8 Commits

Author SHA1 Message Date
b52d6aa49e TP45 Schicht A: Nautobot .30/.31/.32/.34 -> .154/.155/.156/.158
Oktett-Klasse .150-.199 (App-Services). Nautobot gibt damit .30/.31 an
AGH frei. .157 ist gitea, deshalb nimmt redis .158.

- Datenmigration ueber neues nautobot/tp45-ip-move.py: Nautobot verbietet
  das Aendern einer IP nach dem Anlegen -> anlegen/primary_ip4 umhaengen/
  Altobjekt loeschen, in dieser Reihenfolge
- Stack-Redeploy (PUT /api/stacks/203), Caddy-Backend, Core-Literal *24
  ueber GC deployt (Plan 51a90e25) mit Wirksamkeitspruefung am Geraet
- caddy/deploy.sh: push_verified() ersetzt den push||push-Fallback.
  `pct push` meldet Exit 0 AUCH wenn es die Quelle nicht lesen kann, der
  Fallback griff deshalb nie und `caddy validate` pruefte die ALTE Datei
  -> gruene Abnahme bei unveraendertem Zustand (Symptom: 502 bei
  gesundem Backend)
- 39 Referenzen in 28 Dateien mitgezogen; lebende Doku nachgezogen
  (CLAUDE.md, ip-plan.md, cf-tunnel-mapping §0-Kopf, TP16.3/TP31-Prosa)
- GC-Compliance 140/140, 0 Drifts

Neue Funde (TP45-Prosa + CLAUDE.md):
- Die Core-Adressliste `nautobot` wird von GC nirgends gerendert -> ein
  Recovery von null erzeugt einen Core, in den Nautobot nicht mehr per
  SSH kommt. Gleiche Klasse wie die fehlenden DHCP-Reservierungen.
- Regel *24 (Literal) und *28 (Liste) sind Dubletten; der Literal steht
  bei 0 Paketen. Zusammenlegung bleibt offen.
- gc-manual-plan.py: /api/extras/job-log-entries/ liefert 404 (Nautobot
  3.x) -> bei gescheitertem Deploy fehlt die Fehlermeldung.

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-09-21 13:14:35 +02:00
d63dc7bb78 TP34: 420.teilzeitladen.xyz-Caddy-Block wieder entfernt
teilzeitladen.xyz liegt NICHT im emsenhuber.net-CF-Account (live geprueft: der
CF_DNS_API_TOKEN sieht nur die Zone emsenhuber.net, teilzeitladen.xyz count=0).
Damit kann Caddy auf LXC 130 kein DNS-01-Zert fuer den Namen holen -> Dauer-ACME-
Fehlerschleife. 420.teilzeitladen.xyz bleibt beim Cloudflare-Worker (cf-tunnel-mapping §17).

Ein Caddy-Backend fuer 420 braucht einen DNS-Token aus dem teilzeitladen.xyz-CF-Account
(blaueblueten-Projekt) — separat, nicht Teil von bf-infra. Seeder/Renderer bleiben.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-08 13:36:33 +02:00
b200401c5a TP34: 420.teilzeitladen.xyz korrigiert (war terpene.*) + eigener DNS-Token
- caddy/Caddyfile: Hostname 420.teilzeitladen.xyz (nicht terpene.*); eigener
  per-site tls-Block mit CF_DNS_API_TOKEN_TEILZEITLADEN, damit der enge
  emsenhuber.net-ACME-Token unangetastet bleibt (Least-Privilege)
- nautobot/tp34-caddy-cf-seed.py: veraltete terpene.*-Referenz im Kommentar korrigiert

Deploy erst nach Hinterlegen des teilzeitladen.xyz-Tokens in /etc/caddy/caddy.env
(Zone:DNS:Edit nur teilzeitladen.xyz).

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-08 13:30:30 +02:00
384f356290 TP34: terpene Quick-Win + Caddy-CF-Seeder + Renderer
- caddy/Caddyfile: terpene.teilzeitladen.xyz → 10.40.20.167:8890 (Quick-Win Schritt 0)
- nautobot/tp34-caddy-cf-seed.py: legt CustomFields caddy_fqdn/caddy_group auf
  ipam.Service an und setzt Werte fuer die 9 Routen mit vorhandenem Service-Objekt
- nautobot/tp34-caddy-render.py: rendert Caddyfile aus Nautobot, Diff gegen
  caddy/Caddyfile, optionaler Deploy via pct push + caddy reload

Deploy-Auflage fuer den terpene-Block:
  pct push 130 caddy/Caddyfile /etc/caddy/Caddyfile
  ssh root@10.40.20.40 "caddy reload --config /etc/caddy/Caddyfile"
(Plus CF-Tunnel-Route fuer terpene.teilzeitladen.xyz pruefen)

Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
2026-09-08 11:48:18 +02:00
c7e173ec5a TP42-Vorarbeit + TP41 zurückgestellt: interne Namen auf bf.emsenhuber.net
- caddy/Caddyfile: nackte *.emsenhuber.net-Aliase entfernt, nur noch
  *.bf.emsenhuber.net (Split-Horizon, zeigt auf 10.40.20.40)
- nautobot/mikrotik_routeros.j2: DNS-Static *.bf.lan → *.bf.emsenhuber.net,
  router.lan entfernt
- docs/teilprojekte.md: TP41 ⏳→⏸️ (User-Entscheid 2026-09-01, offen nur
  Gelis WARP-Client), Ist-Stand-Block mitgezogen

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-02 02:56:30 +02:00
012397f194 TP41: T4/T3/T2 durch (zt-svc, WARP-intern .36/.37, vw/admin 404 origin); Token-Altlast geklärt; TP42 angelegt
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-09-01 19:19:52 +02:00
1d307721ad TP23 Stufe 2 + TP31 Schritt 4: AdGuard split-horizon mit .bf.-Suffix, Caddyfile .bf.-FQDNs
- AGH 110/111: conditional upstream [/bf.emsenhuber.net/]10.40.20.1
- 47 Rewrites: 16 Service->Caddy (inkl. .bf.), 10 Hosts mit .bf., suffixlose parallel
- Caddyfile: interne Sites mit .bf.-Alias (public vw/hass/n8n/gitea ohne)
- DHCP: alle 7 VLANs zeigen auf .36/.37 (domain=emsenhuber.net)
- Firewall-Regeln auf .36/.37 bereits scharf
- nas.emsenhuber.net endgueltig entfernt (war schon in 1d569fa)
- Ist-Stand-Block + Status-Tabelle nachgezogen
2026-08-26 21:22:39 +02:00
5ee0716dda Initial import from bf-network-r6.opencode — opencode migration 2026-08-26 12:44:21 +02:00