# SESSION_HANDOFF — kube-bot

Stand: 2026-06-14 09:53 UTC

## Backup/Restore-Abstimmung — dmz-backup (2026-06-20)

- Neue Zielstrecke mit diskstation-bot/Mislav abgestimmt: K3s/DMZ pusht nach `dmz-backup` (`192.168.20.90`), Synology pullt von dort und bleibt Langzeit-Backup-Master.
- Kube-bot-Anforderungen dokumentiert in `/home/node/.openclaw/workspace/inventory/backup-strategy-draft.md`, Abschnitt `K3s-Anforderungen an neue DMZ-Backup-Strecke (2026-06-20)`.
- Aus Cluster-Sicht wichtig: pro Namespace/Tenant getrennte Artefakte, keine Klartext-Secrets, clientseitige Verschlüsselung bei Secret-, Credential-, Datenbank- oder personenbezogenem Inhalt, klare Zuordnung `PVC -> Longhorn Volume -> Backup-Artefakt`.
- `dmz-backup` darf keine dauerhaften Passphrases oder Private Keys halten; Metadaten enthalten nur Verschlüsselungsstatus, Key-/Secret-Referenz und Fingerprint ohne Werte.
- Restore-Tests zuerst isoliert in `restore-test-*` Namespaces mit neuen PVCs, ohne produktiven Ingress/Traffic und ohne produktive PVCs zu überschreiben.
- Keine echten Backup-Jobs, Longhorn-Zieländerungen, Credential-Anlagen oder Restore-Ausführungen ohne explizites OK von Mislav.
- Mislav bevorzugt als ersten Pilot `platform/cluster/prod` / Control-Plane-Konfiguration. Zielpfad: `k3s-dmz/platform/cluster/prod/`. Scope ist nur read-only Export + clientseitig verschluesselte Ablage + Synology-Pull + Artefakt-/Manifest-/Checksum-Pruefung aus Staging; kein produktiver Control-Plane- oder etcd-Restore.
- Mislav korrigierte danach: erster Pilot lieber mit banaler App Homarr. Kube-bot hat Phase-1 lokal vorbereitet:
  - Arbeitsverzeichnis: `/home/node/.openclaw/workspace/backups/homarr-pilot-20260620T073545Z`.
  - Archiv: `/home/node/.openclaw/workspace/backups/20260620T073545Z__dmz-k3s__pidoka__homarr__metadata__pilot.tar.gz`.
  - SHA256: `b698c3b0456c36950338838a7b98bb83d63290852a75feab44b9e803e7dc9793`.
  - Enthalten: Manifeste, PVC/PV/Longhorn-Metadaten, GitOps-Artefakte, redaktierte Secret-Metadaten, Checksums, Restore-Notizen.
  - Nicht enthalten: Secretwerte, PVC-Dateiinhalte, Longhorn Snapshots/Backups.
  - Nicht erfolgt: Push nach `dmz-backup`, Verschluesselung mit improvisierter Passphrase, Cluster-Aenderungen.
  - Blocker: Verschluesselungswerkzeug + Empfaenger-Key/Infisical-Pfad finalisieren; `dmz-backup` SSH Host-Key/technischen User verifizieren.
- Homarr Phase-1 Push abgeschlossen/verifiziert — 2026-06-20 17:57 UTC:
  - `age` ist in der OpenClaw Shared-Tool-Ablage vorhanden: `/home/node/shared/tools/age` und `/home/node/shared/tools/age-keygen`, jeweils `v1.3.1`.
  - Age-Keypair fuer Homarr liegt in Infisical `Backup_Restore/prod`; dokumentiert werden nur die Secretnamen `BACKUP_HOMARR_AGE_RECIPIENT` und `BACKUP_HOMARR_AGE_PRIVATE_KEY`.
  - SSH-/Zielwerte fuer `dmz-backup` liegen in Infisical `Backup_Restore/prod` unter `DMZ_BACKUP_HOST`, `DMZ_BACKUP_SSH_USER`, `DMZ_BACKUP_SSH_PRIVATE_KEY`, `DMZ_BACKUP_SSH_PUBLIC_KEY`, `DMZ_BACKUP_SSH_KEY_FINGERPRINT`, `DMZ_BACKUP_SSH_HOSTKEY_ED25519_SHA256`, `DMZ_BACKUP_HOMARR_TARGET_PATH`.
  - Frisches lokales Paket: `/home/node/.openclaw/workspace/backups/20260620T104142Z__dmz-k3s__pidoka__homarr__metadata__pilot.tar.gz`.
  - Klartext-Paket SHA256: `64802165be001fd7c5dab1a59bf0f97934ce47aa31863fcf0c622d0bfa66db87`.
  - Verschluesseltes Paket: `/home/node/.openclaw/workspace/backups/20260620T104142Z__dmz-k3s__pidoka__homarr__metadata__pilot.tar.gz.age`.
  - Verschluesseltes Paket SHA256: `b90154a732f756a10de218f30d28fa9afd8bd15644781aa207011188ca4a5f19`.
  - Remote-Ziel: `/srv/dmz-backup/k3s-dmz/tenants/pidoka/prod/homarr/20260620T104142Z__dmz-k3s__pidoka__homarr__metadata__pilot.tar.gz.age`.
  - Verifiziert: Infisical Login ohne Ausgabe von Secretwerten, `dmz-backup` ED25519 Host-Key-Fingerprint gegen Infisical, lokale Age-Decrypt-Probe gegen Klartext-SHA, Remote-Datei vorhanden, Remote-SHA passt.
  - Nicht enthalten/erfolgt: keine Secretwerte, keine PVC-Dateiinhalte, keine Longhorn Snapshots/Backups, keine Cluster-Aenderung, kein Private Key auf `dmz-backup`.
  - Naechster sinnvoller Schritt: diskstation-bot/Synology-Pull dieses `.age`-Artefakts pruefen lassen; danach Restore-Test nur als Artefakt-/Decrypt-/Checksum-Pruefung in Staging, nicht gegen produktive PVCs.
- Pause durch Mislav am 2026-06-20 07:46 UTC:
  - Frage zum technischen SSH-Zugang ging ausdruecklich nur an diskstation-bot; kube-bot hat nicht im Channel geantwortet.
  - Mislav plant in Infisical/Intranet einen Ordner `Backup_Restore`; beide Bots sollen dort Zugriff erhalten.
  - Erwartung: technische SSH-Zugaenge/Keys fuer `dmz-backup` werden dort abgelegt, keine Keywerte in Slack oder lokalen Notizen.
  - Naechster kube-bot-Schritt nach Pause: erst pruefen, welche Infisical-Referenzen/Key-Fingerprints freigegeben sind, dann clientseitige Verschluesselung und `dmz-backup` Host-Key-Verifikation fortsetzen.
- Restic/Kopia Einordnung 2026-06-20:
  - Fuer Homarr Phase 1 nicht noetig; weiter SSH/SFTP + clientseitig verschluesseltes Artefakt.
  - `dmz-backup` bleibt dummes Staging ohne dauerhafte Keys/Passphrases und ohne aktive Backup-Logik.
  - Restic ist spaeter sinnvoll fuer echte Datei-/App-/DB-Dump-Backups; Repo kann per Ordner/SFTP auf `dmz-backup` liegen, Passphrase/Recipient-Referenz in Infisical `Backup_Restore`.
  - Kopia/MinIO/S3 erst separat bewerten, wenn Longhorn oder spaetere zentrale Policies es benoetigen.
- Infisical `Backup_Restore` Zugriff geprueft — 2026-06-20 09:28 UTC:
  - Intranet-Infisical: `http://192.168.1.121:8088`.
  - Universal Auth Login mit vorhandenen kube-bot Runtime-Credentials erfolgreich; Token nicht ausgegeben.
  - Projekt sichtbar: `Backup_Restore`.
  - Projekt-ID: `ba0a79d9-32fe-474c-be2f-88384a3d9749`.
  - Slug: `backup-restore-rb-he`.
  - Organisation/Org-ID laut API: `2e714d13-a322-4947-a8b0-4ea91a29691a`.
  - Environments vorhanden: `dev`, `staging`, `prod`.
  - Keine Secretwerte gelesen oder ausgegeben.
  - Naechster sicherer Schritt nach Freigabe: Pfad-/Key-Namensschema fuer Backup/Restore unter `Backup_Restore/prod` festlegen, z. B. SSH-Zieluser, Host-Key-Fingerprint, Restic/age/passphrase-Referenzen.
- Vorgeschlagenes Namensschema fuer `Backup_Restore/prod` von diskstation-bot, durch kube-bot akzeptiert:
  - `DMZ_BACKUP_HOST`
  - `DMZ_BACKUP_SSH_HOSTKEY_ED25519_SHA256`
  - `DMZ_BACKUP_SSH_USER`
  - `DMZ_BACKUP_SSH_PRIVATE_KEY`
  - `DMZ_BACKUP_SSH_PUBLIC_KEY`
  - `DMZ_BACKUP_SSH_KEY_FINGERPRINT`
  - `DMZ_BACKUP_HOMARR_TARGET_PATH`
  - `BACKUP_HOMARR_AGE_RECIPIENT`
  - `BACKUP_HOMARR_AGE_PRIVATE_KEY`
  - alternativ spaeter `RESTIC_PASSWORD`
- Tool-Stand kube-bot Runtime:
  - Korrigiert/verifiziert 2026-06-20 17:54 UTC: `age` und `age-keygen` vorhanden unter `/home/node/shared/tools/`, Version `v1.3.1`.
  - `restic` nicht vorhanden.
  - `openssl` vorhanden.
  - Empfehlung: Phase 1 bleibt `age`; fuer echte Datei-/PVC-/DB-Backups spaeter Restic separat evaluieren.

## Aktueller Zustand
- IT15 ist Management-Ziel.
- One-Node-K3s auf IT15 läuft.
- Neues Argo CD auf IT15 läuft im Namespace `argocd`, Service `argocd-server`, bewusst nur `ClusterIP`/nicht exponiert.
- Bestehendes DMZ-Argo-CD bleibt unverändert bis Parallelbetrieb + Rollback-Gate erfolgreich sind.
- Infisical auf IT15 läuft lokal in Docker/WSL; API erreichbar unter `http://192.168.1.121:8088`.
- Infisical Backup/Restore-Gate war grün.
- Keine Secretwerte werden in Slack/Logs ausgegeben.

## Infisical Stand
- Fachliche Ziel-Organisation für Cattaro-Betrieb: `cattaro_gmbh`.
- `Admin Org` ist nicht mehr Default/Fachgrenze für Cattaro-Infrastruktur.
- Runtime-Variablen aktuell vorhanden:
  - `INFISICAL_CLIENT_ID` gesetzt.
  - `INFISICAL_AUTH_KEY` gesetzt.
- Universal Auth Login mit aktueller Cattaro-Client-ID erfolgreich getestet am 2026-06-14 09:52 UTC.
- Token wurde empfangen, aber nicht ausgegeben.
- `/api/v1/projects` liefert genau 1 sichtbares Projekt:
  - Name: `platform-kubernetes`
  - Slug: `platform-kubernetes-lk-mr`
  - ID: `c5e8661f-4b7a-43e1-80b0-8674f30950dc`
- `/api/v2/projects` existiert auf dieser Instanz nicht / 404.

## Konzeptentscheidung Mandanten / Fachanwendungen
- Cattaro GmbH wird als eigene fachliche Grenze modelliert.
- Externe Mandanten werden später separat modelliert.
- Zielmodell:
  - Infisical: Org `cattaro_gmbh`; Projekt `platform-kubernetes` für Cattaro-Platform/Kubernetes; später `tenant-cattaro` oder app-/mandantenspezifische Projekte nach Bedarf.
  - Argo CD: Platform-AppProjects (`platform-core`, `platform-security`, `platform-observability`) und Tenant-AppProject `tenant-cattaro`.
  - Kubernetes: Platform-Namespaces getrennt von Fachanwendungs-Namespaces, z.B. `platform-argocd`, `platform-secrets`, `tenant-cattaro-stage`, `tenant-cattaro-prod`.
- Keine mandantenübergreifenden Machine Identities.
- Keine globalen Tokens in Argo CD oder Workloads.
- Produktiv-/Stage-/Dev-Identities strikt trennen.
- Konzeptdatei aktualisiert:
  - `/home/node/.openclaw/workspace/INFISICAL_ARGO_K3S_KONZEPT.md`

## Guardrails
- Kein DB-Bootstrap als nächster Schritt.
- DB-Bootstrap nur letzte Option, mit frischem Backup/Restore-Gate und explizitem OK von Mislav.
- Keine schreibenden Infisical-Änderungen ohne explizites OK.
- Keine Argo-CD Credential-Rotation ohne explizites OK.
- Keine Änderungen an DMZ-K3s ohne explizites OK.
- Secrets/Tokens/kubeconfigs niemals im Klartext posten.

## Nächste sichere Schritte
1. Lesend weiter prüfen, welche Environments/Secrets-Metadaten im Projekt `platform-kubernetes` vorhanden sind, ohne Secretwerte auszugeben.
2. Minimalen Zielpfad für kube-bot/Argo-CD Credentials festlegen.
3. Danach mit OK: Argo-CD Admin-Credential rotieren und direkt in Infisical speichern.
4. Danach mit OK: DMZ-K3s mit eingeschränktem Pilot-ServiceAccount/RBAC an IT15-Argo-CD anbinden.
5. Danach Pilotdeployment für unkritische Cattaro-App in `tenant-cattaro-stage`.

## Wichtige Pfade / IDs
- Plan: `/home/node/.openclaw/workspace/ARGOCD_IT15_INFISICAL_PIDOKA_PLAN.md`
- Handoff: `/home/node/.openclaw/workspace/SESSION_HANDOFF.md`
- Konzept: `/home/node/.openclaw/workspace/INFISICAL_ARGO_K3S_KONZEPT.md`
- IT15: `Misla@192.168.1.121`
- Infisical app path: `/opt/infisical`
- Infisical backup grün: `/root/infisical-backups/backup-20260613-080228`

## Ergänzung — Zielkorrektur und offene Aufgaben (2026-06-15 08:34 UTC)

- SSH ist jetzt als Zugriffspfad für den operativen DMZ-K3s-Kontext vorgesehen.
- Ziel bleibt: IT15/Intranet-Argo-CD steuert Deployments in den operativen DMZ-K3s-Cluster.
- Die Dummy-Testanwendung darf nicht auf dem IT15-Management-K3s verbleiben; sie ist als Pilot für den DMZ-Zielcluster zu verwenden.
- Vor dem Pilotdeployment ist read-only zu prüfen, ob und wo die irrtümliche Dummy-App auf IT15 existiert, damit sie später nach explizitem OK sauber entfernt oder ignoriert werden kann.
- Zusätzlich offene Secret-Aufgabe: kube-bot/OpenClaw SSH-Private-Keys sollen in Infisical gesichert werden, weil lokale SSH-Keys nach OpenClaw-Updates verloren gehen können.
- Für SSH-Key-Sicherung gilt: keine Private-Key-Inhalte in Slack/Logs; Ablage nur über sicheren Infisical-Write-Pfad und nur nach explizitem OK.

## Demo Deployment Status — 2026-06-15 12:36 UTC

- SSH/sudo Zugriff auf DMZ Control-Plane `kube-bot@192.168.20.40` funktioniert.
- IT15 Management-K3s und Argo CD sind gesund.
- IT15 kann DMZ Kubernetes API `192.168.20.40:6443` erreichen.
- Pilot-Namespace im DMZ-Cluster angelegt: `tenant-cattaro-stage`.
- Restricted Argo CD ServiceAccount im DMZ-Cluster angelegt: `tenant-cattaro-stage/argocd-demo-manager`.
- IT15 Argo CD Zielcluster-Secret registriert für DMZ-Cluster, beschränkt auf Namespace `tenant-cattaro-stage`.
- Demo-Application in IT15 Argo CD: `argocd/demo-guestbook-cattaro-stage`.
- Quelle: `https://github.com/argoproj/argocd-example-apps.git`, Pfad `guestbook`.
- Ziel: DMZ-Cluster Namespace `tenant-cattaro-stage`.
- Status: `Synced` / `Healthy`.
- Direkte DMZ-Verifikation: `deployment/guestbook-ui` rollout erfolgreich; Service `guestbook-ui` intern per curl erreichbar.

Hinweise:
- Kein Ingress/Public Exposure für die Demo-App angelegt.
- RBAC für den Pilot ist namespace-weit administrativ plus minimale Discovery-Rechte, aber nicht cluster-admin.
- Tokens/Secrets wurden nicht in Slack ausgegeben.


## SSH-Zugangsmerker — 2026-06-15 13:00 UTC

- Aktuelle OpenClaw Runtime: User `node`, Host/Container `0e9d9d0b8619`.
- Lokaler SSH-Key: `/home/node/.ssh/kube-bot-it15-ed25519`.
- Funktionierender DMZ-Control-Plane-Zugang: `kube-bot@192.168.20.40` mit `-i ~/.ssh/kube-bot-it15-ed25519`.
- Auf `192.168.20.40` funktioniert `sudo kubectl --kubeconfig=/etc/rancher/k3s/k3s.yaml ...`.
- Nicht verwenden: `sudo KUBECONFIG=/etc/rancher/k3s/k3s.yaml kubectl ...`, weil sudo das Setzen von `KUBECONFIG` blockiert.
- IT15 `Misla@192.168.1.121` ist aus aktueller Runtime derzeit nicht per SSH erreichbar (`Permission denied`); User/Key muss bestätigt oder neu eingerichtet werden.
- Keine SSH-Private-Key-Inhalte in Slack oder Markdown dokumentieren.

## IT15 SSH-Korrektur — 2026-06-15 14:15 UTC

- Korrektes IT15 SSH-Ziel aus OpenClaw Runtime: `Misla@192.168.1.121`.
- Korrektes Kommandomuster: `ssh -i /home/node/.ssh/kube-bot-it15-ed25519 Misla@192.168.1.121`.
- IT15 ist Windows; Linux/K3s-Kontext läuft in WSL Distribution `Ubuntu`.
- Korrektes WSL-Kommandomuster: `ssh -i /home/node/.ssh/kube-bot-it15-ed25519 Misla@192.168.1.121 "wsl.exe -d Ubuntu -e bash -lc '<command>'"`.
- Verifiziert: IT15 Management-K3s `it15-mgmt` Ready, Argo CD Pods Running.
- ArgoCD Apps gefunden:
  - `demo-guestbook-cattaro-stage`: dest `https://192.168.20.40:6443`, namespace `tenant-cattaro-stage`, `Synced/Healthy` — korrektes DMZ-Ziel.
  - `guestbook`: dest `https://kubernetes.default.svc`, namespace `tenant-cattaro-stage`, `Synced/Healthy` — lokale/Intranet-App, später nach explizitem OK entfernen.

## Infisical Recovery-Ablage — kube-bot SSH Keys — 2026-06-15 14:29 UTC

- SSH-Recovery-Secrets liegen in Infisical:
  - Projekt: `platform-kubernetes` (`c5e8661f-4b7a-43e1-80b0-8674f30950dc`)
  - Environment: `prod`
  - Pfad: `/bots/kube-bot/ssh`
- Secret-Namen: `SSH_KEY_IT15_PRIVATE`, `SSH_KEY_IT15_PUBLIC`, `SSH_KEY_IT15_FINGERPRINT`, `SSH_HOST_IT15`, `SSH_KEY_IT15_LOCAL_PATH`, `SSH_HOST_DMZ_CONTROL_PLANE`, `SSH_HOST_DMZ_WORKER`.
- Fingerprint: `SHA256:v1vAeRvbpSAkVQe2kTdjZjwNexaFJ59XWt8+QlOXgmE`.
- Recovery: Key aus Infisical lesen -> `/home/node/.ssh/kube-bot-it15-ed25519` schreiben -> `chmod 600` -> Fingerprint prüfen -> SSH testen.
- Verification 2026-06-15 14:29 UTC: Infisical-readback in temporärer Datei + SSH-Probe auf IT15 erfolgreich; temporäre Datei gelöscht.
- Niemals Private-Key-Inhalte ausgeben.

## Ergänzung Infisical — DMZ SSH Key-Namenssatz — 2026-06-15 14:35 UTC

- DMZ-spezifische SSH-Secrets ergänzt im Pfad `platform-kubernetes/prod:/bots/kube-bot/ssh`:
  - `SSH_KEY_DMZ_PRIVATE`, `SSH_KEY_DMZ_PUBLIC`, `SSH_KEY_DMZ_FINGERPRINT`, `SSH_KEY_DMZ_LOCAL_PATH`, `SSH_HOST_DMZ_CONTROL_PLANE`, `SSH_HOST_DMZ_WORKER`.
- Das Keymaterial ist aktuell identisch mit dem OpenClaw/kube-bot Key für IT15, aber unter separaten DMZ-Namen abgelegt, damit Recovery/Automation nicht an IT15-Namen hängt.
- Verification: Infisical-readback + temporärer SSH-Test auf `kube-bot@192.168.20.40` erfolgreich; temporäre Datei gelöscht.

## SSH Verifikation — DMZ Worker `192.168.20.45` — 2026-06-15 15:03 UTC

- `kube-bot@192.168.20.45` funktioniert mit `/home/node/.ssh/kube-bot-it15-ed25519`.
- sudo NOPASSWD funktioniert.
- Host meldet `mini-it13-02`.
- Key ist über Infisical DMZ-Namenssatz dokumentiert: `platform-kubernetes/prod:/bots/kube-bot/ssh`.

## SSH Verifikation — Nginx Proxy Host `192.168.20.20` — 2026-06-15 15:14 UTC

- `kube-bot@192.168.20.20` funktioniert mit `/home/node/.ssh/kube-bot-it15-ed25519`.
- sudo NOPASSWD funktioniert.
- Host meldet `raspi`.
- Alter Authorized-Key-Kommentar `kube-bot@openclaw-k3s-diagnostics` wurde entfernt; aktueller Key `kube-bot@openclaw-it15-20260614` bleibt.
- Backup der ursprünglichen `authorized_keys` wurde auf dem Zielhost angelegt.

## Ergänzung Infisical — Nginx/Raspi SSH Key-Namenssatz — 2026-06-15 15:16 UTC

- Nginx/Raspi-spezifische SSH-Secrets ergänzt im Pfad `platform-kubernetes/prod:/bots/kube-bot/ssh`:
  - `SSH_KEY_NGINX_PRIVATE`, `SSH_KEY_NGINX_PUBLIC`, `SSH_KEY_NGINX_FINGERPRINT`, `SSH_KEY_NGINX_LOCAL_PATH`, `SSH_HOST_NGINX_PROXY`.
- Ziel: `kube-bot@192.168.20.20`.
- Das Keymaterial ist aktuell identisch mit dem OpenClaw/kube-bot Key, aber unter separaten Nginx-Namen abgelegt.
- Verification: Infisical-readback + temporärer SSH-Test auf `kube-bot@192.168.20.20` erfolgreich; temporäre Datei gelöscht.

## Arbeitsregel ergänzt — Proaktive Schlussfolgerungen — 2026-06-15 15:30 UTC

- Kube-bot soll nach Aktivitäten proaktiv Schlussfolgerungen ziehen, sichere Folgearbeiten erledigen, Merker aktualisieren und nächste Schritte empfehlen.
- Diese Regel gilt allgemein, nicht nur für SSH-Zugänge.
- Grenze bleibt: riskante/schreibende/destructive Infrastruktur-, Cluster-, Firewall-, Secret- oder Deployment-Aktionen nur mit explizitem OK von Mislav.

