Files

Ansible Servercow da81549161 add docs

2026-06-11 18:04:41 +02:00

28 KiB

Raw Blame History

Mail-Server-Verwaltung (Mailcow)

Übersicht

Diese Kategorie umfasst 13 spezialisierte Playbooks zur Verwaltung von Mailcow-basierten Mail-Servern. Mailcow ist eine containerisierte, Docker-basierte Mail-Server-Lösung.

Anwendungsfälle:

Mailcow-Updates und -Upgrades
Start/Stop von Mail-Services
Konfigurationsänderungen (SNI, Garbage Collector, Watchdog)
Migration zu zentralen Services (ClamAV, Syslog)
Health-Checks und Monitoring
Docker-Proxy-Konfiguration
Roundcube-Installation-Verwaltung
Mailbox-Zählung

Standard-Installationspfad: /opt/mailcow-dockerized

Playbooks

update-mailcow.yaml

Umfassende Mailcow-Update mit Snapshots, Versionsvergleich, Health-Checks und automatischem Cleanup.

Datei: playbooks/managed-mailcow/update-mailcow.yaml

Zweck: Vollautomatisches Mailcow-Update mit Pre-Checks, Snapshot-Erstellung, Versions-Management und Post-Update-Cleanup.

Ziel-Hosts: all

Benutzer: tincadmin (mit sudo-Rechten)

Verwendete Rollen:

managed-mailcow (find-mailcow-composedir, check-mailcow-install-status, get-mailcow-current-version, update-mailcow)
system (check-disk-utilization)
proxmox-automation (get-vmid, create-snapshots) - optional
docker (cleanup-all)

Wichtige Variablen:

Variable	Default	Beschreibung
`github_mailcow_ver`	`"2026-03b"`	Ziel-Mailcow-Version
`do_snapshots`	`true`	Erstellt Proxmox-Snapshots
`debug`	`true`	Debug-Ausgaben aktivieren
`load_vault`	`true`	Vault-Datei laden
`snapshot_name`	`"pre-mailcow-update-{{ github_mailcow_ver }}"`	Snapshot-Name

Verwendungsbeispiel:

# Vollständiges Update mit Snapshots
ansible-playbook playbooks/managed-mailcow/update-mailcow.yaml \
  -i inventories/extern.yml \
  -e "github_mailcow_ver=2026-04" \
  -K --ask-vault-pass

# Ohne Snapshots (nicht empfohlen)
ansible-playbook playbooks/managed-mailcow/update-mailcow.yaml \
  -i inventories/extern.yml \
  -e "do_snapshots=false" \
  -K

# Einzelner Mail-Server
ansible-playbook playbooks/managed-mailcow/update-mailcow.yaml \
  -i inventories/extern.yml \
  --limit mail.example.com \
  -e "github_mailcow_ver=2026-04" \
  -K --ask-vault-pass

Abhängigkeiten:

Vault-Datei (vault.yml) für Proxmox-Integration
Ausreichend Festplattenspeicher (mindestens 4 GB frei)
Proxmox-Umgebung (optional, für Snapshots)
Mailcow-Installation

Besonderheiten:

Komplexeste Logik aller Playbooks:
- Vergleicht GitHub-Version mit lokaler Version
- Erstellt Snapshot nur bei signifikanter Versions-Differenz
- Disk-Space-Check vor Update (mindestens 4 GB erforderlich)
- Automatisches Cleanup nach erfolgreichem Update
- Pre-Tasks für Vault-Laden
Intelligente Version-Prüfung: Überspringt Update wenn bereits aktuell
Rollback-fähig: Durch Proxmox-Snapshots

Workflow:

Pre-Task: Lädt Vault-Datei (wenn load_vault=true)
Findet Mailcow-Compose-Directory
Prüft Mailcow-Installationsstatus
Prüft Festplattenspeicher (mindestens 4 GB)
Ermittelt aktuelle Mailcow-Version
Vergleicht mit Ziel-Version
Überspringt Update wenn bereits aktuell
Abruft Proxmox VM-ID (wenn Snapshots aktiviert)
Erstellt Pre-Update-Snapshot
Führt Mailcow-Update durch (Git-Pull + Update-Script)
Wartet auf Abschluss
Führt Docker-Cleanup durch
Verifiziert neue Version

⚠️ Wichtig: Dieses Playbook kann lange laufen (10-30 Minuten je nach System). Planen Sie Wartungsfenster.

