Dist-Upgrade auf Debian 8 Jessie: Mein persönlicher Erfahrungsbericht

Rund drei Monate nach dem Release von Debian 8 Jessie hatte ich das Gefühl es wäre nun an der Zeit für ein Upgrade meines Haupt-Servers von Debian 7 Wheezy nach Debian 8 Jessie. Der Startschuss von Debian 8 war am 25. April 2015. Ich hatte bereits die Tage zuvor gleich zweimal hintereinander das Jessie Upgrade Dokument durchgelesen, um sicher zu gehen, auf keinen bösen Blocker nach dem ersten Reboot zu stoßen.

Jetzt im Nachhinein sehe ich meiner Entscheidung skeptisch entgegen. Grundsätzlich wird Debian Oldstable noch mindestens ein Jahr supported, bei Wheezy wäre das also bis April 2016, wobei auch Debian 7 Wheezy vielleicht LTS Support bekommt (es werden noch Entwickler oder Spender gesucht). Aus Sicht der Security noch lange kein Zeitdruck das System up zu graden. Ich habe es trotzdem getan. Was mich an der Umstellung am meisten gestört hat, sind die kleinen aber fiesen Änderungen an den Paketen wie Apache (2.4) und PHP (5.6). Ich hoffe, mein persönlicher Erfahrungsbericht hilft dem einen oder anderen Sysadmin bei seiner Planung & Beachtung der nötigen Anpassungen.

Die Problemliste

Diese Liste der automatisch erneuerten Programmversionen durch Debian 8 Wheezy sollte selbstverständlich äußerst sorgfältig ausgewertet werden. Ich möchte an dieser Stelle meine eigene kleine Tabelle zeigen, worin ich alle bei meinem Upgrade aufgetretenen Probleme vermerke. Weiter unten gehe ich auf das Problem der Slowloris Attacken ein und verliere ein Wort über die Feststellung, dass Debian 8 als Systemd<>SysVinit Zwitter das alte SysVinit nicht abschütteln will.

Apache 2.4: Ohne Anpassungen bleiben die Webseiten offline

Die Umstellung auf Apache 2.4 hat mich am meisten Nerven gekostet. Es ist nämlich so, dass Apache 2.4 jedes Config-File in /etc/apache2/sites-enables/ mit der Endung *.conf haben will. Sonst wird die Konfiguration schlicht und ergreifend nicht mehr eingelesen. Ich wusste das durch eine Diskussion auf meiner Arbeit bereits vorher und habe diese Konfigurationsdateien schon vor dem Dist-Upgrade angepasst.

Nach dem Upgrade bleiben die Webseiten trotzdem tot – bzw. mit einem Forbidden 403 offline. Ursache ist eine weitere Umstellung in der Konfiguration. Diese beiden Zeilen:

Order allow,deny
Allow from all

müssen durch einen Einzeiler:

Require all granted

ersetzt werden. Im Umkehrschluss wird aus diesen beiden deny Zeilen:

Order deny, allow
Deny from all

ein

Require all denied

Leider schluckt der alte Apache 2.2 auf Debian 7 diese Änderung noch nicht, weshalb erst nach dem Dist-Upgrade die Konfiguration korrigiert werden kann. Im besten Fall sollte man sich die neue Apache-Config als Kopie bereits erstellen & griffbereit ablegen, womit die Apache-Downtime nach dem Dist-Upgrade verkürzt werden kann.

Apache 2.4: Keinen guter Schutz gegen Slowloris mit mod_qos

Auch fies mit Apache 2.4: Die beliebte mod_qos ist teilweise defekt. Mod_qos startet zwar mit einer Warnung, aber die wichtigste Zeile gegen Slowloris #QS_SrvMinDataRate 150 1200 funktioniert nicht mehr:

Jul 31 16:19:26 apache2[20356]: AH00526: Syntax error on line 27 of /etc/apache2/mods-enabled/qos.conf:
Jul 31 16:19:26 apache2[20356]: Invalid command 'QS_SrvMinDataRate', perhaps misspelled or defined by a module not included in the server configuration

Aus diesem Grund sind gegen Slowloris abgesicherte mod_qos Apache’s mit Debian 8 plötzlich wieder gegen diese Art Angriffe verletzlich. Mit der Voreinstellung von mods-enabled/reqtimeout.conf in Debian 8 werden die gefälschten Verbindungen erst nach 40 Sekunden gekappt, wodurch der Zielserver mit einer Slowloris Attacke problemlos für je 40 Sekunden vom Netz „getrennt“ werden kann.

