Debian Upgrade leicht gemacht: Von Wheezy über Jessie auf Stretch

Ich setze auf 90% meiner Server Debian Linux als Betriebssystem ein. Leider bin ich manchmal etwas schludrig in Bezug auf größe Distributionsupdates, was bei Debian auch gar nicht so furchtbar schlimm ist. Die LTS-Zeiten des Debian-Teams sind dankenswerterweise sehr, sehr großzügig.

Entsprechend hatte ich noch einen Stapel Server, auf dem Debian Wheezy (7.11 aus 2013) lief. Dessen LTS endet aber nun im Mai 2018 und spätestens dann ist es höchste Eisenbahn auf eine neuere Version zu wechseln. 

Meine Erfahrungen will ich hier dokumentieren und für die Nachwelt festhalten 🙂

Status Quo

Auf den betroffenen Servern lief folgende Software (also „insgesamt“ gedacht):

• Apache 2.2
• mySQL 5.5
• PHP 5.6
• Dovecot
• Postfix
• Let’s Encrypt
• SpamAssassin
• Endanwender-Tools: WordPress, Typo3, WebsiteBaker

Der Updateprozess

Ein direktes Update von Wheezy (7.x) auf Stretch (9.x) ist nicht vorgesehen und auch absolut nicht ratsam. Lieber langsam und dafür sicher den Umweg über Jessie (8.x) gehen. Spätestens bei dem Upgrade auf Jessie merkt man, was kaputt gegangen ist und was man nochmal fixen muss.

Dabei ist der Schritt von Wheezy zu Jessie tatsächlich der größere, da sich hier für das o.g. Software-Setup einiges ändert! (Dazu mehr gleich im Abschnitt „Fallstricke und mögliche Probleme“.)

Das Update an sich ist hier sehr gut beschrieben. Es gibt auch zwei Dokumente von Debian, die mögliche Probleme adressieren (für Wheezy und Jessie). Eine sehr ausführliche Abhandlung über die Risiken gibt es auch hier.

Im Endeffekt funktioniert das Update in wenigen Schritten immer gleich, egal ob von Wheezy auf Jessie oder Jessie auf Stretch:

1. Einen screen öffnen, damit eventuelle Netzwerkprobleme nicht zum Abbruch des Upgrades führen, gerade wenn man per SSH unterwegs ist
2. Sicherstellen, dass alles up to date ist (apt-get update && apt-get upgrade)
3. Schauen, ob noch Pakete „on hold“ sind, z.B. mit dpkg –get-selections | grep ‚hold‘
4. Die sources.list von apt anpassen, sodass die neuen Pakete geladen werden können; am einfachsten geht das z.B. mit einem Befehl wie sed -i ’s/ALTEVERSION/NEUEVERSION/g‘ /etc/apt/sources.list, wobei ALTEVERSION beispielsweise für Wheezy und NEUEVERISON für Jessie steht
5. apt-get update
6. apt-get upgrade
7. apt-get dist-upgrade
8. Neustart z.B. mit reboot

Fallstricke und mögliche Probleme

Apache 2.2 auf 2.4: Syntaxprobleme

Der Versionswechsel bei Apache bedeutet auch große Änderungen in der Syntax. Davor hatte ich am meisten Angst, denn so wird zum Beispiel das AllowOverride für alle Hosts auf None gesetzt, wenn nicht explizit etwas anderes angegeben wird. Eventuell vorhandene .htaccess Dateien werden so möglicherweise nicht mehr berücksichtigt.

Die Quick and Dirty^TM Lösung ist folgendes in die apache2.conf (oder httpd.conf) an eine beliebige Stelle einzubauen:

<Directory />
        Options FollowSymLinks
        AllowOverride All
        Require all denied
</Directory>

<Directory /var/www/>
        Options Indexes FollowSymLinks
        AllowOverride All
        Require all granted
</Directory>

Das birgt jedoch einige mögliche Sicherheitsrisiken, gerade wenn man fremde User auf dem Server hat, da man die .htaccess quasi komplett freigibt. Und die feine englische Art ist es auch nicht. Aber für’s erste als kleiner Hack reicht es.