start-stop-mailcow.yaml

Start/Stop der kompletten Mailcow-Docker-Compose-Stack.

Datei: playbooks/managed-mailcow/start-stop-mailcow.yaml

Zweck: Kontrolliertes Herunterfahren und Hochfahren der gesamten Mailcow-Umgebung.

Ziel-Hosts: all

Benutzer: tincadmin (mit sudo-Rechten)

Verwendete Rollen:

managed-mailcow (find-mailcow-composedir, stop-mailcow, start-mailcow)

Wichtige Variablen:

Variable	Default	Beschreibung
`verbose`	`true`	Zeigt Docker-Compose-Output

Verwendungsbeispiel:

# Stop und Start aller Mailcow-Services
ansible-playbook playbooks/managed-mailcow/start-stop-mailcow.yaml \
  -i inventories/extern.yml \
  -K

# Ohne Debug-Output
ansible-playbook playbooks/managed-mailcow/start-stop-mailcow.yaml \
  -i inventories/extern.yml \
  -e "verbose=false" \
  -K

# Nur ein Server
ansible-playbook playbooks/managed-mailcow/start-stop-mailcow.yaml \
  -i inventories/extern.yml \
  --limit mail-01.example.com \
  -K

Abhängigkeiten:

Mailcow-Installation
Docker und Docker-Compose

Besonderheiten:

Sequenzielle Ausführung: Stop → Start
Sauberes Herunterfahren: Verwendet docker-compose down (nicht kill)
Wartezeit: Zwischen Stop und Start für vollständiges Shutdown
Verbose-Output: Zeigt alle Docker-Logs wenn aktiviert

Workflow:

Findet Mailcow-Directory
Stoppt alle Container mit docker-compose down
Wartet auf vollständiges Shutdown
Startet alle Container mit docker-compose up -d
Wartet auf Verfügbarkeit der Services

Anwendungsfälle:

Wartungsarbeiten
Konfigurationsänderungen die Neustart erfordern
Problembehebung
Host-Neustarts vorbereiten

check-mailcow-health.yml

Health-Checks von Mailcow-Instanzen (UI, SMTP, IMAP, Submission).

Datei: playbooks/managed-mailcow/check-mailcow-health.yml

Zweck: Überwachung der Erreichbarkeit und Funktionalität von Mailcow-Services von extern.

Ziel-Hosts: localhost

Benutzer: Lokal (keine Remote-Ausführung)

Verwendete Rollen: Keine (direkte Tasks)

Wichtige Variablen:

Variable	Beispielwert	Beschreibung
`hosts`	`["mail.ps.develcow.de", "mail.np.develcow.de"]`	Liste zu testender Mail-Server

Verwendungsbeispiel:

# Health-Check auf definierten Hosts
ansible-playbook playbooks/managed-mailcow/check-mailcow-health.yml

# Mit custom Hosts
ansible-playbook playbooks/managed-mailcow/check-mailcow-health.yml \
  -e '{"hosts": ["mail.example.com", "mail2.example.com"]}'

# Mit Verbose-Output
ansible-playbook playbooks/managed-mailcow/check-mailcow-health.yml -v

Abhängigkeiten:

Externe Erreichbarkeit der Mail-Server
Ports: 25, 587, 143, 993, 443

Besonderheiten:

Testet Weboberfläche: Sucht nach "showVersionModal" im HTML
Testet Mail-Ports:
- SMTP (Port 25)
- Submission (Port 587)
- IMAP (Port 143)
- IMAPS (Port 993)
ignore_errors: yes auf allen Tests - keine Unterbrechung bei Fehlern
Keine Timeouts als Fehler gewertet

Workflow:

Iteriert über Host-Liste
Für jeden Host:
- HTTP-Request zur Weboberfläche (Port 443)
- TCP-Verbindungstest zu SMTP (25)
- TCP-Verbindungstest zu Submission (587)
- TCP-Verbindungstest zu IMAP (143)
- TCP-Verbindungstest zu IMAPS (993)
Sammelt Ergebnisse
Zeigt Zusammenfassung

Ausgabe-Beispiel:

TASK [Test Webinterface] ****
ok: [localhost] => (item=mail.example.com)

TASK [Test SMTP Port] ****
ok: [localhost] => (item=mail.example.com)

count-mailboxes.yml

