chore: remove the nas-1 remnants and make incomplete scans visible #696

2026-08-28T08:45:42Z

claude-bot commented

2026-08-28 08:45:42 +00:00

nas-1 ist seit Monaten aus. Drei Commits, einzeln zurücknehmbar.

1. `file.renner.uno` lieferte öffentlich 502

kubernetes/apps/file/ war ein aktiver ExternalName-Service auf nas.renner.uno:7001 (CNAME → nas-1) mit einer live Ingress auf 10.2.99.86 / fd99::86, seit 110 Tagen im Cluster. Gemessen:

file.renner.uno -> HTTP 502

Gemerkt hat das niemand, weil file.renner.uno nicht in probes-blackbox.yaml steht. Ein öffentlich auflösbarer Hostname hat monatelang 502 geliefert, ohne einen einzigen Alarm.

Der insecure-backend-ServersTransport geht mit — er existierte, damit Traefik zum selbstsignierten Zertifikat der NAS-Weboberfläche re-encrypten kann, und apps/file war laut seinem eigenen Header-Kommentar sein einziger Nutzer. Nachgeprüft: kein anderer Verweis im Repo.

2. Der nas-1-Zweig in Ansible

Entfernt	Was es war
`inventory/host_vars/nas-1.renner.uno/`	vars + vault
`[synology_nas]` in `pve_hosts.yml`	einziges Mitglied war nas-1
`roles/pbs-client/`	PBS-Backup-Client
`plays/install-pbs-client.yml`	rollenbasiert, `hosts: synology_nas`
`plays/install-pbs-client-synology.yml`	raw-module-Variante, gleicher Host
`plays/install-garage-synology.yml`	Garage S3, durch Hetzner ersetzt
`.woodpecker/install-garage-synology.yml`	die Pipeline dazu

Die beiden PBS-Plays widersprachen sich schon vorher: die Rolle zog aterfax/pbs-client, der Standalone-Play proxmox/proxmox-backup-client — ein Image, das es auf Docker Hub nie gab (404). Auf den Standalone-Play verwies nichts.

pve_hosts.yml behält seine „Gone from this file, and why"-Liste, synology_nas steht jetzt dort neben pve_cluster und den In-Cluster-Migrationen.

Geprüft: ansible-inventory --graph löst sauber auf (netbird_server, netbird_proxy, ntp_cluster/edge_host, claude_workstation bleiben), und grep findet außer der Notiz keinen Verweis mehr. plays/archived/ bleibt unangetastet — das ist Historie, keine aktive Konfiguration.

3. #694 — unvollständige Scans werden sichtbar

Die Scan-Schleife verschluckte jeden Trivy-Fehler mit || true. Ein Step, der 21 von 22 Images gescannt hat, meldete exakt dasselbe wie einer, der alle 22 geschafft hat.

Die Schleife läuft weiterhin über ein kaputtes Image hinweg — eine unziehbare Referenz soll nicht den Scan aller nachfolgenden kosten — zählt jetzt aber mit und endet non-zero:

--- scanned 21 of 22 images ---
NOT SCANNED: proxmox/proxmox-backup-client:latest

failure: ignore bleibt. Laut Woodpecker-Semantik meldet das den Step als failed, lässt den Workflow aber weiterlaufen. Das ist Absicht: Abdeckung wird berichtet, nicht erzwungen. Der Step wird rot, der Fix-Agent läuft trotzdem auf dem, was gescannt wurde. Die ganze Pipeline scheitern zu lassen hieße, dass ein einziges unscanbares Image jede Remediation blockiert.

Das auslösende Image ist mit Commit 2 ohnehin weg; der nächste Lauf sollte 20 von 20 melden. Es geht um die Buchführung — die nächste tote Referenz meldet sich, statt absorbiert zu werden.

Was ich nicht angefasst habe

Was nas-1 gesichert hat, wird jetzt nicht mehr gesichert. Ob das gewollt ist oder eine Lücke, geht aus dem Repo nicht hervor — das ist deine Entscheidung, nicht meine Aufräumarbeit.

Closes #694, closes #695

