homelab-infra/docs/EXTERNAL_DEPENDENCIES.md

# External Dependencies - KalliLab CORE

Status: Betreiber-Baseline 2026-06-01; Account-Recovery, Schluessel und Besitznachweise bleiben ausserhalb des Repos.

## Zweck

Dieses Dokument beschreibt externe Anbieter und Konten, von denen Betrieb, Recovery oder Zugriff abhaengen. Ziel ist, im Ausfallfall nicht erst suchen zu muessen, welcher Provider welches Teilproblem verursacht.

## Abhaengigkeiten

| Anbieter / System | Zweck | Kritikalitaet | Recovery-Auswirkung | Zugang / Besitz | Notfallplan |
|---|---|---:|---|---|---|
| Telekom DSL | Internet-Uplink | hoch | Public Apps, ACME, DDNS, Hetzner-Off-site und Tailscale-Initial-Verbindung fallen aus | Telekom-Kundenkonto | Kein WAN-Failover am Standort eingerichtet (FRITZ!Box-Ausfallschutz inaktiv); lokale LAN-Dienste laufen weiter; Hotspot-Behelf nur fuer Operator-Arbeit, nicht fuer Public Apps |
| FRITZ!Box 7590 | Router, DHCP, Telefonie, WAN | hoch | LAN ohne DHCP/Routing; auch lokale Inter-Subnet-Kommunikation kann brechen | Operator-Login auf `192.168.178.1` | FRITZ!Box-Konfig-Backup vom 2026-06-01 liegt extern/off-system in Vaultwarden; Reset-Pin und Account-Pfad bereithalten; Remote-HTTPS/FTP/FTPS aus dem Internet sind aus |
| Domain-Registrar | Besitz `kaleschke.info` | hoch | Ohne Domain brechen Public URLs/TLS-Erneuerung | Operator-Konto ausserhalb Repo, konkreten Registrar im Account pruefen | Registrar-Zugang, 2FA-Recovery und Zahlungsweg analog/off-system sichern |
| Cloudflare DNS | Authoritative DNS, ACME DNS-Challenge, DDNS | hoch | Neue Zertifikate/DNS-Aenderungen blockiert | Cloudflare-Konto; API-Token liegt als Host-Secret | API-Token rotierbar halten, Account-Recovery und Zone-Besitz pruefen |
| Hetzner Storage Box | Off-site Borg Backup | kritisch | Restore aus Off-site ggf. nicht moeglich | Hetzner-Konto / Storage-Box-Zugang ausserhalb Repo | Borg-Passphrase ist offline gesichert; Hetzner 2FA/Recovery/Zahlung sind bestaetigt; Storage Box ist SSH-only, Maintenance-Key liegt in Vaultwarden; Borg `append-only` wird per Operator-Entscheidung nicht umgesetzt |
| GitHub Mirror | Externer Repo-Mirror `michaelkaleschke-spec/homelab-infra` (privat) | mittel/hoch | Gitea-Verlust abfederbar, aber Bare-Metal-Bootstrap braucht Read-Zugang (PAT oder SSH-Deploy-Key); ohne diesen ist der Mirror im DR nicht klonbar | GitHub-Konto; Push-PAT liegt in Gitea-Mirror-Settings; **Read-PAT/Deploy-Key fuer DR muss zusaetzlich offline im DR-Kit liegen** | Mirror-Status regelmaessig pruefen; lokalen Clone als zweite Kopie behalten; Read-PAT mit Scope `repo:read` separat erzeugen und im DR-Kit ablegen |
| Tailscale | Remote-/Operator-Zugang | hoch | Remote-Zugriff erschwert, lokale Bedienung bleibt | Tailnet-Konto; Node `Kallilabcore`, IPv4 `100.80.98.33` | Break-glass per LAN und physischem Zugriff; Tailnet-Recovery-Codes sichern |
| GMX SMTP | Authelia Notifier, Vaultwarden-Einladungen, Ops-Report-Mail | mittel | Mail-Notifier und Vaultwarden-Einladungen fallen aus; Login selbst nicht zwingend | GMX-Konto; SMTP-Secrets liegen hostseitig | ntfy/zweiter SMTP als Fallback pruefen |
| OpenAI API | Paperless-GPT LLM/Vision-OCR (Dokumenttext/-bilder) **und** n8n Mail->LLM->Gitea-Workflow (GMX-Mailinhalt bis ~8000 Zeichen) | mittel | Automatische Dokument-Titel/Tags/Korrespondenten/LLM-OCR und die n8n-Mail-Extraktion fallen aus; Paperless und n8n laufen sonst weiter | je eigener OpenAI-API-Key ausserhalb Repo (Paperless-GPT Stack-ENV; n8n Credentials Store) | Keys in Vaultwarden/Komodo sichern, bei Offenlegung rotieren; Kosten/Usage im OpenAI-Projekt beobachten. Datenklasse/Retention/Loeschpfad stehen unten in "Data Privacy / Egress-Kontrollen"; konkrete OpenAI-Projekt-Settings bleiben live zu pruefen |
| Let's Encrypt | TLS-Zertifikate | hoch | Cert-Erneuerung faellt aus | automatisch via Traefik und Cloudflare DNS-Challenge | Cert-Expiry Alert einrichten; Cloudflare-Token und Traefik-Storage pruefen |
| Container Registries | Image Pulls von Docker Hub, GHCR, LSCR, Gitea Registry u. a. | mittel | Redeploy/Update blockiert | ueberwiegend oeffentlich; keine produktiven Registry-Tokens im Repo | Gepinnte Digests und lokale Runtime helfen kurzfristig; Updates geplant und einzeln deployen |
| Plex Konto | Plex native Auth, Claim und Client-Zugriff ueber `plex.kaleschke.info` | mittel | Plex-Web/App-Login und Clients koennen ausfallen; LAN-Medienpfade bleiben lokal | Plex-Konto ausserhalb Repo; `PLEX_CLAIM` nur fuer Setup | Plex Remote Access bleibt aus; externer Zugriff laeuft ueber Traefik/443. Konto-Recovery separat sichern |
| Mobile Push | ntfy (self-hosted) und ggf. mobile Plattform-Pushes; Egress = Alert-Payloads/Topic-Namen an Upstream-Push | niedrig/mittel | Alerts erreichen Mobilgeraete ggf. nicht | App-/Device-seitig | Kritische Alerts zusaetzlich in Grafana/Glance sichtbar halten; Payloads/Topics ohne PII/Pfade/Secrets halten; konkrete Live-Namen periodisch screenen |
| healthchecks.io (Cloud) | Externer Dead-Man's-Switch fuer Host-down-/Backup-Stillstand: Borg-Pre-Hook, baerchen-Nearline-Pull, geplanter Monitoring-Watchdog (#8); interne Job-Checks laufen self-hosted | mittel | Stiller Ausfall von Borg-/Nearline-Lauf wird nicht extern sichtbar; Backups selbst laufen weiter | healthchecks.io-Account; Ping-/Capability-URLs als Host-Secrets (`docs/SECRETS_MAP.md`) | Datenklasse = operative Metadaten (Check-Name/Timing); Naming ohne PII/Pfade/Secrets. Skripte sind endpoint-agnostisch -> bei Bedarf auf self-hosted `hc.kaleschke.info` umstellbar. Bewusste Architektur (DECISIONS 2026-06-23): Host-down-Waechter bleiben extern |
| Operator-DR-Workstation | Bare-Metal-Recovery-Arbeitsplatz (Gaming-PC Windows, lokaler Repo-Clone `G:\Gitea_Clone\homelab-infra`) | kritisch | Ohne Workstation kein Borg-Extract, kein Hetzner-Zugriff, kein Repo-Bootstrap; der Unraid-Host ist im Bare-Metal-Fall gerade weg | Operator-PC, WSL2 + Borg-Client, SSH-Key fuer Hetzner Storage Box, Offline-Kopie der Borg-Passphrase | Setup als bewusste DR-Vorbedingung pflegen (siehe Abschnitt "DR-Workstation Bare-Metal-Kit") |