Zählung aktiver Mailboxen über die Mailcow-Datenbank.

Datei: playbooks/managed-mailcow/count-mailboxes.yml

Zweck: Ermittelt die Anzahl aktiver Mailboxen auf allen Mailcow-Servern zur Lizenzierung oder Reporting.

Ziel-Hosts: all (mit Aggregation)

Benutzer: tincadmin (mit sudo-Rechten)

Verwendete Rollen:

managed-mailcow (find-mailcow-composedir)

Wichtige Variablen:

DBROOT - Wird automatisch aus mailcow.conf extrahiert

Verwendungsbeispiel:

# Zähle Mailboxen auf allen Servern
ansible-playbook playbooks/managed-mailcow/count-mailboxes.yml \
  -i inventories/extern.yml \
  -K

# Nur ein Server
ansible-playbook playbooks/managed-mailcow/count-mailboxes.yml \
  -i inventories/extern.yml \
  --limit mail-01.example.com \
  -K

Abhängigkeiten:

Mailcow-Installation
MySQL-Container muss laufen
Zugriff auf mailcow.conf für DB-Root-Passwort

Besonderheiten:

Liest DBROOT-Passwort aus mailcow.conf
Nutzt docker compose exec für DB-Abfrage
Aggregiert Ergebnisse über alle Hosts (verwendet run_once: true)
SQL-Query: SELECT COUNT(*) FROM mailbox WHERE active = 1

Workflow:

Findet Mailcow-Directory auf jedem Host
Extrahiert DB-Root-Passwort aus mailcow.conf
Führt SQL-Query in MySQL-Container aus
Sammelt Mailbox-Counts von allen Hosts
Zeigt Aggregierte Summe

Ausgabe-Beispiel:

TASK [Show mailbox counts] ****
ok: [mail-01.example.com] => {
    "msg": "mail-01.example.com: 245 active mailboxes"
}
ok: [mail-02.example.com] => {
    "msg": "mail-02.example.com: 189 active mailboxes"
}

Total: 434 active mailboxes

enable-sni-globally.yml

Globale Aktivierung von SNI (Server Name Indication) in Mailcow.

Datei: playbooks/managed-mailcow/enable-sni-globally.yml

Zweck: Aktiviert SNI-Support für Multi-Domain-SSL-Zertifikate in Mailcow.

Ziel-Hosts: all

Benutzer: tincadmin (mit sudo-Rechten)

Verwendete Rollen:

managed-mailcow (find-mailcow-composedir, start-mailcow)

Wichtige Variablen:

Variable	Default	Beschreibung
`debug`	`false`	Debug-Output aktivieren

Verwendungsbeispiel:

# SNI global aktivieren
ansible-playbook playbooks/managed-mailcow/enable-sni-globally.yml \
  -i inventories/extern.yml \
  -K

# Mit Debug-Output
ansible-playbook playbooks/managed-mailcow/enable-sni-globally.yml \
  -i inventories/extern.yml \
  -e "debug=true" \
  -K

Abhängigkeiten:

Mailcow-Installation

Besonderheiten:

Konfigurationsänderung: Setzt ENABLE_SSL_SNI=y in mailcow.conf
Bedingter Neustart: Nur wenn Änderung vorgenommen wurde
Idempotent: Mehrfache Ausführung sicher

Workflow:

Findet Mailcow-Directory
Prüft aktuellen SNI-Status in mailcow.conf
Ändert ENABLE_SSL_SNI=y (falls noch nicht gesetzt)
Startet Mailcow neu (nur bei Änderung)
Wartet auf Service-Verfügbarkeit

Wann verwenden:

Multi-Domain-Setups
Verschiedene SSL-Zertifikate pro Domain
Wildcard-Zertifikate für Subdomains

remove-watchdog-mail.yaml

Deaktivierung von Watchdog-E-Mail-Benachrichtigungen.

Datei: playbooks/managed-mailcow/remove-watchdog-mail.yaml

Zweck: Entfernt oder kommentiert die Watchdog-Benachrichtigungs-E-Mail-Adresse in Mailcow.

Ziel-Hosts: all

Benutzer: tincadmin (mit sudo-Rechten)

Verwendete Rollen:

managed-mailcow (find-mailcow-composedir, start-mailcow)

Wichtige Variablen:

Variable	Default	Beschreibung
`debug`	`false`	Debug-Ausgaben

