Debian Lenny: erste Erfahrungen
Nachdem ich in den letzten Tagen einige Maschinen - heimische und Mietserver, letztere mit und ohne serielle Konsole - von Debian Etch auf Lenny hochgezogen haben, sind mir dabei einige Gemeinsamkeiten aufgefallen. Zunächst vielleicht das wichtigste: die in den Release Notes angesprochenen Probleme mit neu nummerierten Devices oder gar Problemen beim Auffinden des Root-Filesystems beim Reboot (Device enumeration reordering, System boot hangs on Waiting for root file
system) sind bei mir glücklicherweise in keinem Fall aufgetreten; das verlief vielmehr alles durchaus problemlos, sei es mit LILO als Bootloader (ggf. an Verkleinerung der RAM-Disk denken, Prepare initramfs for LILO!) oder mit grub. Das hat mich besonders erleichtert, weil, wie gesagt, nicht alle entfernten Maschinen über eine serielle Konsole und damit über die Möglichkeit eines einfachen Zugriffs bei Bootproblemen verfügen.
Auch ansonsten verliefen die Upgrades an und für sich - bei der in den Release Notes empfohlenen Vorgehensweise - erfreulich unproblematisch. Das gehört auch zu den Dingen, die ich an Debian besonders schätze: der Upgrade-Prozeß ist in der Regel schmerzlos, gut dokumentiert und getestet. Hilfreich insbesondere, wenn man sich in den eher zentralen und maschinennahen Bereichen nicht so besonders auskennt und/oder keinen unmittelbaren Zugriff auf das System hat.
Schon allein ein Blick auf Munin zeigt aber einige Veränderungen, die sich aus den in den Beitrag eingestreuten Graphiken ergeben. Dass der Platzverbrauch im Rootverzeichnis - genauer wohl in /libs - gestiegen ist, hatte ich schon vorgestern nach dem Update der ersten Maschine berichtet. Das ist aber natürlich nicht die einzige Veränderung - es gibt auch positives zu berichten. So hatte ich zuerst den Eindruck gewonnen, daß die Speicherauslastung zurückgegangen ist, nicht nur, soweit sich die Buffer nach dem Reboot erst einmal wieder füllen müssen, sondern auch, soweit der von Applikationen in Anspruch genommene Speicher betroffen ist. Das scheint mir aber ein Irrtum gewesen zu sein; mit der Zeit steuert die Auslastung wieder dem bisherigen Wert zu. Was sich aber definitiv direkt um Größenordnungen erhöht und insoweit verbessert hat, ist die zur Verfügung stehende Entropie, wichtig für die Erzeugung von Zufallswerten, insbesondere auch im Zusammenhang mit der Verschlüsselung. Auf den meisten Maschinen ist die Erhöhung eine generelle, auf einer Maschine ist sie zumindest eine temporäre. Zumindest auf einer Maschine hat sich auch die Anzahl der MySQL-Queries spürbar verringert; das erscheint mir aber eher zufällig zu sein (oder steckt vielleicht irgendwo im neuen INN drin - denn der dürfte auf dieser Maschine für die SQL-Queries in erster Linie verantwortlich sein).
Ansonsten finden sich die meisten Veränderungen, wie in den Release Notes schon angekündigt, rund um den Apache herum: die Konfigurationsdatei wurde deutlich entschlackt und die Konfiguration von Modulen in die entsprechenden Module - in mods-available/ - verschoben, phpMyAdmin wird nicht mehr über einen Symlink, sondern direkt über einen Alias aus der Serverkonfiguration (in conf.d/phpmyadmin.conf, ein Symlin auf /etc/phpmyadmin/apache.conf) eingebunden, und mod\_suphp muß auf einen anderen MIME-Type reagieren (application/x-httpd-php statt x-httpd-php) und wird per default für /usr/share, wo die in Debian gepackageten Webapplikationen liegen, deaktiviert (in mods-available/suphp.conf). Das erfordert ggf. einige Nacharbeit. Hat man zum Beispiel bisher den https-Zugriff auf phpMyAdmin dadurch erzwungen, daß das DocumentRoot für den normalen, unverschlüsselten Zugriff auf den Server nicht auf /var/www/ zeigt, sondern auf ein anderes Verzeichnis, so daß phpMyAdmin nur beim Aufruf per https gefunden werden konnte, hilft das jetzt nicht mehr, denn per Alias-Direktive wird es immer eingebunden. Hier kann man stattdessen an der passenden Stelle ein SSLRequireSSL in /etc/phpmyadmin/apache.conf einsetzen. Wenn man auch die Webapplikationen (weiterhin) nicht unter mod\_php, sondern unter mod\_suphp laufen lassen will (vielleicht schon deshalb, weil man mod\_php gar nicht installiert hat), dann sollte man die entsprechenden Änderungen in mods-available/suphp.conf auskommentieren.
Schließlich beschwerte sich pam\_env bei mir seit dem Upgrade, daß es /etc/default/locale nicht finden könne. Ein Anlegen der Datei beseitigt diese Fehlermeldungen aus dem Logfile.
Eine Sache ist mir allerdings noch etwas schleierhaft, und zwar hatte ich zumindest auf einer Maschine das Problem, das php-cgi ab und an segfaultet:
Apr 16 19:50:37 machine kernel: [113175.233973] php-cgi[2618]: segfault at b6d62eae ip b638e3cf sp b6b940b8 error 4 in libgcc\_s.so.1[b6387000+c000]
Apr 17 01:25:27 machine kernel: [134723.984243] php-cgi[31344]: segfault at b6c94eae ip b62c03cf sp b6ac60b8 error 4 in libgcc\_s.so.1[b62b9000+c000]
Apr 17 18:08:37 machine kernel: [199692.119127] php-cgi[21780]: segfault at b6d2be90 ip b6d2be90 sp b6b5d3ac error 4 in librt-2.7.so[b771f000+7000]
Apr 17 18:14:32 machine kernel: [200072.558515] php-cgi[22441]: segfault at b6cd9e90 ip b6cd9e90 sp b6b0b3ac error 4 in libtasn1.so.3.0.15[b759d000+f000]
Das tut es eben nicht immer, nur manchmal, vorher nicht und seitdem auch nicht mehr. Google hat mir eine entsprechende Anfrage eines Nutzers auf der Debian-User-Mailingliste aus dem Februar präsentiert, die allerdings bisher AFAIS ohne Antwort geblieben ist; dort scheinen mir dieselben Symptome dargestellt zu sein. Fällt jemand etwas dazu ein?
Trackbacks
Keine Trackbacks
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt