Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] ldappcng & capitalization

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] ldappcng & capitalization


Chronological Thread 
  • From: Tom Zeller <>
  • To: Paul Engle <>
  • Cc: "" <>
  • Subject: Re: [grouper-users] ldappcng & capitalization
  • Date: Tue, 27 Sep 2011 07:13:11 -0700 (MST)

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



Archive powered by MHonArc 2.6.16.

Top of Page