Netz - Rettung - Recht (Artikel mit Tag stretch)

Von Jessie zu Stretch - erneut

nospam@example.com (Thomas Hochstein) — Tue, 12 May 2020 06:10:00 +0000

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.

Der Injection-Date:-Header

nospam@example.com (Thomas Hochstein) — Fri, 06 Oct 2017 06:05:00 +0000

Das Usenet ist zunehmend in die Bedeutungslosigkeit zurückgefallen - ironischerweise sind die zugrundeliegenden Formate und Protokolle heutzutage aber klarer spezifiziert als das zu seinen Hochzeiten der Fall war. NNTP, das Übermittlungsprotokoll mit der größten Verbreitung, war recht gut definiert, erst in RFC 977 von 1986 und dann zwanzig Jahre später in RFC 3977; außerdem kann man den INN wohl als eine Referenzimplementation betrachten.

Mit dem Nachrichtenformat war es da schon schwieriger: Auf RFC 850 von 1983 folgte RFC 1036 von 1987, der während der Blütezeit des Usenets niemals aktualisiert wurde, obschon es bereits 1993 einen Entwurf für einen Nachfolger gab, den sog. “Son-of-1036” (der erst 2010 als historisches Dokument in Form von RFC 1849 veröffentlicht wurde). Der De-Facto-Standard war dann letztlich “Son-of-1036” mit weitgehend ungeschriebenen Modifikationen aus der Implementierungspraxis, während die USEFOR working group der IETF sich unendlich lange vergeblich mit der Erstellung einer Spezifikation abmühte. Als Ende 2009 dann endlich RFC 5536 “Netnews Article Format” veröffentlicht wurde (der zusammen mit RFC 5537 “Netnews Architecture and Protocols” ein umfassendes Kompendium zur Implementation von Newsservern, -readern und allen möglichen anderen Tools rund um das Usenet bzw. Netnews darstellt), waren die großen Zeiten des Usenets bereits Vergangenheit.

Implementation von RFC 5536

Es dauerte dementsprechend auch seine Zeit, bis die Theorie der RFCs allmählich in die Praxis einzusickern begann. Die ersten Neuerungen fanden sich schon in INN 2.5.0 (von 2009), aber neue Header wie Injection-Info oder Injection-Date wurden erst ab INN 2.5.3 (2012) tatsächlich beachtet und erst ab INN 2.6.0 (2015!) erzeugt.

Damit wurden dann die bisherigen, nie offiziell standardisierten Header NNTP-Posting-Host, NNTP-Posting-Date und X-Trace durch eine klarere Definition des Path-Headers und die neuen Header Injection-Info und Injection-Date ersetzt. Dabei ersetzt Injection-Date das NNTP-Posting-Date (also den Zeitstempel der Einspeisung ins Netz per POST), wohingegen im Header Injection-Info alle Daten über das einspeisende System enthalten sind; dieser Header ersetzt also neben NNTP-Posting-Host vor allem X-Trace.

Wer als Newsserver-Betreiber diese Tracking-Header zu Zwecken der Anonymisierung oder Pseudonymisierung seiner Nutzer bisher entfernt oder modifiziert hat, muss beim Update auf INN 2.6.0 (und damit beim Update auf Debian Stretch) entsprechend aufpassen und nacharbeiten. Dasselbe gilt auch für denjenigen, der Postings aus seinem INN heraus per suck erneut ins Netz einspeist: auch der Header Injection-Info muss vor dem Repost entfernt werden.

Injection-Date als Ersatz für NNTP-Posting-Date?

So weit, so gut - eines sollte man aber dabei nicht aus den Augen verlieren: Injection-Date ist nicht dasselbe wie NNTP-Posting-Date, obschon das eine der Ersatz des anderen sein soll (RFC 5536, 3.2.7):

This header field is intended to replace the currently used but
undocumented "NNTP-Posting-Date" header field, whose use is now
deprecated.

NNTP-Posting-Date wurde nämlich - wenn konfiguriert - immer gesetzt, um den Zeitpunkt der tatsächlichen Einspeisungs ins Netz anzugeben, der durchaus Stunden oder Tage nach der Erstellung des Artikels liegen kann. Injection-Date hat zwar denselben Zweck - um aber zu vermeiden, dass ansonsten identische Artikel mit verschiedenen Injection-Date-Headern verbreitet werden, darf Injection-Date nicht gesetzt werden, wenn der eingelieferte Artikel bereits sowohl einen Date:- als auch einen Message-ID:-Header hat:

                                     If the proto-article had
both a Message-ID header field and a Date header field, an
Injection-Date header field MUST NOT be added, since the proto-
article may have been multiply injected by a posting agent that
predates this standard.  Otherwise, the injecting agent MUST add
an Injection-Date header field containing the current date and
time.

Sinnigerweise findet man das nicht in RFC 5536, sondern in RFC 5537 (3.6, Ziffer 11). Der Hintergrund für diese Regelung ist etwas komplex: Die Verbreitung von Duplikaten bereits vorhandener Artikel wird verhindert, indem jeder Newsserver nur solche Artikel annimmt, deren Message-ID er noch nicht kennt. Um nun diese Liste bekannter Message-IDs (die sog. History) nicht ins Unendliche wachsen zu lassen, speichert jeder Newsserver die ihm bekannte Message-IDs nur für einen begrenzten Zeitraum (bspw. 14 Tage) und nimmt ältere Artikel schlicht nicht an. Für die Bestimmung des Alters eines Artikels soll aber auf den Injection-Date-Header abgestellt werden, nicht auf “Date”; schließlich mag ein Artikel vor seiner Einspeisung länger auf Halde gelegen haben. Wenn nun aber ein Artikel (mit Date und Message-ID) einmal heute und dann nochmals drei Wochen später eingespeist würde und beide Male ein aktuelles Injection-Date bekäme, dann würde ein Newsserver, der seine History nur 14 Tage hält, den zweiten Artikel annehmen (lt. Injection-Date ist er ja ganz frisch) und duplizieren (weil er nicht mehr weiß, dass derselbe Artikel vor drei Wochen schonmal vorbeikam).

Nun ist es alles andere als ungewöhnlich, dass ein einzuspeisender Artikel bereits über Date und Message-ID verfügt; das Datum wird ohnehin regelmäßig gesetzt, und die Message-ID setzten viele (die meisten?) Newsreader auch. Das bedeutet dann aber im Umkehrschluss, dass Injection-Date in sehr vielen Situationen eben kein Ersatz für NNTP-Posting-Date ist.

Mir fiel das auf, als ich mal wieder einen Stapel noch auf meinem Laptop herumliegender Artikel mit ungefähr einer Woche Verspätung gepostet hatte: nach dem Update meines lokalen Newsservers auf Debian Stretch war nicht mehr erkennbar, dass diese Postings verspätet eingespeist worden waren, weil es keinen Injection-Date-Header gab. Die Ursache dieses scheinbaren Fehlers musste ich mir dann erst von Russ Allbery persönlich erklären lassen …

X-NNTP-Posting-Date

Ich habe mir dann kurzerhand einen Ersatz geschaffen und setze nunmehr über den Perl-Filter (filter_nnrpd.pl) einen X-NNTP-Posting-Date-Header:

# Add X-NNTP-Posting-Date header
$hdr{'X-NNTP-Posting-Date'} = strftime("%a, %d %b %Y %H:%M:%S %z", localtime);

phpMyAdmin nur für einen vhost einbinden

nospam@example.com (Thomas Hochstein) — Fri, 08 Sep 2017 06:50:00 +0000

phpMyAdmin verwende ich seit über einem Jahrzehnt, um bequem auf die Datenbanken auf meinen verschiedenen Webspaces zugreifen zu können (und diesen Zugriff ggf. auch anderen Nutzern zu ermöglichen). Dabei nutze ich der Einfachheit halber das jeweilige Debian-Paket - je mehr Webapplikationen nicht gesondert aktualisiert werden müssen, desto besser.

Die Standardinstallation hat - aus meiner Sicht - allerdings einen Nachteil: sie macht phpMyAdmin für alle vhosts verfügbar, d.h. unter allen auf dem Server gehosteten “Domains” aufrufbar. Manchmal mag das praktisch sein, wenn man bspw. so für jeden Kunden scheinbar “sein” phpMyAdmin mitliefert; mir gefällt das aber nicht so gut, und sei es nur, weil phpMyAdmin (wie jede verbreitete Webapplikation) regelmäßig “angegriffen” wird (sprich: Bots rufen die URL auf und suchen nach Schwachstellen oder versuchen, das Passwort zu erraten). Lieber würde ich phpMyAdmin nur unter einer “Domain” - einem vhost aufrufbar machen.

Glücklicherweise lässt sich das ohne großen Aufwand machen.

Standardmäßig legt Debian (Stretch) bei der Installation des Pakets eine entsprechende Konfiguration unter /etc/apache2/conf-available/phpmyadmin.conf an und aktiviert sie durch einen Symlink in /etc/apache2/conf-enabled/. Diese Datei hat folgenden Inhalt:

# phpMyAdmin default Apache configuration

Alias /phpmyadmin /usr/share/phpmyadmin

<Directory /usr/share/phpmyadmin>
    Options SymLinksIfOwnerMatch
    DirectoryIndex index.php

    <IfModule mod_php5.c>
        <IfModule mod_mime.c>
            AddType application/x-httpd-php .php
        </IfModule>
        <FilesMatch ".+\.php$">
            SetHandler application/x-httpd-php
        </FilesMatch>

        php_value include_path .
        php_admin_value upload_tmp_dir /var/lib/phpmyadmin/tmp
        php_admin_value open_basedir /usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/:/usr/share/php/php-gettext/:/usr/share/php/php-php-gettext/:/usr/share/javascript/:/usr/share/php/tcpdf/:/usr/share/doc/phpmyadmin/:/usr/share/php/phpseclib/
        php_admin_value mbstring.func_overload 0
    </IfModule>
    <IfModule mod_php.c>
        <IfModule mod_mime.c>
            AddType application/x-httpd-php .php
        </IfModule>
        <FilesMatch ".+\.php$">
            SetHandler application/x-httpd-php
        </FilesMatch>

        php_value include_path .
        php_admin_value upload_tmp_dir /var/lib/phpmyadmin/tmp
        php_admin_value open_basedir /usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/:/usr/share/php/php-gettext/:/usr/share/php/php-gettext/:/usr/share/javascript/:/usr/share/php/tcpdf/:/usr/share/doc/phpmyadmin/:/usr/share/php/phpseclib/
        php_admin_value mbstring.func_overload 0
    </IfModule>

</Directory>

# Authorize for setup
<Directory /usr/share/phpmyadmin/setup>
    <IfModule mod_authz_core.c>
        <IfModule mod_authn_file.c>
            AuthType Basic
            AuthName "phpMyAdmin Setup"
            AuthUserFile /etc/phpmyadmin/htpasswd.setup
        </IfModule>
        Require valid-user
    </IfModule>
</Directory>

# Disallow web access to directories that don't need it
<Directory /usr/share/phpmyadmin/templates>
    Require all denied
</Directory>
<Directory /usr/share/phpmyadmin/libraries>
    Require all denied
</Directory>
<Directory /usr/share/phpmyadmin/setup/lib>
    Require all denied
</Directory>

Entscheidend ist dabei die Zeile Alias /phpmyadmin /usr/share/phpmyadmin - sie legt (global, da in der Serverkonfiguration eingebunden) für jeden vhost einen Alias an, der beim Aufruf von http://meine-domain.example/phpmyadmin/ nun eben phpMyAdmin anzeigt.

Will man diese Funktionalität auf einen vhost beschränken, genügt, es, die globale Konfiguration mit a2disconf phpmyadmin abzuschalten und sie danach stattdessen in einen vhost (oder auch mehrere) einzubinden:

<VirtualHost ${APACHE_IP4}:80 ${APACHE_IP6}:80>
    ServerName mein-vhost.example
    DocumentRoot /var/www/mein-vhost.example

    Include /etc/apache2/conf-available/phpmyadmin.conf
</VirtualHost>

Sinnvoll mag es zudem sein, die Konfiguration nur für einen vhost einzubinden, bei dem SSL aktiviert ist.

Dann noch ein service apache2 reload (oder systemctl reload apache2, oder apache2ctl graceful), und jetzt ist phpMyAdmin nur noch unter http://mein-vhost.example/phpmyadmin/ abrufbar - und nirgendwo sonst.

Wer ganz andere Lösungen umsetzen möchte als der Debian-Default es vorsieht (bspw. ein Aufruf über https://phpmyadmin.mein-vhost.example/), der kann die Debian-Konfiguration schlicht als Ausgangspunkt nehmen und die entscheidenden Teile in einen passenden vhost kopieren.

Von Jessie zu Stretch

nospam@example.com (Thomas Hochstein) — Wed, 06 Sep 2017 05:45:00 +0000

Ein Jahr nach dem letzten Distributions-Upgrade stand für meinen heimischen Server das Upgrade auf Debian Stretch an, das (wie immer) allein durch Download und Installation einige Zeit in Anspruch nahm, diesmal aber auch ungewohnt viele manuelle Eingriffe erforderte.

Erneut war ich positiv über die geringe Zahl von Änderungen in conffiles überrascht; insgesamt verlief das Upgrade auch grundsätzlich problemlos. Es “hakte” dann aber im Vergleich zu früheren Upgrades doch ungewohnt oft - jedenfalls für Debian, das normalerweise nach meiner Erfahrung einen nahezu hindernisfreien Upgrade-Pfad bietet.

Konkrete Einzelfallprobleme

Es begann damit, dass das initiale Upgrade und das folgende Dist-Upgrade nicht ohne Schwierigkeiten durchliefen, sondern abbrachen und mehrfach neu gestartet werden mussten; ohne längere Suche im Log kann ich den Grund dafür gar nicht benennen, was letztlich aber auch egal ist - solange am Ende das Upgrade durchläuft, soll’s mir recht sein.

Ganz tat es das allerdings nicht; die Datenbank-Upgrades von phpMyAdmin und Roundcube scheiterten, weil der Datenbank-Server nicht richtig lief. Das wiederum lag darum, dass das Upgrade / die Umstellung von mySQL auf MariaDB nicht vollständig funktioniert hatte:

mysqld_safe[6933]: 2017-09-01 13:52:40 139724014662208 [Note] Using unique option prefix 'key_buffer' is error-prone and can break in the future. Please use the full name 'key_buffer_size' instead.
mysqld_safe[6933]: 2017-09-01 13:52:40 139724014662208 [Note] /usr/sbin/mysqld (mysqld 10.1.26-MariaDB-0+deb9u1) starting as process 6959 ...
mysqld_safe[6933]: 
mysqld_safe[6933]: Installation of system tables failed!  Examine the logs in
mysqld_safe[6933]: /var/lib/mysql for more information.
mysqld_safe[6933]: 
mysqld_safe[6933]: The problem could be conflicting information in an external
mysqld_safe[6933]: my.cnf files. You can ignore these by doing:
mysqld_safe[6933]: 
mysqld_safe[6933]:     shell> /usr/scripts/scripts/mysql_install_db --defaults-file=~/.my.cnf
mysqld_safe[6933]: 
mysqld_safe[6933]: You can also try to start the mysqld daemon with:
mysqld_safe[6933]: 
mysqld_safe[6933]:     shell> /usr/sbin/mysqld --skip-grant --general-log &
mysqld_safe[6933]: 
mysqld_safe[6933]: and use the command line tool /usr/bin/mysql
mysqld_safe[6933]: to connect to the mysql database and look at the grant tables:
mysqld_safe[6933]: 
mysqld_safe[6933]:     shell> /usr/bin/mysql -u root mysql
mysqld_safe[6933]:     mysql> show tables;
mysqld_safe[6933]: 
mysqld_safe[6933]: Try 'mysqld --help' if you have problems with paths.  Using
mysqld_safe[6933]: --general-log gives you a log in /var/lib/mysql that may be helpful.
mysqld_safe[6933]: 
mysqld_safe[6933]: The latest information about mysql_install_db is available at
mysqld_safe[6933]: https://mariadb.com/kb/en/installing-system-tables-mysql_install_db
mysqld_safe[6933]: MariaDB is hosted on launchpad; You can find the latest source and
mysqld_safe[6933]: email lists at http://launchpad.net/maria
mysqld_safe[6933]: 
mysqld_safe[6933]: Please check all of the above before submitting a bug report
mysqld_safe[6933]: at http://mariadb.org/jira
mysqld_safe[6933]:

Ich mutmaße, dass die Rechte in /var/lib/mysql nicht ganz stimmten - was auch immer. Mehrere Versuche mit mysql_upgrade und /usr/bin/mysql_install_db --defaults-file=~/.my.cnf waren jedenfalls schlussendlich erfolgreich; die Einzelheiten habe ich nicht debugt.

Änderungen für bestimmte Softwarepakete

Abgesehen von dem vorstehend geschilderten Einzelfallproblem ergeben sich einige generelle Merkpunkte, die ich auch beim Upgrade meiner anderen Maschinen im Blick behalten werde:

Der Account uucp bekam - wie beim Upgrade auf Jessie - wieder /usr/sbin/nologin als Shell verpasst.
fail2ban startete nicht mehr, weil in der /etc/fail2ban/jail.local ein nicht mehr existenter Filter aktiviert wurde. Nach Berichtigung der Konfiguration ließ sich der Dienst problemlos starten.
Der isc-dhcp-server startet jetzt per Default für ipv4 und ipv6; jedenfalls bei mir fehlte ihm aber für letzteres die passende Konfiguration, so dass er mit einer Fehlermeldung stehenblieb. Das bisherige Verhalten lässt sich wiederhestellen, indem man in /etc/default/isc-dhcp-server folgendes setzt: INTERFACES="eth0". Da aber INTERFACES offenbar demnächst wegfällt, kann man es auch direkt richtig machen und stattdessen INTERFACESv4="eth0" setzen.
Wer duply und duplicity für sein Backup nutzt, muss aufgrund der neuen Version von gpg die Konfiguration anpassen: in der conf-Datei ist zu setzen: GPG_OPTS='--pinentry-mode loopback'
offlineimap verifiziert jetzt TLS-Zertifikate, will also immer dann, wenn ssl = yes in der Konfiguration gesetzt ist (aber wohl auch dann, wen SSL jedenfalls möglich wäre), entweder den Pfad zu den Root-Zertifikaten angegeben haben (wenn die Gegenstelle ein Zertifikat einer anerkannten CA hat) oder den Fingerprint des Zertifikats (wenn es sich um ein selbst-signiertes handelt). Zum jeweiligen remotehost gehört also entweder sslcacertfile = /etc/ssl/certs/ca-certificates.crt oder cert_fingerprint = ....
Außerdem müssen bei offlineimap Sonderzeichen in Passworten - konkret hier % - teilweise gequoted werden (konkret hier als %%).
Jedenfalls wenn bei offlineimap das Feature Name translation genutzt wird, muss überdies die Konfiguration auch insoweit angepasst werden - offlineimap synchronisiert Folder jetzt beidseits, was beim Umschreiben von Foldernamen zum Chaos führen kann, weil externe Folder lokal anders heißen und dann ggf. unter ihrem lokalen Namen neu auf den entfernten IMAP-Server synchronisiert würden. Die Name translation muss daher beidseits erfolgen, daher auch für das lokale “Repository” (“Reverse namentrans”). Der Aufruf von offlineimap --info kann beim Debugging hier sehr hilfreich sein.
Wer gitolite genutzt hat und nun auf gitolite3 umstellen will, wird jedenfalls die bisherige Konfiguration übernehmen bzw. anpassen müssen und muss auf den Clients im Auge behalten, dass der lokale Benutzer auf dem Server jetzt nicht mehr gitolite, sondern gitolite3 heißt. (Ob es einen automatisierten Upgrade-Pfad gibt, wenn man gitolite3 nachinstalliert, kann ich nicht sagen, weil ich so “klug” war, erst das gitolite-Paket zu entfernen und dann gitolite3 zu installieren …)

Hinweis: In den Kommentaren finden sich noch Ergänzungen, auf die ich später gestoßen bin. So muss man als Nutzer von suck daran denken, den Injection-Info:-Header auszufiltern, und wer noch DSS-Keys für (automatisierte) SSH-Verbindungen nutzt, sollte im Blick haben, dass ssh-dss nicht mehr zu den PubkeyAcceptedKeyTypes gehört.

Neue Software und geänderte Defaults

vim hat per Default ärgerlicherweise eine aktivierte Maussteuerung verpasst bekommen, die sich zudem (aufgrund der Reihenfolge, mit der die Konfigurationsdateien eingelesen werden) nicht systemweit deaktivieren lässt, sondern zumindest eine leere ~/.vimrc für jeden Nutzer erfordert (weil sonst stattdessen /usr/share/vim/vim80/defaults.vim geladen wird, und zwar zur selben Zeit wie sonst die .vimrc und damit nach /etc/vim/vimrc.local). Alternativ kann man das Laden der defaults.vim in /etc/vim/vimrc deaktivieren (wenn man dieses conffile um den entsprechenden, auskommentierten Inhalt ergänzt hat, wie beim Upgrade vorgeschlagen). Für die Einzelheiten sehr informativ ist hier der entsprechende Bugreport.
Mit Debian Stretch kommt PHP7; es mag sich daher empfehlen, PHP5 zu deinstallieren. Außerdem wird man im Zweifel spätetens jetzt auf php-fpm umstellen wollen.

Zusammenfassung

Das Upgrade verlief - in einer Gesamtbetrachtung - ohne echte (reproduzierbare) Fehler, erforderte aber ungewöhnlich viel manuellen Nacharbeit. Andererseits wurden zumindest manche Punkte vermutlich im jeweiligen NEWS-Eintrag angesprochen (ich muss gestehen, ich lese die Upgrade-Anleitung immer sehr genau, aber NEWS habe ich bisher allenfalls überflogen - keine gute Idee), und meine Konfiguration hier zuhause ist eher komplex und historisch gewachsen; eine schlechte Kombination.

Weitere Hinweise zum Upgrade gibt es auch in Jonathan McDowell’s Blog.

Webserver-Tuning

nospam@example.com (Thomas Hochstein) — Tue, 22 Aug 2017 05:40:00 +0000

Alle paar Monate wieder turnt ein - weniger rücksichtsvoller - Crawler vorbei und spidert sich zügig durch alle Einträge meines Blogs. Damit brachte er meinen bisherigen Server gerne an den Rand seiner Leistungsfähigkeit, durfte dieser doch für jeden Link einen php-cgi-Prozess starten. Man merkte das recht schnell an den steigenden Antwortzeiten, und auch interaktiv auf der Shell machte sich die steigende load bemerkbar. Am Ende blieben meist einige php-cgi-Prozesse übrig, die man dann manuell mittels kill entsorgen durfte. (Vielleicht lag auch hier das eigentliche Problem, dass nämlich die genutzten Ressourcen nicht wieder freigegeben wurden. Hinter die Einzelheiten bin ich nie so recht gekommen.)

Die brandneue Maschine hingegen sollte durch FastCGI und massenhaft RAM sowie schnelle SSDs einem solchen Ansturm (auch bei weiterer Verwendung des doch eher schwergewichtigen Apachen) besser gewachsen sein - dachte ich mir. Bis eines Freitagmorgens die E-Mails des Monitoring-System eingingen, die mir mitteilten, dass der Webserver nicht mehr auf Anfragen reagiert. Gar nicht mehr.

Der Grund dafür fand sich schnell im Log:

[mpm_event:error] [pid 1365:tid 139856442496192] AH00484: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting

Alle Threads des Webservers waren mit Anfragen ausgelastet (und offensichtlich wurden sie auch nicht mehr freigegeben - oder der Apache hatte sich “verschluckt”). Ein service apache2 restart löste daher das Problem; Zeit aber für einen Blick in die Konfiguration - vielleicht sollte man etwas an den Limits drehen (“consider raising the MaxRequestWorkers setting “).

Apache Event-MPM

Für das verwendete MPM findet sich die entsprechende Konfiguration (unter Debian) in /etc/apache2/mods-enabled/mpm_event.conf; sie sieht per default so aus:

# event MPM
# StartServers: initial number of server processes to start
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadsPerChild: constant number of worker threads in each server process
# MaxRequestWorkers: maximum number of worker threads
# MaxConnectionsPerChild: maximum number of requests a server process serves
<IfModule mpm_event_module>
       StartServers              2
       MinSpareThreads          25
       MaxSpareThreads          75
       ThreadLimit              64
       ThreadsPerChild          25
       MaxRequestWorkers       150
       MaxConnectionsPerChild    0
</IfModule>

Es werden also standardmäßig zwei Serverprozesse (StartServers)gestartet; jeder hat 25 Threads (ThreadsPerChild), also können 50 parallele Anfragen abgearbeitet werden. Sobald weniger als 25 freie Threads zur Verfügung stehen (MinSpareThreads), werden weitere Serverprozesse gestartet, bis zum Maximum von 150 Threads (MaxRequestWorkers) - das entspricht sechs Prozessen (mit je 25 Threads). Sobald mehr als 75 Threads unbeschäftigt sind (MaxSpareThreads), werden Serverprozesse wieder zurückgefahren.

150 Prozesse für eine Vielzahl von Webpräsenzen erschien mir wirklich nicht viel; ich habe (angesichts des zur Verfügung stehenden Speichers) daher etwas nachgelegt:

<IfModule mpm_event_module>
        ServerLimit               40
        StartServers               5
        MinSpareThreads          100
        MaxSpareThreads          250
        ThreadLimit               64     
        ThreadsPerChild           25
        MaxRequestWorkers       1000
        MaxConnectionsPerChild  1000
</IfModule>

Wir fangen jetzt also mit mit 125 Threads an (fünf Server mit je 25 Threads) und halten minimal 100 Threads bereit, maximal 250 - eine Lastspitze kann daher besser abgefedert werden, weil von Anfang an mehr Ressourcen bereitstehen und schneller zusätzliche Ressourcen hochgefahren werden). Maximal können dann 1.000 Threads laufen (statt vorher 150) - zu diesem Zweck muss auch ServerLimit erhöht werden, das per Default auf 16 steht - denn 1.000 Threads brauchen bei 25 Threads pro Prozess 40 Prozesse (mit dem Default von 16 Prozessen kommt man daher maximal auf 400 Threads).

