Grouper Users - Open Discussion List

[Paul Engle <>]

Greetings,
 I'm running into a vexing problem with ldappcng that I think may be a 
bug. I'm running version 1.6.3 & provisioning into a FedoraDS server. 
Groups are groupOfUniqueNames and the DN of group members are stored as 
uniqueMember values. The problem is that at some point when the provisioner 
was offline, a person was manually entered into LDAP as a quick workaround. 
The DN string was entered as all lowercase: 
uid=foo,ou=people,dc=rice,dc=edu.

Ever since, when the group tries to sync via ldappcng, it fails. In the 
LDAP server logs, it's throwing an attribute exists error for the group 
object.

Running the ldappcng as a one-off diff for that group shows that it wants 
to do an add of "uid=foo,ou=People,dc=rice,dc=edu" and a delete of 
"uid=foo,ou=people,dc=rice,dc=edu" (!)

I can manually delete that uniqueMember value, and the sync works fine. 
BUT, the ldap server is doing some funky caching so the value that actually 
gets stored is still all lowercase. Grr.

I wouldn't have expected a simple case mismatch to have triggered a 
modification event. If that's not a bug, then I would petition that the 
modification order be deletes before adds to avoid hitting the attribute 
exists error on the ldap server.

I'm going to fight with the ldap server some more to see if I can get it to 
forget the lowercase value. Even manually deleteting it and re-adding it 
with uppercase doesn't seem to work, so I know the caching issue is not on 
the grouper side. I think the next step is to just delete the whole group 
object and sync it fresh. Any other suggestions are welcome.


 -paul

--
Paul D. Engle              |  Rice University
Sr. Systems Administrator  |  Information Technology - MS119
(713)348-4702              |  PO Box 1892

            |  Houston, TX 77252-1892

Attachment: pgpexJMcuH1Ir.pgp
Description: PGP signature