STRATO Linux VServer mit Webserver im Rettungssystem

Maintenance Seite

Ich kann den STRATO vServern in ein Rettungssystem starten, welches leider keinen Webserver enthält.
Das Rettungssystem ist Praktisch, da ich über dieses Alternative Betriebssystem an alle Daten die auf dem Server abgelegt sind gelangen kann, auch wenn mein selbst verwaltetes Betriessystem auf dem Server nicht mehr funktioniert. Die Besucher meiner Seite erfahren leider nicht das ich meinen Server grade warte.
Um den potentiellen besuchern meiner Seite jedoch zeigen zu können das meine Seite durchaus noch vorhanden, nur grade in einem Wartungsfenster ist, ist ein solcher sehr wünschenswert.

Der einfache versuch via „apt update && apt install lighttps“ führt jedoch leider zu ein paar nicht sehr aussagekräftigen Fehlermeldungen.

Es fehlen jedoch einfach nur ein paar Benutzer, genauer die Benutzer _apt, der Benutzer postfix und der Benutzer www-data.

Im Anschluss kann der Webserver einfach installiert werden.:

Im Anschluss bearbeite ich die Datei /etc/lighttpd/lighttpd.conf und füge am ende die folgenden 4 Zeilen an.:

Die Raute # in der Zeile ‚#  „mod_rewrite“,‘ muss entfernt werden, so das die erste Zeile jedwede Anfragen an die Datei maintenance.php im Ordner /var/www/html/ umleiten kann.
Die verbleibenden drei Zeilen ermöglichen es dem Webserver PHP-Scripte auszuführen.

Die Datei /var/www/html/maintenance.php gibt in meinem Beispiel den HTTP StatusCode 503 (Vorübergehend nicht verfügbar; Server überlastet, ausgefallen oder in Wartung) und einen kurzen Wartungstext aus.:

Zu guter letzt muss der Webserver nur noch neu gestartet werden, und es wird die Wartungsseite angfezeigt.

git als static binary compilieren

GIT

Was ist eine „static binary“?

Während der Übersetzung eines Quellcodes in ein ausführbares Programm verknüpft der Compiler die ausführbare Datei des Programms, um später bei der Ausführung des Programms Arbeitsspeicher zu sparen, mit „shared dynamic libraries“.

Diese Bibliotheken sind eine Sammlung von Funktionen welche von mehreren Programmen geteilt verwendet werden um bestimmte Aufgaben zu zu erfüllen. Durch die gemeinsame Nutzung dieser Bibliotheken kann der Arbeitsspeicher des Computers geschont werden, da nur eine Kopie der Bibliothek für viele verschiedene Programme im Speicher geladen sein muss.

Um ein unerwartetes Verhalten von Programmen zu vermeiden, ist es manchmal unumgänglich das Programm mit einer bestimmten Version einer Bibliothek zu Übersetzen. Auch um die Portabilität eines Programms zu verbessern ist es wichtig die Abhängigkeit vom vorhanden sein einer dynamischen Bibiothek zu vermeiden.
In Linux Systemen sorgt ein Paketmanager dafür, dass Versionsabhängigkeiten korrekt erfüllt werden. Wenn Du auf einem Computer arbeitest über den Du keine Administrative Kontrolle besitzt kannst Du die Version der verwendeten Bibliothek nicht bestimmen oder eine aktualisiert verhindern.
Programme können, wenn s
ie mit „shared dynamic libraries“ übersetzt wurden nur auf andere Computer übertragen werden auf der, die gleiche Prozessorarchitektur und die gleichen Bibliotheken verfügbar sind.
Falls die Bibliotheken des Computers auf den das Programm übertragen wurde aktualisiert werden, eine Bibliothek entfernt wird oder eine der Bibliotheken
auf dem Zielrechner werden kompromittiert oder durch bösartige Versionen ersetzt. Hier kommt das bauen einer „static binary“ ins Spiel.
Wie wird GIT als „static binary“ übersetzt?

in diesem Beispiel gehe ich davon aus das die NAS gemäß dieser Anleitung bereits mit dem notwendigen Buildsystem eingerichtet wurde. Im Anschluss kann die entstehende Binärdatei von GIT auf allen identischen ARM Prozessoren verwendet werden.
Die aktuellste GIT Version kann auf http://git-scm.com gefunden werden.

Folgende 3 Schritte sind auszuführen:

1) GIT Quellcode herunterladen, entpacken und in das GIT Buildverzeichnis wechseln:

2) Die Compilervariablen setzen und git mittels configure konfigurieren um in ein separates Verzeichnis zu übersetzt zu werden:

3) git übersetzen:

In das Zielverzeichnis installieren