## Data Privacy / Egress-Kontrollen

Stand: 2026-06-26, gegen Repo und offizielle Anbieter-Doku eingeordnet. Diese
Tabelle beschreibt erlaubte externe Pfade und die erwartete Datenhygiene. Sie
ersetzt keine Live-Kontrolle der konkreten Account-Schalter.

| Egress-Pfad | Repo-Beleg | Datenklasse | Token / Account | Retention beim Dritten | Loesch-/Export-/Opt-out-Pfad | Naheliegende Optimierung |
|---|---|---|---|---|---|---|
| Paperless-GPT -> OpenAI API | `apps/paperless-gpt/docker-compose.yml`, `docs/SERVICE_CATALOG.md` | Dokumenttext, Dokumentbilder, Metadaten, ggf. personenbezogene Inhalte | `OPENAI_API_KEY` als Stack-ENV/Host-Secret | OpenAI API: Standard-Retention bis zu 30 Tage fuer API Inputs/Outputs; Responses-API Application State standardmaessig 30 Tage; API-Daten werden laut OpenAI standardmaessig nicht zum Training genutzt, sofern nicht explizit opt-in | App deaktivieren oder Provider wechseln; API-Key rotieren/loeschen; OpenAI-Projekt/Logs pruefen; ZDR nur fuer geeignete Accounts/Endpoints beantragen; bei Responses-API `store=false`/Feature-Nutzung bewusst setzen, falls die App dies unterstuetzt | Nur Allowlist/Tags an Paperless-GPT senden; keine sensiblen Dokumenttypen ohne bewusste Freigabe |
| n8n Mail -> OpenAI -> Gitea | n8n-Workflow-JSONs und `docs/SERVICE_CATALOG.md`; Live-Aktivitaet separat pruefen | GMX-Mailinhalt bis Workflow-Limit, extrahierte Aufgaben/Metadaten | n8n Credential Store: GMX/OpenAI/Gitea-Credentials; `N8N_ENCRYPTION_KEY` fuer Restore noetig | OpenAI wie oben; Gitea speichert erzeugte Issues lokal und ggf. im GitHub-Mirror, falls dort committed/gespiegelt | Workflow deaktivieren; Credentials rotieren/loeschen; n8n Credential-Export nur verschluesselt behandeln; Gitea-Issues loeschen/exportieren | Workflow standardmaessig inaktiv halten oder Mail-Absender/Ordner allowlisten; Prompts auf minimale Datenweitergabe kuerzen |
| GMX IMAP/SMTP | Authelia/Vaultwarden/Mail-Archiver/n8n Mailpfade in Service-Doku | E-Mail-Inhalte, Absender/Empfaenger, SMTP-/IMAP-Metadaten | GMX-Konto + Host-Secrets | GMX: Content-/Nutzungsdaten werden nach 180 Tagen Inaktivitaet geloescht; bei Kuendigung werden Userdaten geloescht, sofern keine gesetzlichen Aufbewahrungsfristen greifen | GMX Account verwalten/kuendigen; Mails via IMAP/POP3/Export sichern; personenbezogene Accountdaten im Kundencenter exportieren | n8n/Mail-Archiver nur mit dediziertem Postfach oder dedizierten Ordnern betreiben; keine privaten Vollpostfaecher ungefiltert an LLM-Workflows geben |
| healthchecks.io Cloud | Externe Borg-/Nearline-/Host-down-Waechter in `docs/MASTER_TODO.md`, `ops/h-drive-nearline/README.md` | Checknamen, Ping-Zeitpunkte, IP-/Log-Metadaten, Capability-URLs | healthchecks.io-Account; Ping-URLs als Host-Secrets | Healthchecks.io: inaktive Accounts werden nach Hinweis geschlossen; Daten koennen nach Loeschung/Account-Schliessung bis zu 2 Monate in DB-Backups wiederherstellbar sein | Checks/Account loeschen; Capability-URLs rotieren; Pfad bei Bedarf auf self-hosted `hc.kaleschke.info` umstellen | Checknamen abstrakt halten, keine Hostpfade/Personennamen/Secrets im Namen oder Payload |
| ntfy / Mobile Push | `ops/ntfy`, Monitoring/Alertmanager-Bridge, Service-Doku | Alert-Payloads, Topicnamen, ggf. operative Metadaten | ntfy-User/Topic/Device; mobile Push ueber App-Plattform | ntfy: Nachrichten werden standardmaessig 12h gecached, Attachments 3h; bei Play/App-Store-Versionen koennen Metadaten/Inhalte ueber FCM laufen | Payload loeschen/Cache abwarten; mobile Push abmelden; F-Droid-App oder Self-host/Instant-Delivery nutzen, wenn FCM vermieden werden soll | Payloads weiter minimieren: keine PII, keine Pfade, keine Secrets, keine aussagekraeftigen internen Hostnamen |
| Borg -> Hetzner Storage Box | Borg-Scope, `ops/borg-ui/BACKUP_SCOPE.md`, `docs/RESTORE_MATRIX.md` | Verschluesselte Offsite-Kopie aller Borg-Quellen inkl. personenbezogener Appdaten und Secrets | Hetzner-Konto, Storage-Box-SSH-Key, Borg-Passphrase | Retention liegt primaer in Borg-Retention; Hetzner verarbeitet als Dienstleister nach DPA/Produktstandort, Non-Cloud-Produkte laut Hetzner innerhalb EU | Borg prune/delete/compact; Storage-Box-Daten loeschen/Account kuendigen; Crypto-Shred durch Vernichtung der Borg-Passphrase/Keys als letzte Kontrolle | DPA im Hetzner-Account aktuell halten; Restore und Loesch-/Prune-Lauf periodisch belegen |
| GitHub Mirror | `docs/EXTERNAL_DEPENDENCIES.md`, Gitea-Push-Mirror | Repo-Inhalt: Infrastruktur-Code/Doku, keine Secret-Werte; ggf. interne Host-/Pfadnamen | GitHub-Konto; Push-PAT in Gitea; DR-Read-Deploy-Key offline | GitHub behandelt private Repos als vertraulich; konkrete Repo-/Account-Loeschung ueber GitHub-Settings, Actions-Artefakt-Retention separat falls genutzt | Mirror deaktivieren/Repo loeschen; PAT/Deploy-Key widerrufen; Audit-/Access-Listen exportieren, soweit Account/Plan es erlaubt | Mirror weiter privat halten; Branch-/Token-Inventar live pruefen; Secret-Scanner gegen History laufen lassen |

