Updates auf Produktions-Servern
18. April 2008
Beim Ende der Vernunft wird gerade über automatische Updates diskutiert. Da gestern und vorgestern Updates auf den Mailservern stattfanden, gibts hier auch ein paar Worte dazu.
Im bytecamp haben wir eine recht homogene FreeBSD-Umgebung. Wie bei Gentoo Linux werden bei uns alle Programme und Bibliotheken über die Ports selbst compiliert. Das hat verschiedene Gründe. Mal sind es Optimierungen, die mehr Performance bringen, aber hauptsächlich die Flexibilität, die wir gewinnen, wenn wir selbst entscheiden können, welche Bibliotheken mit in die Software hineingelinkt werden und welche nicht.
Gestern ergab ein portupgrade -rRan auf einem Server die Zahl von 61 Ports, die aktualisiert werden mußten. So etwas automatisch per Cron-Job machen zu lassen, wäre grob fahrlässig. Für die meisten Ports lese ich bei freshports.org nach, welche Dinge bei Aktualisierungen zu beachten sind. Bei clamav mußte ich z.B. gestern erst die alten Viren-Definitionen löschen und ein freshclam laufen lassen. Bei zwei verschiedenen qmail-Slaveports vergaß er bei einem portupgrade alle Optionen, die beim Compilieren angegeben wurden. Als Ergebnis hatten wir plötzlich ein qmail ohne SMTP-Auth und Kunden konnten kurz keine Mails versenden. Oft ändert sich durch ein Update auch die Syntax der Konfigurations-Dateien und ein Dienst startet nicht mehr. Oder die Default-Einstellungen zwischen zwei Versionen ändern sich und ein Dienst legt ein anderes Verhalten an den Tag. Deswegen lassen wir automatische Updates schön bleiben.
Die Installation sämtlicher Servertypen ist zeilenweise genau dokumentiert. Die Webserver werden zyklisch grundsätzlich neu installiert und die Installationen dann gespiegelt. Das ist aber auch noch suboptimal. Erklärtes Ziel ist es, mit wenigen Mausklicks ein Jail einzurichten, dort eine Installation zu updaten (oder aufzusetzen) und zu testen, davon wieder per Mausklick ein Image zu erzeugen, welches dann per NFS von den Servern gebootet wird. Geht mal eine Kiste kaputt, weist man das Image der defekten Maschine einfach einem anderen Rechner zu. So kann man nicht nur prima auf Lastspitzen reagieren, sondern auch Updates in aller Ruhe testen.
