Netz - Rettung - Recht (Artikel mit Tag jessie)

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 jessie)

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