openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by jclarke＠linagora.com 16 Feb '09

16 Feb '09

On 14.02.2009 01:51, Howard Chu wrote: > Jonathan Clarke wrote: >> On 13.02.2009 01:23, Howard Chu wrote: >>> If you want a setup similar to test049, follow what it does. If you >>> want to something else, do otherwise. >> I am following what test049 does. Only difference is test049 starts >> slapd with "-h $URI1" (with URI1="ldap://localhost:9011/") and I start >> slapd with no -h option or a slightly different URI. This is quite >> common, I believe. > > And the slapd(8) manpage clearly states that with no -h option, it > defaults to "ldap:///". If the default suits your purpose, use it. If > not, then specify the URL you want explicitly. Yes, it's quite common to > start slapd with no -h option, because it suits the general case. This > discussion is not about the general case. > >> If you patch the test as follows, it fails: > > Obviously you should not do that. > >>> There are valid reasons to point a syncrepl consumer at the same slapd >>> (e.g., proxy syncrepl, automatic local backup/mirroring, rewriting a >>> subtree of a main database, etc.). Using the exhaustive matching that >>> serverID uses would preclude those cases from working. >> I see. I understand you don't want to break existing functionality. >> However, I still feel this is a bug, or at least that you need to "hack" >> the setup to get things working as expected. > > The docs state that "syncrepl provider" is the LDAP URI of the master > server. If you're not putting in the same URI as the master is using, > that's a config error, not a bug. Understood. Nothing is broken, and we have worked around this issue using explicit listeners to slapd -h. This behaviour did surprise me, considering the behaviour of serverID matching. May I suggest that a note of warning is included in the admin guide? For example: http://milopita.phillipoux.net/jonathan-clarke-20090216.patch >> Would I be right in assuming that in all the "valid reasons to point a >> syncrepl consumer at the same slapd" you mention, the syncrepl consumer >> uses a different base DN than the base DN of the database that the >> syncrepl consumer is configured on? If so, maybe the exhaustive matching >> that serverID uses could be used, if and only if those two base DNs are >> different? > > That sounds reasonable. Will think about it a bit more. Certainly if the > two base DNs are the same, it will cause a loop... Indeed. For what it's worth, while testing on cn=config, I noticed this having various consequences including: 1) cn=config becoming read-only (shadow) and updates returning a referral. 2) in a MMR setup, some updates not being replicated to all N servers. Regards, Jonathan

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by brett.maxfield＠gmail.com 14 Feb '09

14 Feb '09

--0016e6520602e44cff0462e14152 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Sat, Feb 14, 2009 at 11:17 PM, Pierangelo Masarati <ando(a)sys-net.it>wrote: > 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. Yep all looks good now, using either the meta backend, or the ldap + rwm overlay. Good work :) --0016e6520602e44cff0462e14152 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote">On Sat, Feb 14, 2009 at 11:17 PM, Pierangelo Mas= arati <<a href=3D"mailto:ando@sys-net.it">ando@sys-net= .it</a>> wrote: <blockquote class=3D"gmail_quote" style=3D"bor= der-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-= left: 1ex;"> 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 sen= se, but not in your case).  This issue should now be fixed in HEAD.<br= > Note that entryDN and subschemaSubentry are not leaked by slapd-meta(5): th= ey're actually generated by the frontend.  This should be prevente= d now.  Please re-test.</blockquote><div> Yep all looks good now, u= sing either the meta backend, or the ldap + rwm overlay. Good work :) </div></div> --0016e6520602e44cff0462e14152--

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by ando＠sys-net.it 14 Feb '09

14 Feb '09

brett.maxfield(a)gmail.com wrote: > 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 : (snip) > 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" > (snip) > 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. 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(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by brett.maxfield＠gmail.com 14 Feb '09

14 Feb '09