Verwendungsbeispiel:

# Watchdog-Benachrichtigungen deaktivieren
ansible-playbook playbooks/managed-mailcow/remove-watchdog-mail.yaml \
  -i inventories/extern.yml \
  -K

# Auf einzelnem Server
ansible-playbook playbooks/managed-mailcow/remove-watchdog-mail.yaml \
  -i inventories/extern.yml \
  --limit mail.example.com \
  -K

Abhängigkeiten:

Mailcow-Installation

Besonderheiten:

Kommentiert oder entfernt WATCHDOG_NOTIFY_EMAIL in mailcow.conf
Restart nach Änderung
Idempotent

Workflow:

Findet Mailcow-Directory
Sucht WATCHDOG_NOTIFY_EMAIL in mailcow.conf
Kommentiert Zeile aus oder entfernt sie
Startet Mailcow neu (bei Änderung)

Wann verwenden:

Zu viele Watchdog-Benachrichtigungen
Externes Monitoring bevorzugt (z.B. CheckMK)
Benachrichtigungen an andere Destination

change-garbagecleaner.yaml

Änderung des Mailcow-Garbage-Cleaner-Intervalls.

Datei: playbooks/managed-mailcow/change-garbagecleaner.yaml

Zweck: Setzt das Garbage-Collector-Intervall für Maildir-Bereinigung auf 7 Tage (10080 Minuten).

Ziel-Hosts: all

Benutzer: tincadmin (mit sudo-Rechten)

Verwendete Rollen: Keine (direkte Tasks)

Wichtige Variablen:

Regex-Ersetzung: MAILDIR_GC_TIME=10080

Verwendungsbeispiel:

# Garbage-Cleaner-Intervall ändern
ansible-playbook playbooks/managed-mailcow/change-garbagecleaner.yaml \
  -i inventories/extern.yml \
  -K

# Mit custom Intervall (z.B. 14 Tage = 20160 Minuten)
ansible-playbook playbooks/managed-mailcow/change-garbagecleaner.yaml \
  -i inventories/extern.yml \
  -e "gc_time=20160" \
  -K

Abhängigkeiten:

Mailcow-Installation unter /opt/mailcow-dockerized

Besonderheiten:

Backup des Config-Files vor Änderung
Bedingte Docker-Compose Neustart (nur bei Änderung)
Hardcoded Pfad: /opt/mailcow-dockerized/mailcow.conf

Workflow:

Erstellt Backup von mailcow.conf
Ersetzt MAILDIR_GC_TIME mit neuem Wert (10080)
Prüft ob Änderung erfolgte
Restart Mailcow (bei Änderung)

Wann verwenden:

Speicherplatz-Optimierung
Compliance-Anforderungen (längere Aufbewahrung)
Performance-Tuning

migrate-clamd.yaml

Migration zu zentralem ClamAV-Server, Deaktivieren lokaler ClamAV.

Datei: playbooks/managed-mailcow/migrate-clamd.yaml

Zweck: Umstellung von lokalem ClamAV auf zentralen ClamAV-Server für Antivirus-Scanning.

Ziel-Hosts: all

Benutzer: tincadmin (mit sudo-Rechten)

Verwendete Rollen: Keine (direkte Tasks)

Wichtige Variablen:

Variable	Wert	Beschreibung
Neuer ClamAV-Server	`[2a07:6fc0:c:2809::23]:3310`	Zentrale ClamAV-Instanz (IPv6)

Verwendungsbeispiel:

# Migration auf zentralen ClamAV
ansible-playbook playbooks/managed-mailcow/migrate-clamd.yaml \
  -i inventories/extern.yml \
  -K

# Mit custom ClamAV-Server
ansible-playbook playbooks/managed-mailcow/migrate-clamd.yaml \
  -i inventories/extern.yml \
  -e "clamd_server=[2a07:6fc0:c:2809::99]:3310" \
  -K

Abhängigkeiten:

Mailcow-Installation unter /opt/mailcow-dockerized
Erreichbarkeit des zentralen ClamAV-Servers

Besonderheiten:

Ändert Rspamd-Config: antivirus.conf
Ändert Mailcow-Config: SKIP_CLAMD=y (deaktiviert lokalen ClamAV)
Neustart von Mailcow und Rspamd-Container
Ressourcen-Einsparung: Kein lokaler ClamAV mehr nötig

