Du sitzt gerade verzweifelt vor deinem Server, weil er nach einen upgrade auf Ubuntu 16.04.LTS nicht mehr funktioniert? Dann lies dieses Märchen. Kopf hoch! Wie in den meisten Märchen stirbt das Böse und das Gute gewinnt. Das dafür manchmal 2 Tage notwendig sind, in denen Admina um ihren Server zittert, sagt uns Hollywood natürlich nicht. Also: Es war einmal ein Server. Dieser lief seit Jahren mit Ubuntu 14.04 LTS absolut super, durchlief laue Sommernächte und wilde Winterabende mit Glühwein… Naja, ich will jetzt nicht übertreiben, aber so oder so ähnlich könnte das Märchen beginnen. Die Realität ist härter.

Ziel war es, auf einen Ubuntu 14.04 LTS Server ein upgrade auf Ubuntu 16.04 LTS durchzuführen. Diese Aktualisierung wird auch bei jeder Anmeldung am Server mit einen do-release-upgrade beworben. Also schaute ich mir die release notes von Xenial Xerus an – der märchenhafte Namen von 16.04. Und da fand ich nichts, was mich wirklich von einen upgrade abhielt. Hätten dort so böse Hexen gestanden wie systemd, PHP7 oder MariaDB version 10 und Torwächter gespielt, hätte ich es (wahrscheinlich) nicht gemacht. Aber bisschen Kernel, bisschen Python…. und PHP7 hatte ich überlesen. Ich war magisch angezogen und der Held kennt kein zurück. Eben Hollywood.

Mein Server steht bei Hetzner – übrigens ein Serveranbieter, den ich nur empfehlen kann! Und dort bekam ich auch die Info, dass ich meine apt/source.list auf die 16.04 Hetzner Quellen anpassen kann. Nachdem ich nochmal ein aptitude update/upgrade in meiner alten Installation ausgeführt, mit autoclean/autoremove die bestehende Paketverwaltung bereinigt und mir noch eine Kanne Kaffee bereitgestellt hatte, gab ich ein herzhaftes do-release-upgrade auf der Konsole ein und wartete.

Als ersten Schritt fragte mich das upgrade script, ob ich die Dienste selbst neu starten wolle. Ziel meiner Vorgehensweise war es, die größtmögliche Kontrolle im upgrade Prozess zu übernehmen. Immerhin sollten meine angepassten Konfigurationen nicht einfach im Nimmermehrland enden. Also schaute ich mir brav jeden Diff der configs an (wird mit [d] angeboten), wenn mir Ubuntu dieses anbot – entsprechend übernahm oder verneinte ich und machte mir Notizen (so richtig mit Stift auf Papier!) welche Dienste ich nach dem upgrade – vor(!) dem Neustart – nochmal anschauen musste. Also um im Märchen zu bleiben: weniger Shrek, mehr Robin Hood.

Irgendwann bot mir die Ubuntu Fee den Neustart an. Ich überlegte nochmal, ob alles saß. Ich hatte schon einmal Weihnachtsfeiertage in einen Büro verbracht, weil ich dummerweise einen Server crashte (führe niemals ein rm -rf / aus! Auch nicht zufällig oder gut gemeint!). Kennt Ihr das Gefühl, wenn es einen heiß den Rücken runter läuft?? Genauso sitzt Admina dann vor dem Monitor… Im jetzigen 16.04er upgrade war ich mir aber sehr sicher, dass der Server wieder hochkommt und machte den Neustart. Das der Neustart einige Minuten nach einem upgrade dauern kann, war mir schon klar. Dumm nur, wenn Admina den SSH port nicht mehr erreicht und die Webseite wegbleibt! Die böse upgrade Hexe hatte zugeschlagen!

Erstmal auf den Server kommen

Was tun, sprach Zeus! Erst einmal: Kaffee! Wichtig ist in diesen Moment, herauszubekommen, wo steht der Server! Natürlich im Rechenzentrum – aber ich meine natürlich die Dienste. Wo bleibt der Server beim hochfahren hängen? Eine Kernelpanic habe ich seit Jahren mit verschiedenen Linuxen nicht mehr gesehen, dies schloss ich aus. Also Dienste!

Ein portscan mit nmap auf meinen Server und siehe da, einige Dienste waren sehr wohl gestartet! Leider nicht der SSH. Hetzner bietet für solche Fälle einen gut durchdachten Rescue Modus an: Es wird ein Rescue System zur Aktvierung angeboten, dass sich der Server nach einen Neustart zieht. Ein Strg+Alt+Entf oder Server aus/an bietet Hetzner ebenfalls an. Damit bekommt Admina einen SSH Zugang mit Passwort auf den Standardport für das Rescue System. Jetzt noch das /dev/md (quasi die Partition) mit dem installierten System an einen Ordner mounten, chroot-prepare ausführen und schon kann Admina in der bestehenden Installation rumfuhrwerken. Also habe ich erst einmal die Firewall deaktiviert. Ich nahm an, dass ich beim upgrade unabsichtlich die sshd_config (mit dem Standardport 22) aktualisiert hatte, obwohl die Firewall diesen port nicht zulässt. Und nach einen Neustart hatte ich wieder Zugang per SSH auf meinen Server ohne Rescue Modus. Puuhh…

