Hi,
thank you for your reply. I try to be a bit more precise in this post.
I don't see "cn=example,ou=management,ou=groups,dc=domain" among memberOf's of "cn=my.name..." (assuming "..." stands for ",o=...,ou=identities,dc=domain", of course). I've tested the current implementation of slapo-memberof (test52 of the test suite) and I don't see any strange behavior.
Ups sry. I tried to simplify the tree structure, but it ended in an inconsistent example. Try to do it better this time.
You should provide a little bit more info, including your configuration and a clear set of LDIFs that allow to exactly create your database prior to modification, and a modification that results in an incorrect behavior.
Snippet of Configuration (currently using cn=config)
(Loaded schemas: core,cosine,nis,inetorgperson,dyngroup,eduperson,edumember,postfix,openssh-lpk_openldap)
dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModulePath: /usr/lib/ldap olcModuleLoad: {0}back_hdb olcModuleLoad: {1}dynlist olcModuleLoad: {2}memberof
dn: olcOverlay={0}memberof,olcDatabase={1}hdb,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {0}memberof olcMemberOfDangling: ignore olcMemberOfRefInt: FALSE
dn: olcDatabase={1}hdb,cn=config objectClass: olcDatabaseConfig objectClass: olcHdbConfig olcDatabase: {1}hdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=domain olcAccess: {0}to attrs=userPassword by dn.base="cn=admin,dc=domain" write by anonymous auth by self write by * none olcAccess: {1}to dn.base="" by * read olcAccess: {2}to dn.subtree="dc=domain" by dn.base="cn=admin,dc=domain" write by dn.children="ou=system,dc=domain" read by users read by anonymous auth olcAccess: {3}to * by dn.base="cn=admin,dc=domain" write by * none olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcMonitoring: FALSE olcDbCacheSize: 1000 olcDbCheckpoint: 512 30 olcDbConfig: {0}set_cachesize 0 2097152 0 olcDbConfig: {1}set_lk_max_objects 1500 olcDbConfig: {2}set_lk_max_locks 1500 olcDbConfig: {3}set_lk_max_lockers 1500 olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass eq olcDbIndex: uid eq,sub olcDbIndex: memberOf eq olcDbIndex: member eq olcDbLinearIndex: FALSE olcDbMode: 384 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0
(In general I'm using SSL for encryption, skipped that configuration part.)
Back to the example and the original LDIF group and user file:
dn: cn=my.name,ou=identities,dc=domain objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: person objectClass: top objectClass: eduPerson cn: my.name uid: my.name
dn: cn=myadmin,ou=management,ou=groups,dc=domain objectClass: groupOfNames objectClass: top member: cn=default,ou=identities,dc=domain member: cn=my.name,ou=identities,dc=domain cn: myadmin
Adding (using standard ldapadd) this file to the LDAP tree results in a correct set of memberOf values for user cn=my.name,...
Then I'm going to do an ldapmodify and try to remove the member attribute: dn: cn=nmyadmin,ou=management,ou=groups,dc=domain changetype: modify delete: member member: cn=my.name,ou=identities,dc=domain
# ldapmodify -x -W -D cn=admin,dc=domain -f updateMembership.ldif
After repeating the search for cn=my.name this still results in: # ldapsearch -x -D cn=admin,dc=domain -b dc=domain -LLL -W "(cn=my.name)" memberOf
dn: cn=my.name,ou=identities,dc=domain memberOf: cn=admins,ou=groups,dc=domain memberOf: cn=myadmin,ou=management,ou=groups,dc=domain
Also, I note that 2.4.11 is relatively old. If you compare just the memberof.c file between 2.4.11 and 2.4.19 you'll note hundreds of lines of changes.
Yes that's correct. But I'd like to use debian lenny and all it's packets, which is still marked as stable... So I try to avoid handmade adoptions. If it is really necessary, I'll try to specify an extra procedure. Additionally I've read, that most of the memberof overlay changes were related to the syncrepl scenario, which we do not use at the moment. And since the operation I do is very basic, I doubt, that it didn't work in the past, so my assumption is, that I misconfigured or missed anything using the memberOf overlay correctly.
A last assumption... might it be, that the eduMember / eduPerson schema have an influence on the memberOf overlay? https://spaces.internet2.edu/display/macedir/OpenLDAP+eduMember
Best regards, Robert