kms: document native DNS auto-discovery (no client config needed)
LAN clients with DNS suffix viktorbarzin.lan now activate with zero configuration — Windows queries _vlmcs._tcp.viktorbarzin.lan SRV by default and the chain resolves through vlmcs.viktorbarzin.lan to the new 10.0.20.202 KMS IP. DNS state (Technitium primary, replicated to secondary+tertiary by the existing technitium-zone-sync CronJob every 30 min): - _vlmcs._tcp.viktorbarzin.lan SRV 0 0 1688 vlmcs.viktorbarzin.lan (was: target=kms.viktorbarzin.lan) - vlmcs.viktorbarzin.lan A 10.0.20.202 (added) - kms.viktorbarzin.lan A 10.0.20.200 (unchanged — still the Traefik LB for the user-facing website at kms.viktorbarzin.lan/) vlmcs.viktorbarzin.lan was added as a dedicated KMS-server hostname rather than retargeting kms.viktorbarzin.lan so the LAN-direct website keeps working without depending on hairpin NAT through pfSense. Verified end-to-end on WIN10Pro-DS32 (192.168.1.230): slmgr /ckms → slmgr /ato → "Product activated successfully" with "KMS machine name from DNS: vlmcs.viktorbarzin.lan:1688" and "KMS machine IP address: 10.0.20.202". Real client IP 192.168.1.230 appears in vlmcsd log and in the slack-notifier sent line; second activation within the dedup window correctly increments kms_activations_dedup_skipped_total.
This commit is contained in:
parent
d85b54d89d
commit
0752bd49c8
1 changed files with 14 additions and 0 deletions
|
|
@ -15,6 +15,20 @@ how to tune the rate limit, how to revoke if abused.
|
||||||
the kube-proxy SNAT too). Same pattern mailserver used pre-2026-04-19.
|
the kube-proxy SNAT too). Same pattern mailserver used pre-2026-04-19.
|
||||||
Sharing `10.0.20.200` isn't an option — all 10 services there are
|
Sharing `10.0.20.200` isn't an option — all 10 services there are
|
||||||
ETP=Cluster and MetalLB requires a single ETP per shared IP.
|
ETP=Cluster and MetalLB requires a single ETP per shared IP.
|
||||||
|
- **Native DNS auto-discovery for LAN clients**: any Windows client with
|
||||||
|
DNS suffix `viktorbarzin.lan` activates with zero config — Windows
|
||||||
|
queries `_vlmcs._tcp.viktorbarzin.lan` SRV by default, the SRV target
|
||||||
|
resolves to `vlmcs.viktorbarzin.lan` → `10.0.20.202`, and `slmgr /ato`
|
||||||
|
succeeds. Records:
|
||||||
|
- `_vlmcs._tcp.viktorbarzin.lan` SRV 0 0 1688 vlmcs.viktorbarzin.lan
|
||||||
|
- `vlmcs.viktorbarzin.lan` A `10.0.20.202`
|
||||||
|
- `kms.viktorbarzin.lan` A `10.0.20.200` (Traefik — for the user-facing
|
||||||
|
website at `https://kms.viktorbarzin.lan/`; **not** the KMS server)
|
||||||
|
Manual override (e.g., for clients without the suffix or for clients
|
||||||
|
on the public internet): `slmgr /skms kms.viktorbarzin.me:1688` (WAN
|
||||||
|
path via pfSense forward) or `slmgr /skms 10.0.20.202:1688` (direct).
|
||||||
|
To revert a manually-overridden client back to auto-discovery:
|
||||||
|
`slmgr /ckms`.
|
||||||
- **Pod fluidity**: deployment has `replicas=1` (notifier dedup state is
|
- **Pod fluidity**: deployment has `replicas=1` (notifier dedup state is
|
||||||
per-pod) with no node affinity. TCP readiness/liveness probes on 1688
|
per-pod) with no node affinity. TCP readiness/liveness probes on 1688
|
||||||
gate Pod Ready on the listener actually being up, so MetalLB only
|
gate Pod Ready on the listener actually being up, so MetalLB only
|
||||||
|
|
|
||||||
Loading…
Add table
Add a link
Reference in a new issue