Grouper Users - Open Discussion List

[Tom Zeller <>]

>> > Hi,
>> >
>> > I have ldappc-ng running continuously with these arguments:
>> >
>> > gsh.sh -ldappcng -bulkSync -interval 180
>> >
>> > I then removed a subject from group. In LDAP the group's
>> > hasMember and member attributes were updated correctly to
>> > reflect that the subject was removed from the group.
>> >
>> > The isMemberOf attribute for the subject's DN, however, has
>> > not been appropriately de-provisioned.
>> >
>> > If I leave ldappc-ng running but fire up another process I can
>> > see that it thinks it should be de-provisioned:
>> >
>> > $:/opt/grouper/grouper# sudo -u tomcat6 ./bin/gsh.sh -ldappcng -diff 
>> > 
>> > Using GROUPER_HOME: /opt/grouper/grouper.api-1.6.3
>> > Using GROUPER_CONF: /opt/grouper/grouper.api-1.6.3/conf
>> > Using JAVA: java
>> > using MEMORY: 64m-512m
>> > Grouper starting up: version: 1.6.3, build date: 2011/01/28 14:16:16, 
>> > env: production
>> > grouper.properties read from: 
>> > /opt/grouper/grouper.api-1.6.3/conf/grouper.properties
>> > Grouper current directory is: /opt/grouper/grouper.api-1.6.3
>> > log4j.properties read from: 
>> > /opt/grouper/grouper.api-1.6.3/conf/log4j.properties
>> > Grouper logs are not using log4j: class 
>> > org.apache.commons.logging.impl.SLF4JLocationAwareLog
>> > grouper.hibernate.properties:
>> > /opt/grouper/grouper.api-1.6.3/conf/grouper.hibernate.properties
>> > grouper.hibernate.properties:
>> > grouper@jdbc:mysql://localhost:3306/grouper
>> > sources.xml read from:
>> > /opt/grouper/grouper.api-1.6.3/conf/sources.xml
>> > sources.xml groupersource id: g:gsa
>> > sources.xml jndi source id:   ligo:
>> > uid=grouper,ou=system,dc=ligo,dc=org@ldap://ldap-test.ligo.org
>> > <ldappc:diffResponse
>> > xmlns:ldappc='http://grouper.internet2.edu/ldappc'
>> > status='success' requestID='2011/04/05-20:26:26.877_QWFZE3IS'>
>> >  <modifyRequest xmlns='urn:oasis:names:tc:SPML:2:0'
>> > entityName='member'
>> > requestID='2011/04/05-20:26:27.095_QWFZE3I0'
>> > returnData='everything'>
>> >    <psoID ID='employeenumber=882,ou=people,dc=ligo,dc=org'
>> > targetID='ldap'/>
>> >    <modification modificationMode='delete'>
>> >      <dsml:modification
>> > xmlns:dsml='urn:oasis:names:tc:DSML:2:0:core'
>> > name='isMemberOf' operation='delete'>
>> >        
>> > <dsml:value>Communities:LVC:LSC:MOU:UWM:UWMGroupMembers</dsml:value>
>> >      </dsml:modification>
>> >    </modification>
>> >  </modifyRequest>
>> >  <ldappc:id 
>> > '/>
>> > </ldappc:diffResponse>
>> >
>> > But after watching 5 cycles go by for the ldappc-ng running
>> > with interval 180 I still do not see the isMemberOf attribute
>> > being deprovisioned:
>> >
>> > $ ldapsearch -x -LLL -b "dc=ligo,dc=org" -H ldap://ldap-test.ligo.org 
>> > "(uid=scott.koranda)" isMemberOf | grep UWMGroupMembers
>> > isMemberOf: Communities:LVC:LSC:MOU:UWM:UWMGroupMembers
>> >
>> > In ldappcng.xml I have this for object 'member':
>> >
>> >    <object id="member">
>> >      <identifier ref="member-dn" baseId="${peopleOU}">
>> >        <identifyingAttribute name="objectClass" value="person" />
>> >      </identifier>
>> >      <attribute name="objectClass" ref="member-objectclass" 
>> > retainAll="true" />
>> >      <attribute name="isMemberOf" ref="memberIsMemberOf" />
>> >    </object>
>> >
>> > Any ideas?
>>
>> Bug. The -interval option selects groups that have been changed during
>> the specified interval for provisioning as well as their members. If a
>> member has been removed, it is no longer considered for provisioning.
>
> Thanks for the update.
>
>>
>> I see 3 options :
>>
>> 1. support incremental provisioning (we are actively figuring this
>> out, no code yet)
>> 2. When using -interval, do a full sync at some configurable interval, say 
>> 24h
>> 3. support Member.lastModifyTime (and Stem.lastModifyTime, etc)
>
> Unfortunately since we use isMemberOf attributes on users for
> important authorization decisions I cannot have a latency of
> 24 hours. I really need an operational latency of < 15 minutes.
>
>>
>> I think #2 might be realistic in the short term.
>
> Is there any path forward that could get me a latency of < 15
> minutes in the short term other than running a full sync
> (which takes just about 15 minutes for us) in the next few
> days?
>
> Or do I have to revert back to ldappc (no ng) for the time
> being? Can that be done with Grouper 1.6.3?

You can revert to ldappc (no ng), whose code is the same as it was in
1.5, however, I would like to see you stay with ng.

I have uncommitted changes which help performance. They require some
configuration changes, so it will take me some time to work through
the release process, but if you are not using the new attribute
framework then you can run the improved code without changing your
configuration. Are you interested ?

Let me look at -interval <last_modify_time> [<full_sync_interval>] and
see how much work it is ...