Quellen fuer Anbieter-Regeln:

- OpenAI API Data Controls: `https://developers.openai.com/api/docs/guides/your-data`
- OpenAI Enterprise Privacy/API Retention: `https://openai.com/enterprise-privacy/`
- GMX Privacy/Data Collection: `https://www.gmx.com/company/privacypolicy/`, `https://www.gmx.com/company/data-collection/mail-client/`
- GMX Export: `https://support.gmx.com/account/managing/export-data.html`
- Healthchecks.io Privacy: `https://healthchecks.io/privacy/`
- ntfy Privacy: `https://docs.ntfy.sh/privacy/`
- Hetzner DPA/Data Protection: `https://docs.hetzner.com/general/company-and-policy/data-protection-at-hetzner/`
- GitHub private repo confidentiality/deletion/export: `https://docs.github.com/site-policy/github-terms/github-terms-of-service`

## Kritische Secrets ausserhalb des Repos

Authoritativ ist `docs/SECRETS_MAP.md`. Diese Liste markiert nur externe Abhaengigkeiten.

| Secret | Zweck | Recovery-Hinweis |
|---|---|---|
| Borg Passphrase | Entschluesselung Borg-Repos | Offline gesichert, Operator-Bestaetigung 2026-05-26 |
| Cloudflare DNS API Token | ACME DNS-Challenge | Token-Rotation und Scope pruefen |
| GitHub Mirror Token | Push-Mirror | In Gitea/GitHub verwaltet, nicht im Repo |
| Tailscale Account Recovery | Tailnet-Zugang | Account-2FA/Recovery Codes sichern |
| SMTP Passwort | Authelia Mail, Vaultwarden-Einladungen, Ops-Report-Mail | In Host-Secrets, Fallback pruefen |
| Domain-Registrar Recovery | Domain-Besitz und Zahlung | Account, 2FA und Zahlungsweg ausserhalb des Homelabs sichern |
| Hetzner Storage Box Zugang | Off-site Backup-Ziel | Account 2FA aktiv, Recovery Key offline gedruckt, Zahlungsweg ok; Maintenance-Key und Storage-Box-Passwort in Vaultwarden |
| OpenAI API Key | Paperless-GPT GPT-Zugriff | Als Stack ENV / Vaultwarden-Eintrag sichern; bei Verdacht auf Leak rotieren |
| KOMODO_* Stack-ENV-Notiz | Offline-Sicherung der 5 Komodo-Werte (`KOMODO_SECRET_KEY`, `KOMODO_WEBHOOK_SECRET`, `KOMODO_JWT_SECRET`, `KOMODO_MONGO_PASSWORD`, `KOMODO_PERIPHERY_PASSKEY`) | **Status 2026-06-03: offline gesichert (Operator-Bestaetigung)**. Quelle der Werte ist die host-seitige Self-Stack-`.env` (`/mnt/user/services/stacks/komodo/.env`) bzw. die Drift-Recovery-Kopie unter `/mnt/user/appdata/secrets/_komodo_stack_env_recovery_2026-05-04.env`. Nicht im Repo, nicht in ntfy, nicht in Logs |
| GitHub-Mirror Read-Only Deploy-Key | DR-Read-Zugang zum privaten Mirror `michaelkaleschke-spec/homelab-infra` | **Status 2026-06-03: offline gesichert (Operator-Bestaetigung).** SSH-Deploy-Key `dr-readonly-2026-06-03` (ed25519, Passphrase-frei), Title in GitHub Repo Settings -> Deploy Keys: `DR Read-Only 2026-06-03`, Write-Access bewusst deaktiviert. Private Key liegt offline neben der KOMODO_*-Notiz. Smoke `git ls-remote` am 2026-06-03 erfolgreich. |

