--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"
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 * 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.
Cheers Brett
On Sun, Jan 25, 2009 at 12:53 AM, Pierangelo Masarati ando@sys-net.itwrote:
[please reply to the ITS, otherwise issues can't be tracked]
Brett @Google wrote:
HI Ando,
Do you know if the fix for ITS#5760 (says fixed for RE24 and HEAD) make it into RE24 in time for the 2.4.13 release ?
apparently, yes.
If so, i can still see the behaviour here with 2.4.13, i can see
operational attributes, but non non-operational attributes, when mapping both objectclass and attribute..
Bug seems to be focused on using of *, rather than an explicit list of non-operational attrs which works, ie :
I can search for attributes with * ( get all non-operational attributes ) and don't get any non-operational attributes, whereas explicitly adding any non-operational attribute will result i a search returning the named values, which is allowable via the objectclass maps.
seems to work the same (omitting non-oprational attrs), even if i dont specufy the objectclass rwm maps.
Not sure I understand. Can you post simple (both working and not working) examples?
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: ando@sys-net.it
--0016e65206024a6d9d0462d5c0d0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I have re-tested with recent RE24 and this still happens. <br><br>Assuming = the config (database meta, and map instead of rwm-map shows similar problem= ) :<br><br>database ldap<br>suffi= x "c=3DAU"<= br>uri &nb= sp; "ldap://<a href=3D"http://127.0.0.1:390/c=3DAU%22%3E127.0.0.1:390/c=3D= AU</a>"<br> <br>overlay rwm<br><br>rwm-map attribute cn *<br>rwm-map attribute sn *<br>= rwm-map attribute givenName *<br>rwm-map attribute *<br><br>rwm-map objectc= lass inetOrgPerson *<br>rwm-map objectclass organisationalUnit *<br>rwm-map= objectclass organization *<br> rwm-map objectclass country *<br>rwm-map objectclass *<br><br>I have a stan= dard LDAP with standard inetOrgPerson style schemas on ldap://<a href=3D"ht= tp://127.0.0.1:390/c=3DAU">127.0.0.1:390/c=3DAU</a> with some dummy data, a= nd when i query the source directory i get sensible results:<br> <br>suse:/usr/local/etc/openldap # ldapsearch -H ldap://<a href=3D"http://1= 27.0.0.1:390">127.0.0.1:390</a> -x -b 'cn=3Dtest00496,ou=3Dsupport,o=3D= openldap,c=3DAU' '(objectclass=3D*)' '*'<br># extended = LDIF<br> #<br># LDAPv3<br># base <cn=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU= > with scope subtree<br># filter: (objectclass=3D*)<br># requesting: *<b= r>#<br><br># test00496, support, openldap, AU<br>dn: cn=3Dtest00496,ou=3Dsu= pport,o=3Dopenldap,c=3DAU<br> objectClass: inetOrgPerson<br>cn: test00496<br>givenName: test00496<br>uid:= test00496<br>sn: test00496lname<br>displayName: test00496 test00496lname<b= r>userPassword:: bm92ZWxs<br><br># search result<br>search: 2<br>result: 0 = Success<br> <br># numResponses: 2<br># numEntries: 1<br><br>When i query the meta direc= tory, i get no attributes (* or + or *,+, in the requested attributes all r= eturn no attributes as below) :<br><br>ldapsearch -H ldap://<a href=3D"http= ://127.0.0.1:391">127.0.0.1:391</a> -x -b 'cn=3Dtest00496,ou=3Dsupport,= o=3Dopenldap,c=3DAU' '(objectclass=3D*)' '*'<br> # extended LDIF<br>#<br># LDAPv3<br># base <cn=3Dtest00496,ou=3Dsupport,= o=3Dopenldap,c=3DAU> with scope subtree<br># filter: (objectclass=3D*)<b= r># requesting: *<br>#<br><br># test00496, support, openldap, AU<br>dn: cn= =3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU<br> <br># search result<br>search: 2<br>result: 0 Success<br><br># numResponses= : 2<br># numEntries: 1<br><br>But if i query the meta directory explicitly = for some attributes (no * +), it works, i get :<br><br> ldapsearch -H = ldap://<a href=3D"http://127.0.0.1:391%22%3E127.0.0.1:391</a> -x -b 'cn=3Dt= est00496,ou=3Dsupport,o=3Dopenldap,c=3DAU' '(objectclass=3D*)' = cn sn firstName<br> # extended LDIF<br>#<br># LDAPv3<br># base <cn=3Dtest00496,ou=3Dsupport,= o=3Dopenldap,c=3DAU> with scope subtree<br># filter: (objectclass=3D*)<b= r># requesting: cn sn firstName<br>#<br><br># test00496, support, openldap,= AU<br> dn: cn=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU<br>cn: test00496<br>sn:= test00496lname<br><br># search result<br>search: 2<br>result: 0 Success<br=
<br># numResponses: 2<br># numEntries: 1<br><br>So i conclude then that th=
e default attribute lists of *, +, or *,+ are somehow being lost by backend= meta or overlay rwm ?<br> <br>Probably * and + (or *,+) should be expanded to the list of user or adm= inistrative attributes (respectively) by meta/rwm first, specifically those= that are allowed by "map attribute" lines, before being handed t= o the real directory (helpful to performance if the backend directory has m= any attributes, that the meta directory is not interested in).<br> <br>This is also why attributes don't appear in a GUI browser for me, i= f i am using a GUI browser, as they commonly use *,+ as their default.<br><= br>Cheers<br>Brett<br><br><div class=3D"gmail_quote">On Sun, Jan 25, 2009 a= t 12:53 AM, Pierangelo Masarati <span dir=3D"ltr"><<a href=3D"mailto:and= o@sys-net.it">ando@sys-net.it</a>></span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">[please reply to = the ITS, otherwise issues can't be tracked]<div class=3D"Ih2E3d"><br> <br> Brett @Google wrote:<br> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> HI Ando,<br> <br> Do you know if the fix for ITS#5760 (says fixed for RE24 and HEAD) make it<= br> into RE24 in time for the 2.4.13 release ?<br> </blockquote> <br></div> apparently, yes.<div class=3D"Ih2E3d"><br> <br> <blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(204, = 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> If so, i can still see the behaviour here with 2.4.13, i can see operationa= l<br> attributes, but non non-operational attributes, when mapping both<br> objectclass and attribute..<br> <br> Bug seems to be focused on using of *, rather than an explicit list of<br> non-operational attrs which works, ie :<br> <br> I can search for attributes with * ( get all non-operational attributes )<b= r> and don't get any non-operational attributes, whereas explicitly adding= any<br> non-operational attribute will result i a search returning the named values= ,<br> which is allowable via the objectclass maps.<br> <br> seems to work the same (omitting non-oprational attrs), even if i dont<br> specufy the objectclass rwm maps.<br> </blockquote> <br></div> Not sure I understand. Can you post simple (both working and not work= ing) examples?<div><div></div><div class=3D"Wj3C7c"><br> <br> p.<br> <br> <br> Ing. Pierangelo Masarati<br> OpenLDAP Core Team<br> <br> SysNet s.r.l.<br> via Dossi, 8 - 27100 Pavia - ITALIA<br> <a href=3D"http://www.sys-net.it" target=3D"_blank">http://www.sys-net.it</= a><br> -----------------------------------<br> Office: +39 02 23998309<br> Mobile: +39 333 4963172<br> Fax: +39 0382 476497<br> Email: <a href=3D"mailto:ando@sys-net.it" target=3D"_blank">ando@sys= -net.it</a><br> -----------------------------------<br> <br> </div></div></blockquote></div><br>
--0016e65206024a6d9d0462d5c0d0--
-
brett.maxfield＠gmail.com