Files
bf-infra/routeros/tp28-ap3-service-accounts.rsc
Christoph Emsenhuber 1006f91e6a TP28: ap3 (cAP ax) live als CAP, ap1 funkstill, Compliance 130/130 ueber 5 Geraete
Der dritte Access-Point laeuft: 10.40.99.13 auf vlan99, Uplink ether1 -> core ether21,
reiner CAP unter crs326-core, Kanaele 5180/ax/Ce/I und 2437/ax (ch6) -- am Geraet
nachgemessen, nicht aus dem Plan abgeschrieben. Der Kanalplan stammt aus TP25 vom
2026-08-24; mein erster Entwurf hatte ihn neu erfunden und waere bei ch1 statt ch6
gelandet. Lehre: den TP-Body lesen, nicht nur den Quick-Index.

ap1 hat bewusst KEINE Provisioning-Regel mehr: es steht bis zu seinem Umzug ans
Sideboard direkt neben ap3 und wuerde auf 5180 kollidieren. Geraet bleibt erreichbar,
die Objekte ch-*-ap1 / cfg-main-*-ap1 bleiben fuer den Umzug stehen.

Bring-up in zwei Phasen ueber ein Patchkabel ap3 ether2 -> core ether22, weil ueber
ether1 nichts ging (s.u.). Loop-Schutz: ether21 war waehrend Phase 1 abgeschaltet und
wurde im selben Befehl gegen ether22 getauscht. RouterOS 7.20.8 -> 7.24.1 plus
RouterBOOT (zwei Reboots, TP27-Kriterium erfuellt). Die anderen vier stehen auf 7.24 --
die Angleichung ist ein eigener Durchgang, der Core-Reboot ist ein Standort-Ausfall.

Nautobot: DeviceType "cAP ax", Device ap3 mit 16 Interfaces, primary_ip4, secrets_group,
ConfigContext 5g=ch36 2g=ch6 extra_ports=[]. Nebenkorrektur: ap1 stand auf "Wohnzimmer
Sideboard", steht physisch aber in Technik UG (User-Bestaetigung).

Sechs Funde, alle als Gotcha in CLAUDE.md und im Handoff:
- ether1 ist am Werksgeraet WAN: Discovery aus, Input-TCP verworfen, ICMP aber erlaubt.
  Es pingt, und das liest sich wie "erreichbar". MikroMCP hilft nicht -- Port 80 ist zu.
- pvid ist Ingress, tagged/untagged ist Egress. Ein Lease hing ewig auf "offered", weil
  der ACK getaggt rausging und ein Werksgeraet das nicht versteht.
- `cap enabled=yes` reicht nicht: jedes Master-Radio braucht configuration.manager=capsman,
  sonst bietet der CAP seine Radios gar nicht an -- state=Ok, radio-Tabelle leer.
- Ein Geraet ohne secrets_group erzeugt eine LUECKE, keine Fehlermeldung: Backup scheitert
  still, keine Compliance-Eintraege, Zahl bleibt unauffaellig bei 104/104. Eine
  gleichbleibende Compliance-Zahl nach dem Hinzufuegen eines Geraets ist ein BEFUND.
- CAPsMAN verteilt keine Login-Passwoerter, nur WLAN-PSKs. Der Geraete-Login ist eine
  lokale DB pro Geraet; das einheitliche Admin-PW ist eine Konvention von Hand.
- Firewall-Regelnummern aus `print where` sind Handles, keine Positionen. Beweis ist der
  Zaehler, nicht die Zahl.

Abnahme: 3 CAPs state=Ok, VAP-Satz vollstaendig und running, 20 IOT-Clients auf ap3 mit
0 % Ping-Verlust ueber VLAN30 (bewusst nicht ueber die Registration-Table abgenommen),
Compliance 130/130 / 0 Drifts, Core-Temp-Pfad restlos abgeraeumt.

Offen: TP25-Messrunde (braucht Rundgang), PW-Rotation TP30, MikroMCP-Neustart.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-30 17:54:07 +02:00

37 lines
2.5 KiB
Plaintext

# =====================================================================================
# ap3 — dedizierte Service-Accounts nachziehen. TP28-Nachtrag, 2026-08-30.
#
# BEFUND: nach dem Bring-up rendert Golden Config die intended config fuer ap3 sauber,
# aber der BACKUP-Job scheitert -- Nautobot kommt per SSH nicht auf das Geraet. Ursache
# ist kein Netz- und kein Firewall-Problem: ap1/ap2/core/branch tragen seit TP-PWD
# (2026-08-23) dedizierte Service-Accounts `nautobot` und `ha`, ein Werksgeraet hat nur
# `admin`. Ohne den User gibt es kein Backup, ohne Backup keine Compliance-Eintraege --
# und die Gesamtzahl bleibt unauffaellig bei 104/104, weil ein Geraet ohne Ergebnisse
# eben auch keine Drift meldet. 🔴 Merkregel: eine gleichbleibende Compliance-Zahl nach
# dem Hinzufuegen eines Geraets ist ein BEFUND, kein Erfolg.
#
# Policies 1:1 von ap1 uebernommen (live gelesen, nicht abgeschrieben):
# grp-ha = read,test,api,rest-api + alles andere explizit aus
# grp-nautobot = ssh,read,write,test,sensitive + alles andere explizit aus
# (write, weil Golden Config auch deployen koennen muss)
#
# `__HA_PW__` / `__NB_PW__` sind PLATZHALTER. Die echte Datei wird zur Laufzeit aus
# ~/.secrets/credentials.env (MIKROTIK_HA_PASS / MIKROTIK_NAUTOBOT_PASS) ins Scratchpad
# generiert und danach geloescht -- die Werte stehen nie in diesem Repo.
# =====================================================================================
:if ([:len [/user group find where name="grp-ha"]]=0) do={
/user group add name=grp-ha policy=read,test,api,rest-api,!local,!telnet,!ssh,!ftp,!reboot,!write,!policy,!winbox,!password,!web,!sniff,!sensitive,!romon
}
:if ([:len [/user group find where name="grp-nautobot"]]=0) do={
/user group add name=grp-nautobot policy=ssh,read,write,test,sensitive,!local,!telnet,!ftp,!reboot,!policy,!winbox,!password,!web,!sniff,!api,!romon,!rest-api
}
:if ([:len [/user find where name="ha"]]=0) do={
/user add name=ha group=grp-ha password="__HA_PW__" comment="TP-PWD 2026-08-23: dedizierter Service-Account"
} else={ /user set [find name="ha"] group=grp-ha password="__HA_PW__" }
:if ([:len [/user find where name="nautobot"]]=0) do={
/user add name=nautobot group=grp-nautobot password="__NB_PW__" comment="TP-PWD 2026-08-23: dedizierter Service-Account"
} else={ /user set [find name="nautobot"] group=grp-nautobot password="__NB_PW__" }
:log info ("tp28-ap3: service-accounts, users=" . [:tostr [:len [/user find]]] . " groups=" . [:tostr [:len [/user group find]]])