Skip to Content.
Sympa Menu

grouper-users - Re: [grouper-users] ldappc-ng and deprovisioning of isMemberOf attribute

Subject: Grouper Users - Open Discussion List

List archive

Re: [grouper-users] ldappc-ng and deprovisioning of isMemberOf attribute


Chronological Thread 
  • From: Tom Zeller <>
  • To: Scott Koranda <>
  • Cc: "" <>
  • Subject: Re: [grouper-users] ldappc-ng and deprovisioning of isMemberOf attribute
  • Date: Wed, 6 Apr 2011 11:41:40 -0500
  • Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=qoefCr/Nd2dElF2UDu16QxYSiP6zI2iGrSs8TZunGIepes9JVHH+XUO2L8s7hEPPqn WIMJFkAXeX5F4zTvOG/c2t1Nq0ks+60+tUSBkOtaDDpP/5lEvDUzrgiZCqVf0cyH/Ufq WkNpykngi+rgal233iofbL6RkA5ZbKLYVnYUo=

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

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)

I think #2 might be realistic in the short term.

...and now I see you added GRP-595, Scott. I agree :-)

TomZ

[1] https://bugs.internet2.edu/jira/browse/GRP-595
[2] https://bugs.internet2.edu/jira/browse/GRP-596



Archive powered by MHonArc 2.6.16.

Top of Page