Nochmal kurz: Das nach einen upgrade irgendwas nicht geht, ist erst einmal per se nicht dramatisch – eher muss Admina das (zeitlich) einplanen. Die Frage ist: Wie bekomme ich ein System, in dem ich administrieren kann? Wenn erst einmal die Anmeldung per SSH funktioniert ist der Rest Kosmetik. Tja, Hexe, war wohl nichts.

upstart gegen systemd

Jetzt begann die Fleißarbeit – alle Dienste zum Laufen bringen. Wenn aber viele Dienste nach einer solchen Aktion nicht funktionieren, kann Admina von einen zentralen Fehler ausgehen. Wenn also ein service postfix start mit der Meldung, dass einige Startscripte nicht funktionieren, nicht startet und andere Dienste die selbe Meldung loggen, kommt Admina nicht um das Thema systemd/upstart herum! Auftritt: Hexe!

Mein Ubuntu 14.04 (vormals 12.04 oder so) startete die Server Dienste (postfix, dovecot, apache2) mit upstart/SysVinit. Das upgrade auf 16.04 zaubert einen neuen Mechanismus hinein: systemd/SysVinit. Und das scheinbar nur mangelhaft. Quasi ein Hexenschüler. Bleib ernst! Und so schaut man nach, welcher Mechanismus gerade die Hoheit über die Diensteverwaltung hat:

ps -p1 | grep systemd && echo systemd || echo upstart

Welcher Dienst dich dann gerade sticht – sagt dir gleich das Licht. Bei mir war es eben systemd. Damit verstärkte sich mein Eindruck, dass die neue Diensteverwaltung systemd die installierten Dienste nicht korrekt eingebunden hatte. Also zurück auf upstart. Das war auch relativ simpel: Installiere das Paket upstart-sysv und damit wird die De-Installation von systemd-sysv und ubuntu-standard angeboten und ist zu bestätigen. Nach einen Neustart des Servers hatte ich wieder einige Dienste mehr zur Verfügung.

Tja Hexe, kommt noch was? Aber um es nochmal klar zu machen: Damit hat Admina zwar wieder eine weitestgehend lauffähige Server- Installation, aber auch keine standardmäßige 16.04 LTS Installation! So sind die Server Dienste dann aktuell (Postfix hat die 3er Version, PHP die 7er, Apache 2.4.18) aber wir haben kein systemd, dass wohl in zukünftigen Ubuntu Systemen gefragt ist. Ein downgrade auf 14.04 ist keine Option!

1:0 für die Hexen. Ein halber Sieg, eine kleine Niederlage. Wie dem auch sei: Mir sind die aktuellen Serverdienste wichtiger, als eine neue ausgeklügelte Diensteverwaltung. Normalerweise wird ein Server hochgefahren und läuft dann Jahre durch – ein schnelleres oder flexibleres Starten der Dienste durch systemd bringt mir in dieser(!) Hinsicht keinen Mehrwert. Damit kann ich mit diesen Zwitter- Zustand – neue Dienste und bisherige Diensteverwaltung – leben und arbeiten. Also weiter: Was musste noch nachgebessert werden?

upstart: update-rc.d bügelt alles

Jetzt kamen die Dienste an die Reihe, die sich dem Zauber der systemd scripte weitergehend ergeben hatten. Meine Vorgehensweise war gnadenlos: In der Annahme, dass erst einmal alles weg muss um Platz für das Neue zu schaffen, ballerte ich die Startscripte des jeweiligen Serverdienst (Postfix, Dovecot,…) mit einen

update-rc.d <Serverdienst> remove

erst einmal aus dem Weg und setzte mit einen

update-rc.d <Serverdienst> defaults

die Startscripte auf SysVinit/upstart Basis wieder neu ein. Mehr dazu hier. Damit waren alle restlichen Serverdienste nach einen Neustart wieder zum Dienst angetreten, sprich: verfügbar. Generell würde ich in einer solchen Situation immer erst alle unnötigen Dienste deaktivieren und dann wieder scheibchenweise dazu schalten. Ich denke, dass wir in so einer Situation “Nichts geht mehr!” schneller und effektiver vorankommen, wenn wir scheibchenweise vorgehen. Die Hexe wird erst ihren Zauberstab retten und dann das Schloß. Naja, krankt etwas, aber Du weißt, was ich meine. Und so hatte ich einen spannenden Tag mit Kaffee am Computer verbracht. Wenn nicht noch die kleinen Nervgeister dabei gewesen wären….

Wir lernen PHP7

WordPress ging nicht mehr! Beachte: Plötzlich ist PHP7 im System verfügbar und das php5 Modul für den Apache2 will nicht mehr – Also raus mit php5 und rein mit php7: Ein a2dismod php5 und ein a2enmod php7 auf der Konsole klären das. Weitere Infos zur Apache2 Modul- Verwaltung sind hier. Vergiss danach nicht service apache2 restart. Für WordPress hatte ich noch libapache2-mod-php7.0 für den Datenbankzugriff nachinstalliert. Horde Installateure beachten diese Meldung.

