Grouper Users - Open Discussion List

[Tom Zeller <>]

I chose add-first to be compatible with openldap whose default schema 
requires a value to exist for group member attributes, even if there are no 
members.

Maybe add-first / delete-first should be configurable, not sure.

On Sep 27, 2011, at 8:14 AM, Paul Engle 
<>
 wrote:

> 
> Tom,
> Thanks for looking into it. I agree that the ideal solution is a 
> case-sensitivity flag per-attribute for maximum flexibility. As a 
> short-term workaround, doing a delete before add will avoid hitting the 
> error I'm seeing.
> 
> I tried your suggestion of manually removing the entire uniqueMember 
> attribute (all values) from the group this morning. That seems to have 
> bypassed the silly ldap server caching issue I was seeing when deleting a 
> single value. After another sync, the value now has the expected 
> capitalization. So, my specific issue is fixed.
> 
> As always, thanks for the help!
> 
> -paul
> 
> --On Monday, September 26, 2011 5:13 PM -0500 Tom Zeller 
> <>
>  wrote:
> 
>> Looks like all I can offer you right now is a bug report.
>> 
>> The ldap DN canonicalizer transforms
>> 
>> cn=foo,DC=Edu
>> 
>> to
>> 
>> cn=foo,dc=Edu
>> 
>> So this doesn't help you.
>> 
>> As far as modification order, looks like I punted because I wasn't sure
>> 
>> public List<Modification> getReferenceModification() throws
>> Spml2Exception {     // TODO add or delete first ?
>> 
>> Perhaps delete-first is preferable over add-first.
>> 
>> Finally, there should be a case-sensitivity flag on attributes for
>> comparison, but case-sensitivity was not part of the spml spec so I
>> left it out for the time being.
>> 
>> Can you delete the uniqueMember attribute and then sync ?
>> 
>> TomZ
>> 
>> On Mon, Sep 26, 2011 at 4:11 PM, Tom Zeller 
>> <>
>>  wrote:
>>> I took care when comparing DNs to use a canonical representation to
>>> avoid issues with case. I could have made a mistake.
>>> 
>>> I think I have a junit test for this, let me look ...
>>> 
>>> On Mon, Sep 26, 2011 at 4:03 PM, Paul Engle 
>>> <>
>>>  wrote:
>>>> 
>>>> 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
>>> 
>> 
> 
> 
> 
> -- 
> Paul D. Engle              |  Rice University
> Sr. Systems Administrator  |  Information Technology - MS119
> (713)348-4702              |  PO Box 1892
> 
>             |  Houston, TX 77252-1892