## Read-only Migrationsinventur — ArgoCD/Mandanten — 2026-06-15 15:45 UTC

- Migrationsmatrix erstellt: `/home/node/.openclaw/workspace/inventory/argocd-mandanten-migrationsmatrix-20260615.md`.
- Rohdaten abgelegt unter: `/home/node/.openclaw/workspace/inventory/migration-20260615/`.
- Ergebnis: IT15-ArgoCD ist Zielsystem; DMZ-ArgoCD `infra-argocd` verwaltet aktuell `n8n`, `hf-mautic`, `hf-espocrm`, `suitecrm`, `apps`.
- Pilot-App `demo-guestbook-cattaro-stage` läuft auf DMZ, aber noch im IT15-ArgoCD Project `default`; nächster sauberer Mandantenmodell-Schritt ist Überführung ins Project `tenant-cattaro`.
- Empfohlene erste echte App-Migration: `hf-n8n`, nach read-only Detailcheck zu Helm-Werten, Secrets-Metadaten, PVC/Backup und Ingress.
- Keine Secrets ausgegeben, keine Cluster-Änderungen durchgeführt.

## Mandanten-Pilot IT15 ArgoCD — 2026-06-15 15:48 UTC

- Freigegeben durch Mislav: Demo-App in Mandantenmodell überführen.
- Änderung durchgeführt:
  - IT15 ArgoCD AppProject `tenant-cattaro` um Destination `https://192.168.20.40:6443` / Namespace `tenant-cattaro-stage` erweitert.
  - Application `demo-guestbook-cattaro-stage` von Project `default` nach `tenant-cattaro` verschoben.
- Verifikation:
  - IT15 ArgoCD: `demo-guestbook-cattaro-stage` ist `Synced/Healthy`, Project `tenant-cattaro`.
  - DMZ-K3s: `tenant-cattaro-stage/guestbook-ui` Deployment/Service/Pod laufen weiter; Pod auf Worker `mini-it13-02`.
- Roh-/Verify-Ausgabe: `/home/node/.openclaw/workspace/inventory/migration-20260615/demo-project-move-verification.txt`.
- Schlussfolgerung: Mandanten-AppProject-Modell funktioniert grundsätzlich für IT15-ArgoCD -> DMZ-K3s.
- Nächster empfohlener Schritt: read-only Detailcheck für erste echte Migration `hf-n8n` (altes DMZ-ArgoCD -> IT15 ArgoCD / tenant-pidoka), inkl. Helm-Werte, Secret-Metadaten, PVC/Longhorn, Ingress/NPM und Rollback-Pfad.

## ArgoCD GitHub-Verbindung — Check 2026-06-15 15:50 UTC

- Frage geprüft: Ist neues IT15-ArgoCD schon wie altes DMZ-ArgoCD mit GitHub verbunden?
- Ergebnis: Nein, nicht gleichwertig.
- IT15-ArgoCD hat aktuell keine Repository-/Repo-Creds-Secrets (`argocd.argoproj.io/secret-type=repository|repo-creds`) gefunden.
- IT15 kann öffentliche GitHub-Repos nutzen; Demo-App zieht `https://github.com/argoproj/argocd-example-apps.git` erfolgreich ohne Credentials.
- Altes DMZ-ArgoCD hat Repository-Credential für `https://github.com/GitMasterOne/ArgoCD.git` mit Username/Password vorhanden (Werte nicht ausgegeben).
- Schlussfolgerung: Für Migration der echten Apps aus `GitMasterOne/ArgoCD(.git)` muss im IT15-ArgoCD noch ein GitHub Repo Credential angelegt oder aus Infisical/Token-Flow sauber bereitgestellt werden.
- Rohcheck: `/home/node/.openclaw/workspace/inventory/migration-20260615/argocd-github-connectivity-check.txt`.

## IT15 ArgoCD Readiness Check — 2026-06-15 15:52 UTC

- Readiness-Check dokumentiert: `/home/node/.openclaw/workspace/inventory/argocd-readiness-20260615/README.md`.
- Wichtigste vergessene/offene Punkte:
  1. IT15-ArgoCD hat noch keine GitHub/Repository-Credentials für `GitMasterOne/ArgoCD.git`.
  2. `default` AppProject ist noch breit offen; echte Apps nicht dort betreiben.
  3. `tenant-cattaro` ist noch Pilot-offen (`sourceRepos: *`, Namespace-Ressourcen `*/*`).
  4. `tenant-pidoka` fehlt.
  5. Platform-AppProject(s) fehlen.
  6. Initial Admin Secret existiert noch; Rotation/Ablage in Infisical offen.
  7. ArgoCD CLI fehlt in IT15/WSL PATH.
- Keine Änderungen durchgeführt, nur read-only.

## GitHub PAT für GitOps — Infisical Ablage — 2026-06-15 16:11 UTC

- Mislav hat einen GitHub PAT bereitgestellt; Tokenwert wurde nicht in Markdown dokumentiert.
- Token wurde gegen GitHub verifiziert:
  - Login: `GitMasterOne`
  - Scopes: `repo`
- Token wurde in Infisical abgelegt:
  - Projekt: `platform-kubernetes` (`c5e8661f-4b7a-43e1-80b0-8674f30950dc`)
  - Environment: `prod`
  - Pfad: `/platform/gitops/github`
  - Secret: `GITHUB_PAT_PLATFORM_GITOPS`
- Weitere Metadaten-Secrets: `GITHUB_PAT_PLATFORM_GITOPS_OWNER`, `GITHUB_PAT_PLATFORM_GITOPS_SCOPES`, `GITHUB_REPO_PLATFORM_GITOPS`, `GITHUB_REPO_PLATFORM_GITOPS_URL`.
- Slack-Delete des Token-Posts wurde versucht, schlug aber fehl (`cant_delete_message`). Empfehlung: Mislav löscht die Slack-Nachricht selbst oder rotiert den Token nach Einrichtung.

## GitHub Repo `platform-gitops` + IT15 ArgoCD Credential — 2026-06-15 16:18 UTC

- Repo geprüft: `GitMasterOne/platform-gitops` existiert, ist privat.
- Repo war leer/ohne Inhalt; initiale GitOps-Struktur wurde gepusht.
- Commit: `ae57069` (`Initial GitOps structure for platform and tenants`).
- Enthält Grundstruktur:
  - `clusters/it15-mgmt/argocd/projects/`
  - `clusters/it15-mgmt/argocd/apps/`
  - `clusters/dmz-k3s/bootstrap/`
  - `platform/`
  - `tenants/cattaro/`
  - `tenants/pidoka/`
  - `shared/`
- IT15 ArgoCD Repository Secret erstellt: `argocd/repo-platform-gitops`.
  - URL: `https://github.com/GitMasterOne/platform-gitops.git`
  - Username: `x-access-token`
  - Password/PAT aus Infisical; Wert nicht dokumentiert.
- ArgoCD-Verifikation: Application `platform-argocd-projects` erstellt, Quelle `platform-gitops`, Pfad `clusters/it15-mgmt/argocd/projects`, Status `Synced/Healthy`, Revision `ae57069dc1e0ff38a6134194d47e8d1a75961b22`.
- Hinweis: `platform-argocd-projects` läuft aktuell noch im ArgoCD Project `default`, weil sie die AppProjects selbst verwaltet. Später ggf. Bootstrap/Platform-Project sauber modellieren.
- Direkter `git ls-remote` im repo-server Pod schlug ohne Credentials erwartbar fehl und ist kein valider ArgoCD Credential-Test.

## Zammad Longhorn Migration — 2026-06-17 22:40 UTC

- Fokus nach Mislavs OK: Zammad von alten `local-path` PVCs auf Longhorn-PVCs migrieren, nicht weg von PVCs generell.
- Vorherige GitOps-Adoption war bereits grün:
  - `pidoka-hf-zammad`: `Synced/Healthy`
  - `pidoka-hf-zammad-secrets`: `Synced/Healthy`
  - Secrets laufen über ESO/Infisical; keine Secretwerte dokumentiert.
- Fresh final backup vor Storage-Freeze:
  - Pfad: `/home/kube-bot/backups/zammad-longhorn-20260617T222011Z`
  - DB-Dump: `zammad-postgresql-final.sql.gz`
  - gzip-Test und SHA256-Check waren erfolgreich.
- Neue Longhorn-PVCs:
  - `zammad-postgresql-data-longhorn` -> `pvc-e8dd7160-96c9-4409-b9b8-0e15e1a2ba5f`
  - `zammad-elasticsearch-data-longhorn` -> `pvc-34a029bc-ec9c-4ae6-8dfe-3e40905b8ca4`
  - `zammad-redis-data-longhorn` -> `pvc-61d812f1-d3f3-4d63-a194-782128ae536f`
  - `zammad-var-longhorn` -> `pvc-ed7727c1-57f6-4ed0-8dc2-3f7854de1339`
- Alte `local-path` PVCs bleiben bewusst erhalten und dürfen noch nicht gelöscht werden:
  - `data-zammad-postgresql-0`
  - `data-zammad-elasticsearch-master-0`
  - `redis-data-zammad-redis-master-0`
  - `zammad-var-zammad-0`
- GitOps-Commits:
  - `1e74cfd Prepare Zammad Longhorn storage migration`
  - `669b006 Pin Zammad workloads during Longhorn migration`
- Wichtiger Zwischenfall:
  - Erste PostgreSQL-Tar-Copy erzeugte auf dem Ziel ein defektes/0-Byte `PG_VERSION`; erkannt durch PostgreSQL-Startfehler.
  - PostgreSQL-Daten wurden danach kalt mit `cp -a /old/. /new/` neu kopiert; `PG_VERSION=15` und Start anschließend OK.
- Weiterer Befund:
  - Worker `mini-it13-02` konnte alte Bitnami-Image-Tags nicht pullen (`not found`).
  - Zammad Workloads wurden deshalb live und in GitOps per `nodeSelector` auf `mbrkanov-mini-it13` gepinnt, bis Image-Strategie aktualisiert ist.
- Abschlussprüfung:
  - Pods: `zammad-0` 4/4 Running, PostgreSQL/Redis/Elasticsearch/Memcached Running, alle ohne Restarts seit Migration.
  - Laufende Pods mounten die neuen Longhorn-Claims.
  - Longhorn meldet alle vier neuen Volumes `attached` / `healthy`.
  - Datenzählung unverändert: 370 Users, 393 Tickets, 1182 Ticket-Artikel, 4 Organisationen.
  - Letzte Ticket-/Artikel-Updates: 2026-06-17 19:10 UTC.
  - Extern: `https://service.heckenfels.com/` HTTP 200.
  - ArgoCD IT15: `pidoka-hf-zammad` und `pidoka-hf-zammad-secrets` beide `Synced/Healthy` auf Revision `669b0061283f5f7c3ccba9594bcadb14a9db38dd`.
- Empfehlung:
  - Alte local-path PVCs mindestens über eine Beobachtungsphase behalten.
  - Als nächstes Image-Tags/Registry-Strategie für die alten Bitnami-Images bereinigen, damit der nodeSelector wieder entfernt und Scheduling-Flexibilität wiederhergestellt werden kann.

## Altes ArgoCD Repo Audit — 2026-06-15 19:15 UTC

- Audit gestartet nach Mislavs Hinweis auf mögliche Passwörter/Tokens und uneinheitliche ArgoCD-YAML-Struktur.
- Repo geklont: `GitMasterOne/ArgoCD`, Branch `main`, Commit `8882e3c3a9f0414c0fa9f22772a798f1c2be8155`.
- Audit-Dokument: `/home/node/.openclaw/workspace/audits/argocd-repo-20260615/README.md`.
- Befund:
  - Apps sind uneinheitlich modelliert: App-of-apps, externes Helm Chart, lokale Charts, inline `values`, `valuesObject`, `valueFiles`.
  - Passwort-Verdachtsstellen in `espocrm/values*.yaml` und `charts/suitecrm/values.yaml`; keine Secretwerte in Summary ausgegeben.
  - `n8n` ist sauberster erster Migrationskandidat: externes Helm Chart, Secrets über `n8n-secret` referenziert, PVC Longhorn 5Gi, Ingress `n8n.heckenfels.com`.
- Achtung: Eine erste Live-Secret-Abfrage gab Base64-Werte aus; die persistente Datei wurde sofort sanitisiert und enthält nur Secret-/Key-Namen. Künftig bei Secrets nur JSON/Python-Auswertung mit Key-Namen nutzen, niemals `.data` roh ausgeben.
- Empfehlung: altes Repo nicht direkt reorganisieren; App-für-App neu in `platform-gitops` modellieren. Nächster Schritt: n8n-Migrationsmanifest in `platform-gitops` vorbereiten, aber Cutover/Synchronisation nur mit explizitem OK.

## Vertiefung altes ArgoCD Repo — Git-History Scan — 2026-06-15 19:26 UTC

- Git-History Scan ergänzt: `/home/node/.openclaw/workspace/audits/argocd-repo-20260615/git-history-secret-scan-summary.md`.
- 174 Commits gescannt, 102 maskierte eindeutige Verdachtsfunde.
- Keine GitHub PATs/Private Keys/JWTs gefunden, aber viele Passwort-/Secret-Key-Felder in aktuellen und historischen Dateien.
- Konsequenz: altes Repo samt History als secret-belastet behandeln; nicht in neues Repo übernehmen; betroffene Passwörter perspektivisch rotieren.
- Normalisierungsziel für neues `platform-gitops` dokumentiert: pro App `application.yaml`, `values.yaml`, `external-secrets.yaml`, optional `kustomization.yaml`, `README.md`; keine inline Secretwerte; keine History-Übernahme.
- Nächster sicherer Schritt: für `n8n` Zielstruktur in `platform-gitops` vorbereiten und Secretstrategie definieren. Noch kein Sync/Cutover ohne explizites OK.

## DMZ Infisical via IT15 ArgoCD deployed — 2026-06-15 20:56 UTC

- Architekturentscheidung umgesetzt: DMZ-lokales Infisical statt Firewall-Öffnung DMZ -> IT15.
- GitOps Repo `GitMasterOne/platform-gitops` aktualisiert:
  - Commit `06a7f5c`: `Add DMZ Infisical platform app`
  - Commit `58d807d`: `Allow guestbook demo repo for Cattaro tenant project`
- Neue ArgoCD Application: `platform-infisical-dmz` im Project `platform`.
- Helm Chart: `infisical-standalone` `1.9.0`, Image `infisical/infisical:v0.158.0`.
- Namespace: `platform-infisical`.
- Exposure: nur `ClusterIP`, kein Ingress, kein Public/NPM-Exposure.
- Storage: Longhorn PVCs:
  - PostgreSQL `8Gi`: `data-postgresql-0`
  - Redis `2Gi`: `redis-data-redis-master-0`
- Initial runtime secrets wurden direkt im DMZ-K3s erstellt und NICHT ins Git geschrieben:
  - `infisical-secrets`
  - `postgresql`
  - `redis`
- ArgoCD DMZ Cluster Credential korrigiert:
  - gemeinsamer ServiceAccount `platform-infisical/argocd-dmz-manager`
  - RoleBindings in `platform-infisical` und `tenant-cattaro-stage`
  - ArgoCD Cluster Secret `dmz-k3s-tenant-cattaro-stage` nutzt jetzt den gemeinsamen Token und Namespaces `tenant-cattaro-stage,platform-infisical`
  - temporäres Cluster Secret `dmz-k3s-platform-infisical` wurde gelöscht
- Verification:
  - `platform-infisical` Pods: Infisical/PostgreSQL/Redis Running
  - `/api/status` cluster-intern: `Ok`, `redisConfigured=true`, `inviteOnlySignup=true`
  - IT15 ArgoCD Apps final: `platform-infisical-dmz`, `demo-guestbook-cattaro-stage`, `platform-argocd-projects` alle `Synced/Healthy`
- Auffälligkeit: Infisical-App hatte beim ersten Start 3 Restarts, weil PostgreSQL noch initialisierte. Danach stabil und healthy.
- Nächste Schritte:
  1. Admin-Erstzugang/Bootstrap für DMZ-Infisical klären, vorzugsweise per Port-Forward, nicht öffentlich.
  2. Initial runtime secrets (AUTH_SECRET, ENCRYPTION_KEY, DB/Redis) sicher sichern/Recovery-Konzept festlegen. Aktuell nur in Kubernetes Secrets/PVCs, nicht in Infisical/Markdown.
  3. Backup/Restore-Konzept für DMZ-Infisical PostgreSQL/Longhorn definieren.
  4. Danach Infisical Operator/External Secret Integration für n8n vorbereiten.

## Tagesabschluss / Wiedereinstieg morgen — DMZ Infisical — 2026-06-15 21:39 UTC

### Aktueller verifizierter Zustand

- IT15 ArgoCD:
  - `platform-infisical-dmz`: `Synced / Healthy`
  - `demo-guestbook-cattaro-stage`: `Synced / Healthy`
  - `platform-argocd-projects`: `Synced / Healthy`
- DMZ K3s Namespace: `platform-infisical`
  - Infisical Pod: `1/1 Running`, neuer Pod ohne Restarts beim letzten Check
  - PostgreSQL: `1/1 Running`
  - Redis: `1/1 Running`
  - PVCs: Longhorn `Bound`
- Cluster-interner Healthcheck:
  - `GET http://infisical-infisical-standalone-infisical:8080/api/status`
  - Antwort: `message=Ok`, `redisConfigured=true`, `inviteOnlySignup=true`
- Exposure:
  - Nur `ClusterIP`
  - Kein Ingress
  - Keine Firewall-Öffnung
  - Kein öffentliches/NPM Exposure

### Was heute geändert wurde

- DMZ-lokales Infisical per IT15-ArgoCD eingeführt.
- GitOps Repo `GitMasterOne/platform-gitops`:
  - Commit `06a7f5c`: `Add DMZ Infisical platform app`
  - Commit `58d807d`: `Allow guestbook demo repo for Cattaro tenant project`
- ArgoCD DMZ Cluster Credential korrigiert:
  - ein gemeinsamer namespace-beschränkter ServiceAccount für `tenant-cattaro-stage` und `platform-infisical`
  - keine Cluster-weiten Adminrechte für diesen Flow dokumentiert
- Initial runtime Kubernetes Secrets in `platform-infisical` erzeugt:
  - `infisical-secrets`
  - `postgresql`
  - `redis`
- Keine Secretwerte ins Git oder in Markdown geschrieben.

### Sicherheits-/Betriebsnotizen

- Aktuell ist DMZ-Infisical funktional, aber noch nicht produktionsfertig gebootstrappt.
- Kritischster offener Punkt: Recovery/Backup für Initial-Secrets und PostgreSQL/PVCs.
- Die Initial-Secrets existieren aktuell nur als Kubernetes Secrets im DMZ-Cluster; Werte nicht ausgeben.
- Erstzugang sollte nur temporär per Port-Forward erfolgen, nicht per Ingress/Public Exposure.
- `inviteOnlySignup=true`, also keine offene Registrierung.

### Morgen empfohlene Reihenfolge

1. Kurzstatus prüfen:
   - IT15 ArgoCD Apps `platform-infisical-dmz`, `platform-argocd-projects`, `demo-guestbook-cattaro-stage`
   - DMZ Pods/PVCs in `platform-infisical`
   - `/api/status`
2. Temporären Port-Forward für Mislav öffnen:
   - Von einem erreichbaren Rechner aus per SSH/Kubectl gegen DMZ Control Plane.
   - Ziel: lokaler Browser `http://localhost:<port>` -> Service `infisical-infisical-standalone-infisical:8080`.
   - Kein Firewall-Change, nur laufende Session.
3. Admin-Erstzugang/Bootstrap durchführen.
4. Direkt danach Recovery absichern:
   - Initial-Secrets sicher in IT15-Infisical oder anderem vereinbarten Recovery-Pfad ablegen.
   - Keine Secretwerte in Slack/Markdown posten.
5. Backup-Konzept für DMZ-Infisical festlegen:
   - mindestens PostgreSQL Dump oder Longhorn recurring snapshot/backup
   - Recovery-Probe planen
6. Danach erst Infisical Operator / Secret-Sync für `n8n` vorbereiten.

### Wenn morgen wenig Zeit ist

Minimal sicherer nächster Schritt:
- Nur Status prüfen + Port-Forward erklären/öffnen.
- Bootstrap/Recovery erst machen, wenn Mislav genug Zeit hat.

### Kurzbefehl-Idee für Status morgen

- IT15 ArgoCD App Status via WSL auf IT15.
- DMZ Status via SSH `kube-bot@192.168.20.40` und `/etc/rancher/k3s/k3s.yaml`.


## DMZ Infisical Bootstrap / kube-bot Machine Identity — 2026-06-16 18:33 UTC

- DMZ-Infisical ist temporär via Port-Forward erreichbar unter `http://192.168.20.40:18080`.
- Mislav hat Organisation und Projekt in DMZ-Infisical angelegt.
- DMZ-Infisical Projekt sichtbar für kube-bot:
  - Name: `platform-kubernetes`
  - ID: `d66f3d3b-1484-46f6-8142-f6fc32222b4d`
  - Slug: `platform-kubernetes-pqmd`
- Machine Identity in DMZ-Infisical:
  - Name: `kube-bot`
  - Client-ID: `9d47b9d2-c994-4449-afa1-5bbbf271eda0`
- Client Secret wurde nicht in Slack/Markdown ausgegeben.
- Recovery-/Bootstrap-Secrets liegen in IT15-Infisical:
  - Projekt: `platform-kubernetes` (`c5e8661f-4b7a-43e1-80b0-8674f30950dc`)
  - Environment: `prod`
  - Pfad: `/platform/kube-bot`
  - Secret-Namen: `DMZ_INFISICAL_KUBE_BOT_CLIENT_ID`, `DMZ_INFISICAL_KUBE_BOT_CLIENT_SECRET`, `DMZ_INFISICAL_URL`
- Verification: kube-bot Universal Auth Login gegen DMZ-Infisical erfolgreich; `/api/v1/projects` zeigt `platform-kubernetes`.
- Hinweis: Wunsch-Zielpfad `/platform/infisical/dmz/bootstrap` wurde noch nicht befüllt, weil die verfügbare API-Create-Route encrypted payload erwartet. Aktueller Pfad `/platform/kube-bot` ist funktional und verifiziert.

## Korrektur Tenant-Zuordnung — 2026-06-16 18:53 UTC

- Mislav hat klargestellt:  gehört fachlich zur **PIDOKA GmbH**, nicht zur Cattaro GmbH.
- Für n8n-GitOps ist daher das Ziel-AppProject/der Zielpfad  zu verwenden bzw. entsprechend zu erweitern.
- Bestehender Namespace ist aktuell ; fachliche Zielzuordnung: PIDOKA.

## Korrektur Tenant-Zuordnung — 2026-06-16 18:53 UTC

- Mislav hat klargestellt: n8n gehört fachlich zur **PIDOKA GmbH**, nicht zur Cattaro GmbH.
- Für n8n-GitOps ist daher das Ziel-AppProject/der Zielpfad `tenant-pidoka` zu verwenden bzw. entsprechend zu erweitern.
- Bestehender Namespace ist aktuell `hf-n8n`; fachliche Zielzuordnung: PIDOKA.

