Upgrade Etch: postfix/postfix-tls defekt? (plus erster Erfahrungsbericht)
Hi,
ich bin gerade dabei, einen Server von Sarge auf Etch zu migrieren;
etwas ungewohnt von Debian kam es dabei zu kräftigen Hindernissen, die
mich wohl noch eine Weile beschäftigen werden; der Rechner wurde bereits
einmal von Woody auf Sarge gehieft, das verlief damals aber reibungslos.
Hier ein paar Notizen mit meinen 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.
Ich nutze Debian jetzt schon einige Jahre und habe auch schon mehrere
Upgrades mitgemacht; bei einem Versionswechsel von Stable -> Stable ist
es mir aber noch nie vorgekommen, dass ein großes und wichtiges Paket
wie Postfix "verletzte Abhängigkeiten" hatte.
Entsprechend [1] habe ich 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.
Ich habe also "postfix" und "postfix-tls" deinstalliert, was mir den
Default-Exim bescherte, und nach dem "dist-upgrade" wieder Postfix
installiert, was Exim beseitige. 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 nicht: Postfix nimmt keine
Mail mehr von meinem Client (Seamonkey) entgegen.
(2) Umstellung auf UTF-8
Noch nicht so ganz überblicken kann ich den Rattenschwanz, den die
Umstellung auf UTF-8 mit sich bringt (das war damals allerdings auch bei
anderen Linux-Distributionen nicht ganz unblutig abgelaufen, wenn ich
mich recht entsinne).
Ein erster Effekt scheint zu sein, dass meine Drupal-Websites keine
Umlaute mehr anzeigen, sondern "Sonderzeichen". Das Thema hat sich aber
vorerst sowieso erledigt, da nach "dist-upgrade" und Reboot sowieso die
dynamischen Sites tot waren (siehe (3)).
Auch sämtliche Konfigurations- und Textdateien sind nun zugemüllt mit
fehlerhaften Sonderzeichen. [2] 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 [2] "bei der Migration helfen kann",
leider "für Etch nicht mehr rechtzeitig fertig wurde".
Ich habe nicht die leiseste Ahnung, wie ich hunderte von Text- und
Konfigurationsdateien entmüllt bekommt, oder wie ich auf den
Drupal-Sites wieder Umlaute angezeigt bekomme. Ein paar konstruktive
Hinweise hierzu wären in den "Hinweisen zur Debian GNU/Linux
4.0-Veröffentlichung" definitiv angebracht.
(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. finde ich
passende Hinweise, was eigentlich geändert wurde oder warum plötzlich
meine Drupal-Sites mit fehlerhaften Zeichen zerschrotet sind. Nach dem
Upgrade waren jedenfalls erstmal alle LAMP-Websites komplett tot, nur
Apache2 lieferte noch tapfer statische Seiten aus.
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) [...]
Hmm... Wessen Speicher ist da erschöpft? 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?
Übrigens ist laut "phpMyAdmin - 2.9.1.1-Debian-3" der MySQL-Zeichensatz
jetzt "UTF-8 Unicode (utf8)". Unklar ist für mich auch, warum es dieses
Problem überhaupt gibt: Angeblich speichert Drupal alle Daten ohnehin
als UTF-8 [5].
Die Drupal-Sites sind weiterhin zugemüllt mit fehlerhaften Umlauten und
Sonderzeichen. Hier komme ich ebensowenig weiter wie bei den Text- und
Konfigurationsdateien. Auch scheinen etliche Module nicht mehr zu
funktionieren, obowohl explizite PHP5-Versionen existieren.
(4) Kernel 2.6
Völlig bizarr: Nachdem ich ziemlich sorgfältig und exakt nach [3] und
[4] den Kernel von 2.4.29 SMP auf 2.6.18 aktualisiert und auch mehrfach
die /boot/grub/menu.lst kontrolliert hatte, kam eine Überraschung beim
Reboot:
# uname -r
2.4.29
Diesen Kernel gibt es aber in der menu.lst nicht, ich habe auch kein
Lilo parallel laufen oder jemals einen rogue Kernel installiert. Kurzum:
Ich habe keine Ahnung, woher dieser Kernel kommt und warum er überhaupt
bootet:
# 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
(5) Kleinigkeiten
Und dann wären da noch ein paar "Kleinigkeiten"; beispielsweise werden
anscheinend keine "Cron"-Jobs mehr ausgeführt, und "logrotate" scheint
(vielleicht deshalb) seine Dienste eingestellt zu haben. Auch damit
werde ich mich noch beschäftigen müssen....
Ich bin mittlerweile total frustriert. Für ein Betriebssystem-Upgrade
halte ich es für ein Desaster, wenn praktisch sämtliche Dienste
disfunktional zurückgelassen werden und der Anwender praktisch an jeder
Ecke "nachputzen" muss. Allerdings funktionierte der Upgradeprozess an
sich weitgehend reibungslos, von den merkwürdig kaputten Postfix-Paketen
einmal abgesehen.
M.E. macht es überhaupt keinen Sinn, Sarge auf Etch zu upgraden; die
jetzt anstehende stunden- und tagelange Fehlersuche würde ich mir lieber
ersparen bzw. in konstruktive Konfigurationsarbeit investieren. Die
nächsten "Sarge"-Rechner werde ich daher wohl komplett neu aufsetzen,
dann schießen wenigstens keine Altlasten möglicherweise quer.
Für ein Betriebssystem, dass ich bisher über Jahre hinweg problemlos
upgraden konnte, ist das erstmal eine herbe Enttäuschung :-(
MfG -asb
PS: Für Tipps zu dem UTF8-Problem wäre ich sehr dankbar...
[1] http://www.debian.org/releases/etch/i386/release-notes/index.de.html
[2]
http://www.debian.org/releases/etch/i386/release-notes/ch-whats-new.de.html
[3]
http://www.debian.org/releases/etch/i386/release-notes/ch-information.de.html
[4]
http://www.debian.org/releases/etch/i386/release-notes/ch-upgrading.de.html
[5] http://drupal.org/node/8408
Reply to: