Ich habe es gewagt an einem "Freitag den 13." ein Update von einigen meiner Linux-VServer von Debian 4.0 ("Etch") auf Debian 5.0 ("Lenny") zu machen.
Zu meiner Überraschung lief das ohne größere Probleme. Hier ein paar Notizen was so aufgetreten ist:
Neues Layout der Konfiguration von Apache2
Unter /etc/apache2/ hat sich einiges getan. u.a. ist die Datei /etc/apache2/apache2.conf kürzer geworden und einiges aus dieser Datei ist in das Verzeichnis /etc/apache2/conf.d gewandert. Das finde ich wirklich besser als vorher.
klogd mit sysklogd machten im Linux-VServer Probleme
klogd wollte im VServer einfach nicht starten. Hierfür gibt es eine einfache Lösung: einfach stattdessen rsyslog verwenden. Man kann sogar in der Datei /etc/rsyslog.conf den Eintrag "imklog" auskommentieren, da ein Linux-VServer ja kein Kernel-Logging benötigt.
neues PHP5 memory_limit
die php.ini von PHP5 hat jetzt ein memory_limit von 128M
Trac 0.11
Trac hat mich etwas mehr Zeit gekostet, da sich die Konfiguraton gegenüber der Version 0.10 etwas geändert hat. Vorher habe ich Trac in Verbindung mit FastCGI verwendet. Bei der Version 0.11 habe ich mich für modpython entschieden. Natürlich musste ich noch das WebAdmin-Plugin aus meinem "EggCache" löschen, da dieses Plugin seit 0.11 Bestandteil von Trac geworden ist.
Die Trac "Datenbank" muss mit dem Programm trac-admin und dem Kommando "upgrade" auf den neuesten Stand gebracht werden. Man sollte auch noch das Kommando "wiki upgrade" verwenden um die Standard-Wiki-Seiten auf die neue Version zu heben.
Subversion
Bei Subversion lief bis auf ein älteres Repository alles ohne Probleme. Das besagte Repository hatte das "bdb"-Layout, verwendete also das Berkeley-DB Backend und kam noch aus der Migration von Debian 3.1 ("Sarge"). Jetzt gab es beim Zugriff über den Apache (mod_dav_svn) eine Fehlermeldung. Als ich ein Dump (via svnadmin) von diesem Repository machen wollte kam ein bdb-Versionskonflikt Version 4.4/Version 4.6 zutage.
Abhilfe schaffte hier ein "svnadmin recover". Hiernach konnte ich ein "svnadmin dump" von dem Repository machen. Dann habe ich ein neues Repository angelegt (natürlich wie empfohlen "fsfs") und habe den Dump eingefahren. Et Voilà... das Repository funktioniert jetzt wieder tadellos.
Der Rest
Die restlichen Programme wie munin, mercurial, apt-cacher usw. machten beim Upgrade keinerlei Probleme.
Jetzt habe ich "nur" noch 6 Linux-VServer mit Debian 4.0 ("Etch") die ich dann auch noch irgendwann mal migrieren sollte... Im November gibt es wieder einen "Freitag den 13." - bis dahin habe ich hoffentlich schon die Zeit gefunden und alle VServer brav migriert.
Abonnieren
Kommentare zum Post (Atom)
Keine Kommentare:
Kommentar veröffentlichen