## PIDOKA n8n GitOps Vorbereitung — 2026-06-16 19:08 UTC

- Fachliche Korrektur: n8n gehört zur PIDOKA GmbH.
- Bestehendes n8n läuft in DMZ Namespace `hf-n8n` und wird aktuell noch vom alten DMZ-ArgoCD `infra-argocd/n8n` verwaltet.
- IT15-ArgoCD AppProject `tenant-pidoka` erlaubt bereits Zielnamespace `hf-n8n` und Source `8gears.container-registry.com`.
- Neue GitOps-Manifeste wurden im Repo `GitMasterOne/platform-gitops` vorbereitet und gepusht:
  - Commit: `8a58482 Add PIDOKA n8n GitOps migration manifest`
  - `applications/tenants/pidoka/n8n.yaml`
  - `tenants/pidoka/prod/n8n/values.yaml`
  - `tenants/pidoka/prod/n8n/README.md`
- Ziel der neuen App: IT15-ArgoCD Application `pidoka-n8n`, Project `tenant-pidoka`, Destination `https://192.168.20.40:6443`, Namespace `hf-n8n`.
- SyncPolicy der neuen App bewusst vorsichtig: `prune=false`, `selfHeal=false`.
- Kubernetes server-side dry-run auf IT15-ArgoCD war erfolgreich: `application.argoproj.io/pidoka-n8n created (server dry run)`.
- Noch nicht erledigt: IT15-ArgoCD Application tatsächlich anlegen/syncen; alter DMZ-ArgoCD-Controller wurde nicht verändert.
- Risiko: Zwei ArgoCD-Controller dürfen n8n nicht dauerhaft gleichzeitig verwalten. Cutover braucht explizites OK.

## PIDOKA n8n Cutover auf IT15-ArgoCD — 2026-06-16 19:28 UTC

- Freigabe durch Mislav: n8n direkt migrieren und danach ArgoCD UI bereitstellen.
- Neue IT15-ArgoCD Application: `pidoka-n8n`, Project `tenant-pidoka`.
- Ziel: DMZ `https://192.168.20.40:6443`, Namespace `hf-n8n`.
- GitOps Repo Commit-Stand:
  - `8a58482` initiale PIDOKA n8n Migration-Manifeste
  - `814792f` IT15-App auf manual sync gesetzt
  - `a10207a` Helm `releaseName: n8n`, damit bestehende Ressourcen übernommen statt neu erzeugt werden
- IT15-ArgoCD Cluster Secret `dmz-k3s-tenant-cattaro-stage` wurde um Namespace `hf-n8n` erweitert.
- DMZ RBAC namespace-scoped für ServiceAccount `platform-infisical/argocd-dmz-manager` in `hf-n8n` angelegt/erweitert.
- Alter DMZ-ArgoCD Application-Controller für n8n wurde entkoppelt:
  - `infra-argocd/n8n` Application gelöscht, vorher Backup auf DMZ Host: `/tmp/old-n8n-argocd-application-backup.yaml`
  - n8n-Ressourcen wurden nicht gelöscht/pruned.
- IT15-ArgoCD Status nach Cutover:
  - `pidoka-n8n`: `Synced / Healthy`
  - Ressourcen: ConfigMap/PVC/Service/ServiceAccount/Deployment/Ingress `n8n` in `hf-n8n` synced
- DMZ Live-Status nach Cutover:
  - Deployment `n8n`: `1/1`, Image `n8nio/n8n:1.122.4`
  - PVC `n8n`: Bound, Longhorn 5Gi
  - Ingress `n8n.heckenfels.com` unverändert
- Hinweis: IT15-ArgoCD zeigt noch `SharedResourceWarning` mit alter App-ID `n8n`; funktional ist die App grün. Ursache sind alte ArgoCD tracking/instance Cache-/Tracking-Reste aus der Übernahme.
- Temporärer IT15 ArgoCD UI Port-Forward läuft:
  - IT15 WSL PID: `892996`
  - URL aus Intranet voraussichtlich: `https://192.168.1.121:18081`
  - Kein Ingress/Public Exposure.

## Legacy DMZ-ArgoCD n8n Quelle entfernt — 2026-06-16 19:59 UTC

- Mislav gab grünes Licht, die alte n8n-Quelle im Legacy-DMZ-ArgoCD zu entschärfen.
- Im alten Repo `GitMasterOne/ArgoCD.git` wurde `applications/n8n.yaml` entfernt:
  - Commit: `f8a3e69 Remove n8n from legacy DMZ ArgoCD app-of-apps`
- Legacy Parent-App `infra-argocd/apps` wurde refreshed und ist danach `Synced / Healthy` auf Revision `f8a3e69`.
- Legacy `infra-argocd/n8n` Application ist danach absent.
- DMZ n8n Workloads blieben bestehen und healthy:
  - Deployment `hf-n8n/n8n`: `1/1`
  - PVC `hf-n8n/n8n`: Bound, Longhorn 5Gi
  - Ingress `n8n.heckenfels.com` unverändert
- IT15-ArgoCD `pidoka-n8n` bleibt `Synced / Healthy`.
- IT15-ArgoCD listet nur noch eine n8n-App: `pidoka-n8n`.
- Resthinweis: `pidoka-n8n` zeigt aktuell noch `SharedResourceWarning` mit alter App-ID `n8n`; keine zweite IT15-App existiert und Legacy-DMZ-App ist entfernt. Vermutlich stale resource-tracking/cache aus der Übernahme; funktional ist der Zustand grün.

## Recovery-Zwischenstand — PIDOKA HF Matomo Migration — 2026-06-17 11:04 UTC

Rekonstruiert aus lokalem Chat-/Sessionverlauf bis 2026-06-17 ca. 08:00 UTC. Dieser Abschnitt ist der aktuelle Wiedereinstiegspunkt nach Runtime-Abbruch.

### n8n Abschluss

- `n8n` gehört fachlich zur PIDOKA GmbH / HF-Servicegruppe.
- IT15-ArgoCD verwaltet n8n produktiv:
  - Application `pidoka-n8n`: zuletzt `Synced / Healthy`.
  - Application `pidoka-n8n-secrets`: nach Normalisierung ebenfalls `Synced / Healthy`.
- n8n Secret-Sync über ESO ist aktiv:
  - `ExternalSecret/hf-n8n/n8n-secret` Ready / SecretSynced.
  - `Deployment/hf-n8n/n8n` nutzt Secret-Refs für `N8N_BASIC_AUTH_USER`, `N8N_BASIC_AUTH_PASSWORD`, `N8N_ENCRYPTION_KEY`.
- Letzte relevante GitOps-Commits:
  - `559f471 Fix n8n chart extraEnv placement`
  - `48b5515 Normalize n8n ExternalSecret defaults`
- Keine Secretwerte wurden dokumentiert.

### Tenant-/Namespace-Zielmodell PIDOKA/HF

- Mislav hat bestätigt: `hf-*` Services sind zusammengehörige Services der PIDOKA GmbH.
- Ziel-Namensschema: `pidoka-hf-*`, damit Tenant und HF-Servicegruppe sichtbar bleiben.
- Geplante Zuordnung:
  - `hf-n8n` -> `pidoka-hf-n8n` später / separat.
  - `hf-matomo` -> `pidoka-hf-matomo` als erster Migrationskandidat.
  - `hf-mautic` -> `pidoka-hf-mautic` später; vorher CronJob-Probleme prüfen.
  - `hf-espocrm` -> `pidoka-hf-espocrm` später; vorher DB-CrashLoop prüfen.
  - `hf-suitecrm` -> `pidoka-hf-suitecrm` später.
  - `zammad` -> vermutlich `pidoka-hf-zammad`, aber ausdrücklich erst später, weil datenkritisch und lokaler Storage riskanter ist.
- Mislav gab OK für app-by-app Migration, aber Bedingung: keine Datenverluste riskieren; Backup-/Rollback-Gate vor Cutover.

### Matomo Migration — bisher erledigt

- Startkandidat: `hf-matomo`, weil healthy, klein und Longhorn-basiert.
- Vorgehen: Staging-Migration ohne Traffic-Cutover.
- Backup-Gate bestanden:
  - Backup-Pfad auf DMZ Control Plane: `/home/kube-bot/backups/matomo-20260617T060849Z`
  - Live-Manifeste ohne Secretwerte gesichert: `/home/kube-bot/backups/matomo-live-manifests-20260617T061025Z.yaml`
- Sensible Matomo DB-Werte lagen historisch als Literal-Env im alten Deployment. Sie wurden als Secret-Material behandelt und nicht ausgegeben.
- Matomo-Secrets wurden nach DMZ-Infisical übertragen und verifiziert:
  - Infisical-Pfad: `/tenants/pidoka/matomo`
  - Secretwerte nicht dokumentiert.
- GitOps-Staging-Manifeste wurden erstellt und gepusht:
  - Repo: `GitMasterOne/platform-gitops`
  - Commit: `da6bb82 Add PIDOKA HF Matomo staging migration`
  - Applications:
    - `applications/tenants/pidoka/matomo.yaml` -> `pidoka-hf-matomo`
    - `applications/tenants/pidoka/matomo-secrets.yaml` -> `pidoka-hf-matomo-secrets`
  - Manifeste:
    - `tenants/pidoka/prod/matomo/app.yaml`
    - `tenants/pidoka/prod/matomo/external-secrets/matomo-secret.yaml`
    - `tenants/pidoka/prod/matomo/README.md`
  - Zielnamespace: `pidoka-hf-matomo`.
  - Workloads bewusst mit `replicas: 0`, damit keine leere Neuinstallation Daten überschreibt und kein Traffic-Cutover passiert.
- `tenant-pidoka` AppProject wurde im GitOps-Repo um Zielnamespace `pidoka-hf-matomo` erweitert.

### Matomo Migration — letzter bekannter Laufzustand vor Abbruch

- Neue ArgoCD Apps wurden auf IT15 angelegt bzw. teilweise angelegt:
  - `pidoka-hf-matomo`
  - `pidoka-hf-matomo-secrets`
- Namespace `pidoka-hf-matomo` wurde angelegt, weil AppProject keine ClusterResource Namespace-Erstellung erlaubt.
- Services/PVCs im neuen Namespace wurden begonnen/angelegt.
- Workloads sollten weiterhin `replicas: 0` bleiben; kein Traffic-Cutover.
- Offener Blocker beim Abbruch:
  - ESO konnte im neuen Namespace noch nicht syncen, weil das namespace-lokale Infisical-Auth-Secret fehlte.
  - Nächster Schritt war: bestehende Infisical-Auth-Secret-Referenz in `pidoka-hf-matomo` kopieren, ohne Werte auszugeben, dann `pidoka-hf-matomo-secrets` syncen/verifizieren.

### Sichere Fortsetzung ab jetzt

1. Read-only Status prüfen:
   - IT15-ArgoCD Apps `pidoka-hf-matomo`, `pidoka-hf-matomo-secrets`.
   - DMZ Namespace `pidoka-hf-matomo`: Services, PVCs, Deployments/StatefulSets, ESO Ressourcen.
   - Sicherstellen: keine Matomo/DB Pods laufen unerwartet (`replicas=0`).
2. Wenn Infisical-Auth-Secret fehlt: nur bestehendes Auth-Secret aus funktionsfähigem PIDOKA/ESO-Namespace in `pidoka-hf-matomo` kopieren; Secretwerte niemals ausgeben.
3. Danach ESO sync/verifizieren.
4. Danach erst Restore in neue PVCs planen/ausführen; keine Traffic-/Ingress-Umschaltung ohne weitere Verifikation.
5. Zammad weiterhin nicht anfassen.

## Live-Zwischenstand — PIDOKA HF Matomo Restore — 2026-06-17 11:08 UTC

Nach Wiederaufnahme wurde an `pidoka-hf-matomo` weitergearbeitet. Produktion `hf-matomo` blieb unverändert.

### Sicher verifiziert

- IT15/ArgoCD hat den Matomo-Staging-Commit gesehen:
  - `da6bb82 Add PIDOKA HF Matomo staging migration`
  - später `b200d25 Add MariaDB env compatibility for Matomo staging`
- Neue Namespace-Ressourcen `pidoka-hf-matomo` existieren.
- Neue Workloads waren initial bewusst `replicas: 0`.
- Alte Produktion `hf-matomo` läuft weiter und wurde nicht gestoppt/umgeschaltet.
- Backup-Artefakte vorhanden und SHA256 geprüft:
  - `/home/kube-bot/backups/matomo-20260617T060849Z`
  - `SHA256SUMS` OK.

### GitOps-Korrektur

- Problem: `mariadb:latest` erwartet aktuelle `MARIADB_*` Env-Namen; alte Manifeste hatten nur `MYSQL_*`.
- Fix committed und gepusht:
  - Commit: `b200d25 Add MariaDB env compatibility for Matomo staging`
  - `matomo-db` Deployment hat jetzt zusätzlich:
    - `MARIADB_ROOT_PASSWORD` -> `MYSQL_ROOT_PASSWORD`
    - `MARIADB_DATABASE` -> `MYSQL_DATABASE`
    - `MARIADB_USER` -> `MYSQL_USER`
    - `MARIADB_PASSWORD` -> `MYSQL_PASSWORD`
- Da `argocd` CLI auf IT15 nicht verfügbar war, wurde die GitOps-Quelle direkt auf DMZ angewendet; ArgoCD hatte den Commit gesehen, war aber noch nicht automatisch live synchronisiert.

### Aktueller Blocker

- Restore-Versuch wurde gestoppt/abgebrochen, nachdem neue Staging-DB crashte.
- Ursache konkret verifiziert: Kubernetes Secret `pidoka-hf-matomo/matomo-secret` existiert, aber ESO/Infisical hat leere Werte geliefert.
- Nur Längen geprüft, keine Secretwerte ausgegeben:
  - `MATOMO_DATABASE_DBNAME: len=0`
  - `MATOMO_DATABASE_HOST: len=0`
  - `MATOMO_DATABASE_USERNAME: len=0`
  - `MYSQL_DATABASE: len=0`
  - `MYSQL_USER: len=0`
  - Passwortfelder waren ebenfalls nicht nutzbar/leer bzw. wurden nur maskiert betrachtet.
- Alte Live-Deployment-Werte in `hf-matomo` sind vorhanden; nur Längen geprüft:
  - `MATOMO_DATABASE_HOST` len 9
  - DB/User-Namen len 6
  - Passwörter vorhanden, nicht ausgegeben.

### Aktueller sicherer Zustand

- Neue `pidoka-hf-matomo` DB wurde wieder auf `replicas=0` skaliert.
- Stuck Restore-Pod `matomo-html-restore` wurde gelöscht.
- Neue Staging-Umgebung enthält keine produktive Traffic-Umschaltung.
- Alte Produktion `hf-matomo` läuft weiter.

### Nächster Schritt

1. Alte Live-Matomo-Env-Werte maschinell aus `hf-matomo` lesen, nicht ausgeben.
2. Werte nach DMZ-Infisical `/tenants/pidoka/matomo` upserten.
3. ESO resyncen oder warten, dann nur Secret-Key-Längen in `pidoka-hf-matomo/matomo-secret` prüfen.
4. Erst danach DB-Restore erneut starten.
5. HTML-Restore muss auf Control-Plane `mbrkanov-mini-it13` laufen oder Backup muss auf Worker verfügbar sein; vorher Restore-Pod nodeSelector/affinity setzen oder Backup erreichbar machen.

## PIDOKA HF Matomo Staging-Restore — 2026-06-17 13:05 UTC

- Mislav gab OK, die Matomo-Secrets nach DMZ-Infisical zu upserten und den Restore fortzusetzen.
- Secretwerte wurden nicht ausgegeben oder dokumentiert.
- Live-Werte aus `hf-matomo` wurden maschinell gelesen und nach DMZ-Infisical übertragen:
  - Projekt: `platform-kubernetes` (`d66f3d3b-1484-46f6-8142-f6fc32222b4d`)
  - Environment: `prod`
  - Pfad: `/tenants/pidoka/matomo`
- GitOps-Korrektur gepusht:
  - Repo: `GitMasterOne/platform-gitops`
  - Commit: `815ea84 Fix Matomo ExternalSecret Infisical path`
  - Ursache: ESO/Infisical braucht `secretsPath: /tenants/pidoka/matomo` im SecretStore und kurze `remoteRef.key`-Namen.
- IT15 ArgoCD:
  - `pidoka-hf-matomo`: `Synced / Healthy`, Revision `815ea84c63677765b7a3c986e0baa6f38581352d`
  - `pidoka-hf-matomo-secrets`: `Synced / Healthy`, gleiche Revision
- ESO-Verifikation im Namespace `pidoka-hf-matomo`:
  - `SecretStore/dmz-infisical`: `Ready=True`, `Valid`
  - `ExternalSecret/matomo-secret`: `Ready=True`, `SecretSynced`
  - Alle erwarteten Secret-Keys haben nicht-leere Werte; nur Längen geprüft.
- Staging-Restore durchgeführt:
  - Staging-PVCs `matomo-pvc` und `matomo-db-pvc` geleert.
  - HTML aus `/home/kube-bot/backups/matomo-20260617T060849Z/matomo-html.tar.gz` nach `matomo-pvc` wiederhergestellt.
  - DB aus `/home/kube-bot/backups/matomo-20260617T060849Z/matomo-db.sql.gz` in frische MariaDB auf `matomo-db-pvc` importiert.
  - DB-Verifikation: 53 Tabellen, 2 Einträge in `matomo_site`.
  - HTML-Verifikation: `index.php` und `config/` vorhanden, 30 Top-Level-Einträge.
- Interner App-Test:
  - `Deployment/matomo` temporär auf 1 skaliert.
  - Interner HTTP-Test im Pod: `200`.
  - Keine Restarts.
  - Danach `matomo` und `matomo-db` wieder auf `replicas=0` skaliert.
- Produktion blieb unverändert:
  - Namespace `hf-matomo`
  - Deployments `matomo` und `matomo-db`: `1/1`
  - Pods Running, Restarts `0`
  - Ingress `matomo.heckenfels.com` unverändert.
- Wichtiger Hinweis:
  - Staging zog ein anderes `matomo:latest` Image-Digest als die laufende Produktion. Vor Cutover sollte das Image auf eine feste Version/Digest gepinnt oder bewusst abgeglichen werden.
  - Es gab keinen Traffic-Cutover und kein neues Ingress.
- Lokaler GitOps-Worktree-Hinweis:
  - Es existiert weiterhin eine uncommitted Änderung an `tenants/pidoka/prod/n8n/external-secrets/n8n-secret.yaml`; diese wurde nicht angefasst und nicht gepusht.

### Nächster empfohlener Schritt

1. Matomo-Staging-Image pinnen/angleichen, vorzugsweise auf die produktiv verifizierte Version statt `latest`.
2. Danach Staging-App erneut intern testen.
3. Erst danach Cutover planen: DNS/Ingress/Namespace-Wechsel oder sauberer Ersatz der alten `hf-matomo` Ressourcen.
4. Vor Cutover erneut Backup/Restore-Punkt prüfen und Rollback-Pfad festlegen.

## PIDOKA HF Matomo Image-Pin + Retest — 2026-06-17 13:35 UTC

- Staging-Images wurden auf die aktuell produktiv laufenden Image-Digests gepinnt:
  - Matomo: `docker.io/library/matomo@sha256:21b8bae018cd51a05f36bc6beac3861bb314d131df690c47bba1648aad2b8d7e`
  - MariaDB: `docker.io/library/mariadb@sha256:e0236fc6386e7eacd9359e59d0a078bd7aa0d18280d36d13061121bedeaee903`
- GitOps Commit:
  - Repo: `GitMasterOne/platform-gitops`
  - Commit: `9a8b373 Pin Matomo staging images to production digests`
- IT15 ArgoCD:
  - `pidoka-hf-matomo`: `Synced / Healthy`, Revision `9a8b373abdf4f0bb1e5d3959c2ceaee50b87584f`
  - `pidoka-hf-matomo-secrets`: `Synced / Healthy`, gleiche Revision
- Interner Staging-Retest:
  - `matomo-db` und `matomo` temporär auf `replicas=1` skaliert.
  - Beide Pods liefen mit den gepinnten produktiven Digests.
  - Restarts: `0`.
  - Interner HTTP-Test im Matomo-Pod: `200`.
  - DB-Check: 53 Tabellen, 2 Einträge in `matomo_site`.
  - Danach Staging wieder auf `replicas=0` skaliert.
- Produktion `hf-matomo` blieb unverändert:
  - `matomo` und `matomo-db`: `1/1`
  - Pods Running, Restarts `0`
  - Ingress `matomo.heckenfels.com` unverändert.
- Lokaler GitOps-Worktree-Hinweis:
  - Weiterhin uncommitted: `tenants/pidoka/prod/n8n/external-secrets/n8n-secret.yaml`; nicht Teil der Matomo-Arbeit.

## PIDOKA HF Zammad Analyse + DB-Backup — 2026-06-17 19:40 UTC

- Mislav gab ein kleines Wartungsfenster frei: vorsichtig, kleine Schritte, laufend berichten.
- Zammad wurde vorab read-only analysiert:
  - Namespace: `zammad`.
  - Helm Release: `zammad`, Chart `zammad-10.2.1`, App `6.2.0-1`, Revision `1`.
  - Keine ArgoCD Application fuer Zammad sichtbar; aktuell Helm-managed.
  - Service: `LoadBalancer` Port `8080`, NPM/Externpfad `service.heckenfels.com`.
  - Storage: vier `local-path` PVCs auf `mbrkanov-mini-it13`, ReclaimPolicy `Delete`.
- Backup-Pfad auf DMZ Control Plane:
  - `/home/kube-bot/backups/zammad-20260617T193554Z`
- Gesichert:
  - `status-before.txt`
  - `status-after.txt`
  - `helm-status.txt`
  - `zammad-manifests-no-secrets.yaml`
  - `README.txt`
  - `zammad-postgresql.sql.gz`
  - `SHA256SUMS`
- Secretwerte wurden nicht ausgegeben oder exportiert.
- Fuer konsistenten DB-Dump wurde nur `StatefulSet/zammad` temporaer auf `replicas=0` skaliert.
- PostgreSQL, Redis, Elasticsearch blieben online.
- DB-Dump:
  - Datei: `/home/kube-bot/backups/zammad-20260617T193554Z/zammad-postgresql.sql.gz`
  - Groesse: ca. `191M`
  - SHA256: `75af32c1d0fe94f89af541cdc89300464cb648391c5aff56b77a780082927210`
  - `gzip -t` erfolgreich.
  - `sha256sum -c` erfolgreich.
- Zammad wurde danach wieder auf `replicas=1` skaliert.
- Abschlusszustand:
  - `zammad-0`: `4/4 Running`, neuer Pod ohne Restarts.
  - `https://service.heckenfels.com/`: HTTP `200`.
- Naechste sichere Schritte:
  - Optional: Zammad-Datei-/PVC-Backup fuer `zammad-var`, Redis und Elasticsearch ergaenzen.
  - Danach GitOps-Zielmodell entscheiden: bestehendes `zammad` adoptieren oder spaeter nach `pidoka-hf-zammad` migrieren.
  - Keine Migration/Cleanup ohne separates OK.

### Ergaenzung — Zammad PVC-Dateisicherung — 2026-06-17 19:55 UTC

