install/mailsystem
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Add selective Postfix SRS installation and management

Browse Source
This commit is contained in:
chris
2026-10-25 22:20:12 +01:00
parent e732e6d9d8
commit efaa58fcf9
28 changed files with 2325 additions and 202 deletions
Download Patch File Download Diff File Expand all files Collapse all files
README-install-SRS.md
+221
View File
@@ -0,0 +1,221 @@
# Selektives SRS – Installation und Betrieb
**Stand:** 23. Oktober 2026
**Geltungsbereich:** Aktuelle Skripte dieses Repositories; Debian 13/Postfix
**Status:** Erfolgreicher End-to-End-Test auf `e.mx.oopen.de`; Fehlerfalltests offen
Siehe auch [README-SRS.md](README-SRS.md) fuer Architektur,
Abhaengigkeiten und bewusst akzeptierte Grenzen.
## 1. Voraussetzungen
Die regulaere Postfix-Installation muss funktionsfaehig sein. Virtuelle
Alias-Weiterleitungen und AmaViS-Reinjektion muessen bekannt und getestet
sein. Die SRS-Domain braucht passende oeffentlich aufloesbare DNS-Eintraege.
Die Installationspruefung kontrolliert die autoritativen Nameserver sowie
SPF und MX im vorgesehenen Setup.
Die Hostkonfiguration liegt in `conf/srs.conf`; als Ausgangspunkt dient
`conf/srs.conf.sample`. Beim Aufruf wird die gewaehlte SRS-Domain angezeigt
und bestaetigt. Fuer den Testserver wurde `srs.e.mx.oopen.de` verwendet;
diese Domain ist **kein** universeller Standard fuer andere Hosts.
Die Skripte werden in diesem Repository als `root` ausgefuehrt. Vor
Installation oder Aktivierung Backups und einen Wartungs-/Rueckbauplan
bereithalten. Keines der Skripte ersetzt die Kontrolle des Mailflusses.
## 2. Lesende Installationspruefung
```bash
cd /usr/local/src/mailsystem || exit 1
./install-update-srs.sh --help
./install-update-srs.sh --check
```
`--check` fragt nach der SRS-Domain, prueft Voraussetzungen und inventarisiert
die Installation, ohne den Zustand des Systems zu veraendern. Fehlende
DNS-Konfiguration zuerst korrigieren, nicht die Vorpruefung umgehen.
## 3. Installation oder Update
```bash
cd /usr/local/src/mailsystem || exit 1
./install-update-srs.sh --install
```
Standardversion: PostSRSd `2.4.1`. Fuer eine andere Version steht
`--version X.Y.Z` zur Verfuegung. Der Ablauf enthaelt eine Bestaetigung
fuer die Vorbereitung und eine gesonderte Bestaetigung fuer die Installation
der vorbereiteten Dateien. Unter anderem werden PostSRSd gebaut, die
Upstream-Tests ausgefuehrt, Dateien und Dienste vorbereitet und ein Backup
angelegt. Aktive SRS-Integration verhindert laut Installer-Logik ein Update.
**Wichtig:** `--install` aktiviert **nicht** die selektive SRS-Verarbeitung
im regulaeren Postfix und startet die SRS-Dienste nicht. Die Anzeige des
Backup-Pfads ist aufzubewahren. Das SRS-Secret bei Updates unveraendert
erhalten, damit fruehere SRS-Adressen ueberpruefbar bleiben.
## 4. Selektives SRS aktivieren
```bash
cd /usr/local/src/mailsystem || exit 1
./activate-srs.sh
```
Das Skript prueft die Installation, Laufzeitdienste, Ports und den bisherigen
Postfix-Zustand. Bei `DISABLED` zeigt es eine Zusammenfassung und fordert
eine ausdrueckliche Bestaetigung. Erst danach werden Sicherungen erstellt,
die verwalteten Konfigurationsbloecke eingesetzt, Dienste gestartet und
Postfix neu geladen. Bei inkonsistentem Zustand nicht manuell fortfahren,
sondern Ursache klaeren.
### Kontrolle nach Aktivierung
```bash
systemctl is-active postfix.service
systemctl is-active postsrsd-srs.service srs-reverse-map.service postfix@srs-delivery.service
postconf -h default_transport
postconf -M srs-forward/unix
postqueue -j
postqueue -c /etc/postfix-srs/delivery -j
```
Der aktivierte Transport ist `srs-forward`. Die SRS-Delivery-Instanz ist
gesondert zu kontrollieren. Ein erfolgreicher Service-Start beweist noch
keine erfolgreiche externe Weiterleitung: Eine reale Testnachricht an eine
virtuelle Alias-Adresse mit externem Ziel ist erforderlich. Im Journal
sollten die PostSRSd-Umschreibung, die Reinjektion in die zweite Instanz
und die SMTP-Uebergabe an den naechsten Mailserver nachvollziehbar sein.
## 5. Zweiphasig deaktivieren
```bash
cd /usr/local/src/mailsystem || exit 1
./deactivate-srs.sh
```
Die Deaktivierung ist interaktiv und prueft vor der Bestaetigung, dass
der Zustand `ENABLED` konsistent und die SRS-Delivery-Queue **leer** ist.
Nach Bestaetigung:
1. Urspruengliche `main.cf`-Parameter und Empfangseinstellungen
wiederherstellen; `srs-forward` zunaechst in `master.cf` belassen;
alten Queue-Manager erfassen und Postfix neu laden.
2. Auf Beendigung des alten Queue-Managers und erkennbarer
`srs-forward`-Arbeit sowie auf leere SRS-Delivery-Queue warten
(maximal 180 Sekunden).
3. Pipe-Dienst und systemd-Abhaengigkeiten entfernen; erneut pruefen
und laden; Queue erneut pruefen; alle drei SRS-Dienste stoppen und
deaktivieren; Endzustand verifizieren.
Wenn beim Start bereits Nachrichten in der SRS-Delivery-Queue stehen,
verweigert das Skript die Deaktivierung. Wird die Queue waehrend der
Umschaltung nicht leer oder kann nicht gelesen werden, fuehrt das zu
Abbruch und einem **versuchten** Rollback. Wartende Mails werden nicht
absichtlich geloescht.
Die Installation, Binaries und `/etc/postfix-srs/state.conf` bleiben
nach erfolgreicher Deaktivierung fuer eine spaetere Aktivierung erhalten.
**Verspaetete SRS-Ruecklaeufer:** Nach vollstaendiger Deaktivierung koennen
spaet eintreffende Bounces an SRS-Adressen nicht mehr wie im aktiven Betrieb
verarbeitet werden. Das ist eine bewusste Projektentscheidung; ein
Reverse-only-Modus ist nicht vorgesehen. Der normale Postfix-Betrieb hat
Vorrang. Details: [README-SRS.md](README-SRS.md).
### Kontrolle nach Deaktivierung
```bash
systemctl is-active postfix.service
systemctl is-active postsrsd-srs.service srs-reverse-map.service postfix@srs-delivery.service
systemctl is-enabled postsrsd-srs.service srs-reverse-map.service postfix@srs-delivery.service
postconf -h default_transport
postconf -M srs-forward/unix 2>/dev/null || true
postqueue -j
```
Alle SRS-Dienste sollen `inactive` und `disabled` sein; der Pipe-Dienst
soll fehlen. Auf dem Testserver war `default_transport` danach wieder
`smtp` (impliziter Standard). Die urspruenglichen, nicht explizit gesetzten
Parameter sind nicht mehr Teil der lokalen `main.cf`.
**Keine vermeintliche Null-Queue erzwingen:** Bei gestoppter zweiter Instanz
kann `postqueue -c ... -j` mit einer `showq`-Warnung scheitern. Das
Kommando nicht blind mit `wc -l` zu einem angeblichen Erfolg zusammenfassen.
Der sichere Leerstand wird waehrend der Deaktivierung bei laufender Instanz
geprueft. Bei Bedarf die Queue-Dateien offline und mit Bedacht inspizieren.
### Wichtiger Funktionstest nach der Deaktivierung
Eine Nachricht erneut an dieselbe externe virtuelle Alias-Weiterleitung
senden. Im Mail-Log muss der regulaere `postfix/smtp`-Transport und der
urspruengliche Envelope-Absender sichtbar sein. Auch eine lokale
Zustellung sollte unveraendert funktionieren. Die erfolgreiche SMTP-Uebergabe
an den naechsten Mailserver ist noch kein Beweis fuer den Postfacheingang.
## 6. Log- und Queue-Diagnose
```bash
journalctl --since "15 minutes ago" --no-pager | grep -Ei 'srs-forward|postfix-srs-delivery|postsrsd|SRS0='
postqueue -j
# Nur waehrend die zweite Instanz laeuft:
postqueue -c /etc/postfix-srs/delivery -j
```
Bei Fehlern keine Dateien aus der SRS-Queue entfernen, um die Deaktivierung
zu erzwingen. Zuerst Ursache und enthaltene Nachrichten klaeren. Die
Backup-Verzeichnisse unter `/root/postfix-srs-activation-*` bzw.
`/root/postfix-srs-deactivation-*` zusammen mit den Journalmeldungen sichern.
## 7. Getesteter Stand und ausstehende Pruefungen
Am **23. Oktober 2026** auf `e.mx.oopen.de` erfolgreich getestet:
Installationsvorpruefung, Installation mit Upstream-CTest, Aktivierung,
eine echte externe Alias-Weiterleitung mit SRS, zweiphasige Deaktivierung,
anschliessend dieselbe Weiterleitung ohne SRS. Beide Postfix-Queues waren
zum Zeitpunkt der abschliessenden Kontrolle leer.
**Noch nicht praktisch nachgewiesen:** Ein absichtlich ausgeloester
Fehler mit vollstaendigem Rollback und die Deaktivierung unter
anhaltender Zustelllast. Die isolierten Mock-Tests ersetzen diese
Integrationstests nicht.
## 8. Historische Dokumentation
Die ausfuehrlichen Texte und frueheren Entwicklungsnotizen vom
20. Oktober 2026 verbleiben unveraendert in
[`archive/selective-srs-2026/`](archive/selective-srs-2026/).
Sie sind keine aktuelle Installationsanleitung.
## Oeffentlicher MX-Hostname und SRS-Domain
Der lokale Systemhostname (`hostname -f`) kann vom oeffentlichen
MX-Hostnamen abweichen.
Der Installer fragt deshalb den oeffentlichen MX-Hostnamen separat ab.
Als Vorgabe verwendet er `hostname -f`. Bei einer Erstinstallation wird
die SRS-Domain aus `srs.<MX-Hostname>` vorgeschlagen.
Beispiel fuer `mail.interventionistische-linke.org`:
_MX_HOST="mail.interventionistische-linke.org"
_SRS_DOMAIN="srs.mail.interventionistische-linke.org"
Beide Werte werden in `conf/srs.conf` gespeichert.
Bei einer bestehenden SRS-Konfiguration bleiben die bereits
konfigurierten Werte erhalten. Fehlt lediglich `_MX_HOST`, wird dieser
Parameter bei einem Wartungsupdate ergaenzt.
Erforderliche DNS-Eintraege fuer das Beispiel:
srs.mail.interventionistische-linke.org. IN MX 10 mail.interventionistische-linke.org.
srs.mail.interventionistische-linke.org. IN TXT "v=spf1 mx -all"
Der Installer prueft die oeffentlichen DNS-Eintraege ueber die
autoritativen Nameserver.
Mit `./install-update-srs.sh --check` kann die System- und
DNS-Vorpruefung ohne Aenderung der Installation ausgefuehrt werden.