This commit is contained in:
Ansible Servercow
2026-06-11 18:04:41 +02:00
parent 590d37e4cf
commit da81549161
9 changed files with 5004 additions and 0 deletions

216
docs/00-Übersicht.md Normal file
View File

@@ -0,0 +1,216 @@
# Operating Automation - Ansible-Projekt Dokumentation
## Übersicht
Dieses Ansible-Projekt dient der Automatisierung von Systemadministrations-Aufgaben für eine Debian-basierte Infrastruktur. Es umfasst 26 Playbooks und 10 Rollen zur Verwaltung von Betriebssystem-Updates, Container-Verwaltung, Mail-Server-Betrieb (Mailcow), Monitoring (CheckMK), Virtualisierung (Proxmox) und Sicherheits-Härtung.
## Projektzweck
Das Projekt automatisiert folgende Hauptbereiche:
- **Betriebssystem-Verwaltung**: Updates, Major-Upgrades, Mirror-Konfiguration
- **Container-Infrastruktur**: Docker-Installation und -Wartung
- **Mail-Server-Betrieb**: Umfassende Mailcow-Verwaltung mit 13 spezialisierten Playbooks
- **Monitoring**: CheckMK-Agent-Installation und -Verwaltung
- **Virtualisierung**: Proxmox-Snapshot-Verwaltung
- **Sicherheit**: SSH-Schlüssel-Verwaltung und System-Härtung
- **Wartung**: Cleanup-Routinen für Snapshots, Container und Agenten-Plugins
## Projektstruktur
```
operating-automation/
├── ansible.cfg # Ansible-Hauptkonfiguration
├── vault.yml # Verschlüsselte Zugangsdaten (Ansible Vault)
├── inventories/ # Host-Inventories
│ ├── extern.yml # Externe Mail-Server
│ ├── icp-fra-pve1.yml # Proxmox-Cluster (6 Hosts, IPv6 TincVPN)
│ ├── icp-frav-packer01.yml # Packer-Build-Host
│ └── group_vars/ # Gruppenvariablen
│ ├── all.yml # Globale Variablen für alle Hosts
│ └── all.example.yml # Template für Umgebungsanpassungen
├── playbooks/ # Ansible-Playbooks
│ ├── *.yml # Root-Level Playbooks (OS, Monitoring, etc.)
│ ├── cleanups/ # Wartungs- und Bereinigungsaufgaben
│ ├── docker/ # Docker-Verwaltung
│ ├── hardening/ # Sicherheits-Härtung
│ └── managed-mailcow/ # Mailcow-spezifische Automatisierung
├── roles/ # Ansible-Rollen
│ ├── checkmk-monitoring/ # CheckMK-Integration
│ ├── deploy-clamd/ # ClamAV-Antivirus-Bereitstellung
│ ├── docker/ # Docker-Verwaltung
│ ├── manage-ssh-keys/ # SSH-Schlüssel-Administration
│ ├── managed-mailcow/ # Mailcow-Operationen
│ ├── os-updates/ # Betriebssystem-Updates
│ ├── proxmox-automation/ # Proxmox-Snapshot-Verwaltung
│ ├── ssh/ # SSH-Konfiguration (in Entwicklung)
│ ├── system/ # Basis-Systemkonfiguration
│ └── updates/ # Generische Update-Mechanismen
└── collections/ # Externe Collections (via ansible-galaxy)
```
## Ansible-Konfiguration
Die Datei `ansible.cfg` definiert folgende wichtige Einstellungen:
| Einstellung | Wert | Bedeutung |
|-------------|------|-----------|
| `host_key_checking` | `False` | Deaktiviert SSH-Host-Key-Überprüfung |
| `roles_path` | `./roles:/etc/ansible/roles` | Priorisiert lokale Rollen |
| `interpreter_python` | `/usr/bin/python3` | Erzwingt Python 3 auf allen Zielhosts |
## Inventory-Struktur
Das Projekt nutzt drei separate Inventory-Dateien für unterschiedliche Deployment-Kontexte:
### icp-fra-pve1.yml
- **Zweck**: Proxmox-Cluster-Verwaltung
- **Hosts**: 6 Systeme
- **Adressierung**: IPv6 TincVPN-Adressen
- **Ziel-OS**: Debian Bookworm/Trixie
### extern.yml
- **Zweck**: Externe Mail-Server
- **Adressierung**: IPv4 mit custom SSH-Ports
- **Besonderheit**: Root-SSH-Zugang
### icp-frav-packer01.yml
- **Zweck**: Einzelner Packer-Build-Host
- **Zugriff**: Root via SSH
## Gruppenvariablen (group_vars)
Die Konfiguration erfolgt über eine dreistufige Hierarchie:
1. **all.yml** - Globale Defaults für alle Hosts:
- OS-Update-Konfiguration (Mirror, Upgrade-Modi, Ziel-Versionen)
- CheckMK-Agent-Version (2.3.0p34 CEE) und Server-URLs
- Docker-Mirror und Proxy-Konfiguration
- CrowdSec LAPI-Einstellungen
- BackupCow Git-Repository
2. **Gruppen-spezifische Variablen** - Z.B. für Proxmox-Cluster
3. **Host-spezifische Variablen** - Inline in Inventory-Dateien
## Externe Abhängigkeiten
Das Projekt benötigt folgende Ansible-Collections (Installation via `ansible-galaxy`):
| Collection | Version | Verwendung |
|------------|---------|------------|
| `community.docker` | 3.11.0 | Docker-Operationen (cleanup, image mgmt) |
| `community.proxmox` | 1.4.0 | Proxmox API (Snapshots, VM-Management) |
| `checkmk.general` | - | CheckMK-Agent-Deployment & Registrierung |
## Vault-Verwendung
Die Datei `vault.yml` enthält verschlüsselte Zugangsdaten für:
- Proxmox API-Tokens
- CheckMK Automation-User und Passwörter
- Weitere sensible Konfigurationsdaten
**Verwendung**: Playbooks mit Vault-Zugriff müssen mit `--ask-vault-pass` ausgeführt werden.
## Voraussetzungen
- **Ansible**: Version 2.14 oder höher
- **Python**: Version 3.x auf allen Zielhosts
- **SSH-Zugriff**: Schlüsselbasierte Authentifizierung als `tincadmin` mit Sudo-Rechten
- **Betriebssystem**: Debian Bookworm oder Trixie auf Zielhosts
## Dokumentationsnavigation
Die Dokumentation ist nach funktionalen Kategorien gegliedert:
1. **[OS-Management](01-OS-Management.md)** - Betriebssystem-Updates, Major-Upgrades, Mirror-Verwaltung
2. **[Monitoring](02-Monitoring.md)** - CheckMK-Agent-Installation und -Verwaltung
3. **[Container-Management](03-Container-Management.md)** - Docker-Installation und -Wartung
4. **[Mail-Server-Verwaltung](04-Mail-Server-Verwaltung.md)** - Mailcow-Automatisierung (13 Playbooks)
5. **[Security & Hardening](05-Security-Hardening.md)** - SSH-Schlüssel-Verwaltung
6. **[Virtualisierung](06-Virtualisierung.md)** - Proxmox-Snapshot-Automatisierung
7. **[Basis-System](07-Basis-System.md)** - Grundlegende Systemkonfiguration, ClamAV, Chrony
8. **[Cleanup-Aufgaben](08-Cleanup-Aufgaben.md)** - Wartungs- und Bereinigungsroutinen
## Quick Start
Grundlegendes Kommando-Muster:
```bash
# Einfaches Playbook ohne Vault
ansible-playbook playbooks/setup-chronyd.yml -i inventories/icp-fra-pve1.yml -K
# Playbook mit Vault-Zugriff
ansible-playbook playbooks/os-update.yml -i inventories/icp-fra-pve1.yml -K --ask-vault-pass
# Mit spezifischen Variablen
ansible-playbook playbooks/os-major-upgrade.yml \
-i inventories/icp-fra-pve1.yml \
-e "os_update_version_codename=trixie" \
-e "do_snapshots=true" \
-K --ask-vault-pass
```
**Parameter-Erklärung**:
- `-i`: Inventory-Datei
- `-K`: Fragt nach Sudo-Passwort
- `--ask-vault-pass`: Fragt nach Vault-Passwort
- `-e`: Externe Variable (überschreibt Defaults)
## Best Practices
1. **Snapshots**: Aktivieren Sie Snapshots bei riskanten Operationen (Major-Upgrades, Mailcow-Updates)
2. **Dry-Run**: Nutzen Sie `--check` für Trockenläufe (wo unterstützt)
3. **Limitierung**: Verwenden Sie `--limit hostname` für Tests auf einzelnen Hosts
4. **Vault-Sicherheit**: Bewahren Sie das Vault-Passwort sicher auf
5. **Inventories**: Pflegen Sie getrennte Inventories für Produktion und Test-Umgebungen
## Projekt-Architektur
```
┌─────────────────────────────────────────────────────────────┐
│ Ansible Control Node │
│ │
│ ┌─────────────┐ ┌──────────────┐ ┌─────────────┐ │
│ │ Playbooks │──▶│ Roles │──▶│ Inventories │ │
│ └─────────────┘ └──────────────┘ └─────────────┘ │
│ │ │ │ │
│ │ │ │ │
│ └──────────────────┴───────────────────┘ │
│ │ │
└────────────────────────────┼─────────────────────────────────┘
┌───────────────────────────────────────┐
│ Target Infrastructure │
│ │
│ ┌──────────┐ ┌──────────────┐ │
│ │ Proxmox │ │ Mailcow │ │
│ │ Cluster │ │ Servers │ │
│ └──────────┘ └──────────────┘ │
│ │
│ ┌──────────┐ ┌──────────────┐ │
│ │ CheckMK │ │ Docker │ │
│ │ Agent │ │ Container │ │
│ └──────────┘ └──────────────┘ │
└───────────────────────────────────────┘
```
## Häufig verwendete Playbooks
| Playbook | Häufigkeit | Zweck |
|----------|------------|-------|
| `os-update.yml` | Wöchentlich | Regelmäßige Sicherheitsupdates |
| `managed-mailcow/update-mailcow.yaml` | Monatlich | Mailcow-Updates |
| `docker/cleanup-images.yml` | Wöchentlich | Speicherplatz freigeben |
| `setup-checkmk-monitoring.yml` | Bei neuen Hosts | Monitoring einrichten |
| `os-major-upgrade.yml` | Bei Releases | Debian-Versionssprung |
## Kontakt und Support
Diese Dokumentation wurde erstellt am: **14. April 2026**
Bei Änderungen an Playbooks oder Rollen sollte diese Dokumentation entsprechend aktualisiert werden.
---
**Navigation**: [Nächstes: OS-Management →](01-OS-Management.md)

346
docs/01-OS-Management.md Normal file
View File