- Nach Mislavs OK wurden zusaetzlich die vier `local-path` PV-Verzeichnisse gesichert.
- Fuer die Dateisicherung wurde erneut nur `StatefulSet/zammad` temporaer auf `replicas=0` skaliert.
- PostgreSQL, Redis, Elasticsearch blieben online.
- Backup-Dateien im selben Pfad:
  - `/home/kube-bot/backups/zammad-20260617T193554Z/pvc-zammad-postgresql.tar.gz` ca. `239M`
  - `/home/kube-bot/backups/zammad-20260617T193554Z/pvc-zammad-redis.tar.gz` ca. `7.2M`
  - `/home/kube-bot/backups/zammad-20260617T193554Z/pvc-zammad-elasticsearch.tar.gz` ca. `4.5M`
  - `/home/kube-bot/backups/zammad-20260617T193554Z/pvc-zammad-var.tar.gz` ca. `6.9K`
  - `/home/kube-bot/backups/zammad-20260617T193554Z/status-after-pvc-backup.txt`
- `SHA256SUMS` wurde um DB-Dump und PVC-Tarballs erweitert.
- `sha256sum -c SHA256SUMS` erfolgreich fuer alle fuenf Artefakte.
- `gzip -t` erfolgreich fuer alle vier PVC-Tarballs.
- Backup-Ordner gesamt: ca. `441M`.
- Abschlusszustand:
  - `zammad-0`: `4/4 Running`, neuer Pod ohne Restarts.
  - `https://service.heckenfels.com/`: HTTP `200`.
- Hinweis: Die PVC-Tarballs sind Dateisicherungen der laufenden Backend-PVs; der PostgreSQL-Dump bleibt das primaere konsistente DB-Artefakt.

### Ergaenzung — Zammad GitOps-Adoptionsvorbereitung — 2026-06-17 20:10 UTC

- Nach Mislavs OK wurde sorgfaeltig nur lokal/read-only weitergearbeitet.
- Live-Helm-Release wurde sanitizt exportiert:
  - `/home/kube-bot/backups/zammad-20260617T193554Z/helm-metadata.txt`
  - `/home/kube-bot/backups/zammad-20260617T193554Z/helm-values-all-redacted.json`
  - `/home/kube-bot/backups/zammad-20260617T193554Z/helm-manifest-no-secrets.yaml`
- `helm-values-all-redacted.json` enthaelt keine absichtlich ausgegebenen Secretwerte; sensitive Keys wurden ersetzt.
- `helm-manifest-no-secrets.yaml` enthaelt keine Kubernetes `Secret`-Dokumente.
- Chart-Metadaten:
  - Helm Release `zammad`
  - Chart `zammad-10.2.1`
  - App `6.2.0-1`
  - Dependencies: Elasticsearch, Memcached, PostgreSQL, Redis
- Helm-Chart-Quelle:
  - Aktuelle Zammad-Helm-Seite/Repo verweist auf `https://github.com/zammad/zammad-helm`.
  - Der direkte GitHub Release Asset fuer `zammad-10.2.1.tgz` existiert noch.
  - Der aktuelle Helm-Index listet `10.2.1` aber nicht mehr per `helm pull`; daher wurde fuer die erste Adoptionsvorlage eine statisch gerenderte, sanitizte Manifest-Variante gewaehlt.
- Lokale GitOps-Vorlage erstellt, nicht gepusht und nicht angewendet:
  - `repos/platform-gitops/applications/tenants/pidoka/zammad.yaml`
  - `repos/platform-gitops/tenants/pidoka/prod/zammad/app.yaml`
  - `repos/platform-gitops/tenants/pidoka/prod/zammad/kustomization.yaml`
  - `repos/platform-gitops/tenants/pidoka/prod/zammad/README.md`
- Ziel:
  - ArgoCD Application `pidoka-hf-zammad`
  - Project `tenant-pidoka`
  - Destination Namespace `zammad`
  - Kein automatischer Sync, kein Prune.
- Validierung:
  - Kustomize rendert 19 Ressourcen im Namespace `zammad`.
  - Keine `Secret`-Ressourcen im Render.
  - DMZ `kubectl apply --dry-run=server` erfolgreich.
  - Dry-run meldet erwartbare Adoption-Warnungen: bestehende Ressourcen haben keine `kubectl.kubernetes.io/last-applied-configuration` Annotation, weil sie historisch Helm-managed sind.
  - Externer Check danach: `https://service.heckenfels.com/` HTTP `200`.
- Wichtiger GitOps-Worktree-Hinweis:
  - Es existiert weiterhin eine aeltere uncommitted n8n-Aenderung an `tenants/pidoka/prod/n8n/external-secrets/n8n-secret.yaml`; sie wurde nicht angefasst.
- Naechster sicherer Schritt:
  - Secret-Key-Inventar fuer Zammad erfassen und Infisical/ESO-Zielmodell vorbereiten, ohne Werte auszugeben.
  - Danach erst entscheiden, ob die Zammad-Adoptionsvorlage gepusht und als ArgoCD-App nur zum Diff angelegt wird.
  - Kein Sync/Apply/Migration ohne separates OK.

### Ergaenzung — Zammad Secret-Inventar + ESO-Vorbereitung — 2026-06-17 20:25 UTC

- Nach Mislavs OK wurde mit Zammad weitergearbeitet, weiterhin ohne Cluster-Sync/Apply.
- Secret-Inventar wurde ohne Werte erstellt und im Backup-Pfad abgelegt:
  - `/home/kube-bot/backups/zammad-20260617T193554Z/secret-key-inventory.tsv`
- Inventar:
  - `zammad-postgresql` (`Opaque`): `password` len 6, `postgres-password` len 6
  - `zammad-postgresql-pass` (`Opaque`): `postgresql-pass` len 6
  - `zammad-redis` (`Opaque`): `redis-password` len 6
  - `zammad-redis-pass` (`Opaque`): `redis-password` len 6
- Keine Secretwerte wurden ausgegeben.
- Lokale GitOps/ESO-Vorlage erstellt, nicht gepusht und nicht angewendet:
  - `repos/platform-gitops/applications/tenants/pidoka/zammad-secrets.yaml`
  - `repos/platform-gitops/tenants/pidoka/prod/zammad/external-secrets/kustomization.yaml`
  - `repos/platform-gitops/tenants/pidoka/prod/zammad/external-secrets/zammad-secrets.yaml`
- Zielmodell:
  - Infisical Pfad `platform-kubernetes/prod:/tenants/pidoka/zammad`
  - SecretStore `zammad/dmz-infisical`
  - ExternalSecrets erhalten die bestehenden Ziel-Secret-Namen.
  - Remote-Key-Namen:
    - `POSTGRESQL_PASSWORD`
    - `POSTGRESQL_POSTGRES_PASSWORD`
    - `ZAMMAD_POSTGRESQL_PASS`
    - `REDIS_PASSWORD`
    - `ZAMMAD_REDIS_PASS`
- Validierung:
  - Kustomize/DMZ server-side dry-run erfolgreich.
  - Render enthaelt vier `ExternalSecret` und einen `SecretStore`.
  - Render enthaelt keine Kubernetes `Secret`-Ressourcen.
- Offener Blocker vor echtem ESO-Sync:
  - `zammad/infisical-universal-auth` fehlt aktuell.
  - Dieses Auth-Secret muesste vor Sync aus einem funktionierenden PIDOKA-ESO-Namespace kopiert oder sauber bereitgestellt werden.
  - Das ist eine Secret-/Cluster-Aenderung und braucht separates OK.
- Wichtiger GitOps-Worktree-Hinweis:
  - Weiterhin vorhanden: aeltere uncommitted n8n-Aenderung an `tenants/pidoka/prod/n8n/external-secrets/n8n-secret.yaml`; nicht angefasst.

### Ergaenzung — Zammad Secrets nach Infisical + ESO live — 2026-06-17 20:35 UTC

- Mislav gab OK fuer den schreibenden Secret-/ESO-Schritt.
- Zammad-Secretwerte wurden maschinell aus bestehenden Kubernetes Secrets gelesen und nach DMZ-Infisical geschrieben.
- Keine Secretwerte wurden ausgegeben.
- Infisical:
  - Projekt: `platform-kubernetes` (`d66f3d3b-1484-46f6-8142-f6fc32222b4d`)
  - Environment: `prod`
  - Pfad: `/tenants/pidoka/zammad`
  - Ordner `/tenants/pidoka/zammad` wurde angelegt.
  - Keys geschrieben:
    - `POSTGRESQL_PASSWORD`
    - `POSTGRESQL_POSTGRES_PASSWORD`
    - `ZAMMAD_POSTGRESQL_PASS`
    - `REDIS_PASSWORD`
    - `ZAMMAD_REDIS_PASS`
- `infisical-universal-auth` wurde aus einem funktionierenden PIDOKA-ESO-Namespace nach `zammad` kopiert.
- ESO-Ressourcen wurden live angelegt:
  - `SecretStore/zammad/dmz-infisical`
  - `ExternalSecret/zammad/zammad-postgresql`
  - `ExternalSecret/zammad/zammad-postgresql-pass`
  - `ExternalSecret/zammad/zammad-redis`
  - `ExternalSecret/zammad/zammad-redis-pass`
- Wegen bestehender Kubernetes Secrets nutzt die Zammad-ESO-Vorlage `creationPolicy: Merge` und `deletionPolicy: Retain`.
- Verifikation:
  - `SecretStore/zammad/dmz-infisical`: `Ready=True`, `Valid`, `ReadOnly`
  - Alle vier ExternalSecrets: `SecretSynced`, `Ready=True`
  - Ziel-Secret-Key-Laengen unveraendert gegen Vorinventar:
    - `zammad-postgresql/password` len 6
    - `zammad-postgresql/postgres-password` len 6
    - `zammad-postgresql-pass/postgresql-pass` len 6
    - `zammad-redis/redis-password` len 6
    - `zammad-redis-pass/redis-password` len 6
  - Zammad Pods: Running, `zammad-0` `4/4`, Restarts `0`
  - `https://service.heckenfels.com/`: HTTP `200`
- Statusartefakte:
  - `/home/kube-bot/backups/zammad-20260617T193554Z/status-eso-after.txt`
  - `/home/kube-bot/backups/zammad-20260617T193554Z/secretstore-dmz-infisical.yaml`
  - `/home/kube-bot/backups/zammad-20260617T193554Z/externalsecrets-zammad.yaml`
- Wichtiger GitOps-Worktree-Hinweis:
  - Die Zammad GitOps-/ESO-Dateien sind lokal vorbereitet, aber noch nicht gepusht.
  - Live-ESO wurde manuell angewendet und sollte zeitnah durch GitOps nachgezogen werden.
  - Weiterhin vorhanden: aeltere uncommitted n8n-Aenderung an `tenants/pidoka/prod/n8n/external-secrets/n8n-secret.yaml`; nicht angefasst.

### Ergaenzung — Zammad GitOps gepusht — 2026-06-17 20:45 UTC

- Mislav gab OK, den GitOps-Stand nachzuziehen.
- Lokaler Commit erstellt und nach `origin/main` gepusht:
  - Commit: `4797ae3 Add PIDOKA Zammad GitOps adoption`
- Enthalten:
  - `applications/tenants/pidoka/zammad.yaml`
  - `applications/tenants/pidoka/zammad-secrets.yaml`
  - `tenants/pidoka/prod/zammad/app.yaml`
  - `tenants/pidoka/prod/zammad/kustomization.yaml`
  - `tenants/pidoka/prod/zammad/README.md`
  - `tenants/pidoka/prod/zammad/external-secrets/kustomization.yaml`
  - `tenants/pidoka/prod/zammad/external-secrets/zammad-secrets.yaml`
- Push brachte auch die bereits lokalen Mautic-Commits hoch:
  - `624f944 Add clean PIDOKA Mautic deployment`
  - `fd8a65b Use MariaDB LTS for Mautic`
- Kein ArgoCD-Sync/Apply durch diesen Schritt.
- Verifikation nach Push:
  - Git `main...origin/main` sauber, bis auf die bekannte lokale n8n-Dateiaenderung.
  - Zammad Pods Running, `zammad-0` `4/4`, Restarts `0`.
  - Zammad ExternalSecrets alle `SecretSynced=True`.
  - `https://service.heckenfels.com/`: HTTP `200`.
- Weiterhin offen:
  - Aeltere uncommitted n8n-Aenderung an `tenants/pidoka/prod/n8n/external-secrets/n8n-secret.yaml`; nicht angefasst.
  - Zammad ArgoCD Applications sind im Repo vorhanden, aber nicht automatisch angelegt/synchronisiert, sofern keine Parent-App diesen Pfad managed.
  - Naechster Schritt waere ArgoCD-Diff/Adoption nur mit separatem OK.

## PIDOKA HF Mautic Cleanup + Clean Install — 2026-06-17 16:40 UTC

- Mislav gab explizites OK: alte Legacy-Mautic-App und zugehörige PVCs dürfen gelöscht werden; danach sauber neu aufsetzen.
- Vor Cleanup verifiziert:
  - Alte DB war nicht leer, aber inkonsistent: ca. 107 Tabellen mit Prefix `mtc_`; alte CronJobs suchten Tabellen ohne Prefix.
  - Live-Konfig hatte `db_table_prefix => null`; alte Chart-Env nutzte u.a. `MAUTIC_DB_NAME`, während Mautic `MAUTIC_DB_DATABASE` erwartet.
  - Alte CronJobs liefen in `CrashLoopBackOff` wegen `Table 'mautic.campaigns' doesn't exist`.
- Legacy-DMZ-ArgoCD entschärft:
  - Altes Repo `GitMasterOne/ArgoCD.git`: `applications/hf-mautic.yaml` entfernt.
  - Commit: `664e83e Remove Mautic from legacy DMZ ArgoCD app-of-apps`.
  - Legacy Parent-App `infra-argocd/apps`: danach `Synced / Healthy`, Revision `664e83e`.
  - Alte `infra-argocd/hf-mautic` Application gelöscht.
- Alte DMZ-Ressourcen entfernt:
  - Namespace `hf-mautic` inklusive alter Workloads, CronJobs, Secret, ConfigMaps und PVCs gelöscht.
  - Alte PVs/PVCs `data-hf-mautic-mariadb-0` und `redis-data-hf-mautic-redis-master-0` sind nicht mehr im Cluster sichtbar.
- Neue DMZ-Infisical-Secrets angelegt:
  - Projekt: `platform-kubernetes` (`d66f3d3b-1484-46f6-8142-f6fc32222b4d`)
  - Environment: `prod`
  - Pfad: `/tenants/pidoka/mautic`
  - Secretwerte wurden nicht ausgegeben oder dokumentiert.
  - Erwartete Keys wurden via ESO in `hf-mautic/mautic-secret` synchronisiert; nur Längen geprüft.
- Neues GitOps-Setup:
  - Repo `GitMasterOne/platform-gitops`
  - Commit `624f944 Add clean PIDOKA Mautic deployment`
  - Commit `fd8a65b Use MariaDB LTS for Mautic`
  - Neue IT15-ArgoCD Apps:
    - `pidoka-hf-mautic-secrets`
    - `pidoka-hf-mautic`
  - Beide Apps zuletzt `Synced / Healthy`, Revision `fd8a65be5d4abfd4ac7eec255de2bea2136a8f6a`.
- Neuer Live-Zustand in DMZ `hf-mautic`:
  - `mautic-db-0`: `1/1 Running`, MariaDB `10.11`, PVC `mautic-db-pvc` 10Gi Longhorn.
  - `mautic`: `1/1 Running`, Image `mautic/mautic:5-apache`, PVC `mautic-data-pvc` 5Gi Longhorn.
  - `mautic-cron`: `1/1 Running`, Image `mautic/mautic:5-apache`.
  - Ingress `mautic.heckenfels.com` über Traefik vorhanden.
  - Interner HTTP-Test: `/` leitet auf `/index.php/installer`; Installer antwortet HTTP 200.
  - DB ist frisch und leer: 0 Tabellen, Mautic noch nicht durch Installer eingerichtet.
- Während Aufbau behoben:
  - `mariadb:11.8` hing bei `mariadb-install-db`; auf `mariadb:10.11` geändert.
  - `MAUTIC_TRUSTED_PROXIES` musste JSON sein; Wert in Infisical auf JSON-Array korrigiert.
  - Docker-Hub-DNS/Pull war temporär langsam, später erfolgreich.
- Offener nächster Schritt:
  - Mautic Installer unter `https://mautic.heckenfels.com` abschließen oder CLI-Installationsweg definieren.
  - Danach DB-Tabellen/Health/Cron-Funktion prüfen.
- Lokaler GitOps-Worktree-Hinweis:
  - Es existiert weiterhin eine uncommitted Änderung an `tenants/pidoka/prod/n8n/external-secrets/n8n-secret.yaml`; diese wurde nicht angefasst und nicht gepusht.

### Nächster empfohlener Schritt

Cutover-Plan für Matomo ausarbeiten, bevor Traffic umgestellt wird:
1. finalen Pre-Cutover-Backupzeitpunkt definieren,
2. Freeze-/Wartungsfenster klären,
3. Ingress/Traffic-Umschaltung auswählen,
4. Rollback-Pfad festlegen,
5. danach erst mit explizitem OK umstellen.

## PIDOKA HF Matomo Cutover — 2026-06-17 14:30 UTC

- Mislav meldete ein Wartungsfenster: aktuell arbeitet niemand mit Matomo.
- Cutover wurde durchgeführt.
- Secretwerte wurden nicht ausgegeben.

### Freeze und finaler Stand

- Alte Produktion `hf-matomo/matomo` wurde auf `replicas=0` skaliert, um Writes während Backup/Restore zu stoppen.
- Alte DB `hf-matomo/matomo-db` blieb `1/1` für Dump und Rollback.
- Finaler DB-Dump:
  - `/home/kube-bot/backups/matomo-cutover-20260617T135148Z/matomo-db.sql.gz`
  - SHA256 geprüft.
- Altes Ingress für Rollback gesichert:
  - `/home/kube-bot/backups/matomo-cutover-20260617T135148Z/old-matomo-ingress.yaml`
  - SHA256 geprüft.
- Finales HTML-Backup wurde versucht, aber der Tar-Prozess lief zu lange und wurde abgebrochen.
  - Incomplete Datei: `/home/kube-bot/backups/matomo-cutover-20260617T135148Z/matomo-html.tar.gz.incomplete`
  - Nicht für Restore verwenden.
  - Neuer Matomo-HTML-PVC nutzt weiterhin den vorher verifizierten Restore aus `/home/kube-bot/backups/matomo-20260617T060849Z/matomo-html.tar.gz`.

### Finaler Restore in neues Ziel

- Namespace: `pidoka-hf-matomo`
- DB-PVC `matomo-db-pvc` wurde geleert und mit finalem DB-Dump neu importiert.
- DB-Verifikation nach finalem Import:
  - 53 Tabellen
  - 2 Einträge in `matomo_site`
- App/DB laufen mit gepinnten Produktions-Digests:
  - Matomo: `docker.io/library/matomo@sha256:21b8bae018cd51a05f36bc6beac3861bb314d131df690c47bba1648aad2b8d7e`
  - MariaDB: `docker.io/library/mariadb@sha256:e0236fc6386e7eacd9359e59d0a078bd7aa0d18280d36d13061121bedeaee903`

### GitOps / ArgoCD

- GitOps Commits:
  - `5851072 Add Matomo cutover ingress`
  - `d625118 Enable Matomo cutover workloads`
- IT15 ArgoCD:
  - `pidoka-hf-matomo`: `Synced / Healthy`, Revision `d6251183310cc6e3446fb2bb77d91450ddfb66e4`
  - `pidoka-hf-matomo-secrets`: zuletzt `Synced / Healthy`
- Neuer Ingress:
  - Namespace `pidoka-hf-matomo`
  - Name `matomo-ingress`
  - Host `matomo.heckenfels.com`
  - Class `traefik`
- Alter Ingress `hf-matomo/matomo-ingress` wurde gelöscht.

### Verification nach Cutover

- Neue Deployments:
  - `pidoka-hf-matomo/matomo`: `1/1`
  - `pidoka-hf-matomo/matomo-db`: `1/1`
  - Restarts: `0`
- Traefik intern:
  - `Host: matomo.heckenfels.com` gegen `192.168.20.40`: HTTP `200`
  - gegen `192.168.20.45`: HTTP `200`
- Extern:
  - `http://matomo.heckenfels.com/`: HTTP `301`
  - `https://matomo.heckenfels.com/`: HTTP `200`
- Alte Produktion:
  - `hf-matomo/matomo`: `0/0` eingefroren
  - `hf-matomo/matomo-db`: `1/1` läuft weiter als kurzfristiger Rollback-Pfad
  - alte PVCs bleiben unverändert erhalten.

### Rollback-Pfad

Wenn Rollback nötig:
1. Neues Ingress `pidoka-hf-matomo/matomo-ingress` löschen oder GitOps-App auf vorherigen Stand zurücksyncen.
2. Altes Ingress aus `/home/kube-bot/backups/matomo-cutover-20260617T135148Z/old-matomo-ingress.yaml` wieder anwenden.
3. Alte App `hf-matomo/matomo` wieder auf `replicas=1` skalieren.
4. Prüfen: `https://matomo.heckenfels.com/` HTTP `200`.

### Offene Nacharbeiten

- Alte `hf-matomo` Ressourcen nicht sofort löschen; mindestens kurze Beobachtungsphase abwarten.
- Wenn Matomo stabil bleibt: Altbestand geplant entfernen oder archivieren, nur mit explizitem OK.
- Incomplete HTML-Backup-Datei kann später entfernt werden, wenn kein Bedarf besteht.
- Lokaler GitOps-Worktree-Hinweis:
  - Weiterhin uncommitted: `tenants/pidoka/prod/n8n/external-secrets/n8n-secret.yaml`; nicht Teil der Matomo-Arbeit.

## Zammad GitOps-Adoption vorbereitet — 2026-06-17 22:03 UTC

- Fokus nach Mislavs OK: Zammad-Adoption risikoarm vorbereiten, ohne Live-Sync.
- Live-Zustand vor/nach Prüfung:
  - `https://service.heckenfels.com/`: HTTP `200`.
  - `zammad-0`: `4/4 Running`, Container-Restarts `0`.
  - PostgreSQL, Redis, Elasticsearch, Memcached: Running.
  - Zammad ESO: alle vier ExternalSecrets `SecretSynced=True`, SecretStore `Ready=True`.
- Befund:
  - `pidoka-hf-zammad-secrets` hatte server-side diff ohne Ausgabe / Exit 0.
  - `pidoka-hf-zammad` hatte Apply-Konflikte auf Helm-owned StatefulSet `volumeClaimTemplates`.
- Lokale GitOps-Korrektur vorbereitet, noch nicht gepusht und nicht gesynct:
  - `repos/platform-gitops/tenants/pidoka/prod/zammad/app.yaml`
    - `volumeClaimTemplates` aus den bestehenden Helm-StatefulSets entfernt.
    - `apiVersion: v1` am Elasticsearch `MY_POD_NAME` fieldRef ergänzt.
  - `repos/platform-gitops/tenants/pidoka/prod/zammad/README.md`
    - Hinweis ergänzt, dass StatefulSet-PVC-Templates bei der Adoption absichtlich live/Helm-owned bleiben.
- Verifikation:
  - `npx kustomize build tenants/pidoka/prod/zammad` erfolgreich.
  - DMZ `kubectl diff --server-side=true -f -` gegen gerenderten Zammad-Stand: keine Ausgabe / Exit 0.
  - Zammad danach weiterhin HTTP `200`, Pods Running.