Es muss also eine Notlösung mit iptables her, denn in meinem Fall reicht es nicht aus bei Apache 2.4 im automatisch aktivierten mod_reqtimeout die Gürtel enger zu schnallen. Zumindest konnte ich meinen eigenen Apache mit den im Netz gefundenen Slowloris Perlscripts komplett über den Haufen schiessen. Eine mögliche Übergangslösung wäre beispielsweise mittels iptables die Anzahl  Verbindungen gegen Port 80/443 pauschal einzuschränken:

iptables -A INPUT -p tcp --syn --dport 80 -m connlimit --connlimit-above 100 -j DROP
iptables -A INPUT -p tcp --syn --dport 443 -m connlimit --connlimit-above 100 -j DROP

Damit blockiert iptables zuviele Verbindungen auf Port 80 und 443, worauf der Angriff Slowloris basiert.

Mod_qos wird hauptsächlich von der Schweizer Firma AdNovum (NevisProxy) geschrieben, es ist mir schleierhaft wieso AdNovum ihre weltweit beliebte Mod nicht längst für Apache 2.4 optimiert hat!?

PHP 5.6: Mag keine Self Signed Zertifikate bei Roundcube Webmail

In meinem Fall wollte mein Roundcube Webmail nicht mehr funktionieren, weil ich dort ein selbst signiertes Zertifikat für SSL einsetze. PHP 5.6 prüft – anders als noch PHP 5.4 – gewisse Parameter und blockiert unter Umständen den Zugriff. Glücklicherweise gibt es für Roundcube seit Juni eine neue Version, welche selbst einen Fix liefert. Ich mag mich gut erinnern, wie ich die Config config.inc.php von der .sample abkopieren & neu befüllen musste, die alte Konfigurationsdatei hattew wegen existenziellen Änderungen nicht mehr funktioniert.

Debian Jessie 8 ist ein Zwitter. SysVinit darf nicht gelöscht werden.

Ich war natürlich auch heiß auf die Änderungen welche mit Systemd Einzug halten. Ganz besonders spannend fand ich das Entdecken der neuen «Init-Scripte», die systemd Startscripts. Doch schnell stellte sich Ernüchterung ein, denn Debian 8 wechselt überhaupt nicht alles auf Systemd.

Der Init Prozess läuft zwar mit Systemd aber viele Startskripte sind immer noch SysVinit, darunter einige sehr wichtige wie z.B. das von Apache2. Im ersten Moment fand ich das schade, weil das Gefühl aufkommt man habe hier keine Nägel mit Köpfen gemacht. Aber Debian muss diesen Mittelweg gehen und ich kann das durchaus verstehen. Was sonst soll das Debian Projekt machen, um nicht die ganze Community zu vergraulen? Ein Zwitter, was Debian 8 unweigerlich ist, schien die beste Lösung.

Aus diesem Grund ist es m.E. überhaupt nicht möglich, SysVinit aus Debian 8 zu verbannen. Debian 8 lebt von den Paketen systemd und systemd-sysv, und wenn das Zwitter-Paket systemd-sysv gelöscht werden möchte, entfernt Debian das neue Systemd komplett, ersetzt durch das Paket sysvinit-core.

Letztlich bleibt dem gewieften Admin die Frage, ob ein Upgrade auf Debian 8 schon heute sinnvoll ist. Ich behaupte nein – solange die Pakete aus Debian 7 für den täglichen Bedarf ausreichend sind.

Könnte ich die Zeit zurückdrehen, würde ich meinen Server erst kurz vor Ablauf der einjährigen Supportzeit migrieren, also zwischen Januar und April 2016.

Tipp zum Schluss: Apt kann jetzt auch ohne -get

Anleitungen für den Umgang mit dem neuen systemd systemctl restart <service> oder journalctl findet man im Internet zu hauf. Was mich an Debian 8 Jessie hoch erfreut liegt im Detail: Apt kann jetzt ohne -get. Was früher

apt-get update
apt-get upgrade
apt-get remove

war, kann heute

apt update
apt upgrade
apt remove

genauso. Steht in den aufgepeppten Manpages von Apt (man apt).

Nur wer Freude an kleinen Vereinfachungen hat, bleibt gesund und glücklich 😀