[email protected] wrote: > --0016e65206024a6d9d0462d5c0d0 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: 7bit > > I have re-tested with recent RE24 and this still happens. > > Assuming the config (database meta, and map instead of rwm-map shows similar > problem) : > > database ldap > suffix "c=AU" > uri "ldap://127.0.0.1:390/c=AU";
You messed things up a little bit: back-ldap does not allow the DN part of the URI. > overlay rwm > > rwm-map attribute cn * > rwm-map attribute sn * > rwm-map attribute givenName * > rwm-map attribute * > > rwm-map objectclass inetOrgPerson * > rwm-map objectclass organisationalUnit * s/organisationalUnit/organizationalUnit/: this raises a warning. > rwm-map objectclass organization * > rwm-map objectclass country * > rwm-map objectclass * > > I have a standard LDAP with standard inetOrgPerson style schemas on ldap:// > 127.0.0.1:390/c=AU with some dummy data, and when i query the source > directory i get sensible results: > > suse:/usr/local/etc/openldap # ldapsearch -H ldap://127.0.0.1:390 -x -b > 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' '*' > # extended LDIF > # > # LDAPv3 > # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree > # filter: (objectclass=*) > # requesting: * > # > > # test00496, support, openldap, AU > dn: cn=test00496,ou=support,o=openldap,c=AU > objectClass: inetOrgPerson > cn: test00496 > givenName: test00496 > uid: test00496 > sn: test00496lname > displayName: test00496 test00496lname > userPassword:: bm92ZWxs > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > When i query the meta directory, i get no attributes (* or + or *,+, in the > requested attributes all return no attributes as below) : > > ldapsearch -H ldap://127.0.0.1:391 -x -b > 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' '*' > # extended LDIF > # > # LDAPv3 > # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree > # filter: (objectclass=*) > # requesting: * > # > > # test00496, support, openldap, AU > dn: cn=test00496,ou=support,o=openldap,c=AU > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > But if i query the meta directory explicitly for some attributes (no * +), > it works, i get : > > ldapsearch -H ldap://127.0.0.1:391 -x -b > 'cn=test00496,ou=support,o=openldap,c=AU' '(objectclass=*)' cn sn firstName > # extended LDIF > # > # LDAPv3 > # base <cn=test00496,ou=support,o=openldap,c=AU> with scope subtree > # filter: (objectclass=*) > # requesting: cn sn firstName > # > > # test00496, support, openldap, AU > dn: cn=test00496,ou=support,o=openldap,c=AU > cn: test00496 > sn: test00496lname > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > So i conclude then that the default attribute lists of *, +, or *,+ are > somehow being lost by backend meta or overlay rwm ? > > Probably * and + (or *,+) should be expanded to the list of user or > administrative attributes (respectively) by meta/rwm first, specifically > those that are allowed by "map attribute" lines, before being handed to the > real directory (helpful to performance if the backend directory has many > attributes, that the meta directory is not interested in). > > This is also why attributes don't appear in a GUI browser for me, if i am > using a GUI browser, as they commonly use *,+ as their default. Well, if you don't request any attribute, those that are mapped appear. I've modified slapo-rwm to pass thru special attribute names ("*", "+", "1.1") in order to defer their mapping when results are returned. This looks simpler than detecting whether non-mapped attrs are filtered and, in tat case, replace "*" by the mapped attributes, although the latter could be an optimization. A fix is in HEAD (affecting back-meta and slapo-rwm independently). Please test. Unfortunately it seems to be too late for OpenLDAP 2.4.14. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Fax: +39 0382 476497 Email: [email protected] -----------------------------------
