Files
scadaproj/infra/glauth-redundant/README.md
T

59 lines
2.5 KiB
Markdown

# Redundant LDAP test pair (primary + backup "DC")
Two GLAuth containers on the **dev Mac** that simulate the NAM two-DC topology
(`uswap-vdc-nam1`/`nam2`) for exercising `ZB.MOM.WW.Auth.Ldap` **0.2.x
`FallbackServers` sticky failover**. Deliberately local — the shared
`zb-shared-glauth` on `10.100.0.35:3893` serves every other dev stack and must
never be stopped for a drill.
| | container | host port | from a container |
|---|---|---|---|
| primary | `zb-ldap-primary` | `3893` | `host.docker.internal:3893` |
| backup | `zb-ldap-backup` | `3894` | `host.docker.internal:3894` |
Both mount the same `config.toml` — identical directory contents, like a real
replicated pair. It is a copy of [`../glauth/config.toml`](../glauth/config.toml)
with one difference: the serviceaccount password here is the well-known local
value `serviceaccount123` (the shared instance's is rotated out-of-band, SEC-36).
Same users otherwise (`multi-role`/`password`, etc.).
```bash
docker compose up -d # start the pair
```
## Consumer wiring (any of the four apps)
```
Ldap__Server: host.docker.internal # primary
Ldap__Port: "3893"
Ldap__FallbackServers__0: host.docker.internal:3894
Ldap__Transport: None
Ldap__AllowInsecure: "true"
```
Wired consumers (both drilled PASS 2026-08-13):
- `HistorianGateway/docker/docker-compose.yml` (Auth `0.2.1`, dashboard login
enabled). Note its Production-env container needs
`Serilog__WriteTo__0__Name: Console` or it logs **nothing** — the drill's
failover lines would be invisible.
- ScadaBridge docker rig (`docker/central-node-{a,b}/appsettings.Central.json`,
commit `b71fbae3`) — this pair REPLACED the shared `10.100.0.35` GLAuth there,
whose serviceaccount password rotation (SEC-36) had silently broken rig login.
ScadaBridge's `AuthFlowTests` also target `localhost:3893` and pass 5/5 with
the pair up (they skip when it is down).
## Failover drill (verified PASS 2026-08-13 against HistorianGateway)
1. login → served by primary, no warnings
2. `docker stop zb-ldap-primary` → login OK; app logs
`WRN LDAP endpoint …:3893 failed system-side at connect` +
`INF LDAP sticky preference moved to …:3894`
3. `docker start zb-ldap-primary` → login OK, **still served by the backup**
(sticky by design — verified by bind counts: primary got zero new binds)
4. `docker stop zb-ldap-backup` → login OK; warn on `:3894`, sticky moves back
to `:3893`
The sticky preference lives in the app's singleton `LdapAuthService`, so an app
restart resets it to the configured primary.