CVE-2026-109618 and CVE-2026-109619 (BSI BITS-H 2026-297981-1132) allow
unauthenticated RCE on every PHP before 8.5.12/8.4.27/8.3.36/8.2.35;
mod_php is the highest-risk variant. The running pod reports PHP 8.3.35
and www.renner.uno serves / to the internet without the Authentik gate.
Switch to the php8.5-apache variant of the same WordPress release,
pinned to the index digest rebuilt on 2026-10-22 after the PHP fix.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Flux source URL, flux-git rotator verify repo, review-bot REPOS, pipeline API,
clone and push URLs, the heating-can source label and the review-bot and
kuma-sync Go module paths. Merge right after the transfer.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Homelab moves to konairius/homelab; after the Woodpecker move its pipelines
resolve org secrets in konairius. The k.renner containers stay until the move
is done.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
registry-bot is the konairius registry identity: write:package PAT,
konairius org secret registry_bot_token, rotated by
openbao/rotation/registry-bot.yaml. That rotation syncs the secret for
the push, tag, release and manual events, so the manual trigger is
`event: manual` instead of a deployment target.
registry_bot_token is a konairius org secret. Woodpecker resolves org
secrets through the repo's org link, so this pipeline gets it only once
homelab has moved to konairius/homelab
(docs/superpowers/plans/2026-10-18-homelab-konairius-main.md, cut-over 1).
Drops the daily cron and the upstream-polling decide step. Every version
in ci/images/hermes/Containerfile is now an image reference (FROM for
nousresearch/hermes-agent, COPY --from for talosctl, kubectl, flux, bao
and tea), which Renovate's enabled dockerfile manager updates and
digest-pins. A merged Renovate PR pushes to ci/images/hermes/**, the
pipeline builds build.<unix-ts>, and Flux image automation rolls it out.
No checksums to maintain: the binaries come from digest-pinned images.
renovate.json: the hermes Containerfile gets a PR of its own instead of
the "CI non-major" group (that group is for changes that never reach the
cluster), and nousresearch/hermes-agent is held to v0.x because the
retired date-versioned v2026.x tags sort above it.
Verified: each COPY --from path exists in the pinned image and the
binary runs on the hermes-agent v0.22.2 base. renovate-config-validator
37.440.7 reports only the two pre-existing errors on master
(flux/kubernetes.managerFilePatterns).
nousresearch/hermes-agent ships no talosctl, kubectl, flux, bao, tea or
jq. The kubectl init container dropped its binary in /opt/data/.local/bin,
which the agent's terminal never has on PATH: Hermes snapshots the env
from a bash login shell, and Debian's /etc/profile resets PATH for
non-root users. /usr/local/bin survives that reset.
Upstream's documented route for always-present tools is a derived image
(docs/user-guide/docker, "Adding tools"). ci/images/hermes builds FROM
the upstream release and adds the binaries, versions matched to the
cluster (Talos v1.13.10, Kubernetes v1.36.3, Flux v2.9.5, OpenBao 2.7.1)
and checksummed against upstream release checksums.
.woodpecker/hermes-image.yml rebuilds daily when upstream publishes a
new release (compared against the uno.renner.hermes.version label on
:latest), and on any push to the Containerfile. Tags are
build.<unix-ts>, the scheme Flux image automation already tracks for
wiki and shelly-manager.
Owner step after merge: register the cron
woodpecker repo cron add --repo k.renner/homelab \
--name hermes-image --branch master --schedule '@daily'
The Deployment switch follows in a separate PR once the first build
exists, so the Recreate rollout never points at a missing tag.
Switches apps/hermes to gitea.renner.uno/gitea_admin/hermes, which
carries talosctl, kubectl, flux, bao, tea and jq in /usr/local/bin. The
image-automation policy now tracks its build.<unix-ts> tags instead of
upstream nousresearch/hermes-agent; .woodpecker/hermes-image.yml follows
upstream releases.
Drops the kubectl init container and its emptyDir: the binary sat in
/opt/data/.local/bin, which the agent's terminal does not have on PATH.
One group per own service with application-level checks (json-query on
health/API endpoints where ungated, keyword otherwise) and a Third-party
group with plain checks. Endpoints verified from the Kuma VPS.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The owner placed hermes-bot's API token at OpenBao apps/hermes/gitea
(api-token). ExternalSecret hermes-gitea mounts it as a file at
/var/run/secrets/gitea/api-token.
git is configured through GIT_CONFIG_* env on the container, so nothing
lives on the PVC: a credential helper for https://gitea.renner.uno that
answers with hermes-bot and the token read from the file, plus the
commit identity hermes-bot <hermes-bot@konstantin-renner.de>. Hermes'
subprocess env scrub only strips its own provider/messaging secrets, so
GIT_* reaches the terminal tool.
SOUL.md drops "no write access" and tells the agent how to use git and
the REST API (no tea in the image) without printing the token; the
existing feature-branch/PR/no-self-merge rules apply.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
apps/hermes sets namespaces per resource, not in the kustomization, so
configMapGenerator emitted hermes-soul and hermes-skills without one and
the Flux apply failed ("namespace not specified"). The earlier
server-side dry-run masked it by defaulting to the current namespace.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
SOUL.md comes from git (ConfigMap hermes-soul, subPath over the PVC
copy): the stock persona plus the homelab's working rules distilled
from Claude Code's global CLAUDE.md and feedback memory — wiki first,
the verification ladder, the network/DNS/placement/secret design rules,
operational change discipline and how to work with the owner. Claude
Code harness specifics (Bash allowlisting, subagent sizing, worktrees,
claude-bot identities) are left out.
The homelab-wiki skill (ConfigMap hermes-skills, mounted at
/opt/hermes-skills and registered via skills.external_dirs) wraps the
wiki service API in a stdlib Python client, since the image has no
bash or jq. Hermes calls the in-cluster service directly with its own
API key, identity `hermes`:
- apps/hermes/wiki -> Secret hermes-wiki, mounted as a file (optional,
so the pod starts before it is seeded; reads are anonymous)
- apps/ai/wiki-api-key-hermes -> Auth__ApiKeys__hermes on the wiki. A
separate path rather than a field in apps/ai/wiki-api-keys, because
claude-bot's OpenBao policy is write-only and a put on the shared path
would drop the workstation key.
- CNPs: hermes egress to ai/wiki:8080, wiki ingress from hermes
- hermes added to the openbao ClusterSecretStore allowlist
The built-in memory store (2200/1375 chars, agent-rewritten) is left to
the agent.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A single-file bind mount pins the inode present at container start.
ansible.builtin.copy replaces the file by rename, so the running
container kept executing the previous kuma-setup.js: the #1358 deploy
ran the old admin-only script (host md5 8d77..., container 55a2...) and
created no notification, status page or metrics key.
The script now lives in {{ uptime_kuma_dir }}/setup/, mounted read-only
at /app/setup; the compose change recreates the container once. The old
file path is removed.
Verified on a local 2.5.6 container: a file replaced by rename in the
mounted directory is visible inside, and the script run from
/app/setup resolves socket.io-client and converges.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Kuma 2.5.6 afterLogin (server/server.js:1839-1848) sends the
notification and API-key lists inside Promise.allSettled and acks the
login regardless. A missing notificationList was read as empty and
would create a second default "email" notification (double mails);
a missing apiKeyList would add a key without removing the old one.
The script now fails the run instead.
Verified against a local 2.5.6: fresh run creates everything, second
run reports no changes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
kuma-setup.js now logs in after the admin setup and converges on every run:
- settings: Trust Proxy on, Primary Base URL https://kuma.renner.uno.
Read-modify-write; unset keys get the same defaults the Kuma settings page
applies before saving (a raw getSettings payload has nscd unset, which makes
setSettings stop nscd).
- notification "email" (SMTP, default enabled, applied to existing monitors):
created or updated in place by name, never duplicated. Credentials from
OpenBao homelab/infrastructure/uptime-kuma/smtp; recipient is the
Alertmanager receiver admin@renner.uno; 465 means implicit TLS, else STARTTLS.
- status page "renner" / "Renner" with custom domain uptime.renner.uno. Only
title and domain are enforced; saveStatusPage replaces all groups, so the
current publicGroupList from /api/status-page/<slug> is sent back unchanged.
Steady state does not call saveStatusPage at all.
- metrics API key "prometheus": Ansible checks the key stored at
homelab/infrastructure/uptime-kuma-metrics against /metrics; if it is
missing or rejected the script deletes all "prometheus" keys, creates a new
one and hands it over via a 0600 file in the data dir, which Ansible writes
to OpenBao (vault_kv2_write, community.hashi_vault 7.1.0 in the CI image)
and then removes. The key never reaches stdout/stderr or the Ansible log.
The script is restructured into small async steps with per-emit timeouts.
The uptime-kuma-vps policy gains read on the smtp path and
read/create/update on the metrics path (must be applied by hand).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Kuma 2.5.6 applies "default enabled" notifications only in the web UI
(src/pages/EditMonitor.vue:4128-4132); the server's add handler stores
exactly the notificationIDList the client sends (server/server.js:748,791).
Monitors created by kuma-sync therefore had no notifications.
The notification set is now a managed field: exactly the IDs of all
notifications with isDefault set, sorted, applied on create and update
(group monitors included). Monitor.NotificationIDs is part of
Normalized(), so a changed default set or a hand-made change triggers an
update on the next resync and an unchanged one does not.
Client.DefaultNotifications reads the library's cached notificationList
(go-uptime-kuma-client v0.6.2 notification.go:17). Kuma has no command to
request the list; it pushes it at login and to every session of the user
after each change (server/client.js:31, server/server.js:1573,1594,1836).
A failed read is KumaUnavailable with no create or update.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
nousresearch/hermes-agent still carries v2026.4.3..v2026.9.24 from the
old date-based scheme. As semver they sort above 0.x, so '>=0.22.2'
picked v2026.9.24 (2026-09-24) and rolled the pod back from v0.22.2.
Cap the range below 1.0.0 and pin the manifests back to v0.22.2.
Add a blackbox-http probe of kuma.renner.uno with a dedicated critical
UptimeKumaUnreachable rule (excluded from BlackboxProbeFailing), scrape
Kuma /metrics with the API key from OpenBao, and alert on sustained slow
monitor response times. No egress policy exists in the monitoring
namespace, so no CNP change is needed.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
After a Kuma database loss or restore, IDs restart and a resource's
status.monitorID can point at a monitor that now carries another
resource's ownership tag. That proves our monitor is gone, so the
controller creates a new one instead of parking at NotOwned forever.
Only an untagged monitor at the previous ID still blocks the create
(tag removed by hand), as before.
Residual Important finding from the kuma-sync final review.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Hermes Agent as a pod in its own `hermes` namespace: gateway (messaging
platforms, cron, OpenAI-compatible API) and dashboard, supervised by the
image's s6-overlay, state on a 10Gi ceph-block PVC.
- hermes.renner.uno (LAN): dashboard and Hermes Desktop remote gateway.
Plain Traefik plus the dashboard's own Authentik OIDC login (public PKCE
client, Hermes Users group) — a forward-auth gate would break Desktop's
Bearer-token calls.
- hermes-api.renner.uno (LAN): API server, Bearer key generated in-cluster
by an ESO Password generator.
- Read-only kubectl via the built-in `view` ClusterRole.
- CNPs: world 443/80, kube-apiserver, Traefik for LAN hostnames, and
Prometheus/Alertmanager/Loki (with the matching monitoring-side grant).
- Image automation for nousresearch/hermes-agent v-tags.
After deploy: log in to Anthropic inside the pod
(`hermes auth add anthropic --type oauth --no-browser`, then `hermes model`);
platform and Home Assistant tokens go in via the dashboard.
Not yet covered: a Velero schedule for the PVC.
Last smoke-test step: Flux prunes the KumaMonitor and the controller's
finalizer deletes Kuma monitor 9.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
claude-botandClaude Opus 5.5
k.renner
hermes-bot
security-bot