Wie neulich im Artikel Wildes Let’s Encrypt erwähnt ist es möglich automatisiert Let’s Encrypt Wildcard Zertifikate zu erstellen und verlängern zu lassen. Nur was macht man damit? Es folgt ein Beispiel aus dem Bereich Mass Virtual Hosting.Eine Möglichkeit wäre dies für einen Test-Webserver zu verwenden. Ich habe öfters mal die Anforderung, dass für eine Teststellung für einen Kunden eine weitere Testdomain benötigt wird. Diese haben allesamt die Form „<projektname>.test.gehirn-mag.net“ – ein Beispiel auf meine Blogdomain umgeschrieben. Das gibt es zumindest hier nicht wirklich 😉
Also wie läuft das ab? Die Entwickler melden sich bei mir als Webadmin „Du, wir brauchen eine neue Testdomain wdd“. Also verbinde ich mit via ssh auf den Server, kopiere eine vorhandene vhost-Konfig von apache und passe die entsprechenden Werte an. Zu viel Handarbeit? Ok, ggf. hat man ja eine Orchestrierung wie ansible oder der gleichen am laufen die einem die Handarbeit abnimmt. Aber was tut die? Die kopiert die apache vhost Konfig aus einer Vorlage und passt die entsprechenden Werte an… Ihr seht schon, der gleiche Text. Auch wenn die Werkzeuge anders sind. Und wer räumt hinterher wieder auf? Der Entwickler der meldet er braucht diese Testinstanz nicht mehr? Die Realität ist hier oftmals eine andere.
Dabei hat apache alles was man für eine praktikable Lösung braucht bereits mit an Bord dabei: Dynamically Configured Mass Virtual Hosting. Zusammengefasst wird nur noch ein einziger vhost angelegt der über den Hostnamen das passende DocumentRoot ermittelt. Damit das funktioniert muss im apache das Modul vhost_alias aktiviert werden (z.B. bei Debian/Ubuntu mit a2enmod vhost_alias). Und das ganze funktioniert sogar mit einem Wildcard Zertifikat wie das oben erwähnte Let’s Encrypt. Und so sieht die Konfiguration aus:
<VirtualHost *:443>
ServerName test.gehirn-mag.net
ServerAlias *.test.gehirn-mag.net
SSLEngine on
SSLCertificateFile /etc/letsencrypt/live/test.gehirn-mag.net/fullchain.pem
SSLCertificateKeyFile /etc/letsencrypt/live/test.gehirn-mag.net/privkey.pem
UseCanonicalName Off
VirtualDocumentRoot /var/www/vhosts/%0
LogFormat "%V:%p %h %l %u %t \"%r\" %>s %O \"%{Referer}i\" \"%{User-Agent}i\"" virtual_vhost_combined
ErrorLog ${APACHE_LOG_DIR}/error.log
CustomLog ${APACHE_LOG_DIR}/access.log virtual_vhost_combined
</VirtualHost>
Das ist nur ein Auszug in dem aber bereits alles wesentliche enthalten ist. Die Daten für das Beispiel wdd müssten also im Verzeichnis /var/www/vhosts/wdd.test.gehirn-mag.net liegen. Wer das nicht mag kann anstatt %0 im VirtualDocumentRoot auch auf %1 wechseln und den Pfad etwas anpassen um z.B. folgende Struktur zu erreichen: /var/www/vhosts/test.gehirn-mag.net/wdd. foobar wäre nach dieser Logik dann unterhalb von /var/www/vhosts/test.gehirn-mag.net/foobar zu suchen. Weitere Bespiele wie das mit den %-Zahlen funktioniert finden sich in der verlinkten Doku.
Ein Tipp noch zuletzt: Da alle Logdaten, egal von welcher Domain in einer Logdatei landen und diese im Standard vhost_combined Format mit „test.gehirn-mag.net“ aufgeschrieben werden, empfiehlt es sich hier das Format etwas anzupassen. Also einfach aus dem vordefinierten %v ein %V machen und das war es. Details zum apache Logformat? Die gibt es hier: http://httpd.apache.org/docs/current/mod/mod_log_config.html.
Und was bringt das ganze? Neuer vhost gefällig? Einfach einen neuen, leeren Ordner anlegen. Ein alter vhost soll weg? Einfach den Ordner löschen. Mit den passenden Rechten im Dateisystem versehen kann das der Webentwickler auch ohne mich als Admin. Die apache Konfig bleibt stets unverändert. Wieder mal die Welt gerettet. Mit „Dynamically Configured Mass Virtual Hosting“. Und künftig muss ich als fauler Admin auch gar nichts mehr dafür tun 😛