Alle guten Dingen enden einmal, oder: Downtime morgen ab ca. 17:15 Uhr

Yamagi

Possessed With Psi Powers
Teammitglied
Hallo BSDForen,
heute sind es auf den Tag genau 5 Jahre, dass BSDForen.de auf diversen Versionen und Patchlevel der FreeBSD 8 Reihe läuft. Das sind 1826 Tage ohne einen einen einzigen Crash, ungeplanten Reboot und was sonst alles so an unschönen Dingen passieren kann. Auf einem Supermicro-Mainboard für Sockel F mit den legendären "Nforce Professional"-Chipsatz, wie man vielleicht noch einmal besonders betonen sollte. :)

Aber alles muss einmal zu einem Ende kommen und obwohl FreeBSD 8.4 noch einige Monate Support hat, möchte ich die langen Winterabende für eine große Updaterunde nutzen. Ich werde daher morgen den Host auf FreeBSD 10.1 aktualisieren. Es ist ein recht großer Sprung, dazu kommen Backups, der Umstieg auf jail.conf, eventuell Syntax-Änderungen an der pf.conf und was alles dazu gehört. Ich habe auch ein wenig Schiss wegen dem gmirror über zwei komplette Platten, auf dem ein MBR-Slice mit dem BSDLabel drin liegt. Wir alle wissen, dass es eigentlich funktionieren sollte, man aber aus Gründen inzwischen einzelne Partitionen spiegelt. Worst Case muss man da also noch mit einer Live-CD bei. Kurz gesagt: Gebt mir einige Stunden.

Lange Rede, kurzer Sinn:

Morgen am Dienstag, den 20. Januar 2015 ist BSDForen.de ab ca. 17:15 (+/- ein paar Minuten) für einige Stunden nicht erreichbar.

Es werden noch einige weitere Downtimes folgen, da ich auch die Jails aktualisieren und teilweise umbauen muss. Das wird dann aber extra angekündigt.
 
Wow, wäre echt cool da ein log oder so zu haben von den Dingen auf die du da stößt. Nur falls das nicht zu viel Arbeit macht natürlich. :)

Vor allem das mit den Jails klingt spannend.

Viel Glück!
 
Auch von mir viel Glück und an dieser stelle vielen Dank für die jahrelange gute Arbeit hinter den Kulissen - auf weitere 5 genauso stabile Jahre!
 
jaja, manchmal ist ein Ölwechsel notwendig ;-) Viel Erfolg, Grüße und Dank, Norbert

PS: Es sind die vielen kleinen, unscheinbaren Dinge, die die Essenz ausmachen... Ich denke z.B. an Admins - wenn sie mal nicht da sind, merkt man, wie wichtig sie sind :-)
 
So, die Aktion ist eigentlich sehr glatt gelaufen. Ich essen nun mal was, schaue was dämliches im Fernsehen und schreibe nachher noch einen längeren Bericht.
 
So, nun noch einmal etwas ausführlicher: Ich habe zuerst die Jails heruntergefahren und alle sonstigen Dienste beendet. Außerdem habe ich die Jails aus der rc.conf genommen und in ihre Partionen in der fstab auskommentiert. Dann Reboot in den Single User Mode. Dort zuerst jede der System-Partionen mit fsck(8) behandeln und anschließen per dump(8) gesichert. Dabei habe ich einige sehr große Dateien, die ich eh nochmal im Offline-Backup habe und die nicht lebenswichtig sind, per "nodump"-Flag ausgeschlossen.
Danach mit "mount -a" alle Partitionen eingehängt. Den neuen Kernel und die neue Welt hatte ich bereits zuvor gebaut und nur auf den Server kopiert. Die 8 Opteron-Kerne sind zwar nicht langsam, aber mein Desktop ist doch deutlich schneller und vor allem läuft er nicht mit Apache um die Wette. Also:

Code:
cd /usr/home/build/10.1/src
setenv MAKEOBJDIRPREFIX /usr/home/build/10.1/src

Die Umgebungsvariable sagt ihm, wo er seine Objekte findet. Leider ist der Pfad zu den Sourcen noch immer im Objekt-Verzeichnis vernudelt und kann auch nicht ohne weiteres geändert werden, weshalb man die Sourcen auf der Quell- und der Zielmaschine im gleichen Verzeichnis haben muss. Oder sich zumindest etwas mit Nullfs basteln. Dann versucht den Kernel mit "make installkernel" zu installieren. Ich ging davon aus, dass es abbrechen würde und tatsächlich tat es das. Daher war der gute, alte Make-Trick notwendig:

Code:
cp /usr/bin/make /root/make
cp /usr/home/build/10.1/obj/usr/home/build/10.1/src/usr.bin/bmake/make /usr/bin/make

Da /usr/bin/make statisch gelinkt ist und so gut wie keine Syscalls nutzt, kann der alte Kernel mit sehr hoher Wahrscheinlichkeit das neue Binary ausführen. Da die Installation von Kernel und Welt ausschließlich das make-Kommando vom Host nutzen (alles andere wird aus der neuen Welt genommen), kann man so Inkompatibilitäten zwischen einem zu alten make(1) auf dem Host und zu neuen Makefiles in den Sourcen umgehen. Beim Bauen klappt es leider nicht, da sie in der ersten Phase wesentlich mehr Tools des Hosts nutzen.

Zumindest war am Ende der Kernel problemlos installiert und ich konnte das System ein zweites Mal rebooten. Nun passierte genau das, was ich bereits befürchtet hatte. FreeBSD 10.1 weigert sich aufgrund des gmirror die Partitionen zu lesen und kann folglich kein Rootdateisystem mounten:

Code:
GEOM_PART: integrity check failed (mirror/gm0, MBR)

Ich entschloss es erst einmal mit der Trickkiste zu probieren, bevor ich eine Live-CD über die IPMI-Karte nudel und neu partitioniere. Dafür also Reset und im Loader zum Prompt gewechselt. Dort dann die Integritätsprüfungen abgeschaltet. Das lief jahrelang, sie sind nur ein Ergebnis eines strikteren Parsers. Also nicht gefährlich:

Code:
set kern.geom.part.check_integrity="0"

Und tatsächlich bootet er dann wieder in den Single User Mode durch. Eine kurze Analyse ergab, dass die MBR-Tabellen und das darin liegende BSDLabel den einen Sektor zu lang sind, den gmirror für seine Metadaten nutzt. Sie gingen also über die ganze Platte, der gmirror war aber einen Sektor kleiner. Dadurch erkannte der Kernel eine Inkonsistenz und um mich schützen weigerte er sich. Das lässt sich aber relativ simpel reparieren. Dazu beginnt man mit einem Dump des BSDLabel:

Code:
gpart backup mirror/gm0s1 > bsdlabel_dump

Nun öffnet man die Datei in einem Editor und macht die letzte Partition einfach einen Sektor kleiner. Anschließend schreibt man das BSDLabel mit Gewalt neu:

Code:
gpart restore -F mirror/gm0s1 < bsdlabel_dump

Das gleiche wird mit dem umgebenden MBR wiederholt. Anschließend noch ein Reboot um sicherzustellen, dass die Inkonsistenz behoben ist. Danach weiter mit dem Installieren der Welt:

Code:
cd /usr/home/build/10.1/src
setenv MAKEOBJDIRPREFIX /usr/home/build/10.1/src
mergemaster -m /usr/home/build/10.1/src -UFi
make installworld
make installworld

Zweimal, da der Sprung FreeBSD 8.4 -> 10.1 offiziell nicht unterstützt wird und man nie weiß, ob im ersten Durchlauf nicht dich irgendwo mal auf den Host zurückgegriffen wurde und Dinge unbemerkt schief gegangen sind. Paranoid, ich weiß. Aber die 2 Minuten mehr brauche ich für meinen Seelenfrieden. Nun noch ein Mergemaster:

Code:
mergemaster -m /usr/home/build/10.1/src -UFi
etcupdate extract

Das "etcupdate extract" ist für das nächste Mal. Denn Mergemaster ist ein wirklich dummes Tool. Ich hatte mal wieder gleich mehrmals das Problem, dass er mir die Originalzeile zusammen mit weiteren Upstream-Änderungen als Ersatz für meine Zeile anbot, die ich aber gern behalten wollte. Also nichts neues unter der Sonne. Noch schnell die alten Dateien und Bibliotheken abgeräumt und ein weiterer Reboot in den Multi User Mode:

Code:
yes | make delete-old
yes | make delete-old-libs

Wieder per SSH auf der Kiste habe ich zuerst /etc/ durchgeschaut. Meine von Mergemaster zerkloppten Dateien repariert, die rc.conf aufgeräumt und die sysctl.conf einmal durchgegangen. Dann erstmal mein universelles Aufräumkommando, was diverse Sicherheitskopien von "make installkernel" und "make installworld" abräumt:

Code:
rm -Rf /boot/*old /libexec/*old /etc/*old /etc/*orig

Da die Paketdatenbank nur dumm von pkg_install auf pkg konvertiert worden war, wollte ich sie gleich neu machen. Also auch hier einmal Tabula Rasa:

Code:
cp -r /usr/local/etc /root/local_etc
rm -Rf /usr/local /usr/ports /var/db/pkg/* /var/db/ports/* /var/db/portsnap/*
mkdir /usr/ports
portsnap fetch extract
pkg bootstrap

Der Rest war dann das normale Vorgehen. Die gewünschten Pakete installiert und gleich einen neuen Satz meiner Dotfiles hinterher. Die alten waren Jahre alt. Die Scripte durchgegangen, ob sie noch funktionieren und einige kleinere Anpassungen vorgenommen. Die pf.conf einmal aufgeräumt, denn da hatte sich über die Jahre etwas harmloser aber nervender Wildwuchs ergeben. Die jail.conf hatte ich schon vorher geschrieben, musste ich also nur noch einkopieren. Ich habe dann die Partitionen der Jails noch einmal mit fsck(8) gescannt, sie anschließend gemountet und die Jails wieder gestartet. Sie kamen sauber wieder hoch.

Das alles war nun lediglich das Host-System. Es folgen nun als nächstes Updates für die Jails, zumindest für MySQL und den Webserver muss es sichtbare Downtimes geben. Die kündige ich natürlich vorher an. Aber nun ist erst einmal Feierabend. :)
 
Zuletzt bearbeitet:
Ich bin jetzt mal ganz frech und frage mal so blauäugig: Hätte sich da eine komplette Neuinstallation mit ZFS nicht rentiert? :)

Vielen Dank für deine Mühe. Ist immer interessant, so einen Bericht zu lesen...
 
WOW!!
Ich bin begeistert. So ein Bericht, nach der Nervenarbeit. [Hätte ich es auch geschafft (den Bericht)? zu 80% nicht.]
Also Note: 1* und dann schauen alle mal das das Ding wieder x Jahre läuft, ohne Zicken und Bla-bla-bla. Dh. alle sind aufgerufen kein Blödsinn (so wie ich) zu schreiben, das belastet die CPU und die Festplatte duckt sich, nicht zu vergessen, der Arbeitsspeicher dreht sich um und flüchtet.
Also nochmal:
Herzlich Gratulation für diese brillante Tätigkeit.
 
foxit schrieb:
Ich bin jetzt mal ganz frech und frage mal so blauäugig: Hätte sich da eine komplette Neuinstallation mit ZFS nicht rentiert?

Eine Neuinstallation wäre unter dem Strich sicher kaum aufwändiger gewesen. Wenn überhaupt. Über ZFS hatte ich nachgedacht, aber da die Maschine "nur" 8 Gigabyte RAM hat und mir ein Update auf 16G zu aufwändig erschien, habe ich die Idee wieder verworfen. Mal ganz grob gedacht, ist die Maschine nun sowieso schon wieder 5 Jahre alt und wir sollten für nächstes Jahr etwas Neues ins Auge fassen. Da würde ich dann natürlich auch gleich ZFS nehmen.

darktrym schrieb:
Ich hab das Gefühl, das Forum ist jetzt reaktiver.

Das ist dann aber die Arbeit der FreeBSD Kernel-Entwickler und nicht meine. :)
 
Mal ganz grob gedacht, ist die Maschine nun sowieso schon wieder 5 Jahre alt und wir sollten für nächstes Jahr etwas Neues ins Auge fassen.
Nachdem sich die Leute hier positiv äußerten ("reaktiver"), scheint die Maschine aber noch durchaus gut genug zu sein. Never change a running system.
 
Von der Leistung her wird die Maschine noch Ewigkeiten reichen. Ich meinte nur, da jahrelanger 24/7-Dauerbetrieb irgendwann jede Maschine kaputt bekommt und der Erfahrung nach so nach 6 bis 8 Jahren die Probleme beginnen. Mal schauen, erstmal behalten wir sie noch.
 
das habe ich mir nie bewusst gemacht: ihr habt da einen eigenen Server, also eigene HW irgendwo rum stehen?
Macht man dies heute nicht über eines der vielen Angebote aus dem Web, wo man dann einen Server (also eine VM) mietet?

Mir gefällt es viel besser, Zugriff zur HW zu haben, aber wieso habt ihr (bzw Yamagi und/oder Kith) euch anders entschieden und behaltet das Konzept so bei?
Und wie sieht das denn mit den Betriebskosten aus? Das Ding arbeitet ja auch nicht umsonst.
 
Zurück
Oben