61. pepsi-setup

Richtet Datenbank, Signierschlüssel und DNS für eine Installation ein.

61.1. Rolle

pepsi-setup ist das administrative Bootstrap-Werkzeug. In einem Aufruf validiert es die Konfiguration, installiert das Schema, erzeugt Signierschlüssel und gibt die zu veröffentlichenden DNS-Einträge aus; ein separates check verifiziert Live-DNS. Referenzen: pepsi-setup(1) / pepsi.conf(5).

61.2. Funktionen

  • Konfigurationsvalidierung. Parst [pepsi], [pepsi-ingress] und die [stage-*]-Pipeline; prüft, dass [stage-init] existiert, dass jedes NEXT_STAGE/BOUNCE_STAGE auflöst, dass die Programmkonfiguration jeder Stage (einschließlich Smarthost-Routing) geparst werden kann und dass Domains und PUBLIC_IP-Werte wohlgeformt sind. Bei einem Fehler ändert es nichts und beendet sich mit einem Wert ungleich null.

  • TLS-Zertifikat-Einrichtung. Für jeden TLS-terminierenden Listener-/Zertifikatsabschnitt ohne TLS_CERT/TLS_KEY füllt es das Standard-certbot-Pfad-Layout aus (schreibt die Konfigurationsdatei an Ort und Stelle um, Kommentare erhalten) und führt dann certbot certonly --standalone aus, um jedes noch nicht auf der Festplatte vorhandene Zertifikat zu beziehen (oder eines zu erweitern, das nicht mehr jeden Namen abdeckt). Übergeben Sie --no-certbot, um den certbot-Aufruf zu überspringen und Zertifikate selbst zu verwalten. Ein fehlendes Zertifikat, das nicht bezogen werden kann, wird zurückgestellt, nicht als fatal behandelt: Der Rest des Laufs wird fortgesetzt, und die Zusammenfassung am Ende des Laufs nennt, was noch zu tun ist.

  • Einrichtung des TLS-Zugriffs. Die Server laufen unter unprivilegierten Benutzern, während certbot /etc/letsencrypt nur für root lesbar hält. Unter systemd schreibt pepsi-setup pro Unit ein LoadCredential=-Drop-in, sodass systemd jedes Zertifikat und jeden Schlüssel beim Start der Unit als root liest und dem Dienst eine private Kopie übergibt — die Dateirechte spielen dann überhaupt keine Rolle. Zusätzlich vergibt es POSIX-ACLs und installiert einen certbot-Deploy-Hook (der die Rechte erneut vergibt und die Server neu startet, damit ein erneuertes Zertifikat auch wirklich ausgeliefert wird), und schließlich überprüft es — indem es zum Dienstbenutzer wird und die Datei öffnet —, dass alles Übrige tatsächlich lesbar ist.

  • Schema-Installation. Der einzige Installer des einzigen pepsi-Schemas: wendet die nummerierte Patch-Serie und die neu erstellbaren Prozeduren aus SQL_DIR an; idempotent und wiederholbar. Er hält per Inhalts-Hash fest, was er angewendet hat, sodass jedes Programm ein Schema aus einem anderen Release zurückweisen kann, und weigert sich selbst, über ein neueres Schema zu installieren (siehe Upgrade). run --reset verwirft das Schema und erstellt es neu (zerstört eingereihte Mail; Schlüssel auf der Festplatte bleiben erhalten).

  • Schlüsselerzeugung. Für jede Domain, für die Pepsi autoritativ ist — die Vereinigung von ACCEPTED_DOMAINS, der SERVER_NAME/POSTMASTER-Domain jeder Stage, jeder explizit angegebenen SIGNING_DOMAIN, SRS_DOMAIN oder festen RESPONSE_FROM sowie ARC_DOMAIN — erstellt es einen RSA-2048- und einen Ed25519-DKIM-Schlüssel (RFC 8463) unter KEY_DIR (Modus 0600 in 0700-Verzeichnissen), falls nicht vorhanden; bestehende Schlüssel werden nie überschrieben.

  • Ausgabe der DNS-Einträge. Gibt im BIND-Zonenformat die öffentlichen DKIM-Schlüssel (<selector>._domainkey und <selector>-ed25519._domainkey), eine aus dem PUBLIC_IP jeder Relay-Stage (vereinigt) gebaute SPF-Richtlinie, einen DMARC-Vorschlag, wo keiner veröffentlicht ist, einen MTA-STS-_mta-sts-TXT-Eintrag (RFC 8461), einen TLSRPT-Eintrag, wenn [pepsi-tlsrpt] RUA gesetzt ist, sowie DANE/TLSA-Einträge für die TLS-Listener aus. Bereits mit dem richtigen Wert veröffentlichte Einträge werden weggelassen. Die Richtliniendatei selbst wird von pepsi-httpd bereitgestellt, nicht ausgegeben. Lange RSA-Einträge werden in mehrere Zeichenketten aufgeteilt. Derselbe SPF-Eintrag wird für jede bediente Domain vorgeschlagen; die Ausgabe weist darauf hin, dass besondere Multi-Host-Konstellationen eine engere, dennoch korrekte domainspezifische Gruppierung bevorzugen könnten, die pepsi-setup nicht automatisch berechnet.

  • Live-DNS-Verifikation (check): fragt DNS ab und berichtet pro Domain, ob der veröffentlichte DKIM-p= mit dem lokalen Schlüssel übereinstimmt, der SPF-Eintrag jede PUBLIC_IP auflistet, der DMARC-Eintrag gültig ist und der _mta-sts-TXT vorhanden und parsbar ist; außerdem vergleicht es die MTA-STS-Richtlinie mit den aktuellen MX-Einträgen und mit dem, was tatsächlich ausgeliefert wird, und prüft, dass die SRS-Domain ihre Bounces empfangen kann. Rein informativ: Seine Befunde bestimmen nie den Exit-Status.

  • Setup-Assistent (--wizard): ein kurzes interaktives Interview, das eine vollständige, bereits validierte Konfigurationsdatei schreibt (in den --config-Pfad oder standardmäßig /etc/pepsi/pepsi.conf) und dann anbietet, das vollständige Setup auszuführen. Es importiert die Antworten eines vorherigen Laufs aus dem [pepsi-wizard]-Abschnitt der Datei; --force überschreibt eine Datei ohne einen solchen Abschnitt ohne Nachfrage.

