Cluster access is primarily defined in data.yaml, but additional group membership changes need to be made in LDAP. Having two data sources to edit causes overhead and is error-prone wrt stale data.
One way to solve this is to make data.yaml the authoritative source and auto-generate LDIFs based on changes made to data.yaml. These could then be merged/applied during the puppet-merge step (as long as the change touches modules/admin/data/data.yaml)
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T142815 Enhance account handling (meta bug) | |||
| Declined | None | T142819 Update/add/remove LDAP entries based on changes to data.yaml | |||
| Resolved | jbond | T142821 Synchronise groups defined in data.yaml to LDAP |
I thought all our LDAP groups and all our production server groups were entirely separate?
Mostly, yes. cn=ops can/needs to be kept in sync, though. I have opened T142821 for for the followup work for generic groups.
I'll extend the data.yaml file to also track users with privileged LDAP access (ops or wmf group), but no production shell access. That way we have the same properties on record as for shell access (full name, email address, optional expiry address for non-staff) and the access is properly reviewable/tracked in git.