Workflow:

Backup von antivirus.conf
Ändert Rspamd-Antivirus-Konfiguration auf zentralen Server
Setzt SKIP_CLAMD=y in mailcow.conf
Restart Mailcow-Stack
Restart Rspamd-Container spezifisch

Vorteile:

Ressourcen-Einsparung: ClamAV benötigt 1-2 GB RAM pro Instanz
Zentrale Updates: Virus-Signaturen nur einmal aktualisieren
Konsistenz: Gleiche Scan-Engine für alle Server

Siehe auch: Basis-System → deploy-clamav-server.yml

use-syslog-server.yaml

Umleitung von Docker-Container-Logs auf zentralen Syslog-Server.

Datei: playbooks/managed-mailcow/use-syslog-server.yaml

Zweck: Konfiguration des Docker-Logging-Treibers für zentrale Syslog-Aggregation.

Ziel-Hosts: all

Benutzer: tincadmin (mit sudo-Rechten)

Verwendete Rollen:

managed-mailcow (find-mailcow-composedir, stop-mailcow, start-mailcow)

Wichtige Variablen:

Variable	Wert	Beschreibung
Syslog-Server	`udp://[2a0e:b680:80::91]:5514`	Zentrale Syslog-Instanz (IPv6, UDP)
Format	`rfc5424`	Syslog-Message-Format
Tag	`{{ '{{.Name}}' }}`	Container-Name als Log-Tag

Verwendungsbeispiel:

# Syslog-Logging aktivieren
ansible-playbook playbooks/managed-mailcow/use-syslog-server.yaml \
  -i inventories/extern.yml \
  -K

# Mit custom Syslog-Server
ansible-playbook playbooks/managed-mailcow/use-syslog-server.yaml \
  -i inventories/extern.yml \
  -e "syslog_server=udp://syslog.example.com:514" \
  -K

Abhängigkeiten:

Mailcow-Installation
Erreichbarkeit des Syslog-Servers
Docker installiert

Besonderheiten:

Ändert log-driver zu "syslog" in docker-compose.override.yml
Bedingte Anwendung: Nur wenn aktueller Driver "local" ist
Mailcow-Neustart nach Änderung für Aktivierung
RFC5424-Format: Strukturierte Syslog-Messages

Workflow:

Findet Mailcow-Directory
Prüft aktuellen Log-Driver in docker-compose.yml
Erstellt docker-compose.override.yml (falls nicht vorhanden)
Konfiguriert Syslog-Logging für alle Services
Stoppt Mailcow
Startet Mailcow (neue Log-Konfiguration aktiv)

Vorteile:

Zentrale Log-Aggregation
Log-Retention-Management zentralisiert
Bessere Analyse-Möglichkeiten (z.B. mit ELK-Stack)
Reduzierter lokaler Speicherverbrauch

use-docker-image-proxy.yaml

Konfiguration von Docker-Daemon zur Nutzung von Docker-Image-Proxy.

Datei: playbooks/managed-mailcow/use-docker-image-proxy.yaml

Zweck: Konfiguration des Docker-Daemons zur Verwendung eines HTTP-Proxys für Docker-Image-Downloads.

Ziel-Hosts: all

Benutzer: tincadmin (mit sudo-Rechten)

Verwendete Rollen: Keine (direkte Tasks)

Wichtige Variablen:

Variable	Wert	Beschreibung
Proxy-Server	`dim.servercow.com:3128`	Docker-Image-Mirror-Proxy
CA-Certificate URL	`http://[2a07:6fc0:c:2809::20]:3128/ca.crt`	Proxy-CA-Zertifikat

Verwendungsbeispiel:

# Docker-Proxy konfigurieren
ansible-playbook playbooks/managed-mailcow/use-docker-image-proxy.yaml \
  -i inventories/extern.yml \
  -K

# Mit custom Proxy
ansible-playbook playbooks/managed-mailcow/use-docker-image-proxy.yaml \
  -i inventories/extern.yml \
  -e "docker_proxy=proxy.example.com:3128" \
  -K

Abhängigkeiten:

Docker installiert
Erreichbarkeit des Proxy-Servers

Besonderheiten:

Entfernt existing registry-mirrors (saubere Neukonfiguration)
Installiert CA-Zertifikat für HTTPS-Proxying
Konfiguriert systemd-override für Docker-Proxy-Environment
Reload und Restart von Docker-Daemon