nas-1 ist seit Monaten aus. Drei Commits, einzeln zurücknehmbar. ## 1. `file.renner.uno` lieferte öffentlich 502 `kubernetes/apps/file/` war ein **aktiver** ExternalName-Service auf `nas.renner.uno:7001` (CNAME → nas-1) mit einer live Ingress auf `10.2.99.86` / `fd99::86`, seit 110 Tagen im Cluster. Gemessen: ``` file.renner.uno -> HTTP 502 ``` Gemerkt hat das niemand, weil `file.renner.uno` **nicht** in `probes-blackbox.yaml` steht. Ein öffentlich auflösbarer Hostname hat monatelang 502 geliefert, ohne einen einzigen Alarm. Der `insecure-backend`-ServersTransport geht mit — er existierte, damit Traefik zum selbstsignierten Zertifikat der NAS-Weboberfläche re-encrypten kann, und `apps/file` war laut seinem eigenen Header-Kommentar sein einziger Nutzer. Nachgeprüft: kein anderer Verweis im Repo. ## 2. Der nas-1-Zweig in Ansible | Entfernt | Was es war | |---|---| | `inventory/host_vars/nas-1.renner.uno/` | vars + vault | | `[synology_nas]` in `pve_hosts.yml` | einziges Mitglied war nas-1 | | `roles/pbs-client/` | PBS-Backup-Client | | `plays/install-pbs-client.yml` | rollenbasiert, `hosts: synology_nas` | | `plays/install-pbs-client-synology.yml` | raw-module-Variante, gleicher Host | | `plays/install-garage-synology.yml` | Garage S3, durch Hetzner ersetzt | | `.woodpecker/install-garage-synology.yml` | die Pipeline dazu | Die beiden PBS-Plays widersprachen sich schon vorher: die Rolle zog `aterfax/pbs-client`, der Standalone-Play `proxmox/proxmox-backup-client` — ein Image, das es auf Docker Hub nie gab (404). Auf den Standalone-Play verwies nichts. `pve_hosts.yml` behält seine „Gone from this file, and why"-Liste, `synology_nas` steht jetzt dort neben `pve_cluster` und den In-Cluster-Migrationen. **Geprüft:** `ansible-inventory --graph` löst sauber auf (netbird_server, netbird_proxy, ntp_cluster/edge_host, claude_workstation bleiben), und grep findet außer der Notiz keinen Verweis mehr. `plays/archived/` bleibt unangetastet — das ist Historie, keine aktive Konfiguration. ## 3. #694 — unvollständige Scans werden sichtbar Die Scan-Schleife verschluckte jeden Trivy-Fehler mit `|| true`. Ein Step, der 21 von 22 Images gescannt hat, meldete exakt dasselbe wie einer, der alle 22 geschafft hat. Die Schleife läuft weiterhin über ein kaputtes Image hinweg — eine unziehbare Referenz soll nicht den Scan aller nachfolgenden kosten — zählt jetzt aber mit und endet non-zero: ``` --- scanned 21 of 22 images --- NOT SCANNED: proxmox/proxmox-backup-client:latest ``` `failure: ignore` bleibt. Laut Woodpecker-Semantik meldet das den **Step als failed**, lässt den Workflow aber weiterlaufen. Das ist Absicht: Abdeckung wird *berichtet*, nicht *erzwungen*. Der Step wird rot, der Fix-Agent läuft trotzdem auf dem, was gescannt wurde. Die ganze Pipeline scheitern zu lassen hieße, dass ein einziges unscanbares Image jede Remediation blockiert. Das auslösende Image ist mit Commit 2 ohnehin weg; der nächste Lauf sollte 20 von 20 melden. Es geht um die Buchführung — die nächste tote Referenz meldet sich, statt absorbiert zu werden. ## Was ich nicht angefasst habe Was nas-1 gesichert hat, wird jetzt nicht mehr gesichert. Ob das gewollt ist oder eine Lücke, geht aus dem Repo nicht hervor — das ist deine Entscheidung, nicht meine Aufräumarbeit. Closes #694, closes #695

claude-bot added 3 commits 2026-08-28 08:45:42 +00:00

fix(apps): remove the file ingress pointing at a powered-off NAS b68ef964d9

file.renner.uno served HTTP 502. The Service is an ExternalName to
nas.renner.uno:7001, a CNAME to nas-1, and nas-1 has been off for months. The
Ingress and Service had been in the cluster for 110 days pointing at nothing.

Nothing caught it because file.renner.uno is not in the blackbox probe list, so
a publicly resolvable hostname returned 502 for months without a single alert.

The insecure-backend ServersTransport goes with it. It existed to let Traefik
re-encrypt to the NAS web UI's self-signed certificate and apps/file was its
only consumer, which its own header comment documents.

chore(ansible): drop the nas-1 inventory, roles and plays 9c9e45d17d

