4 Commits

Include renames

Author	SHA1	Message	Date
mats	66f36cfac6	more stuff	2026-10-16 14:49:50 +02:00
matsandClaude Sonnet 5.5	2f25463347	Add fancy-dns-console migrate to convert an existing deployment into cluster objects ... The settings of the ConfigMap-and-YAML deployment have to become objects before the mechanisms that held them can go. The command reads what the old console wrote (the zone--<apex>.zone keys of the zones ConfigMap and the address-overrides RPZ), and optionally the resolver's config.yaml, and converts: zone master files -> DNSZone address-overrides RPZ -> AddressOverride, one per name URL blocklists -> BlockList allow_entries/block_entries -> DomainRule inline-allow / inline-block acl.groups -> ClientGroup By default it only prints manifests, which can be reviewed or committed; -apply creates or updates the objects. It never deletes or edits the ConfigMaps or the config. Each conversion is validated with the code the resolver uses to read the objects, and anything it cannot represent faithfully is listed and left alone: a zone with a record type the API does not write, a list that is a file on the pod, a name that is not a legal object name, an RPZ line that is not an A or AAAA override. Tests apply a conversion of the live data to a fake cluster and read it back through the resolver's source, and run the command against fake ConfigMaps, offline from files, and with the ConfigMaps missing. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>	2026-10-16 10:12:45 +02:00
matsandClaude Sonnet 5.5	88479b9a12	Add AddressOverride and DomainRule objects for what lived in a ConfigMap and the config file ... The address redirects page rewrote an RPZ ConfigMap through the resolver's own service account, and the domains page rewrote allow_entries/block_entries in the config file. Both become cluster objects like the rest. AddressOverride is one name answered with fixed addresses (the name and everything under it), exactly what an RPZ "name A address" line did. DomainRule is a block or allow list of inline names. The resolver reads both with the existing watch: overrides are rendered into the managed RPZ source the blocklist manager already has, and rule names join the config's inline entries in the merged overlay, so the file's config is never written to. Names are checked to be DNS names or wildcard patterns before they are used, because they are joined into line-oriented parser input and a newline or a comment character in one would otherwise add a rule of its own. The console edits both: the address-overrides and domains endpoints now write objects. The console keeps its added rules in one DomainRule per action (inline-block, inline-allow) instead of an object per name, and removes a name from whichever DomainRule holds it, wildcard or not. An end-to-end test drives the pages' endpoints and checks the resolver's answers. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>	2026-10-16 10:08:08 +02:00
matsandClaude Sonnet 5.5	1a536e7d0e	Split the console from the resolver: fancy-dns-console writes the cluster ... fancy-dns-console is a second binary holding the web UI, authentication and every edit. It writes ClientGroup, BlockList and DNSZone objects through the new kubeedit package and forwards all other /api routes to a running resolver with its own key, dropping the browser's credentials, so it can run in the cluster or on a workstation with a kubeconfig and nothing about the resolver's placement matters. The resolver never imports kubeedit and the console is not on the DNS path. kubeedit validates every spec with the runtime's own converters (kubesource.CheckGroup/CheckList/CheckZone) before writing, so the console cannot store an object the resolver would reject. Zone edits keep the file-based writer's behaviour: duplicate and below-a-delegation records are refused, a delegation in a new zone also gives the zone its servers, and a zone with no apex NS is never stored. Each object records the editing user in an annotation; updates retry on conflict. The resolver reports groups from ClientGroup objects as source "kubernetes" and counter-only rows (the "(default)" bucket, or a group removed since) as "history", and lists DNSZone zones as the editable ones. The console uses that to leave the YAML's groups alone and to drop history rows, which the UI would otherwise send back on save. Its GET /api/clients overlays the cluster's current objects on the resolver's list, because the resolver only sees an edit after its watch fires and a save made just after another would delete the first. An end-to-end test runs both halves against one fake apiserver: a group saved through the console refuses queries, a zone built record by record answers authoritatively, and a request with the resolver's own key is rejected by the console. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>	2026-10-16 08:43:41 +02:00