## DR-Workstation Bare-Metal-Kit

Der Operator-Gaming-PC ist im Bare-Metal-Fall die einzige Stelle, von der aus Recovery starten kann. Folgende Bestandteile gehoeren zum minimalen DR-Kit auf diesem Rechner:

| Bestandteil | Zweck | Pruefen |
|---|---|---|
| Repo-Clone `G:\Gitea_Clone\homelab-infra` (master, gefetcht) | Recovery-Anker fuer `ops/komodo/docker-compose.yml`, Restore-Skripte | `git -C G:\Gitea_Clone\homelab-infra log --oneline -1` plausibel aktuell |
| Read-Zugang zum privaten GitHub-Mirror | Fallback, falls lokaler Clone defekt | SSH-Deploy-Key `dr-readonly-2026-06-03` (ed25519, Passphrase-frei) offline im DR-Kit, ein Test-Clone pro Quartal mit `GIT_SSH_COMMAND="ssh -i <pfad-zum-key> -o IdentitiesOnly=yes" git ls-remote git@github.com:michaelkaleschke-spec/homelab-infra.git` |
| WSL2 mit Borg-Client (`apt install borgbackup`) | Borg-Extract von Hetzner Storage Box ohne laufenden Unraid-Host | `borg --version` antwortet; ein `borg list` gegen Hetzner-Repo laeuft |
| SSH-Key fuer Hetzner Storage Box | Login auf `u565255.your-storagebox.de:23` | **Status 2026-06-03: ed25519-DR-Key `dr-hetzner-2026-06-03` offline gesichert.** Pubkey via `install-ssh-key` auf der Storage Box autorisiert, passwortloser Login erfolgreich, `ls` zeigt vier Borg-Repos (`backup`, `backup2`, `hetzner_borg_appdata`, `hetzner_borg_appdata_critical`). Private Key liegt offline neben KOMODO_*-Notiz und GitHub-Deploy-Key |
| Offline-Kopie Borg-Passphrase | Entschluesselung des Borg-Repos | Operator-Bestaetigung 2026-05-26; bei Reviews nur Auffindbarkeit pruefen |
| Offline-Kopie KOMODO_* Stack-ENV | Komodo-Bootstrap ohne Vaultwarden | **Status 2026-06-03: offline gesichert (Operator-Bestaetigung)** |
| Vaultwarden Master-Passwort offline | Zugriff auf Vaultwarden-Export im DR | Operator-Wissen, ggf. analog gesichert |

