Grouper Users - Open Discussion List

[Julian Williams <>]

Thanks David,

 

Yes I did anticipate that we would get problems if the subject/entries weren’t in the same LDAP directory that we’re provision the groups to. That is why we have a copy of the person entries in the target that we are provisioning to and in my limited testing so far I have only been using groups with person entries that I know exist in this ‘copy’. This is only a peculiarity of our test environment and once we get to production yes we’re intending to use the same directory for both subjects and groups.

 

Just to rule out whether the problem *was* caused by having separate LDAP source & target, as a test yesterday I changed the configuration so that we use the same local directory for both (although still using different connectors in Grouper - one via sources.xml for the subject API and one via Spring/vtldap for the PSP ). However I still get the same schema error reported below L.

 

Yes I realise that Grouper is concerned with managing groups but in the configuration that I was trying it is also attempting to update the ‘memberOf’, ‘isMemberOf’ and ‘objectClass’ of the subject/person entry in LDAP which looks like the bit that is throwing this error (although as I say it doesn’t happen when trying to update a subject that doesn’t already have the eduMember objectClass). To avoid the PSP having to touch the  subject/person entries at all I’m next going to try it using an OpenLDAP overlay so that OpenLDAP keeps the memberOf attributes in sync and hopefully I’ll fair better.

 

Yes I agree that configuring PSP is a bit of a beast, a pig in fact! We are considering using alternatives (including something like CMU’s GAP) but need to get something working that we can demonstrate in the very near future so the pressures on.

 

Cheers,

Julian

 

--

Julian Williams (Identity and Access Management Developer)

Systems Development and Support, IT Services, University of Oxford

 

From: David Vezzani [mailto:]
Sent: 07 October 2014 23:07
To: Julian Williams
Cc:
Subject: Re: [grouper-users] Schema error when provisioning using PSP

 

Julian,

 

We had spent some time evaluating Grouper to see if it would suffice for our needs.

 

As it was explained to me, if the source and target sources are different, you will need to have a different tool synchronize the subject entries that are in the source with those in the target.  From Grouper’s perspective, it is my current understanding that Grouper will expect that the source and destination data targets already share the same subject entries.  Grouper is concerned with managing groups, not in creating subjects.

 

When you analyze the Grouper tables, the only values associated with the source target subjects are the DN value and the source id (whether it came from an ldap, jdbc, or some other type of data store).  The rest of a subject’s attributes reside in both the source and destination data targets.

 

And if Grouper PSP is used to add a subject to a group’s membership and the subject doesn’t exist in the destination target, you will be seeing errors like you described.

 

loader ran successfully: Error: PSP Consumer 'psp' - An error occurred processing sequence number 2835278, sequenceNumber: 2835278, edu.internet2.middleware.psp.PspException: SearchResponse[psos=0,status=failure,error=customError,errorMessages={Unable to determine schema entity for oakPrimaryPersonID=91677,ou=people,dc=oak,dc=ox,dc=ac,dc=uk},requestID=2014/10/07-12:58:59.671]

 

Also, I’m not sure if Grouper can be used to update subject attributes.  Again, it focuses on group management and leaves subject management up to the individual source and destination targets.

 

Or perhaps running PSP in this way doesn’t have the ability to update the person entries?

 

There is no question in my mind that PSP configuration is a beast.  The plans for the tool that will be replacing PSP (https://spaces.internet2.edu/display/Grouper/Post+PSP+Provisioning) indicate that a simplification of the configuration will be one of the most significant features and flexibility may be provided by custom Java code.  Nothing is set in stone yet, but there seems to be great optimism for the efforts being made.

 

David Vezzani

(c) 209-756-9688

(o) 209-228-4516

 

 

 

On Oct 7, 2014, at 8:07 AM, Julian Williams <> wrote:

Hi,

 

I’ve been looking at the PSP over the last few days and trying to get something working for our test/dev environment. We’re now using Grouper 2.2 (and PSP 2.2). We have a subject source LDAP (our Live OpenLDAP directory) that is different from the one that we’re provisioning Grouper groups to (an instance of OpenLDAP local to Grouper). However the latter does also have people entries copied from the former. Our LDAP schema is non-standard, in particular the person entries have objectclass’ of ‘eduPerson’, and a locally defined ‘oakPerson’ (but no eduMember).

 

I’ve encountered the following problems when trying to provision groups (so far without a memberof overlay running on OpenLDAP):

 

1. When adding or deleting a member from a group and getting the PSP to detect the change via the changelog

i.e. running the following using gsh:

gsh % loaderRunOneJob("CHANGE_LOG_changeLogTempToChangeLog")

gsh % loaderRunOneJob("CHANGE_LOG_consumer_psp")

 

I get:

 

loader ran successfully: Error: PSP Consumer 'psp' - An error occurred processing sequence number 2835278, sequenceNumber: 2835278, edu.internet2.middleware.psp.PspException: SearchResponse[psos=0,status=failure,error=customError,errorMessages={Unable to determine schema entity for oakPrimaryPersonID=91677,ou=people,dc=oak,dc=ox,dc=ac,dc=uk},requestID=2014/10/07-12:58:59.671]

     at edu.internet2.middleware.psp.Psp.hasAttribute(Psp.java:2046)

...

 

In this case the ‘oakPrimaryPersonID=91677,ou=people,dc=oak,dc=ox,dc=ac,dc=uk’ is the DN of the person I have deleted from the group.

I was wondering whether it was complaining about the schema because we use a non-standard ‘oakPerson’ objectclass on the person entries, and if so how do I tell PSP about it so it doesn’t complain?

 

However I don’t see the error if I add a member that has not been touched by the PSP yet (i.e. doesn’t have the ‘eduMember’ objectClass). But I do get the error if I try and add any member (to any group) that already has the ‘eduMember’ objectClass.

 

2. Interestingly if I run a full sync on the group by doing something like  ‘gsh -psp -sync oucs0175-01:testgroup3’ it completes without error and appears to update the group correctly. However it doesn’t attempt to update the ‘memberOf’ or ‘isMemberOf’ on the person entry which I was expecting it to. Is this something that only happens when the PSP is monitoring for changes via the changelog or have I got something missing from my psp config perhaps? Or perhaps running PSP in this way doesn’t have the ability to update the person entries?

 

I suspect that I have made a mistake in the config whilst taking the examples and adapting for our environment (I initially took the examples from the ‘Grouper to OpenLDAP Multiple’ example). I haven’t attached my psp config files but let me know if that would be useful and I will send in a follow-up.

 

I will be grateful for any help you can give.

 

Cheers,

 

Julian

 

 

--

Julian Williams (Identity and Access Management Developer)

Systems Development and Support, IT Services, University of Oxford