Workflow:

Entfernt alte Registry-Mirrors aus /etc/docker/daemon.json
Lädt CA-Zertifikat vom Proxy herunter
Installiert CA-Zertifikat systemweit
Erstellt systemd-Override für Docker (/etc/systemd/system/docker.service.d/http-proxy.conf)
Setzt Environment-Variablen:
- HTTP_PROXY
- HTTPS_PROXY
- NO_PROXY
Reload systemd
Restart Docker-Service

Vorteile:

Schnellere Image-Downloads (Caching)
Bandbreiten-Einsparung
Rate-Limit-Vermeidung bei Docker Hub
Offline-Capability (gecachte Images)

Siehe auch: Container-Management → Docker-Image-Proxy/Mirror

find-roundcube-installations.yaml

Suche nach Roundcube-Webmail-Installationen in Mailcow.

Datei: playbooks/managed-mailcow/find-roundcube-installations.yaml

Zweck: Automatisches Auffinden von Roundcube-Webmail-Installationen auf Mail-Servern.

Ziel-Hosts: all

Benutzer: tincadmin (mit sudo-Rechten)

Verwendete Rollen: Keine (direkte Tasks)

Wichtige Variablen:

Variable	Default	Beschreibung
`mailcow_search_paths`	`[/opt, /data, /root, /storage]`	Suchverzeichnisse
`rc_dirs`	`[rc, roundcube, roundcubemail]`	Roundcube-Verzeichnisnamen

Verwendungsbeispiel:

# Suche nach Roundcube-Installationen
ansible-playbook playbooks/managed-mailcow/find-roundcube-installations.yaml \
  -i inventories/extern.yml \
  -K

# Mit custom Suchpfaden
ansible-playbook playbooks/managed-mailcow/find-roundcube-installations.yaml \
  -i inventories/extern.yml \
  -e "mailcow_search_paths=[/var/www, /srv]" \
  -K

Abhängigkeiten:

Keine (nur Dateisystem-Zugriff)

Besonderheiten:

Recursive Find über mehrere Verzeichnisse
Pattern-Matching: Sucht nach typischen Roundcube-Verzeichnissen
Report nur für Hosts mit gefundenen Installationen
Keine Änderungen - nur Information

Workflow:

Durchsucht definierte Pfade rekursiv
Sucht nach Verzeichnissen mit Namen: rc, roundcube, roundcubemail
Sammelt gefundene Pfade
Zeigt Report für jeden Host mit Installationen

Ausgabe-Beispiel:

TASK [Show Roundcube installations] ****
ok: [mail-01.example.com] => {
    "msg": "Found Roundcube at: /opt/mailcow-dockerized/data/web/rc"
}
skipping: [mail-02.example.com]  # Keine Installation gefunden

Wann verwenden:

Inventarisierung von Roundcube-Installationen
Vor Roundcube-Updates
Security-Audits
Bereinigung alter Installationen

install-register-cmk-agent.yaml

Installation und Registrierung von CheckMK-Agent für verwaltete Mailcow-Systeme.

Datei: playbooks/managed-mailcow/install-register-cmk-agent.yaml

Zweck: Spezialisierte CheckMK-Agent-Installation für Mailcow-Hosts mit spezifischen Konfigurationen.

Ziel-Hosts: all

Benutzer: tincadmin (mit sudo-Rechten)

Verwendete Rollen:

checkmk.general.agent (externe Collection)

Wichtige Variablen:

Variable	Default	Beschreibung
`checkmk_agent_version`	`"2.3.0p14"`	Agent-Version (älter als Standard!)
`checkmk_agent_user`	`"automation"`	CheckMK-Automation-User
`checkmk_agent_server`	`servercow.observer`	CheckMK-Server
`checkmk_agent_folder`	`"/managed_mailcows"`	Ziel-Ordner im CheckMK
Discovery	`max_parallel_tasks: 2`	Parallelisierung der Discovery

Verwendungsbeispiel:

# CheckMK-Agent für Mailcow-Hosts installieren
ansible-playbook playbooks/managed-mailcow/install-register-cmk-agent.yaml \
  -i inventories/extern.yml \
  -K --ask-vault-pass

# Mit neuerer Agent-Version
ansible-playbook playbooks/managed-mailcow/install-register-cmk-agent.yaml \
  -i inventories/extern.yml \
  -e "checkmk_agent_version=2.4.0p17" \
  -K --ask-vault-pass

