Netz - Rettung - Recht (Artikel mit Tag debian)

Von Debian Stretch zu Buster - Teil 2

nospam@example.com (Thomas Hochstein) — Wed, 07 Apr 2021 14:45:00 +0000

Vor rund einem Jahr habe ich meinen größten Server auf Debian Buster geupgradet; über Ostern habe ich die restlichen vier Maschinen nachgezogen, so dass nur noch mein Homeserver und ein Altfall bleiben.

Wesentlich neues hat sich dabei nicht ergeben; ich kann im Prinzip auf den vorherigen Eintrag Bezug nehmen. Insgesamt liefen die Upgrades erfreulich glatt.

Notwendige Änderungen / Caveats

phpMyAdmin ist in Debian Buster nicht enthalten, kann aber aus den Backports installiert bzw. geupdatet werden, das ist also kein Problem.
Bei Spamassassin ändert sich die Art und Weise der Aktivierung; das ENABLED-Flag aus /etc/default/spamassassin entfällt.
logrotate wird nicht mehr als Cronjob, sondern als systemd-Timer ausgeführt; ich habe mich (wie im verlinkten Beitrag beschrieben, ungeachtet der Vorschläge dort in den Kommentaren) erneut für eine Änderung der Timer-Unit entschieden, so dass alle Maschinen auf demselben Stand sind.
PHP 7.3 ersetzt PHP 7.0; dementsprechend sind, wie im verlinkten Beitrag beschrieben, die PHP-FPM-Konfigurationen anzupassen.
Wie immer möchte debsecan per dpkg-reconfigure debsecan das aktuell installierte Release beigebogen bekommen.
su behält nunmehr das Environment des bisherigen Users, insbesondere PATH, bei, hat also standardmäßig bspw. /usr/sbin/ nicht mehr im Pfad. Der Aufruf mit su -l hilft.

Mit dem angeblich zu der Version aus Stretch nicht kompatiblen duply und den in den Hinweise hervorgehobenen Änderungen an gnupg2, OpenSSH und OpenSSL hatte ich keine Schwierigkeiten.

Notwendige Änderungen an Konfigurationsdateien

Insbesondere folgende Konfigurationsdateien waren bei mir von Änderungen betroffen:

/etc/dovecot/conf.d/10-mail.conf
/etc/dovecot/conf.d/10-ssl.conf
/etc/mysql/mariadb.conf.d/50-server.cnf
/etc/munin/plugin-conf.d/munin-node
/etc/news/inn.conf
/etc/news/incoming.conf (nur Kommentare)
/etc/oidentd.conf
/etc/ssh/sshd_config
/etc/systemd/timesyncd.conf

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. Erfreulicherweise war aber wenig zu tun.

Auch sonst sind mir bislang keine Schwierigkeiten aufgefallen.

[Nachträglich veröffentlicht im September 2021]

Von Debian Stretch zu Buster

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

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 hatte mit den Betriebssystemupdate nichts zu tun.

Hinweise zu bestimmten Softwarepaketen

Ein paar Notizen:

phpMyAdmin ist in Debian Buster nicht enthalten, kann aber aus den Backports installiert bzw. geupdatet werden, das ist also kein Problem.
Bei Spamassassin ändert sich die Art und Weise der Aktivierung; das ENABLED-Flag aus /etc/default/spamassassin entfällt.
Dovecot bekommt per Default ein selbstsigniertes SSL-Zertifikat; wenn man schon selbst eines hat, will man diese Änderung natürlich nicht.
Angeblich soll duply zu der Version aus Stretch nicht kompatibel sein, da haben sich bei mir aber keine Probleme ergeben.
Wie immer möchte debsecan per dpkg-reconfigure debsecan das aktuell installierte Release beigebogen bekommen.
su behält nunmehr das Environment des bisherigen Users, insbesondere PATH, bei, hat also standardmäßig bspw. /usr/sbin/ nicht mehr im Pfad. Der Aufruf mit su - hilft.
Die in den NEWs hervorgehobenen Änderungen an gnupg2, OpenSSH und OpenSSL haben mich nicht betroffen.

logrotate nicht mehr als Cronjob, sondern als systemd-Timer

Wenn man Exim als MTA verwendet und weiterhin über den bei Debian inkludierten Cronjob den dort generierten täglichen Report erhalten will, muss man dessen Erzeugung auf den Zeitpunkt der Logrotation abstellen. Bei Stretch - und zuvor - ist das kein Problem, weil sowohl die Erzeugung des Reports als auch die Logrotation über Cronjobs in /etc/cron.daily erfolgen, die in alphabetischer Reihenfolge ausgeführt werden, und da kommt exim4-base vor logrotate. Debian Buster aber setzt bei Logrotate stattdessen auf einen systemd-Timer; ist systemd auf dem System aktiv, wird der Cronjob deaktiviert:

# skip in favour of systemd timer
if [ -d /run/systemd/system ]; then
    exit 0
fi

Die Timer-Unit für logrotate findet sich in /lib/systemd/system/logrotate.timer und wird täglich ausgeführt:

[Unit]
Description=Daily rotation of log files
Documentation=man:logrotate(8) man:logrotate.conf(5)

[Timer]
OnCalendar=daily
AccuracySec=12h
Persistent=true

[Install]
WantedBy=timers.target

Bedauerlicherweise läuft cron.daily bei Debian standardmäßig um 06.30 Uhr, und der systemd-Timer bereits um Mitternacht. Daher enthält der Exim-Report nur noch sechseinhalb von vierundzwanzig Stunden, und zudem die eher wenig aktiven Nachtzeiten.

Für dieses Problem gibt es verschiedene Lösungen; man kann den Zeitpunkt von cron.daily verlegen, den Exim-Cronjob auslagern und auf einen eigenen Zeitpunkt verlegen und was der Dinge mehr sind. Ich habe mich stattdessen dazu entschieden, den Zeitpunkt der Logrotation zu verlegen, und zwar “hinter” cron.daily. Das erscheint mir aus verschiedenen Gründen vorzugswürdig: der Eingriff betrifft nur ein Element (logrotate) und nicht den Zeitpunkt zur Ausführung zentraler Systemdienste, er verschiebt keine bei Debian mitgelieferten Dateien an einen anderen Ort, und der Gedanke ist nicht fernliegend, dass auch andere tägliche Cronjobs möglicherweise damit rechnen, dass ihnen die Logs nicht vor der Nase wegrotiert werden.

Technisch ist das minimalinvasiv machbar: systemd-Units in /etc/systemd haben Vorrang vor denen in /lib/systemd; es genügt also, einen /etc/systemd/system/logrotate.timer mit angepasstem Inhalt zu erstellen, indem man /lib/systemd/system/logrotate.timer nach dort kopiert und die Zeile OnCalendar anpasst:

OnCalendar=*-*-* 06:35:00

Das führt die Logrotation nunmehr täglich um 06.35 Uhr, also fünf Minuten nach cron.daily, aus. Mit systemctl reenable logrotate.timer wird die Änderung übernommen (d.h. der Symlink der Timer-Unit gelöscht und - auf die neue, vorrangige Einheit - neu erstellt, mit systemctl list-timers kann man sich den richtigen Zeitpunkt der Timer-Ausführung bestätigen lassen.

Änderungen an Konfigurationsdateien

Insbesondere folgende Konfigurationsdateien waren bei mir von Änderungen betroffen:

/etc/dovecot/conf.d/10-mail.conf
/etc/dovecot/conf.d/10-ssl.conf
/etc/mysql/mariadb.conf.d/50-server.cnf
/etc/munin/plugin-conf.d/munin-node
/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; es gab praktisch nichts zu tun.

Umstellung von PHP 7.0 auf PHP 7.3

Mit Buster kommt PHP 7.3; man will also ggf. zum einen PHP 7.0 runterwerfen und muss in jedem Fall die PHP-FPM-Konfiguration mal wieder anpassen, weil die Konfigurationsdateien für PHP 7.3 “natürlich” in einem anderen Verzeichnis als die von PHP 7.0 liegen. Andererseits hat das den Vorteil, dass man PHP 7.0 zunächst auch weiterbetreiben kann, wenn man das möchte, oder beide Versionen parallel betrieben werden können.

Für die notwendigen Änderungen für den Wechsel kann ich auf meinen Beitrag zum Update auf Debia Stretch verweisen; es sind dieselben Schritte zu gehen wie beim Update von PHP 5.

Der größte Aufwand waren dann tatsächlich Umstellungen an PHP-Scripts - und der Kampf mit der aktuellen Version von nanoc, meinem static site compiler. (“Kampf” ist vielleicht etwas zuviel gesagt; ich habe primär einen Fehler beim Updaten der Ruby-Gems gemacht und hatte dann noch einige Anpassungen in eher speziellen Modulen vorzunehmen. Der Aufwand war v.a. deshalb größer, weil dieses Ökosystem für mich noch unvertraut ist.)

Zusammenfassung

Jedenfalls bei diesem Host war das Update unter dem Strich wirklich ereignislos. Möglicherweise sieht das anderswo noch anders aus, wenn bspw. INN und Mailman betroffen sind. Andererseits erlaubt Buster es, einmal Mailman 3 auszuprobieren …

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

Ä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?

Verzögerungen beim SSH-Login

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

Manchmal dauert der SSH-Login auf einem meiner Server etwas länger. Dann ist entweder dort die Load zu hoch oder es gibt Probleme mit der DNS-Auflösung meiner IP-Adresse oder das Netz ist dicht - meistens das heimische WLAN. Dieser Tage aber dauerte es nicht nur “etwas” länger - vielmehr hatte ich regelmäßige Verzögerungen im Bereich von etlichen Sekunden beim Login, immer auf denselben Maschinen (eine davon in meinem heimischen Netz!) und nach (!) dem Anzeigen des Login-Banners. Die Load war in Ordnung, die DNS-Auflösung sollte jedenfalls im lokalen Netz funktionieren, und ständig überlastet kann die Netzanbindung eigentlich auch nicht sein, jedenfalls nicht immer zu denselben beiden Maschinen.

Eigenartig.

Nachdem ich mich - wie üblich - zunächst einmal einfach nur geärgert und darauf gehofft hatte, dass das Problem sich von selbst lösen möge, sah ich mich dann doch gezwungen, zum Äußersten zu greifen und ins Logfile zu schauen. Dort fanden sich dann Einträge dieser Art:

Jul  3 21:11:02 myhost dbus[23288]: [system] Activating via systemd: service name='org.freedesktop.login1' unit='dbus-org.freedesktop.login1.service'
Jul  3 21:11:02 myhost systemd[1]: Started Login Service.
Jul  3 21:11:27 myhost dbus[23288]: [system] Failed to activate service 'org.freedesktop.login1': timed out

Ein Timeout - das würde ja passen! — Aber warum?

Die einfachste Lösung ist in solchen Fällen oft - und gerade bei absoluter Ahnungslosigkeit - ein gezielte Suche bei Google oder einer anderen Suchmaschine des jeweiligen Vertrauens. Mich brachte das in diesem Fall zu einem Stackexchange-Eintrag, der genau auf mein Problem passte: Dieser “Hänger” geschieht, wenn dbus neu gestartet wurde - und genau das hatte ich nach dem Einspielen von Updates getan!

Die Lösung soll sein, danach auch logind wieder zu starten. Und tatsächlich: service systemd-logind restart, und schon war wieder alles paletti.

(Vielleicht hilft das dem einen oder anderen, der - namentlich unter Debian Jessie - vor demselben Problem steht.)

letsencrypt jenseits des Webservers

nospam@example.com (Thomas Hochstein) — Tue, 30 Aug 2016 14:30:00 +0000

Vor einigen Monaten hatte ich über letsencrypt, die neue Zertifizierungsstelle für TLS-Zertifikate, berichtet und demletzt meine guten Erfahrungen damit dargestellt. Doch HTTP ist ja nicht das einzige Protokoll, das einer Absicherung bedarf. Wie sieht es mit TLS-Zertifikaten für Mail (SMTP und POP3 oder IMAP) und News (NNTP) oder noch andere Dienste aus?

Grundsätzlich ist das kein Problem: vorhandene Zertifikate mit dem (oder den) passenden Hostnamen müssen nur eingebunden werden.

In der Folge stelle ich die Vorgehensweise ausgehend von einem Debian-Jessie-System aus vor.

Erhalt des Zertifikats

Am einfachsten ist das, wenn unter jedem Hostnamen auch ein Webserver erreichbar ist; dann kann nämlich einfach das webroot-Plugin verwendet werden. Ist das nicht der Fall, kommen bspw. das manual-Plugin oder das external-Plugin in Betracht.

Installation des Zertifikats

Das bereits - für den Webserver - vorhandene oder neu erhaltene Zertifikat und der zugehörige Schlüssel ( Key), die üblicherweise im Verzeichnis /etc/letsencrypt/live/domain.example/ liegen, können nun eingebunden werden - entweder das Zertifikat und die ganze Zertifikatskette mit allen Zwischenzertifikaten zusammen in einer Datei (fullchain.pem), oder das Zertifikat (cert.pem) und die Zwischenzertifikate (chain.pem) getrennt, je nachdem, was die Applikation unterstützt.

Nicht immer ist es aber ohne weiteres möglich, unmittelbar auf die Dateien in /etc/letsencrypt/live/domain.example/ zuzugreifen, die root:root gehören und aufgrund der Verzeichnisrechte auch nur für root lesbar sind. Manche Programme (bspw. der Mailserver Exim) greifen nämlich auf die Zertifikate zu einem Zeitpunkt zu, zu dem sie bereits keine Root-Rechte mehr haben; und es erscheint wenig tunlich, sie in die Gruppe root aufzunehmen oder gar Zertifikat und Key weltweit lesbar zu machen. Andere Programme wiederum haben ausgesprochen strikte Vorstellungen darüber, welchem Benutzer und/oder welcher Gruppe die Dateien “gehören” müssen und wie die Zugriffsrechte auszusehen haben (so z.B. der Newsserver INN, der erwartet, dass der Key ausschließlich für den User news lesbar ist). In diesen Fällen wird es m.E. unausweichlich sein, Kopien der Zertifikate und des Keys mit den passenden Rechten anzulegen.

Dovecot

Der POP3- und IMAP-Server Dovecot greift als root auf die Zertifikate zu und kann - jedenfalls in seiner in Debian Jessie enthaltenen Version 2.2.13 - die Zertifikatskette (fullchain.pem) verarbeiten. Es genügt also, Zertifikat und Key einzubinden und die Serverkonfiguration neu einzulesen (service dovecot reload).

Exim

Anders sieht es mit dem SMTP-Server Exim aus. Dieser gibt seine Root-Rechte auf, bevor er auf die TLS-Zertifikate zugreift. Immerhin kommt auch er mit fullchain.pem klar.

Eine Möglichkeit ist es, Zertifikat und Key in ein passendes Verzeichnis zu kopieren und dann Eigentümer und Rechte (644!) anzupassen, bspw. so:

cd /etc/exim4
mkdir certs 
cp /etc/letsencrypt/live/domain.example/fullchain.pem /etc/exim4/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/exim4/certs/
service exim4 restart
chown Debian-exim:Debian-exim /etc/exim4/certs/
chown Debian-exim:Debian-exim /etc/exim4/certs/*
chmod 644 /etc/exim4/certs/*

Ein solches Vorgehen wird dann auch bei jeder Erneuerung der Zertifikate erforderlich (s.u.)!

Danach genügt es, die Serverkonfiguration neu zu laden (service exim4 reload) und sich dann zu Testzwecken auf Port 25 zu verbinden und nach dem EHLO ein STARTTLS abzusetzen.

INN

INN stellt - jedenfalls in der in Debian Jessie enthaltenen Version 2.5.4 - ganz besondere Ansprüche: jedenfalls der Key muss für den Benutzer news lesbar sein, und er benötigt cert.pem und chain.pem getrennt.

Umsetzen könnte man das bspw. so:

cd /etc/news
mkdir certs 
cp /etc/letsencrypt/live/domain.example/cert.pem /etc/news/certs/
cp /etc/letsencrypt/live/domain.example/chain.pem /etc/news/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/news/certs/
chown news:news /etc/news/certs/*
chmod 600 /etc/news/certs/*

Auch hier muss man dieses Vorgehen für eine Erneuerung der Zertifikate im Blick behalten (s.u.).

Ein Einlesen der inn.conf später (service inn2 restart) sollte dann alles funktionieren wie geplant.

Zertifikat-Updates

Die nunmehr im Dateisystem verstreuten Zertifikatskopien müssen nach jeder Erneuerung des Zertifikats gleichfalls erneuert werden, damit nicht ein ungültiges Zertifikat ausgeliefert wird. Sinnvollerweise geschieht das ebenso automatisiert wie die Erneuerung des Zertifikats; hilfreich dabei die Möglichkeit, letsencrypt (bzw. certbot) mittels --post-hook nach einem Zertifikatsaustausch ein Script ablaufen zu lassen.

Exim

Man könnte sich daher bspw. eine Datei /usr/local/bin/certbot-exim4-renew.sh mit folgendem Inhalt anlegen:

#!/bin/dash
cp /etc/letsencrypt/live/domain.example/fullchain.pem /etc/exim4/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/exim4/certs/
service exim4 reload

Dazu passt dann ein Cron-Eintrag der folgenden Art:

certbot certonly --quiet -n --webroot -w /var/www/domain.example -d domain.example --keep-until-expiring --post-hook /usr/local/bin/certbot-exim4-renew.sh

Damit wird versucht, das Zertifikat für diesen Hostnamen (domain.example) zu erneuern, jedoch nur, wenn es der Erneuerung bedürftig ist.

Der Aufruf sollte in der Crontab zeitlich vor dem allgemeinen Aufruf certbot renew --quiet erfolgen, damit erst das spezielle Zertifikat aktualisiert (und ggf. umkopiert) wird und danach die übrigen.

INN

Für den INN sähe diese Lösung analog mit einer Datei /usr/local/bin/certbot-inn2-renew.sh so aus:

#!/bin/dash
cp /etc/letsencrypt/live/domain.example/cert.pem /etc/news/certs
cp /etc/letsencrypt/live/domain.example/chain.pem /etc/news/certs
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/news/certs
cd /etc/news/certs
chown news:news *.pem
chmod 600 *.pem
service inn2 reload

Der Cron-Eintrag wäre dann entsprechend:

certbot certonly --quiet -n --webroot -w /var/www/domain.example -d domain.example --keep-until-expiring --post-hook /usr/local/bin/certbot-inn2-renew.sh

Auch dieser Eintrag muss zeitlich vor dem allgemeinen Aufruf certbot renew --quiet liegen.

Und ihr?

So richtig optimal erscheinen mir diese Lösungen noch nicht. Gibt es bessere Ideen? Andere Erfahrungen?

Nutzt ihr letsencrypt noch für andere Dienste als die oben genannten?

An Euren Erfahrungen und Lösungen wäre ich interessiert und freue mich daher über Kommentare, Hinweise und Ergänzungen.

Von Wheezy zu Jessie

nospam@example.com (Thomas Hochstein) — Mon, 15 Aug 2016 18:30:00 +0000

Heute bin ich - fast 16 Monate nach dem Release - endlich dazu gekommen, den heimischen Server von Debian Wheezy nach Jessie (Debian 8.0) zu aktualisieren. Wie üblich nahm das Distributions-Upgrade - schon durch den Download der aktualisierten Pakete und dann durch deren Installation - einige Zeit in Anspruch, verlief aber weitgehend problemlos. Erfreulich vor allem, dass der Wechsel auf systemd keine erkennbaren Schwierigkeiten mit sich brachte. Endlich ist jetzt auch zuhause service [whatever] status gesprächiger.

Größere Schwierigkeiten ergaben sich nicht; teilweise waren durch den Wechsel von Apache 2.2 auf Apache 2.4 Änderungen an der Apache-Konfiguration erforderlich, aber da ich kaum Webpräsenzen konfiguriert habe, hielt sich das im Rahmen. Dem Account uucp musste ich statt /usr/sbin/nologin wieder eine Shell verpassen, damit die Cronjobs laufen - darauf wurde aber eigentlich in den Release-Notes hingewiesen -, und die Dovecot-Konfiguration brauchte mehrfache Eingriffe, bis wieder alles lief; ich meine, dass dort ohne Rückfrage einfach aktualisierte Konfigurationsdateien eingespielt wurden, so dass Änderungen teilweise überschrieben wurden, möglicherweise weil die Konfigurationsdateien nicht korrekt als conffiles markiert waren. Das ließ sich aber schnell wieder beheben.

Glücklicherweise hielten sich diesmal auch die nachzuführenden Änderungen in conffiles, die sich in der Distribution geändert haben, aber auch von mir editiert worden waren, in Grenzen; das ist sonst erfahrungsgemäß der bei weitem größte Aufwand bei einem Upgrade.

Nun bin ich zuversichtlich, dass zumindest alle wesentlichen Dienste wieder laufen - jetzt in der jeweils aktuellsten (Debian-)Version. Also steht kein Zeitdruck zu befürchten, wenn der LTS-Support für Wheezy ausläuft oder Stretch released wird.

PHP-FPM - jetzt mit mod_proxy_fcgi

nospam@example.com (Thomas Hochstein) — Tue, 26 Apr 2016 05:50:00 +0000

Vergangene Woche hatte ich darüber berichtet, wie man - unter Debian Jessie - PHP-FPM mit mod_fastcgi installieren kann. In den Kommentaren hatte Sven mir dann nachfolgend erläutert, wie sich die Einbindung einfacher und besser über mod_proxy_fcgi lösen lässt, vorausgesetzt, man hat (wie in Debian Jessie) einen Apache 2.4 vor sich.

Da mir das ebenfalls vorzugswürdig erscheint, beschreiben ich in der Folge nunmehr diese Variante.

PHP-FPM und `mod_proxy_fcgi` installieren

Unter Debian Jessie ist die Installation der Pakete hinreichend einfach:

apt-get install php5-fpm php5

Debian hinterlegt dabei die php.ini für die FastCGI-Prozesse unter /etc/php5/fpm/php.ini und die Konfiguration für FPM unter /etc/php5/fpm/php-fpm.conf, ergänzt u.a. um die Konfiguration installierter Module in /etc/php5/fpm/conf.d/, wie man das so kennt.

Im Verzeichnis /etc/php5/fpm/pool.d/ sind dann die einzelnen Pools definiert, die ebenfalls in die /etc/php5/fpm/php-fpm.conf inkludiert werden, standardmäßig nur der Pool des Benutzers www-data, unter dem der Webserver läuft.

`mod_proxy_fcgi` für PHP-FPM konfigurieren

Serverweit lässt sich PHP-FPM dann wie folgt in einer neuen Datei /etc/apache2/conf-available/php5-fpm.conf konfigurieren:

<IfModule mod_proxy_fcgi.c>
    <Proxy "unix:/var/run/php5-fpm.sock|fcgi://php-fpm">
        # we must declare a (any) parameter in here 
        # or it won't register the proxy ahead of time
        ProxySet disablereuse=off
    </Proxy>
    <FilesMatch ".+\.php$">
        SetHandler proxy:fcgi://php-fpm
    </FilesMatch>
</IfModule>

Auf diese Weise werden auf .php endende Dateien an den darüber definierten Prxoy durchgereicht. Wer will, kann stattdessen bspw. auch <FilesMatch ".+\.ph(p[345]?|t|tml)$"> verwenden, wie Sven das empfohlen hat; das deckt auch alle anderen gebräuchlichen Endungen für PHP-Scripts ab.

Standardmäßig sorgt Debian übrigens dafür, dass das - mitinstallierte - Modul mod_proxy nicht als forward proxy arbeitet; das ist in der Datei /etc/apache2/mods-available/proxy.conf konfiguriert und stellt also kein Problem dar.

Nach Aktivieren des Moduls und der Konfiguration vermittels a2enmod proxy_fcgi und a2enconf php5-fpm sowie einem Restart des Webservers (service apache2 restart) sollte PHP nun zur Verfügung stehen.

Pools für einzelne Benutzer einrichten

Um nun verschiedene Pools für verschiedene Benutzer einzurichten, bedarf es neben einer passenden Konfiguration des jeweiligen Pools in /etc/php5/fpm/pool.d/ und eines geänderten Aufrufs in jedem virtual host, der diesem Benutzer zugeordnet ist.

Am einfachsten kopiert man sich die bestehende Konfiguration für den Pool www und wandelt sie ab:

cd /etc/php5/fpm/pool.d
cp www.conf user1.conf
vim user1.conf

Folgende Teile der Konfiguration müssen ersetzt werden: der Name des Pools, user, group und listen:

; Start a new pool named 'user1'.
; the variable $pool can we used in any directive and will be replaced by the
; pool name ('user1' here)
[user1]

[...]

user = user1
group = users

[...]

listen = /var/run/php5-fpm-user1.sock

Selbstverständlich können auch andere, für diesen Pool spezifische Änderungen vorgenommen werden

Und danach bekommt der bspw. in /etc/apache2/sites-available/user1-domain.example konfigurierte virtual host noch folgende Ergänzung (zwischen <VirtualHost ...> und </VirtualHost>):

<IfModule mod_proxy_fcgi.c>
    <Proxy "unix:/var/run/php5-fpm-user1.sock|fcgi://php-fpm-user1">
        # we must declare a (any) parameter in here 
        # or it won't register the proxy ahead of time
        ProxySet disablereuse=off
    </Proxy>
    <FilesMatch ".+\.php$">
        SetHandler proxy:fcgi://php-fpm-user1
    </FilesMatch>
</IfModule>

In diesem virtual host kommuniziert der Apache also nicht mit dem FastCGI-Server über /var/run/php5-fpm.sock, sondern über /var/run/php5-fpm-user1.sock, und den haben wir ja anders konfiguriert. Ein service apache2 restart bzw. service php5-fpm restart später sollte die geänderte Konfiguration zur Verfügung stehen.

Soll PHP in mehreren virtual hosts unter derselben Benutzerkennung laufen, empfiehlt es sich, die o.g. Konfiguration in eine eigene Datei (bspw. /etc/apache2/sites-available/user1.fcgi) auszulagern und diese Datei dann in die virtual host-Konfiguration einzubinden:

Include /etc/apache2/sites-available/user1.fcg

Das spart nicht nur Tipparbeit, sondern erleichtert auch spätere Änderungen sehr.

Die Installation testen

Am einfachsten gestaltet sich der Test, wenn man im Webroot des Servers (Debian Jessie: /var/www/html/) und der einzelnen virtual hosts jeweils eine Datei test.php speichert, die nur phpinfo() aufruft:

<?php phpinfo(); ?>

In der Ausgabe von phpinfo() wird angezeigt, unter welchem Benutzer das Script ausgeführt wird.

Vielen Dank an Sven für den hilfreichen Tip!

PHP-FPM mit Debian Jessie

nospam@example.com (Thomas Hochstein) — Mon, 18 Apr 2016 06:45:00 +0000

Statische Webseiten sind nett (und durchaus wieder im Kommen), aber zumindest für manche Zwecke sind dynamisch generierte Seiten und die auf diese Weise ermöglichte Interaktivität doch dann besser oder gar notwendig. Facebook, bspw., würde sich als statische Seite dann doch eher schwierig gestalten.

Die Welt dynamischer Webseiten

Scriptsprachen

Dynamisch generierte Seiten bedingen, dass beim Aufruf einer Webseite nicht nur eine auf dem Server abgelegte Datei angezeigt wird, sondern dass ein Programm dort läuft, das die Ausgabe mehr oder weniger live generiert. Das hat ganz andere Implikationen für die Sicherheit des Servers, denn nunmehr läuft dort von außen erreichbarer Code, der schlimmstenfalls noch durch die Nutzer selbst aufgespielt werden kann. Nicht jeder, der seine ersten Gehversuche mit Scripts macht, hat dabei auch Fragen der IT-Sicherheit ausreichend im Blick - um das Problem einmal stark verharmlosend zu beschreiben. Gerade PHP hat nicht den Ruf, zumindest in den ersten Jahren seiner Entwicklung großes Gewicht auf das Fördern oder gar Erzwingen sicherer Praktiken gelegt zu haben, und viele lern(t)en es vor allem als eine Art Templating-Sprache kennen, die man irgendwie in seine HTML-Seiten einbettet, um ihnen damit eine erweiterte Funktionalität zu verleihen, ohne dabei groß an Konsequenzen zu denken (schuldig, euer Ehren!).

Rechteprobleme

Besondere Schwierigkeiten kommen hinzu, wenn mehr als ein Benutzer auf dem Server Scripts nutzen will. Denn wenn der Webserver bzw. der von diesem gestartete Interpreter das Script ausführen will, muss er es lesen können. Dann muss er aber - logischerweise - auch die Scripts aller anderen nutzer lesen können, was bedeutet, dass Nutzer A ein Sript schreiben kann, mit dem er sich die Scripts von Benutzer B anzeigen lassen kann, samt aller dort gespeicherten Informationen (Datenbankpassworte usw.), ebenso wie Dateien, die Benutzer B anlegt. Und wenn das Script irgendwelche Dateien anlegt (man denke an hochgeladene Bilder), dann werden diese Dateien unter der Nutzerkennung des Webservers angelegt, so dass der Benutzer dann keinen vollen Zugriff darauf hat. Das ist alles etwas unschön, weshalb man schon bald die Möglichkeit geschaffen hat, Scripts (sei es Perl, sei es Python, sei es PHP) unter der Benutzerkennung des jeweiligen Nutzers laufen zu lassen, dem das Script “gehört”.

suexec und suphp

Das schafft zwar andere Probleme, insbesondere im Bereich der Performance, denn nun kann ein Webserverprozess nicht mehr beliebig viele Scripts in parallelen Threads abarbeiten, weil diese ja vielleicht verschiedenen Nutzern gehören, so dass für jedes Script ein neuer Interpreter-Prozess gestartet werden muss, aber es ist doch in der Regel vorzugswürdig.

Für Scripts, die über die CGI-Schnittstelle (ja, ich weiß, das “I” steht schon für “Interface”) gestartet werden, stellt suexec die entsprechende Funktionalität bereit. Für PHP tat das traditionell suphp. suphp gibt es aber in Debian Jessie nicht mehr. Was also tun?

Als Lösung bietet sich PHP-FPM an.

PHP-FPM

FPM steht dabei für FastCGI Process Manager und ist eine sehr angenehme Lösung, um PHP als FastCGI einzubinden. FastCGI ist ein Mittelding zwischen der Einbindung per mod_php, also als Modul im Webserver, und als CGI, so dass für jeden Aufruf eines PHP-Scripts ein eigener Prozess gestartet werden muss: es werden einige FastCGI-Prozesse gestartet, die in einem Pool vorgehalten werden, und wenn ein PHP-Script aufgerufen wird, wird der Aufruf vom Webserver an den schon laufenden Prozess weitergereicht. Das erspart den sonst für jeden Aufruf notwendigen Start des Interpreters - und es bietet die Möglichkeit, pro Pool festzulegen, unter welcher Benutzerkennung die Prozesse dieses Pools laufen sollen.

Hinweis: Der folgende Vorschlag ist nicht der einzige Weg, PHP-FPM zu installieren. Eine bessere Lösung unter Verwendung von mod_proxy_fcgi, auf die ich in den Kommentaren hingewiesen wurde, habe ich mittlerweile auch beschrieben. Dieser andere Weg setzt Apache 2.4.x voraus, benötigt aber kein Paket aus dem nicht-freien Debian-Repository. Insgesamt erscheint mir dieser andere Weg vorzugswürdig.

PHP-FPM installieren

Unter Debian Jessie ist die Installation der Pakete hinreichend einfach:

apt-get install libapache2-mod-fastcgi php5-fpm php5

libapache2-mod-fastcgi kommt hier aus dem non-free-Repository, das dementsprechend eingebunden sein muss.

FastCGI für PHP-FPM konfigurieren

Wenn man möchte, kann man die bestehende Konfigurationsdatei sichern:

cp /etc/apache2/mods-available/fastcgi.conf /etc/apache2/mods-available/fastcgi.conf.backup

und danach sie danach mittels vim /etc/apache2/mods-available/fastcgi.conf neu befüllen wie folgt:

<IfModule mod_fastcgi.c>
    AddType application/x-httpd-fastphp5 .php
    Action application/x-httpd-fastphp5 /php5-fcgi
    Alias /php5-fcgi /usr/lib/cgi-bin/php5-fcgi
    FastCgiExternalServer /usr/lib/cgi-bin/php5-fcgi -socket /var/run/php5-fpm.sock -pass-header Authorization
    <Directory /usr/lib/cgi-bin>
        Require all granted
    </Directory>
</IfModule>

Auf diese Weise bekommen auf .php endende Dateien den Typ x-httpd-fastphp5 zugewiesen, der über den Handler /php5-fcgi aufgerufen wird, der wiederum auf /usr/lib/cgi-bin/php5-fcgi zeigt, was aber ebenfalls nicht existiert, so dass Apache stattdessen alles dem externen FastCGI-Server zuwirft, der über den Socket /var/run/php5-fpm.sock kommuniziert.

Nach Aktivieren der notwendigen Module mittels a2enmod fastcgi actions alias und einem Restart des Webservers (service apache2 restart) sollte PHP zur Verfügung stehen.

Pools für einzelne Benutzer einrichten

Am einfachsten kopiert man sich die bestehende Konfiguration für den Pool www und wandelt sie ab:

cd /etc/php5/fpm/pool.d
cp www.conf user1.conf
vim user1.conf

Folgende Teile der Konfiguration müssen ersetzt werden: der Name des Pools, user, group und listen:

; Start a new pool named 'user1'.
; the variable $pool can we used in any directive and will be replaced by the
; pool name ('user1' here)
[user1]

[...]

user = user1
group = users

[...]

listen = /var/run/php5-fpm-user1.sock

Selbstverständlich können auch andere, für diesen Pool spezifische Änderungen vorgenommen werden

Und danach bekommt der bspw. in /etc/apache2/sites-available/user1-domain.example konfigurierte virtual host noch folgende Ergänzung (zwischen <VirtualHost ...> und </VirtualHost>):

<IfModule mod_fastcgi.c>
    AddType application/x-httpd-fastphp5 .php
    Action application/x-httpd-fastphp5 /php5-fcgi
    Alias /php5-fcgi /usr/lib/cgi-bin/php5-fcgi-user1
    FastCgiExternalServer /usr/lib/cgi-bin/php5-fcgi-user1 -socket /var/run/php5-fpm-user1.sock -pass-header Authorization
</IfModule>

Include /etc/apache2/sites-available/user1.fcg

Das spart nicht nur Tipparbeit, sondern erleichtert auch spätere Änderungen sehr.

Wichtig: Der Eintrag FastCgiExternalServer darf dabei nur einmal erfolgen, also nicht pro vhost wiederholt werden.

Die Installation testen

<?php phpinfo(); ?>

In der Ausgabe von phpinfo() wird angezeigt, unter welchem Benutzer das Script ausgeführt wird.

Weiterer Lesestoff

Alex Fornuto bei linode: Install PHP-FPM and Apache on Debian 8 (Jessie)
Apache httpd Wiki: High-performance PHP on apache httpd 2.4.x using mod_proxy_fcgi and php-fpm

SSL/TLS mit Let's Encrypt

nospam@example.com (Thomas Hochstein) — Mon, 11 Apr 2016 07:00:00 +0000

Bereits vergangene Woche berichtete ich von meinen Irrungen und Wirrungen des letzten Jahrzehnts mit SSL/TLS im Web. Erst Ende 2015 hatte ich mich aufgerafft, über StartCom für einige Domains Zertifikate erstellen zu lassen, und parallel die Berichterstattung über Let’s Encrypt verfolgt.

Der Workflow für die Erstellung und Pflege von HTTPS-Zertifikaten kann schnell komplex werden:

Am Anfang steht die Erzeugung eines Schlüsselpaares, denn das spätere Zertifikat wird nur derjenige verwenden können, der auch den passenden privaten Schlüssel hat.
Dann ist für jedes Zertifikat ein Certificate Signing Request (CSR) zu erstellen; das ist quasi die Roh-Form des späteren Zertifikats mit den notwendigen Informationen, die darin enthalten sein sollen.
Dieser CSR muss dann von der Zertifierungsstelle (Certificate Authority, CA) digital signiert werden.
Das so entstandene Zertifikat muss gespeichert und in die Webserver-Konfiguration eingebunden werden.
Der ganze Ablauf ist nur zielführend, wenn die CA von den verbreiteten Browsern anerkannt ist, den von ihr signierten Zertifikaten also vertraut wird. Dafür wollen die meisten CAs Geld. Zudem müssen sie sich über einen mehr oder weniger aufwendigen Weg zumindest vergewissern, dass derjenige, der ein Zertifikat für einen bestimmten Hostnamen ausgestellt haben möchte, über diesen auch verfügen kann.
Zertifikate werden in der Regel nur für einen begrenzten Zeitraum - meistens ein Jahr - ausgestellt. Danach müssen sie (rechtzeitig!) verlängert werden.

Let’s Encrypt ist angetreten, diese Abläufe weitestmöglich zu vereinfachen.

Let’s Encrypt - die Prinzipien

Let’s Encrypt arbeitet kostenlos und veröffentlicht die verwendeten Schnittstellen. Es stellt eine CA zur Verfügung, die automatisch Zertifikate ausstellt, nachdem sie überprüft hat, dass der Anfragende die administrative Kontrolle über den entsprechenden Hostnamen hat - beispielsweise, indem Let’s Encrypt verlangt, dass eine bestehende Datei auf dem Webserver unter diesem Hostnamen hinterlegt wird. Die erstellten Zertifikate werden öffentlich gemacht; es kann also jeder jederzeit nachvollziehen, wann Let’s Encrypt welche Zertifikate erstellt hat.

Mittlerweile ist das Zwischenzertifikat von Let’s Encrypt nicht nur durch Let’s Encrypt selbst, sondern auch durch eine andere CA (IdenTrust) signiert und wird daher regelmäßig von den Browsern als vertrauenswürdig anerkannt. Von Let’s Encrypt ausgestellte Zertifikate werden also akzeptiert und führen nicht zu irgendwelchen Warnmeldungen. Sie gelten allerdings nur rund 90 Tage und müssen dann erneut werden.

Let’s Encrypt stellt Client-Software zur Verfügung, die den gesamten, einleitend dargestellten Workflow automatisiert, ermöglicht es aber auch, die notwendigen Schritte in beliebigem Umfang manuell nachzuvollziehen oder auch eigene Lösungen zu programmieren. Im vollautomatischen Modus erstellt Let’s Encrypt das notwendige Schlüsselpaar und den CSR, überprüft, dass der Antragsteller den Hostnamen kontrolliert, stellt das Zertifikat aus und speichert es, passt die Webserver-Konfiguration an und bindet das Zertifikat ein und kann auf Wunsch rechtzeitig vor Ablauf ein neues Zertifikat erstellen.

Let’s Encrypt und der Apache-Webserver unter Debian Jessie

Im Anschluss möchte ich einen weitgehend, aber nicht völlig automatisierten Ablauf zum Erstellen von SSL-Zertifikaten und deren Einbindung in einen Apache unter Debian Jessie darstellen. Es ist durchaus möglich, weit weniger auf Automatismen zu setzen; dann muss der Client auch nicht zwingend mit Root-Rechten laufen. Matthias Gutjahr schildert in seinem Blog eine Möglichkeit dafür; Dirk Deimeke hat eine weitere Alternative dargestellt. Beide Beiträge sind am Ende dieses Blogbeitrags verlinkt.

Installation

Ab Jessie, der derzeit stabilen Debian-Version, steht letsencrypt als Paket zur Verfügung, allerdings nur in den Backports. Wenn sich in der /etc/apt/sources.list also die Zeile deb http://ftp.debian.org/debian jessie-backports main findet, ist die Installation daher denkbar einfach:

apt-get -t jessie-backports install letsencrypt

Die umfangreichen Abhängigkeiten werden mitinstalliert.

Wer noch unter Wheezy arbeitet, benötigt etwas mehr Vertrauen in die Macher von Let’s Encrypt - und Platz für ein umfangreicheres Software-Paket (letsencrypt-auto), das u.a. eine komplette virtuelle Python-Umgebung mit sich schleppt:

cd /usr/local
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto --help

letsencrypt-auto akzeptiert dann denselben Input wie letsencrypt.

Zertifikat erstellen lassen

letsencrypt bietet eine ncurses-Oberfläche, die es ermöglicht, auf einige Kommandozeilen-Parameter zu verzichten und ggf. notwendige Abfragen im Dialog zu beantworten. Dazu gehört beim ersten Start u.a. die Angabe einer E-Mail-Adresse für eine mögliche Kontaktaufnahme und die Bestätigung der AGB, die erforderlich ist. Danach erstellt letsencrypt automatisch einen Account samt Schlüsselpaar, so dass weitere Aufrufe in der Regel ohne Interaktion ablaufen können.

Alle Daten werden standardmäßig unter /etc/letsencrypt/ abgelegt.

Der folgende Aufruf fordert ein Zertifikat für die Hostnamen domain.example und www.domain.example an, deren Dateien auf der Platte im Verzeichnis /var/www/domain.example (Webroot) liegen:

letsencrypt certonly --webroot -w /var/www/domain.example/ -d domain.example -d www.domain.example

Falls notwendig, werden Mailadresse und Zustimmung zu den AGB (“Terms of Service”, “TOS”) abgefragt und ein privater Schlüssel (bzw. das Schlüsselpaar) erstellt. Dann wird der CSR an Let’s Encrypt geschickt, temporär eine unter http://domain.example/ abrufbare Datei im Webroot erstellt und so geprüft, dass man wirklich die Kontrolle über diesen Hostnamen hat, das Zertifikat erstellt, unter /etc/letsencrypt/archive/domain.example/ gespeichert und ein Symlink von /etc/letsencrypt/live/domain.example/ nach dort erstellt.

Soll das Zertifikat für weitere Hostnamen gelten, können beliebig viele Folgen von -w webroot -d hostname angeschlossen werden. Es folgt jeweils auf das -w webroot die Angabe der Hostnames, die zu diesem Webroot gehören.

Zertifikat beim Apache einbinden

Eine minimale Konfiguration für den virtual host könnte im Apache 2.4 (Debian Jessie) so aussehen:

<VirtualHost *:443>
    ServerName domain.example
    ServerAlias www.domain.example

    DocumentRoot /var/www/domain.example

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/domain.example/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/domain.example/privkey.pem
</VirtualHost>

Der Apache 2.2, der mit Debian Wheezy ausgeliefert wird, muss Zertifikat und Zwischenzertifikat der CA getrennt ausliefern:

<VirtualHost *:443>
    [...]
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/domain.example/cert.pem
    SSLCertificateChainFile /etc/letsencrypt/live/domain.example/chain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/domain.example/privkey.pem
</VirtualHost>

Zertifikate erneuern

Folgender Cronjob prüft täglich um 4 Uhr morgens, ob ein Zertifikat erneuert werden muss, und nimmt diese Erneuerung automatisch vor, wenn sich der Ablaufzeitpunkt nähert:

00 4 * * * letsencrypt renew --keep-until-expiring

Weiterer Lesestoff

Let’s Encrypt: Getting Started
Wouter Verhelst im WEBlog — Wouter’s Eclectic Blog: Playing with Letsencrypt
Matthias Gutjahr im Sperrobjekt Weblog: Let’s Encrypt-Zertifikate manuell erzeugen
Dirk Deimeke in Dirks Logbuch: Let’s Encrypt …

Debian 8.0 "Jessie" released

nospam@example.com (Thomas Hochstein) — Mon, 27 Apr 2015 20:15:41 +0000

Am Wochenende wurde, wie angekündigt, nach knapp zwei Jahren Entwicklungszeit die aktuelle stabile Version 8.0 der GNU/Linux-Distribution Debian mit dem Codenamen Jessie veröffentlicht. Voraussichtlich wird die bisherigen Version Wheezy wiederum im Rahmen des LTS-Projekts noch weitere drei Jahre mit Sicherheitsupdates versorgt werden.

Mehr dazu bei:

Mario
Dirk

Netz - Rettung - Recht (Artikel mit Tag debian)

Von Debian Stretch zu Buster - Teil 2

Notwendige Änderungen / Caveats

Notwendige Änderungen an Konfigurationsdateien

Von Debian Stretch zu Buster

Hinweise zu bestimmten Softwarepaketen

logrotate nicht mehr als Cronjob, sondern als systemd-Timer

Änderungen an Konfigurationsdateien

Umstellung von PHP 7.0 auf PHP 7.3

Zusammenfassung

Von Jessie zu Stretch - erneut

Konkrete Einzelfallprobleme

Änderungen an Konfigurationsdateien

Änderungen für bestimmte Softwarepakete

Neue Software und geänderte Defaults

Umstellung von PHP 5 auf PHP 7

Zusammenfassung

Der Injection-Date:-Header

Implementation von RFC 5536

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

X-NNTP-Posting-Date

phpMyAdmin nur für einen vhost einbinden

Von Jessie zu Stretch

Konkrete Einzelfallprobleme

Änderungen für bestimmte Softwarepakete

Neue Software und geänderte Defaults

Zusammenfassung

Webserver-Tuning

Apache Event-MPM

FPM-Konfiguration

Erfahrungswerte

systemd-Unit für srsd unter Debian

SPF und DKIM

SRS

systemd unit file für srds

Was meint die werte Leserschaft?

Verzögerungen beim SSH-Login

letsencrypt jenseits des Webservers

Erhalt des Zertifikats

Installation des Zertifikats

Dovecot

Exim

INN

Zertifikat-Updates

Exim

INN

Und ihr?

Von Wheezy zu Jessie

PHP-FPM - jetzt mit mod_proxy_fcgi

PHP-FPM und mod_proxy_fcgi installieren

mod_proxy_fcgi für PHP-FPM konfigurieren

Pools für einzelne Benutzer einrichten

Die Installation testen

PHP-FPM mit Debian Jessie

Die Welt dynamischer Webseiten

Scriptsprachen

Rechteprobleme

suexec und suphp

PHP-FPM

PHP-FPM installieren

FastCGI für PHP-FPM konfigurieren

Pools für einzelne Benutzer einrichten

Die Installation testen

Weiterer Lesestoff

SSL/TLS mit Let's Encrypt

Let’s Encrypt - die Prinzipien

Let’s Encrypt und der Apache-Webserver unter Debian Jessie

Installation

Zertifikat erstellen lassen

Zertifikat beim Apache einbinden

Zertifikate erneuern

Weiterer Lesestoff

Debian 8.0 "Jessie" released

PHP-FPM und `mod_proxy_fcgi` installieren

`mod_proxy_fcgi` für PHP-FPM konfigurieren