@@ -0,0 +1,346 @@
# OS-Management
## Übersicht
Diese Kategorie umfasst alle Playbooks und Rollen zur Verwaltung des Debian-Betriebssystems, einschließlich regulärer Updates, Major-Version-Upgrades und Paketquellen-Konfiguration.
**Anwendungsfälle**:
- Regelmäßige Sicherheits- und Paket-Updates
- Debian-Versionssprünge (z.B. Bookworm → Trixie)
- Umstellung auf alternative Mirror-Server
- Automatisierte Wartungsfenster
---
## Playbooks
### os-update.yml
Führt reguläre Betriebssystem-Updates (Minor-Updates) für Debian-Systeme durch.
**Datei**: `playbooks/os-update.yml`
**Zweck**: Regelmäßige Installation von Sicherheits- und Paket-Updates auf allen Debian-Systemen mit optionaler Snapshot-Erstellung vor dem Update.
**Ziel-Hosts**: `all` (gefiltert auf Debian-Systeme)
**Benutzer**: `tincadmin` (mit sudo-Rechten)
**Verwendete Rollen**:
- [`proxmox-automation`](06-Virtualisierung.md#rolle-proxmox-automation) (optional, für Snapshots)
- `os-updates` (siehe unten)
**Wichtige Variablen**:
| Variable | Default | Beschreibung |
|----------|---------|-------------|
| `os_also_update_mirror` | `false` | Aktualisiert auch die Mirror-Konfiguration |
| `os_update_version_codename` | `"trixie"` | Ziel-Codename für Paketquellen |
| `do_snapshots` | `true` | Erstellt Proxmox-Snapshots vor Updates |
| `snapshot_name` | `"AUTO_before_os_update_{{ ansible_date_time.date }}"` | Name des Snapshots |
**Verwendungsbeispiel**:
```bash
# Einfaches Update ohne Snapshots
ansible-playbook playbooks/os-update.yml \
-i inventories/icp-fra-pve1.yml \
-e "do_snapshots=false" \
-K --ask-vault-pass
# Update mit Mirror-Aktualisierung
ansible-playbook playbooks/os-update.yml \
-i inventories/icp-fra-pve1.yml \
-e "os_also_update_mirror=true" \
-K --ask-vault-pass
# Update auf einzelnem Host
ansible-playbook playbooks/os-update.yml \
-i inventories/icp-fra-pve1.yml \
--limit hostname.example.com \
-K --ask-vault-pass
```
**Abhängigkeiten**:
- Vault-Datei (`vault.yml`) für Proxmox API-Zugriff
- Proxmox-Umgebung (wenn `do_snapshots=true`)
- Verfügbare Updates auf den Zielsystemen
**Besonderheiten**:
- Prüft mit `apt list --upgradable`, ob Updates verfügbar sind
- Erstellt Snapshots nur wenn tatsächlich Updates vorhanden sind
- Überspringt Snapshot-Erstellung automatisch, wenn `do_snapshots=false`
- Bedingte Proxmox-Integration je nach Konfiguration
**Workflow**:
1. Lädt Vault-Datei (falls Snapshots aktiviert)
2. Prüft auf verfügbare Updates
3. Erstellt Snapshot (optional, nur bei verfügbaren Updates)
4. Aktualisiert APT-Cache
5. Führt Paket-Upgrade durch
6. Neustart bei Kernel-Updates (optional)
---
### os-major-upgrade.yml
Führt ein Debian-Major-Version-Upgrade durch (z.B. Bookworm → Trixie).
**Datei**: `playbooks/os-major-upgrade.yml`
**Zweck**: Upgrade des Debian-Betriebssystems auf die nächste Hauptversion mit automatischer Snapshot-Erstellung und Neustart-Verwaltung.
**Ziel-Hosts**: `all` (gefiltert auf Debian-Systeme)
**Benutzer**: `tincadmin` (mit sudo-Rechten)
**Verwendete Rollen**:
- [`proxmox-automation`](06-Virtualisierung.md#rolle-proxmox-automation) (für Snapshots)
- `os-updates` (für Version-Upgrade-Logik)
**Wichtige Variablen**:
| Variable | Default | Beschreibung |
|----------|---------|-------------|
| `os_update_major_version` | `true` | Aktiviert Major-Version-Upgrade |
| `os_update_version_codename` | `"trixie"` | Ziel-Debian-Version |
| `do_snapshots` | `true` | Erstellt Snapshots vor Upgrade |
| `snapshot_name` | `"AUTO_before_major_{{ ansible_date_time.date }}"` | Snapshot-Name |
**Verwendungsbeispiel**:
```bash
# Major-Upgrade auf Trixie mit Snapshots
ansible-playbook playbooks/os-major-upgrade.yml \
-i inventories/icp-fra-pve1.yml \
-e "os_update_version_codename=trixie" \
-K --ask-vault-pass
# Ohne Snapshots (nicht empfohlen!)
ansible-playbook playbooks/os-major-upgrade.yml \
-i inventories/icp-fra-pve1.yml \
-e "do_snapshots=false" \
-K --ask-vault-pass
# Test auf einzelnem Host
ansible-playbook playbooks/os-major-upgrade.yml \
-i inventories/icp-fra-pve1.yml \
--limit test-host.example.com \
-K --ask-vault-pass
```
**Abhängigkeiten**:
- Vault-Datei für Proxmox API-Tokens
- Proxmox-Integration (stark empfohlen für Snapshots)
- Ausreichend Festplattenspeicher für Upgrade
- Stabile Netzwerkverbindung
**Besonderheiten**:
- **Liest `/etc/os-release`** um aktuelle Debian-Version zu ermitteln
- **Vergleicht** aktuelle und Ziel-Version vor Upgrade
- **Erstellt Snapshots** vor dem Upgrade (Rollback-Möglichkeit)
- **Wartet auf Verbindung** nach Neustart (Timeout: 300 Sekunden)
- **Überspringt** Upgrade automatisch, wenn bereits auf Ziel-Version
**Workflow**:
1. Lädt Vault-Datei
2. Liest aktuelle OS-Version aus `/etc/os-release`
3. Abruft Proxmox VM-ID
4. Erstellt Pre-Upgrade Snapshot
5. Aktualisiert Paketquellen auf neue Version
6. Aktualisiert APT-Cache
7. Führt `apt dist-upgrade` durch
8. Startet System neu
9. Wartet auf Verfügbarkeit des Systems
**⚠️ Warnung**: Major-Upgrades sind kritische Operationen. Immer Snapshots aktivieren und auf Test-Systemen validieren!
---
### os-change-mirror.yml
Ändert die Debian-Paketquellen (APT-Mirror) auf allen Systemen.
**Datei**: `playbooks/os-change-mirror.yml`
**Zweck**: Umstellung der APT-Paketquellen auf alternative Mirror-Server (z.B. auf interne tinc.gmbh Mirrors).
**Ziel-Hosts**: `all` (gefiltert auf Debian-Systeme)
**Benutzer**: `tincadmin` (mit sudo-Rechten)
**Verwendete Rollen**:
- `os-updates` (Task: `update_mirrors`)
**Wichtige Variablen**:
- Verwendet Variablen aus `group_vars/all.yml` (`os_update_mirrors`)
**Verwendungsbeispiel**:
```bash
# Mirror-Änderung auf allen Hosts
ansible-playbook playbooks/os-change-mirror.yml \
-i inventories/icp-fra-pve1.yml \
-K
# Auf spezifischer Host-Gruppe
ansible-playbook playbooks/os-change-mirror.yml \
-i inventories/extern.yml \
-K
# Mit custom Mirror (überschreibt Defaults)
ansible-playbook playbooks/os-change-mirror.yml \
-i inventories/icp-fra-pve1.yml \
-e "os_update_mirrors=['http://deb.debian.org/debian']" \
-K
```
**Abhängigkeiten**:
- Debian-Betriebssystem (`ansible_os_family == "Debian"`)
- Keine Vault-Datei erforderlich
**Besonderheiten**:
- **Überprüfung des Betriebssystems** mit Fehler-Abbruch bei Nicht-Debian
- **Backup** der alten `/etc/apt/sources.list` wird automatisch erstellt
- **Aktualisiert** APT-Cache nach Mirror-Änderung
- **Einfaches Playbook** ohne komplexe Logik
**Workflow**:
1. Prüft OS-Familie (nur Debian erlaubt)
2. Erstellt Backup der aktuellen sources.list
3. Schreibt neue Mirror-Konfiguration
4. Aktualisiert APT-Cache (`apt update`)
---
## Rollen
### Rolle: os-updates
**Zweck**: Zentrale Rolle für alle OS-Update-Operationen auf Debian-Systemen.
**Pfad**: `roles/os-updates/`
**Hauptaufgaben**:
#### 1. main.yml
Steuert den Update-Workflow und koordiniert Mirror-Updates und Paket-Upgrades.
#### 2. update_mirrors.yaml
Aktualisiert die APT-Mirror-Konfiguration in `/etc/apt/sources.list`.
- Verwendet Jinja2-Template `sources.list.j2`
- Setzt Mirror-URLs aus `os_update_mirrors` Variable
- Erstellt Backup der Original-Konfiguration
#### 3. upgrade_packages.yaml
Führt das eigentliche Paket-Upgrade durch.
- Aktualisiert APT-Cache
- Führt `apt upgrade` oder `apt dist-upgrade` durch
- Prüft auf Kernel-Updates
- Triggert Neustart bei Kernel-Update (über Handler)
#### 4. update_major_version.yaml
Wechselt Debian auf eine neue Hauptversion.
- Ändert Codename in `/etc/apt/sources.list`
- Führt `apt update` und `apt dist-upgrade` durch
- Verwaltet Neustart-Logik
**Standardvariablen** (`defaults/main.yml`):
| Variable | Default | Beschreibung |
|----------|---------|-------------|
| `os_update_auto_upgrade` | `true` | Automatisches Upgrade aktivieren |
| `os_also_update_mirror` | `true` | Mirror auch aktualisieren |
| `os_update_mirrors` | tinc.gmbh Mirrors | Liste der APT-Mirror-URLs |
| `os_update_major_version` | `false` | Major-Version-Upgrade aktivieren |
| `os_update_version_codename` | `"bookworm"` | Ziel-Debian-Codename |
**Handler**:
- `apt cleanup` - Führt `apt autoremove` und `apt clean` aus
- `Reboot system` - Startet System neu und wartet auf Verfügbarkeit
**Templates**:
- `sources.list.j2` - Erzeugt `/etc/apt/sources.list` mit konfigurierten Mirrors
**Verwendung in Playbooks**:
```yaml
- name: OS Updates durchführen
hosts: all
become: true
roles:
- role: os-updates
```
**Verwendung einzelner Tasks**:
```yaml
- name: Nur Mirrors aktualisieren
include_role:
name: os-updates
tasks_from: update_mirrors
```
---
## Best Practices
### 1. Snapshot-Verwaltung
Aktivieren Sie **immer** Snapshots bei Major-Upgrades:
```bash
-e "do_snapshots=true"
```
### 2. Test-First-Ansatz
Testen Sie Updates zuerst auf einem einzelnen Host:
```bash
--limit test-host.example.com
```
### 3. Wartungsfenster
Planen Sie OS-Updates in Wartungsfenstern, besonders wenn Neustarts erforderlich sind.
### 4. Mirror-Auswahl
Verwenden Sie geografisch nahe oder interne Mirrors für schnellere Updates:
```yaml
os_update_mirrors:
- "http://tinc.gmbh/debian"
- "http://tinc.gmbh/debian-security"
```
### 5. Monitoring nach Updates
Überprüfen Sie nach Major-Upgrades:
- System-Services: `systemctl --failed`
- Kernel-Version: `uname -r`
- Verfügbare Updates: `apt list --upgradable`
- Logs: `/var/log/apt/history.log`
---
## Fehlerbehebung
### Problem: Snapshot schlägt fehl
**Lösung**: Überprüfen Sie Proxmox API-Zugangsdaten in `vault.yml` und Speicherplatz auf dem Storage.
### Problem: APT-Lock während Update
**Lösung**: Stellen Sie sicher, dass keine anderen APT-Prozesse laufen:
```bash
sudo lsof /var/lib/dpkg/lock-frontend
sudo killall apt apt-get
```
### Problem: Neustart nach Kernel-Update hängt
**Lösung**: Überprüfen Sie Console-Zugriff über Proxmox und prüfen Sie auf Boot-Probleme.
### Problem: Mirror nicht erreichbar
**Lösung**: Testen Sie Mirror-Erreichbarkeit manuell:
```bash
curl -I http://tinc.gmbh/debian/
```
---
**Navigation**: [← Zurück zur Übersicht](00-Übersicht.md) | [Nächstes: Monitoring →](02-Monitoring.md)

454
docs/02-Monitoring.md Normal file
View File

@@ -0,0 +1,454 @@
# Monitoring
## Übersicht
Diese Kategorie umfasst alle Playbooks und Rollen zur CheckMK-Monitoring-Integration. CheckMK wird für die zentrale Überwachung aller verwalteten Systeme eingesetzt.
**Anwendungsfälle**:
- Installation und Registrierung des CheckMK-Agenten auf neuen Hosts
- Neuinstallation von CheckMK-Agenten nach Problemen
- Automatische Service-Discovery auf überwachten Hosts
- Bereinigung von Agent-Plugins
- Verwaltung von Hosts im CheckMK-Server
**CheckMK-Server**: `servercow.observer` (Site: `scowmon`)
---
## Playbooks
### setup-checkmk-monitoring.yml
Umfassende CheckMK-Monitoring-Einrichtung mit Host-Erstellung, Agent-Installation und Service-Discovery.
**Datei**: `playbooks/setup-checkmk-monitoring.yml`
**Zweck**: Vollständige Integration eines neuen Hosts in das CheckMK-Monitoring-System, einschließlich Host-Registrierung, Agent-Installation, Zertifikat-Signierung und automatischer Service-Erkennung.
**Ziel-Hosts**: `all`
**Benutzer**: `tincadmin` (mit sudo-Rechten)
**Verwendete Rollen**:
- `checkmk-monitoring` (eigene Rolle)
- Tasks: `create-host`, `sign-bake-agents`, `discover-host`
- `checkmk.general.agent` (externe Collection)
**Wichtige Variablen**:
Alle Variablen werden aus der Vault-Datei geladen. Wichtige Konfigurationsparameter:
| Variable | Beispielwert | Beschreibung |
|----------|--------------|-------------|
| `checkmk_server` | `servercow.observer` | CheckMK-Server-URL |
| `checkmk_site` | `scowmon` | CheckMK-Site-Name |
| `checkmk_folder` | `/managed_mailcows` | Ziel-Ordner im CheckMK |
| `checkmk_automation_user` | Aus Vault | Automation-Benutzer |
| `checkmk_automation_secret` | Aus Vault | Automation-Passwort |
**Verwendungsbeispiel**:
```bash
# Vollständiges Monitoring-Setup für alle Hosts
ansible-playbook playbooks/setup-checkmk-monitoring.yml \
-i inventories/icp-fra-pve1.yml \
-K --ask-vault-pass
# Nur für bestimmte Host-Gruppe
ansible-playbook playbooks/setup-checkmk-monitoring.yml \
-i inventories/extern.yml \
-K --ask-vault-pass
# Einzelner Host
ansible-playbook playbooks/setup-checkmk-monitoring.yml \
-i inventories/icp-fra-pve1.yml \
--limit newhost.example.com \
-K --ask-vault-pass
```
**Abhängigkeiten**:
- Vault-Datei (`vault.yml`) mit CheckMK-Zugangsdaten
- Externe Collection: `checkmk.general`
- Erreichbarkeit des CheckMK-Servers
- DNS-Auflösung für überwachte Hosts
**Besonderheiten**:
- **Mehrere sequenzielle Schritte**:
1. Host im CheckMK registrieren
2. Agent-Zertifikate signieren und backen
3. CheckMK-Agent auf Host installieren
4. Service-Discovery durchführen
- **2-Minuten-Pause** vor Discovery für Agent-Bereitschaft
- **`ignore_errors: true`** für Agent-Zertifikat-Handling (Fehlertoleranz)
- **Delegation zu localhost** für CheckMK-API-Aufrufe
**Workflow**:
1. Lädt Vault-Datei mit Zugangsdaten
2. Erstellt Host im CheckMK-Server (Task: `create-host`)
3. Signiert und bäckt ausstehende Agent-Jobs (Task: `sign-bake-agents`)
4. Installiert CheckMK-Agent auf Zielhost (externe Rolle)
5. Wartet 2 Minuten auf Agent-Bereitschaft
6. Führt Service-Discovery durch (Task: `discover-host`)
7. Aktiviert Änderungen im CheckMK
---
### reinstall-cmk-agent.yml
Neuinstallation und Neuregistrierung des CheckMK-Monitoring-Agenten.
**Datei**: `playbooks/reinstall-cmk-agent.yml`
**Zweck**: Neuinstallation des CheckMK-Agenten, z.B. nach Agenten-Problemen oder Version-Upgrades.
**Ziel-Hosts**: `all`
**Benutzer**: `tincadmin` (mit sudo-Rechten)
**Verwendete Rollen**:
- `checkmk.general.agent` (externe Collection)
**Wichtige Variablen**:
| Variable | Default | Beschreibung |
|----------|---------|-------------|
| `checkmk_agent_version` | `"2.4.0p17"` | Agent-Version |
| `checkmk_agent_edition` | `"cee"` | Edition (CEE = Commercial Enterprise Edition) |
| `checkmk_agent_server` | `servercow.observer` | CheckMK-Server |
| `checkmk_agent_site` | `"scowmon"` | Site-Name |
| `checkmk_agent_folder` | `"/managed_mailcows"` | Ziel-Ordner |
| `checkmk_agent_auto_activate` | `true` | Automatische Aktivierung |
| `checkmk_agent_tls` | `true` | TLS-Verschlüsselung aktivieren |
| `checkmk_agent_discover` | `true` | Automatische Service-Discovery |
**Verwendungsbeispiel**:
```bash
# Neuinstallation des Agenten auf allen Hosts
ansible-playbook playbooks/reinstall-cmk-agent.yml \
-i inventories/icp-fra-pve1.yml \
-K --ask-vault-pass
# Mit spezifischer Agent-Version
ansible-playbook playbooks/reinstall-cmk-agent.yml \
-i inventories/icp-fra-pve1.yml \
-e "checkmk_agent_version=2.4.0p20" \
-K --ask-vault-pass
# Nur auf problematischen Hosts
ansible-playbook playbooks/reinstall-cmk-agent.yml \
-i inventories/extern.yml \
--limit mail-server-01.example.com \
-K --ask-vault-pass
```
**Abhängigkeiten**:
- Vault-Datei mit CheckMK-Zugangsdaten (`checkmk_agent_user`, `checkmk_agent_pass`)
- Externe Collection `checkmk.general`
- CheckMK-Server muss erreichbar sein
- Host muss bereits im CheckMK registriert sein
**Besonderheiten**:
- **Strategie: linear** - Hosts werden nacheinander bearbeitet
- **Host-Auto-Discovery** aktiviert (`checkmk_agent_discover: true`)
- **Automatische API-Aktivierung** nach Host-Hinzufügen
- **IP-Adresse** wird automatisch aus `ansible_default_ipv4.address` extrahiert
- **Discovery mit Parallelisierung**: `max_parallel_tasks: 2`
**Workflow**:
1. Lädt Vault-Datei
2. Deinstalliert alten Agent (falls vorhanden)
3. Lädt neue Agent-Version herunter
4. Installiert neuen Agenten
5. Registriert Agent beim CheckMK-Server
6. Führt Service-Discovery durch
7. Aktiviert Änderungen
**⚠️ Hinweis**: Dieses Playbook verwendet eine ältere Agent-Version (2.4.0p17) als das Standard-Setup (2.3.0p34 in `group_vars/all.yml`). Passen Sie die Version bei Bedarf an.
---
## Rollen
### Rolle: checkmk-monitoring
**Zweck**: Integriert Hosts mit dem CheckMK-Überwachungsserver und verwaltet Monitoring-Agenten.
**Pfad**: `roles/checkmk-monitoring/`
**Hauptaufgaben**:
#### 1. create-host.yaml
Registriert neue Hosts auf dem CheckMK-Server.
- Verwendet CheckMK REST-API
- Erstellt Host-Eintrag mit IPv6-Adressen
- Setzt Host-Attribute (Ordner, Tags, IP-Adresse)
- Delegiert zu localhost (API-Aufruf)
**Beispiel-Verwendung**:
```yaml
- import_role:
name: checkmk-monitoring
tasks_from: create-host.yaml
```
#### 2. sign-bake-agents.yaml
Signiert und bäckt ausstehende Agent-Jobs im CheckMK.
- Signiert TLS-Agent-Zertifikate
- Bäckt Agent-Pakete
- Wartet auf Abschluss des Baking-Prozesses
- **Retry-Logik**: Versucht mehrfach bei Fehlern
**Beispiel-Verwendung**:
```yaml
- import_role:
name: checkmk-monitoring
tasks_from: sign-bake-agents.yaml
```
#### 3. discover-host.yaml
Führt automatische Service-Discovery auf Hosts durch.
- Scannt Host nach verfügbaren Services
- Fügt erkannte Services zum Monitoring hinzu
- Aktiviert Änderungen automatisch
- Delegiert zu localhost (API-Aufruf)
**Beispiel-Verwendung**:
```yaml
- import_role:
name: checkmk-monitoring
tasks_from: discover-host.yaml
```
#### 4. delete-host.yaml
Löscht Hosts vom CheckMK-Server.
- Entfernt Host aus Monitoring
- Bereinigt alle assoziierten Services
- Nützlich für Dekommissionierung
**Beispiel-Verwendung**:
```yaml
- import_role:
name: checkmk-monitoring
tasks_from: delete-host.yaml
```
#### 5. cleanup-agent-plugins.yaml
Bereinigt nicht benötigte Agent-Plugins auf überwachten Hosts.
- Entfernt veraltete oder unerwünschte Plugins
- Reduziert Overhead auf Agenten
- Verwendet Variable `checkmk_agent_plugins_to_remove`
**Beispiel-Verwendung**:
```yaml
- import_role:
name: checkmk-monitoring
tasks_from: cleanup-agent-plugins.yaml
```
**Standardvariablen** (`defaults/main.yaml`):
| Variable | Default | Beschreibung |
|----------|---------|-------------|
| `checkmk_agent_plugins_to_remove` | `["docker-mailq-monitoring"]` | Liste zu entfernender Plugins |
**Handler**:
| Handler | Funktion |
|---------|----------|
| `Activate Changes` | Aktiviert Konfigurationsänderungen auf CheckMK |
| `Sign and bake pending agent jobs` | Signiert Agent-Zertifikate mit Retry-Logik |
**Abhängigkeiten**:
- Keine lokalen Abhängigkeiten
- Externe Collection: `checkmk.general` erforderlich
**Verwendung in Playbooks**:
Das Playbook `setup-checkmk-monitoring.yml` zeigt die typische Verwendung:
```yaml
- name: Create host in CheckMK
import_role:
name: checkmk-monitoring
tasks_from: create-host.yaml
- name: Sign and bake pending agent jobs
import_role:
name: checkmk-monitoring
tasks_from: sign-bake-agents.yaml
- name: Install CheckMK agent
include_role:
name: checkmk.general.agent
- name: Wait for agent to be ready
pause:
minutes: 2
- name: Discover host
import_role:
name: checkmk-monitoring
tasks_from: discover-host.yaml
```
---
## CheckMK-Konfiguration
### Global Variables (aus group_vars/all.yml)
```yaml
# CheckMK Agent Configuration
checkmk_agent_version: "2.3.0p34"
checkmk_agent_edition: "cee"
checkmk_agent_server: "servercow.observer"
checkmk_agent_site: "scowmon"
checkmk_agent_folder: "/managed_mailcows"
checkmk_agent_auto_activate: true
checkmk_agent_tls: true
checkmk_agent_discover: true
checkmk_agent_registration_mode: "automatic"
```
### Vault-Variablen (vault.yml)
```yaml
# Nicht sichtbar - verschlüsselt
checkmk_automation_user: "automation"
checkmk_automation_secret: "<verschlüsselt>"
checkmk_agent_user: "automation"
checkmk_agent_pass: "<verschlüsselt>"
```
---
## Best Practices
### 1. Monitoring neuer Hosts
Verwenden Sie `setup-checkmk-monitoring.yml` für neue Hosts. Es führt alle notwendigen Schritte automatisch durch.
### 2. Agent-Updates
Für bestehende Hosts mit alten Agent-Versionen:
```bash
ansible-playbook playbooks/reinstall-cmk-agent.yml \
-i inventories/icp-fra-pve1.yml \
-e "checkmk_agent_version=2.4.0p20" \
-K --ask-vault-pass
```
### 3. Service-Discovery
CheckMK führt automatisch Discovery durch. Für manuelle Discovery nur bei Änderungen:
```bash
# Führen Sie setup-checkmk-monitoring.yml mit --limit aus
ansible-playbook playbooks/setup-checkmk-monitoring.yml \
-i inventories/icp-fra-pve1.yml \
--limit changed-host.example.com \
-K --ask-vault-pass
```
### 4. Plugin-Bereinigung
Entfernen Sie regelmäßig nicht benötigte Plugins:
```bash
ansible-playbook playbooks/cleanups/cleanup-cmk-agent-plugins.yml \
-i inventories/icp-fra-pve1.yml \
-K
```
### 5. TLS-Verschlüsselung
Halten Sie `checkmk_agent_tls: true` für sichere Agent-Verbindungen.
---
## Fehlerbehebung
### Problem: Agent-Registrierung schlägt fehl
**Symptome**: Agent kann sich nicht beim Server registrieren
**Lösung**:
1. Überprüfen Sie Vault-Zugangsdaten
2. Testen Sie Erreichbarkeit des CheckMK-Servers:
```bash
curl https://servercow.observer/scowmon
```
3. Überprüfen Sie Firewall-Regeln (Port 6556 für Agent-Communication)
### Problem: Service-Discovery findet keine Services
**Symptome**: Nach Installation werden keine Services erkannt
**Lösung**:
1. Warten Sie 2-3 Minuten nach Agent-Installation
2. Überprüfen Sie Agent-Status auf Host:
```bash
systemctl status check-mk-agent.socket
cmk-agent-ctl status
```
3. Manuelle Discovery im CheckMK-Web-Interface durchführen
### Problem: TLS-Zertifikat-Fehler
**Symptome**: Agent-Verbindung schlägt mit TLS-Fehler fehl
**Lösung**:
1. Regenerieren Sie Agent-Zertifikate:
```bash
ansible-playbook playbooks/setup-checkmk-monitoring.yml \
--tags sign-bake \
-i inventories/... \
-K --ask-vault-pass
```
2. Deinstallieren und neu installieren Sie den Agenten
### Problem: Alte Plugins stören Monitoring
**Symptome**: Fehler in Service-Checks oder hohe Agent-Last
**Lösung**:
```bash
# Bereinigen Sie Plugins
ansible-playbook playbooks/cleanups/cleanup-cmk-agent-plugins.yml \
-i inventories/icp-fra-pve1.yml \
-K
# Passen Sie checkmk_agent_plugins_to_remove in defaults/main.yaml an
```
---
## Externe Abhängigkeiten
### CheckMK Collection Installation
Installieren Sie die erforderliche Collection:
```bash
ansible-galaxy collection install checkmk.general
```
Oder mit spezifischer Version:
```bash
ansible-galaxy collection install checkmk.general:5.0.0
```
### Dokumentation
Offizielle CheckMK Collection Dokumentation:
- https://docs.checkmk.com/stable/en/agent_linux.html
- https://galaxy.ansible.com/checkmk/general
---
**Navigation**: [← Zurück: OS-Management](01-OS-Management.md) | [Nächstes: Container-Management →](03-Container-Management.md)

View File

@@ -0,0 +1,547 @@
# Container-Management
## Übersicht
Diese Kategorie umfasst alle Playbooks und Rollen zur Docker-Container-Verwaltung, einschließlich Installation, Konfiguration, Bereinigung und Wartung.
**Anwendungsfälle**:
- Docker-Installation auf neuen Hosts
- Bereinigung ungenutzter Container und Images
- Verwaltung von Docker-Daemons
- Konfiguration von Image-Proxy/Mirror für schnellere Pulls
- Status-Überprüfung von Docker-Compose-Stacks
---
## Playbooks
### docker/install-docker.yml
Installation und Konfiguration von Docker aus offizieller Quelle.
**Datei**: `playbooks/docker/install-docker.yml`
**Zweck**: Installiert Docker Engine von der offiziellen Docker-Repository auf Debian-basierten Systemen.
**Ziel-Hosts**: `all`
**Benutzer**: `tincadmin` (mit sudo-Rechten)
**Verwendete Rollen**:
- `system` (Task: `install-docker.yaml`)
**Wichtige Variablen**:
| Variable | Default | Beschreibung |
|----------|---------|-------------|
| `docker_install_source` | `"official"` | Installationsquelle (official/tinc) |
**Verwendungsbeispiel**:
```bash
# Docker von offizieller Quelle installieren
ansible-playbook playbooks/docker/install-docker.yml \
-i inventories/icp-fra-pve1.yml \
-K
# Mit tinc-Mirror (schneller in internem Netzwerk)
ansible-playbook playbooks/docker/install-docker.yml \
-i inventories/icp-fra-pve1.yml \
-e "docker_install_source=tinc" \
-K
# Auf einzelnem Host
ansible-playbook playbooks/docker/install-docker.yml \
-i inventories/icp-fra-pve1.yml \
--limit newhost.example.com \
-K
```
**Abhängigkeiten**:
- `system` Rolle
- Internet-Zugriff oder tinc-Mirror-Zugriff
- APT-Paketmanager
**Besonderheiten**:
- Verwendet offizielle Docker-Registry standardmäßig
- Installiert Docker CE (Community Edition)
- Konfiguriert Docker-Daemon automatisch
- Aktiviert Docker-Service beim Systemstart
**Workflow**:
1. Fügt Docker GPG-Key hinzu
2. Konfiguriert Docker APT-Repository
3. Aktualisiert APT-Cache
4. Installiert Docker CE
5. Startet und aktiviert Docker-Service
---
### docker/cleanup-images.yml
Bereinigung ungenutzter Docker-Images.
**Datei**: `playbooks/docker/cleanup-images.yml`
**Zweck**: Entfernt ungenutzte Docker-Images um Festplattenspeicher freizugeben.
**Ziel-Hosts**: `all`
**Benutzer**: `tincadmin` (mit sudo-Rechten)
**Verwendete Rollen**:
- `docker` (Tasks: `get-containerstatus`, `cleanup-images`)
**Wichtige Variablen**:
| Variable | Default | Beschreibung |
|----------|---------|-------------|
| `docker_compose_path` | `/opt/mailcow-dockerized` | Pfad zum Docker-Compose-Projekt |
**Verwendungsbeispiel**:
```bash
# Cleanup für alle Hosts
ansible-playbook playbooks/docker/cleanup-images.yml \
-i inventories/icp-fra-pve1.yml \
-K
# Mit custom Compose-Pfad
ansible-playbook playbooks/docker/cleanup-images.yml \
-i inventories/extern.yml \
-e "docker_compose_path=/opt/my-app" \
-K
# Nur auf spezifischem Host
ansible-playbook playbooks/docker/cleanup-images.yml \
-i inventories/icp-fra-pve1.yml \
--limit mail-server-01.example.com \
-K
```
**Abhängigkeiten**:
- Docker-Installation
- Docker-Compose (falls Compose-Projekt)
**Besonderheiten**:
- **Statischer Mailcow-Pfad** - Standard ist `/opt/mailcow-dockerized`
- Entfernt nur ungenutzte Images (keine aktiven Container betroffen)
- Prüft Container-Status vor Cleanup
**Workflow**:
1. Überprüft Status aller Container im Compose-Projekt
2. Identifiziert ungenutzte Images
3. Entfernt ungenutzte Images
4. Gibt Speicherplatz frei
**⚠️ Hinweis**: Stopped Container und deren Images werden nicht entfernt. Nur vollständig ungenutzte Images.
---
### docker/cleanup-all.yml
Vollständige Docker-Bereinigung (Container, Images, Volumes, Networks).
**Datei**: `playbooks/docker/cleanup-all.yml`
**Zweck**: Umfassende Bereinigung von Docker-Ressourcen auf Mailcow-Hosts, nur wenn alle Container laufen.
**Ziel-Hosts**: `all` (mit Mailcow)
**Benutzer**: `tincadmin` (mit sudo-Rechten)
**Verwendete Rollen**:
- `managed-mailcow` (Task: `find-mailcow-composedir`)
- `docker` (Tasks: `get-containerstatus`, `cleanup-all`)
**Wichtige Variablen**:
| Variable | Beschreibung |
|----------|-------------|
| `docker_compose_path` | Wird dynamisch aus Mailcow-Directory ermittelt |
**Verwendungsbeispiel**:
```bash
# Vollständiges Cleanup auf Mailcow-Hosts
ansible-playbook playbooks/docker/cleanup-all.yml \
-i inventories/extern.yml \
-K
# Mit Debug-Ausgabe
ansible-playbook playbooks/docker/cleanup-all.yml \
-i inventories/icp-fra-pve1.yml \
-v \
-K
```
**Abhängigkeiten**:
- Vorhandene Mailcow-Installation
- Alle Container müssen laufen (Sicherheitsbedingung)
**Besonderheiten**:
- **Conditional Cleanup**: Nur wenn alle Container aktiv sind
- **Bedingung**: `not 'false' in container_status.values()`
- Dynamische Pfaderkennung über `managed-mailcow` Rolle
- Entfernt:
- Stopped Container
- Ungenutzte Images
- Ungenutzte Volumes
- Ungenutzte Networks
**Workflow**:
1. Findet Mailcow-Compose-Directory
2. Prüft Status aller Container
3. **Abbruch** wenn Container nicht laufen
4. Führt vollständiges Cleanup durch:
- `docker system prune -a`
- `docker volume prune`
- `docker network prune`
**⚠️ Warnung**: Dieses Playbook ist aggressiv und entfernt alle ungenutzten Ressourcen. Verwenden Sie es nur, wenn Sie sicher sind, dass alle gewünschten Container laufen.
---
## Rollen
### Rolle: docker
**Zweck**: Verwaltung von Docker-Containern, Images und Daemon-Konfiguration.
**Pfad**: `roles/docker/`
**Hauptaufgaben**:
#### 1. install-docker.yml
Installiert Docker von offiziellem Repo oder tinc-Mirror.
**Funktionen**:
- Fügt Docker GPG-Signatur-Key hinzu
- Konfiguriert Docker APT-Repository
- Installiert Docker CE, CLI und containerd
- Konfiguriert Docker-Daemon mit Proxy (optional)
**Variablen**:
```yaml
docker_install_source: "official" # oder "tinc"
```
#### 2. cleanup-images.yml
Entfernt ungenutzte Docker-Images.
**Funktionen**:
- Verwendet `docker image prune -a`
- Bereinigt dangling Images
- Gibt Speicherplatz frei
**Verwendung**:
```yaml
- include_role:
name: docker
tasks_from: cleanup-images.yml
```
#### 3. cleanup-all.yml
Vollständige Bereinigung aller Docker-Ressourcen.
**Funktionen**:
- Entfernt stopped Container
- Löscht ungenutzte Images
- Bereinigt Volumes
- Entfernt ungenutzte Networks
**Verwendung**:
```yaml
- include_role:
name: docker
tasks_from: cleanup-all.yml
```
#### 4. get-containerstatus.yml
Prüft Status von Docker-Compose-Containern.
**Funktionen**:
- Liest `docker-compose ps`
- Erstellt Status-Dictionary
- Prüft ob Container running sind
**Ausgabe**:
```yaml
container_status:
nginx-mailcow: true
mysql-mailcow: true
postfix-mailcow: false # nicht laufend
```
**Verwendung**:
```yaml
- include_role:
name: docker
tasks_from: get-containerstatus.yml
vars:
docker_compose_path: /opt/mailcow-dockerized
```
#### 5. restart-daemon.yml
Startet Docker-Daemon neu.
**Funktionen**:
- Reload systemd
- Restart Docker-Service
- Wartet auf Verfügbarkeit
**Verwendung**:
```yaml
- include_role:
name: docker
tasks_from: restart-daemon.yml
```
**Standard-Variablen**:
Die Rolle selbst hat keine `defaults/main.yml`, aber verwendet Variablen aus `group_vars/all.yml`:
```yaml
use_docker_image_mirror: true
docker_mirror_location: "SC" # oder "tinc"
docker_install_source: "official"
```
**Abhängigkeiten** (`requirements.yml`):
```yaml
collections:
- name: community.docker
version: "3.11.0"
```
**Installation**:
```bash
ansible-galaxy collection install -r roles/docker/requirements.yml
```
---
## Docker-Image-Proxy/Mirror
### Konfiguration
Für schnellere Docker-Pulls in internen Netzwerken kann ein Image-Proxy konfiguriert werden.
**Siehe auch**: [Mail-Server-Verwaltung → use-docker-image-proxy.yaml](04-Mail-Server-Verwaltung.md#use-docker-image-proxyyaml)
**Vorteile**:
- Reduzierte Bandbreitennutzung
- Schnellere Image-Downloads
- Caching häufig genutzter Images
- Rate-Limit-Vermeidung bei Docker Hub
**Konfiguration in group_vars/all.yml**:
```yaml
# Docker Mirror Configuration
use_docker_image_mirror: true
docker_mirror_location: "SC" # ServerCow Mirror
# Proxy Settings
docker_proxy_host: "dim.servercow.com"
docker_proxy_port: 3128
```
---
## Best Practices
### 1. Regelmäßiges Cleanup
Führen Sie wöchentliches Image-Cleanup durch:
```bash
# Jeden Sonntag via Cron
0 2 * * 0 ansible-playbook /path/to/playbooks/docker/cleanup-images.yml \
-i /path/to/inventories/all.yml
```
### 2. Vor Major-Updates
Cleanup vor großen Updates für Speicherplatz:
```bash
ansible-playbook playbooks/docker/cleanup-all.yml \
-i inventories/icp-fra-pve1.yml \
-K
```
### 3. Image-Mirror verwenden
Nutzen Sie interne Mirrors für schnellere Pulls:
```yaml
# In group_vars/all.yml
use_docker_image_mirror: true
docker_mirror_location: "tinc"
```
### 4. Container-Status überwachen
Vor Cleanup immer Container-Status prüfen:
```bash
# Manuell auf Host
docker ps -a
docker-compose ps
# Via Ansible
ansible all -i inventories/icp-fra-pve1.yml \
-m shell -a "docker ps --format '{{.Names}}: {{.Status}}'"
```
### 5. Speicherplatz-Monitoring
Überwachen Sie Docker-Speicherverbrauch:
```bash
# Auf Host
docker system df
# Via Ansible
ansible all -i inventories/icp-fra-pve1.yml \
-m shell -a "docker system df"
```
---
## Fehlerbehebung
### Problem: Docker-Installation schlägt fehl
**Symptome**: APT kann Docker-Repository nicht erreichen
**Lösung**:
1. Überprüfen Sie Internet-Verbindung
2. Testen Sie Repository-Erreichbarkeit:
```bash
curl -fsSL https://download.docker.com/linux/debian/gpg
```
3. Verwenden Sie tinc-Mirror als Alternative:
```bash
-e "docker_install_source=tinc"
```
### Problem: Cleanup entfernt benötigte Images
**Symptome**: Nach Cleanup fehlen Images für laufende Container
**Lösung**:
- Dies sollte nicht passieren, da `cleanup-all.yml` nur bei laufenden Containern ausgeführt wird
- Restore aus Backup oder re-pull Images:
```bash
cd /opt/mailcow-dockerized
docker-compose pull
docker-compose up -d
```
### Problem: Kein Speicherplatz freigegeben
**Symptome**: `docker system df` zeigt immer noch hohe Nutzung
**Lösung**:
1. Überprüfen Sie Volumes:
```bash
docker volume ls
docker volume prune
```
2. Überprüfen Sie Build-Cache:
```bash
docker builder prune -a
```
3. Manuelle vollständige Bereinigung:
```bash
docker system prune -a --volumes
```
### Problem: Docker-Daemon startet nicht
**Symptome**: `systemctl status docker` zeigt Failed
**Lösung**:
1. Überprüfen Sie Logs:
```bash
journalctl -u docker.service -n 50
```
2. Überprüfen Sie Daemon-Konfiguration:
```bash
cat /etc/docker/daemon.json
```
3. Starten Sie Daemon neu:
```bash
systemctl restart docker
```
### Problem: Container-Status-Prüfung fehlgeschlagen
**Symptome**: `get-containerstatus` Task schlägt fehl
**Lösung**:
1. Überprüfen Sie docker-compose.yml:
```bash
cd /opt/mailcow-dockerized
docker-compose config
```
2. Überprüfen Sie ob Docker-Compose installiert ist:
```bash
docker-compose --version
```
---
## Externe Abhängigkeiten
### Community Docker Collection
**Installation**:
```bash
ansible-galaxy collection install community.docker:3.11.0
```
**Dokumentation**:
- https://docs.ansible.com/ansible/latest/collections/community/docker/
- https://galaxy.ansible.com/community/docker
**Verwendete Module**:
- `community.docker.docker_image`
- `community.docker.docker_container`
- `community.docker.docker_prune`
- `community.docker.docker_compose`
---
## Nützliche Kommandos
### Docker-Informationen abrufen
```bash
# Speichernutzung
ansible all -i inventories/icp-fra-pve1.yml \
-m shell -a "docker system df -v" \
-b
# Laufende Container
ansible all -i inventories/icp-fra-pve1.yml \
-m shell -a "docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Image}}'" \
-b
# Docker-Version
ansible all -i inventories/icp-fra-pve1.yml \
-m shell -a "docker version --format '{{.Server.Version}}'" \
-b
```
### Manuelle Bereinigung
```bash
# Auf spezifischem Host
ssh tincadmin@host.example.com
sudo docker system prune -a --volumes
sudo docker image ls
sudo docker volume ls
```
---
**Navigation**: [← Zurück: Monitoring](02-Monitoring.md) | [Nächstes: Mail-Server-Verwaltung →](04-Mail-Server-Verwaltung.md)

File diff suppressed because it is too large Load Diff

View File

@@ -0,0 +1,532 @@
# Security & Hardening
## Übersicht
Diese Kategorie umfasst Playbooks und Rollen zur Verbesserung der Systemsicherheit, insbesondere SSH-Zugriffsverwaltung und Härtung.
**Anwendungsfälle**:
- Verwaltung autorisierter SSH-Schlüssel
- Entfernung kompromittierter oder veralteter Schlüssel
- SSH-Zugriffskontrolle über Whitelisting und Blacklisting
- Zentrale SSH-Schlüssel-Verwaltung über mehrere Hosts
---
## Playbooks
### hardening/manage-ssh-keys.yaml
Verwaltung von SSH-Schlüsseln für Systemzugriff (Hinzufügen/Entfernen).
**Datei**: `playbooks/hardening/manage-ssh-keys.yaml`
**Zweck**: Zentrale Verwaltung von SSH-Public-Keys mit Whitelisting (erlaubte Schlüssel) und Blacklisting (zu entfernende Schlüssel) auf allen verwalteten Hosts.
**Ziel-Hosts**: `all`
**Benutzer**: `tincadmin` (mit sudo-Rechten)
**Verwendete Rollen**:
- `manage-ssh-keys`
**Wichtige Variablen**:
| Variable | Typ | Beschreibung |
|----------|-----|-------------|
| `good_keys` | Liste | Autorisierte SSH-Public-Keys (werden hinzugefügt) |
| `bad_keys` | Liste | Zu entfernende SSH-Public-Keys (Blacklist) |
| `ssh_user` | String | Zielbenutzer für SSH-Schlüssel (Default: `root`) |
**Verwendungsbeispiel**:
```bash
# Mit Variablen aus Rolle (defaults/main.yml)
ansible-playbook playbooks/hardening/manage-ssh-keys.yaml \
-i inventories/icp-fra-pve1.yml \
-K
# Mit externen Variablen (JSON-Format)
ansible-playbook playbooks/hardening/manage-ssh-keys.yaml \
-i inventories/icp-fra-pve1.yml \
-e '{"good_keys": ["ssh-ed25519 AAAA... user@host"]}' \
-e '{"bad_keys": ["ssh-rsa AAAA... old-key"]}' \
-K
# Nur auf einzelnem Host
ansible-playbook playbooks/hardening/manage-ssh-keys.yaml \
-i inventories/icp-fra-pve1.yml \
--limit critical-server.example.com \
-K
# Für spezifischen User (nicht root)
ansible-playbook playbooks/hardening/manage-ssh-keys.yaml \
-i inventories/icp-fra-pve1.yml \
-e "ssh_user=tincadmin" \
-K
```
**Abhängigkeiten**:
- `manage-ssh-keys` Rolle
- Sudo-Rechte auf Zielhosts
- SSH-Zugriff zu Hosts
**Besonderheiten**:
- **Kommentierte Variablen** für externe Übergabe im Playbook
- **Validierung** von Schlüsseln vor Anwendung
- **Idempotent**: Mehrfache Ausführung sicher
- **Atomare Operationen**: Erst Validierung, dann Änderung
- **Automatisches Backup**: Vor jeder Änderung
**Workflow**:
1. Validiert SSH-Schlüssel-Format (good_keys und bad_keys)
2. Überprüft `.ssh`-Verzeichnis-Existenz (erstellt falls nötig)
3. Entfernt Schlüssel aus Blacklist (`bad_keys`)
4. Fügt Schlüssel aus Whitelist (`good_keys`) hinzu
5. Bereinigt Kommentare in authorized_keys
6. Fügt Änderungs-Timestamp hinzu
**Sicherheitsaspekte**:
- ✅ Whitelisting-Ansatz (explizite Erlaubnis)
- ✅ Blacklisting für Revokation kompromittierter Schlüssel
- ✅ Automatische Bereinigung alter Einträge
- ✅ Audit-Trail durch Timestamps
- ✅ Validierung verhindert fehlerhafte Schlüssel
---
## Rollen
### Rolle: manage-ssh-keys
**Zweck**: Verwaltet SSH-Schlüssel mit Whitelisting und Blacklisting-Mechanismen für sicheren Systemzugriff.
**Pfad**: `roles/manage-ssh-keys/`
**Hauptaufgaben**:
#### 1. validate-keys.yml
Stellt sicher, dass `.ssh`-Verzeichnis existiert und korrekte Berechtigungen hat.
**Funktionen**:
- Erstellt `.ssh`-Verzeichnis (falls nicht vorhanden)
- Setzt Berechtigungen: `0700` (nur Owner kann lesen/schreiben/ausführen)
- Erstellt `authorized_keys`-Datei (falls nicht vorhanden)
- Setzt Berechtigungen für `authorized_keys`: `0600`
**Ausgeführt für User**:
```yaml
ssh_user: "root" # Standard, kann überschrieben werden
```
#### 2. add-goodkeys.yml
Fügt autorisierte SSH-Public-Keys hinzu.
**Funktionen**:
- Iteriert über `good_keys`-Liste
- Fügt jeden Schlüssel zu `authorized_keys` hinzu
- Verhindert Duplikate (idempotent)
- Verwendet `authorized_key`-Modul von Ansible
**Beispiel good_keys**:
```yaml
good_keys:
- "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKey1 admin@workstation"
- "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC... admin@laptop"
```
#### 3. remove-badkeys.yml
Entfernt nicht autorisierte oder kompromittierte Schlüssel.
**Funktionen**:
- Iteriert über `bad_keys`-Liste
- Entfernt jeden Schlüssel aus `authorized_keys`
- Verwendet `absent`-State in `authorized_key`-Modul
- Sicher bei nicht vorhandenen Schlüsseln (idempotent)
**Beispiel bad_keys**:
```yaml
bad_keys:
- "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC... old-compromised-key"
- "ssh-dss AAAAB3NzaC1kc3MAAACBAP... deprecated-dsa-key"
```
**Standardvariablen** (`defaults/main.yml`):
```yaml
# User für SSH-Schlüsselverwaltung
ssh_user: "root"
# Pfad zu authorized_keys
authorized_keys_file: "/{{ ssh_user }}/.ssh/authorized_keys"
# Whitelist: Autorisierte SSH-Schlüssel (ca. 20+ Schlüssel)
good_keys:
- "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKey1"
- "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKey2"
- "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQC..."
# ... weitere autorisierte Schlüssel
# Blacklist: Zu entfernende Schlüssel (6+ revozierte Schlüssel)
bad_keys:
- "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQC... old-key-1"
- "ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQD... compromised-key"
# ... weitere zu entfernende Schlüssel
```
**Handler**:
| Handler | Funktion |
|---------|----------|
| `Cleanup Comments` | Entfernt alte Kommentare aus authorized_keys |
| `Add Comment` | Fügt Änderungs-Timestamp hinzu |
**Verwendung in Playbooks**:
```yaml
# Vollständige Rolle
- name: Manage SSH Keys
hosts: all
become: true
roles:
- manage-ssh-keys
# Mit custom Variablen
- name: Manage SSH Keys for tincadmin user
hosts: all
become: true
roles:
- role: manage-ssh-keys
vars:
ssh_user: tincadmin
good_keys:
- "ssh-ed25519 AAAAC3... new-admin-key"
bad_keys:
- "ssh-rsa AAAAB3... old-admin-key"
# Einzelne Tasks
- name: Add authorized keys only
include_role:
name: manage-ssh-keys
tasks_from: add-goodkeys.yml
```
---
## SSH-Schlüssel-Typen
### Empfohlene Schlüsseltypen (2026)
| Typ | Sicherheit | Empfehlung | Verwendung in Projekt |
|-----|------------|------------|----------------------|
| **Ed25519** | ⭐⭐⭐⭐⭐ Höchste | ✅ Bevorzugt | Ja (~15+ Schlüssel) |
| **RSA 4096** | ⭐⭐⭐⭐ Hoch | ✅ Akzeptabel | Ja (~5+ Schlüssel) |
| **ECDSA** | ⭐⭐⭐ Mittel | ⚠️ Mäßig | Nicht im Projekt |
| **RSA 2048** | ⭐⭐ Niedrig | ⚠️ Veraltet | Einige Legacy-Keys |
| **DSA** | ⭐ Sehr niedrig | ❌ Deprecated | Sollte entfernt werden |
### Schlüssel-Generierung
**Ed25519 (empfohlen)**:
```bash
ssh-keygen -t ed25519 -C "admin@workstation-$(date +%Y%m%d)"
```
**RSA 4096**:
```bash
ssh-keygen -t rsa -b 4096 -C "admin@workstation-$(date +%Y%m%d)"
```
---
## Best Practices
### 1. Regelmäßiges Key-Rotation
Erneuern Sie SSH-Schlüssel regelmäßig:
```bash
# Quartalsweise
ansible-playbook playbooks/hardening/manage-ssh-keys.yaml \
-i inventories/icp-fra-pve1.yml \
-e '{"good_keys": [...neue Schlüssel...]}' \
-e '{"bad_keys": [...alte Schlüssel...]}' \
-K
```
### 2. Zentrale Schlüsselverwaltung
Pflegen Sie `good_keys` und `bad_keys` in:
- `roles/manage-ssh-keys/defaults/main.yml` (Standard)
- Externe Variablendateien für verschiedene Umgebungen
- Vault-Datei für sensible Schlüssel
### 3. Audit-Trail
Dokumentieren Sie Schlüssel-Änderungen:
```bash
# Vor Änderung: Backup erstellen
ansible all -i inventories/icp-fra-pve1.yml \
-m fetch \
-a "src=/root/.ssh/authorized_keys dest=/backup/ssh-keys/{{ inventory_hostname }}-{{ ansible_date_time.date }}" \
-b
# Änderung durchführen
ansible-playbook playbooks/hardening/manage-ssh-keys.yaml ...
# Verifizierung
ansible all -i inventories/icp-fra-pve1.yml \
-m shell -a "wc -l /root/.ssh/authorized_keys" \
-b
```
### 4. Kompromittierte Schlüssel sofort entfernen
Bei Sicherheitsvorfällen:
```bash
# Notfall-Entfernung kompromittierter Schlüssel
ansible-playbook playbooks/hardening/manage-ssh-keys.yaml \
-i inventories/all.yml \
-e '{"bad_keys": ["ssh-rsa AAAA... KOMPROMITTIERT"]}' \
-K
```
### 5. Test auf Non-Production zuerst
```bash
# Test auf einzelnem Host
ansible-playbook playbooks/hardening/manage-ssh-keys.yaml \
-i inventories/icp-fra-pve1.yml \
--limit test-host.example.com \
-e '{"good_keys": [...]}' \
-K
# Nach Verifizierung: Rollout
ansible-playbook playbooks/hardening/manage-ssh-keys.yaml \
-i inventories/icp-fra-pve1.yml \
-K
```
### 6. Mehrfache Admin-Keys
Verwenden Sie mehrere Admin-Schlüssel für Redundanz:
```yaml
good_keys:
- "ssh-ed25519 ... primary-admin@workstation"
- "ssh-ed25519 ... secondary-admin@laptop"
- "ssh-ed25519 ... emergency-admin@spare"
```
---
## SSH-Daemon-Härtung
Während dieses Playbook die Schlüssel verwaltet, sollten Sie auch SSH-Daemon-Konfiguration härten.
### Empfohlene sshd_config-Einstellungen
```ini
# /etc/ssh/sshd_config
# Nur Public-Key-Authentifizierung
PubkeyAuthentication yes
PasswordAuthentication no
ChallengeResponseAuthentication no
# Kein Root-Login mit Passwort
PermitRootLogin prohibit-password
# Moderne Krypto-Algorithmen
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
# Weitere Härtungen
PermitEmptyPasswords no
X11Forwarding no
MaxAuthTries 3
LoginGraceTime 20
```
### Anwendung mit Ansible
**Siehe**: [`system` Rolle → ssh-hardening.yaml](07-Basis-System.md#rolle-system)
```bash
# SSH-Daemon härten (falls implementiert in system Rolle)
ansible-playbook playbooks/hardening/harden-sshd.yml \
-i inventories/icp-fra-pve1.yml \
-K
```
---
## Fehlerbehebung
### Problem: Aussperrung nach Schlüssel-Entfernung
**Symptome**: Kein SSH-Zugriff mehr nach Ausführung
**Prävention**:
1. **Immer** mindestens einen funktionierenden Schlüssel in `good_keys` behalten
2. Testen Sie auf einzelnem Host zuerst (`--limit`)
3. Halten Sie Console-Zugriff bereit (z.B. Proxmox VNC)
**Lösung bei Aussperrung**:
1. Zugriff über Console (Proxmox, IPMI, etc.)
2. Manuelle Wiederherstellung:
```bash
# Via Console
echo "ssh-ed25519 AAAA... emergency-key" >> /root/.ssh/authorized_keys
```
3. Führen Sie Playbook erneut aus mit korrekten Schlüsseln
### Problem: Schlüssel werden nicht hinzugefügt
**Symptome**: `good_keys` werden nicht in authorized_keys eingetragen
**Lösung**:
1. Überprüfen Sie Schlüssel-Format:
```bash
ssh-keygen -l -f /path/to/public_key.pub
```
2. Überprüfen Sie Berechtigungen:
```bash
ansible all -i inventories/... \
-m shell -a "ls -la /root/.ssh/" \
-b
```
3. Führen Sie validate-keys Task manuell aus:
```yaml
- include_role:
name: manage-ssh-keys
tasks_from: validate-keys.yml
```
### Problem: Handler werden nicht ausgeführt
**Symptome**: Timestamps oder Kommentare fehlen
**Lösung**:
- Handler laufen erst am Ende des Plays
- Erzwingen Sie Handler-Ausführung:
```yaml
- meta: flush_handlers
```
- Oder führen Sie Playbook mit `--force-handlers` aus
### Problem: Unterschiedliche Schlüssel pro Umgebung
**Symptome**: Dev/Prod benötigen verschiedene Schlüssel-Sets
**Lösung**:
Verwenden Sie separate Variablendateien:
```bash
# Development
ansible-playbook playbooks/hardening/manage-ssh-keys.yaml \
-i inventories/dev.yml \
-e "@vars/ssh-keys-dev.yml" \
-K
# Production
ansible-playbook playbooks/hardening/manage-ssh-keys.yaml \
-i inventories/prod.yml \
-e "@vars/ssh-keys-prod.yml" \
-K
```
**vars/ssh-keys-prod.yml**:
```yaml
good_keys:
- "ssh-ed25519 ... prod-admin-1"
- "ssh-ed25519 ... prod-admin-2"
bad_keys:
- "ssh-rsa ... old-dev-key"
```
---
## Compliance und Audit
### DSGVO / Datenschutz
SSH-Schlüssel-Management unterstützt Compliance durch:
- ✅ **Access Control**: Nur autorisierte Personen
- ✅ **Audit Trail**: Timestamps in authorized_keys
- ✅ **Revocation**: Schnelle Entfernung kompromittierter Keys
- ✅ **Least Privilege**: Spezifische User-Zuordnung
### Audit-Kommandos
```bash
# Liste aller autorisierten Schlüssel
ansible all -i inventories/icp-fra-pve1.yml \
-m shell -a "cat /root/.ssh/authorized_keys" \
-b
# Zähle Schlüssel pro Host
ansible all -i inventories/icp-fra-pve1.yml \
-m shell -a "wc -l /root/.ssh/authorized_keys" \
-b
# Prüfe auf DSA-Schlüssel (veraltet)
ansible all -i inventories/icp-fra-pve1.yml \
-m shell -a "grep 'ssh-dss' /root/.ssh/authorized_keys || echo 'None found'" \
-b
# Letzte Änderung
ansible all -i inventories/icp-fra-pve1.yml \
-m stat -a "path=/root/.ssh/authorized_keys" \
-b
```
---
## Weitere Sicherheits-Maßnahmen
Neben SSH-Schlüssel-Verwaltung gibt es weitere Härtungs-Maßnahmen im Projekt:
### 1. Fail2Ban (nicht implementiert)
Schutz vor Brute-Force-Attacken
### 2. UFW/Firewall (nicht implementiert)
Netzwerk-Level-Zugriffsschutz
### 3. Sudo-Beschränkungen
Siehe `system` Rolle für zukünftige Implementierung
### 4. SELinux/AppArmor
OS-Level Mandatory Access Control
---
## Nützliche Kommandos
### SSH-Schlüssel-Informationen abrufen
```bash
# Alle Schlüssel auf Hosts anzeigen
ansible all -i inventories/icp-fra-pve1.yml \
-m shell \
-a "cat /root/.ssh/authorized_keys | grep -v '^#' | while read line; do echo \$line | ssh-keygen -l -f - 2>/dev/null || echo 'Invalid: '\$line; done" \
-b
# Schlüssel-Typen zählen
ansible all -i inventories/icp-fra-pve1.yml \
-m shell \
-a "cat /root/.ssh/authorized_keys | grep -v '^#' | awk '{print \$1}' | sort | uniq -c" \
-b
```
### Backup erstellen
```bash
# Backup aller authorized_keys Dateien
ansible all -i inventories/icp-fra-pve1.yml \
-m fetch \
-a "src=/root/.ssh/authorized_keys dest=/backup/ssh-keys/{{ inventory_hostname }}-{{ ansible_date_time.date }}/" \
-b
```
---
**Navigation**: [← Zurück: Mail-Server-Verwaltung](04-Mail-Server-Verwaltung.md) | [Nächstes: Virtualisierung →](06-Virtualisierung.md)

553
docs/06-Virtualisierung.md Normal file
View File

@@ -0,0 +1,553 @@
# Virtualisierung (Proxmox)
## Übersicht
Diese Kategorie umfasst die Rolle zur Proxmox VE-Automatisierung, insbesondere für VM-Snapshot-Verwaltung. Die Proxmox-Integration wird von vielen anderen Playbooks genutzt, um Snapshots vor kritischen Operationen zu erstellen.
**Anwendungsfälle**:
- Automatische Snapshot-Erstellung vor OS-Updates
- Automatische Snapshot-Erstellung vor Mailcow-Updates
- Snapshot-Bereinigung nach erfolgreichen Updates
- Rollback-Möglichkeit bei fehlgeschlagenen Operationen
- VM-ID-Ermittlung für API-Operationen
**Proxmox-Cluster**: `icp-fra-pve1` (6 Hosts)
---
## Verwendung in anderen Playbooks
Die Proxmox-Automation-Rolle wird nicht direkt über dedizierte Playbooks aufgerufen, sondern als **integraler Bestandteil** anderer Playbooks verwendet:
### Playbooks mit Proxmox-Integration
| Playbook | Verwendung | Snapshot-Name-Muster |
|----------|------------|----------------------|
| [`os-update.yml`](01-OS-Management.md#os-updateyml) | Snapshot vor OS-Updates | `AUTO_before_os_update_{{ date }}` |
| [`os-major-upgrade.yml`](01-OS-Management.md#os-major-upgradeyml) | Snapshot vor Major-Upgrade | `AUTO_before_major_{{ date }}` |
| [`update-mailcow.yaml`](04-Mail-Server-Verwaltung.md#update-mailcowyaml) | Snapshot vor Mailcow-Update | `pre-mailcow-update-{{ version }}` |
| `cleanups/clean-pve-snapshots.yml` | Snapshot-Löschung | Alle außer "current" |
### Beispiel-Integration in Playbook
```yaml
- name: OS-Update mit Snapshot
hosts: all
become: true
pre_tasks:
- name: Load vault
include_vars: ../vault.yml
when: do_snapshots | bool
tasks:
- name: Get Proxmox VM ID
include_role:
name: proxmox-automation
tasks_from: get-vmid
when: do_snapshots | bool
- name: Create pre-update snapshot
include_role:
name: proxmox-automation
tasks_from: create-snapshots
vars:
snapshot_name: "AUTO_before_update_{{ ansible_date_time.date }}"
when: do_snapshots | bool
# ... Update-Tasks ...
```
---
## Rollen
### Rolle: proxmox-automation
**Zweck**: Automatisiert Proxmox VE VM-Verwaltung, primär für Snapshot-Operationen.
**Pfad**: `roles/proxmox-automation/`
**Hauptaufgaben**:
#### 1. get-vmid.yaml
Ermittelt die Proxmox VM-ID für den aktuellen Host.
**Funktionen**:
- Verwendet Proxmox API zur VM-ID-Ermittlung
- Sucht nach VM mit passendem Hostname
- Setzt `proxmox_vmid` Fact für weitere Operationen
- Delegiert zu localhost (API-Aufruf)
**Benötigte Variablen**:
```yaml
proxmox_host: "pve-cluster.example.com"
proxmox_user: "automation@pve"
proxmox_token_id: "ansible"
proxmox_token_secret: "<aus Vault>"
```
**Verwendung**:
```yaml
- include_role:
name: proxmox-automation
tasks_from: get-vmid
```
**Output**:
```yaml
proxmox_vmid: 100 # VM-ID des aktuellen Hosts
```
**API-Endpunkt**: `GET /api2/json/cluster/resources?type=vm`
---
#### 2. create-snapshots.yaml
Erstellt VM-Snapshots mit automatischer Retention (behält letzten 2).
**Funktionen**:
- Erstellt benannten Snapshot der VM
- Löscht alte Snapshots automatisch
- **Retention**: Behält nur die letzten 2 Snapshots
- Wartet auf Snapshot-Completion
- Delegiert zu localhost (API-Aufruf)
**Benötigte Variablen**:
```yaml
snapshot_name: "pre-update-2026-04-14"
proxmox_vmid: 100 # Aus get-vmid Task
proxmox_host: "pve-cluster.example.com"
proxmox_user: "automation@pve"
proxmox_token_id: "ansible"
proxmox_token_secret: "<aus Vault>"
```
**Verwendung**:
```yaml
- include_role:
name: proxmox-automation
tasks_from: create-snapshots
vars:
snapshot_name: "my-snapshot-{{ ansible_date_time.date }}"
```
**Snapshot-Retention-Logik**:
1. Listet alle existierenden Snapshots auf
2. Sortiert nach Erstellungsdatum
3. Löscht alle außer den letzten 2
4. Erstellt neuen Snapshot
5. Wartet auf Completion
**API-Endpunkte**:
- `GET /api2/json/nodes/{node}/qemu/{vmid}/snapshot`
- `POST /api2/json/nodes/{node}/qemu/{vmid}/snapshot`
- `DELETE /api2/json/nodes/{node}/qemu/{vmid}/snapshot/{snapname}`
**⚠️ Wichtig**: Die Retention von 2 Snapshots ist hardcoded. Ältere Snapshots werden **automatisch gelöscht**.
---
#### 3. delete-snapshots.yaml
Löscht alle Snapshots außer "current" (aktiver Zustand).
**Funktionen**:
- Listet alle Snapshots einer VM auf
- Löscht alle Snapshots außer "current"
- Useful für Cleanup nach erfolgreichen Updates
- Delegiert zu localhost (API-Aufruf)
**Benötigte Variablen**:
```yaml
proxmox_vmid: 100
proxmox_host: "pve-cluster.example.com"
proxmox_user: "automation@pve"
proxmox_token_id: "ansible"
proxmox_token_secret: "<aus Vault>"
```
**Verwendung**:
```yaml
- include_role:
name: proxmox-automation
tasks_from: delete-snapshots
```
**Workflow**:
1. Abruft alle Snapshots der VM
2. Filtert "current" aus (wird nicht gelöscht)
3. Iteriert über verbleibende Snapshots
4. Löscht jeden Snapshot
5. Wartet auf Completion
**API-Endpunkte**:
- `GET /api2/json/nodes/{node}/qemu/{vmid}/snapshot`
- `DELETE /api2/json/nodes/{node}/qemu/{vmid}/snapshot/{snapname}`
**Verwendung**: Siehe [Cleanup-Aufgaben → clean-pve-snapshots.yml](08-Cleanup-Aufgaben.md#clean-pve-snapshotsyml)
---
## Vault-Konfiguration
### Erforderliche Variablen in vault.yml
```yaml
# Proxmox API Credentials
proxmox_host: "pve-cluster.example.com"
proxmox_user: "automation@pve"
proxmox_token_id: "ansible"
proxmox_token_secret: "<generiertes API-Token>"
```
### Proxmox API-Token erstellen
1. **Login to Proxmox Web Interface**
2. **Datacenter → Permissions → API Tokens**
3. **Add API Token**:
- User: `automation@pve` (erstellen falls nicht vorhanden)
- Token ID: `ansible`
- Privilege Separation: **Unchecked** (Token hat alle User-Rechte)
- Expire: Nie oder lang genug
4. **Kopieren Sie den Secret** (nur einmal sichtbar!)
5. **Speichern Sie in vault.yml**
### Benötigte Proxmox-Berechtigungen
Der Automation-User benötigt folgende Berechtigungen:
| Pfad | Berechtigung | Zweck |
|------|--------------|-------|
| `/vms` | `VM.Snapshot` | Snapshots erstellen/löschen |
| `/vms` | `VM.Audit` | VM-Informationen lesen |
| `/` | `Sys.Audit` | Cluster-Ressourcen lesen |
**Minimale Berechtigung**:
```bash
# Via Proxmox CLI
pveum role add AutomationRole -privs "VM.Snapshot,VM.Audit,Sys.Audit"
pveum aclmod / -user automation@pve -role AutomationRole
```
---
## Externe Abhängigkeiten
### Community Proxmox Collection
**Installation**:
```bash
ansible-galaxy collection install community.proxmox:1.5.0
```
**In requirements.yml**:
```yaml
collections:
- name: community.proxmox
version: "1.5.0"
```
**Installation via requirements**:
```bash
ansible-galaxy collection install -r roles/proxmox-automation/requirements.yml
```
### Verwendete Module
- `community.general.proxmox_snap`: Snapshot-Verwaltung
- `community.general.proxmox`: VM-Informationen
- `ansible.builtin.uri`: Für direkte API-Aufrufe
**Dokumentation**:
- https://docs.ansible.com/ansible/latest/collections/community/general/proxmox_snap_module.html
- https://pve.proxmox.com/wiki/Proxmox_VE_API
---
## Best Practices
### 1. Snapshots nur bei kritischen Operationen
Aktivieren Sie Snapshots für:
- ✅ OS Major-Upgrades
- ✅ Mailcow-Updates (große Versionssprünge)
- ✅ Konfigurationsänderungen an kritischen Services
- ❌ Nicht für tägliche OS-Updates (außer bei kritischen Systemen)
```bash
# Mit Snapshots
ansible-playbook playbooks/os-major-upgrade.yml \
-e "do_snapshots=true" \
...
# Ohne Snapshots (schneller, aber riskanter)
ansible-playbook playbooks/os-update.yml \
-e "do_snapshots=false" \
...
```
### 2. Aussagekräftige Snapshot-Namen
Verwenden Sie beschreibende Namen:
```yaml
# Gut
snapshot_name: "pre-mailcow-update-2026-03b"
snapshot_name: "before-debian-trixie-upgrade"
snapshot_name: "AUTO_before_major_2026-04-14"
# Schlecht
snapshot_name: "snapshot1"
snapshot_name: "backup"
```
### 3. Regelmäßiges Snapshot-Cleanup
Bereinigen Sie alte Snapshots nach erfolgreichen Updates:
```bash
# Nach erfolgreichem Update
ansible-playbook playbooks/cleanups/clean-pve-snapshots.yml \
-i inventories/icp-fra-pve1.yml \
-K --ask-vault-pass
```
### 4. Snapshot-Retention beachten
Die Rolle behält automatisch nur die **letzten 2 Snapshots**. Planen Sie entsprechend:
- Tag 1: Snapshot A (vor Update 1)
- Tag 2: Snapshot B (vor Update 2) → Snapshot A bleibt
- Tag 3: Snapshot C (vor Update 3) → Snapshot A wird gelöscht, B bleibt
### 5. Storage-Kapazität überwachen
Snapshots benötigen Speicherplatz:
```bash
# Proxmox Storage-Nutzung prüfen
pvesm status
# Pro VM Snapshot-Größe
qm listsnapshot <vmid>
```
### 6. Snapshot-Limits beachten
Proxmox hat keine harte Snapshot-Anzahl-Begrenzung, aber:
- ⚠️ Zu viele Snapshots degradieren Performance
- ⚠️ Snapshots sind keine Backups (auf gleichem Storage)
- ✅ Maximale Empfehlung: 5-10 Snapshots pro VM
---
## Snapshot-Rollback
### Manuelle Rollback über Proxmox Web-Interface
1. **VM auswählen** in Proxmox
2. **Snapshots** Tab öffnen
3. **Gewünschten Snapshot auswählen**
4. **Rollback** klicken
5. **Bestätigen**
**⚠️ Warnung**: Rollback überschreibt aktuellen Zustand!
### Rollback via CLI (auf Proxmox-Host)
```bash
# Liste Snapshots
qm listsnapshot <vmid>
# Rollback zu Snapshot
qm rollback <vmid> <snapshot-name>
# Beispiel
qm rollback 100 pre-update-2026-04-14
```
### Rollback via Ansible (manuell)
```yaml
- name: Rollback to snapshot
hosts: localhost
tasks:
- name: Proxmox Snapshot Rollback
community.general.proxmox_snap:
api_host: "{{ proxmox_host }}"
api_user: "{{ proxmox_user }}"
api_token_id: "{{ proxmox_token_id }}"
api_token_secret: "{{ proxmox_token_secret }}"
vmid: 100
snapname: "pre-update-2026-04-14"
state: rollback
```
**⚠️ Wichtig**: Nach Rollback ist die VM im Zustand des Snapshots. Alle Änderungen danach gehen verloren!
---
## Fehlerbehebung
### Problem: API-Authentifizierung schlägt fehl
**Symptome**: `401 Unauthorized` oder `403 Forbidden`
**Lösung**:
1. Überprüfen Sie API-Token in vault.yml:
```bash
ansible-vault view vault.yml | grep proxmox
```
2. Testen Sie API-Zugriff manuell:
```bash
curl -k "https://pve-cluster.example.com:8006/api2/json/cluster/resources" \
-H "Authorization: PVEAPIToken=automation@pve!ansible=<token-secret>"
```
3. Überprüfen Sie Benutzerberechtigungen in Proxmox
### Problem: VM-ID kann nicht gefunden werden
**Symptome**: `get-vmid` Task schlägt fehl
**Lösung**:
1. Überprüfen Sie Hostname-Übereinstimmung:
```bash
# Auf Ansible-Host
ansible <host> -m setup -a "filter=ansible_hostname"
# In Proxmox
# VM-Name muss mit Hostname übereinstimmen
```
2. Manuelle VM-ID-Ermittlung:
```bash
pvesh get /cluster/resources --type vm
```
3. Setzen Sie VM-ID manuell:
```yaml
-e "proxmox_vmid=100"
```
### Problem: Snapshot-Erstellung timeout
**Symptome**: Task hängt oder timeout nach langer Zeit
**Lösung**:
1. Überprüfen Sie Proxmox-Storage-Performance
2. Überprüfen Sie Storage-Kapazität:
```bash
pvesm status
```
3. Reduzieren Sie VM-RAM (weniger Snapshot-Größe):
- Snapshots mit RAM benötigen mehr Zeit
- Erwägen Sie `snapshots ohne RAM` (in Proxmox-Config)
4. Erhöhen Sie Ansible-Timeout:
```yaml
async: 3600 # 1 Stunde
poll: 10
```
### Problem: Alte Snapshots werden nicht gelöscht
**Symptome**: Mehr als 2 Snapshots vorhanden
**Lösung**:
1. Manuelle Bereinigung:
```bash
ansible-playbook playbooks/cleanups/clean-pve-snapshots.yml \
-i inventories/... \
-K --ask-vault-pass
```
2. Überprüfen Sie Snapshot-Liste:
```bash
qm listsnapshot <vmid>
```
3. Manuell löschen via CLI:
```bash
qm delsnapshot <vmid> <snapshot-name>
```
### Problem: Nicht genug Speicherplatz für Snapshot
**Symptome**: `no space left on device`
**Lösung**:
1. Überprüfen Sie Storage-Nutzung:
```bash
pvesm status
df -h
```
2. Bereinigen Sie alte Snapshots:
```bash
# Alle VMs, alle Snapshots
for vmid in $(qm list | awk 'NR>1 {print $1}'); do
qm delsnapshot $vmid <old-snapshot-name>
done
```
3. Erweitern Sie Storage oder verschieben Sie VMs
---
## Monitoring und Reporting
### Snapshot-Übersicht abrufen
```bash
# Via Ansible ad-hoc
ansible localhost \
-m uri \
-a "url=https://{{ proxmox_host }}:8006/api2/json/nodes/{{ proxmox_node }}/qemu/{{ vmid }}/snapshot headers={'Authorization':'PVEAPIToken={{ proxmox_user }}!{{ proxmox_token_id }}={{ proxmox_token_secret }}'} validate_certs=no" \
-e @vault.yml \
--ask-vault-pass
# Direkt auf Proxmox-Host
pvesh get /nodes/<node>/qemu/<vmid>/snapshot
```
### Alle Snapshots im Cluster
```bash
# Auf Proxmox-Host
for node in $(pvesh get /nodes --output-format json | jq -r '.[].node'); do
echo "=== Node: $node ==="
for vmid in $(qm list | awk 'NR>1 {print $1}'); do
echo "VM $vmid:"
qm listsnapshot $vmid
done
done
```
---
## Integration mit anderen Systemen
### Backup-Integration
Snapshots sind **keine Backups**! Kombinieren Sie mit echten Backups:
1. **Proxmox Backup Server (PBS)**: Native Integration
2. **Borg/Rsync**: File-Level Backups
3. **3-2-1 Regel**: 3 Kopien, 2 Medien, 1 Offsite
### Monitoring-Integration
Überwachen Sie Snapshots mit CheckMK oder Prometheus:
- Anzahl Snapshots pro VM
- Alter des letzten Snapshots
- Snapshot-Größe
- Failed Snapshot-Operationen
---
## Weiterführende Ressourcen
### Proxmox-Dokumentation
- [Proxmox VE API](https://pve.proxmox.com/wiki/Proxmox_VE_API)
- [Snapshots and Backups](https://pve.proxmox.com/wiki/Storage:_Directory#_snapshots_and_backups)
- [Qemu/KVM Virtual Machines](https://pve.proxmox.com/wiki/Qemu/KVM_Virtual_Machines)
### Ansible Collections
- [community.general.proxmox_snap](https://docs.ansible.com/ansible/latest/collections/community/general/proxmox_snap_module.html)
- [community.general Collections](https://galaxy.ansible.com/community/general)
---
**Navigation**: [← Zurück: Security & Hardening](05-Security-Hardening.md) | [Nächstes: Basis-System →](07-Basis-System.md)

779
docs/07-Basis-System.md Normal file
View File

@@ -0,0 +1,779 @@
# Basis-System
## Übersicht
Diese Kategorie umfasst Playbooks und Rollen für grundlegende Systemkonfiguration und Infrastruktur-Services wie ClamAV-Antivirus, Zeitsynchronisation (Chrony) und allgemeine System-Setup-Aufgaben.
**Anwendungsfälle**:
- Installation von ClamAV-Antivirus-Server
- NTP-Zeitserver-Konfiguration (Chrony)
- Docker-Installation und -Konfiguration
- Basis-Tools-Installation
- System-Härtung
- MOTD-Konfiguration
- Admin-Benutzer-Erstellung
---
## Playbooks
### deploy-clamav-server.yml
Bereitstellung eines dedizierten ClamAV-Antivirus-Servers.
**Datei**: `playbooks/deploy-clamav-server.yml`
**Zweck**: Installation und Konfiguration eines zentralen ClamAV-Servers für Antivirus-Scanning. Dieser Server wird von Mailcow-Instanzen für Malware-Scanning verwendet.
**Ziel-Hosts**: `clamav-servers` (Inventory-Gruppe)
**Benutzer**: `tincadmin` (mit sudo-Rechten)
**Verwendete Rollen**:
- `deploy-clamd`
**Verwendungsbeispiel**:
```bash
# ClamAV-Server bereitstellen
ansible-playbook playbooks/deploy-clamav-server.yml \
-i inventories/icp-fra-pve1.yml \
-K
# Mit spezifischer ClamAV-Version
ansible-playbook playbooks/deploy-clamav-server.yml \
-i inventories/icp-fra-pve1.yml \
-e "clamd_version=1.4.3" \
-K
```
**Abhängigkeiten**:
- `deploy-clamd` Rolle
- Build-Tools (gcc, cmake, Rust)
- Internet-Zugriff für ClamAV-Source-Download
**Besonderheiten**:
- **Kompiliert ClamAV von Source** (Version 1.4.2)
- Installiert FreshClam für Signatur-Updates
- Konfiguriert systemd-Services
- Erstellt dedizierte clamav-User/Group
**Workflow**:
1. Installiert Build-Dependencies
2. Erstellt clamav-Benutzer und -Gruppe
3. Lädt ClamAV-Source herunter
4. Kompiliert mit CMake
5. Installiert Binärdateien
6. Konfiguriert ClamAV-Daemon
7. Konfiguriert FreshClam (Signatur-Updates)
8. Erstellt und startet systemd-Services
**Integration**: Siehe [Mail-Server → migrate-clamd.yaml](04-Mail-Server-Verwaltung.md#migrate-clamdyaml)
**⚠️ Hinweis**: Kompilation kann 10-20 Minuten dauern je nach System-Performance.
---
### setup-chronyd.yml
Setup des Chronyd-NTP-Zeitservers.
**Datei**: `playbooks/setup-chronyd.yml`
**Zweck**: Installation und Konfiguration von Chrony für präzise Zeitsynchronisation auf Debian/Ubuntu-Systemen.
**Ziel-Hosts**: `all` (gefiltert auf Debian/Ubuntu)
**Benutzer**: `tincadmin` (mit sudo-Rechten)
**Verwendete Rollen**:
- `system` (Task: `setup-timeserver`)
**Verwendungsbeispiel**:
```bash
# Chrony auf allen Hosts installieren
ansible-playbook playbooks/setup-chronyd.yml \
-i inventories/icp-fra-pve1.yml \
-K
# Auf einzelnem Host
ansible-playbook playbooks/setup-chronyd.yml \
-i inventories/icp-fra-pve1.yml \
--limit timeserver.example.com \
-K
```
**Abhängigkeiten**:
- `system` Rolle
- Debian/Ubuntu Betriebssystem
**Besonderheiten**:
- **Einfaches Playbook** ohne komplexe Logik
- **Deinstalliert NTPd** (falls vorhanden, Konflikt mit Chrony)
- Installiert Chrony
- Konfiguriert NTP-Pools
- Startet und aktiviert chronyd-Service
**Workflow**:
1. Entfernt ntpd (falls installiert)
2. Installiert chrony-Paket
3. Konfiguriert NTP-Server-Pools
4. Startet chronyd-Service
5. Aktiviert Service beim Boot
**Warum Chrony statt NTP**:
- ✅ Bessere Performance bei instabilen Verbindungen
- ✅ Schnellere Synchronisation nach Boot
- ✅ Geringerer Ressourcenverbrauch
- ✅ Moderne Alternative zu ntpd
---
## Rollen
### Rolle: deploy-clamd
**Zweck**: Kompiliert, konfiguriert und stellt ClamAV-Antivirensoftware bereit.
**Pfad**: `roles/deploy-clamd/`
**Hauptaufgaben**:
#### 1. install-dependencies.yml
Installiert Build-Tools und Abhängigkeiten.
**Installierte Pakete**:
- Build-Essentials: `gcc`, `g++`, `make`, `cmake`
- Rust-Toolchain (für ClamAV 1.4.x)
- Python3 und pip
- Entwicklungsbibliotheken: `libssl-dev`, `libjson-c-dev`, `libpcre2-dev`
- Zusatztools: `wget`, `curl`, `pkg-config`
**Besonderheit**: Installiert Rust über rustup (erforderlich ab ClamAV 1.4.x)
#### 2. setup-clamav-user-group.yml
Erstellt System-Benutzer und -Gruppe für ClamAV.
**Funktionen**:
- Erstellt Gruppe `clamav`
- Erstellt System-User `clamav` (no-login)
- Erstellt Verzeichnisse:
- `/var/lib/clamav` (Datenbank)
- `/var/log/clamav` (Logs)
- `/var/run/clamav` (PID-Files)
- Setzt korrekte Berechtigungen
#### 3. compile-clamav.yml
Lädt ClamAV-Source herunter und kompiliert.
**Funktionen**:
- Download von GitHub (Version 1.4.2)
- Entpackt Source
- Konfiguriert mit CMake:
```bash
cmake . \
-DCMAKE_INSTALL_PREFIX=/usr/local \
-DENABLE_SYSTEMD=ON \
-DENABLE_JSON_SHARED=ON
```
- Kompiliert mit `make -j$(nproc)`
- Installiert mit `make install`
**Dauer**: 10-20 Minuten je nach CPU
#### 4. configure-clamav.yml
Konfiguriert ClamAV-Daemon und FreshClam, erstellt systemd-Services.
**Funktionen**:
- Generiert `clamd.conf` aus Template
- Generiert `freshclam.conf` aus Template
- Erstellt systemd-Service-Files:
- `clamav-daemon.service`
- `clamav-freshclam.service`
- Reload systemd
- Startet Services
**Standardvariablen** (`defaults/main.yml`):
| Variable | Default | Beschreibung |
|----------|---------|-------------|
| `clamd_version` | `1.4.2` | ClamAV-Version zum Kompilieren |
**Templates**:
#### clamav-config.j2
ClamAV-Daemon-Konfiguration.
**Wichtige Einstellungen**:
```ini
LogFile /var/log/clamav/clamd.log
LogFileMaxSize 10M
LogTime yes
LogSyslog yes
# Scanning-Parameter
MaxThreads 4
MaxDirectoryRecursion 15
MaxFileSize 100M
# Network
TCPSocket 3310
TCPAddr 0.0.0.0 # Lauscht auf allen Interfaces
```
#### freshclam-config.j2
FreshClam-Konfiguration (Virus-Signatur-Updates).
**Wichtige Einstellungen**:
```ini
DatabaseDirectory /var/lib/clamav
LogFile /var/log/clamav/freshclam.log
# Update-Häufigkeit
Checks 24 # 24x pro Tag (jede Stunde)
# Update-Quellen
DatabaseMirror database.clamav.net
DatabaseMirror db.local.clamav.net
# SecureInfo URLs für Premium-Signaturen
# (optional, falls lizenziert)
```
#### systemd-clamav-service.j2
Systemd-Service für ClamAV-Daemon.
```ini
[Unit]
Description=ClamAV Antivirus Daemon
After=network.target
[Service]
Type=forking
ExecStart=/usr/local/sbin/clamd
Restart=on-failure
User=clamav
Group=clamav
[Install]
WantedBy=multi-user.target
```
#### systemd-freshclam-service.j2
Systemd-Service für FreshClam.
```ini
[Unit]
Description=ClamAV Virus Database Updater
After=network.target
[Service]
Type=simple
ExecStart=/usr/local/bin/freshclam -d
Restart=on-failure
User=clamav
Group=clamav
[Install]
WantedBy=multi-user.target
```
**Handler**:
| Handler | Funktion |
|---------|----------|
| `Reload Systemd Daemon` | Lädt systemd-Konfiguration neu |
| `Start Clamd Service` | Startet ClamAV-Daemon |
| `Start Freshclam Service` | Startet FreshClam-Service |
**Verwendung**:
```yaml
- name: Deploy ClamAV Server
hosts: clamav-servers
become: true
roles:
- deploy-clamd
```
**Weiterführende Informationen**:
- Scanning-Performance: 50-200 MB/s je nach Hardware
- RAM-Bedarf: ~1-2 GB (für Signatur-Datenbank)
- Signatur-Updates: Automatisch jede Stunde
- Network-Port: 3310 (TCP)
---
### Rolle: system
**Zweck**: Grundlegende Systemkonfiguration und Administration.
**Pfad**: `roles/system/`
**Hauptaufgaben**:
#### 1. install-basic-tools.yaml
Installiert essenzielle System-Tools.
**Installierte Pakete**:
- `git` - Versionskontrolle
- `curl`, `wget` - Download-Tools
- `vim` - Editor
- `htop` - Prozess-Monitor
- `net-tools` - Netzwerk-Tools (ifconfig, netstat)
- `tcpdump` - Netzwerk-Paket-Analyse
- `bind9-dnsutils` - DNS-Tools (dig, nslookup)
- `gnupg` - GPG-Verschlüsselung
- `sudo` - Privilege Escalation
**Verwendung**:
```yaml
- include_role:
name: system
tasks_from: install-basic-tools
```
#### 2. install-docker.yaml
Installiert Docker von offiziellem Repo oder tinc-Mirror.
**Funktionen**:
- Fügt Docker GPG-Key hinzu
- Konfiguriert Docker APT-Repository
- Installiert Docker CE, CLI, containerd
- Konfiguriert Docker-Daemon
- Startet und aktiviert Service
**Variablen**:
```yaml
docker_install_source: "official" # oder "tinc"
```
**Verwendung**:
```yaml
- include_role:
name: system
tasks_from: install-docker
```
**Siehe auch**: [Container-Management → install-docker.yml](03-Container-Management.md#dockerinstall-dockeryml)
#### 3. install-docker-image-mirror.yaml
Konfiguriert Docker HTTP-Proxy für Image-Mirror.
**Funktionen**:
- Installiert CA-Zertifikat für Proxy
- Konfiguriert systemd-Override für Docker
- Setzt HTTP_PROXY, HTTPS_PROXY Environment-Variablen
- Restart Docker-Daemon
**Variablen**:
```yaml
use_docker_image_mirror: true
docker_mirror_location: "SC" # oder "tinc"
```
**Proxy-Server**:
- SC (ServerCow): `dim.servercow.com:3128`
- tinc: `[2a07:6fc0:c:2809::20]:3128`
**Verwendung**:
```yaml
- include_role:
name: system
tasks_from: install-docker-image-mirror
```
#### 4. setup-timeserver.yaml
Installiert und konfiguriert Chrony für NTP.
**Funktionen**:
- Deinstalliert ntpd (Konflikt-Vermeidung)
- Installiert chrony
- Konfiguriert NTP-Pools:
- `0.debian.pool.ntp.org`
- `1.debian.pool.ntp.org`
- `2.debian.pool.ntp.org`
- `3.debian.pool.ntp.org`
- Startet und aktiviert chronyd
**Verwendung**:
```yaml
- include_role:
name: system
tasks_from: setup-timeserver
```
#### 5. ssh-hardening.yaml
Ruft SSH-Schlüssel von URL ab und härtet sshd_config.
**Funktionen**:
- Download autorisierter SSH-Keys von URL
- Konfiguriert sshd_config mit Härtung:
- `PermitRootLogin without-password`
- `PasswordAuthentication no`
- `PubkeyAuthentication yes`
- Moderne Krypto-Algorithmen
- Restart SSH-Service
**Template**: `templates/sshd_config.j2`
**Verwendung**:
```yaml
- include_role:
name: system
tasks_from: ssh-hardening
```
**⚠️ Vorsicht**: Testen Sie auf einem Host zuerst, um Aussperrung zu vermeiden!
#### 6. check-disk-utilization.yaml
Prüft mindestens 4 GB verfügbaren Speicherplatz.
**Funktionen**:
- Ermittelt verfügbaren Speicher auf `/`
- Schlägt fehl wenn weniger als 4 GB frei
- Nützlich vor großen Updates
**Verwendung**:
```yaml
- include_role:
name: system
tasks_from: check-disk-utilization
```
**Verwendung in**: [Mail-Server → update-mailcow.yaml](04-Mail-Server-Verwaltung.md#update-mailcowyaml)
#### 7. special-admin-create.yaml
Erstellt Admin-Benutzer mit Sudo ohne Passwort.
**Funktionen**:
- Erstellt Benutzer `specialadmin` (konfigurierbarer Name)
- Fügt zu `sudo`-Gruppe hinzu
- Konfiguriert passwordless sudo
- Kopiert SSH-Keys
**Verwendung**:
```yaml
- include_role:
name: system
tasks_from: special-admin-create
vars:
admin_username: myadmin
```
#### 8. install-motd.yaml
Installiert custom Message of the Day (MOTD).
**Funktionen**:
- Kopiert MOTD-File von `files/motd`
- Zeigt bei jedem SSH-Login
- Kann Branding, Warnungen, Informationen enthalten
**File**: `roles/system/files/motd`
**Verwendung**:
```yaml
- include_role:
name: system
tasks_from: install-motd
```
**Standardvariablen**:
```yaml
# Docker-Konfiguration
use_docker_image_mirror: true
docker_mirror_location: "SC" # oder "tinc"
docker_install_source: "official"
# NTP-Server
ntp_servers:
- 0.debian.pool.ntp.org
- 1.debian.pool.ntp.org
- 2.debian.pool.ntp.org
- 3.debian.pool.ntp.org
```
**Handler**:
| Handler | Funktion |
|---------|----------|
| `Reload systemd` | Lädt systemd-Konfiguration neu |
| `Restart SSH` | Startet SSH-Daemon neu |
| `Restart Docker` | Startet Docker-Service neu |
| `Restart chronyd` | Startet Chrony-Service neu |
| `Enable Docker` | Aktiviert Docker beim Boot |
| `Start Docker` | Startet Docker-Service |
**Templates**:
#### sshd_config.j2
SSH-Daemon-Konfiguration mit Härtung.
**Wichtige Einstellungen**:
```ini
# Authentifizierung
PermitRootLogin without-password
PasswordAuthentication no
PubkeyAuthentication yes
ChallengeResponseAuthentication no
# Krypto
Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com
KexAlgorithms curve25519-sha256,curve25519-sha256@libssh.org
# Sicherheit
PermitEmptyPasswords no
X11Forwarding no
MaxAuthTries 3
LoginGraceTime 20
```
**Files**:
#### files/motd
Custom Message of the Day.
Kann enthalten:
- Systemidentifikation
- Sicherheitshinweise
- Kontaktinformationen
- Maintenance-Ankündigungen
**Verwendung der Rolle**:
```yaml
# Vollständige System-Setup
- name: System Base Configuration
hosts: all
become: true
roles:
- system
```
---
### Rolle: updates
**Zweck**: Verschiedene Update-Mechanismen für unterschiedliche Distributionen.
**Pfad**: `roles/updates/`
**Hauptaufgaben**:
#### 1. apk-based-update.yaml
Für Alpine Linux Updates.
**Funktionen**:
- `apk update`
- `apk upgrade`
#### 2. apt-based-update.yaml
Für Debian/Ubuntu Updates.
**Funktionen**:
- `apt update`
- `apt dist-upgrade`
- Kernel-Update-Prüfung
#### 3. apt-cleaning.yaml
APT-Cache-Bereinigung.
**Funktionen**:
- `apt clean`
- `apt autoclean`
- `apt autoremove`
#### 4. debian-major-upgrade-apt.yaml
Upgrade auf neue Debian-Hauptversion.
**Funktionen**:
- Ändert Paketquellen
- `apt update`
- `apt dist-upgrade`
**Verwendung**:
Diese Rolle wird als **Fallback** verwendet, wenn spezifischere Rollen nicht passen.
**Siehe bevorzugt**: [`os-updates` Rolle](01-OS-Management.md#rolle-os-updates)
---
## Best Practices
### 1. ClamAV-Server-Dimensionierung
**Empfohlene Hardware**:
- CPU: 2+ Cores
- RAM: 4 GB (2 GB für ClamAV, 2 GB für System)
- Disk: 20 GB (10 GB für Signaturen und Logs)
- Network: Gbit-Ethernet empfohlen
### 2. Chrony-Konfiguration
Verwenden Sie mehrere NTP-Server für Redundanz:
```yaml
ntp_servers:
- 0.de.pool.ntp.org
- 1.de.pool.ntp.org
- ptbtime1.ptb.de # Deutsche Physikalisch-Technische Bundesanstalt
- ptbtime2.ptb.de
```
### 3. Docker-Mirror nutzen
Für schnellere Image-Downloads in internen Netzwerken:
```yaml
use_docker_image_mirror: true
docker_mirror_location: "tinc"
```
### 4. Basis-Tools konsistent installieren
Installieren Sie Basis-Tools auf allen Hosts:
```bash
ansible all -i inventories/icp-fra-pve1.yml \
-m include_role \
-a "name=system tasks_from=install-basic-tools" \
-b
```
### 5. Regelmäßige ClamAV-Signatur-Updates
FreshClam aktualisiert automatisch. Überprüfen Sie regelmäßig:
```bash
# Auf ClamAV-Server
freshclam --version
journalctl -u clamav-freshclam -n 50
```
---
## Fehlerbehebung
### Problem: ClamAV-Kompilation schlägt fehl
**Symptome**: Build-Fehler während `compile-clamav.yml`
**Lösung**:
1. Überprüfen Sie Rust-Installation:
```bash
rustc --version
cargo --version
```
2. Installieren Sie fehlende Dependencies manuell
3. Überprüfen Sie Internet-Verbindung für Source-Download
4. Erhöhen Sie RAM (ClamAV-Build benötigt ~2 GB)
### Problem: Chrony synchronisiert nicht
**Symptome**: Uhrzeit ist falsch oder driftet
**Lösung**:
1. Überprüfen Sie Chrony-Status:
```bash
chronyc tracking
chronyc sources -v
```
2. Testen Sie NTP-Server-Erreichbarkeit:
```bash
chronyc -n sources
ping 0.debian.pool.ntp.org
```
3. Restart Chrony:
```bash
systemctl restart chronyd
```
### Problem: Docker-Mirror funktioniert nicht
**Symptome**: Image-Pulls schlagen fehl oder sind langsam
**Lösung**:
1. Testen Sie Proxy-Erreichbarkeit:
```bash
curl -I http://dim.servercow.com:3128
```
2. Überprüfen Sie Docker-Daemon-Config:
```bash
cat /etc/systemd/system/docker.service.d/http-proxy.conf
```
3. Restart Docker:
```bash
systemctl restart docker
```
### Problem: SSH-Härtung sperrt aus
**Symptome**: Kein SSH-Zugriff nach Härtung
**Prävention**:
- Testen Sie zuerst auf einem Non-Production-Host
- Halten Sie Console-Zugriff bereit (Proxmox, IPMI)
- Behalten Sie eine offene SSH-Session während Änderungen
**Lösung**:
1. Zugriff über Console
2. Revert sshd_config:
```bash
cp /etc/ssh/sshd_config.backup /etc/ssh/sshd_config
systemctl restart sshd
```
---
## Nützliche Kommandos
### ClamAV-Operationen
```bash
# Signatur-Version prüfen
clamdscan --version
# Manueller Scan
clamdscan /path/to/directory
# Signatur-Update manuell
freshclam
# ClamAV-Status
systemctl status clamav-daemon
journalctl -u clamav-daemon -f
```
### Chrony-Operationen
```bash
# Zeitquellen anzeigen
chronyc sources -v
# Synchronisations-Status
chronyc tracking
# Force-Sync (bei großer Drift)
chronyc makestep
# Statistiken
chronyc sourcestats -v
```
### System-Tools
```bash
# Installierte Basis-Tools prüfen
dpkg -l | grep -E 'git|curl|wget|vim|htop'
# Docker-Version
docker --version
docker compose version
# Verfügbarer Speicher
df -h
```
---
**Navigation**: [← Zurück: Virtualisierung](06-Virtualisierung.md) | [Nächstes: Cleanup-Aufgaben →](08-Cleanup-Aufgaben.md)

508
docs/08-Cleanup-Aufgaben.md Normal file
View File

@@ -0,0 +1,508 @@
# Cleanup-Aufgaben
## Übersicht
Diese Kategorie umfasst Wartungs- und Bereinigungsroutinen für verschiedene Systemkomponenten. Regelmäßige Cleanup-Aufgaben sind wichtig für Speicherplatz-Management, Performance-Optimierung und System-Hygiene.
**Anwendungsfälle**:
- Löschen alter Proxmox-Snapshots
- Bereinigung ungenutzter CheckMK-Agent-Plugins
- Entfernung veralteter Docker-Images und -Container
- Speicherplatz-Freigabe
---
## Playbooks
### cleanups/clean-pve-snapshots.yml
Löschen von Proxmox VE Snapshots auf VM-Hosts.
**Datei**: `playbooks/cleanups/clean-pve-snapshots.yml`
**Zweck**: Bereinigung aller Proxmox-VM-Snapshots (außer "current") zur Freigabe von Speicherplatz nach erfolgreichen Updates oder Wartungsarbeiten.
**Ziel-Hosts**: `all`
**Benutzer**: `tincadmin` (mit sudo-Rechten)
**Verwendete Rollen**:
- `proxmox-automation` (get-vmid, delete-snapshots)
**Wichtige Variablen**:
- Keine (verwendet Vault-Variablen)
**Verwendungsbeispiel**:
```bash
# Alle Snapshots auf allen VMs entfernen
ansible-playbook playbooks/cleanups/clean-pve-snapshots.yml \
-i inventories/icp-fra-pve1.yml \
-K --ask-vault-pass
# Nur für spezifische Hosts
ansible-playbook playbooks/cleanups/clean-pve-snapshots.yml \
-i inventories/icp-fra-pve1.yml \
--limit mail-server-01.example.com \
-K --ask-vault-pass
# Mit Verbose-Output
ansible-playbook playbooks/cleanups/clean-pve-snapshots.yml \
-i inventories/icp-fra-pve1.yml \
-v \
-K --ask-vault-pass
```
**Abhängigkeiten**:
- Vault-Datei (`vault.yml`) für Proxmox API-Tokens
- Hosts müssen Proxmox-VMs sein
- Proxmox API-Zugriff
**Besonderheiten**:
- **`gather_facts: false`** - Keine Fact-Sammlung für Performance
- **Löscht ALLE Snapshots** außer "current" (aktiver VM-Zustand)
- **Snapshot-ID-Abruf** vor Löschung
- **API-basiert** - Delegiert zu localhost
**Workflow**:
1. Lädt Vault-Datei mit Proxmox-Zugangsdaten
2. Für jeden Host:
- Ermittelt Proxmox VM-ID
- Listet alle Snapshots auf
- Filtert "current" aus
- Löscht alle verbleibenden Snapshots
3. Gibt Speicherplatz frei
**⚠️ Warnung**: Dieses Playbook löscht **ALLE** Snapshots! Stellen Sie sicher, dass keine wichtigen Snapshots mehr benötigt werden.
**Wann verwenden**:
- Nach erfolgreichen OS-Major-Upgrades
- Nach erfolgreichen Mailcow-Updates
- Monatliche Speicherplatz-Bereinigung
- Vor großen Updates (alte Snapshots entfernen, neue erstellen)
**Siehe auch**: [Virtualisierung → delete-snapshots.yaml](06-Virtualisierung.md#3-delete-snapshotsyaml)
---
### cleanups/cleanup-cmk-agent-plugins.yml
Bereinigung von CheckMK-Agent-Plugins auf überwachten Hosts.
**Datei**: `playbooks/cleanups/cleanup-cmk-agent-plugins.yml`
**Zweck**: Entfernung nicht benötigter oder veralteter CheckMK-Agent-Plugins zur Reduzierung des Monitoring-Overheads.
**Ziel-Hosts**: `all`
**Benutzer**: `tincadmin` (mit sudo-Rechten)
**Verwendete Rollen**:
- `checkmk-monitoring` (Task: `cleanup-agent-plugins`)
**Wichtige Variablen**:
- `checkmk_agent_plugins_to_remove` (aus Rolle)
**Verwendungsbeispiel**:
```bash
# Standard-Cleanup (entfernt Plugins aus defaults/main.yaml)
ansible-playbook playbooks/cleanups/cleanup-cmk-agent-plugins.yml \
-i inventories/icp-fra-pve1.yml \
-K
# Mit custom Plugin-Liste
ansible-playbook playbooks/cleanups/cleanup-cmk-agent-plugins.yml \
-i inventories/icp-fra-pve1.yml \
-e '{"checkmk_agent_plugins_to_remove": ["docker-mailq-monitoring", "old-plugin"]}' \
-K
# Nur auf Mail-Servern
ansible-playbook playbooks/cleanups/cleanup-cmk-agent-plugins.yml \
-i inventories/extern.yml \
-K
```
**Abhängigkeiten**:
- `checkmk-monitoring` Rolle
- CheckMK-Agent muss installiert sein
**Besonderheiten**:
- **Minimales Playbook** - Nur Rollen-Aufruf
- **`gather_facts: false`** - Performance-Optimierung
- **Idempotent** - Mehrfache Ausführung sicher
**Workflow**:
1. Liest Plugin-Liste aus `checkmk_agent_plugins_to_remove`
2. Für jeden Host:
- Lokalisiert CheckMK-Agent-Plugin-Verzeichnis
- Löscht spezifizierte Plugins
- Bereinigt zugehörige Konfigurationsdateien
3. CheckMK-Agent wird automatisch neu geladen
**Standard-Plugins zur Entfernung** (aus `roles/checkmk-monitoring/defaults/main.yaml`):
```yaml
checkmk_agent_plugins_to_remove:
- "docker-mailq-monitoring"
```
**Wann verwenden**:
- Nach Migration zu alternativen Monitoring-Lösungen
- Nach Dekommissionierung von Services
- Bei Performance-Problemen durch zu viele Plugins
- Regelmäßige Bereinigung (quartalsweise)
**Plugin-Verzeichnisse** (typisch):
- `/usr/lib/check_mk_agent/plugins/`
- `/usr/lib/check_mk_agent/local/`
- `/etc/check_mk/`
**Siehe auch**: [Monitoring → Rolle checkmk-monitoring](02-Monitoring.md#5-cleanup-agent-pluginsyaml)
---
## Docker-Cleanup-Playbooks
Die Docker-Cleanup-Playbooks sind in der [Container-Management](03-Container-Management.md)-Kategorie dokumentiert:
- **[docker/cleanup-images.yml](03-Container-Management.md#dockercleanup-imagesyml)** - Bereinigung ungenutzter Docker-Images
- **[docker/cleanup-all.yml](03-Container-Management.md#dockercleanup-allyml)** - Vollständige Docker-Bereinigung
Diese Playbooks sind ebenfalls Teil der Cleanup-Strategie und sollten regelmäßig ausgeführt werden.
---
## Cleanup-Strategie und Best Practices
### 1. Regelmäßige Ausführung
Empfohlener Cleanup-Zeitplan:
| Aufgabe | Häufigkeit | Playbook | Begründung |
|---------|------------|----------|------------|
| Docker-Images | Wöchentlich | `docker/cleanup-images.yml` | Speicherplatz-Management |
| Proxmox-Snapshots | Monatlich | `cleanups/clean-pve-snapshots.yml` | Nach erfolgreichen Updates |
| CMK-Agent-Plugins | Quartalsweise | `cleanups/cleanup-cmk-agent-plugins.yml` | Nach Plugin-Änderungen |
| Docker-Full-Cleanup | Monatlich | `docker/cleanup-all.yml` | Vollständige Bereinigung |
### 2. Automatisierung mit Cron/Systemd-Timer
**Beispiel Cron-Job** (auf Ansible-Control-Node):
```bash
# /etc/cron.d/ansible-cleanup
# Wöchentliches Docker-Image-Cleanup (Sonntag 02:00 Uhr)
0 2 * * 0 ansible-user /usr/local/bin/cleanup-docker-images.sh
# Monatliches Snapshot-Cleanup (1. des Monats, 03:00 Uhr)
0 3 1 * * ansible-user /usr/local/bin/cleanup-snapshots.sh
```
**Wrapper-Script** (`/usr/local/bin/cleanup-docker-images.sh`):
```bash
#!/bin/bash
cd /opt/operating-automation
ansible-playbook playbooks/docker/cleanup-images.yml \
-i inventories/icp-fra-pve1.yml \
>> /var/log/ansible-cleanup.log 2>&1
```
### 3. Pre-Cleanup-Checks
Vor größeren Cleanups:
```bash
# 1. Überprüfen Sie aktuelle Snapshot-Liste
ansible all -i inventories/icp-fra-pve1.yml \
-m shell -a "qm listsnapshot \$(qm list | grep $(hostname) | awk '{print \$1}')" \
-b
# 2. Überprüfen Sie Docker-Speichernutzung
ansible all -i inventories/icp-fra-pve1.yml \
-m shell -a "docker system df" \
-b
# 3. Überprüfen Sie CheckMK-Plugins
ansible all -i inventories/icp-fra-pve1.yml \
-m shell -a "ls -la /usr/lib/check_mk_agent/plugins/" \
-b
```
### 4. Post-Cleanup-Verifizierung
Nach Cleanup-Operationen:
```bash
# 1. Verifizieren Sie freigegebenen Speicherplatz
ansible all -i inventories/icp-fra-pve1.yml \
-m shell -a "df -h /" \
-b
# 2. Überprüfen Sie Service-Status
ansible all -i inventories/icp-fra-pve1.yml \
-m shell -a "systemctl status docker check-mk-agent" \
-b
# 3. Überprüfen Sie ob kritische Snapshots gelöscht wurden
# (manuell im Proxmox Web-Interface)
```
### 5. Backup vor Cleanup
Für sicherheitskritische Cleanups:
```bash
# 1. Erstellen Sie neue Snapshots BEVOR Sie alte löschen
ansible-playbook playbooks/os-update.yml \
-e "do_snapshots=true" \
-e "snapshot_name=pre-cleanup-$(date +%Y%m%d)" \
-i inventories/... \
-K --ask-vault-pass
# 2. Dann Cleanup durchführen
ansible-playbook playbooks/cleanups/clean-pve-snapshots.yml \
-i inventories/... \
-K --ask-vault-pass
```
---
## Speicherplatz-Monitoring
### Speichernutzung überwachen
```bash
# Gesamte Festplattennutzung
ansible all -i inventories/icp-fra-pve1.yml \
-m shell -a "df -h | grep -E 'Filesystem|/$'" \
-b
# Docker-Speichernutzung detailliert
ansible all -i inventories/icp-fra-pve1.yml \
-m shell -a "docker system df -v" \
-b
# Proxmox-Storage-Status
pvesm status
```
### Top-Speicherverbraucher identifizieren
```bash
# Größte Verzeichnisse finden
ansible all -i inventories/icp-fra-pve1.yml \
-m shell -a "du -h / --max-depth=2 2>/dev/null | sort -rh | head -20" \
-b
# Docker-Volume-Größen
ansible all -i inventories/icp-fra-pve1.yml \
-m shell -a "docker system df -v | grep VOLUME -A 100" \
-b
```
---
## Fehlerbehebung
### Problem: Snapshot-Cleanup schlägt fehl
**Symptome**: delete-snapshots Task meldet Fehler
**Lösung**:
1. Überprüfen Sie Proxmox-API-Zugangsdaten in Vault
2. Überprüfen Sie ob Snapshots tatsächlich existieren:
```bash
qm listsnapshot <vmid>
```
3. Versuchen Sie manuelles Löschen:
```bash
qm delsnapshot <vmid> <snapshot-name>
```
4. Überprüfen Sie Proxmox-Logs:
```bash
journalctl -u pveproxy -n 100
```
### Problem: Plugin-Cleanup entfernt benötigte Plugins
**Symptome**: CheckMK-Services fehlen nach Cleanup
**Prävention**:
- Überprüfen Sie `checkmk_agent_plugins_to_remove` Liste vor Ausführung
- Testen Sie auf einzelnem Host zuerst
**Lösung**:
1. Re-installation des CheckMK-Agents:
```bash
ansible-playbook playbooks/reinstall-cmk-agent.yml
```
2. Service-Discovery neu ausführen:
```bash
ansible-playbook playbooks/setup-checkmk-monitoring.yml \
--limit affected-host
```
### Problem: Docker-Cleanup löscht benötigte Images
**Symptome**: Container können nicht starten nach Cleanup
**Prävention**:
- Verwenden Sie `cleanup-images.yml` statt `cleanup-all.yml` für konservatives Cleanup
- Stellen Sie sicher alle Container laufen vor `cleanup-all.yml`
**Lösung**:
1. Re-pull Images:
```bash
cd /opt/mailcow-dockerized
docker-compose pull
docker-compose up -d
```
### Problem: Zu wenig Speicherplatz freigegeben
**Symptome**: Nach Cleanup immer noch hohe Speichernutzung
**Lösung**:
1. Identifizieren Sie Top-Verbraucher:
```bash
du -h / --max-depth=2 | sort -rh | head -20
```
2. Überprüfen Sie Log-Dateien:
```bash
journalctl --vacuum-size=100M
find /var/log -type f -name "*.log" -size +100M
```
3. Bereinigen Sie alte Kernels:
```bash
apt autoremove --purge
```
4. Überprüfen Sie Mailcow-Logs:
```bash
cd /opt/mailcow-dockerized
du -sh data/logs/*
# Bereinigen Sie alte Logs manuell
```
---
## Erweiterte Cleanup-Operationen
### APT-Cache-Bereinigung
```bash
# Auf allen Hosts
ansible all -i inventories/icp-fra-pve1.yml \
-m apt -a "autoclean=yes" \
-b
ansible all -i inventories/icp-fra-pve1.yml \
-m apt -a "autoremove=yes purge=yes" \
-b
```
### Journalctl-Log-Rotation
```bash
# Logs älter als 30 Tage löschen
ansible all -i inventories/icp-fra-pve1.yml \
-m shell -a "journalctl --vacuum-time=30d" \
-b
# Logs auf max 500MB begrenzen
ansible all -i inventories/icp-fra-pve1.yml \
-m shell -a "journalctl --vacuum-size=500M" \
-b
```
### Alte Kernel-Versionen entfernen
```bash
# Automatische Entfernung alter Kernels (Debian)
ansible all -i inventories/icp-fra-pve1.yml \
-m apt -a "autoremove=yes purge=yes" \
-b
```
### Mailcow-Log-Bereinigung
```bash
# Alte Mailcow-Logs löschen (älter als 30 Tage)
ansible all -i inventories/extern.yml \
-m shell -a "find /opt/mailcow-dockerized/data/logs -type f -mtime +30 -delete" \
-b
```
---
## Cleanup-Checkliste
Verwenden Sie diese Checkliste für monatliche Wartung:
- [ ] **Pre-Check**: Speichernutzung dokumentieren
- [ ] **Backup**: Wichtige Snapshots oder Backups erstellen
- [ ] **Docker-Images**: `playbooks/docker/cleanup-images.yml` ausführen
- [ ] **Proxmox-Snapshots**: `playbooks/cleanups/clean-pve-snapshots.yml` ausführen (nach erfolgreichen Updates)
- [ ] **CMK-Plugins**: `playbooks/cleanups/cleanup-cmk-agent-plugins.yml` ausführen (quartalsweise)
- [ ] **APT-Cache**: `apt autoclean` und `apt autoremove` auf allen Hosts
- [ ] **Logs**: Journalctl und Application-Logs rotieren
- [ ] **Post-Check**: Speicherplatz-Freigabe verifizieren
- [ ] **Monitoring**: Services und Container-Status prüfen
- [ ] **Dokumentation**: Cleanup-Ergebnisse dokumentieren
---
## Nützliche Kommandos
### Speicherplatz-Analyse
```bash
# Top 10 größte Verzeichnisse
ansible all -i inventories/... \
-m shell -a "du -h / --max-depth=2 2>/dev/null | sort -rh | head -10" \
-b
# Inode-Nutzung
ansible all -i inventories/... \
-m shell -a "df -i" \
-b
```
### Cleanup-Status
```bash
# Anzahl Docker-Images
ansible all -i inventories/... \
-m shell -a "docker images | wc -l" \
-b
# Anzahl Snapshots pro VM
pvesh get /nodes/<node>/qemu/<vmid>/snapshot
# CheckMK-Plugin-Liste
ansible all -i inventories/... \
-m shell -a "ls /usr/lib/check_mk_agent/plugins/ | wc -l" \
-b
```
---
## Zusammenfassung
Cleanup-Aufgaben sind essentiell für:
-**Speicherplatz-Management**: Verhindert Disk-Full-Situationen
-**Performance**: Reduziert Overhead durch alte Snapshots/Images
-**Sicherheit**: Entfernt veraltete Software-Komponenten
-**Compliance**: Erfüllt Datenaufbewahrungsrichtlinien
-**Wartungsfreundlichkeit**: Übersichtlichere Systeme
**Empfohlene Cleanup-Routine**:
1. Wöchentlich: Docker-Image-Cleanup
2. Monatlich: Vollständiges Docker-Cleanup, APT-Cache
3. Nach Updates: Proxmox-Snapshot-Cleanup
4. Quartalsweise: CheckMK-Plugin-Cleanup, Log-Rotation
---
**Navigation**: [← Zurück: Basis-System](07-Basis-System.md) | [Zurück zur Übersicht](00-Übersicht.md)