Außerdem lasse icn jeden Thread nach 1.000 beantworteten Anfragen neu starten (MaxConnectionsPerChild); so können sich Speicherlecks nicht zu Problemen auswachsen.

Seitdem war der Webserver jedenfalls nicht mehr komplett ausgelastet; schauen wir mal, ob das schon der richtige Mittelweg zwischen der Bereitstellung ausreichender Ressourcen und dem Schutz des Gesamtsystems vor Überlast war oder mir als nächstes die ganze Maschine in die Knie geht, wenn es mal richtig rundgeht …

FPM-Konfiguration

Für Webapplikationen in PHP ist die Apache-Konfiguration nicht das einzige limitierende Element - vielmehr muss jede Anfrage auch von einem FastCGI-Prozess beantwortet werden, und auch die sind limitiert: per Default (bei Debian) auf 50 pro Pool, konfiguriert (unter Strech) in /etc/php/7.0/fpm/pool.d/www.conf, wobei statt www.conf eben der jeweilige Pool einzusetzen ist.

Das erscheint mir ebenfalls nicht besonders viel; ich habe daher den Pool für mein Blog etwas nach oben angepasst:

pm.max_children = 250
pm.start_servers = 30
pm.min_spare_servers = 10
pm.max_spare_servers = 50

Zu lesen ist das ähnlich wie oben beim Apachen: 30 Prozesse stehen von Anfang an zur Verfügung, 10 müssen mindestens immer arbeitslos sein, sonst werden Prozesse nachgelegt, bis zur Maximalzahl von 250. Ab 50 “arbeitslosen” Prozessen werden überzählige Prozesse gestoppt.

