[Date Prev][Date Next]
Re: (ITS#5760) attribute hiding in rwm overlay
> Yes, sorry i was originally using meta backend & switched to ldap. Although
> openldap seems to accept the DN component, but happily ignore it.
Well, AFAIK it complains. You'll get a warning, unless anything worse
happens: if your DN contains a comma (","), parsing would (correctly) fail.
> Here the correct spelling is "organisation", i forgot to type it "wrong" for
> openldap :P
You know, Oscar Wilde wrote that US and UK (and the Commonwealth, I
presume) have lots in common, except language :)
> Just tried, the fix works perfectly with database meta, overlay rwm, and
> rwm-map :
> However, there is also a similar problem with database meta, and map :
> database meta
> suffix "c=AU"
> uri "ldap://127.0.0.1 <http://127.0.0.1:390/c=AU>:390/c=AU"
> When i run the above i get :
> ldapsearch -H ldap://127.0.0.1 <http://127.0.0.1:390/c=AU>: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
> entryDN: cn=test00496,ou=support,o=openldap,c=AU
> subschemaSubentry: cn=Subschema
> # search result
> search: 2
> result: 0 Success
> # numResponses: 2
> # numEntries: 1
> Which is not (yet) showing the user attributes, and is leaking some
> un-requested operational attributes.
The missing operational attrs are my fault: I erroneously tested
back-meta with slapo-rwm's mapping, instead of the native one (which may
make sense, but not in your case). This issue should now be fixed in HEAD.
Note that entryDN and subschemaSubentry are not leaked by slapd-meta(5):
they're actually generated by the frontend. This should be prevented
now. Please re-test.
Ing. Pierangelo Masarati
OpenLDAP Core Team
via Dossi, 8 - 27100 Pavia - ITALIA
Office: +39 02 23998309
Mobile: +39 333 4963172
Fax: +39 0382 476497