Hinter Apache oder nginx

Läuft auf der Maschine schon ein Webserver – etwa weil dort auch die Website des Kunden liegt –, übernimmt POSTDOG die Ports 80 und 443 nicht, sondern geht dahinter. Das erledigt das Installationsskript selbst.

Wie das Skript entscheidet

Es sieht nach, wer auf 443 und 80 lauscht:

Ergebnis	Was passiert
beide frei	POSTDOG übernimmt 80 und 443 selbst
Apache (apache2/httpd)	POSTDOG geht hinter Apache
nginx	POSTDOG geht hinter nginx
etwas anderes	Abbruch – hinter diesem Server richtet sich POSTDOG nicht selbst ein

Mit --behind apache, --behind nginx oder --behind none gibst du es selbst vor.

Was es einrichtet

1. Ein lokaler Port. Der Container bekommt den ersten freien Port ab 127.0.0.1:8380. Er hört nur auf Loopback, von außen ist er nicht erreichbar. Im Container spricht Apache dann nur HTTP – TLS endet bei deinem Webserver.

2. Eine eigene vhost-Datei postdog.conf für postdog.<domain> und meet.<domain>:

   Webserver	Datei
   Apache (Debian/Ubuntu)	/etc/apache2/sites-available/postdog.conf, aktiviert mit a2ensite
   Apache (sonst)	/etc/httpd/conf.d/postdog.conf
   nginx (Debian/Ubuntu)	/etc/nginx/sites-available/postdog.conf, verlinkt nach sites-enabled
   nginx (sonst)	/etc/nginx/conf.d/postdog.conf

   Bei Apache schaltet es dazu die Module proxy, proxy_http, proxy_wstunnel, headers, rewrite und ssl ein.

3. Das Zertifikat von Let's Encrypt mit certbot im Webroot-Verfahren, für postdog.<domain> und meet.<domain>. Die Prüfdateien liegen unter /var/lib/postdog/acme. Fehlt certbot, wird er installiert.

4. Weiterleitung von HTTP auf HTTPS, sobald das Zertifikat da ist. WebSockets werden durchgereicht, bei nginx sind Uploads bis 110 MB erlaubt.

Andere Dateien deines Webservers fasst das Skript nicht an.

Die richtige Adresse

Ein vhost greift nur, wenn er auf derselben Adresse lauscht wie die anderen. Steht in deiner Konfiguration <VirtualHost 203.0.113.10:443> und POSTDOG schriebe *:443, würde Apache den POSTDOG-vhost nie auswählen.

Deshalb übernimmt das Skript die Adressform aus deinem laufenden Webserver:

• Apache: aus apachectl -S
• nginx: aus den listen-Zeilen in nginx -T

Findet es dort nichts, nimmt es *:80 und *:443.

Konfigurationstest und Rücknahme

Nach jedem Schreiben prüft das Skript die Konfiguration (apachectl -t bzw. nginx -t):

• Test bestanden: systemctl reload des Webservers.
• Test fehlgeschlagen: Es zeigt die letzten Zeilen der Fehlermeldung, nimmt postdog.conf wieder heraus und bricht ab. Dein Webserver läuft unverändert weiter.

Ohne Zertifikat

Zeigen die Namen noch nicht auf die Maschine, scheitert certbot. Das Skript bricht dann nicht ab: POSTDOG läuft vorerst über http://postdog.<domain>/. Sobald der DNS stimmt, startest du das Skript noch einmal – vorher docker compose down, siehe Ein zweiter Lauf.

Die Erneuerung übernimmt certbot selbst. Nach jeder Erneuerung lädt er deinen Webserver neu. Ob das klappt:

certbot renew --dry-run

Die eigene Datei

postdog.conf beginnt mit der Zeile

# POSTDOG - written by install.sh, overwritten on the next run

Bei jedem Lauf schreibt das Skript die Datei neu. Eigene Änderungen darin gehen also verloren.

Gibt es schon eine postdog.conf ohne diese Zeile, bricht das Skript ab, statt sie zu überschreiben. Benenne deine Datei dann um.

Kalender und der Name mail.

postdog.conf deckt postdog.<domain> und meet.<domain> ab, nicht mail.<domain>. Wie Mailprogramme den Kalender finden, steht unter DNS-Einträge.