Sample entries from production show:
- customers live in ou=customer (singular), not ou=customers
- customers have gidNumber 10004 and staff 10002; uidNumbers are in
the 10000s
- staff entries list organizationalPerson and person explicitly
- the servers serve ldaps:// on port 636
The app reads all of these from settings, so its behaviour is
unchanged; the customer entry it creates already matches production
attribute for attribute. The defaults and test setups were wrong:
env.sample, the Kubernetes ConfigMap (now ldaps:// without StartTLS,
gid 10004, start uid 10000), dev/env.dev and the dev LDAP seed now
mirror production. The made-up ou=groups is gone. The tests take the
customer DN and gidNumber from settings instead of hardcoding them.
deploy/k8s/dev runs the base with 2 replicas alongside throwaway
services: two independent OpenLDAP servers (the dev image), PostgreSQL
18 and Mailpit.
deploy/k8s/dev/e2e.sh checks a running deployment: both probes,
registration with the activation mail sent over SMTP (and no password
in it), activation, login, and login and readiness while ldap1 is
scaled to zero. All checks pass.