Erfahrungswerte

Ich habe bisher, muss ich gestehen, nicht die geringste Erfahrung mit solchen “Tuning-Aufgaben”, und werde daher abwarten müssen, ob sich die Werte bewähren. Aus dem Log kann ich jedenfalls sehen, dass 50 Prozesse viel zu wenig waren und auch 150 mehrfach nicht ausreichten:

WARNING: [pool blog] server reached pm.max_children setting (150), consider raising it

Andererseits habe ich bisher zumindest aus Munin - das allerdings nicht sehr fein auflöst - keine Hinweise für Lastspitzen (CPU-Nutzung, RAM-Nutzung und Load); da scheint im Tagesverlauf überall noch viel, viel Luft nach oben zu sein.

Hat jemand aus der werten Leserschaft Erfahrungen und Tips, die er gerne teilen möchte? Sonst berichte ich, wenn das nächste Mal etwas danebengeht.

systemd-Unit für srsd unter Debian

nospam@example.com (Thomas Hochstein) — Mon, 14 Aug 2017 05:10:00 +0000

Ich fürchte, das wird einer dieser Beiträge, bei dem die notwendige Vorrede bald länger wird als der Beitrag selbst …

Aber fangen wir einfach einmal vorne an: Der Kampf gegen unerwünschte E-Mails, die einen mit Malware oder Angeboten für die Verlängerung oder Vergrößung verschiedenster Körperteile (neuerdings auch - noch sachnah - gerne für den Wechsel der Krankenkasse) beglücken, heutzutage meist als Spam bezeichnet, tobt seit Jahrzehnten. Nach den verschiedensten Filtern entstanden auch mehrere Ansätze, die gar nicht so sehr den Spam an sich bekämpfen, sondern weiter vorne - oder auch parallel - ansetzen und die (meist mit Spam verbundene) Fälschung von Absenderadressen verhindern bzw. umgekehrt eine (begrenzte) Garantie für die Echtheit des Absenders übernehmen wollen.

