Grouper Users - Open Discussion List

[Scott Koranda <>]

Hi,

Apologies for the long note. 

I have two further issues and questions regarding ldappc
provisioning. After the long introductions with details the
questions begin with

Q1)

and 

Q2)

----------------------------------------

Recall that I was having problems with ldappc provisioning the
isMemberOf attribute.

I cleaned up the Grouper/LDAP synchronization by removing the
isMemberOf attributes from the LDAP server for DNs where the
attribute had become "confused" and then ran ldappc through a
full cycle using this command:

./bin/gsh.sh -ldappc -subject GrouperSystem -groups -memberships 
-configManager /opt/grouper/ldappc/grouper/conf/ldappc.xml 

I then ran it through three more cycles and each time I looked
at the file created by ldappc for updates to the LDAP server
and saw that they were empty. This makes sense since no
changes were made to Grouper. So I believe at this time
Grouper and the LDAP server were in sync and ldappc was
provisioning correctly.

I then added a subject to a group directly, and by that
membership to another group indirectly.

After running ldappc through one provisioning cycle I saw it
generate this file for recording updates to the LDAP server:

employeeNumber=882,ou=people,dc=ligo,dc=org     1 
Communities:LVC:LSC:MOU:UWM:UWMCouncilMembers

The group on the right is the group to which I added the
subject--the direct membership. 

I verified in the LDAP server that the isMemberOf attribute
now contained this extra membership entry.

I then ran ldappc again through a single full cycle and it
generated this file for updates:

employeeNumber=882,ou=people,dc=ligo,dc=org     1 
Communities:LVC:LSC:Council:LSCCouncil

The group on the right is the group to which I added the
subject by an indirect membership.

Again I verified in the LDAP server that the isMemberOf
attribute now contained this extra membership entry for the
indirect membership. At this point the isMemberOf attribute
for this subject was a complete representation of the
memberships (both direct and indirect) in Grouper.

So after adding the user to a group directly and another group
indirectly it took *two* full ldappc provisioning cycles for
the isMemberOf attribute to be correct.

I then removed the subject from the Group UWMCouncilMembers
(the direct membership).

I ran ldappc through a full cycle and it generated this file
for updates:

employeeNumber=882,ou=people,dc=ligo,dc=org     3 
Communities:LVC:LSC:MOU:UWM:UWMCouncilMembers

Another cycle generated this file:

employeeNumber=882,ou=people,dc=ligo,dc=org     3 
Communities:LVC:LSC:Council:LSCCouncil

So again after *two* full ldappc provisioning cycles the
isMemberOf attribute is correct.

Q1) Is this the expected behavior that it takes two cycles for
an indirect membership to be provisioned?

My ldappc configuration is attached. I would be grateful if
the experts could look for dumb mistakes that perhaps cause
two cycles to be necessary?

I am particularly interested to know if my
<source-subject-identifier> for source="g:gsa" is correct.

-----------------------------------------------

With Grouper and the LDAP server in sync again I then started
ldappc using the -interval option:

./bin/gsh.sh -ldappc -subject GrouperSystem -groups -memberships 
-configManager /opt/grouper/ldappc/grouper/conf/ldappc.xml -interval 60

Next, I then created a new group and added a user to it. ldappc created
this file for recording updates to the LDAP server:

employeeNumber=882,ou=people,dc=ligo,dc=org     2 
Communities:LVC:LSC:MOU:UWM:UWMPions

About 3 minutes later ldappc created this file for updates to the
LDAP server:

employeeNumber=882,ou=people,dc=ligo,dc=org     1 
Communities:LVC:LSC:CompComm:AuthProject:AuthProjectGroupMembers
employeeNumber=882,ou=people,dc=ligo,dc=org     1 
Communities:LVC:LSC:CompComm:CompCommGroupMembers
employeeNumber=882,ou=people,dc=ligo,dc=org     1 
Communities:LVC:LSC:LSCGroupMembers
employeeNumber=882,ou=people,dc=ligo,dc=org     1 
Communities:LVC:LSC:MOU:UWM:UWMGroupMembers
employeeNumber=882,ou=people,dc=ligo,dc=org     1 
Communities:LVC:LVCGroupMembers
employeeNumber=882,ou=people,dc=ligo,dc=org     2 
Communities:LVC:LSC:MOU:UWM:UWMSupportStaff

Again about 3 minutes later ldappc create this file for
updates:

employeeNumber=882,ou=people,dc=ligo,dc=org     1 
Communities:LVC:LSC:CompComm:AuthProject:AuthProjectGroupMembers
employeeNumber=882,ou=people,dc=ligo,dc=org     1 
Communities:LVC:LSC:CompComm:CompCommGroupMembers
employeeNumber=882,ou=people,dc=ligo,dc=org     1 
Communities:LVC:LSC:LSCGroupMembers
employeeNumber=882,ou=people,dc=ligo,dc=org     1 
Communities:LVC:LSC:MOU:UWM:UWMGroupMembers
employeeNumber=882,ou=people,dc=ligo,dc=org     1 
Communities:LVC:LVCGroupMembers
employeeNumber=882,ou=people,dc=ligo,dc=org     2 
Communities:LVC:LSC:MOU:UWM:UWMPions

This cycle continues on and on.

What I see when querying the LDAP server, however, is that the
isMemberOf attribute for employeeNumber=882 is oscillating
between

isMemberOf: Communities:LVC:LSC:MOU:UWM:UWMSupportStaff

and

isMemberOf: Communities:LVC:LSC:MOU:UWM:UWMPions

Information about the other group membership is "lost" in the
LDAP server.

So it appears that when running with the -interval option bug
GRP-227 is easily tickled:

https://bugs.internet2.edu/jira/browse/GRP-227

I think this is a different failure mode then what is reported
in that bug report because only ldappc had done any
provisioning and each provisioning cycle had run to completion
(at least, no errors were reported and the ldappc process kept
running).

Q2) Is ldappc with -interval fundamentally broken? Or again is
it perhaps my configuration that is broken?

Thanks,

Scott

Attachment: ldappc.xml
Description: application/xml