HAPPYTEC.at :: Blog

Teil Vier in einer Serie rund um Tipps für die Verwendung des Raspberry Pi in einem Rechenzentrum. Heute mit dem üblichen Problem bei Remote-Systemen, dass man Boot-Ausgaben nicht sehen kann. Allerdings geht es hierbei rein um jene Ausgaben der Init-Scripte. Die Kernel-Meldungen findet man sowieso im Syslog und via dmesg. Um die Ausgaben der startenden Dienste sehen zu können, sollte man bootlogd installieren. Dann werden alle Ausgaben unter /var/log/boot abgelegt. Um Startprobleme von Diensten zu analysieren ist das unverzichtbar.

Ein weiteres Thema sind die Ausgaben des RPi's über HDMI/Composite. Gerade im RZ wird dort (hoffentlich) nichts angeschlossen sein. Und genau deshalb kann man jene Konsolenausgaben (mit Kernelmeldungen usw.) gleich ausblenden...

Im dritten Teil der Tipps für den Raspberry Pi im Rechenzentrum - aber natürlich auch für alle anderen Einsatzzwecke - geht es um den Swap-Speicher, also die Auslagerungspartition/-datei unter Linux.

Anders als der Titel vermuten lässt, empfehle ich trotz reiner Verwendung von Flash-Medien (Speicherkarte, USB-Sticks, ...) unbedingt eine Swap-Partition mit ~256MB anzulegen. So hat man wenigstens einen kleinen Puffer, wenn der Arbeitsspeicher voll läuft. Ein Swapfile wäre zwar auch noch eine Option, das ist allerdings noch langsamer und sollte nur eine Notoption sein. Was man allerdings unbedingt anpassen sollte, ist die Swapiness. Beim Standardwert von 60 wird meistens deutlich zu viel ausgelagert, was nicht nur die Lebenszeit des Flash-Speichers drastisch verkürzt sondern auch noch zu einem langsamen System führen kann.

Bereits beim letzten Mal habe ich mit fake-hwclock die Lösung für ein Zeitproblem beim Raspberry Pi im Rechenzentrum angesprochen. Damals noch zur Umgehung von Problemen bei der Dateisystemüberprüfung beim Systemstart. Doch auf die Frage: "Wie spät ist es?", kann der RPi so tatsächlich nur: "Der Zeiger liegt in der Kurve!", antworten. Um ein System ohne Echtzeituhr aber dafür mit aktiver Internetverbindung sinnvoll verwenden zu können, sollte man immer NTP einsetzen. Mittels NTP (und dem gleichnamigen Paket) kann man die virtuelle Uhrzeit des Kernels dauerhaft mit anderen Zeitservern synchron halten. Doch leider gibt es hierbei zwei Probleme:

Bis zur ersten Synchronisierung vergehen teilweise mehrere Minuten nach dem Systemstart.
Und bei zu großer Abweichung der Zeit, kann NTP die automatische Aktualisierung verweigern.

Mein Raspberry Pi ist seit letzter Woche im Rechenzentrum von EDIS untergebracht. Und da der letzte Beitrag aus technischer Sicht etwas mager ausgefallen ist, wird es Zeit für einige hilfreiche Tipps. Heute mit: Mounten will gelernt sein!

Es gibt nichts schlimmeres als einen RPi im Rechenzentrum, der nicht mehr booten will. An ziemlich oberster Stelle der Problemursachen liegen natürlich die Speichermedien, die beim Systemstart eingebunden werden. Sofern nicht wirklich ein physikalischer Defekt vorliegt und z.B. nur das Dateisystem "leicht" beschädigt ist, hat man vor allem beim Root-Filesystem sehr gute Chancen, dass es sich von selbst reparieren kann. Doch dazu muss es zuerst einmal als Read-Only gemountet sein. Das habe ich bereits vor zwei Wochen im Beitrag [fsck] rootfs is not mounted read-only genauer beschrieben. Sofern das letzte Argument in der /etc/fstab für die Hauptpartition dann eine "1" ist, steht der automatischen Überprüfung beim Systemstart nichts mehr im Weg:

Code:

# <file system> <mount point> <type> <options> <dump> <pass>
/dev/mmcblk0p3 / ext4 noatime,errors=remount-ro 0 1

Ein weiteres reales Problem ist...

Der Raspberry Pi ist ein sehr kleiner Einplatinencomputer, den man um ~35€ bekommen kann und der mittlerweile zu einem sehr beliebten System mit weltweit vielen Fans herangewachsen ist. Mit einer Prozessorleistung von 700 MHz (~1 GHz übertaktet) und 512 MB Ram gehört er nicht zu den stärksten Computern, aber das will er auch gar nicht sein. Neben dem Ziel der (schulischen) Förderung rund um Informatikthemen, hat der RPi vor allem als Thin-Client, Mediaplayer (z.B. mit XBMC), Prototypen und Experimente (dank den GPIO-Pins) sowie nicht zuletzt als kleiner Homeserver eine große Beliebtheit errungen. Um letzteres soll es in diesem Blogpost gehen.

Kleingeräte mit ARM-Prozessoren in ein Rechenzentrum zu verfrachten ist prinzipiell keine neue Idee. Bereits zu Zeiten der damals sehr günstigen und beliebten Dockstar's - die eigentlich nur abgewandelte SheevaPlug's sind - wollte netcup für eine monatliche Gebühr von ~15€ ein Housing der Geräte anbieten. Allerdings scheiterte es damals an der hohen Wärmeentwicklung und der fehlenden Abführmöglichkeit. Damals wurde ich zwar ebenfalls zu einem Fan der Dockstar (und betreibe immer noch einige 24/7), die Idee mit dem RZ fand ich allerdings weniger prickelnd. Der Hauptgrund dafür war unter anderem die Fehleranfälligkeit von USB-Festplatten und die dadurch zu erwartenden Kosten, vor allem für Remote Hands, wenn das Teil ausfallen sollte. Jeder normale (v)Server schien da deutlich günstiger zu sein.

Zwei Jahre später (also 2012) waren die Dockstar's/SheevaPlug's quasi vergessen und ein neues Gerät gewann die Aufmerksamkeit der Nerds und all jener, die es noch werden wollten. Mit dem RPi kam ein Gerät auf den Markt...