Abhängigkeiten:

CheckMK-Server erreichbar
Vault-Authentifizierung

Besonderheiten:

Strategie: linear - Sequential processing
Unterschiedliche Versionen je nach Use-Case (2.3.0p14 vs. 2.4.0p17)
IPv4-Adresse wird automatisch aus ansible_default_ipv4.address extrahiert
Spezifischer Folder: /managed_mailcows für Organisierung

Workflow:

Lädt Vault-Daten
Installiert CheckMK-Agent (Version 2.3.0p14)
Registriert Agent beim Server
Führt Service-Discovery durch (max 2 parallel)
Aktiviert Host in CheckMK

⚠️ Hinweis: Dieses Playbook verwendet eine ältere Agent-Version (2.3.0p14) als das generische Playbook. Prüfen Sie ob dies beabsichtigt ist.

Siehe auch: Monitoring → reinstall-cmk-agent.yml

add-haveged.yaml

Installation von Haveged (Entropy-Generator).

Datei: playbooks/managed-mailcow/add-haveged.yaml

Zweck: Installation des Haveged-Daemons für bessere Zufallszahlen-Generierung (Entropie).

Ziel-Hosts: all

Benutzer: tincadmin (mit sudo-Rechten)

Verwendete Rollen: Keine (direkte apt-Installation)

Verwendungsbeispiel:

# Haveged installieren
ansible-playbook playbooks/managed-mailcow/add-haveged.yaml \
  -i inventories/extern.yml \
  -K

Abhängigkeiten:

Debian APT

Besonderheiten:

Sehr einfaches Playbook
Direkte apt-Installation ohne Rolle
Startet automatisch nach Installation

Workflow:

Aktualisiert APT-Cache
Installiert Paket haveged
Startet und aktiviert Service

Wann verwenden:

Virtuelle Maschinen mit niedriger Entropie
Kryptographie-intensive Anwendungen (Mail-Server, TLS)
Nach /dev/random Blockierungen

Warum für Mail-Server:

Mail-Verschlüsselung benötigt gute Zufallszahlen
TLS-Verbindungen nutzen Entropie
DKIM-Signing profitiert von guter Entropie

Rollen

Rolle: managed-mailcow

Zweck: Verwaltung von Mailcow-E-Mail-Servern (Docker-basiert).

Pfad: roles/managed-mailcow/

Hauptaufgaben:

1. check-mailcow-install-status.yml

Prüft ob Mailcow installiert ist.

Überprüft Existenz von mailcow.conf
Setzt mailcow_installed Fact
Verwendet in Pre-Checks

2. find-mailcow-composedir.yml

Sucht und ermittelt Mailcow-Installationsverzeichnis.

Sucht nach docker-compose.yml mit Mailcow-spezifischem Content
Setzt mailcow_dir_result Variable
Standardpfad: /opt/mailcow-dockerized

3. get-mailcow-current-version.yml

Ermittelt aktuell installierte Mailcow-Version.

Liest Git-Tag oder Branch
Parses Versions-Information
Setzt mailcow_current_version Fact

4. start-mailcow.yml

Startet Mailcow-Docker-Compose-Stack.

Verwendet docker-compose up -d
Wartet auf Service-Verfügbarkeit
Optionale Verbose-Ausgabe

5. stop-mailcow.yml

Stoppt Mailcow-Stack sauber.

Verwendet docker-compose down
Graceful shutdown
Wartet auf vollständiges Stoppen

6. update-mailcow.yml

Führt Mailcow-Update durch.

Git-Pull von Mailcow-Repository
Führt update.sh Script aus
Throttled execution (verhindert Overload)
Wartet auf Abschluss

7. install-mailcow-components.yml

Installiert fehlende Mailcow-Komponenten.

Installiert optionale Features
Konfiguriert Zusatzmodule

Standardvariablen:

Die Rolle hat keine defaults/main.yml - Variablen werden per Playbook übergeben.

Typische Variablen:

mailcow_dir: /opt/mailcow-dockerized
github_mailcow_ver: "2026-03b"
verbose: true
debug: false

Verwendung in Playbooks:

# Find Mailcow directory
- include_role:
    name: managed-mailcow
    tasks_from: find-mailcow-composedir