4) Prüfe das GIT so wie erwartet funktioniert

Raspberry Pi: Animiertes Bootlogo (splash screen)

Ich suchte für meinen MAME-Retro-Arcasde Automaten nach einer Möglichkeit ein Bootlogo anzuzeigen, so das ersichtlich ist das der Automat noch startet. (und nicht etwa hängen geblieben ist)

Leider dauert das laden des Linux-Systems und des MAME mehrere Minuten auf dem Raspberry Pi, so das ein stehendes Bild wie ein abgestürztes System erscheinen. Die Linux Boot-Meldungen hingegen passen nicht zu einem Spielautomaten.

Ich persönlich verwende für meinen Spielautomaten ein statisches Bild, das MAME-Logo, vor welches ich einen loading spinner! gelegt habe.
Sehr schön für einen Spielautomaten sind auch animierte Charaktere aus klassischen Spielen, wie die Eule aus Apydia. Suche bei der Suchmaschine deine Wahl nach „animated gif sprites“ um einige zu finden.Agony (1992) Art & Magic / Psygnosis

Die Bootmeldungen können über die drei Einträge „consoleblank=0 loglevel=1 quiet“ in der Datei cmdline.txt im Verzeichnis /boot abgeschaltet werden.
Ebenfalls in der Datei cmdline.txt kann das Bootlogo, die Himbeeren die oben links erscheinen, mittels „logo.nologo“ abgeschaltet werden.
Mit dem Eintrag disable_splash=1 in der Datei config.txt im Ordner /boot schaltet Ihr auch noch das Regenbogen-Startbild des Raspberry Pi ab.

Splashscreen Werkzeuge wie FbiPlymouth oder FMI unterstützen leider keine Animationen. Das Werkzeug bannerd von Alexander Lukichev füllt genau diese Lücke und bietet die Möglichkeit eine Serie von BMP-Bildern als Animation wiederzugeben. (Die Letzte Aktualisierung des von bannerd ist leider aus dem September 2012)

Im Raspbian Repository ist bannerd aktuell leider nicht vorhanden, kann jedoch einfach aus den Quellen übersetzt werden.
Hierzu holen wir den Quellcode aus dem GIT-Repository und übersetzen es im Anschluss mittels make.:

Im Anschluss muss die entstandene Datei bannerd in den Ordner /usr/local/bin/ oder /bin kopiert werden, ausführbar gemacht werden sowie der Eigentümer und die Gruppe auf root geändert werden.

Als Bootanimation ist bei bannerd ausschließlich eine Sequenz von BMP Bildern möglich. Wenn die Boot-Animation bereits als Videodatei oder als animiertes Gif vorliegt kann diese mittels ffmpeg in eine Bildsequenz umgewandelt werden.

Da mein Beispiel GIF eine Transparenz hat und ffmpeg leider automatisch weiß als Hintergrundfarbe bei der Umwandlung in Dateiformate ohne Apha Kanal.
Wenn Du eine andere Hintergrundfarbe als weiß benötigst können solche animierte GIFs leider nicht direkt umgewandelt werden.
Mit dem Umweg über PNG Bilder mit Alpha Transparenz können den BMPs auch andere Hintergundfarben gegeben werden.:

Wenn das animierte GIF als kleine Animation in der unteren rechten Ecke des Bootbildes angezeigt werden soll können die Animationphasen mit folgenden Befehlen mit einem Hintergrundbild zusammengefügt werden. (Das Hintergrundbild wird im folgenden Beispiel mittels Imagemagic als leeres schwarzes Bild erzeugt.)

Nach dem wir jetzt den Dienst bannerd haben und die anzuzeigende Animation abgelegt haben brauchen wir noch einen systemd Service der im Bootvorgang bannerd startet.

der Service kann in Form der folgenden Datei /etc/systemd/system/bootlogo.service erzeugt werden:

Jetzt muss der nrur Dienst noch aktualisiert werden.: sudo systemctl enable bootlogo
Das Bootlogo kann mit dem Befehl systemctl start bootlogo oder mit einem neustart des Computers getestet werden.

Neuer Linux Kernel für Raspberry Pi

Manchmal brauche ich einfach das eine oder andere Kernel Modul welches sich nicht im Vanilla Kernel meines Rasbian befindet, oder ich möchte unbedingt einige Module loswerden oder ich will einen aktuelleren linux Kernel.
Um eines oder alle diese Ziele zu erreichen muss ein neuer Linux Kernel für den Raspberry Pi angefertigt werden. Hier die Kurzanleitung wie dies in fünf einfach Schritten zu schaffen ist.:

1.) Linux Kernel Quellen herunterladen

Um den Aktuellen Kernel übersetzen zu können brauchen wir einige Module. Um diese zu Installieren nutzen wir apt-get install.:

Um den „aktuellen“ Linux Kernel zu bekommen holen wir über Git die Quellen:

alternativ können wir auch einen aktuelleren Kernel (im Beispiel 4.5) holen lassen.:

und wechseln in das Installationsverzeichnis.

2.) Default Konfiguration erstellen

Im Anschluss muss ich die default Linux Konfiguration für meinen Raspberry Pi erstellen, für Raspberry Pi 1 A oder B und das Compute Module:

für den Raspberry Pi 2 geht dies über:

3.) Kernel konfiguration anpassen (optional)

um die Konfiguration des Linux Kernels anzupassen bietet Linux die

oder alternativ

4.) Kernel übersetzen

um den Kernel im Anschluss zu compilieren die folgenden Zeilen ausführen:

5.) Kernel Installieren

Wenn der Kernel einen abweichenden Namen erhalten soll kann in der Datei config.txt die Zeile „kernel“ für den verwendeten Kernel angepasst werden.:

Raspberry Pi 2 – Arch Linux Installation aus einem Linux System

Vorbereiten der SD-Karte. Ersetze sdX in den folgenden Schritten durch den entsprechenden Namen des Gerätes unter dem deine SD-Karte in Linux erschienen ist. (leicht über dmesg|tail direkt nach Anschluss der SD-Karte zu finden)

  1. Starte fdisk um die SD-Karte zu partitionieren:
    sudo –s # um alle folgenden Schritte als Benutzer root auszuführen
    fdisk /dev/
    sdX
  2. In der fdisk Eingabe lösche die alten Partitionen und erstelle die neuen:
    1. Der Befehl o löscht alle Partitionen auf der Karte.
    2. p zeigt alle vorhandenen Partitionen an. Es sollte keine mehr existieren
    3. Wähle n, für neue Partition, dan p für primäre Partition, im Anschluss 1 für die erste Partition, danach ENTER um den ersten Sektor zu bestätigen und +100M für den letzten Sektor.
    4. Im Anschluss t, danach c um den Typ der Partition auf „W95 FAT32 (LBA)“ zu setzen.
    5. Drücke n, dan p im Anschluss 2 für die zweite Partition dann ENTER zwei mal um sowohl den ersten als auch den letzten Sektor zu bestätigen.
    6. Schreibe die Partitionstabelle und verlasse das Programm mit w.
  3. Erstellen des ext4 Dateisystems:
    mkfs.ext4 /dev/sdX2
    mkdir /mnt/root
    mount /dev/sdX2 /mnt/root
  4. FAT-Dateisystem erstellen und mounten:
    mkfs.vfat /dev/sdX1
    mkdir /mnt/root/boot
    mount /dev/sdX1 /mnt/root/boot
  5. Lade die ArchLinux Distribution auf das root Dateisystem:
    wget http://archlinuxarm.org/os/ArchLinuxARM-rpi-2-latest.tar.gz
    tar -xpf ArchLinuxARM-rpi-2-latest.tar.gz -C /mnt/root
    sync
  6. Die beiden Partitionen unmounten:
    umount /mnt/root/boot /mnt/root

Jetzt ist die SD-Karte bereit für den Raspberry Pi. Nach dem Anschluss von Netzwerk und 5V-Stromversorgung startet er ArchLinux.
Eine Verbindung ist über angeschlossenen Monitor und Tastatur, SSH und Serielle Konsole möglich.
Der Benutzername des default Benutzers ist „alarm“ sein Passwort lautet „alarm“.
Das root-Password lautet „root“.

shellshock II (RPM-Paket erstellen)

In der chroot-Umgebung aus der ersten Anleitung kann auch direkt ein rpm Paket erstellen, welches eine saubere Installation der aktualisierten Bash ermöglicht.

Die Anleitung beginnt an Punkt 2 (2. Bash Quellen bereitstellen) der ersten Anleitung!

In der chroot-Umgebung des Build Systems einen Benutzer für den Paketbau anlegen:

Im Anschluß werden die für rpmbuild notwendigen Verzeichnisse, die drei Bash Konfigurations-Dateien .bashrc, .bash_profile, .bash_logout und die Specs-Datei für den rpm-Paketbau angelegt und die Bash Quellcodes sowie Patches heruntergeaden.:

Die bash.spec-Datei enthält die Konfigutarion des Paketes sowie die bei der Installation und deinstallation notwendigen Scripte. Die Vorliegende SPECS Datei ist eine bearbeitung der Original Quelle von Fedora Core 12, welche ich für die aktuelle BASH angepasst habe.

