Description
Details
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Resolved | • madhuvishy | T135931 Tool Labs users missing replica.my.cnf (tracking) | |||
| Resolved | scfc | T138102 Some Tools users do not show up in create-dbusers query |
Event Timeline
Most likely, this is not related to LDAP paging because (AFAIUI) that only affects the number of "entries" returned. In this case, there is always only one entry (project-tools), and it is the number of returned attributes that is the problem.
The missing users are all at the end of ldaplist -l group project-tools, so I assume that this is a problem in python3-ldap3 vs. python-ldap that is used by ldaplist.
A naive:
#!/usr/bin/python2 import ldap ds = ldap.initialize('ldap://ldap-labs.eqiad.wikimedia.org:389') ds.binddn = 'cn=proxyagent,ou=profile,dc=wikimedia,dc=org' ds.bindpw = '$passwd' ds.protocol_version = ldap.VERSION3 ds.start_tls_s() ds.simple_bind_s(ds.binddn, ds.bindpw) PosixData = ds.search_s('ou=projects,dc=wikimedia,dc=org', ldap.SCOPE_SUBTREE, '(cn=tools)', ['member'])
also only returns 1063 attributes. So ldapsupportlib seems to do some magic.
The problem stems from the OpenStack migration: Previously, cn=tools,ou=projects,dc=wikimedia,dc=org had the authoritative information about members of a project in addition to cn=project-tools,ou=groups,dc=wikimedia,dc=org. Now, only the latter is updated and the former entry is stale (AFAIUI).
Change 295099 had a related patch set uploaded (by Tim Landscheidt):
labstore: Fix LDAP query for project members
Change 295225 had a related patch set uploaded (by Andrew Bogott):
labstore: Fix LDAP query for project members