SPF und DKIM

Dazu gehören SPF (Sender Policy Framework, früher: sender permitted from) und DKIM (DomainKeys Identified Mail).

Bei SPF nutzt der Verantwortliche für eine Domain (meist ein Provider) das DNS (Domain Name System), um dort bekanntzugeben, von welchen Servern (welchen IP-Adressen) “echte” Mail mit einem Absender aus dieser Domain stammen dürfen. So kann bspw. GMX festlegen, dass legitime Mail mit einem Absender @gmx.net (also bspw. irgendwer@gmx.net) nur von einem ihrer Mailserver ausgehen dürfen:

thh@thangorodrim:~$ host -t txt gmx.net 
gmx.net descriptive text "v=spf1 ip4:213.165.64.0/23 ip4:74.208.5.64/26 ip4:212.227.126.128/25 ip4:212.227.15.0/25 ip4:212.227.17.0/27 ip4:74.208.4.192/26 ip4:82.165.159.0/24 ip4:217.72.207.0/27 -all"

(Da sieht man dann auch direkt das erste Problem: wer als Kunde von GMX eine E-Mail mit seiner GMX-Adresse über einen anderen Mailserver versenden will, steht vor Schwierigkeiten.)

SPF funktioniert besonders gut zusammen mit DNSEC, also digital signierten DNS-Einträgen, deren Echtheit sich prüfen lässt.

DKIM geht einen Schritt weiter und publiziert nicht (nur) eine (sich ggf. oft ändernde) Liste legitimer Absender-Server für eine Domain, sondern veröffentlicht im DNS einen digitalen Signaturschlüssel, mit dem dann die wesentlichen Teile der Header (“Kopfzeilen”) einer jeden ausgehenden Mail digital signiert werden. Auch hier steht natürlich vor Problemen, wer nicht den Server des Anbieters zum Mailversand nutzt, denn nur der kann entsprechend digital signieren.