Jetzt kann mit rpmbuild das Paket erstellt werden, welches direkt im Anschluss mit rpm Installiert werden kann. Das alte Bash Paket wird hierbei durch das neue Paket ersetzt.


Das aus diesem Tutorial entstehende Bash-Binary und RPM-Datei zur Installation

squashfs Image einer Linux Distribution über Grub starten

Dies ist eine „Kurzanleitung“, wie ein squashfs Image über Grub zu starten. Ich gehe davon aus, das Grub installiert ist und das du das <LinuxBootCD>.iso Image besitzt.

Um unser Ziel zu erreichen kopieren wir einige Dateien aus dem ISO Image und schaffen einen Grub Eintrag.

Jetzt sind alle benötigten Daten kopiert, es folgt die GRUB Einrichtung.

Dies ist bereits der gesammte Prozess. Nach der aktuelisierung der Grub Konfiguration via update-grub ist existiert der neue Boot-Eintrag.

Zeit neu zu booten und im Grub den neuen Boot-Eintrag zu wählen.

Ich mag diese Art der „Installation“, da der Boot-Vorgang dank squashfs sehr schnell und vor ungewollten Veränderungen geschützt ist. 😉

X-server-minimal

Die X-Server Grundinstallation

$ aptitude install xserver-xorg-core

zusätzlich muss noch eine Terminal Emulation, einen Window Manager und gegebenen falls das Programm für den Ziffernblock manuell installiert werden.
Terminal Emulationen:
– xterm (1180kB)
– multi-aterm (188kB) mit Tabs
– xvt (139kB)

Window Manager:
– icewm
– fluxbox oder blackbox

Um den Ziffernblock unter X.ORG zu aktivieren wird das folgende Programm benötigt, es ist für Notebooks, Netbooks nicht sinvoll und wird auch bei einer KDE, gnome oder xfce Installation unnötig.
– numlockx

Xserver starten

Um den Server manuell zu starteten wird folgendes in die Schell eingegeben:
$ startx icewm (in dem angegeben beispiel wird icewm gestartet!)

Komfortabler geht es mit einem Displaymanager wie xdm (X Display Manager). Wird ein solcher installiert, bootet der Rechner bis zu einem grafischen Login um dann den Windowmanager / die Deskop Umgebung zu starten.

Displaymanager

– xdm (ca 1MB)
– gdm (ca 9MB + Gnomelibs)
– kdm (ca 1MB + KDELibs)
– login.app (ca 1MB)
– slim (ca 1MB)
– wdm (ca 1MB)

Window Manager

$ aptitude install xserver-xorg-core icewm

Die Empfehlung aus „Xserver-minimal“ und „Displaymanager“:
$ aptitude install xserver-xorg-core icewm numlockx multi-aterm wdm

ergeben eine einfach zu nutzende grafische Oberfläche.
Eine Liste von Window Managern, die in debian enthalten sind, befindet sich im [„SoftwareFinder/GUI“].
Gedanken und Konfigurationsdateien für einen leichtgewichtigen Desktop (engl)

Desktop Umgebungen

KDE minimal

$ aptitude install xserver-xorg-core kdebase kdm
– Platzverbrauch durch diese Installation(zusätzlich zur Basisinstallation): 103MB + Sprachunterstützung (24MB)
– Arbeitsspeicherverbrauch durch diese Installation: ?
– Windowmanager ist enthalten: kwin
– kdm kann auch weggelassen werden wenn man einen anderen(oder keinen) Displaymanager nutzen möchte.
– kde-i18n-de für die deusche Tastaturunterstützung

Gnome minimal

$ aptitude install xserver-xorg-core gnome-core gdm
– Platzverbrauch durch diese Installation(zusätzlich zur Basisinstallation): 157MB
– Arbeitsspeicherverbrauch durch diese Installation: ?
– Windowmanager ist enthalten: metacity
– gdm oder anderen, oder keinen Displaymanager nutzen

XFCE minimal

$ aptitude install xserver-xorg-core xfce4 gdm
– Platzverbrauch durch diese Installation zusätzlich: 81MB
– RAM nutzung durch diese Installation: ~ 80 MB
– Windowmanager ist enthalten: xfwm
– gdm oder anderen, oder keinen Displaymanager nutzen

Schriften

Anwendungen welche GTK1 benutzen (zum Beisspiel xmms, emelfm) haben nach der Installation ohne eines der Folgenden Pakete unlesbare Schriften. Je nach eingestellter Auflösung:
– xfonts-100dpi-transcoded (ca 12MB)
– xfonts-75dpi-transcoded (ca 10MB)
– xfonts-base-transcoded (ca 2MB)