Hi all,
When I started at this job I acquired OpenLDAP based authentication infrastructure, which I've pretty much been able to leave to its own devices without looking under the hood at what's going on. Recently I've been noticing that a few minor performance problems I'm having seem to be linked to LDAP so I've started looking at how it's set up and it's got some quirks, e.g.
# Indices to maintain index entryUUID eq index cn,sn,uid,displayName pres,sub,eq index uidNumber eq index gidNumber eq index memberUid eq index sambaSID eq index sambaPrimaryGroupSID eq index sambaDomainName eq index sambaGroupType eq index sambaSIDList eq index sudoUser eq index uniqueMember,member eq index objectClass pres,eq index mail,mailAlternateAddress eq,sub index accountStatus eq index mailHost,deliveryMode eq index Status,HostGroup eq index default sub
There are only around 600 users in the ldap tree, hardly anything. It seems a bit excessive to have that many indexes set up for the tree. Is there any way to identify which indexes are being used and how frequently? I'm pretty certain some of those entries probably get checked once in a blue moon.
I'm also seeing odd entries in the ldap logs:
Dec 20 11:21:17 <server> slapd[11171]: <= bdb_equality_candidates: (objectClass) index_param failed (18) Dec 20 11:21:17 <server> slapd[11171]: <= bdb_equality_candidates: (objectClass) index_param failed (18) Dec 20 11:21:17 <server> slapd[11171]: <= bdb_equality_candidates: (gidNumber) index_param failed (18)
Which seems bizarre given those entries are in the list of indexes. I've tried running slapindex and restarting to no avail. Those items still seem to throw up those alerts, as does the sudoUser entry.
On a separate note I've found the slapcat doesn't produce an LDIF file that slapadd will use, even keeping to the same version of software (2.3.37), or importing into newer (2.3.43). It always errors after the first entry because it seems to be trying to add a user to an ou that doesn't exist yet, which disturbs me slightly because the backup infrastructure has been relying on that mechanism for recovery. To create another ldap slave I ended up having to use Apache Directory Studio to create the LDIF for import, which slapadd was perfectly happy to work with. I'm not sure if that may be a known bug that I'm running up against. I see a few entries in archives relating to it but not much by way of response other than suggests it should work.
Paul