- Weiterhin lokal uncommitted und nicht Teil dieser Arbeit:
  - `repos/platform-gitops/tenants/pidoka/prod/n8n/external-secrets/n8n-secret.yaml`.
- Nächster Schritt mit explizitem OK:
  - Zammad-Adoptionsfix committen/pushen.
  - Danach ArgoCD refresh/diff prüfen.
  - Erst danach optional `pidoka-hf-zammad-secrets` und `pidoka-hf-zammad` syncen, ohne Prune.

## Zammad GitOps-Adoptionsfix gepusht — 2026-06-17 22:07 UTC

- Mislav gab OK zum Commit/Push.
- Commit im Repo `GitMasterOne/platform-gitops`:
  - `edc5624 Prepare Zammad GitOps adoption diff`
- Enthalten:
  - `tenants/pidoka/prod/zammad/app.yaml`
  - `tenants/pidoka/prod/zammad/README.md`
- Push nach `origin/main` erfolgreich.
- IT15 ArgoCD Refresh wurde nur auf den beiden Zammad Applications angestoßen, kein Sync:
  - `pidoka-hf-zammad`: danach `Synced / Healthy`, Revision `edc56244b52263300752a3489134c6d4e3d8e024`.
  - `pidoka-hf-zammad-secrets`: weiterhin `OutOfSync / Healthy`, Revision `edc56244b52263300752a3489134c6d4e3d8e024`.
- Verifikation:
  - DMZ server-side diff für `tenants/pidoka/prod/zammad`: keine Ausgabe / Exit 0.
  - DMZ server-side diff für `tenants/pidoka/prod/zammad/external-secrets`: keine Ausgabe / Exit 0.
  - Zammad `https://service.heckenfels.com/`: HTTP `200`.
  - Zammad ExternalSecrets weiterhin `SecretSynced=True`.
- Einschätzung:
  - Haupt-Zammad-App ist erfolgreich als ArgoCD-Adoptionsstand sauber.
  - Secrets-App ist funktional gesund, aber ArgoCD zeigt OutOfSync vermutlich wegen noch fehlender ArgoCD-Übernahme/Tracking der bereits manuell angewendeten ESO-Objekte.
- Nächster Schritt mit explizitem OK:
  - `pidoka-hf-zammad-secrets` einmal ohne Prune syncen, um ArgoCD-Tracking nachzuziehen.
  - Danach Status prüfen; falls grün, keine weitere Aktion nötig.

## Zammad Secrets-App synchronisiert — 2026-06-17 22:10 UTC

- Mislav gab OK zum Sync.
- Durchgeführt:
  - Nur `pidoka-hf-zammad-secrets` synchronisiert.
  - `prune=false`.
  - `ServerSideApply=true`.
  - Kein Sync der Haupt-Zammad-App nötig, da diese bereits `Synced / Healthy` war.
- Ergebnis IT15 ArgoCD:
  - `pidoka-hf-zammad`: `Synced / Healthy`.
  - `pidoka-hf-zammad-secrets`: `Synced / Healthy`, Operation `Succeeded`.
- Ergebnis DMZ:
  - `https://service.heckenfels.com/`: HTTP `200`.
  - Zammad Pods Running:
    - `zammad-0`: `4/4`, Container-Restarts `0`.
    - PostgreSQL, Redis, Elasticsearch, Memcached Running.
  - ESO:
    - `SecretStore/zammad/dmz-infisical`: `Valid`, `Ready=True`.
    - `ExternalSecret` `zammad-postgresql`, `zammad-postgresql-pass`, `zammad-redis`, `zammad-redis-pass`: `SecretSynced=True`.
- Lokaler GitOps-Stand:
  - `main...origin/main` sauber.
  - Weiterhin uncommitted: `tenants/pidoka/prod/n8n/external-secrets/n8n-secret.yaml`; nicht Teil der Zammad-Arbeit.
- Schlussfolgerung:
  - Zammad ist jetzt in IT15-ArgoCD adoptiert und die Secret-/ESO-Schicht ist GitOps-synchronisiert.
  - Kein Prune/Cleanup durchgeführt.

## Wiedereinstieg / Read-only Verifikation — 2026-06-18 06:20 UTC

- Direkter Slack-Read auf `#it-service` war aus aktueller Runtime nicht moeglich (`not_in_channel`); Stand wurde aus Handoff und von Mislav reinkopiertem Verlauf rekonstruiert.
- DMZ-K3s erreichbar; beide Nodes `Ready`:
  - `mbrkanov-mini-it13` control-plane
  - `mini-it13-02` worker
- IT15-ArgoCD Apps read-only geprueft:
  - `pidoka-n8n`, `pidoka-n8n-secrets`
  - `pidoka-hf-matomo`, `pidoka-hf-matomo-secrets`
  - `pidoka-hf-mautic`, `pidoka-hf-mautic-secrets`
  - `pidoka-hf-zammad`, `pidoka-hf-zammad-secrets`
  - Ergebnis: alle `Synced / Healthy`.
- DMZ Workloads read-only geprueft:
  - `hf-n8n/n8n`: Running, Restarts `0`
  - `pidoka-hf-matomo/matomo` und `matomo-db`: Running, Restarts `0`
  - `hf-mautic/mautic`, `mautic-cron`, `mautic-db`: Running, Restarts `0`
  - `zammad`: Zammad, PostgreSQL, Redis, Elasticsearch, Memcached Running, Restarts `0`
- ESO read-only geprueft:
  - n8n, Matomo, Mautic und Zammad SecretStores `Valid` / `Ready=True`
  - ExternalSecrets `SecretSynced=True`
- Externe HTTP-Checks:
  - `https://service.heckenfels.com/`: `200`
  - `https://matomo.heckenfels.com/`: `200`
  - `https://mautic.heckenfels.com/`: `200`
  - `https://n8n.heckenfels.com/`: `200`
- Zammad Longhorn-Migration verifiziert:
  - Laufende StatefulSets mounten die neuen Longhorn-Claims:
    - `zammad-postgresql-data-longhorn`
    - `zammad-elasticsearch-data-longhorn`
    - `zammad-redis-data-longhorn`
    - `zammad-var-longhorn`
  - Alte `local-path` PVCs existieren weiterhin als Rueckfallbestand und wurden nicht geloescht.
  - Longhorn-Volumes der neuen Zammad-Claims: `attached / healthy`.
  - DB-Zaehler unveraendert:
    - Users `370`
    - Tickets `393`
    - Ticket-Artikel `1182`
    - Organisationen `4`
- Zammad Scheduling-/Image-Risiko bestaetigt:
  - Alle Zammad-Komponenten sind per `nodeSelector` auf `mbrkanov-mini-it13` gepinnt.
  - Aktuell referenzierte alte Bitnami-Backend-Tags liefern bei Docker Hub Registry-Manifestcheck `404`:
    - `bitnami/redis:7.0.11-debian-11-r20`
    - `bitnami/elasticsearch:8.8.2-debian-11-r0`
    - `bitnami/postgresql:15.3.0-debian-11-r17`
    - `bitnami/memcached:1.6.21-debian-11-r4`
- GitOps-Stand:
  - `repos/platform-gitops` `main...origin/main` ist gleichauf.
  - Bekannte lokale uncommitted Aenderung bleibt: `tenants/pidoka/prod/n8n/external-secrets/n8n-secret.yaml`.

### Naechster empfohlener Schritt

Zammad nicht weiter anfassen, bis ein kleiner Image-Strategie-Plan erstellt ist:
1. Ersatz fuer die vier nicht mehr abrufbaren Bitnami-Backend-Images festlegen oder Digests aus bestehendem Node-Cache bewusst sichern.
2. Aenderung zuerst als GitOps-Diff/Dry-run vorbereiten.
3. Danach mit explizitem OK ein kleines Wartungsfenster fuer kontrollierten Rollout planen.
4. Alte `local-path` PVCs weiter behalten; kein Cleanup.

### Entscheidung Mislav — Zammad Version halten — 2026-06-18 06:13 UTC

- Mislav hat klargestellt: Zammad ist alt, fuer diese erste Migration soll bewusst bei der aktuellen Version geblieben werden, um keine zusaetzlichen Upgrade-Probleme einzufuehren.
- Read-only Image-Cache/Digest-Pruefung:
  - Control-Plane `mbrkanov-mini-it13` hat die aktuell laufenden Zammad-Images im Container-Cache.
  - Worker `mini-it13-02` hat diese alten Zammad/Bitnami-Images nicht vollstaendig im Cache.
  - Laufende Image-Digests:
    - `bitnami/memcached:1.6.21-debian-11-r4` -> `sha256:22fd157b63fa6d83a4ad83209ee262bb090f99f02ec39fe6e2a031fa899e3dab`
    - `bitnami/redis:7.0.11-debian-11-r20` -> `sha256:dbb40f9e6e52ef4605e08b6987641edc869d7dc84d812b41a932e8d718bae20c`
    - `bitnami/elasticsearch:8.8.2-debian-11-r0` -> `sha256:bd0f166fa332dc3d11f3364b75bb750bb13c8544895de626e06bc86ac45202c4`
    - `bitnami/postgresql:15.3.0-debian-11-r17` -> `sha256:7f6b00d6b84b0f3115c15aa06694c4dc80e4999ef7ba2b30ec31fc4ded904f13`
    - `ghcr.io/zammad/zammad:6.2.0-1` -> `sha256:1f435bc72f22ff45fbd3442b30494e9f01e0cab569cbb06a0bc0097a3ee827e3`
- Operative Konsequenz:
  - Kein Versionsupgrade als Teil der Storage-/GitOps-Stabilisierung.
  - Naechster sicherer Plan sollte die bestehenden Images/Digests konservieren, z.B. in eine eigene Registry spiegeln oder anderweitig pull-sicher machen.
  - NodeSelector erst entfernen, wenn Images auf beiden Nodes pullbar oder lokal verfuegbar sind.

### Zammad Image-Konservierungsplan — read-only vorbereitet — 2026-06-18 06:22 UTC

- Read-only Pruefung:
  - Keine interne Registry/Harbor-Installation im DMZ-K3s sichtbar.
  - Auf DMZ Control-Plane vorhanden: `ctr`, `crictl`.
  - Nicht vorhanden: `skopeo`, `docker`, `nerdctl`.
- Ziel bleibt: Zammad-Version und Backend-Versionen fuer die erste Migration unveraendert halten.
- Empfohlener konservativer Pfad:
  1. Ziel fuer Image-Konservierung festlegen:
     - bevorzugt private Registry im Intranet/DMZ oder bestehendes GitHub Container Registry Repo.
     - alternativ kurzfristig Image-Archive auf Control-Plane plus Backup-Ziel sichern.
  2. Exakt laufende Images aus dem Control-Plane-Cache exportieren oder spiegeln:
     - Zammad `ghcr.io/zammad/zammad@sha256:1f435bc72f22ff45fbd3442b30494e9f01e0cab569cbb06a0bc0097a3ee827e3`
     - Bitnami Memcached/Redis/Elasticsearch/PostgreSQL mit den oben dokumentierten Digests.
  3. Integritaet pruefen:
     - Image-ID/Digest nach Import/Pull vergleichen.
     - Test-Pull auf Worker erst nach OK.
  4. GitOps erst danach auf unveraenderte Versionen, aber pull-sichere Referenzen umstellen.
  5. NodeSelector erst entfernen, wenn beide Nodes die Images ziehen koennen und ein kontrollierter Restart erfolgreich war.
- Nicht tun:
  - Kein Zammad-Upgrade.
  - Kein Wechsel auf neue Bitnami-Major-/OS-Tags.
  - Kein Rollout/Restart ohne Wartungsfenster und explizites OK.

### Zammad Image-Archive erstellt — 2026-06-18 06:22 UTC

- Mislav gab OK fuer ein Image-Archive statt private Registry als ersten konservativen Schritt.
- Archiv auf DMZ Control-Plane erstellt:
  - Pfad: `/home/kube-bot/backups/zammad-image-archive-20260618T062200Z`
  - Datei: `zammad-runtime-images.tar`
  - Groesse: `1097786368` Bytes, ca. `1.1G`
  - Begleitdateien: `images.txt`, `SHA256SUMS`
- `sha256sum -c SHA256SUMS` erfolgreich.
- Archiv enthaelt die erwarteten Runtime-Images:
  - `ghcr.io/zammad/zammad:6.2.0-1`
  - `bitnami/memcached:1.6.21-debian-11-r4`
  - `bitnami/redis:7.0.11-debian-11-r20`
  - `bitnami/elasticsearch:8.8.2-debian-11-r0`
  - `bitnami/postgresql:15.3.0-debian-11-r17`
- Keine Kubernetes-Ressourcen veraendert, kein Rollout/Restart durchgefuehrt.
- Wichtig:
  - Das Archiv ist ein Recovery-Artefakt auf der Control-Plane.
  - Scheduling auf Worker ist dadurch noch nicht geloest.
  - Naechster Schritt waere nur mit OK: Archiv zusaetzlich auf Backup-Ziel/Synology kopieren oder Images auf Worker importieren/testen.

### Zammad Image-Archive auf Worker kopiert — 2026-06-18 06:31 UTC

- Mislav wollte das Archiv zunaechst lokal lassen, hoechstens auf den Worker kopieren.
- Direkte Control-Plane -> Worker Kopie per SSH scheiterte, weil die Control-Plane keinen passenden SSH-Key fuer `kube-bot@192.168.20.45` hatte.
- Kopie wurde deshalb ueber die aktuelle OpenClaw Runtime als temporaere Zwischenstation durchgefuehrt:
  - Quelle: `kube-bot@192.168.20.40:/home/kube-bot/backups/zammad-image-archive-20260618T062200Z`
  - Ziel: `kube-bot@192.168.20.45:/home/kube-bot/backups/zammad-image-archive-20260618T062200Z`
  - Temporaere lokale Kopie unter `/tmp/zammad-image-archive-20260618T062200Z` wurde nach erfolgreichem Upload geloescht.
- Verifikation auf Worker:
  - `sha256sum -c SHA256SUMS` erfolgreich.
  - Datei `zammad-runtime-images.tar` ca. `1.1G` vorhanden.
- Keine Images wurden auf dem Worker importiert.
- Keine Kubernetes-Ressourcen geaendert, kein Rollout/Restart.

### Zammad Helper-Image-Archive ergaenzt — 2026-06-18 06:47 UTC

- Bei GitOps-Read-only-Pruefung wurden zwei zusaetzliche fuer Restart/Recovery relevante Init-/Hilfsimages gefunden:
  - `docker.io/bitnami/bitnami-shell:11-debian-11-r131` fuer Elasticsearch InitContainer
  - `docker.io/library/alpine:3.18.4` fuer Zammad Volume-Permissions InitContainer
- Zusatzarchiv erstellt:
  - Control-Plane: `/home/kube-bot/backups/zammad-image-archive-20260618T062200Z/zammad-helper-images.tar`
  - Groesse: ca. `36M`
  - Begleitdatei: `helper-images.txt`
  - `SHA256SUMS` wurde erweitert.
- Zusatzarchiv auf Worker kopiert:
  - `kube-bot@192.168.20.45:/home/kube-bot/backups/zammad-image-archive-20260618T062200Z`
  - `sha256sum -c SHA256SUMS` erfolgreich.
- Temporaere OpenClaw-Zwischenkopie wurde geloescht.
- Keine Images importiert, keine Kubernetes-Ressourcen geaendert, kein Rollout/Restart.

## Aktueller Wiedereinstiegspunkt — PIDOKA Migration — 2026-06-18 06:55 UTC

### Gesamtstand

- `n8n`
  - Fachlich PIDOKA / HF.
  - Von Legacy-DMZ-ArgoCD nach IT15-ArgoCD migriert.
  - Apps `pidoka-n8n` und `pidoka-n8n-secrets` zuletzt `Synced / Healthy`.
  - ESO/Infisical Secret-Sync aktiv; keine Secretwerte dokumentiert.
  - Extern `https://n8n.heckenfels.com/` zuletzt HTTP `200`.
- `Matomo`
  - Nach `pidoka-hf-matomo` migriert.
  - Cutover erfolgt; neuer Ingress bedient `matomo.heckenfels.com`.
  - Apps `pidoka-hf-matomo` und `pidoka-hf-matomo-secrets` zuletzt `Synced / Healthy`.
  - Extern `https://matomo.heckenfels.com/` zuletzt HTTP `200`.
  - Alte `hf-matomo` Ressourcen/PVCs als kurzfristiger Rollback-Bestand behalten; nicht loeschen ohne OK.
- `Mautic`
  - Alte Legacy-Mautic-App und PVCs wurden nach Mislavs OK entfernt.
  - Clean Install in `hf-mautic` via IT15-ArgoCD aufgebaut.
  - Apps `pidoka-hf-mautic` und `pidoka-hf-mautic-secrets` zuletzt `Synced / Healthy`.
  - Pods `mautic`, `mautic-cron`, `mautic-db` zuletzt Running, Restarts `0`.
  - Extern `https://mautic.heckenfels.com/` zuletzt HTTP `200`, aber Installer/Ersteinrichtung ist noch offen.
  - Naechster fachlicher Schritt: Installer abschliessen oder CLI-Installationsweg definieren; danach DB-Tabellen, Health und Cron pruefen.
- `Zammad`
  - GitOps/ESO adoptiert.
  - Storage-Migration von alten `local-path` PVCs auf neue Longhorn-PVCs abgeschlossen.
  - Laufende StatefulSets mounten:
    - `zammad-postgresql-data-longhorn`
    - `zammad-elasticsearch-data-longhorn`
    - `zammad-redis-data-longhorn`
    - `zammad-var-longhorn`
  - Alte `local-path` PVCs bleiben als Rueckfallbestand; nicht loeschen ohne OK.
  - Apps `pidoka-hf-zammad` und `pidoka-hf-zammad-secrets` zuletzt `Synced / Healthy`.
  - Extern `https://service.heckenfels.com/` zuletzt HTTP `200`.
  - DB-Zaehler nach Migration unveraendert: Users `370`, Tickets `393`, Ticket-Artikel `1182`, Organisationen `4`.
  - Zammad-Version bewusst halten, kein Upgrade im Rahmen der ersten Migration.
  - Zammad Runtime-/Helper-Images als Archive auf Control-Plane und Worker gesichert:
    - `/home/kube-bot/backups/zammad-image-archive-20260618T062200Z`
    - `zammad-runtime-images.tar`
    - `zammad-helper-images.tar`
    - `SHA256SUMS` auf beiden Nodes geprueft.
  - Images wurden nicht auf dem Worker importiert.
  - NodeSelector auf `mbrkanov-mini-it13` bleibt vorerst sinnvoll, weil alte Bitnami-Tags extern nicht mehr pullbar sind.

### Offene Punkte

- Mautic Installer/Initialisierung abschliessen; danach Health, DB-Tabellen und Cron-Funktion pruefen.
- Matomo Altbestand `hf-matomo` nach Beobachtungsphase planen: behalten, archivieren oder mit OK entfernen.
- Zammad alte `local-path` PVCs nach Beobachtungsphase planen: behalten oder mit OK entfernen.
- Zammad Image-Strategie spaeter entscheiden:
  - aktuell nur Archive vorhanden;
  - langfristig private Registry/Spiegelung sinnvoll;
  - kein Zammad-Upgrade als Teil dieser Stabilisierung.
- Bekannte lokale GitOps-Aenderung weiter offen:
  - `repos/platform-gitops/tenants/pidoka/prod/n8n/external-secrets/n8n-secret.yaml`
  - nicht Teil der Zammad/Matomo/Mautic-Arbeiten; nicht unbesehen committen oder verwerfen.
- Weitere PIDOKA/HF Apps noch offen:
  - `hf-espocrm`
  - `hf-suitecrm`

### Naechster empfohlener Schritt nach Wiederaufnahme

1. Read-only Kurzstatus pruefen:
   - IT15-ArgoCD PIDOKA Apps `Synced / Healthy`.
   - DMZ Pods/PVCs/ESO fuer `hf-mautic`, `pidoka-hf-matomo`, `zammad`, `hf-n8n`.
   - Externe HTTP-Checks fuer `mautic`, `matomo`, `service`, `n8n`.
2. Danach mit Mislav an Mautic weitermachen:
   - Installer unter `https://mautic.heckenfels.com` abschliessen oder CLI-Setup definieren.
   - Keine produktiven Cleanup-/Prune-/PVC-Loeschungen ohne explizites OK.

## Mautic Read-only Einstiegspunkt — 2026-06-18 07:02 UTC

- Mislav gab OK fuer schnellen read-only Mautic-Kurzstatus.
- IT15-ArgoCD:
  - `pidoka-hf-mautic`: `Synced / Healthy`
  - `pidoka-hf-mautic-secrets`: `Synced / Healthy`
- DMZ `hf-mautic`:
  - `mautic-db-0`: `1/1 Running`, Restarts `0`, Node `mini-it13-02`
  - `mautic`: `1/1 Running`, Restarts `0`
  - `mautic-cron`: `1/1 Running`, Restarts `0`
  - PVCs:
    - `mautic-db-pvc` Longhorn 10Gi Bound
    - `mautic-data-pvc` Longhorn 5Gi Bound
  - ESO:
    - `SecretStore/dmz-infisical`: `Valid`, `Ready=True`
    - `ExternalSecret/mautic-secret`: `SecretSynced`, `Ready=True`
    - erwartete Secret-Keys haben nicht-leere Werte; nur Laengen geprueft.
- HTTP:
  - `https://mautic.heckenfels.com/` liefert HTTP `200`
  - Redirect/Final URL: `http://mautic.heckenfels.com/s/login`
  - Ergebnis: nicht mehr Installer-Seite, sondern Login-Seite sichtbar.
- DB/Runtime:
  - Mautic App-Container meldet `Mautic 5.2.11 - app/prod`.
  - `/var/www/html/config/local.php` existiert.
  - DB enthaelt `107` Tabellen; Tabellen `users` und `leads` existieren.
  - Doctrine-Migration-Status meldet dennoch `Executed 0`, `New 53`.
- Auffaelligkeit:
  - `mautic-cron` loggt aktuell weiterhin: `Waiting for Mautic to be installed`.
  - Das ist ein echter aktueller Zustand (`--since=2m` bestaetigt), kein altes Log.
- Naechster kleiner Schritt:
  - Read-only pruefen, welche Bedingung der `mautic-cron` Container fuer "installed" erwartet.
  - Danach entscheiden, ob ein kontrollierter Pod-Restart, Console-Kommando oder GitOps-Fix noetig ist.
  - Keine Aenderung ohne explizites OK.

### Mautic Cron Ursache + lokaler GitOps-Fix vorbereitet — 2026-06-18 07:08 UTC

- Ursache read-only verifiziert:
  - `mautic-cron` wartet in `/startup/wait_for_mautic_install.sh`.
  - Das Skript prueft `${MAUTIC_VOLUME_CONFIG}/local.php` auf `db_driver` und `site_url`.
  - Web-Container sieht die installierte Datei `/var/www/html/config/local.php`:
    - Groesse `450`
    - `db_driver` und `site_url` gesetzt.
  - Cron-Container sah eine andere/frische Image-Datei:
    - Groesse `568`
    - `db_driver` vorhanden, aber `site_url` fehlt.
  - Grund im GitOps-Manifest: `mautic` mountet `mautic-data-pvc` nach `/var/www/html/config`, `/var/www/html/var/logs`, `/var/www/html/docroot/media`; `mautic-cron` hatte diese Mounts nicht.
