--0016e648d4747104c80462dfbb05 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On Sat, Feb 14, 2009 at 7:40 PM, Pierangelo Masarati ando@sys-net.itwrote:
brett.maxfield@gmail.com 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.
Yes, sorry i was originally using meta backend & switched to ldap. Although openldap seems to accept the DN component, but happily ignore it.
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.
Ditto with the typing error.
Here the correct spelling is "organisation", i forgot to type it "wrong" for openldap :P
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.
Just tried, the fix works perfectly with database meta, overlay rwm, and rwm-map :
database ldap suffix "c=AU" uri "ldap://127.0.0.1 http://127.0.0.1:390/c=AU:390/c=AU"
overlay rwm
rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute givenName * rwm-map attribute createTimestamp * rwm-map attribute modifyTimestamp * rwm-map attribute *
rwm-map objectclass inetOrgPerson * rwm-map objectclass organizationalUnit * rwm-map objectclass organization * rwm-map objectclass country * rwm-map objectclass *
Eg :
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 objectClass: inetOrgPerson cn: test00496 givenName: test00496 sn: test00496lname createTimestamp: 20090213130450Z modifyTimestamp: 20090213130450Z
# search result search: 2 result: 0 Success
# numResponses: 2 # numEntries: 1
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"
map attribute cn * map attribute sn * map attribute givenName * map attribute *
map objectclass inetOrgPerson * map objectclass organizationalUnit * map objectclass organization * map objectclass country * map objectclass *
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.
Cheers Brett
--0016e648d4747104c80462dfbb05 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
<div class=3D"gmail_quote">On Sat, Feb 14, 2009 at 7:40 PM, Pierangelo Masa= rati <span dir=3D"ltr"><<a href=3D"mailto:ando@sys-net.it" target=3D"_bl= ank">ando@sys-net.it</a>></span> wrote:<br><blockquote class=3D"gmail_qu= ote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0p= t 0.8ex; padding-left: 1ex;">
<div><a href=3D"mailto:brett.maxfield@gmail.com" target=3D"_blank">brett.ma= xfield@gmail.com</a> wrote:<br> </div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb= (204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> --0016e65206024a6d9d0462d5c0d0<br> Content-Type: text/plain; charset=3DISO-8859-1<br> Content-Transfer-Encoding: 7bit<div><br> <br> 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 simila= r<br> problem) :<br> <br> database ldap<br> suffix "c=3DAU"<br> uri "ldap://<a href=3D"http:= //127.0.0.1:390/c=3DAU" target=3D"_blank">127.0.0.1:390/c=3DAU</a>"<br=
</div></blockquote> <br> You messed things up a little bit: back-ldap does not allow the DN part of = the URI.<div></div></blockquote><div><br>Yes, sorry i was originally using = meta backend & switched to ldap. Although openldap seems to accept the = DN component, but happily ignore it.<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;"> 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 objectclass inetOrgPerson *<br> rwm-map objectclass organisationalUnit *<br> </blockquote> <br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> s/organisationalUnit/organizationalUnit/: this raises a warning.</blockquot= e><div><br>Ditto with the typing error.<br><br>Here the correct spelling is= "organisation", i forgot to type it "wrong" for openld= ap :P<br>
<br><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid rgb(2= 04, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Probably * an= d + (or *,+) should be expanded to the list of user or<br> administrative attributes (respectively) by meta/rwm first, specifically<br=
those that are allowed by "map attribute" lines, before being han= ded to the<br> real directory (helpful to performance if the backend directory has many<br=
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, if i = am<br> using a GUI browser, as they commonly use *,+ as their default.<br> </blockquote> <br></div><blockquote class=3D"gmail_quote" style=3D"border-left: 1px solid= rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Well, if you don't request any attribute, those that are mapped appear.= I've modified slapo-rwm to pass thru special attribute names (&q= uot;*", "+", "1.1") in order to defer their mappin= g when results are returned. This looks simpler than detecting whether non-= mapped attrs are filtered and, in tat case, replace "*" by the ma= pped attributes, although the latter could be an optimization.<br>
<br> 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.<div>= </div></blockquote><div><br>Just tried, the fix works perfectly with databa= se meta, overlay rwm, and rwm-map :<br> <br>database ldap<br>suffix = "c=3DAU"<br>uri &= nbsp; "lda= p://<a href=3D"http://127.0.0.1:390/c=3DAU" target=3D"_blank">127.0.0.1</a>= :390/c=3DAU"<br><br>overlay rwm<br><br>rwm-map attribute cn *<br> rwm-map attribute sn *<br>rwm-map attribute givenName *<br>rwm-map attribut= e createTimestamp *<br>rwm-map attribute modifyTimestamp *<br>rwm-map attri= bute *<br><br>rwm-map objectclass inetOrgPerson *<br>rwm-map objectclass or= ganizationalUnit *<br> rwm-map objectclass organization *<br>rwm-map objectclass country *<br>rwm-= map objectclass *<br><br>Eg :<br><br>ldapsearch -H ldap://<a href=3D"http:/= /127.0.0.1:390/c=3DAU" target=3D"_blank">127.0.0.1</a>:391 -x -b 'cn=3D= test00496,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: c= n=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU<br> objectClass: inetOrgPerson<br>cn: test00496<br>givenName: test00496<br>sn: = test00496lname<br>createTimestamp: 20090213130450Z<br>modifyTimestamp: 2009= 0213130450Z<br><br># search result<br>search: 2<br>result: 0 Success<br> <br># numResponses: 2<br># numEntries: 1<br><br></div></div>However, there = is also a similar problem with database meta, and map :<br><br>database&nbs= p; meta<br>suffix &nbs= p; "c=3DAU"<br>uri  = ; "ldap://<a hre= f=3D"http://127.0.0.1:390/c=3DAU" target=3D"_blank">127.0.0.1</a>:390/c=3DA= U"<br> <br>map attribute cn *<br>map attribute sn *<br>map attribute givenName *<b= r>map attribute *<br><br>map objectclass inetOrgPerson *<br>map objectclass= organizationalUnit *<br>map objectclass organization *<br>map objectclass = country *<br> map objectclass *<br><br>When i run the above i get :<br><br>ldapsearch -H = ldap://<a href=3D"http://127.0.0.1:390/c=3DAU" target=3D"_blank">127.0.0.1<= /a>:391 -x -b 'cn=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU' = 9;(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: c= n=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU<br> entryDN: cn=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU<br>subschemaSubent= ry: cn=3DSubschema<br><br># search result<br>search: 2<br>result: 0 Success= <br><br># numResponses: 2<br># numEntries: 1<br><br>Which is not (yet) show= ing the user attributes, and is leaking some un-requested operational attri= butes.<br> <br>Cheers<br>Brett<br>
--0016e648d4747104c80462dfbb05--
-
brett.maxfield＠gmail.com