# Check installation status
- include_role:
    name: managed-mailcow
    tasks_from: check-mailcow-install-status

# Update Mailcow
- include_role:
    name: managed-mailcow
    tasks_from: update-mailcow
  vars:
    github_mailcow_ver: "2026-04"

Best Practices

1. Updates planen

Mailcow-Updates in Wartungsfenstern durchführen:

# Außerhalb der Geschäftszeiten
ansible-playbook playbooks/managed-mailcow/update-mailcow.yaml \
  -i inventories/extern.yml \
  -e "github_mailcow_ver=2026-04" \
  -K --ask-vault-pass

2. Snapshots aktivieren

Immer Snapshots bei Updates aktivieren:

-e "do_snapshots=true"

3. Health-Checks vor und nach Änderungen

# Vor Änderung
ansible-playbook playbooks/managed-mailcow/check-mailcow-health.yml

# Änderung durchführen

# Nach Änderung
ansible-playbook playbooks/managed-mailcow/check-mailcow-health.yml

4. Zentrale Services nutzen

Verwenden Sie zentrale Services für Ressourcen-Einsparung:

ClamAV: migrate-clamd.yaml
Syslog: use-syslog-server.yaml
Docker-Proxy: use-docker-image-proxy.yaml

5. Regelmäßige Bereinigung

Wöchentliche Docker-Cleanups nach Updates:

# Nach jedem Update
ansible-playbook playbooks/docker/cleanup-images.yml \
  -i inventories/extern.yml \
  -K

Fehlerbehebung

Problem: Mailcow-Update hängt

Symptome: Update-Script läuft endlos

Lösung:

Überprüfen Sie Logs auf dem Host:

tail -f /opt/mailcow-dockerized/logs/update.log

Überprüfen Sie Docker-Container-Status:
```
docker-compose ps
```

Manuelle Intervention:

cd /opt/mailcow-dockerized
./update.sh --skip-start

Problem: Container starten nach Update nicht

Symptome: Services bleiben down nach Update

Lösung:

Überprüfen Sie Logs:
```
docker-compose logs -f
```

Neustart einzelner Container:

docker-compose restart <container-name>

Vollständiger Neustart:

ansible-playbook playbooks/managed-mailcow/start-stop-mailcow.yaml

Problem: Disk-Space-Check schlägt fehl

Symptome: Update abbricht wegen Speicherplatz

Lösung:

Bereinigen Sie Docker-Ressourcen:

ansible-playbook playbooks/docker/cleanup-all.yml

Überprüfen Sie Speichernutzung:
```
df -h /var/lib/docker
```
Erweitern Sie Partition oder löschen Sie alte Backups

Problem: Syslog-Logging funktioniert nicht

Symptome: Keine Logs auf Syslog-Server

Lösung:

Testen Sie Syslog-Server-Erreichbarkeit:
```
nc -vuz [2a0e:b680:80::91] 5514
```

Überprüfen Sie Docker-Logging-Konfiguration:

docker inspect <container> | grep -A 10 LogConfig

Restart Container nach Logging-Änderung

Navigation: ← Zurück: Container-Management | Nächstes: Security & Hardening →

28 KiB Raw Blame History

Mail-Server-Verwaltung (Mailcow)

Übersicht

Playbooks

update-mailcow.yaml

start-stop-mailcow.yaml

check-mailcow-health.yml

count-mailboxes.yml

enable-sni-globally.yml

remove-watchdog-mail.yaml

change-garbagecleaner.yaml

migrate-clamd.yaml

use-syslog-server.yaml

use-docker-image-proxy.yaml

find-roundcube-installations.yaml

install-register-cmk-agent.yaml

add-haveged.yaml

Rollen

Rolle: managed-mailcow

1. check-mailcow-install-status.yml

2. find-mailcow-composedir.yml

3. get-mailcow-current-version.yml

4. start-mailcow.yml

5. stop-mailcow.yml

6. update-mailcow.yml

7. install-mailcow-components.yml

Best Practices

1. Updates planen

2. Snapshots aktivieren

3. Health-Checks vor und nach Änderungen

4. Zentrale Services nutzen

5. Regelmäßige Bereinigung

Fehlerbehebung

Problem: Mailcow-Update hängt

Problem: Container starten nach Update nicht

Problem: Disk-Space-Check schlägt fehl

Problem: Syslog-Logging funktioniert nicht

28 KiB

Raw Blame History