oopen-server/roles/ipt-server/MIGRATION.md

ipt-server — Migrationsleitfaden

Dieser Leitfaden beschreibt, wie ein bestehender Host vom alten Verfahren (manuell verwaltete /etc/ipt-firewall/-Dateien, ggf. firewall- oder modify-ipt-server-Rolle) auf die neue ipt-server-Ansible-Rolle umgestellt wird.

---

Überblick

Das alte Verfahren:

• Firewall-Skripte und Conf-Dateien wurden manuell oder über die alte firewall-Rolle (lineinfile/blockinfile) gepflegt.
• Änderungen direkt in /etc/ipt-firewall/ auf dem Host.

Das neue Verfahren:

• Alle Firewall-Einstellungen liegen in host_vars/<hostname>/ipt_firewall.yml.
• Ansible deployt die Config-Dateien aus Jinja2-Templates.
• Direktes Editieren auf dem Host ist nicht mehr vorgesehen.

Die Migration ist nicht-destruktiv: Bestehende Config-Dateien werden erst dann überschrieben, wenn die Migration explizit freigegeben wird (fw_manage_config: true).

---

Schritt 1 — Aktuelle Konfiguration auslesen

Das Skript extract-fw-host-vars.py liest die vier Conf-Dateien vom Host via SSH, mappt alle Variablen auf die fw_*-Ansible-Variablen und schreibt eine fertige host_vars-Datei:

cd /path/to/ansible/oopen-server

./extract-fw-host-vars.py <hostname> --sudo \
  -o host_vars/<hostname>/ipt_firewall.yml

Das Skript fragt einmalig nach dem sudo-Passwort.

Ergebnis prüfen:

cat host_vars/<hostname>/ipt_firewall.yml

Kontrollpunkte:

• Sind fw_ext_interfaces, fw_ext_ips_v4, fw_ext_ips_v6 korrekt?
• Sind aktivierte Dienste (Mail, HTTP, VPN usw.) vorhanden?
• Sind munin_remote_ipv4 / munin_remote_ipv6 eingetragen (falls Munin läuft)?

Fehlende oder falsche Werte können direkt in der YAML-Datei korrigiert werden. Alle Variablen und ihre Bedeutung stehen in defaults/main.yml.

---

Schritt 2 — Erste Ausrollung (Safety-Guard aktiv)

Solange fw_manage_config nicht auf true gesetzt ist (Default: false), überschreibt Ansible keine bestehenden Config-Dateien. Es werden nur installiert:

• Firewall-Skripte → /usr/local/sbin/
• Geteilte Conf-Dateien → /etc/ipt-firewall/
• Systemd-Units → /etc/systemd/system/

# Vorschau:
ansible-playbook ipt-server.yml --limit <hostname> --check --diff

# Ausrollen:
ansible-playbook ipt-server.yml --limit <hostname>

Die Firewall wird dabei nicht neu gestartet — die bestehenden Config-Dateien bleiben unangetastet.

---

Schritt 3 — Verifizieren: sind die Rules identisch?

Dieser Schritt prüft, ob ein Neustart der Firewall mit den neuen Skripten und den bestehenden Config-Dateien exakt dieselben iptables-Rules erzeugt wie aktuell geladen.

ssh <hostname> '
  # Aktuellen Stand einfrieren (Timestamps und Zähler normalisieren)
  iptables-save  | grep -v "^#" | sed "s/\[[0-9]*:[0-9]*\]/[0:0]/g" \
    > /tmp/fw_before_v4.rules
  ip6tables-save | grep -v "^#" | sed "s/\[[0-9]*:[0-9]*\]/[0:0]/g" \
    > /tmp/fw_before_v6.rules

  # Firewall neu starten
  systemctl restart ipt-firewall
  systemctl restart ip6t-firewall

  # Neuen Stand einfrieren
  iptables-save  | grep -v "^#" | sed "s/\[[0-9]*:[0-9]*\]/[0:0]/g" \
    > /tmp/fw_after_v4.rules
  ip6tables-save | grep -v "^#" | sed "s/\[[0-9]*:[0-9]*\]/[0:0]/g" \
    > /tmp/fw_after_v6.rules

  # Vergleichen
  echo "=== IPv4 diff ==="
  diff /tmp/fw_before_v4.rules /tmp/fw_after_v4.rules
  echo "=== IPv6 diff ==="
  diff /tmp/fw_before_v6.rules /tmp/fw_after_v6.rules