- Lokaler GitOps-Fix vorbereitet, noch nicht committed/gepusht/gesynct:
  - Datei: `repos/platform-gitops/tenants/pidoka/prod/mautic/app.yaml`
  - `mautic-cron` bekommt dieselben `mautic-data-pvc` VolumeMounts wie Web:
    - `/var/www/html/config` subPath `config`
    - `/var/www/html/var/logs` subPath `logs`
    - `/var/www/html/docroot/media` subPath `media`
- Validierung:
  - `npx kustomize build tenants/pidoka/prod/mautic` erfolgreich.
  - DMZ `kubectl apply --dry-run=server -f -` erfolgreich.
- Wichtig:
  - Noch keine Cluster-Aenderung.
  - Noch kein Commit/Push.
  - Ein echter Sync wuerde mindestens `mautic-cron` neu starten und braucht Mislavs explizites OK.
  - Bekannte uncommitted n8n-Datei existiert weiterhin separat.

### Mautic Cron-Fix ausgerollt — 2026-06-18 07:15 UTC

- Mislav gab OK fuer Commit/Push/Sync.
- GitOps Commit:
  - Repo: `GitMasterOne/platform-gitops`
  - Commit: `e06d314 Mount Mautic shared data in cron pod`
  - Geaendert: nur `tenants/pidoka/prod/mautic/app.yaml`
  - Bekannte lokale n8n-Aenderung blieb uncommitted und unangetastet.
- Push nach `origin/main` erfolgreich.
- IT15-ArgoCD:
  - `pidoka-hf-mautic` synchronisiert.
  - Status danach: `Synced / Healthy`, Revision `e06d3147590e8098c10006d34d1e69eafeed34a3`.
  - `pidoka-hf-mautic-secrets` blieb `Synced / Healthy`.
- DMZ `hf-mautic`:
  - `mautic-cron` wurde durch Deployment-Rollout neu gestartet.
  - Neuer Pod: `mautic-cron-59565dc547-k4xx4`, `1/1 Running`, Restarts `0`.
  - `mautic` und `mautic-db` blieben Running, Restarts `0`.
  - Cron ist registriert (`crontab -u www-data -l`) und Prozess `cron -f` laeuft.
  - Logs seit dem Rollout zeigen nur:
    - `MySQL is not ready yet, waiting...`
    - `MySQL is alive and well.`
  - Keine neuen `Waiting for Mautic to be installed` Logs nach dem Rollout.
- HTTP:
  - `https://mautic.heckenfels.com/` -> HTTP `200`, final `http://mautic.heckenfels.com/s/login`.
- GitOps Worktree:
  - `main...origin/main` gleichauf.
  - Weiterhin uncommitted: `tenants/pidoka/prod/n8n/external-secrets/n8n-secret.yaml`.
- Naechster sinnvoller Schritt:
  - Nach planmaessigem Cron-Zeitpunkt erneut Logs pruefen, ob `segments:update`, `campaigns:update`, `campaigns:trigger` sauber laufen.
  - Danach entscheiden, ob HTTPS/Proxy-Redirect fuer Mautic noch korrigiert werden muss, weil final URL aktuell `http://mautic.heckenfels.com/s/login` ist.

## n8n ExternalSecret normalisiert — 2026-06-18 07:27 UTC

- Mislav gab OK fuer Schritt 1: n8n geradeziehen. Demo-App wurde dabei nicht angefasst.
- Lokale Aenderung war die schon bekannte n8n-Normalisierung:
  - `SecretStore/hf-n8n/dmz-infisical` nutzt jetzt `secretsPath: /tenants/pidoka/n8n`.
  - `ExternalSecret/hf-n8n/n8n-secret` nutzt kurze `remoteRef.key` Namen:
    - `BASIC_AUTH_USER`
    - `BASIC_AUTH_PASSWORD`
    - `ENCRYPTION_KEY`
- Server-side dry-run gegen DMZ war erfolgreich.
- GitOps Commit:
  - Repo: `GitMasterOne/platform-gitops`
  - Commit: `de40887 Normalize n8n Infisical secret refs`
  - Push nach `origin/main` erfolgreich.
- IT15-ArgoCD:
  - `pidoka-n8n-secrets` gezielt synchronisiert.
  - Ergebnis: `Succeeded / Synced / Healthy`, Revision `de40887a89ab929a364a5c3ba1f320ca9cba0518`.
  - `pidoka-n8n` blieb `Synced / Healthy`.
- DMZ `hf-n8n`:
  - Pod `n8n-774976cd74-z5kvb`: `1/1 Running`, Restarts `0`.
  - PVC `n8n`: Bound, Longhorn 5Gi.
  - `ExternalSecret/n8n-secret`: `SecretSynced=True`.
  - `SecretStore/dmz-infisical`: `Valid`, `Ready=True`.
  - Secret-Key-Laengen geprueft, keine Werte ausgegeben.
- Extern:
  - `https://n8n.heckenfels.com/` HTTP `200`.
- GitOps Worktree:
  - `main...origin/main` sauber.
- Noch offen:
  - Schritt 2 waere mit separatem OK: `demo-guestbook-cattaro-stage` entfernen.

## Demo Guestbook entfernt — 2026-06-18 07:31 UTC

- Mislav gab OK fuer Schritt 2: Demoanwendung `demo-guestbook-cattaro-stage` entfernen.
- Vorher:
  - IT15-ArgoCD Application `demo-guestbook-cattaro-stage`: `Synced / Healthy`, Project `tenant-cattaro`, Zielnamespace `tenant-cattaro-stage`.
  - DMZ Ressourcen:
    - `deployment/guestbook-ui`
    - `replicaset/guestbook-ui-*`
    - `pod/guestbook-ui-*`
    - `service/guestbook-ui`
- Durchgefuehrt:
  - ArgoCD Application `argocd/demo-guestbook-cattaro-stage` geloescht.
  - Da keine ArgoCD-Finalizer-Kaskade/prune ausgefuehrt wurde, blieben die Ressourcen zunaechst orphaned.
  - Tracking-Annotation bestaetigte Zugehoerigkeit zur Demo-App:
    - `argocd.argoproj.io/tracking-id: demo-guestbook-cattaro-stage:apps/Deployment:tenant-cattaro-stage/guestbook-ui`
  - Danach gezielt geloescht:
    - `deployment/guestbook-ui`
    - `service/guestbook-ui`
- Verifikation:
  - IT15-ArgoCD Application `demo-guestbook-cattaro-stage` ist absent.
  - Namespace `tenant-cattaro-stage` zeigt keine `all,pvc,ingress` Ressourcen mehr.
  - Kontrollierte Apps bleiben gruen:
    - `pidoka-n8n`: `Synced / Healthy`
    - `pidoka-n8n-secrets`: `Synced / Healthy`
    - `pidoka-hf-mautic`: `Synced / Healthy`
    - `pidoka-hf-zammad`: `Synced / Healthy`
    - `platform-argocd-projects`: `Synced / Healthy`
  - GitOps `main...origin/main` sauber.
- Nicht geloescht:
  - Namespace `tenant-cattaro-stage` selbst blieb bestehen.
  - Keine AppProject-/RBAC-/Cluster-Secret-Bereinigung durchgefuehrt.
- Naechster optionaler Schritt:
  - Read-only pruefen, ob `tenant-cattaro-stage` noch in ArgoCD Cluster-Secret/AppProject/RBAC als erlaubter Namespace benoetigt wird.
  - Cleanup nur mit separatem OK.
  - Mislav hat Cleanup auf spaeter verschoben; merken.

## Altes DMZ-ArgoCD / EspoCRM + SuiteCRM Befund — 2026-06-18 14:40 UTC

- Mislav: `espocrm` wird nicht mehr benoetigt, war nur Test.
- Mislav: `suitecrm` war ebenfalls Test, soll aber perspektivisch in Produktion; Neuinstallation mit neuer Version ist akzeptabel, wenn einfacher.
- Read-only Alt-ArgoCD Bestand `infra-argocd`:
  - `apps`: `Synced / Healthy`, Parent-App, verwaltet noch `hf-espocrm` und `suitecrm`.
  - `hf-espocrm`: `OutOfSync / Progressing`, Zielnamespace `hf-espocrm`.
  - `suitecrm`: `Synced / Progressing`, Zielnamespace `hf-suitecrm`.
- `hf-espocrm` Live:
  - `espocrm` Deployment `1/1 Running`.
  - `hf-espocrm-mariadb-0` `CrashLoopBackOff`.
  - PVC `data-hf-espocrm-mariadb-0` Longhorn 8Gi Bound.
- `hf-suitecrm` Live:
  - `suitecrm-suitecrm` `0/2 ImagePullBackOff`.
  - Ursache: altes Image `bitnami/suitecrm:8.8.1` wird nicht gezogen und ist nicht lokal gecached.
  - `suitecrm-mariadb-0` laeuft aktuell `1/1`, hat aber sehr viele Restarts; Root-Secret passt nicht mehr zur DB, App-DB-User funktioniert.
  - PVCs Longhorn/Bound:
    - `data-suitecrm-mariadb-0` 10Gi
    - `suitecrm-suitecrm` 10Gi
  - DB-Bestand klein:
    - 218 Tabellen
    - `users`: 1
    - `accounts`: 4
    - `contacts`: 4
  - App-Secret hat leere SMTP-Felder; Werte wurden nicht ausgegeben.
- Externe Quellen geprueft:
  - SuiteCRM Download-Seite zeigt aktuelle SuiteCRM 8.10 Linie.
  - GitHub Releases zeigen SuiteCRM-Core 8.10.1/8.9.x/8.8.x Releases.
  - Docker Hub meldet Bitnami `suitecrm` nicht mehr frei verfuegbar.
- Bewertung:
  - EspoCRM kann spaeter als Test-App entfernt werden, aber erst mit explizitem OK.
  - SuiteCRM sollte fuer Produktion eher sauber neu aufgebaut werden statt den alten Bitnami-Teststack zu reparieren.
  - Alte SuiteCRM-PVCs sollten vor Cleanup mindestens gesichert oder bewusst als Altbestand behalten werden.
- Naechster empfohlener Schritt:
  - SuiteCRM-Neuaufbau-Plan fuer `pidoka-hf-suitecrm` erstellen:
    - aktuelle SuiteCRM 8.x Quelle/Containerstrategie festlegen,
    - DB/PVC/Infisical/ESO Zielmodell definieren,
    - altes `hf-suitecrm` nicht loeschen, bis neuer Stack laeuft oder Backup/OK vorliegt.

## SuiteCRM Clean Install live — 2026-06-18 15:10 UTC

- Mislav gab OK: alter SuiteCRM-Testbestand muss nicht behalten werden, kann weg und sauber neu installiert werden.
- Legacy DMZ-ArgoCD:
  - `applications/suitecrm.yaml` aus altem Repo entfernt.
  - Commit `fa379bd Remove SuiteCRM from legacy DMZ ArgoCD app-of-apps` gepusht.
  - `infra-argocd/apps` synchronisiert, danach `Synced / Healthy`.
  - Alte ArgoCD Application `suitecrm` ist absent.
- Alter Namespace:
  - `hf-suitecrm` geloescht und spaeter fuer Neuaufbau frisch angelegt.
  - Alte Longhorn-PVs sind noch als `Released` vorhanden und wurden nicht geloescht:
    - alter App-PV `pvc-1fe75ee1-d3e0-4ad9-861b-ba79cf0f7189`
    - alter DB-PV `pvc-557bb62f-3d89-48fb-9327-37040f1c0986`
- Neues GitOps:
  - Repo `GitMasterOne/platform-gitops`
  - Commit `e64776a Add SuiteCRM GitOps deployment`
  - Commit `fd8c4d2 Add SuiteCRM auto-install admin env`
  - Neue IT15-ArgoCD App: `pidoka-hf-suitecrm`
  - App revision: `fd8c4d24cf97761f237e90bda8def10aa821b91a`
  - Status zuletzt: `Synced / Healthy`, Operation `Succeeded`.
- Neuer Live-Zustand:
  - Namespace `hf-suitecrm`
  - Image: `docker.io/guerchele/suitecrm:8.10.1` (inoffizielles Community-Image, Version bewusst gepinnt)
  - DB: `docker.io/library/mariadb:10.11`
  - Pods:
    - `suitecrm-db-0`: `1/1 Running`
    - `suitecrm-6d84847488-kftxs`: `1/1 Running`, Restarts `0`
  - PVCs Longhorn/Bound:
    - `suitecrm-db-pvc` 10Gi
    - `suitecrm-state-pvc` 10Gi
  - Ingress:
    - Host `suitecrm.heckenfels.com`
    - Externer Test: `https://suitecrm.heckenfels.com/` HTTP `200`
- Secrets:
  - DMZ-Infisical ist erreichbar, aber der schreibende Bootstrap-Zugang war in dieser Session nicht verfuegbar.
  - Deshalb wurde fuer den Start ein direktes Kubernetes Secret `hf-suitecrm/suitecrm-secret` mit generierten Werten angelegt.
  - Werte wurden nicht dokumentiert oder ausgegeben.
  - `kubectl.kubernetes.io/last-applied-configuration` wurde vom Secret entfernt; keine base64-kodierten Secretwerte in dieser Annotation.
  - Die vorbereitete ArgoCD Secrets-App `pidoka-hf-suitecrm-secrets` wurde bewusst noch nicht angelegt/aktiviert.
- Offene Punkte:
  - SuiteCRM Secrets nach DMZ-Infisical `/tenants/pidoka/suitecrm` uebertragen, sobald schreibender Infisical-Zugang wieder verfuegbar ist.
  - Danach `pidoka-hf-suitecrm-secrets` anlegen/syncen und `ExternalSecret/suitecrm-secret` verifizieren.
  - Admin-Zugang sicher an Mislav uebergeben bzw. nach erstem Login rotieren; nicht in Slack posten.
  - Alte `Released` SuiteCRM-PVs erst nach separatem OK loeschen.
  - EspoCRM-Test-App spaeter separat entfernen, ebenfalls nur mit OK.

## SuiteCRM Secrets nach DMZ-Infisical uebertragen — 2026-06-18 19:50 UTC

- Mislav bat darum, die SuiteCRM-Secrets sauber zu uebertragen.
- DMZ-Infisical API wurde temporaer ueber Port-Forward auf `127.0.0.1:18081` erreicht; Tunnel danach beendet.
- Verwendet wurde die vorhandene `infisical-universal-auth` Machine Identity aus `hf-suitecrm`; Login erfolgreich.
- Infisical:
  - Projekt: `platform-kubernetes` (`d66f3d3b-1484-46f6-8142-f6fc32222b4d`)
  - Environment: `prod`
  - Pfad: `/tenants/pidoka/suitecrm`
  - Ordner `/tenants/pidoka/suitecrm` wurde angelegt.
  - 12 Keys wurden aus `hf-suitecrm/suitecrm-secret` nach Infisical geschrieben.
  - Secretwerte wurden nicht ausgegeben oder dokumentiert.
- GitOps:
  - Commit `233c13b Use merge policy for SuiteCRM ExternalSecret` gepusht.
  - Grund: bestehendes Live-Secret wurde kontrolliert von ESO uebernommen, ohne Secret-Recreate.
  - ArgoCD App `pidoka-hf-suitecrm-secrets` wurde angelegt und synchronisiert.
- Verifikation:
  - `pidoka-hf-suitecrm`: `Synced / Healthy`, Revision `233c13bdcb449e8bb869a415b983d9930b49bb95`
  - `pidoka-hf-suitecrm-secrets`: `Synced / Healthy`, gleiche Revision
  - `SecretStore/hf-suitecrm/dmz-infisical`: `Ready=True`, `Valid`, Capability `ReadOnly`
  - `ExternalSecret/hf-suitecrm/suitecrm-secret`: `Ready=True`, `SecretSynced`
  - Kubernetes Secret `hf-suitecrm/suitecrm-secret`: 12 Keys, keine `kubectl.kubernetes.io/last-applied-configuration` Annotation.
  - SuiteCRM Pods weiter stabil:
    - `suitecrm-db-0`: `1/1 Running`, Restarts `0`
    - `suitecrm-6d84847488-kftxs`: `1/1 Running`, Restarts `0`
  - `https://suitecrm.heckenfels.com/`: HTTP `200`
- Weiter offen:
  - Admin-Zugang sicher an Mislav uebergeben bzw. nach erstem Login rotieren; nicht in Slack posten.
  - Alte `Released` SuiteCRM-PVs erst nach separatem OK loeschen.
  - EspoCRM-Test-App spaeter separat entfernen, ebenfalls nur mit OK.

## EspoCRM Test-App aus altem DMZ-ArgoCD entfernt — 2026-06-18 19:58 UTC

- Mislav gab explizit OK: `hf-espocrm` soll komplett entfernt werden.
- Legacy Repo `GitMasterOne/ArgoCD.git`:
  - Datei `applications/hf-espocrm.yaml` entfernt.
  - Commit `5c3e791 Remove EspoCRM from legacy DMZ ArgoCD app-of-apps` gepusht.
- Altes DMZ-ArgoCD:
  - Parent-App `infra-argocd/apps` auf Revision `5c3e7916bd7ac759bd0ec6559de221df2a6136fd` synchronisiert.
  - Status: `Synced / Healthy`.
  - Application `hf-espocrm` ist absent.
- Cluster-Cleanup:
  - Namespace `hf-espocrm` geloescht.
  - Orphaned/released Longhorn PV `pvc-db4dff11-af0c-4a66-8ae9-546c32e8be09` geloescht.
  - Verifikation: Namespace `hf-espocrm` absent, keine EspoCRM-PVs mehr sichtbar.
- Aktueller alter ArgoCD-Bestand:
  - Nur noch Application `infra-argocd/apps` ist vorhanden.
  - Die alte ArgoCD-Installation selbst laeuft weiterhin im Namespace `infra-argocd`.
- Naechster moeglicher Schritt:
  - Wenn alle Legacy-Abhaengigkeiten weg sind, Read-only pruefen, ob `infra-argocd` selbst dekommissioniert werden kann.
  - Entfernen der alten ArgoCD-Installation nur mit separatem OK.

## Architektur-Notiz neues ArgoCD App-of-Apps — 2026-06-18 20:00 UTC

- Mislav fragte, ob das App-of-Apps-Konzept im neuen ArgoCD benoetigt wird.
- Empfehlung/Entscheidung fuer spaeter:
  - Nicht das alte selbstreferenzielle monolithische `apps -> applications -> apps` Muster weiterfuehren.
  - App-of-Apps im neuen IT15-ArgoCD weiterhin sinnvoll, aber schlank und getrennt:
    - `platform-apps` fuer Plattform-/Infra-Bausteine.
    - `tenant-pidoka-apps` fuer PIDOKA Apps.
    - `tenant-cattaro-apps` fuer Cattaro Apps.
  - Vorteil: klare Ownership, gezieltes Sync/Prune pro Bereich, weniger Blast Radius.
- Mislav: Bitte merken; Umsetzung eventuell spaeter.

## Altes DMZ-ArgoCD dekommissioniert — 2026-06-18 20:10 UTC

- Mislav bat, mit der Bereinigung weiterzumachen.
- Vorheriger Check:
  - `infra-argocd` enthielt nur noch die alte ArgoCD-Installation selbst.
  - Alte ArgoCD Application `apps` war nur noch selbstverwaltender Parent ohne Tenant-Child-Apps.
  - Keine verbleibenden Tenant-Apps im alten DMZ-ArgoCD.
- Legacy Repo `GitMasterOne/ArgoCD.git`:
  - Datei `applications/apps.yaml` entfernt.
  - Commit `223694d Remove legacy DMZ ArgoCD app-of-apps` gepusht.
  - Verzeichnis `applications/` ist damit leer/ohne getrackte Application-Manifeste.
- Cluster-Cleanup DMZ:
  - Namespace `infra-argocd` geloescht.
  - Alte ArgoCD CRDs geloescht:
    - `appprojects.argoproj.io`
    - `applications.argoproj.io`
    - `applicationsets.argoproj.io`
  - Alte ArgoCD ClusterRoles/ClusterRoleBindings geloescht:
    - `argocd-application-controller`
    - `argocd-notifications-controller`
    - `argocd-server`
- Bewusst stehen gelassen:
  - `argocd-dmz-platform-manager`
  - `argocd-demo-manager-discovery`
  - Diese koennen zur IT15-ArgoCD DMZ-Anbindung/Discovery gehoeren und wurden nicht angefasst.
- Verifikation:
  - Namespace `infra-argocd`: absent.
  - Keine `argoproj.io` CRDs mehr im DMZ-Cluster sichtbar.
  - Alte ArgoCD RBAC-Rollen fuer Controller/Server/Notifications absent.
  - Neue IT15-ArgoCD Apps weiterhin erreichbar; PIDOKA Apps `Synced / Healthy`.
  - `platform-external-secrets` war weiterhin `Synced / Degraded` und ist als separater Befund zu pruefen, nicht Teil des alten ArgoCD-Cleanups.

## Cattaro Demo-RBAC bereinigt und DMZ-Clusterzugang korrigiert — 2026-06-18 20:28 UTC

- Ausgangspunkt:
  - Mislav war unsicher wegen der verbleibenden RBAC-Objekte und bat um Sicherung/Absicherung.
- Backup vor Aenderungen:
  - Pfad: `/home/node/.openclaw/workspace/backups/argocd-rbac-cleanup-20260618T201922Z`
  - Dateien:
    - `dmz/argocd-rbac-and-serviceaccounts.yaml`
    - `it15/argocd-cattaro-cluster-secret-and-project.yaml`
    - `SHA256SUMS`
  - Checksum-Verify danach erfolgreich.
- Erkenntnis:
  - `argocd-demo-manager-discovery` gehoerte zur alten Demo-Anbindung:
    - ServiceAccount `tenant-cattaro-stage/argocd-demo-manager`
  - `argocd-dmz-platform-manager` gehoert zur aktiven Plattform-Anbindung:
    - ServiceAccount `platform-infisical/argocd-dmz-manager`
  - `argocd-dmz-platform-manager` bleibt bestehen.
- Durchgefuehrter Cleanup:
  - IT15 Secret `argocd/dmz-k3s-tenant-cattaro-stage` zunaechst geloescht.
  - DMZ `ClusterRoleBinding/argocd-demo-manager-discovery` geloescht.
  - DMZ `ClusterRole/argocd-demo-manager-discovery` geloescht.
  - Namespace `tenant-cattaro-stage` geloescht.
- Korrektur:
  - Nach dem Loeschen des IT15 Cluster-Secrets wurden einige DMZ-Ziel-Apps `Unknown`.
  - Das zeigte, dass das Secret trotz altem Namen noch als DMZ-Clusterzugang gebraucht wurde.
  - Aus Backup wiederhergestellt und anschliessend sauber auf frischen Token fuer `platform-infisical/argocd-dmz-manager` umgestellt.
  - Secret-Annotation jetzt: `kube-bot.openclaw/cluster-wide-enabled-for: platform-and-pidoka-dmz`.
  - Token wurde nicht ausgegeben oder dokumentiert.
