Upgrade von Sarge auf Etch: Erste Erfahrungen

Auf die Freigabe von Etch haben wir hier sehnsüchtig gewartet, da beispielsweise neuere MediaWiki-Versionen PHP5 erfordern - verschiedene Projekte hingen daher seit Monaten in der Warteschleife. Obwohl es selten klug ist, frühzeitig auf neue Betriebssystemversionen umzusteigen, migrierten wir einen unserer Rootserver bereits wenige Tage nach dem Release von Etch - frühere Updates, beispielsweise von Woody auf Sarge, hatten auf dem Rechner keine Probleme bereitet.


Hier ein paar Notizen mit unseren ersten Umstiegserfahrungen:


(1) Postfix/Postfix-TLS

Bereits erste Tests zeigten, dass es beim Upgrade zu Etch Probleme mit Postfix/Postfix-TLS geben würde:

# aptitude -y -s -f --with-recommends dist-upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Lese erweiterte Statusinformationen
Initialisiere Paketstatus... Fertig
Lese Task-Beschreibungen... Fertig
Die Abhängigkeiten einiger Pakete sind nicht erfüllt. Das kann
bedeuten, dass Sie eine unmögliche Auswahl getroffen haben oder (falls
Sie die »unstable«-Distribution verwenden), dass einige erforderliche
Pakete fehlen oder aktualisiert werden müssen.
Die folgenden Pakete haben verletzte Abhängigkeiten:
postfix: Kollidiert: postfix-tls aber 2.1.5-9 ist installiert.
postfix-tls: Hängt ab: postfix (= 2.1.5-9) aber 2.3.8-2+b1 soll
installiert werden.

Wir setzen Debian jetzt schon etliche Jahre ein und haben auch schon mehrere Upgrades auf verschiedenen Rechnern mitgemacht; bei einem Versionswechsel von "Stable (alt)" auf "Stable (neu)" ist es dabei noch nie vorgekommen, dass ein großes und wichtiges Paket wie Postfix "verletzte Abhängigkeiten" hatte.

