Skip to content

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 das dist-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 Filters ssh den Filter sshd und statt apache den apache-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 keine authorized_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 durch export AWS_ACCESS_KEY_ID und TARGET_PASS durch export 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 der defaults.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. Aus news.szaf.org::SECRETPASS muss also news.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. :-)

Trackbacks

Netz - Rettung - Recht am : Von Debian Stretch zu Buster

Vorschau anzeigen
Hatte ich demletzt noch von diversen Updates von Debian Oldoldstable auf Debian OLdstable berichtet, habe ich nunmehr meinen Hauptserver auf das aktuelle Debian 10 Buster geupdatet. Das lief weitgehend problemlos; der dennoch entstandene Aufwand hatt

Mitch’s Manga Blog am : Update auf HTTP/2

Vorschau anzeigen
In dieser Kommentarspalte habe ich gelernt, dass HTTP/2 schon seit diversen Jahren ein Ding ist und ich da mal mit der Zeit gehen könnte. Kurzentschlossen und weitgehend problemlos habe ich daraufhin meinen Webserver (Apache) auf HTTP/2 umgestellt.

Kommentare

Ansicht der Kommentare: Linear | Verschachtelt

Sven Hartge am :

Sven Hartge

Kleine Verbesserung für die FPM-Konfiguration, die es aus irgendwelchen Gründen bis heute nicht nach Debian geschafft hat:

CODE:
    <FilesMatch ".+.ph(p[3457]?|t|tml)$">         <If "-f %{REQUEST_FILENAME}">             SetHandler "proxy:unix:/run/php/php7.0-fpm.sock|fcgi://localhost"         </If>     </FilesMatch>

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 :

mitch

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 :

Thomas Hochstein

Ab wann lohnt sich FPM? Schon beim kleinsten Wald- und Wiesen-Blog ohne Traffic?

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 :

mitch

Das klingt tatsächlich ähnlich wie bei mir – dummerweise habe ich nicht drüber gebloggt. Ich werde basteln, danke :-)

Sven Hartge am :

Sven Hartge

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 oder mod_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 :

mitch

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?

  • Let’s Encrypt habe ich am Laufen
  • HTTP/3 bedingt aktuell noch einen Wechsel des Webservers, das ist mir zu wild

mitch am :

mitch

(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 :

mitch

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 :

Thomas Hochstein

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 :

mitch

Nach der Vorschau sieht man ja bereits, wo der Kommentar erscheint

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 :

Sven Hartge

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 :

Sven Hartge

Und wo wir schon dabei sind:phpmyadmin ist aus Buster geflogen und erst seit kurzem via buster-backports verfügbar.

Thomas Hochstein am :

Thomas Hochstein

Hey, Du bist zu früh dran! Das ist der Stretch-Beitrag, der Buster-Beitrag kommt erst nächste Woche! :-)

gregoa am :

gregoa

"Anfang des Jahres" ist eine schoene neue bezeichnung fuer juli 2019, auch wenn sie im ersten moment etwas ungewoehnlich klingt :-)

Thomas Hochstein am :

Thomas Hochstein

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.

Kommentar schreiben

HTML-Tags werden in ihre Entities umgewandelt.
Markdown-Formatierung erlaubt
Standard-Text Smilies wie :-) und ;-) werden zu Bildern konvertiert.
BBCode-Formatierung erlaubt
Gravatar, Identicon/Ycon Autoren-Bilder werden unterstützt.
Formular-Optionen
tweetbackcheck