'

Erwartetes Ergebnis: Beide Diffs sind leer.

Falls Unterschiede erscheinen: die abweichenden Rules identifizieren, die entsprechenden Variablen in host_vars/<hostname>/ipt_firewall.yml nachpflegen und den Diff wiederholen bevor weitergemacht wird.

---

Schritt 4 — Ansible als autoritative Quelle freischalten

Erst wenn Schritt 3 erfolgreich war (leere Diffs), wird die Migration abgeschlossen. Dazu fw_manage_config: true in der host_vars-Datei setzen:

# host_vars/<hostname>/ipt_firewall.yml
---
fw_manage_config: true   # ← hinzufügen / auf true setzen

fw_ext_interfaces:
  - "eth0"
# ...

Dann erneut ausrollen:

# Vorschau — zeigt jetzt auch die Config-Dateien im Diff:
ansible-playbook ipt-server.yml --limit <hostname> --check --diff

# Anwenden:
ansible-playbook ipt-server.yml --limit <hostname>

Ab jetzt:

• Ansible überschreibt die vier Config-Dateien bei jedem Run aus den Templates.
• Bei Änderungen an Templates oder host_vars wird die Firewall automatisch neu gestartet.
• Direktes Editieren von /etc/ipt-firewall/interfaces_*.conf oder main_*.conf auf dem Host wird beim nächsten Ansible-Run überschrieben.

---

Schritt 5 — Altes System deaktivieren

Altes Ansible-Vorgehen abschalten

Sicherstellen, dass der Host nicht mehr durch die alte firewall-Rolle oder modify-ipt-server-Rolle verwaltet wird. Falls der Host in einem Playbook eingetragen ist, das diese Rollen verwendet, den Host dort entfernen oder das Playbook anpassen.

Altes git-Repository auf dem Host entfernen (optional)

Das Repository /usr/local/src/ipt-server wird von der neuen Rolle nicht mehr benötigt. Es kann entfernt werden:

ssh <hostname> 'rm -rf /usr/local/src/ipt-server'

Vorher prüfen, ob das Verzeichnis noch anderweitig verwendet wird.

Sicherstellen, dass niemand mehr direkt editiert

Da fw_manage_config: true gesetzt ist, werden direkte Änderungen in /etc/ipt-firewall/ beim nächsten Ansible-Run überschrieben. Als zusätzliche Absicherung kann eine kurze Warnung oben in die Config-Dateien geschrieben werden — das erledigt Ansible automatisch über den {{ ansible_managed }}-Kommentar am Anfang jedes generierten Templates:

# Ansible managed
# DO NOT EDIT - changes will be overwritten on the next Ansible run.
# Edit host_vars/<hostname>/ipt_firewall.yml instead.

---

Zusammenfassung

Schritt	Befehl / Aktion	Wann
1	extract-fw-host-vars.py ausführen	Einmalig pro Host
2	ansible-playbook ... --check --diff + ausrollen	Einmalig pro Host
3	iptables-Rules vergleichen (vor/nach Restart)	Einmalig pro Host
4	fw_manage_config: true setzen + ausrollen	Einmalig pro Host
5	Alte Rolle deaktivieren, git-Repo auf Host entfernen	Einmalig pro Host
—	Änderungen: host_vars editieren + ansible-playbook	Ab jetzt immer so