--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(a)sys-net.it>wrote: > brett.maxfield(a)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 <<a href=3D"mailto:ando@sys-net.it" target=3D"_bl= ank">ando(a)sys-net.it</a>> wrote: <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(a)gmail.com</a> wrote: </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 Content-Type: text/plain; charset=3DISO-8859-1 Content-Transfer-Encoding: 7bit<div> I have re-tested with recent RE24 and this still happens. Assuming the config (database meta, and map instead of rwm-map shows simila= r problem) : database        ldap suffix          "c=3DAU" 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> You messed things up a little bit: back-ldap does not allow the DN part of = the URI.<div></div></blockquote><div> Yes, sorry i was originally using = meta backend & switched to ldap. Although openldap seems to accept the = DN component, but happily ignore it. <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 rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute givenName * rwm-map attribute * rwm-map objectclass inetOrgPerson * rwm-map objectclass organisationalUnit * </blockquote> </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> Ditto with the typing error. Here the correct spelling is= "organisation", i forgot to type it "wrong" for openld= ap :P <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 administrative attributes (respectively) by meta/rwm first, specifically<br= > those that are allowed by "map attribute" lines, before being han= ded to the real directory (helpful to performance if the backend directory has many<br= > 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. </blockquote> </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. 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> Just tried, the fix works perfectly with databa= se meta, overlay rwm, and rwm-map : database       ldap suffix  =         "c=3DAU" 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" overlay rwm rwm-map attribute cn * rwm-map attribute sn * rwm-map attribute givenName * rwm-map attribut= e createTimestamp * rwm-map attribute modifyTimestamp * rwm-map attri= bute * rwm-map objectclass inetOrgPerson * rwm-map objectclass or= ganizationalUnit * rwm-map objectclass organization * rwm-map objectclass country * rwm-= map objectclass * Eg : 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*)'= '*' '+' # extended LDIF # # LDAPv3 # base <cn=3Dtest00496,ou=3Dsupport,= o=3Dopenldap,c=3DAU> with scope subtree # filter: (objectclass=3D*)<b= r># requesting: * + # # test00496, support, openldap, AU dn: c= n=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU objectClass: inetOrgPerson cn: test00496 givenName: test00496 sn: = test00496lname createTimestamp: 20090213130450Z modifyTimestamp: 2009= 0213130450Z # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 </div></div>However, there = is also a similar problem with database meta, and map : database&nbs= p;       meta suffix   &nbs= p;      "c=3DAU" uri  &nbsp= ;          "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" map attribute cn * map attribute sn * map attribute givenName *<b= r>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://<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' &#3= 9;(objectclass=3D*)' '*' '+' # extended LDIF # # LDAPv3 # base <cn=3Dtest00496,ou=3Dsupport,= o=3Dopenldap,c=3DAU> with scope subtree # filter: (objectclass=3D*)<b= r># requesting: * + # # test00496, support, openldap, AU dn: c= n=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU entryDN: cn=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU subschemaSubent= ry: cn=3DSubschema # search result search: 2 result: 0 Success= # numResponses: 2 # numEntries: 1 Which is not (yet) show= ing the user attributes, and is leaking some un-requested operational attri= butes. Cheers Brett --0016e648d4747104c80462dfbb05--

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by ando＠sys-net.it 14 Feb '09

14 Feb '09

I note there remains an inconsistency: if you request a specific operational attribute, it is not returned unless explicitly allowed by the mapping. However, if you request all operational attributes using "+", you get all. This occurs because when returning search entries, operational attributes are ignored. I think that we should either: - consistently ignore operational attributes when mapping; or - treat them like other attributes. The latter seems more appropriate to me, since mapping operational attributes could be useful when interacting with other implementations. In any case, the behavior should be consistent. It is up to system administrators to use it appropriately. 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(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5945) --enable-backends=auto support
by michael＠stroeder.com 14 Feb '09

14 Feb '09

Kurt(a)OpenLDAP.org wrote: > On Feb 13, 2009, at 6:42 PM, hyc(a)symas.com wrote: > >> Perhaps a decent alternative would be just to read a set of --enable >> switches >> from ~/.openldap_config or somesuch. I.e., have a file of defaults... > > I think I prefer the current situation to such... And I already > have ./config.status --r > > But on new checkouts, I normally just do --enable-backends --enable- > overlays, wait for breakage, and then add disable flags as needed. > Unforunately, it sometimes takes a few tries. > > So, in short, I concur that doing more here is likely not worth the > effort. +1 Ciao, Michael.

1 0

Re: (ITS#5760) attribute hiding in rwm overlay
by ando＠sys-net.it 14 Feb '09

14 Feb '09

brett.maxfield(a)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. > 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: ando(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by ando＠sys-net.it 14 Feb '09

14 Feb '09

philippe.eychart(a)informatique.gov.pf wrote: > This is a multi-part message in MIME format. > > ------=_NextPart_000_00C2_01C98DEA.AA80EF10 > Content-Type: text/plain; > charset="iso-8859-1" > Content-Transfer-Encoding: 7bit > > As I leave one week for a security formation ISO 27001 (and in case it would > persuade me to make never more programming ;), here is the current state > (not finished) of the patch You should upload patches to ftp.openldap.org and post a link to them, otherwise mailers screw them up as below. Please follow instructions at <http://www.openldap.org/devel/contributing.html#submitting>. p. (only the modified function - cf "Followup 19"). > In fact, 2 more options must be validated there : > 1/- ... // if (x-dnssrv == ".") then $hostname is (must be) the search > SRV-domain (or the default domain, if $hostname=="") ... > 2/- // in all cases, if (*port != '\0') then : result = $(grep "$port" $(the > result of the SRV search)) ... > -- > PE > > ------=_NextPart_000_00C2_01C98DEA.AA80EF10 > Content-Type: application/octet-stream; > name="open.c.url_expand.patch" > Content-Transfer-Encoding: quoted-printable > Content-Disposition: attachment; > filename="open.c.url_expand.patch" > > --- openldap-2.4.13/libraries/libldap/open.c 2008-10-31 = > 23:23:58.000000000 +0000=0A= > +++ openldap-2.4.13/libraries/libldap/open.c 2009-02-14 = > 00:31:27.000000000 +0000=0A= > @@ -212,19 +212,164 @@=0A= > return( ld );=0A= > }=0A= > =0A= > +int=0A= > +url_expand_on_srv_search ( char ***result, LDAP_CONST char *url_in, = > char *domain )=0A= > +{ int rc =3D 0;=0A= > + char *scheme, *hostname, *port, *opt;=0A= > +=0A= > + // Syntax validation ...=0A= > + if ( (scheme =3D (char *)LDAP_STRDUP( url_in )) =3D=3D NULL )=0A= > + return -1; // memory error ...=0A= > +=0A= > + hostname =3D (char *)strchrnul( scheme, '/' ); *hostname++ =3D '\0';=0A= > + if ( *hostname++ !=3D '/' )=0A= > + return -1; // syntax error ...=0A= > + =0A= > + opt =3D (char *)strchrnul( hostname, '/' ); if ( *opt ) *opt++ =3D = > '\0';=0A= > + port =3D (char *)strchrnul( hostname, ':' ); if ( *port ) *port++ =3D = > '\0';=0A= > +=0A= > + if ( *hostname && !strcmp ( domain, "." )=3D=3D0 ) // if (x-dnssrv = > =3D=3D ".") then $hostname is the search SRV-domain (or default domain, = > if $hostname=3D=3D"") ...=0A= > + return -1; // syntax error ...=0A= > +=0A= > + // So now, we can search the server name(s) of the _ldap._tcp.$domain = > service ...=0A= > + // if ( *port !=3D '\0') then : grep the result of SRV RR search with = > $port ...=0A= > +=0A= > + // Coming soon ...=0A= > +if ( (*result =3D ldap_str2charray( "ldap1.gov.pf ldap2.gov.pf = > ldap3.gov.pf", " " )) !=3D NULL ) rc =3D 3; // line to delete ...=0A= > +=0A= > + // Search is finished : so now, add initial scheme and opt to result = > hostport(s) ...=0A= > + if ( *result !=3D NULL ) {=0A= > + size_t plus =3D strlen( scheme ) + strlen ( opt ) + 4;=0A= > + for ( rc=3D0; (char *)((*result)[rc]) !=3D NULL; ) {=0A= > + (*result)[rc] =3D (char *)LDAP_REALLOC ( (char *)((*result)[rc]), = > strlen ( (char *)((*result)[rc]) ) + plus ); =0A= > + { // do a : memcpy ( &((char *)((*result)[rc]))[strlen( scheme ) + = > 2], *result[rc], strlen( (char *)((*result)[rc]) ) + 1 );=0A= > + char *n =3D &((char *)((*result)[rc]))[strlen( scheme ) + 2];=0A= > + char *s =3D (char *)((*result)[rc]);=0A= > + char *e =3D s + (strlen( (char *)((*result)[rc]) ) + 1);=0A= > + for ( n +=3D e - s; e >=3D s; ) *n-- =3D *e--;=0A= > + }=0A= > + memcpy ( &((char *)((*result)[rc]))[strlen( scheme )], "//", 2 );=0A= > + memcpy ( (char *)((*result)[rc]), scheme, strlen( scheme ) );=0A= > + strcat ( (char *)((*result)[rc]), "?" ); strcat ( (char = > *)((*result)[rc]), opt );=0A= > + rc++;=0A= > + }=0A= > + } else rc =3D 0;=0A= > +=0A= > + LDAP_FREE ( scheme );=0A= > + return rc;=0A= > +}=0A= > +=0A= > +char *=0A= > +expand_dnssrv_definitions ( LDAP_CONST char *url_in )=0A= > +{=0A= > ...=0A= > =0A= > > ------=_NextPart_000_00C2_01C98DEA.AA80EF10-- > > 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(a)sys-net.it -----------------------------------

1 0

Re: (ITS#5945) --enable-backends=auto support
by Kurt＠OpenLDAP.org 14 Feb '09

14 Feb '09

On Feb 13, 2009, at 6:42 PM, hyc(a)symas.com wrote: > Perhaps a decent alternative would be just to read a set of --enable > switches > from ~/.openldap_config or somesuch. I.e., have a file of defaults... I think I prefer the current situation to such... And I already have ./config.status --r But on new checkouts, I normally just do --enable-backends --enable- overlays, wait for breakage, and then add disable flags as needed. Unforunately, it sometimes takes a few tries. So, in short, I concur that doing more here is likely not worth the effort. -- Kurt

1 0

Re: (ITS#5945) --enable-backends=auto support
by hyc＠symas.com 14 Feb '09

14 Feb '09

Howard Chu wrote: > Kurt Zeilenga wrote: >> I just noting that for testing, it kind of nice to just be able to do >> ./configure --enable-backends=auto --enable-overlays=auto >> make >> make test >> >> To test everything that available on the box. > > Note that there's no need for an "auto" for overlays - all of the core > overlays are self-contained with no external dependencies, and that should > always be the case. > > I agree that "testing everything available" would be nice, because I > frequently forget to --enable-slapi or various other switches. But I don't > think --enable-everything will suit either. > Perhaps a decent alternative would be just to read a set of --enable switches from ~/.openldap_config or somesuch. I.e., have a file of defaults... -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs