Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] ldappc + membership

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] ldappc + membership


Chronological Thread 
  • From: Graham Seaman <>
  • To: Kathryn Huxtable <>
  • Cc: "" <>
  • Subject: Re: [grouper-users] ldappc + membership
  • Date: Mon, 09 Jun 2008 14:49:13 +0100

That's great, thanks for such an incredibly quick response!

Graham

Kathryn Huxtable wrote:
Ah. Got it. My code is naively making the assumption that it is managing the attribute and assuming that if no values were found that we must need to add the object class.

This is wrong on several levels, but I understand why my testing didn't uncover the problem. I would have uncovered it if I had removed all the groups from a member and then added one back. (I used the eduMember objectClass.)

I'll note this and get it into the testing suite and I'll also fix it. It shouldnt't take more than a day or two to tag a fix release.

I am so sorry about this.

-K

On Jun 9, 2008, at 8:41 AM, Kathryn Huxtable wrote:

Okay, this is all useful. The particular error being thrown implies that ldappc is attempting to do an "add" operation to add an attribute where the attribute already exists. It may also be thrown when attempting to add a value where the value already exists.

I'll try again to install Fedora DS on my server. Thanks for the link.

On Sun Directory Server and OpenLDAP, which are the main directories I've had much experience with, you can add attribute values to an existing attribute without any problem. I'd be surprised if Fedora DS had different behavior here, but it's always worth checking.

The thing I noticed is that it looked as if it was attempting to add the eduPerson value to the objectClass attribute. It was almost certainly already there. (op = 1 is ADD, op = 2 is REPLACE.) So I'll take a look at that code. There's probably a bug in it that I introduced since I completely replaced the old attribute matching code.

Thanks for trying this out for me,

-K

On Jun 9, 2008, at 4:58 AM, Graham Seaman wrote:

Graham Seaman wrote:

3. I then changed ldappc.xml to use eduPersonEntitlement rather than isMemberOf, expecting the existing value in this field - which is not managed by grouper - to be overwritten (the current value is urn:mace:InCommon:entitlement:common:1). This time ldappc threw an exception as before (plus your diagnostics):
I should have checked: in spite of throwing the exception, it also updated the directory. ldapsearch now shows:

eduPersonEntitlement: testy:ldap1
eduPersonEntitlement: testy:ldap2
isMemberOf: testy:ldap2

Graham





--
Sponsor me from London to Brighton on http://www.justgiving.com/grahamseaman




Archive powered by MHonArc 2.6.16.

Top of Page