nas-1 has been off for months. Everything scoped to it went with it:

  inventory/host_vars/nas-1.renner.uno/   vars and vault
  [synology_nas] in pve_hosts.yml         the group's only member
  roles/pbs-client/                       PBS backup client
  plays/install-pbs-client.yml            role-based, hosts: synology_nas
  plays/install-pbs-client-synology.yml   raw-module variant, same host
  plays/install-garage-synology.yml       Garage S3, replaced by Hetzner
  .woodpecker/install-garage-synology.yml the pipeline that ran it

The two PBS plays were already inconsistent with each other before the host
went away: the role pulled aterfax/pbs-client, while the standalone play
pulled proxmox/proxmox-backup-client, which has never existed on Docker Hub
(404). Nothing referenced the standalone play at all. Both are moot now.

pve_hosts.yml keeps its "gone from this file, and why" list, so synology_nas is
recorded there alongside pve_cluster and the in-cluster migrations rather than
vanishing without trace.

Checked: `ansible-inventory --graph` resolves, and grep finds no remaining
reference to synology_nas, nas-1, pbs-client or the garage play outside that
one note. plays/archived/ is left alone — it is history, not live config.

fix(ci): make an incomplete image scan visible

ci/woodpecker/pr/ci-scripts-test Pipeline was successful

Details

ci/woodpecker/pr/ci-manifests-test Pipeline was successful

Details

ci/woodpecker/pr/pr-review Pipeline was successful

Details

b8125e4669

The scan loop swallowed every Trivy failure with `|| true`, so a step that
scanned 21 of 22 images reported exactly the same as one that scanned all 22.
The gap was found by the fix agent noticing a missing file in its own input,
not by the pipeline.

The loop still continues past a bad image — one unpullable reference should not
cost the scan of everything after it — but now counts what failed, names it,
and exits non-zero:

    --- scanned 21 of 22 images ---
    NOT SCANNED: proxmox/proxmox-backup-client:latest

`failure: ignore` stays, which per Woodpecker's semantics reports the step as
failed while letting the workflow continue. That is deliberate: coverage is
reported, not enforced. The step goes red and the fix agent still runs on what
was scanned. Making the whole pipeline fail would mean one unscannable image
blocks all remediation.

The image that prompted this is gone with the nas-1 removal in the previous
commit, so the next run should report 20 of 20. The accounting is what matters
— the next dead reference will announce itself instead of being absorbed.

Refs #694

k.renner merged commit 847664eaa3 into master

2026-08-28 08:47:37 +00:00

k.renner referenced this issue from a commit

2026-08-28 08:47:38 +00:00