- Verifikation:
  - Namespace `tenant-cattaro-stage`: absent.
  - `argocd-demo-manager-discovery`: absent.
  - `argocd-dmz-platform-manager`: vorhanden.
  - IT15-ArgoCD Apps wieder:
    - PIDOKA Apps `Synced / Healthy`
    - `platform-infisical-dmz`: `Synced / Healthy`
    - `platform-external-secrets`: weiterhin `Synced / Degraded` (separater Befund).

## Read-only Statuscheck IT15-ArgoCD / DMZ — 2026-06-19 12:15 UTC

- Anlass: Nach Wiederaufnahme read-only geprüft, ob der offene Befund `platform-external-secrets` weiterhin besteht.
- IT15-ArgoCD Applications:
  - Alle PIDOKA Apps und Secrets-Apps: `Synced / Healthy`.
  - `platform-infisical-dmz`: `Synced / Healthy`.
  - `platform-external-secrets`: `Synced / Degraded`.
- DMZ-K3s:
  - Beide Nodes `Ready`.
  - External Secrets Operator Pods im Namespace `external-secrets`: alle `1/1 Running`, Restarts `0`.
  - ESO Deployments: `Available=True`.
  - CRDs `externalsecrets.external-secrets.io`, `secretstores.external-secrets.io`, `clustersecretstores.external-secrets.io`: `Established=True`, `NamesAccepted=True`.
  - Alle geprüften `SecretStore/dmz-infisical`: `Valid`, `Ready=True`.
  - Alle geprüften `ExternalSecret`: `SecretSynced`, `Ready=True`.
- Logs:
  - Keine funktionalen ESO-Fehler gefunden.
  - Cert-Controller aktualisiert regelmäßig Webhook-Konfigurationen/CA-Bundles; Werte wurden nicht dokumentiert.
- Bewertung:
  - Live-Funktion von ESO/Infisical-Secret-Sync ist aktuell grün.
  - Der ArgoCD-Health-Status `Degraded` wirkt eher wie ein Health-/Diff-Artefakt rund um chartverwaltete Webhook-Konfigurationen bzw. dynamische CA-Bundles, nicht wie ein akuter Ausfall.
- Empfehlung:
  - Nächster Schritt: gezielt ArgoCD `ignoreDifferences`/Health-Customization für die ESO Webhook `caBundle` prüfen und erst nach OK als GitOps-Änderung umsetzen.

## Recherche-Ergänzung ESO/ArgoCD Degraded — 2026-06-19 12:25 UTC

- Offizielle ESO-Dokumentation bestätigt:
  - ESO besteht aus Core Controller, Webhook und Cert Controller.
  - Der Cert Controller erzeugt TLS-Credentials und injiziert `caBundle` in CRDs und `ValidatingWebhookConfiguration`.
- Offizielle ArgoCD-Dokumentation bestätigt:
  - Controller oder mutating webhooks können Live-Objekte nach Apply verändern; dafür sind `ignoreDifferences` auf Application- oder Systemebene vorgesehen.
  - ArgoCD nennt `caBundle` in Webhook-Konfigurationen explizit als Beispiel für systemweite Diff-Customization.
  - Application Health wird aus den unmittelbaren Kind-Ressourcen abgeleitet; Custom Health Checks sind per Lua in `argocd-cm` möglich.
- Offizielle Kubernetes-Dokumentation bestätigt:
  - Admission Webhooks brauchen ein gültiges `caBundle`, damit der API Server dem Webhook-Zertifikat vertraut.
- Zusätzliche Beobachtung:
  - Installierte ESO-Version ist Helm Chart/Image `0.10.5`; aktuelle Upstream-Releases liegen deutlich höher. ESO-Support-Policy unterstützt jeweils nur die aktuelle Minor-Version.
- Bewertung:
  - `caBundle` darf nicht statisch aus Git erzwungen werden; es ist runtime-/controllerverwaltet.
  - Primärer Fix-Kandidat ist `ignoreDifferences` für `admissionregistration.k8s.io/ValidatingWebhookConfiguration` und ggf. ESO-CRD conversion webhook `caBundle`.
  - Health-Customization ist nur zweite Option, wenn nach sauberer Diff-Behandlung weiterhin ein falsches `Degraded` bleibt.
  - Größeres separates Thema: geplant getestetes ESO-Upgrade von `0.10.5` auf eine unterstützte aktuelle Version.

## ESO/ArgoCD Degraded Root Cause genauer — 2026-06-19 12:35 UTC

- GitOps-Fix umgesetzt und gepusht:
  - Repo: `GitMasterOne/platform-gitops`
  - Commit: `1311d7d Ignore ESO webhook CA bundle drift`
  - Inhalt: `ignoreDifferences` fuer Webhook-`caBundle` und CRD conversion webhook `caBundle`; `RespectIgnoreDifferences=true`.
- IT15-ArgoCD Application `platform-external-secrets` wurde mit der neuen Spec angewendet.
- Ergebnis:
  - App bleibt `Synced / Degraded`.
  - Hard refresh aendert Health nicht.
  - ESO live bleibt gesund: Deployments/Pods laufen, SecretStores valid, ExternalSecrets synced.
- Genauere ArgoCD Resource-Tree-Diagnose:
  - Degraded kommt von mehreren ESO Generator-CRDs:
    - `acraccesstokens.generators.external-secrets.io`
    - `ecrauthorizationtokens.generators.external-secrets.io`
    - `fakes.generators.external-secrets.io`
    - `gcraccesstokens.generators.external-secrets.io`
    - `githubaccesstokens.generators.external-secrets.io`
    - `passwords.generators.external-secrets.io`
    - `uuids.generators.external-secrets.io`
    - `vaultdynamicsecrets.generators.external-secrets.io`
  - Jeweilige Health-Meldung: `CRD names have not been accepted: "<shortname>" is already in use`.
  - Kubernetes CRD-Status: `Established=True`, aber `NamesAccepted=False` wegen `ShortNamesConflict`.
  - Es wurden keine Generator-Objekte im Cluster gefunden; GitOps nutzt aktuell keine ESO Generatoren.
- Bewertung aktualisiert:
  - Die erste `caBundle`-Hypothese war als Drift-Fix korrekt, aber nicht die Ursache des `Degraded`.
  - Der echte Health-Ausloeser sind ungenutzte Generator-CRDs aus ESO `0.10.5`.
  - Funktionale Infisical-Secret-Synchronisation ist nicht betroffen.
- Moegliche naechste Fix-Pfade:
  1. Sauber geplant: ESO-Upgrade auf aktuelle unterstuetzte Version vorbereiten und in Stage/mit Backup testen; dabei pruefen, ob Generator-CRD ShortName-Konflikte geloest sind.
  2. Kurzfristig kosmetisch: ArgoCD Health-Customization fuer genau diese ESO Generator-CRDs setzen, wenn `Established=True` und nur `ShortNamesConflict` vorliegt.
  3. Nicht bevorzugt ohne Plan: Generator-CRDs loeschen/deaktivieren, da das CRD-Management im Chart `0.10.5` grob und `installCRDs` global ist.

## ESO Upgrade Plan erstellt — 2026-06-19 12:45 UTC

- Mislav bevorzugt einen ESO-Upgrade-Plan statt kurzfristiger Health-Kosmetik.
- Plan erstellt: `/home/node/.openclaw/workspace/ESO_UPGRADE_PLAN_20260619.md`.
- Wichtige Erkenntnisse:
  - DMZ-K3s Server Version ist `v1.28.4+k3s2`.
  - ESO `0.10.5` ist EOL, passt aber noch zur alten Kubernetes-Version.
  - Aktuelle ESO-Linie ist `v2.6.0` / Helm Chart `2.6.0`, aber laut ESO-Supportmatrix fuer deutlich neuere Kubernetes-Versionen gedacht.
  - Alle aktuellen GitOps-ESO-Ressourcen sind `external-secrets.io/v1beta1`.
  - Alle Live-`SecretStore` und `ExternalSecret` sind `Ready=True`.
- Empfehlung:
  - Nicht direkt auf ESO 2.x springen.
  - Erst Phase 1: read-only Backup/Inventar aller ESO CRDs/CRs und ArgoCD-App.
  - Danach server-side dry-run fuer Migration `v1beta1` -> `v1`.
  - Danach K3s-Kompatibilitaets-/Upgrade-Entscheidung vor aktueller ESO-2.x-Linie.

## ArgoCD Adoption Inventur — 2026-06-19 12:55 UTC

- Mislav moechte ESO-Upgrade erstmal warten lassen; wichtiger ist, dass verbleibende Services im DMZ-Cluster vollstaendig nach IT15-ArgoCD/GitOps wandern.
- Read-only Inventur erstellt:
  - `/home/node/.openclaw/workspace/inventory/argocd-adoption-20260619.md`
- Bereits ueber IT15-ArgoCD gemanaged:
  - PIDOKA: `n8n`, `matomo`, `mautic`, `suitecrm`, `zammad` inkl. Secrets-Apps.
  - Plattform: `platform-infisical-dmz`, `platform-external-secrets`, `platform-argocd-projects`.
- Noch nicht sauber in IT15-ArgoCD:
  - `homarr`
  - `longhorn-system`
  - `sealed-secrets-controller`
  - diverse alte/local-path PVCs
- Bewertung:
  - Die zuletzt migrierten PIDOKA-Fachanwendungen sind nicht das Problem; sie sind ArgoCD-managed.
  - Offene Arbeit liegt vor allem bei alten Dashboard-/Admin-Tools, Plattform-Bausteinen und Cleanup-Kandidaten.
- Empfohlene Reihenfolge:
  1. Homarr Secret spaeter nach Infisical/ESO ueberfuehren.
  2. Longhorn separat planen.

## Homarr Einordnung — 2026-06-19 13:00 UTC

- Mislav bestaetigt: Homarr ist Dashboard fuer PIDOKA/HF Anwendungen.
- Bewertung korrigiert:
  - Homarr ist produktiver Service und kein Cleanup-Kandidat.
  - Homarr ist erster sinnvoller GitOps-Adoption-Kandidat unter den noch nicht ArgoCD-managed Dashboard/Admin-Tools.
- Read-only Details:
  - Namespace `homarr`, Deployment `my-homarr`, Pod `1/1 Running`, Restarts `0`.
  - Service `my-homarr` NodePort `30718`; passt zum dokumentierten NPM-Proxy `dashboard.heckenfels.com`.
  - Image gepinnt auf `ghcr.io/ajnart/homarr:0.14.2@sha256:3f2389f69db8b497c32c843d44f26afefb4e47b8e7954d0c43c372713d617ed7`.
  - Aktive Mounts:
    - `/app/data/configs` -> `my-homarr-config` Longhorn; enthaelt `default.json`, `Heckenfels.json`.
    - `/app/public/icons` -> `my-homarr-icons` Longhorn.
    - `/data` -> `my-homarr-data` local-path; enthaelt `db.sqlite`.
  - Weitere PVCs `my-homarr-data-new` und `my-homarr-data-mb` wirken wie alte Migrationsreste.
- Naechster sinnvoller Schritt:
  - Homarr GitOps-Adoption vorbereiten: bestehende Deployment/Service/PVC/Secret-Referenzen in Repo modellieren, ohne Secretwert offenzulegen; danach mit OK apply/adopt.

## Homarr Rename-Wunsch — 2026-06-19 13:05 UTC

- Mislav fragt, ob `my-homarr` direkt in `hf-homarr` umbenannt werden kann.
- Bewertung:
  - Fachlich ja, aber Kubernetes kann Deployment/Service nicht in-place umbenennen; es werden neue Ressourcen angelegt und alte spaeter entfernt.
  - Aktive PVCs sollten zunaechst nicht umbenannt/verschoben werden:
    - `my-homarr-config`
    - `my-homarr-icons`
    - `my-homarr-data`
  - Service-Name `hf-homarr` mit gleichem NodePort `30718` braucht kurzen kontrollierten Cutover, weil `my-homarr` den NodePort aktuell belegt.
- Sicherste Variante:
  - Neue ArgoCD App `pidoka-hf-homarr`.
  - Neues Deployment `hf-homarr`.
  - PVCs zunaechst weiterverwenden.
  - Secret zunaechst referenzieren oder spaeter via Infisical/ESO sauber nach `hf-homarr-secret` ueberfuehren.
  - Service entweder kontrolliert auf `hf-homarr` cutovern oder `my-homarr` vorerst als Kompatibilitaetsanker behalten.

## Homarr GitOps-Adoption abgeschlossen — 2026-06-19 12:50 UTC

- Mislav entschied: Umbenennung erstmal lassen; Adoption mit bestehenden Ressourcennamen durchfuehren.
- GitOps:
  - Repo: `GitMasterOne/platform-gitops`
  - Commit: `59281b7 Adopt Homarr into Pidoka GitOps`
  - Neue ArgoCD Application: `pidoka-hf-homarr`
  - Neuer GitOps-Pfad: `tenants/pidoka/prod/homarr`
  - AppProject `tenant-pidoka` um Namespace `homarr` erweitert.
- Bewusst beibehalten:
  - Deployment/Service Name: `my-homarr`
  - NodePort: `30718`
  - Aktive PVCs:
    - `my-homarr-config`
    - `my-homarr-icons`
    - `my-homarr-data`
  - Bestehendes Secret `my-homarr-homarr-secrets` wird referenziert, aber nicht mit Secretwert ins Repo uebernommen.
- ArgoCD-Verifikation:
  - `platform-argocd-projects`: `Synced / Healthy`, Revision `59281b7`.
  - `pidoka-hf-homarr`: `Synced / Healthy`, Revision `59281b7`.
  - ArgoCD tracking IDs gesetzt fuer:
    - `Deployment/my-homarr`
    - `Service/my-homarr`
    - `PersistentVolumeClaim/my-homarr-config`
    - `PersistentVolumeClaim/my-homarr-icons`
    - `PersistentVolumeClaim/my-homarr-data`
- Live-Verifikation:
  - Pod `my-homarr-698bc75847-nsfph`: `1/1 Running`, Restarts `0`.
  - `https://dashboard.heckenfels.com/` liefert HTTP `307` nach `/board`.
- Weiter offen:
  - Homarr Secret spaeter nach Infisical/ESO ueberfuehren.
  - Alte Homarr PVCs `my-homarr-data-new`, `my-homarr-data-mb` und alte Migration-Jobs nur nach Daten-/Backup-Check und separatem OK bereinigen.

## Homarr Secret/PVC Cleanup — 2026-06-19 13:05 UTC

- Frage von Mislav: Wofuer wird `my-homarr-homarr-secrets` benoetigt?
- Antwort:
  - Es enthaelt `NEXTAUTH_SECRET`.
  - Homarr nutzt diesen Wert fuer NextAuth-/Session-Signatur.
  - Der Wert wurde nicht ausgegeben.
  - Spaeter sinnvoll: Secret nach Infisical/ESO ueberfuehren.
- Alte PVCs geprueft:
  - `my-homarr-data-new` Longhorn 100Gi.
  - `my-homarr-data-mb` Longhorn 10Gi.
  - Beide waren nicht von Homarr gemountet.
  - Beide enthielten nur `db.sqlite` plus `lost+found`.
  - Beide alten DB-Kopien hatten dieselbe Checksum und unterschieden sich von der aktiven `/data/db.sqlite`.
- Cleanup durchgefuehrt:
  - PVCs `my-homarr-data-new` und `my-homarr-data-mb` geloescht.
  - Zugehoerige PVs/Longhorn-Volumes sind danach nicht mehr sichtbar.
- Verifikation:
  - Homarr aktive PVCs bleiben:
    - `my-homarr-data`
    - `my-homarr-icons`
    - `my-homarr-config`
  - Pod `my-homarr-698bc75847-nsfph`: `1/1 Running`, Restarts `0`.
  - `pidoka-hf-homarr`: `Synced / Healthy`.
  - `https://dashboard.heckenfels.com/`: HTTP `307` nach `/board`.
- Weiterer Cleanup nach OK von Mislav:
  - Alte Homarr Migration-Jobs `volume-migration*` geloescht.
  - Altes Helm Release Secret `sh.helm.release.v1.my-homarr.v1` geloescht.
  - Aktives Kubernetes Secret `my-homarr-homarr-secrets` bleibt bestehen, weil Homarr daraus `NEXTAUTH_SECRET` nutzt.
- Abschluss-Verifikation:
  - `secret/my-homarr-homarr-secrets` bleibt vorhanden.
  - Aktive PVCs `my-homarr-data`, `my-homarr-icons`, `my-homarr-config` bleiben vorhanden.
  - Pod/Deployment/Service laufen weiter.
  - `pidoka-hf-homarr`: `Synced / Healthy`.
  - `https://dashboard.heckenfels.com/`: HTTP `307` nach `/board`.
- Offen:
  - Homarr Secret spaeter nach Infisical/ESO ueberfuehren.

## Dashy Cleanup abgeschlossen — 2026-06-19 13:18 UTC

- Mislav bestaetigte: Dashy wird nicht mehr benoetigt und kann komplett entfernt werden.
- Vor Cleanup gefunden:
  - Namespace `dashy`.
  - Deployment/Pod `my-dashy`, Image `lissy93/dashy:2.1.1`.
  - Service `my-dashy` NodePort `32399`.
  - PVC `my-dashy-icons` mit PV `pvc-343a1a01-c7ac-4150-9401-fc497826be6e`.
  - Helm Release Secret `sh.helm.release.v1.my-dashy.v1`.
  - Kein ArgoCD-Bestand und kein Ingress gefunden.
- Cleanup durchgefuehrt:
  - Namespace `dashy` geloescht.
- Verifikation:
  - Namespace `dashy` nicht mehr vorhanden.
  - Dashy Ressourcen nicht mehr abrufbar.
  - PV `pvc-343a1a01-c7ac-4150-9401-fc497826be6e` nicht mehr sichtbar.
  - Nginx Proxy Manager hat keinen Proxy-Host mit `dashy` und keinen Forward auf Port `32399`.
- Schlussfolgerung:
  - Dashy ist als altes Dashboard entfernt; Homarr bleibt das produktive PIDOKA/HF Dashboard und ist ArgoCD-managed.

## Portainer Cleanup abgeschlossen — 2026-06-19 19:08 UTC

- Mislav bestaetigte: Portainer ist alt und kann weg.
- Vor Cleanup im DMZ-K3s gefunden:
  - Namespace `portainer`.
  - Deployments/Pods `portainer` und `portainer-agent`.
  - LoadBalancer Services `portainer` und `portainer-agent`.
  - PVC `portainer` mit PV `pvc-cd93bea7-94f0-490c-969d-5125ac827f4b`.
  - Helm Release Secrets `sh.helm.release.v1.portainer.v1` und `sh.helm.release.v1.portainer.v2`.
- Cleanup durchgefuehrt:
  - Namespace `portainer` geloescht.
- Verifikation:
  - Namespace `portainer` nicht mehr vorhanden.
  - Portainer Kubernetes Services nicht mehr sichtbar.
  - PV `pvc-cd93bea7-94f0-490c-969d-5125ac827f4b` nicht mehr sichtbar.
  - Nginx Proxy Manager hat keinen Proxy-Host mit `portainer` und keinen Forward auf die alten Cluster-Portainer-Ports.
- Hinweis:
  - Auf dem Nginx-Proxy-Host `192.168.20.20` laeuft separat noch Docker-Portainer (`portainer/portainer-ce:latest`) plus Portainer-Agent. Dieser wurde nur erkannt, aber nicht veraendert.
- Naechster sinnvoller Kandidat:
  - `keycloak`, je nach Bedarf/Nutzung und Datenbestand.

## Backup-Konzept Ergaenzung — dmz-backup — 2026-06-19 19:26 UTC

- Mislav ergaenzte neues Backup-Zielbild:
  - Hilfs-Backup-Server in der DMZ: `dmz-backup`
  - IP: `192.168.20.90`
  - K3s/DMZ-Cluster pusht Backup-Dateien nach `dmz-backup`.
  - Synology/DiskStation pullt von `dmz-backup` und bleibt Backup-Master.
- Bewertung:
  - Das passt zur DMZ-Trennung besser als direkte Schreibrechte aus dem Cluster auf Synology.
  - `dmz-backup` ist Staging/Puffer, nicht alleinige Langzeit-Backup-Quelle.
- Konzept aktualisiert:
  - `/home/node/.openclaw/workspace/INFISICAL_ARGO_K3S_KONZEPT.md`
  - `/home/node/.openclaw/workspace/inventory/backup-strategy-draft.md`
  - `/home/node/.openclaw/workspace/INFRASTRUCTURE.md`
- Ordnerstruktur-Entwurf fuer diskstation-bot erstellt:
  - `/home/node/.openclaw/workspace/inventory/backup-folder-structure-dmz-backup-20260619.md`
- Empfehlung fuer diskstation-bot:
  - Struktur nach `platform`, `tenants`, `legacy` uebernehmen.
  - Darunter nach Environment, App und Backup-Art gliedern.
  - Kubernetes Namespace als Metadatum fuehren, nicht als alleinige Ordnergrenze.
  - Staging-Root auf `dmz-backup`: `/srv/dmz-backup/k3s-dmz/`.
- Offene Punkte:
  - Synology Share-Name, Pull-Protokoll, Retention, Quotas, Verschluesselung und erster Restore-Test muessen mit `diskstation-bot` finalisiert werden.

## Bitwarden + Kubernetes Dashboard Cleanup abgeschlossen — 2026-06-19 20:01 UTC

- Mislav gab OK: beide koennen weg.
- `bitwarden` vor Cleanup:
  - Namespace `bitwarden`.
  - Keine Workloads, Services, PVCs oder eigenen Secrets; nur `kube-root-ca.crt`.
- `kubernetes-dashboard` vor Cleanup:
  - Namespace `kubernetes-dashboard`.
  - Deployments/Pods `kubernetes-dashboard` und `dashboard-metrics-scraper`.
  - Service `kubernetes-dashboard` NodePort `31351`.
  - Dashboard ConfigMaps/Secrets.
  - Keine PVCs.
- Cleanup durchgefuehrt:
  - Namespaces `bitwarden` und `kubernetes-dashboard` geloescht.
- Verifikation:
  - Beide Namespaces nicht mehr vorhanden.
  - Keine Ressourcen in beiden Namespaces mehr abrufbar.
  - Nginx Proxy Manager hat keinen Proxy-Host mit `dashboard`/`bitwarden` und keinen Forward auf Port `31351`.
- Naechster sinnvoller Kandidat:
  - `keycloak` nur nach Bedarfsklaerung und Datenentscheidung.

## Keycloak Namespace Cleanup abgeschlossen — 2026-06-19 20:04 UTC

- Mislav bestaetigte: Keycloak war nur Test und kann weg.
- Vor Cleanup im Namespace `keycloak` gefunden:
  - StatefulSets/Pods `keycloak` und `keycloak-postgresql`.
  - LoadBalancer Service `keycloak` mit NodePort `32184`.
  - PVC `data-keycloak-postgresql-0` mit PV `pvc-31e58295-bbc8-4db6-8045-14a9875ac012`.
  - Helm Release Secret `sh.helm.release.v1.keycloak.v1`.
- Cleanup durchgefuehrt:
  - Namespace `keycloak` geloescht.
- Verifikation:
  - Namespace `keycloak` nicht mehr vorhanden.
  - Keycloak Services im Namespace nicht mehr sichtbar.
  - PV `pvc-31e58295-bbc8-4db6-8045-14a9875ac012` nicht mehr sichtbar.
  - Nginx Proxy Manager hat keinen Proxy-Host mit `keycloak`.
## Default my-release Keycloak Cleanup abgeschlossen — 2026-06-19 20:07 UTC

