--0016e648d4747104c80462dfbb05 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On Sat, Feb 14, 2009 at 7:40 PM, Pierangelo Masarati <[email protected]>wrote: > [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. > 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:[email protected]"; target=3D"_bl= ank">[email protected]</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:[email protected]"; target=3D"_blank">brett.ma= [email protected]</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--