Außerdem ändert sich die Rechtesyntax, sodass der Verzeichnisschutz mit .htpasswd eventuell unwirksam wird. 99% aller Admins setzen aber mit Sicherheit schon die neue Syntax ein, die bereits vor Jahren eingeführt wurde – so auch bei mir, da gab es keine Probleme.

Die Apache Foundation hat eine gute Zusammenfassung der Syntaxänderungen hier bereitgestellt, die mir sehr geholfen hat.

Fail2Ban gibt den Geist auf

Bei dem Upgrade von Jessie auf Stretch wird Fail2Ban nicht richtig migriert und entsprechend kackt das Ding komplett ab. Am besten mit apt-get remove fail2ban entfernen und dann nach dem Upgrade wieder installieren.

Warum genau das Tool so Probleme macht… keine Ahnung, ich habe auf eine Fehleranalyse verzichtet.

PHP5.x wird PHP7.x

Mit dem Upgrade auf Jessie, spätestens aber auf Stretch fliegt PHP5.x raus. Das ist auch gut so, denn der LTS für PHP5.6 läuft aktuell aus und der für PHP5.4 ist schon lange abgelaufen. Außerdem ist PHP7.x deutlich performanter, tatsächlich sogar spürbar schneller!

Einige Anwendungen haben Probleme mit PHP7, so zum Beispiel WordPress-Installationen unter Version 4.x, Typo3-Versionen unter 6.x oder das furchtbare CMS WebsiteBaker unter Version 2.10, das leider einer der User einsetzt. Hier hilft nur händisches Nachschauen und Updaten. 

Vorsicht jedoch: Nach dem Upgrade ist PHP7 bei mir nicht aktiv gewesen und PHP5.6 lief einfach unbehelligt weiter. Zwar zeigte in php -v in der Konsole schon PHP7 an, allerdings nutzte der Apache weiter PHP5.6. Grund hierfür ist, dass im Zuge des Upgrades das Modul für PHP7 nicht automatisch geladen wird. Das muss man händisch nachholen, und zwar so:

1. a2dismod php5
2. a2enmod php7.0
3. service apache2 restart

Auch sollte man eventuell noch folgende Pakete nachinstallieren, wenn man Typo3 einsetzt: apt-get install php7.0-apcu php7.0-soap. Diese werden von den meisten Typo3-Installationen benötigt, APCu ist außerdem ein gutes Cache-Tool.

Dovecot zickt herum

Bislang war es üblich beim Mailserver Dovecot in die Konfiguration einzubauen, dass der Mailserver das SSLv2-Protokoll verbieten soll. Die entsprechende Direktive !SSLv2 gibt es allerdings nicht mehr und muss aus der dovecot.conf entfernt werden. Dann startet Dovecot wieder so wie es soll.

EFF Certbot („Let’s Encrypt ACME Client“) vermisst Python

Zumindest bei mir hat es Python zerlegt. Damit der Certbot wieder die korrekten Pakete nachinstallieren kann, das Verzeichnis /opt/EFF.org vollständig löschen. Keine Sorge, die Zertifikate werden nicht gelöscht, nur die Cache und Settings vom Certbot, die jeder sich aber neu generiert und dann alles wieder korrekt installiert.

Das ist vermutlich die einfachste Lösung aller Zeiten 🙂

Apache motzt wegen LockFile und SSLMutex rum

Beide Direktiven gibt es im Apache 2.4 nicht mehr und müssen ersetzt werden. 

LockFile wird zu Mutex file:${APACHE_LOCK_DIR} default

SSLMutex wird einfach nur zu Mutex default.

Apache neustarten und es läuft wieder 🙂

Fazit

Ansonsten war bei mir alles prima. Die Probleme mit dem Dovecot und Apache haben einiges an Nerven gekostet (immer die wichtigsten Dienste machen Probleme!), aber schlussendlich findet man überall Hinweise – so unterschiedlich die Systeme und die Migration dieser auch sind, so oft hat man doch auch die gleichen Probleme.

Damit liefen die Migrationen deutlich problemloser ab als ich befürchtet hatte. Also ran an den Speck, denn wer nicht jetzt upgraded bereut es spätestens nach Mai 2018 😉