Norbert Püschel wrote:
Am 30.12.10 18:28, schrieb Howard Chu:
norbert@pueschel.net wrote:
Updated TAR-file with (hopefully) sufficient copyright notice...
http://www.pueschel.net/openldap/norbert-pueschel-autogroup-27102010.tar
Your code does a string compare againset "memberOf" to detect those filter references.
- it should simply be comparing the AttributeDescription pointers
- since the "memberof" attribute is actually configurable in the
memberof overlay, there's no guarantee that this is the correct attribute to be looking for. It should also be configurable in your patch.
You are right, of course. The problem is, I do not understand enough of internal structures to find the correct pointer... I would need to detect the memberof-overlay and find the correct string or pointer to compare to. I will gladly do so if you can give me some hints where to look.
AttributeDescriptions are a fundamental data structure used throughout the code. It would be impossible to have read any of the existing overlay code without encountering countless examples of their use.
There is no need to detect the memberof overlay. All you need to do is provide a configuration option to specify the attribute you are going to treat as a memberof attribute.
You're using strcasecmp, but your inputs are already normalized values. You should just use ber_bvcmp.
Right, see above.
Replying to the original:
- Using non-DN-valued URIs for autogroup does not work correctly, even
with the latest version from HEAD. Especially changing group member is not tracked.
I don't see why this should ever work or be supported. LDAP groups list DNs.
Wrong. If you really think so, why did you accept Raphael Ouazana's patch, which is all about making this case work? Also see below.
- Using the memberOf-overlay for constructing autogroups does not work
I don't see any reason why this should work. The memberof overlay is not used to construct groups, it is only used to report on group memberships that have already been defined.
Well, consider the following construction (which I am using in our ldap directory and which is the reason I started work on the autogroup overlay):
Ugh.
dn: cn=admins,ou=access,dc=networker-gmbh,dc=de objectClass: groupOfNames cn: admins member: uid=xxxxx,ou=people,dc=networker-gmbh,dc=de member: uid=yyyyyy,ou=people,dc=networker-gmbh,dc=de
dn: cn=admins@networker-gmbh.de,ou=aliases,dc=networker-gmbh,dc=de objectClass: nisMailAlias objectClass: labeledURIObject cn: admins@networker-gmbh.de labeledURI: ldap:///ou=people,dc=networker-gmbh,dc=de?mail?one?(&(objectClass=inetOrgPerson)(memberOf=cn=admins,ou=access,dc=networker-gmbh,dc=de))
dn: cn=admins,ou=groups,dc=networker-gmbh,dc=de objectClass: posixGroup objectClass: labeledURIObject cn: admins gidNumber: 10100 labeledURI: ldap:///ou=people,dc=networker-gmbh,dc=de?uid?one?(&(objectClass=posixAccount)(memberOf=cn=admins,ou=access,dc=networker-gmbh,dc=de))
Additionally, consider this relevant excerpt from slapd.conf:
overlay dynlist dynlist-attrset groupOfNames labeledURI member dynlist-attrset nisMailAlias labeledURI rfc822MailMember:mail
overlay autogroup autogroup-attrset posixGroup labeledURI memberUid
As you can see, I use memberOf the construct mail aliases and posix group memberships from a groupOfNames master-list. For the mail aliases, dyngroup is sufficient, but the posix groups also need reverse lookups, which is why I'm using the autogroup overlay for this. Also, I cannot use a dn-valued list for the posix groups, as the Solaris NSS-libraries require the uid attribute to not contain a full dn.
Short answer - use an NSS client that actually supports RFC2307bis, like every other vendor in the world already does.
In the meantime, if you submit a cleaned up patch that makes better use of the slapd APIs, we can review it again.