Grouper Users - Open Discussion List

[Paul Engle <>]

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

Attachment: pgpuEglLXZWil.pgp
Description: PGP signature