Gestern kriegte ich bescheid gesagt, dass ein Server, den ich mitbetreue, kaputt gegangen sei. Die Hardware wurde vom Hoster getauscht, allerdings wurden auch neue Platten eingebaut. Der Hoster bot an, zusätzlich die alte Platte anzuschließen, um die Daten zu kopieren. Warum er die Daten nicht einfach selbst kopierte, verstehe ich nicht ganz.
Im Rescue-System (ein grml) konnten wir dann die alte Platte (7 Jahre
Betriebsstunden, uff) und die neuen Platten sehen. Nach einem kurzen
dd waren die Daten dann kopiert, danach ging das Anpassen und
Debuggen los. Hier eine Checkliste, was man beachten sollte:
/etc/udev/rules.d/70-persistent-net.rules muss man
einen entsprechenden Eintrag für die neue Netzwerkkarte hinzufügen und
die alten entfernen, damit die neue Netzwerkkarte nicht als eth1
erkannt wird und plötzlich keine Konfiguration mehr hat.
Praktischerweise kann man den nötigen Inhalt direkt aus der
/etc/udev/rules.d/70-persistent-net.rules des
Rescue-systems kopieren./etc/mtab sollte, sofern sie existiert und noch
eine reguläre Datei ist, durch einen Symlink auf
/proc/mounts ersetzt werden.update-initramfs -k all -u
aktualisiert werden.grub-install --recheck
/dev/sda mit aktueller device map installiert werden./etc/fstab sollte angepasst werden.Alle diese Punkte hatten wir befolgt, aber nach einem Neustart kam der Server trotzdem nicht hoch. Eine serielle Schnittstelle, KVM, Remote-Hands o.ä. hatten wir nicht zur Verfügung.
Als nächstes habe ich dann netconsole probiert, um auf einem anderen Rechner die Bootmeldungen zu lesen. Das kriegt man unter Debian folgendermaßen hin:
echo 'forcedeth' >> /etc/initramfs-tools/modules echo 'netconsole netconsole=6655@111.222.333.444/eth0,6644@555.666.777.888/00:0c:db:4e:e8:00' >> /etc/initramfs-tools/modules update-initramfs -k all -u
Wobei hier 111.222.333.444 die IP des Servers ist und 555.666.777.888 die IP
ist, an welche die Nachrichten geschickt werden. Wichtig ist hier noch, dass
die MAC-Adresse diejenige des Gateways ist, damit die Pakete ins Internet
gelangen. Die kann man mit ip -4 neighbor show herausfinden.
Des Rätsels Lösung war dann, dass im BIOS des Rechners die alte Festplatte
zuerst gelistet war, sodass er wieder ins alte System startete. Gelöst haben
wir das dann mit dd if=/dev/zero of=/dev/sdc bs=5M count=10, womit
man den MBR und die Partition Table (und Daten!) der alten Platte überschreibt,
sodass das BIOS diese beim Starten überspringt.
Soeben habe ich i3 v4.2 released. Die Release notes enthalten alle Neuerungen.
Soeben habe ich i3 v4.1.1 released. Die Release notes enthalten alle Neuerungen.
Perl-Module von CPAN installieren ist eigentlich ganz einfach, aber viele Leute wissen nicht, was sie mit der entsprechenden Fehlermeldung anfangen sollen. Daher habe ich http://michael.stapelberg.de/cpan online gestellt, eine Seite, welche erklärt, wie man ein Perl-Modul von CPAN installiert (einmal mit und einmal ohne Root-Rechte).
Die Seite hat ein paar nette Features (in modernen Browsern): Sie bietet Erklärungen für die einzelnen Schritte, welche nach Klick auf die Fragezeichen-Buttons eingeblendet werden. Weiterhin kann man in das Textfeld eine konkrete Fehlermeldung pasten und die Seite passt sich auf genau das fehlende Modul an. Wenn man die URL z.B. im IRC verschickt, kann man durch Anhängen von #Module::Name an die URL, also zum Beispiel http://michael.stapelberg.de/cpan#X11::XCB eine angepasste Seite für das entsprechende Modul verlinken.
systemd ist lange überfällig, denn die Schmerzen beim Überführen eines quick'n'dirty shell scripts in einen ordentlich wartbaren Dienst sind mit sysvinit einfach viel zu groß.
Vor ziemlich langer Zeit habe ich den RaumZeitMPD geschrieben, einen IRC-Bot, welcher bei !stream anzeigt, welches Lied gerade gespielt wird und bei !stream <url> die angegebene URL abspielt. Später wurde er erweitert um bei !ping die Rundumleuchte für 5 Sekunden aufleuchten zu lassen, damit einer der Anwesenden seine Aufmerksamkeit auf das IRC richtet.
Dieser Bot lief bislang in einer screen-Session auf der Blackbox. Dieses Setup ist natürlich nicht ideal, denn sofern die Blackbox neugestartet wird, muss jemand mit Zugriff auf die Blackbox diese Session neustarten. Das ist unzuverlässig und erfordert, dass permanent mindestens eine Person das Wissen haben muss, wie man den RaumZeitMPD startet. Eine bessere Lösung ist es, ihn bei Systemstart zu starten und als Daemon laufen zu lassen.
Das kriegt man natürlich mit sysvinit hin. Ein Initscript, welches anhand des minimale Debian-Beispiels angefertigt wurde, ist allerdings 140 Zeilen lang. Zum Vergleich: Der (Perl-)Code für RaumZeitMPD ist 173 Zeilen, inklusive 30 Zeilen Dokumentation! Mein Projekt hat sich also gerade um fast 100% aufgeblasen, nur damit ich es bei Systemstart starten lassen kann.
Doch das ist nicht das eigentliche Problem, daran hat man sich ja gewöhnt. Die richtigen Schmerzen spürt man, wenn man sich um das daemonizing kümmert. Hierzu gibt es zwei Möglichkeiten:
--background und --make-pidfile beim
Aufruf von start-stop-daemon(8) im Initscript. Der Nachteil:
start-stop-daemon setzt /dev/null als stdin, stdout
und stderr. Plötzlich braucht man also eigenes Logging, und damit verbunden
wieder Parameter, also auch Parameterverarbeitung, eine Hilfefunktion,
Dokumentation.
Proc::Daemon, das
stellt aber eine zusätzliche Dependency dar, da es nicht mit perl
mitgeliefert wird. In der Vergangenheit habe ich die Erfahrung gemacht, dass
sehr viele Nutzer (auch erfahrene Nutzer) vor CPAN zurückschrecken. Das
Modulsystem von Perl ist leider zu unbekannt. Daraus resultiert, dass ich
daemonizing selbst implementieren müsste, was zwar möglich ist (und auch
nicht mehr als ca. 50 Zeilen Code sind), aber das ist Code, der nicht in mein
Script (!) gehört. Das soll kurz und prägnant bleiben, ohne Code, der nicht
dem eigentlichen Zweck dient.
Nun kann man natürlich einen Kompromiss wählen und
start-stop-daemon zum daemonizing benutzen, aber via
Sys::Syslog nach syslog loggen. Das ist gut, denn damit bekommen
wir die aktuelle Uhrzeit, den Programmnamen, die PID und flexible
Umlenkungsmöglichkeiten (remote logging) beim Logging geschenkt. Allerdings
sind viele Scripts so gestaltet, dass sie relativ viel loggen. Das syslog ist
(meiner Ansicht nach) wichtigen Meldungen vorbehalten. Ich würde also deutlich
weniger loggen als in meiner ursprünglichen Version in der screen-Session, was
schlecht ist – logs helfen enorm beim Verstehen/Analysieren von Problemen. Die
Lösung dafür ist also, rsyslogd so zu konfigurieren, dass er die
Ausgabe für den RaumZeitMPD in eine eigene Datei schreibt:
$ cat /etc/rsyslog.d/raumzeitmpd.conf # Log all lines from RaumZeitMPD to /var/log/raumzeitmpd.log (without syncing) # and discard them. :programname, isequal, "RaumZeitMPD" -/var/log/raumzeitmpd.log :programname, isequal, "RaumZeitMPD" ~
Doch damit ist aus dem Script auf einmal ein vollwertiger Daemon geworden, den
ein Gelegenheitshacker nicht mehr interaktiv "mal eben" erweitern kann – nach
dem aufwändigen Clonen des Codes und Installieren der Abhängigkeiten müsste er
nun auch noch seinen syslog-daemon umkonfigurieren, neustarten und permanent
tail -f /var/log/raumzeitmpd.log in einem anderen Fenster laufen
lassen.
Wie hilft hier nun systemd? Es nimmt mir die ganze Arbeit ab. Ich muss mich
nicht darum kümmern, beim starten zu daemonizen (oder im Vordergrund zu
bleiben, wenn man interaktiv debuggen will). Ich kann in meinem Script einfach
nach stdout und stderr loggen, im service-file raumzeitmpd.service
langt der Eintrag StandardOutput=syslog damit bei Systemstart nach
syslog geloggt wird – interaktive Aufrufe schreiben dennoch nach stdout. Ich
brauche keine Optionen einführen. Mein Script bleibt hübsch und konzentriert
sich auf das Wesentliche.
Sobald systemd etwas verbreiteter ist, können wir uns endlich von daemonizing, logging und anderem obsoleten Unsinn trennen und ohne viel Aufwand einfache Scripts in sinnvoller Weise deployen.
Soeben habe ich i3 v4.1 released. Die Release notes enthalten alle Neuerungen.
Nachdem meine SSD nun schon mehrfach für manche Blöcke Input/Output-Errors gegeben hat (nach einem power cycle war sie aber wieder benutzbar), ist sie gestern so ausgefallen, dass ich mich nicht mehr an meinem System anmelden konnte und das Symptom auch über einen Neustart bestehen blieb.
Da ich ja schon vorher Anzeichen hatte, hatte ich mir rechtzeitig Ersatz bestellt und so beschränkte sich die Reparatur auf Austauschen der Platte und Zurückspielen des Backups. Da ich zwischen dem Ausfallzeitpunkt und letztem Sicherungszeitpunkt ein paar kleine Änderungen an zwei Dateien gemacht hatte, habe ich ein grml gebootet und die SSD mit einem alternativen Superblock gemountet – dadurch konnte ich dann auf die Dateien zugreifen.
Bei der neuen SSD (eine OCZ Vertex 2, die hat derzeit das beste Preis-/Leistungsverhältnis) habe ich diesmal die Partitionen so angelegt, dass sie auf eine 512 KiB großen Erase Block Size ausgelegt sind. Mehr als Dokumentation für mich denn als Anleitung hier die nötigen Schritte:
$ fdisk -S 32 -H 32 /dev/sda $ fdisk -l /dev/sda Device Boot Start End Blocks Id System /dev/sda1 1024 511999 255488 83 Linux /dev/sda2 513024 117230591 58358784 83 Linux # the unit of align-payload is 512 byte sectors $ cryptsetup luksFormat --align-payload=1024 /dev/sda2 # /boot $ mkfs.ext4 -b 1024 -E stride=512,stripe-width=512 -O ^has_journal /dev/sda1 $ cryptsetup luksOpen /dev/sda2 sda2_crypt $ mkfs.ext4 -b 4096 -E stride=128,stripe-width=128 /dev/mapper/sda2_crypt
Für die „told you so“-Leute (oder Datenpunkt-Sammler, welche SSDs wann ausfallen): Die alte SSD war von SuperTalent und hielt gute 1,5 Jahre. Ich habe nie TRIM benutzt, was die Symptome erklären könnte. Was man probieren könnte, wäre, die Platte leer zu machen, TRIM zu nutzen und schauen ob sie die defekten Sektoren dann ordentlich wegsortiert. Ich hab aber derzeit nicht die Motivation / Mittel dazu.
Die Moral von der Geschichte ist natürlich, wie toll tägliche Backups sind. ♥
Soeben habe ich i3 v4.0.2 released, ein Bugfix-Release. Die Release notes enthalten alle Neuerungen.
Lesetipp: Understanding and Optimizing 802.11n von Buffalo Technology.
Soeben habe ich i3 v4.0 released. Die Release notes enthalten alle Neuerungen.