[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: memberOf does not Update on Group Modify


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:

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

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

Best regards,
Dipl.-Inform. Robert Henjes
University of Wuerzburg,
Institute of Computer Science,
Chair of Distributed Systems (Informatik III),
Am Hubland, 97074 Wuerzburg, Germany

Tel: +49 931 31-86652
Fax: +49 931 888-6632