Operative Regel: Die DR-Workstation wird nicht als Test-/Spiel-PC betrachtet. WSL und das DR-Kit duerfen nicht unbemerkt unbrauchbar werden. Quartalsweise minimaler Trockenlauf: `borg list <hetzner-repo>` muss antworten und der Repo-Clone muss fetchbar bleiben.

## Ausfall-Szenarien

### Hetzner Storage Box nicht erreichbar

- Lokales Borg-Repo und aktuelle Dumps pruefen.
- Keine destruktiven Host-Aenderungen starten, solange Off-site unklar ist.
- H:/ Nearline-Pull als schnelle lokale Zweitkopie fuer kritische Restore-Artefakte nutzen.
- Zweites Off-site-Ziel nur neu bewerten bei Hetzner-Problemen, stark wachsendem Datenwert oder geaenderter Betreiber-Praeferenz.

### Cloudflare Account/DNS gestoert

- Bestehende Zertifikate laufen bis Ablauf weiter.
- Keine Domain-/ACME-Aenderungen moeglich.
- Tailscale/LAN-Zugang als Break-glass nutzen.

### Tailscale gestoert

- Lokalen LAN-Zugang nutzen.
- Direkte Admin-Ports nur gemaess dokumentierten Ausnahmen verwenden.
- AdGuard-Admin-Bind muss so geplant werden, dass ein lokaler Break-glass-Weg bekannt ist.
- Seit 2026-05-26 ist AdGuard Admin nur ueber `100.80.98.33:8082` gebunden; bei Tailnet-Ausfall ist lokaler Host-/Compose-Zugriff der Break-glass-Weg.