Verwenden Sie pepsi-config, um die effektive Konfiguration zu inspizieren.

61.3. Kommandozeilenoptionen

Ein Lauf ohne Unterbefehl führt das vollständige Setup durch (dasselbe wie run). Die vollständigen Details stehen in pepsi-setup(1); die Optionen sind:

Unterbefehle:

  • run — validieren, TLS einrichten, Schema installieren, Schlüssel erzeugen, DNS ausgeben (die Standardaktion). -r/--reset verwirft zuerst das Schema und erstellt es neu (zerstört die gesamte eingereihte Mail; Schlüssel auf der Festplatte bleiben erhalten).

  • schema — installiert das Schema und die Rollenrechte oder führt ihr Upgrade durch, und sonst nichts; braucht nur [pepsi-postgres] und funktioniert daher auch mit der Konfigurationsdatei eines Telemetrie-Collectors. Weist ein neueres Schema zurück (Exit-Status 78). --backup-dir DIR sichert das Schema zuerst mit pg_dump, wenn es etwas zu aktualisieren gibt; --if-installed tut nichts bei einer Datenbank, die noch kein Schema hat. Dies führt eine Paketaktualisierung aus; siehe Upgrade.

  • check — Live-DNS abfragen und Abweichungen melden; nimmt keine Änderungen vor, und seine Befunde bestimmen nie den Exit-Status.

  • visualize — die [stage-*]-Pipeline als Graphviz-dot-Graph auf der Standardausgabe ausgeben (eine durchgezogene Kante je NEXT_STAGE, eine gestrichelte rote je BOUNCE_STAGE); leiten Sie sie nach dot -Tpng.

  • questions — das Einrichtungsinterview als JSON ausgeben: die Schritte, die Gestalt jeder Frage, ihren Standardwert, ihren Hilfetext und wann sie gestellt wird. Es ist das Modell, durch das sowohl der Terminal-Assistent als auch die Browser-Einrichtung beschrieben werden, und das Schema, gegen das eine --answers-Datei geschrieben wird.

  • apply — die privilegierte Einrichtungsarbeit ausführen, um die die Browser-Oberfläche gebeten hat, wobei die Absichtsdatensätze aus pepsi.setup_task gelesen werden. Wird normalerweise bei Bedarf von systemd gestartet. --once arbeitet das Anstehende ab und beendet sich; --idle SECS legt fest, wie lange es ohne Arbeit wartet, bevor es sich beendet; --clear löscht jeden eingereihten Datensatz, ohne einen einzigen davon auszuführen (schließt sich mit den beiden anderen gegenseitig aus).

  • bootstrap — das einmalige Bearer-Token prägen und ausgeben, das das erste Administratorkonto anlegt (--valid-for SECS, --admin-url URL).

  • import [MTA] — berichten, was von einem vorhandenen MTA (postfix, exim, sendmail, qmail, stalwart) migriert würde, ohne etwas zu schreiben; --root liest unterhalb eines anderen Verzeichnisses, --out schreibt den Bericht und die umgewandelten Map-Dateien, --alias-style wählt, wie bloße Aliasnamen qualifiziert werden.