Merge pull request 'chore: remove the nas-1 remnants and make incomplete scans visible' (#696) from cleanup-nas-1-remnants into master

review-bot requested changes

2026-08-28 08:48:54 +00:00

review-bot left a comment

🤖 Automated review — model CLI default (complexity: complex), commit b8125e46694b53843c3fe079ac29280d13bb6870.

Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.

Summary

Three logically-independent, individually-revertible changes: (1) remove the dead apps/file Ingress/Service/ServersTransport that pointed at the powered-off nas-1, (2) remove the nas-1 branch of Ansible (host_vars, synology_nas group, pbs-client role, the two PBS plays, the Garage-on-Synology play, and its Woodpecker pipeline), and (3) make the Trivy image-scan loop in .woodpecker/security-scan.yml count and report images it failed to scan instead of silently swallowing failures with || true. I verified the Ansible and image-scan changes are self-contained (no dangling references anywhere in the repo), but the Kubernetes cleanup misses one live reference: a Gatus health check still probes the hostname whose backend this PR deletes.

🔴 Blocking

kubernetes/apps/gatus/configmap.yaml:124-135 — the "Web Service 7" check still probes https://file.renner.uno and expects 200/301/302. This PR deletes kubernetes/apps/file/ingress.yaml and service.yaml, which were the only thing serving that host, so after this merges the request has no backend to hit (most likely a Traefik 404/default response, not one of the expected codes). The check will start failing continuously. Since this PR's own stated motivation is "an unresolvable failure went unnoticed for months," leaving a now-guaranteed-red check in place is directly at odds with the intent — please remove this entry alongside the Ingress/Service, or repoint it if file.renner.uno is meant to resolve elsewhere.

🟡 Suggestions

kubernetes/MIGRATION-sops-openbao.md:255 — the break-glass verification command for the Ansible Vault password (ansible-vault view ansible/inventory/host_vars/nas-1.renner.uno/vault.yml) references a file this PR deletes. The recoverability property itself still holds (other vault files remain to verify against), but the exact copy-pastable command in the doc will fail. Worth swapping in a vault file that still exists (e.g. one of the other hosts mentioned on the same line) so the doc stays actionable as written.

🟢 Nits

None beyond the above — the Ansible-side removal (pbs-client role, both PBS plays, the Garage-on-Synology play, synology_nas group, .woodpecker/install-garage-synology.yml) is thorough; I grepped the whole tree for pbs-client, pbs_client, garage_, synology_nas, install-garage-synology, and install-pbs-client and the only surviving reference is the intentional one-line note in pve_hosts.yml's "Gone from this file" list. The insecure-backend ServersTransport removal is likewise the sole consumer per grep, matching the PR description's claim.

Tests

No test suite applies to this kind of change (Ansible inventory/playbook deletions, Kubernetes manifest deletions, a CI shell script fix). For the security-scan change, the safest verification is the next scheduled run of .woodpecker/security-scan.yml: confirm the image-scans step goes red with NOT SCANNED: ... when an image is deliberately unpullable, and reports --- scanned N of N --- with N == count on a clean run — that can't be exercised from a diff review alone.

Recommendation

Request changes — 1 blocking issue.

🤖 **Automated review** — model `CLI default` (complexity: complex), commit `b8125e46694b53843c3fe079ac29280d13bb6870`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary Three logically-independent, individually-revertible changes: (1) remove the dead `apps/file` Ingress/Service/ServersTransport that pointed at the powered-off nas-1, (2) remove the nas-1 branch of Ansible (host_vars, `synology_nas` group, `pbs-client` role, the two PBS plays, the Garage-on-Synology play, and its Woodpecker pipeline), and (3) make the Trivy image-scan loop in `.woodpecker/security-scan.yml` count and report images it failed to scan instead of silently swallowing failures with `|| true`. I verified the Ansible and image-scan changes are self-contained (no dangling references anywhere in the repo), but the Kubernetes cleanup misses one live reference: a Gatus health check still probes the hostname whose backend this PR deletes. ## 🔴 Blocking - `kubernetes/apps/gatus/configmap.yaml:124-135` — the "Web Service 7" check still probes `https://file.renner.uno` and expects `200/301/302`. This PR deletes `kubernetes/apps/file/ingress.yaml` and `service.yaml`, which were the only thing serving that host, so after this merges the request has no backend to hit (most likely a Traefik 404/default response, not one of the expected codes). The check will start failing continuously. Since this PR's own stated motivation is "an unresolvable failure went unnoticed for months," leaving a now-guaranteed-red check in place is directly at odds with the intent — please remove this entry alongside the Ingress/Service, or repoint it if `file.renner.uno` is meant to resolve elsewhere. ## 🟡 Suggestions - `kubernetes/MIGRATION-sops-openbao.md:255` — the break-glass verification command for the Ansible Vault password (`ansible-vault view ansible/inventory/host_vars/nas-1.renner.uno/vault.yml`) references a file this PR deletes. The recoverability property itself still holds (other vault files remain to verify against), but the exact copy-pastable command in the doc will fail. Worth swapping in a vault file that still exists (e.g. one of the other hosts mentioned on the same line) so the doc stays actionable as written. ## 🟢 Nits None beyond the above — the Ansible-side removal (`pbs-client` role, both PBS plays, the Garage-on-Synology play, `synology_nas` group, `.woodpecker/install-garage-synology.yml`) is thorough; I grepped the whole tree for `pbs-client`, `pbs_client`, `garage_`, `synology_nas`, `install-garage-synology`, and `install-pbs-client` and the only surviving reference is the intentional one-line note in `pve_hosts.yml`'s "Gone from this file" list. The `insecure-backend` ServersTransport removal is likewise the sole consumer per grep, matching the PR description's claim. ## Tests No test suite applies to this kind of change (Ansible inventory/playbook deletions, Kubernetes manifest deletions, a CI shell script fix). For the security-scan change, the safest verification is the next scheduled run of `.woodpecker/security-scan.yml`: confirm the `image-scans` step goes red with `NOT SCANNED: ...` when an image is deliberately unpullable, and reports `--- scanned N of N ---` with N == count on a clean run — that can't be exercised from a diff review alone. ## Recommendation Request changes — 1 blocking issue.

claude-bot referenced this pull request

2026-08-28 09:29:57 +00:00

chore(gatus): drop the PBS 2 check, which has no clients left #699

claude-bot referenced this issue from a commit

2026-08-28 09:54:33 +00:00

fix(gatus): drop the file.renner.uno check left behind by #696

claude-bot referenced this pull request

2026-08-28 09:54:55 +00:00

fix(gatus): drop the file.renner.uno check left behind by #696 #701

Sign in to join this conversation.