### Telekom-DSL / FRITZ!Box gestoert

- Lokale LAN-Apps (Plex, AdGuard-DNS, lokales Borg-Dump-Repository) bleiben verfuegbar, solange Host und Switch laufen.
- Tailscale-Sessions, die bereits stehen, koennen ueber DERP/Relays kurzzeitig weiterlaufen; neue Verbindungen koennen ausfallen.
- ACME-/DDNS-/Hetzner-Backup-Laeufe pausieren bis WAN zurueck ist.
- FRITZ!OS ist am 2026-06-01 auf 8.25 (`154.08.25`) beobachtet; weitere Updates nur in einem geplanten Service-Fenster einspielen, weil Reboot WAN/Tailscale-Aufbau unterbricht.

### Domain verloren oder Registrar-Zugriff verloren

- Gitea/GitHub Mirror und lokale IP/Tailscale-Pfade fuer Recovery nutzen.
- Neue Domain waere separater Migrationsfall fuer Traefik, Authelia, App-URLs und Clients.

## Review

| Datum | Ergebnis | Naechste Aktion |
|---|---|---|
| 2026-05-26 bis 2026-06-03 | Baseline und Haertung abgeschlossen: externe Abhaengigkeiten dokumentiert; FRITZ!Box-WAN auf 443/tcp bereinigt, Remote-Dienste aus, Konfig-Backup in Vaultwarden; Hetzner-Account-Hygiene (2FA, Recovery Key offline); KOMODO_*-Notiz und GitHub-Read-Deploy-Key offline gesichert. Detailhistorie in Git. | Keine Folgeaktion |
| 2026-06-03 | Hetzner Storage Box DR-SSH-Key `dr-hetzner-2026-06-03` (ed25519, Passphrase-frei) erzeugt, via `install-ssh-key` auf Storage Box `u565255.your-storagebox.de:23` autorisiert, passwortloser Login erfolgreich (Borg-Repos sichtbar), Private-Key offline neben KOMODO_*-Notiz und GitHub-Deploy-Key abgelegt, Arbeitsplatz-Kopie geloescht. Bare-Metal-Borg-Restore von der DR-Workstation ist damit moeglich, sobald WSL2 + Borg-Client installiert sind. | Restliche P1-Operator-Aufgaben: WSL2 + Borg-Client auf DR-Workstation installieren, Nextcloud-Restore-Test |
| 2026-06-06 | DR-Workstation produktiv: WSL2 Ubuntu 24.04 vorhanden, SSH/Git und Borg 1.2.8 in WSL vorhanden, DR-Key-Arbeitskopien unter `~/.ssh/dr-readonly` und `~/.ssh/dr-hetzner`, GitHub-Read-Smoke und Hetzner-SSH-Smoke erfolgreich, `ops/maintenance/dr-workstation-smoke.sh` nach `~/dr-smoke.sh` kopiert. Finaler Operator-Smoke erfolgreich: GitHub HEAD `3a263a4...`, Hetzner Storage Box Repos sichtbar, Borg-Repo `hetzner_borg_appdata_critical` gelesen, Repository ID `5dd9b949...`, encrypted `Yes (repokey)`, `DR-Smoke OK (2026-06-06 10:05:30)`. | Quartalsweise `bash ~/dr-smoke.sh`; Borg-Passphrase weiterhin nur interaktiv eingeben und nicht speichern |