Installation

Die Zeile

Auf der Maschine, als root oder mit sudo-Rechten:

curl -fsSLo postdog-install.sh https://download.postdog.de/install/<zugang> && bash postdog-install.sh

<zugang> ist dein Zugang aus der Bestellung, zum Beispiel 1042-1. Das geladene Skript kennt ihn schon.

Das Skript lädt nichts nach, das es dann ausführt, und ist zum Lesen gedacht. Wenn du erst sehen willst, was es tut:

less postdog-install.sh
bash postdog-install.sh --dry-run

--dry-run zeigt jeden Schritt und ändert nichts.

Die Fragen

Alle Fragen kommen am Anfang. Danach läuft das Skript ohne Rückfrage durch.

1. Das Geheimnis zu deinem Zugang. Es wird nicht angezeigt und nur einmal gefragt – es gilt für die Registry und für die Lizenz.

2. Deine Domain, zum Beispiel kunde.de. Daraus werden postdog.kunde.de, mail.kunde.de und meet.kunde.de.

3. Die Bestätigung. Das Skript zeigt Oberfläche, Mailserver, Besprechungen, Webserver, Image und Verzeichnis:

   So einrichten? [J/n/ändern]

   J oder Enter richtet ein, n bricht ab, ohne etwas verändert zu haben, ändern fragt die drei Namen einzeln.

Was danach passiert

Schritt	Was das Skript tut
Voraussetzungen	prüft root und die Paketverwaltung
Ports	erkennt Apache oder nginx auf 80/443 und prüft die Mail-Ports
Release prüfen	holt das aktuelle Release über https, prüft die Unterschrift mit openssl, nimmt nur ein veröffentlichtes Release
Zugang	holt die Lizenz mit deinem Zugang
Docker	installiert Docker und docker compose, falls sie fehlen
Volumes anlegen	legt die fünf Volumes an, vorhandene bleiben unberührt
Konfiguration ablegen	schreibt /opt/postdog/.env (Rechte 0600)
Image holen	meldet sich bei der Registry an und holt das Image nach Digest
compose-Datei	legt /opt/postdog/docker-compose.yml aus dem Image ab
Einrichten	prüft im Container die Lizenz und erzeugt einmalig die Geheimnisse
Starten	docker compose up -d, wartet bis zu fünf Minuten auf den Health-Check
In Apache/nginx einbinden	nur hinter einem Webserver, siehe Hinter Apache oder nginx

Das Image wird nach Digest geholt, also genau das, was im unterschriebenen Release steht. Docker rechnet den Digest beim Holen selbst nach.

Was in der .env steht

POSTDOG_IMAGE=…            das Image, nach Digest
POSTDOG_LICENSE=…          dein Lizenzschlüssel
POSTDOG_HOST=postdog.kunde.de
POSTDOG_MAILHOST=mail.kunde.de
POSTDOG_MEET_HOST=meet.kunde.de
POSTDOG_LICENSE_STRICT=true
…

Kennwörter und Keystore stehen nicht in der .env, sondern im Volume postdog-secrets. Die Datei verweist nur auf sie (…_FILE=/run/secrets/…).

Hinter einem Webserver kommen POSTDOG_BEHIND_PROXY und die POSTDOG_BIND_<port>-Zeilen dazu, ebenso für jeden belegten Mail-Port.

Die Geheimnisse

Beim ersten Lauf entstehen im Volume postdog-secrets der Keystore, das Datenbank-Kennwort und – mit dem Paket meet – das Geheimnis für den Besprechungsdienst. Eine vorhandene Datei wird nie überschrieben.

Bei jedem Start prüft der Container nur, ob sie da sind. Er legt dabei keine neuen an.

Wenn es fertig ist

Am Ende zeigt das Skript die Adressen und was noch von Hand zu tun ist:

• DNS: die drei Namen auf die Maschine zeigen lassen, siehe DNS-Einträge.
• Zertifikat: Hinter Apache oder nginx holt das Skript es selbst. Läuft POSTDOG direkt auf 80/443, holt das Skript noch keines – Apache im Container erwartet es im Volume postdog-certs unter live/<postdog-name>/.
• Den ersten Zugang anlegen. Er bekommt ein Einmalkennwort per Mail. Ein Werkzeug dafür bringt das Image noch nicht mit – melde dich dafür bei POSTDOG.
• Sichern: genau drei Volumes, siehe Sichern und Wiederherstellen.

In /opt/postdog/einrichtung.txt steht, was eingerichtet wurde: Kunde, Pakete, Band, Dienste, Zustand der Lizenz.

Optionen

Option	Bedeutung
--dry-run	zeigt, was passieren würde, ändert nichts
--yes, -y	keine Bestätigung
--dir <pfad>	Installationsverzeichnis, Vorgabe /opt/postdog
--behind <server>	apache, nginx oder none; Vorgabe: erkannt an Port 443
--host <name>	Name der Oberfläche
--mailhost <name>	Name des Mailservers
--meethost <name>	Name für Besprechungen
--pull-user <zugang>	der Zugang; in der geladenen Zeile schon gesetzt
--pull-secret <datei>	Datei mit dem Geheimnis, statt es einzutippen
--license <schlüssel>	Lizenzschlüssel; ohne ihn wird er mit dem Zugang geholt
--release <datei|url>	ein anderes Release-Manifest
--no-release	Release nicht prüfen
--image <ref>	ein anderes Image als das aus dem Release
--help, -h	Hilfe

--host und --mailhost zusammen ersetzen die Frage nach der Domain.

Ohne Rückfragen

Für eine Installation ohne Eingaben legst du das Geheimnis in eine Datei – eine Zeile, sonst nichts, Rechte 600, Eigentümer root:

( umask 077 && read -rsp 'Geheimnis: ' s && printf '%s\n' "$s" > /root/postdog.pull )
bash postdog-install.sh --host postdog.kunde.de --mailhost mail.kunde.de \
     --meethost meet.kunde.de --pull-secret /root/postdog.pull --yes

Als Datei und nicht als Angabe, weil eine Kommandozeile in der Prozessliste und in der Shell-Historie landet.

--no-release und --image

Beide schalten die Prüfung gegen das unterschriebene Release ab. Das Skript sagt das in Rot. Nimm sie nur, wenn POSTDOG dich darum bittet.

Ein zweiter Lauf

Das Skript darf mehrfach laufen. Vorhandene Volumes, .env, docker-compose.yml und Geheimnisse bleiben, wie sie sind. Was das für Updates heißt, steht unter Updates.

Vorher stoppen

Stoppe POSTDOG, bevor du das Skript ein zweites Mal startest:

cd /opt/postdog && docker compose down

Sonst hält der laufende Container die Ports, und das Skript hält sie für belegt: hinter einem Webserver nimmt es einen anderen lokalen Port als in der .env, direkt auf 80/443 erkennt es den Apache im Container als Webserver des Hosts. down ohne -v lässt alle Daten stehen.