Grouper Users - Open Discussion List

[Tom Zeller <>]

I've committed changes to GROUPER_1_4_BRANCH which will hopefully
resolve GRP-227.

Instead of attempting to update attribute values using the ldap
replace operation, ldappc will now only use add and remove operations.

As a side effect, it isn't possible currently to support provisioning
the list-empty-value of memberships, so this option of
members-group-list in ldappc.xml has been removed. I think this will
be OK, and it can be re-visited if necessary.

TomZ

On Wed, Apr 22, 2009 at 12:15 PM, Tom Zeller 
<>
 wrote:
> Yes, Scott, I'm seeing undesirable behavior too...more later.
>
> TomZ
>
> On Wed, Apr 22, 2009 at 12:07 PM, Scott Koranda
> <>
>  wrote:
>>>
>>> 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?
>>>
>>
>> I think -interval in this report is a red herring.
>>
>> I am able to reproduce the error if I just run ldappc through
>> complete cycles without -interval.
>>
>> Specifically if I have Grouper and LDAP synchronized, and then
>> I create a new group and add a subject to it, if I then run
>> ldappc through complete cycles I am able to put it into the
>> same oscillating state described above.
>>
>> Scott
>>
>