huschi.net

Ein Update von Etch auf Lenny soll i.d.R. Probleme beheben.
Manche Probleme entstehen aber auch dabei.

Hier soll ein Sammelbecken von Problemen und Lösungen entstehen, welche beim Upgrade auf Lenny vorkommen können.

Der Upgrade auf Lenny

Der Upgrade selbst ist schnell vollzogen:

1. Sicherstellen dass alle Pakete aktuell sind:
<code>apt-get update && apt-get dist-upgradecode>

2. Ändere alle Einträge in <code>/etc/apt/sources.listcode> von <code>etchcode> auf <code>lennycode>.

3. Den Upgrade starten:
<code>apt-get update && apt-get dist-upgradecode>

4. Da ein neuer Kernel installiert wird, muss die Maschine einmal rebootet werden.

Lösungen:

Saslauthd

Bei saslauthd gibt es zwei Punkte zu beachten:
1. Ein neuer Parameter für <code>/etc/default/saslauthdcode>. Ohne diesen Parameter kommt folgende Warnung bei einem <code>restartcode>:

Short name (NAME) undefined in /etc/default/saslauthd, using default
Stopping default [ OK ]
Starting default [ OK ]

Behoben wird der Fehler durch die Ergänzung von <code>NAMEcode>:

NAME="saslauthd"

2. Dennoch kommt weiterhin keine Verbindung zwischen dem Postfix <code>smtpdcode> und <code>saslauthdcode> zustande:

postfix/smtpd[25948]: warning: SASL authentication failure: cannot connect to saslauthd server: Permission denied

Zusätzlich liegt es an den Verzeichnisrechten von <code>/var/spool/postfix/var/run/saslauthdcode>. Diese wurden von <code>drwxr-xr-xcode> auf <code>drwx--x---code> verkürzt. Und zusätzlich gehört das Verzeichnis nicht mehr der Gruppe <code>rootcode> sondern <code>saslcode>.

Setzt man lediglich die Verzeichnisrechte auf 755 hat man kurzfristigen Erfolg. Aber ein Neustart des Servers bzw. des Saslauthd setzt die Rechte wieder zurück.
Denn der reguläre Weg ist den User <code>postfixcode> in die Gruppe <code>saslcode> aufzunehmen:

adduser postfix sasl

Apache: "Warning: SuexecUserGroup directive requires SUEXEC wrapper"

Nach dem Neustart von Apache kommt oben genannte Meldung.
Auswirkung: Alle Perl bzw. FastCGI/fcgi-Prozesse werden wieder als <code>www-datacode> ausgeführt statt mit den richtigen User-Rechten.

Behoben wird das Problem per Neuinstallation von <code>suexeccode> welches aus irgendeinem Grund mit fehlendem SetUID-Bit installiert wurde.

apt-get install –reinstall apache2-suexec
/etc/init.d/apache2 restart

Please check that your locale settings

Häufig kommt es vor, dass die locales-Einstellungen nicht übernommen werden.
Dabei werden oft die Environment-Variablen <code>LANGUAGEcode>, <code>LC_ALLcode> oder <code>LANGcode> bemängelt.

Abhilfe schafft ein neuer Aufruf zur Einstellung:

dpkg-reconfigure locales

Zukunftssichere Admins setzten bereits auf <code>de_DE.UTF-8code>.
In manchen Fällen hielt sich diese Fehleinstellung so permanent, dass erst ein Reboot die neue Einstellungen aktiviert.

Weitere Probleme nach dem Upgrade

Wer von weiteren seltsamen Dingen berichten kann, darf sie mir gerne mailen. Auch wenn noch keine eigene Lösung erarbeitet wurde.