Optionen, die alle vor dem Unterbefehl stehen:

  • --no-certbot — certbot nicht für fehlende TLS-Zertifikate aufrufen; sie werden stattdessen zurückgestellt (siehe TLS-Zertifikat-Einrichtung oben).

  • --no-reverse-proxy — sich nicht automatisch in einen vorhandenen vorgelagerten HTTP-Server integrieren; pepsi-httpd bindet 443 direkt.

  • -y/--yes-to-all, -n/--no-to-all — jedes interaktive Angebot gleich beantworten, sodass die Einrichtung nie auf Eingaben wartet.

  • --wizard — den interaktiven Konfigurationsassistenten ausführen (setzt keine vorhandene Konfigurationsdatei voraus); --force überschreibt eine nicht importierbare Datei ohne Nachfrage. Dazu: --expert SPEC fragt auch die tiefergehenden Optionen ab (--expert=help listet sie auf), --import MTA / --no-import / --import-root DIR steuern die Migration der Einstellungen eines vorhandenen MTA, und --answers FILE beantwortet jede Frage aus JSON, statt sie zu stellen.

  • -c/--config FILE, -L/--log LEVEL, -v/--verbose, -h/--help, -V/--version — die von allen Pepsi-Werkzeugen gemeinsam genutzten Optionen.

61.4. Konfiguration

Liest den gemeinsamen Abschnitt [pepsi] (KEY_DIR, DKIM_SELECTOR, DKIM_ALGORITHMS, ARC_DOMAIN, ARC_ALGORITHM, ORIGINATE_SUCCESS_DSN, MTA_STS_MODE, MTA_STS_MAX_AGE), [pepsi-postgres] (CONFIG, SQL_DIR), [pepsi-ingress] (HOSTNAME, ACCEPTED_DOMAINS) und die [stage-*]-Abschnitte — einschließlich der PUBLIC_IP jeder Relay-Stage (gesammelt nach PROGRAM). Vollständige Referenz: pepsi.conf(5).

61.5. Siehe auch

Installation, Konfiguration, pepsi-setup(1), pepsi.conf(5).