SPF und auch DKIM werden aber vor allem dann zum Problem, wenn man E-Mails weiterleiten möchte - also eine Mailingliste betreibt, oder auch nur einen einfachen Mailverteiler, oder eine Mailweiterleitung von einem Postfach auf ein anderes eingerichtet hat. In allen Fällen geht dann nämlich die E-Mail mit dem (im Beispiel) GMX-Absender bei der Mailingliste (oder dem Mailverteiler, oder dem ersten eigenen Postfach) ein und wird von da weiterversandt (an die Teilnehmer der Mailingliste, den Verteiler ode das Weiterleitungsziel, also das andere eigene Postfach). Dort aber kommt die E-Mail mit einem GMX-Absender, aber von einem falschen Server aus an! (Nämlich von dem Mailinglistenserver, dem Mailverteiler-Server oder dem Server, der zum ersten eigenen Postfach gehört.) Das führt zu einer fehlschlagenden SPF-Prüfung, und wenn bei der Weiterleitung (gerade bei einer Mailingliste!) Header eingefügt oder geändert wurden, dann schlägt auch die DKIM-Signaturprüfung fehl.

SRS

Das SPF-Problem für Weiterleitungen lösen will SRS, das Sender Rewriting Scheme: der technische Absender der Mail (der Envelope-From) wird geändert, so dass die E-Mail nicht mehr von (im Beispiel) GMX kommt, sondern vom Weiterleitungsserver.

Die E-Mail von irgendwer@gmx.net wird also vom Server postfach.provider.example mit einem Absender wie weiterleitung@postfach.provider.example weitergeschickt. Jetzt kommt die Mail für den letztendlichen Empfänger vom “richtigen” Server, nämlich postfach.provider.example (sie hat ja keinen GMX-Absender mehr!).

Das allerdings ist nur der erste Schritt: Fehlermeldungen (wie zum Beispiel über ein volles Postfach) sollen ja nicht beim Weiterleitungsserver landen, sondern an den ursprünglichen Absender zurückgehen. Dieser muss sich also aus der neu erzeugten Absenderadresse rekonstruieren lassen. Da hilft so etwas wie VERP (Variable envelope return path); statt weiterleitung@postfach.provider.example nehmen wir also weiterleitung+irgendwer=gmx.netg@postfach.provider.example. Da steckt die alte Adresse drin; wir wissen also, wo wir Fehlermeldungen an diese Adresse hinschicken müssen.

Auch das genügt aber noch nicht; denn nur echte Fehlermeldungen sollen an den Absender zurückgehen, nicht aber möglicher Spam, der mit leerem Absender (wie eine Fehlermeldung) an die durch den Weiterleitungsserver erzeugte Absenderadresse geht. Was hinderte einen Spammer, seine unerwünschten Nachrichten an weiterleitung+irgendwer=gmx.netg@postfach.provider.example zu schicken? Und dann senden wir den Mist auch noch an irgendwer@gmx.net weiter! Die von uns erzeugten neuen Absenderadressen müssen also kryptographisch gesichert werden, damit nur wir sie erzeugen können, ein Dritter sie aber nicht erraten kann.

systemd unit file für srds

Und “schon” sind wir beim eigentlichen Thema dieses Eintrags angekommen!

Eine Software, die solche kryptographisch sicheren Absenderadressen erzeugen kann, ist srsd, der auch in Debian als Paket verfügbar ist. Auf meinem alten Server hatte ich das vor Jahren einmal kurzfristig aufsetzen müssen, weil Weiterleitungen (ein simpler Mailverteiler) scheiterten, und diese Lösung wollte ich nunmehr auch auf dem neuen Server haben.

Eine Anleitung für die Konfiguration von Exim 4 mit srsd hat Adrian Zaugg geschrieben; sie setzt allerdings auf ein altes sysvinit-Startup-Script. systemd kann zwar auch damit umgehen; ich hätte aber lieber ein “natives” unit file für systemd gehabt.

Also habe ich mich ein wenig belesen und bin bei folgender Lösung gelandet, die als /lib/systemd/system/srsd.service zu speichern ist:

[Unit]
Description='srsd - SRS daemon'
After=syslog.target

[Service]
Type=simple
User=Debian-exim
Restart=on-failure

ExecStart=/usr/bin/srsd --secretfile /etc/exim4/srsd.secret
ExecStopPost=/bin/rm /tmp/srsd

[Install]
WantedBy=multi-user.target

Dann noch das kryptographische Geheimnis erzeugen (bspw. mit openssl rand -base64 12 > /etc/exim4/srsd.secret), und dann kann es mit systemctl enable srsd und systemctl start srsd losgehen.

Meine Variante der Anbindung an Exim kann ich dann gelegentlich[tm] mal nachliefern.

Was meint die werte Leserschaft?

Ich bin sicher, es geht besser - das war mein erstes unit file, und vieles daran ist aus copy & paste mit nachfolgendem Ausprobieren entstanden. Vielleicht (nein, sogar sicher!) kann ich ja noch etwas von meinen Lesern lernen?