- Mislav bestaetigte: separater alter Keycloak-Teststack `my-release` kann auch weg.
- Vor Cleanup im Namespace `default` gefunden:
  - StatefulSets/Pods `my-release-keycloak` und `my-release-postgresql`.
  - Services `my-release-keycloak`, `my-release-keycloak-headless`, `my-release-postgresql`, `my-release-postgresql-hl`.
  - PVC `data-my-release-postgresql-0` mit PV `pvc-c6424e75-9924-42d0-87fb-8596eb7eb069`.
  - ConfigMap `my-release-keycloak-env-vars`.
  - Secrets `my-release-keycloak`, `my-release-postgresql`, `sh.helm.release.v1.my-release.v1`.
- Cleanup durchgefuehrt:
  - Alle Ressourcen mit Label `app.kubernetes.io/instance=my-release` im Namespace `default` geloescht.
  - Helm Release Secret `sh.helm.release.v1.my-release.v1` separat geloescht.
- Verifikation:
  - Keine Ressourcen mit Label `app.kubernetes.io/instance=my-release` mehr sichtbar.
  - PV `pvc-c6424e75-9924-42d0-87fb-8596eb7eb069` nicht mehr sichtbar.
  - Keine `my-release`-/Keycloak-Services mehr sichtbar.
  - Uebrig sichtbare PostgreSQL-Services gehoeren zu `zammad` und `platform-infisical`.
## hf-matomo Rollback-Bestand Cleanup abgeschlossen — 2026-06-19 20:13 UTC

- Mislav bestaetigte: alter Rollback-Pfad wird nicht mehr benoetigt.
- Einordnung:
  - `hf-matomo` war die alte Produktion und kurzfristiger Rollback-Bestand nach Cutover auf `pidoka-hf-matomo`.
  - Sicherheitskopien liegen weiter auf der Control-Plane:
    - `/home/kube-bot/backups/matomo-20260617T060849Z/`
    - `/home/kube-bot/backups/matomo-cutover-20260617T135148Z/`
- Vor Cleanup gefunden:
  - Namespace `hf-matomo`.
  - Deployment `matomo` skaliert auf `0/0`.
  - Deployment/Pod `matomo-db` laufend `1/1`.
  - Services `matomo`, `matomo-db`.
  - PVCs `matomo-pvc`, `matomo-db-pvc`.
- Cleanup durchgefuehrt:
  - Namespace `hf-matomo` geloescht.
  - Released PVs `pvc-f6714be0-39b1-47e6-baa2-2e1ae801d907` und `pvc-61155551-a7de-4c0c-b558-f86437232148` geloescht.
  - Uebrig gebliebene Longhorn Volume-CRs fuer diese beiden PVs geloescht.
- Verifikation:
  - Namespace `hf-matomo` nicht mehr vorhanden.
  - Alte PVs und Longhorn-Volumes nicht mehr sichtbar.
  - Neuer Stack `pidoka-hf-matomo` laeuft weiter:
    - Pod `matomo`: `1/1 Running`, Restarts `0`.
    - Pod `matomo-db`: `1/1 Running`, Restarts `0`.
    - PVCs `matomo-pvc`, `matomo-db-pvc` gebunden.
    - Ingress `matomo.heckenfels.com` vorhanden.
  - `https://matomo.heckenfels.com/` antwortet HTTP `200`.
- Naechster sinnvoller Kandidat:
  - Longhorn/Storage separat planen; nicht als spontaner Cleanup.

## Nginx Proxy Manager Abgleich — 2026-06-19 20:20 UTC

- Nach den Cleanups wurde Nginx Proxy Manager auf `192.168.20.20` read-only gegen aktuelle K3s Ingresses/Services abgeglichen.
- Detailbericht:
  - `/home/node/.openclaw/workspace/inventory/nginx-proxy-abgleich-20260619.md`
- Aktuelle K3s Ingress Hosts:
  - `n8n.heckenfels.com`
  - `matomo.heckenfels.com`
  - `mautic.heckenfels.com`
  - `suitecrm.heckenfels.com`
- OK/behalten:
  - `nextcloud.cattaro.eu`
  - `service.heckenfels.com` -> Zammad, HTTP `200`
  - `dashboard.heckenfels.com` -> Homarr, HTTP `307`
  - `matomo.heckenfels.com` -> neuer `pidoka-hf-matomo` Stack, HTTP `200`
  - `mautic.heckenfels.com` -> aktueller Ingress, HTTP `302`
  - `suitecrm.heckenfels.com` -> aktueller Ingress, HTTP `200`
  - `n8n.heckenfels.com` -> aktueller Ingress, HTTP `200`
- NPM-Cleanup-Kandidaten nach OK:
  - `bitwarden.cattaro.eu`: Port `192.168.20.20:8080` geschlossen, Domain `502`.
  - `crm.heckenfels.com`: kein aktueller Ingress, Traefik `404`, wirkt wie alter EspoCRM-Pfad.
  - `argocd.cattaro.eu`: kein aktueller Ingress, Traefik `404`, altes DMZ-ArgoCD ist nicht mehr Zielmodell.
- Nur nach fachlicher Klaerung:
  - `office.cattaro.eu`: Nicht-K3s Ziel `192.168.188.40:80`, aktuell vom Proxy aus nicht erreichbar.
  - `meshcentral.cattaro.eu`: Nicht-K3s Ziel `192.168.188.42:2087`, aktuell vom Proxy aus nicht erreichbar.
- Es wurden keine NPM-Aenderungen vorgenommen.

## Nginx Proxy Manager Cleanup — 2026-06-19 21:41 UTC

- Mislav gab OK: klare NPM-Cleanup-Kandidaten koennen raus.
- Backup vor Aenderung auf dem Proxy-Host:
  - `/data/compose/2/data/backups/kube-bot-npm-cleanup-20260619T214028Z`
- Entfernt aus Nginx Proxy Manager:
  - ID `6`: `bitwarden.cattaro.eu`
  - ID `8`: `argocd.cattaro.eu`
  - ID `10`: `crm.heckenfels.com`
- Durchgefuehrt:
  - NPM SQLite-Datenbank gesichert.
  - Proxy-Host-Eintraege aus `proxy_host` geloescht.
  - Generierte Config-Dateien `6.conf`, `8.conf`, `10.conf` entfernt.
  - `nginx -t` erfolgreich.
  - Nginx reload ausgefuehrt.
- Verifikation:
  - Entfernte Domains liefern nicht mehr via NPM:
    - `bitwarden.cattaro.eu`: HTTP `000`
    - `crm.heckenfels.com`: HTTP `000`
    - `argocd.cattaro.eu`: HTTP `000`
  - Produktive Domains bleiben erreichbar:
    - `service.heckenfels.com`: HTTP `200`
    - `dashboard.heckenfels.com`: HTTP `307`
    - `matomo.heckenfels.com`: HTTP `200`
    - `mautic.heckenfels.com`: HTTP `302`
    - `suitecrm.heckenfels.com`: HTTP `200`
    - `n8n.heckenfels.com`: HTTP `200`
- Aktive Proxy-Host-IDs danach:
  - `1`, `2`, `3`, `4`, `5`, `7`, `9`, `11`, `12`

## Nginx Proxy Manager Meshcentral Cleanup — 2026-06-19 21:43 UTC

- Mislav gab OK: `meshcentral.cattaro.eu` kann ebenfalls raus.
- `office.cattaro.eu` bleibt vorerst bestehen, weil es ggf. fuer Nextcloud notwendig sein kann.
- Backup vor Aenderung auf dem Proxy-Host:
  - `/data/compose/2/data/backups/kube-bot-npm-meshcentral-cleanup-20260619T214253Z`
- Entfernt aus Nginx Proxy Manager:
  - ID `4`: `meshcentral.cattaro.eu`
- Durchgefuehrt:
  - NPM SQLite-Datenbank gesichert.
  - Proxy-Host-Eintrag aus `proxy_host` geloescht.
  - Generierte Config-Datei `4.conf` entfernt.
  - `nginx -t` erfolgreich.
  - Nginx reload ausgefuehrt.
- Verifikation:
  - `meshcentral.cattaro.eu`: HTTP `000`
  - `office.cattaro.eu`: bleibt als ID `3` erhalten, aktuell HTTP `000`
  - Produktive Domains bleiben erreichbar:
    - `nextcloud.cattaro.eu`: HTTP `302`
    - `service.heckenfels.com`: HTTP `200`
    - `dashboard.heckenfels.com`: HTTP `307`
    - `matomo.heckenfels.com`: HTTP `200`
    - `mautic.heckenfels.com`: HTTP `302`
    - `suitecrm.heckenfels.com`: HTTP `200`
    - `n8n.heckenfels.com`: HTTP `200`
- Aktive Proxy-Host-IDs danach:
  - `1`, `2`, `3`, `5`, `7`, `9`, `11`, `12`

## Homarr Backup Pilot Lauf — 2026-06-20 10:41 UTC

- Mislav gab Freigabe: "bitte backup von homarr durchführen".
- Kube-bot hat nur den engen Pilot-Scope ausgeführt:
  - read-only Export aus DMZ-K3s über `kube-bot@192.168.20.40`
  - keine Cluster-Änderung
  - keine PVC-Dateidaten
  - keine Longhorn-Snapshots oder Longhorn-Backups
  - keine Secretwerte
- Frisches lokales Artefakt:
  - Arbeitsverzeichnis: `/home/node/.openclaw/workspace/backups/homarr-pilot-20260620T104142Z`
  - Archiv: `/home/node/.openclaw/workspace/backups/20260620T104142Z__dmz-k3s__pidoka__homarr__metadata__pilot.tar.gz`
  - SHA256: `64802165be001fd7c5dab1a59bf0f97934ce47aa31863fcf0c622d0bfa66db87`
- Inhalt:
  - Homarr Workload-/PVC-/Event-/Node-/StorageClass-Status
  - Kubernetes-Manifeste ohne Secret-Objekte
  - Secret-Referenz nur als `my-homarr-homarr-secrets` / `Opaque` / `NEXTAUTH_SECRET`
  - PVC/PV-Metadaten
  - Longhorn-Volume-Metadaten für die Longhorn-PVCs
- Hinweise:
  - Namespace `homarr` hatte aktuell keine Events.
  - `my-homarr-data` ist `local-path`; dafür gibt es erwartbar kein Longhorn-Volume.
- Historischer Haltepunkt 10:41 UTC: kein Push nach `dmz-backup`, weil damals noch kein `BACKUP_HOMARR_AGE_RECIPIENT` und kein nutzbares `age`-Tool verifiziert waren.
- Dieser Haltepunkt ist durch den späteren Abschnitt `Homarr Backup Pilot verschlüsselt gepusht — 2026-06-20 17:55 UTC` überholt.
- Diskstation-bot hat die `dmz-backup`-Seite vorbereitet:
  - Zielpfad: `/srv/dmz-backup/k3s-dmz/tenants/pidoka/prod/homarr`
  - Owner: `openclaw:openclaw`
  - Rechte: `750`
  - Schreibtest erfolgreich
  - kein MinIO/S3 installiert, keine Dienste geändert
- Beide Bots hatten zu diesem Zeitpunkt korrekt gestoppt, weil `age`/`rage` noch nicht verifiziert und kein `BACKUP_HOMARR_AGE_RECIPIENT` oder gleichwertiger Verschlüsselungs-Key in Infisical bestätigt war.
- Merker von Mislav 2026-06-20 11:32 UTC: Stand behalten; später durch die `age`-Verifikation und den verschlüsselten Push erledigt.

## Homarr Backup Pilot verschlüsselt gepusht — 2026-06-20 17:55 UTC

- Mislav meldete: `age` v1.3.1 ist in beiden Bot-Runtimes unter `/home/node/shared/tools/age` verfügbar; `age-keygen` ebenfalls.
- Kube-bot hat daraufhin:
  - Age-Keypair für Homarr Phase 1 erzeugt.
  - In Infisical `Backup_Restore/prod` abgelegt:
    - `BACKUP_HOMARR_AGE_RECIPIENT`
    - `BACKUP_HOMARR_AGE_PRIVATE_KEY`
    - `BACKUP_HOMARR_ENCRYPTION_TOOL=age-v1.3.1`
  - Keine Keywerte ausgegeben.
- Verschlüsseltes lokales Artefakt:
  - `/home/node/.openclaw/workspace/backups/20260620T104142Z__dmz-k3s__pidoka__homarr__metadata__pilot.tar.gz.age`
  - SHA256 verschlüsselt: `b90154a732f756a10de218f30d28fa9afd8bd15644781aa207011188ca4a5f19`
  - Lokaler Decrypt-Test mit Infisical-Age-Key gegen Original-SHA erfolgreich.
- Push nach `dmz-backup`:
  - Ziel: `/srv/dmz-backup/k3s-dmz/tenants/pidoka/prod/homarr/20260620T104142Z__dmz-k3s__pidoka__homarr__metadata__pilot.tar.gz.age`
  - `.sha256` daneben übertragen.
  - Remote `sha256sum -c` erfolgreich.
- Weiterhin nicht enthalten:
  - keine Secretwerte im Homarr-Artefakt
  - keine PVC-Dateidaten
  - keine Longhorn-Snapshots/Backups
  - keine Cluster-Änderung
- Hinweis: Ein erster Age-Private-Key-Store-Versuch hatte ein ungeeignetes Format; kube-bot hat das Keypair sofort neu erzeugt, korrekt als Single-Line Age Identity in Infisical ersetzt und das Artefakt neu verschlüsselt/gepusht. Maßgeblich ist der oben genannte verschlüsselte SHA256.
- Synology-Pull-Status 2026-06-20 18:02 UTC:
  - Diskstation-bot verifizierte das `.age`-Artefakt auf `dmz-backup` erneut: Datei vorhanden, SHA256 `b90154a732f756a10de218f30d28fa9afd8bd15644781aa207011188ca4a5f19`, Größe `10694` Bytes, Owner `openclaw:openclaw`, Mode `644`.
  - Mislav gab Go fuer den Synology-Zielshare `Backup_K3S_DMZ`.
  - Diskstation-bot konnte DSM Login und vorhandene Shares pruefen, aber `SYNO.Core.Share create` liefert `403`.
  - SSH zur Synology als `diskstation-bot@192.168.1.40` scheitert mit `Permission denied`.
  - Ergebnis: kein Upload auf Synology erfolgt; Synology-Pull bleibt blockiert, bis der Share `Backup_K3S_DMZ` manuell angelegt oder diskstation-bot mit passenden DSM-/SSH-Rechten ausgestattet ist.
  - Kube-bot-Seite bleibt abgeschlossen: verschluesselter Push auf `dmz-backup` verifiziert, keine Cluster-Aenderung, kein Restore, keine Entschluesselung auf `dmz-backup` oder Synology.
- Pause durch Mislav 2026-06-20 18:23 UTC:
  - Mislav pausiert fuer ca. drei Stunden.
  - Keine weiteren Schritte ohne neue Freigabe/Resume.
  - Resume-Punkt: diskstation-bot muss Synology-Zugriff reparieren oder Share `Backup_K3S_DMZ` manuell erhalten; kube-bot muss erst wieder eingreifen, wenn ein Readback-/Checksum-/Restore-Staging-Check aus K3s-Sicht angefordert wird.

## Infisical-Architektur geklärt + /platform/infisical bereinigt — 2026-06-21 22:15 UTC

### Drei Infisical-Instanzen — verifiziertes Gesamtbild

1. **BotOps-Platform Infisical** — `ki-node` (`192.168.1.50`)
   - Zweck: Bot-Runtime-Management, plattformübergreifend
   - Projekte:
     - `bot-platform` — injizierte Runtime-Secrets für alle Bots (read-only, nicht änderbar)
     - `hob_cattaro` — Pfad `/kube-bot` — kube-bot hat Lese- und Schreibrechte
   - Enthält: Credentials für IT15-Infisical (Cattaro Intranet)
   - Status 2026-06-21: `HOB_CATTARO_*` Variablen noch NICHT injiziert; Neustart mit Variablen-Injektion steht bevor

2. **IT15-Infisical** — `192.168.1.121:8088` — Cattaro GmbH / Intranet
   - Zugehörigkeit: Cattaro GmbH
   - Zweck: Platform-Kubernetes-Secrets, SSH-Keys, GitOps-Credentials, Backup/Restore-Secrets
   - Credentials dafür: in BotOps `hob_cattaro/kube-bot`
   - Zugriff kube-bot: via Runtime-Variablen `INFISICAL_CLIENT_ID` / `INFISICAL_AUTH_KEY` (aus `bot-platform`)

3. **DMZ-Infisical** — cluster-intern `platform-infisical` Namespace — Cattaro GmbH / K3s DMZ
   - Zweck: Laufzeit-Secret-Store für K3s-Workloads (ESO/ExternalSecrets)
   - ClusterIP: `10.43.154.215:8080`
   - Kein Ingress, kein Public Exposure
   - Credentials dafür: in IT15-Infisical `/platform/infisical` (nach Bereinigung)

### /platform/infisical in IT15-Infisical bereinigt — 2026-06-21

- Alte leere `CATTARO_DMZ_INFISICAL_*` Secrets (4 Stück) gelöscht
- Neue saubere Secrets angelegt mit korrekten Werten:
  - `DMZ_INFISICAL_URL` ✓
  - `DMZ_INFISICAL_CLIENT_ID` ✓
  - `DMZ_INFISICAL_CLIENT_SECRET` ✓
  - `DMZ_INFISICAL_PROJECT_ID` ✓ (`d66f3d3b-1484-46f6-8142-f6fc32222b4d`)
- Alte Dopplung in `/platform/kube-bot` noch vorhanden — Cleanup nach Neustart/Klärung

### Offene Punkte nach Neustart

1. Prüfen ob `HOB_CATTARO_*` Variablen korrekt injiziert wurden
2. BotOps `hob_cattaro/kube-bot` Struktur auslesen und dokumentieren
3. `/platform/kube-bot` in IT15-Infisical aufräumen (Dopplung zu `/platform/infisical`)
4. INFRASTRUCTURE.md mit 3-Instanzen-Bild aktualisieren

### Wichtige Architektur-Regel (neu dokumentiert)

- IT15-Infisical-Credentials gehören NICHT in IT15-Infisical selbst (Safe-im-Safe Problem)
- IT15-Infisical-Credentials liegen in BotOps `hob_cattaro/kube-bot`
- DMZ-Infisical-Credentials liegen in IT15-Infisical `/platform/infisical`
- Platform = K3s-Cluster-Platform (nicht IT15/Intranet)

## /platform/kube-bot Cleanup abgeschlossen — 2026-06-21 22:30 UTC

- Alle 3 alten DMZ-Infisical-Secrets aus `/platform/kube-bot` gelöscht:
  - `DMZ_INFISICAL_KUBE_BOT_CLIENT_ID`
  - `DMZ_INFISICAL_KUBE_BOT_CLIENT_SECRET`
  - `DMZ_INFISICAL_URL`
- Kanonischer Pfad ist jetzt `/platform/infisical` mit sauberen `DMZ_INFISICAL_*` Namen
- Ordner `/platform/kube-bot` ist leer (kann manuell in Infisical UI entfernt werden)
- BotOps-Infisical (`ki-node 192.168.1.50`) erfolgreich eingebunden:
  - `HOB_CATTARO_*` Variablen injiziert
  - Login verifiziert
  - `hob_cattaro/kube-bot` enthält 4 Secrets für IT15-Infisical Zugriff

## Tagesabschluss 2026-06-21 23:29 UTC

### Was heute erledigt wurde

- Drei-Infisical-Architektur vollständig geklärt und dokumentiert
- `/platform/infisical` in IT15-Infisical bereinigt (CATTARO_* -> DMZ_* Namen)
- `/platform/kube-bot` Dopplung aufgelöst und geleert
- BotOps-Infisical (`ki-node 192.168.1.50`) erfolgreich eingebunden (`HOB_CATTARO_*`)
- IT15 SSH-Zugang `Misla@192.168.1.121` repariert und gesichert
- Windows authorized_keys Berechtigungen wiederhergestellt
- WSL-Kommandomuster korrigiert: `wsl -d Ubuntu bash -c "..."`
- Zammad vollständig in IT15-ArgoCD adoptiert (`Synced / Healthy`, Tracking-Annotation gesetzt)
- Alle DMZ-Workloads sind jetzt ArgoCD-managed — keine ungemanagte Workloads mehr

### Morgen: Backup & Restore professionalisieren

- Zusammen mit `diskstation-bot` im Channel `#it-service`
- Aktueller Stand: nur PoC (Homarr Pilot, age-verschlüsselt auf dmz-backup, Synology-Pull verifiziert)
- Ziel: produktionsreife Backup/Restore-Strecke für alle Apps
- Wichtige Dokumente:
  - `/home/node/.openclaw/workspace/inventory/backup-strategy-draft.md`
  - `/home/node/.openclaw/workspace/inventory/backup-folder-structure-dmz-backup-20260619.md`
  - `INFRASTRUCTURE.md` Abschnitt Backup-Systeme

### Aktueller Cluster-Gesamtzustand

- Alle IT15-ArgoCD Apps: `Synced / Healthy` (außer `platform-external-secrets` → `Degraded` wegen ESO ShortName-Konflikt, bekannt)
- Alle DMZ-Workloads: Running, 0 Restarts
- SSH-Zugänge: DMZ Control-Plane ✓, DMZ Worker ✓, Nginx/Raspi ✓, IT15 ✓

## Homarr Backup & Restore E2E verifiziert — 2026-06-22

### Was erledigt wurde

- `my-homarr-data` von local-path (100Gi) auf Longhorn (500Mi) migriert — alle 3 Homarr-Volumes jetzt Longhorn
- GitOps-Commits: `de83d25` (neue PVC), `1638a45` (nodeSelector Control-Plane)
- Erstes echtes Backup erstellt (Timestamp `20260622T083928Z`):
  - `metadata`-Artefakt: K8s-Manifeste, PVC/Longhorn-Metadaten, Secret-Referenzen
  - `data`-Artefakt: db.sqlite (72KB), Config-Dateien, Icons
  - Age-verschlüsselt, SHA256-verifiziert
- Push auf `dmz-backup`: `/srv/dmz-backup/k3s-dmz/tenants/pidoka/prod/homarr/20260622T083928Z/` ✅
- diskstation-bot Pull auf DiskStation: `/volume1/KI_Agenten/backups/k3s-dmz/tenants/pidoka/prod/homarr/20260622T083928Z/` ✅
- Restore-Test E2E:
  - Staging-Pfad von diskstation-bot befüllt, SHA256 grün
  - kube-bot: decrypt, db.sqlite in isolierten Namespace `homarr-restore-test` restored
  - SHA256-Vergleich Original ↔ Restored: identisch ✅
  - Test-Namespace danach gelöscht, Temp-Dateien bereinigt

### Offene Punkte
- Alte local-path PVC `my-homarr-data` (100Gi) noch vorhanden — erst nach weiterer Beobachtungsphase löschen
- Nächste App: Matomo (warte auf Freigabe von Mislav)

## Offene Backlog-Punkte (2026-06-22)

- Dediziertes Backup-Image (`kube-bot-backup-tools`) mit `mariadb-dump` + `age` + Checksums — für später, wenn Docker-Registry-Setup passt
- `mariadb-dump` Binary-Name in allen DB-Dump-Skripten dokumentieren (kein `mysqldump` in MariaDB 11+)