Überhaupt habe ich dann einige Zeit mit dem Loswerden von php5 verbracht. So konnte ich das Paket php5-common ohne Einschränkungen entfernen. Ein dpkg -l | grep php zeigt Dir, welche PHP Pakete dein System kennt. Pakete die nur php- im Namen haben, sollen nach den Ubuntu Regularien auf die Version 7 zeigen. Die PHP Pakete der verschiedenen Versionen sind nicht 1:1 aufzufinden. So haben einige PHP7 Module keine entsprechende Namensgebung oder sind in einen Modul zusammengefasst. Alles die Reste vom Hexennebel.

Studieren: Postfix, rsyslogd und fail2ban

Eine Kompatibilitätsprüfung ist für Postfix 3.0 eingeführt worden. Diese zeigt im Log eine entsprechende Anweisung an. Wenn diese befolgt wird, funktioniert Postfix weiterhin wie gewohnt. Natürlich darf Admina nicht die master.cf und die main.cf durch das upgrade überschreiben lassen! Schnell mal upgrade ist nicht. Ebenso bei Dovecot den Diff beim upgrade studieren, sonst hat dovecot ganz schnell keine Datenbankanbindung mehr. Die Email – Hexe würde sich freuen. Auch fail2ban hat einige umfassende Änderungen an der Konfiguration nach dem upgrade in der neuen Version erfahren. Dafür sollte Admina sich auf jeden Fall Zeit geben, da einige Anpassungen (bei bestehender Eigen- Konfiguration) notwendig sind!

Ein Neustart zeigt Dir, wie weit deine Umstellung erfolgreich war. Studiere unter /var/log alle Logfiles schnell mal mit less, ob noch war schief liegt. Mit einen ps -ax auf der Konsole siehst Du, welche Dienste gestartet sind oder eben nicht! Und ein netstat -tulpen listet auf, welche ports dein System anbietet. Aber wie in jeden guten Märchen, schlägt in der letzten Minute der Tod-Geglaubte nochmal zu… In unseren Falle der rsyslogd. Wenn wir unter 14.04 keine Meldungen im log zum Thema hatten – jetzt haben wir sie. Wenn nicht: Nicht bewegen. Ich fasse das einfach mal zusammen.

Wenn eine dieser Meldungen im syslog steht …

Nov  7 11:57:44 svr01 rsyslogd-2222: command ‘KLogPermitNonKernelFacility’ is currently not permitted – did you already set it via a RainerScript command (v6+ config)? [v8.16.0 try http://www.rsyslog.com/e/2222

Nov  7 11:57:44 svr01 rsyslogd-2039: Could not open output pipe ‘/dev/xconsole’:: No such file or directory [v8.16.0 try http://www.rsyslog.com/e/2039 ]

Nov  7 11:57:44 svr01 rsyslogd-2007: action ‘action 10’ suspended, next retry is Mon Nov  7 11:58:14 2016 [v8.16.0 try http://www.rsyslog.com/e/2007 ]

… dann versuche es mit diesen Lösungen:

vi /etc/rsyslog.d/50-default.conf

#daemon.*;mail.*;
#       news.err;
#       *.=debug;*.=info;
#       *.=notice;*.=warn       |/dev/xconsole

vi /etc/rsyslog.conf

# Enable non-kernel facility klog messages
#$KLogPermitNonKernelFacility on

vi /etc/logrotate.d/rsyslog

        postrotate
                service rsyslog rotate >/dev/null 2>&1 || true
#               invoke-rc.d rsyslog rotate > /dev/null
        endscript

(Quelle: u.a. nonkernel postrotate daemon )

Kurze Erläuterungen zu den Lösungen: Funktion ist in einen Standardsystem nicht konfiguriert (xconsole), wird nicht mehr unterstützt (non-kernel) und ist nur funktional mit systemd (postrotate) – das wir ja hier nicht mehr haben. Eine erfolgreiche Optimierung sieht Admina anhand einer Meldung nach einen service rsyslog rotate auf der Konsole und sieht so aus: Closing open files rsyslogd und natürlich daran, dass die gezeigten Meldungen nicht mehr im syslog erscheinen.

Fazit

Ich bin so ein “Nochmal-kurz-Typ”: Plane Zeit ein! Überlege vorher, welche Möglichkeiten Du hast (rescue)! Was ist dein Mehrwert aus dieser Aktion? Ehrlich gesagt: Ich glaube mittlerweile, dass es sinnvoller ist, die 5 Jahre der LTS Versionen voll auszuschöpfen und dann eine Neu- Installation, als sich mittendrin so ein Mischsystem einzuhandeln.

Allerdings sind das auch Momente, in denen Du sehr viel lernen kannst: Wenn es nur das ist, wie es nicht geht! Und so verziehen sich die Fehler- Hexen in den Herbst Nebel und erscheinen uns nur noch als die Schatten eines Märchens, wenn wir es uns erzählen.

Have fun…

---