Renovate PR bodies do not cover every dependency (kaniko from
registry.gitlab.com has no source URL, so Renovate links no notes), and
the reviewer had no way to read upstream changes. The Anthropic backend
now offers the server-side web fetch tool when WEB_FETCH_DOMAINS is set;
the deployment sets github.com,gitlab.com.
- Version web_fetch_20250910 (basic): later versions turn on code
execution for dynamic filtering. max_uses 10 (WEB_FETCH_MAX_USES),
max_content_tokens 20000 per page.
- Anthropic only fetches URLs that appeared in a user message, a client
tool result or an earlier fetch/search result; MCP connector results do
not count. So the task message now lists the https links of the PR body
on the allowed domains (no userinfo, deduplicated, at most 20), marked
as untrusted data. Without web fetch the task is unchanged.
- Tool guard: a server_tool_use other than web_fetch, or web_fetch while
it is off, is a violation, so the review is not posted.
- Network policy: unchanged. The fetch runs on Anthropic's side; the pod
still only talks to Gitea (Traefik) and the model APIs.
The review-bot review of konairius/ical-proxy#22 (golang/alpine digests,
kaniko v1.25.20 -> v1.25.21) restated the diff and listed "digests and CI
not checked" as unverified. Three causes:
- Renovate wrote no release notes: it has no github.com token ("No
github.com token has been configured. Skipping release notes retrieval",
job renovate-29903220). The ExternalSecret now renders
RENOVATE_GITHUB_COM_TOKEN (the current name; GITHUB_COM_TOKEN is
deprecated) from its own OpenBao key apps/renovate/github, field `token`.
No other service reads that key.
- defaultMCPTools still named per-method tools that gitea-mcp 1.13 folded
into commit_read, branch_read, tag_read and release_read. tools/list on
gitea-mcp.renner.uno has none of get_commit, list_commits,
compare_commits, list_branches, get_tag, list_tags, get_release,
get_latest_release, list_releases, so 9 of the 20 enabled names matched
nothing and the prompt's compare_commits/list_commits steps had no tool.
The list now has the 1.13 names; a test keeps it read-only.
- prompt.md had no guidance for dependency updates. New "Dependency
updates" section: release notes between old and new version, the repo's
use of what they change (path:line), one line for digest-only rebuilds,
no unverified boilerplate. New mandatory check: CI status of the head
(pull_request_read get_status; Woodpecker reports commit statuses).
otbr installed socat from apt at every start, which the namespace
egress baseline denies, so it crash-looped. otbr-agent now speaks
spinel+hdlc+unix to a socket served by a native alpine/socat sidecar
that bridges to slzb-thread:6638 (openthread/otbr image of 2026-11-07;
Unix stream sockets landed in OpenThread #13785). otbr-egress allows
only that TCP link (S28-48).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
otbr comes back with its own network instead of joining the Nest's
NEST-PAN-339C, so the Nest Hub can leave the IoT VLAN (S28-46/S28-48).
The bootstrap Job forms it (dataset init new, channel 15, name
Suedstr28-Thread) on a fresh otbr-thread PVC; the Nest dataset
ExternalSecret is dropped and the Flux Kustomization un-suspended.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
error_reporting.enabled has been true since the first deploy. The server
hands the Sentry DSN (authentik.error-reporting.a7k.io) to every outpost
through /api/v3/root/config/, and the RADIUS and LDAP outposts then try
to send reports there; egress policy drops all of it. Reporting to a
third party was never intended to work here.
S28-43
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
matter-server fetches PAA root certificates, vendor names and OTA
metadata from the CSA DCL (on.dcl.csa-iot.org) and the development PAA
certificates from project-chip on GitHub (python-matter-server
helpers/paa_certificates.py, vendor_info.py, ota/dcl.py). zigbee2mqtt
fetches the Koenkk/zigbee-OTA index and images from
raw.githubusercontent.com (zigbee-herdsman ota.ts). The namespace
baseline denied all of it (~350 and ~200 drops a day), so certificate
refresh, vendor names and OTA silently failed. FQDN-scoped, 443 only.
S28-42
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Both phone home on a timer: every alloy pod to stats.grafana.org (~135
a day each) and influxd to telemetry.influxdata.com (56 a day). Egress
policy denies it, so this only removed log noise and wasted SYNs; switch
it off at the source like Loki's reporting_enabled: false.
--disable-reporting per the "alloy run" reference (chart alloy.extraArgs);
INFLUXD_REPORTING_DISABLED per the InfluxDB v2 config options.
S28-41
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
immich-machine-learning has ~222k tags and immich-server ~33k, nearly
all PR builds. Each anonymous scan pages the full list (about 220
requests of 1000 tags for ML) and hourly scans hit ghcr.io's
TOOMANYREQUESTS. Immich releases a few times a week at most, so 6h
costs nothing.
S28-40
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
New CIDR group udm-k8s-ingress (10.2.47.1/32, fd02:47::1/128); the LDAPS
rule references it instead of the whole net-k8s-ingress network.
S28-39
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The UDM authenticates admins against ldap.renner.uno:636 and syncs
hourly. It sources from its k8s-ingress address (10.2.47.1 /
fd02:47::1), which ldap-outpost-lan-ingress did not admit: 200 SYNs a
day dropped at :26 every hour. Same group the alloy-syslog and CoreDNS
policies use for the UDM; LDAPS only.
S28-39
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
About 43k POLICY_DENIED a day from trmnl-renderer to Google update and
account hosts. Source (OCI label): usetrmnl/trmnl-home-assistant dd556e6;
the Chromium flags are a fixed list in screenshot.ts:78 with no env or
option override, and --disable-background-networking is not among them.
Nothing on our side can switch it off; the denies are correct.
S28-4
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
sbr confines only the DHCP (IPv4) routes. net1 still takes a SLAAC address
and an RA default route, so socat-ipv6 sent every relayed datagram out the
IoT VLAN with source fd02:30::…; it came back through the UDM and HA's
CNP dropped it (37k POLICY_DENIED to home-assistant:5353 in 24 h). No IPv6
mDNS announcement reached HA. Same tuning as shelly-manager-iot. The
annotation bump re-attaches net1 with the new NAD.
S28-36
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Devices 7, 11, 17, 18, 20, 23 and 28 have MQTT on and reconnect about
once a minute, each refused for lack of an account. Each reboots once
when its password is pushed.
S28-35
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
shelly-manager has MQTT enabled on the device (gen1 mqtt.enable,
mqtt.server mqtt.renner.uno:1883) and the plug reaches the broker, but it
is refused as not authorised: it has no account. With MQTT on, the
controller's push lands and the device reports connected, so it does not
loop on ROTATE_GRACE.
S28-35
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
edge-2's bridge carried only open3e/# as well, with nothing publishing to it
(owner decision 2026-11-07). The mqtt-bridge role is gone entirely.
- delete the role mqtt-bridge and the play install-mqtt-bridge.yml with its
site.yml import and the inventory group mqtt_bridge
- install-edge-host.yml pre_tasks remove the bridge from every edge host:
stop and disable edge-mqtt-cred and mosquitto (if present), delete the unit,
script, /etc/edge-mqtt-cred and /etc/mosquitto, uninstall mosquitto
- group_vars edge_host: drop the local MQTT contract (edge_mqtt_host/port,
edge_open3e_mqtt_user/password) and the mosquitto/edge-mqtt-cred sudo units
- register: drop the account edge-2; controller egress: drop
edge-2.iot.renner.uno:8443
- docs: drop the MQTT bridge section and the vault_edge_open3e_mqtt_password
entry
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Nothing on edge-1 publishes to its loopback mosquitto any more: the CAN stack is
gone (#1595) and vitocal-can publishes open3e/# to the cluster broker itself.
The bridge carried only open3e/# out and open3e/cmnd in.
- mqtt-bridge leaves the edge base play; the new play install-mqtt-bridge.yml
applies it to the inventory group mqtt_bridge (edge-2) and removes it from
every other edge host: stop and disable edge-mqtt-cred and mosquitto, delete
the unit, script, /etc/edge-mqtt-cred and /etc/mosquitto/bridge.d,
uninstall mosquitto
- register: drop the account edge-1 (readwrite open3e/#)
- mqtt-account-controller-egress: drop edge-1.iot.renner.uno:8443
- docs: the bridge runs only on [mqtt_bridge] hosts
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The Viessmann E3 CAN bus is read by vitocal-can, an ESP32 gateway (open3e-esp32)
at the Vitocal's external CAN port, which publishes open3e/# directly to the
cluster broker (S28-28). edge-1 must no longer read the bus: a second UDS
client on the bus disturbs the gateway's requests.
- remove the roles heating-can and socketcan, the play
install-heating-can.yml, its site.yml import and the inventory group
heating_can; edge-1 stays in edge_host through zwave_gateway
- install-edge-host.yml pre_tasks: compose down (containers and image) and
remove /opt/edge-host/heating-can, remove 80-can0.network and reload
networkd, take can0 down; each step is a no-op where it is already absent
- group_vars edge_host: drop edge_open3e_mqtt_topic, used only by heating-can
- docs: edge-host.md and the ISO README no longer list the CAN stack
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Restricting mosquitto to net-iot (#1586) cut off MQTT clients on the
private LAN; policy drops show one on 8883. TLS port only, plaintext
1883 stays IoT-only.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
vitocal-can is a Waveshare ESP32-S3-RS485-CAN running boonkerz/open3e-esp32 on the
Vitocal 250-A's external CAN port. It takes over the open3e/# topics from
the heating-can stack on edge-1 (S28-28).
The controller pushes the password through the firmware's PUT /api/settings
over plain HTTP. The firmware sends its compiled-in DHCP hostname, so the
device is reachable as open3e.iot.renner.uno regardless of its configured
hostname. The controller egress gains that FQDN on port 80.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
common and plays/configure-vm-time-sync.yml masked systemd-timesyncd on
every KVM guest, assuming a Proxmox host supplies the time. The Proxmox
VMs are gone; the only KVM guests left are the Hetzner/netcup VPS hosts,
which have no such host. netbird.renner.uno ran with no NTP client since
provisioning, drifted behind authentik, and NetBird management rejected
SSO tokens with "token used before issued".
Drop both masking paths and add a timesyncd role to the netbird server
and proxy plays; it unmasks, enables and starts systemd-timesyncd and
waits for NTPSynchronized=yes.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Hubble's static exporter writes every POLICY_DENIED drop event to the
cilium-agent stdout, which Alloy already ships to Loki (1 year
retention). That makes denied traffic reviewable after the fact instead
of only for the minutes the Hubble ring buffer holds.
Filter and field mask were checked against the running 1.20.4 agent
with hubble observe --allowlist / --field-mask. The cilium-config change
rolls the agents one at a time via the reloader annotation.
Refs S28-30
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CoreDNS had no policy, so kube-dns-lb answered any source. The new CNP
allows the whole cluster on every port and the internal client networks
on 53/UDP+TCP. Selecting the pods makes them default-deny for ingress.
Refs S28-19
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ftp-scanner and syncthing-sync accepted any world source.
- ftp-scanner: IoT and Privat. Over the last 7 days the vsftpd log shows
uploads from the BR5C scanner via fd02:30:: and the Brother via
10.2.50.170.
- syncthing-sync: Privat and VPN. Over the last 7 days peers connected
from 10.2.50.0/24 and fd02:50::/64.
host and remote-node stay allowed. Both LBs are ETP=Local.
Refs S28-19
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>