[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: memberOf does not Update on Group Modify
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
--
Dipl.-Inform. Robert Henjes
University of Wuerzburg,
Institute of Computer Science,
Chair of Distributed Systems (Informatik III),
Am Hubland, 97074 Wuerzburg, Germany
henjes@informatik.uni-wuerzburg.de
Tel: +49 931 31-86652
Fax: +49 931 888-6632