Von Jessie zu Stretch - erneut
Ja, ich bin spät dran - bereits Mitte letzten Jahres wurde Debian 10 Buster veröffentlicht, aber die meisten meiner Server liefen noch unter Debian 8 Jessie, mit Ausnahme des neuesten Zugangs, der bereits unter Stretch installiert wurde, und meines heimischen Servers, den ich bereits vor zweieinhalb Jahren (!) geupdatet hatte (dass das so lange her ist und die anderen Updates schon so lange auf meiner Todo-Liste stehen, war mir gar nicht mehr bewusst).
Ich hatte mir im Prinzip für jede Maschine einen (halben) Tag reserviert, aber der Aufwand hielt sich in erstaunlichen, sehr angenehmen Grenzen. Meine Hinweise, die ich bereits vor zweieinhalb Jahren im Blog notiert hatte, kann ich demnach recht kurz ergänzen.
Konkrete Einzelfallprobleme
Wie schon damals geschildert gab es Probleme beim Upgrade von fail2ban, weil sich die Bezeichnungen einiger Filter geändert haben, die noch unter der alten Bezeichnung in
/etc/fail2ban/jail.local
eingebunden waren. Dadurch endete dasdist-upgrade
später mit einem Fehlercode und musste neu gestartet werden, um die restlichen Pakete zu initialisieren. Nach dem ersten Durchlauf habe ich das dadurch behoben, dass ich schon vor dem Upgrade statt des Filtersssh
den Filtersshd
und stattapache
denapache-auth
eingebunden habe.Auch das Upgrade von phpMyAdmin verlief nicht störungsfrei; das Update der Datenbanken lief in einen Fehler (die Datenbankdateien seien korrumpiert) und ein entsprechendes debconf-Prompt. Es stellte sich heraus, dass ein Aufruf von
/usr/bin/mysql_upgrade
notwendig war, den ich dann in einem anderen Terminal vorgenommen habe; danach lief das Upgrade durch. Bei den anderen Servern habe ich dann schon beim ersten Prompt wegen des Updates der phpMyAdmin-Datenbanken in einem anderen Terminal/usr/bin/mysql_upgrade
gestartet; das Upgrade lief dann problemlos.In manchen Fällen wurde der mySQL-Server nach dem Upgrade nicht richtig neu gestartet. Ein
service mysql restart
behebt das, wenn man nicht ohnehin zeitnah rebootet.
Solche Probleme sind bei Debian-Updates ungewöhnlich, waren aber gut managebar; dafür lief an der Configfile-Front alles sehr schön, es waren diesmal kaum Änderungen vorzunehmen.
Änderungen an Konfigurationsdateien
Bei mir bekamen u.a. folgende Konfigurationsdateien größere und kleinere Änderungen mit, die ich dann mit eigenen Änderungen zu konsolidieren hatte (was aber wegen des geringen Umfangs sehr einfach und flott ging):
/etc/apache2/mods-available/userdir.conf
/etc/dhcp/dhclient.conf
/etc/munin/plugin-conf.d/munin-node
/etc/news/inn.conf
/etc/news/innfeed.conf
/etc/vim/vimrc
/etc/phpmyadmin/apache.conf
/etc/ssh/sshd_config
Das ist natürlich eine sehr spezifische Aufzählung, hängt sie doch von der installierten Software und von vorgenommenen Änderungen an deren Konfiguration ab. Sie ist aber m.E. erfreulich übersichtlich; so wenig Nacharbeit hatte ich selten.
Änderungen für bestimmte Softwarepakete
Der Account news bekam
/usr/sbin/nologin
als Shell verpasst; das mag ich nicht, ich arbeite damit häufiger und setze die Shell daher auf die Bash. Das ist im Hinblick auf externe Logins kein Problem, weil ich die passwortbasierte Anmeldung per SSH deaktiviert habe und der User news keineauthorized_keys
hat.duply und duplicity benötigen, wie schon damals geschildert,
GPG_OPTS='--pinentry-mode loopback'
. Wer - wie ich - damit in die Amazon-Cloud (S3) sichert, muss zudem ggf.TARGET_USER
in der Konfiguration durchexport AWS_ACCESS_KEY_ID
undTARGET_PASS
durchexport AWS_SECRET_ACCESS_KEY
ersetzen.Ggf. braucht phpMyAdmin ein längeres
blowfish_secret
als früher, das man in/var/lib/phpmyadmin/blowfish_secret.inc.php
setzen kann.Wie immer möchte debsecan per
dpkg-reconfigure debsecan
das aktuell installierte Release beigebogen bekommen.
Neue Software und geänderte Defaults
vim hat diese furchtbare Maussteuerung bekommen, die man - wie schon beschrieben - aufgrund der Reihenfolge, in der die Konfigurationsdateien geladen werden, nicht so einfach deaktivieren kann, wie man das denken sollte. Entweder braucht jeder Nutzer (!) eine (leere)
~/.vimrc
, oder man klemmt das Laden derdefaults.vim
in/etc/vim/vimrc
in der dort beschriebenen Weise ab. Ich tat letzteres.Der INN setzt jetzt statt NNTP-Posting-Host, NNTP-Posting-Date und X-Trace die Header Injection-Info und ggf. auch Injection-Date; ich habe die damit verbundenen Änderungen bereits 2017 beschrieben.
Wer seinen INN von einer anderen Maschine aus bspw. per nntpsend füttert, muss darauf achten, dass die Gegenstelle (also quasi der Client) in der
passwd.nntp
nunmehr zwingend einen Usernamen gesetzt haben muss, auch wenn der gar nicht ausgewertet wird; dies entspricht der Doku. Ausnews.szaf.org::SECRETPASS
muss alsonews.szaf.org:blafasel:SECRETPASS
werden, sonst kann der “Client” sich nicht mehr anmelden,Mit Debian Stretch kommt PHP7; ich habe daher auch direkt komplett von PHP5 auf PHP7 umgestellt.
Umstellung von PHP 5 auf PHP 7
In meiner Konfiguration waren dafür folgende Änderungen erforderlich:
apt install php7.0-fpm
cp /etc/apache2/conf-available/php5-fpm.conf /etc/apache2/conf-available/php7.0-fpm.conf
vim /etc/apache2/conf-available/php7.0-fpm.conf
Dort wird dann die Zeile
<Proxy "unix:/var/run/php5-fpm.sock|fcgi://php-fpm">
geändert auf
<Proxy "unix:/run/php/php7.0-fpm.sock|fcgi://php-fpm">
Weiter geht es mit
a2disconf php5-fpm
a2enconf php7.0-fpm
service apache2 reload
Ggf. sind auch benutzerbezogene Konfigurationen anzupassen.
Schließlich kann man PHP5 abräumen, bspw. mit
apt remove php5-fpm php5 php5-gd php5-mysql php5-mcrypt php5-imagick php5-curl; apt autoremove
Das hängt natürlich davon ab, was man so alles installiert hatte.
Und dann kommt ggf. der größte Aufwand: alte PHP-Scripts so anzupassen, dass sie mit PHP7 laufen …
Zusammenfassung
Echte Arbeit ist ggf. die Umstellung vorhandener PHP-Scripts von PHP5 auf PHP7 (die man aber nicht zwingend zusammen mit dem Upgrade durchziehen muss); ansonsten ist der Aufwand sehr überschaubar. Es gibt m.E. einen echten Fehler (das Upgrade von phpMyAdmin und einen vermutlich häufigeren Stolperstein (die geänderten Filterbezeichnungen von fail2ban); alle übrigen Anpassungen sind konfigurationsspezifisch. Die Änderungen an Conffiles fielen diesmal angenehm überschaubar aus.
Alles in allem ein überschaubarer Aufwand, insbesondere, wenn man beim zweiten Durchgang (und allen weiteren) den Großteil der Fallstricke bereits kennt.
Kommentare
Ansicht der Kommentare: Linear | Verschachtelt
Sven Hartge am :
Kleine Verbesserung für die FPM-Konfiguration, die es aus irgendwelchen Gründen bis heute nicht nach Debian geschafft hat:
Die Neuerung ist die <If>-Klausel, welche dafür sorgt, dass nur für wirklich existierende Dateien die Übergabe an php-fpm erfolgt. Das reduziert die Last deutlich, wenn irgendwelchen Spielkinder mal wieder den kompletten Server inkl. aller theoretischen Unterverzeichnisse das PHP-Shells oder verwundbarem Anderen abgrasen.
Apache ist natürlich so schlau, dass in
%{REQUEST_FILENAME}
der Dateipfad nach allen Redirects, Rewrites und Veraliasungen steht, so dass die Sache natürlich auch bei extremen SEO-Rewrite-Rules wie bei S9Y oder Wordpress korrekt funktioniert.mitch am :
Man ganz doof gefragt: Ist das auch für normales libapache2-mod-php sinnvoll oder bricht das sowieso passend ab, wenn keine Datei gefunden wird? Da kann ja kein Interpreter gestartet werden.
Ab wann lohnt sich FPM? Schon beim kleinsten Wald- und Wiesen-Blog ohne Traffic? Ich glaube, dass ich FPM vor Jahren mal in Betrieb hatte (oder war es suexec? böhmische Dörfer; auf jeden fall habe ich eine Zeit lang das php-Binary selbstkompiliert), dann irgendwann aus irgendwelchen Gründen nicht mehr und heute ist es immer noch aus
Thomas Hochstein am :
Ich will bzw. brauche eine Lösung, um PHP-Scripts unter der Kennung des Nutzers ausführen zu können (also quasi suexec für PHP), und war da nicht was mit dem PHP-Modul, dass es nicht threadsafe war und daher mit den meisten Apache-MPM nicht kompatibel? Wenn ich mich recht entsinne - es ist schon wieder so lange her - ließ man zur Rechtetrennung früher die CLI-Version ausführen, nutzte jedenfalls suphp (ich glaube, das machte genau das). Hatte ich nicht … ah, doch, ja: Die Welt dynamischer Webseiten
Gegenüber der alten Lösung hat FPM viele Vorteile: die PHP-Prozesse müssen nicht für jeden Seitenaufruf mit allem Overhead gestartet werden, sondern laufen im Hintergrund und führen die Scripts aus, die ihnen zugewiesen werden, wobei sich steuern lässt, wie viele Prozesse auf jeden Fall laufen, wie schnell neue gestartet und beendet werden und wo das Limit sitzt; außerdem lässt sich das Nutzer- bzw. Pool-spezifisch konfigurieren. Ich finde das sehr praktisch.
mitch am :
Das klingt tatsächlich ähnlich wie bei mir – dummerweise habe ich nicht drüber gebloggt. Ich werde basteln, danke
Sven Hartge am :
Die Frage, ob sich PHP-FPM lohnt, stellt sich spätestens dann nicht mehr, wenn man mit Apache HTTP/2 unterstützen will, denn dafür braucht man
mod_event
odermod_worker
, eine Thread-basiertes Worker-Modul.libapache2-php
ist aber nicht thread-safe, funktioniert daher mit diesem beiden Workern nicht mehr.Daher wird man dann gezwungen, in jedem Fall PHP-FPM einzusetzen.
mitch am :
Urks, das nächste Rattenloch Ich habe zwar mal von HTTP/2 gehört, aber das im Reiche der unfertigen Fabel verortet. Habe mich gerade aufgeschlaut …
Danke für den Hinweis, da muss ich mal ran!
Was habe ich denn die letzten Jahre unter meinem Stein denn noch alles verpasst?
mitch am :
(Wenn diese Antwort nicht unterhalb einer meiner anderen Antworten erscheint, sondern irgendwo anders, dann resettet der Button Vorschau mehr oder weniger heimlich die Einstellung Antwort auf.)
mitch am :
Ah: Nach Vorschau wird Antwort auf nur nicht mehr angezeigt, es ist trotzdem noch gültig.
Ich würde die beiden Kommentare wieder löschen, aber ich darf nicht
Thomas Hochstein am :
Ich könnte, aber ich lasse sie mal da - schadet ja nicht.
(Nach der Vorschau sieht man ja bereits, wo der Kommentar erscheint, also ist "Antwort auf" eigentlich nicht mehr nötig. Es sei denn, man wollte das ändern. - Wobei, das geht, indem man auf den passenden "Antwort"-Link klickt. Scheint alles so halbwegs logisch. Irgendwie.)
mitch am :
Leider nicht, der Vorschau-Kommentar taucht (wie hier jetzt z.B.) immer ganz unten über dem Eingabefeld auf statt mitten im Thread. Darum kam ich überhaupt drauf
Sven Hartge am :
Nun, HTTP/3 aka QUIC im Grossen wird eigentlich produktiv nur von Google eingesetzt und die haben es schliesslich erfunden und über den Draft-Zustand ist die Sache bis dato auch noch nicht hinaus gekommen.
HTTP/2 dagegen ist jedoch schon lange Standard und gerade bei korrekter Konfiguration (was z.B. den Push-Content angeht) eine deutliche Beschleunigung für Webseiten.
Sven Hartge am :
Und wo wir schon dabei sind:
phpmyadmin
ist aus Buster geflogen und erst seit kurzem viabuster-backports
verfügbar.Thomas Hochstein am :
Hey, Du bist zu früh dran! Das ist der Stretch-Beitrag, der Buster-Beitrag kommt erst nächste Woche!
gregoa am :
"Anfang des Jahres" ist eine schoene neue bezeichnung fuer juli 2019, auch wenn sie im ersten moment etwas ungewoehnlich klingt
Thomas Hochstein am :
Oh, richtig, ich hatte zunächst fälschlich das Datum des letzten Point-Release genommen und das dann an dieser Stelle nicht mehr korrigiert …
Hab’s behoben.