Grouper Users - Open Discussion List

[Kathryn Huxtable <>]

You could do that. It seems like it might be a lot simpler to load  
eduMember.

When I was at KU, we used a different provisioning mechanism, which  
allowed us to specify a string prefix for provisioning. Our  
provisioning would only manage values in the attribute beginning with  
that prefix, leaving other values alone. This enabled us to have  
multiple provisioning mechanisms provisioning into ePentitlement.

Maybe something like this would be useful in ldappc...

-K

On Jun 9, 2008, at 10:45 AM, Graham Seaman wrote:

> Yes, in fact I was thinking of moving existing ePEntitlement values  
> into (slightly artificial) grouper groups so that I could use  
> eduPersonEntitlement for grouper provisioning without losing  
> existing data, and without having to load the eduMember schema  
> (which is not an issue on my little test
> directory, but might be on the live directory)
>
> Graham
>
> Kathryn Huxtable wrote:
> > I meant list-object-class instead of list-attribute below.
> >
> > -K, banging head against wall
> >
> > On Jun 9, 2008, at 9:43 AM, Kathryn Huxtable wrote:
> >
> > > Graham,
> > >
> > > I'm looking at this stuff, and I think you can use  
> > > eduPersonEntitlement (if you don't mind non-Grouper values being  
> > > replaced) by simply not specifying a list-attribute value in your  
> > > ldappc.xml file. This assumes that all the objects you're querying  
> > > in your person tree already have eduPerson. That way it wouldn't  
> > > alter the objectClass values.
> > >
> > > -K, who is still looking at the code.
> > >
> > > On Jun 9, 2008, at 8:49 AM, Graham Seaman wrote:
> > >
> > > > 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
>
>
> --
> Sponsor me from London to Brighton on http://www.justgiving.com/grahamseaman