Entsprechend [# http://www.debian.org/releases/etch/i386/release-notes/index.de.html] haben wir jetzt ein paar Upgradeschritte durchgeführt (aptitude upgrade; aptitude install initrd-tools; manuelles Kernel-Update; erneutes aptitude upgrade). Ein dist-upgrade scheitert jedoch weiterhin:

# aptitude dist-upgrade
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Lese erweiterte Statusinformationen
Initialisiere Paketstatus... Fertig
Lese Task-Beschreibungen... Fertig
Die Abhängigkeiten einiger Pakete sind nicht erfüllt. Das kann bedeuten,
dass Sie eine unmögliche Auswahl getroffen haben oder (falls Sie die
 »unstable«- Distribution verwenden), dass einige erforderliche Pakete
fehlen oder aktualisiert werden müssen.
Die folgenden Pakete haben verletzte Abhängigkeiten:
postfix: Kollidiert: postfix-tls aber 2.1.5-9 ist installiert.
postfix-tls: Hängt ab: postfix (= 2.1.5-9) aber 2.3.8-2+b1
soll installiert werden.

Wir haben also "postfix" und "postfix-tls" deinstalliert, was uns den Default-Exim bescherte, und nach dem "dist-upgrade" wieder Postfix installiert, was Exim beseitige; TLS-Unterstützung ist in Etch-Postfix bereits enthalten, separate Pakete können und müssen also nicht mehr nachinstalliert werden.

Seitdem nimmt der Mailserver allerdings keine Mail mehr an, obwohl die Konfigurationsdatei (main.cf) unberührt geblieben ist.

Auch ein dpkg-reconfigure von Postfix (mittlerweile um "postfix-tls" abgespeckt) und eine absolute Minimalkonfiguration mit Debian-Bordmitteln beseitigte das Problem isher nicht: Postfix nimmt keine Mail mehr dem Mailclient Seamonkey entgegen.

Postfix läuft und kann über /etc/init.d/postfix fehlerfrei gestartet und angehalten werden; /var/log/mail.err listet auch keine aktuellen Fehler auf. /var/log/mail.log sagt dasselbe, was Seamonkey sagt: "Relay access denied".

Port 25 sollte auch offen sein:

# lsof -i :25
COMMAND PID USER FD TYPE DEVICE SIZE NODE NAME
master 2269 root 11u IPv4 3833 TCP *:smtp (LISTEN)
smtpd 30031 postfix 6u IPv4 3833 TCP *:smtp (LISTEN)
# nmap localhost
25/tcp open smtp

Telnet auf Port 25, also SMPT-Postfix, funktioniert; Postfix reagiert auch korrekt auf SMTP-Kommandos. Auch der lokale Mailversand auf dem Host scheint zu funktionieren.


(2) Umstellung auf UTF-8

Noch nicht so ganz zu überblicken ist der Rattenschwanz, den die Umstellung auf UTF-8 mit sich bringt.

Ein erster Effekt scheint zu sein, dass die auf dem Server laufenden Drupal-Websites keine Umlaute mehr anzeigen, sondern irgenwelche Steuer- und Sonderzeichen.

Auch sämtliche Konfigurations- und Textdateien sind nun zugemüllt mit fehlerhaften Sonderzeichen. [# http://www.debian.org/releases/etch/i386/release-notes/ch-whats-new.de.html] raunt dazu nur "dass beim Wechsel auf UTF-8 möglicherweise auch existierende Dateien aus ihrer vorherigen Kodierung nach UTF-8 umgewandelt werden müssen". Das manuell durchgeführte "dpkg-reconfigure locales" hilft dabei jedenfalls nicht, und besonders tröstlich finde ich auch nicht, dass das Paket "utf8-migration-tool", das laut Debian "bei der Migration helfen kann", leider "für Etch nicht mehr rechtzeitig fertig wurde".

Ein paar konstruktive Hinweise hierzu wären in den "Hinweisen zur Debian GNU/Linux 4.0-Veröffentlichung" definitiv angebracht gewesen.

Das Problem mit den Drupal-Sites dürfte übrigens nicht direkt durch die Umstellung von Debian selbst auf Unicode verursacht, sondern durch neuere Versionen von PHP bzw. MySQL hervorgerufen werden. Leider schweigen sich die entsprechenden READMEs in /usr/share/doc dazu vollkommen aus.


(3) LAMP

Etch migriert nicht automatisch auf PHP5, das jetzt endlich verfügbar ist; auch durch manuelle Installation des Paketes "php5" bleiben alle möglichen PHP4-Komponenten installiert. Es steht eine Menge Handarbeit an, das alles umzustellen.

MySQL wurde dagegen beim Upgrade auf MySQL5 migriert, allerdings wohl ebenfalls ohne die dazugehörigen Module komplett mitzunehmen. Weder in /usr/share/doc/mysql-common noch in /usr/share/doc/php5 etc. sind passende Hinweise zu finden, was eigentlich geändert wurde oder worauf man bei einem "Umzug" achten müsste. Insbesondere das Thema der Datenbank-Konvertierung auf UTF-8 wird nirgends behandelt.

Nach einigen Stunden Konfiguriererei laufen immerhin ein paar simple Skipte (phpsysinfo, Awstats) und sogar MediaWiki, wenn auch schleppend langsam. Drupal ist weitestgehend eliminiert: Eine Site ist komplett abgeschossen (nur noch leere Seiten), eine andere liefert zwar teilweise Seiten aus, jedoch mit kaputten Umlauten, und keine Nodes (ebenfalls leere Seiten).

# tail -f /var/log/apache2/error.log
Fatal error: Allowed memory size of 16777216 bytes exhausted
(tried to allocate 35 bytes) [...]

Ein Hochsetzen des "memory_limit" von 16M (PHP4) auf 64M beseitigt das Problem; Drupal liefert jetzt auch wieder Nodes aus. Nur: Warum braucht PHP plötzlich die vierfache Menge Speicher gegenüber PHP4?

Übrigens ist laut "phpMyAdmin - 2.9.1.1-Debian-3" der MySQL-Zeichensatz jetzt "UTF-8 Unicode (utf8)". Unklar ist auch, warum es dieses Problem überhaupt gibt: Angeblich speichert Drupal alle Daten ohnehin als UTF-8 [# http://drupal.org/node/8408].

Die Drupal-Sites sind weiterhin zugemüllt mit fehlerhaften Umlauten und Sonderzeichen. Hier kommen wir in den nächsten Stunden ebensowenig weiter wie bei den Text- und Konfigurationsdateien. Auch scheinen etliche Drupal-Module nicht mehr zu funktionieren, obwohl explizite PHP5-Versionen existieren.


(4) Kernel 2.6

Völlig bizarr und wohl spezifisch für den betreffenden Rootserver: Nachdem wir ziemlich sorgfältig und exakt nach [# http://www.debian.org/releases/etch/i386/release-notes/ch-information.de.html>] und [# http://www.debian.org/releases/etch/i386/release-notes/ch-upgrading.de.html] den Kernel von 2.4.29 SMP auf 2.6.18 686 aktualisiert und auch mehrfach die /boot/grub/menu.lst kontrolliert hatte, kam eine Überraschung nach dem Reboot:

# uname -r
2.4.29

Diesen Kernel gibt es aber in der menu.lst nicht; wir haben auch kein Lilo parallel laufen oder jemals einen Kernel manuell installiert.

# dpkg -l "kernel-image*" | grep ^ii
ii kernel-image-2.6.8-2-686 2.6.8-16sarge1 Linux kernel image
for version 2.6.8 on PPro
ii kernel-image-2.6.8-3-686 2.6.8-16sarge6 Linux kernel image
for version 2.6.8 on PPro
# cat /boot/grub/menu.lst | grep kernel
title Debian GNU/Linux, kernel Default
kernel /vmlinuz root=/dev/hda3 ro
title Debian GNU/Linux, kernel Default (recovery mode)
kernel /vmlinuz root=/dev/hda3 ro single
title Debian GNU/Linux, kernel 2.6.18-4-686
kernel /vmlinuz-2.6.18-4-686 root=/dev/hda3 ro
title Debian GNU/Linux, kernel 2.6.18-4-686 (recovery mode)
kernel /vmlinuz-2.6.18-4-686 root=/dev/hda3 ro single
title Debian GNU/Linux, kernel 2.6.8-3-686
kernel /vmlinuz-2.6.8-3-686 root=/dev/hda3 ro
title Debian GNU/Linux, kernel 2.6.8-3-686 (recovery mode)
kernel /vmlinuz-2.6.8-3-686 root=/dev/hda3 ro single
title Debian GNU/Linux, kernel 2.6.8-2-686
kernel /vmlinuz-2.6.8-2-686 root=/dev/hda3 ro
title Debian GNU/Linux, kernel 2.6.8-2-686 (recovery mode)
kernel /vmlinuz-2.6.8-2-686 root=/dev/hda3 ro single

Kurzum: Es ist unklar. woher dieser Kernel kommt und warum er überhaupt bootet.

Unsere Arbeitshypothese, die noch zu prüfen wäre: Es handelt sich ja um einen "Rootserver", den wir nicht selbst aufgesetzt haben; er wurde ursprünglich mit einem "Woody"-Image des Providers (Strato) installiert, dass wir dann aus den offiziellen Debian-Quellen auf Sarge aktualisiert haben.

Wir vermuten momentan, dass dieser Kernel ein Überbleibsel des Strato-Images ist, das sich an der Debian-Paketverwaltung vorbei im System "eingebraben" hat. Da die serielle Konsole des Rootservers in den letzen Monaten sher unzuverlässig war, sprich: öfter mal ausfiel, sind wir hier nicht besonders experimentierfreudig und freuen uns, dass der alte 2.4-er Kernel unter Etch vorerst läuft.


(5) "Kleinigkeiten"

Ein paar "Kleinigkeiten" fielen ebenfalls auf; beispielsweise werden anscheinend keine "Cron"-Jobs mehr ausgeführt, und "logrotate" scheint (vermutlich wegen des nicht funktionierenden Cron) seine Dienste eingestellt zu haben.

Auch Cron läuft und kann über /etc/init.d/ fehlerfrei gestartet gestoppt werden; Fehlermeldungen sind im Syslog nicht erkennbar.


Fazit

Der Zeitpunkt für einen Umstieg auf Etch erscheint uns deutlich verfrüht; im UNterschied zu früheren Debian-Versionen macht dieses Release einen noch etwas unausgereiften Eindruck. Wenn beispielsweise neue Programmversionen von MySQL die Konvertierung von Datenbanken erfordern, sollten die Installationsskripte das erledigen; wenn sie das nicht tun, muß es zumindest Warnungen und weiterführende Hinweise in den Readmes (sprich: in der Systemdokumentation) geben.

Ein Umstiegzum jetzigen Zeitpunkt erfordert enorm viel Zeitaufwand für Reparaturen und Nachbesserungen sowie nicht zuletzt eine äußerst hohe Frustrationstoleranz. Man sollte Etch zunächst dringend auf einem Testsystem installieren, die Neuerungen von systemkritischen Anwendungen vorab recherchieren und unbedingt ein komplettes und funktionierendes (testen!) Komplettbackup anfertigen.

Allerdings funktionierte der Upgradeprozess an sich weitgehend reibungslos, von den merkwürdig kaputten Postfix-Paketen einmal abgesehen. M.E. macht es derzeit noch keinen Sinn, Sarge auf Etch zu upgraden; sinnvoller erscheint es uns, stattdessen Etch komplett neu aufzusetzen - dann schießen wenigstens keine Altlasten möglicherweise quer. Für ein Betriebssystem, dass wir bisher über Jahre hinweg problemlos upgraden konnte, sind diese Umstiegserfahrungen erstmal eine ziemlich herbe Enttäuschung.

Ähnliche Beiträge wie Upgrade von Sarge auf Etch: Erste Erfahrungen

Ansichten Ähnlichkeit
Upgrade von Sarge auf Etch: Erfahrungsbericht Teil 2
Blogeintrag erstellt am 14.04.2007 von asb, zuletzt bearbeitet am 14.04.2007
1.545 724000%
Vorgefundene Konfiguration des Strato HighQ-Servers MR6 – Erfahrungsbericht zum HighQ-Server MR6 von Strato unter Debian GNU/Linux
Blogeintrag erstellt am 17.01.2009 von asb, zuletzt bearbeitet am 18.01.2009
1.854 1514250%
Installation zusätzlicher Anwendungen auf dem Strato HighQ-Server MR6 – Erfahrungsbericht zum HighQ-Server MR6 von Strato unter Debian GNU/Linux
Blogeintrag erstellt am 17.01.2009 von asb, zuletzt bearbeitet am 18.01.2009
2.173 1514300%
Umzug auf den neuen Strato HighQ-Server MR6 – Erfahrungsbericht zum HighQ-Server MR6 von Strato unter Debian GNU/Linux
Blogeintrag erstellt am 18.01.2009 von asb, zuletzt bearbeitet am 28.01.2009
2.101 (1) 1514400%
Upgrade von Etch auf Lenny – Erfahrungsbericht zum Betriebssystemupgrade eines Strato-Rootservers auf Debian GNU/Linux 5.0 ›Lenny‹
Blogeintrag erstellt am 24.02.2009 von asb, zuletzt bearbeitet am 24.02.2009
3.519 1528200%