Grouper Users - Open Discussion List

[Scott Koranda <>]

> >> > 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 

Which attribute framework is that? 

Is it this one?

https://spaces.internet2.edu/display/Grouper/Grouper+attribute+framework

If so, then no, we are not using that in production today,
though we are planning to use it at some point.

> then you can run the improved code without changing your
> configuration. Are you interested ?

Yes, thanks.

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

Thanks.

Cheers,

Scott