openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 14 Feb '09

14 Feb '09

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 (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--

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by hyc＠symas.com 14 Feb '09

14 Feb '09

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. > 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... -- -- 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

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

14 Feb '09

--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(a)sys-net.it>wrote: > [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(a)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. Assuming = the config (database meta, and map instead of rwm-map shows similar problem= ) : database        ldap suffi= x          "c=3DAU"<= br>uri           &nb= sp; "ldap://<a href=3D"http://127.0.0.1:390/c=3DAU">127.0.0.1:390/c=3D= AU</a>" overlay rwm rwm-map attribute cn * rwm-map attribute sn * = rwm-map attribute givenName * rwm-map attribute * rwm-map objectc= lass inetOrgPerson * rwm-map objectclass organisationalUnit * rwm-map= objectclass organization * rwm-map objectclass country * rwm-map objectclass * 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: 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*)' '*' # extended = LDIF # # LDAPv3 # base <cn=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU= > with scope subtree # filter: (objectclass=3D*) # requesting: *<b= r># # test00496, support, openldap, AU dn: cn=3Dtest00496,ou=3Dsu= pport,o=3Dopenldap,c=3DAU objectClass: inetOrgPerson cn: test00496 givenName: test00496 uid:= test00496 sn: test00496lname displayName: test00496 test00496lname<b= r>userPassword:: bm92ZWxs # search result search: 2 result: 0 = Success # numResponses: 2 # numEntries: 1 When i query the meta direc= tory, i get no attributes (* or + or *,+, in the requested attributes all r= eturn no attributes as below) : 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*)' '*' # 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: cn= =3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU # 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://<a href=3D"http://127.0.0.1:391">127.0.0.1:391</a> -x -b 'cn=3Dt= est00496,ou=3Dsupport,o=3Dopenldap,c=3DAU' '(objectclass=3D*)' = cn sn firstName # extended LDIF # # LDAPv3 # base <cn=3Dtest00496,ou=3Dsupport,= o=3Dopenldap,c=3DAU> with scope subtree # filter: (objectclass=3D*)<b= r># requesting: cn sn firstName # # test00496, support, openldap,= AU dn: cn=3Dtest00496,ou=3Dsupport,o=3Dopenldap,c=3DAU cn: test00496 sn:= test00496lname # search result search: 2 result: 0 Success<br= > # numResponses: 2 # numEntries: 1 So i conclude then that th= e 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 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). 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>Cheers Brett <div class=3D"gmail_quote">On Sun, Jan 25, 2009 a= t 12:53 AM, Pierangelo Masarati <<a href=3D"mailto:and= o(a)sys-net.it">ando(a)sys-net.it</a>> wrote: <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"> Brett @Google wrote: <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, 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 ? </blockquote> </div> apparently, yes.<div class=3D"Ih2E3d"> <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 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 )<b= r> 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. </blockquote> </div> Not sure I understand.  Can you post simple (both working and not work= ing) examples?<div><div></div><div class=3D"Wj3C7c"> p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA <a href=3D"http://www.sys-net.it" target=3D"_blank">http://www.sys-net.it</= a> ----------------------------------- Office:  +39 02 23998309 Mobile:  +39 333 4963172 Fax:     +39 0382 476497 Email:   <a href=3D"mailto:ando@sys-net.it" target=3D"_blank">ando@sys= -net.it</a> ----------------------------------- </div></div></blockquote></div> --0016e65206024a6d9d0462d5c0d0--

1 0

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by hyc＠symas.com 13 Feb '09

13 Feb '09

toby(a)inf.ed.ac.uk wrote: > This looks a little strange to me... > > (gdb) p f2->f_choice > Cannot access memory at address 0x39 > (gdb) up > #1 0x08155862 in tavl_insert (root=0x8afe590, data=0x8aefb88, > fcmp=0x81399b0<pcache_query_cmp>, fdup=0x8154700<avl_dup_error>) > at tavl.c:82 > 82 cmp = fcmp( data, p->avl_data ); > (gdb) p p->avl_data > $1 = (void *) 0x8af62e0 > (gdb) It appears you've compiled with debug and optimization, can you please compile without optimization and try to reproduce this? -- -- 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

(ITS#5944) configure options --program-prefix and --program-suffix do not update servers/slapd/main.c
by Frank.Swasey＠uvm.edu 13 Feb '09

13 Feb '09

Full_Name: Francis Swasey Version: 2.4.13 OS: Red Hat Enterprise Linux 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (132.198.37.250) When using the configure options --program-prefix or --program-suffix, the binaries are named as exspected. However, slapd's tools array is not updated and so when using the slap* tool binaries, slapd doesn't recognize that it is being executed as a tool and attempts to start up as slapd.

1 0

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

13 Feb '09

This is a multi-part message in MIME format. --------------030704040902090700090604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 13.02.2009 14:29, jclarke(a)linagora.com wrote: > On 13.02.2009 01:23, Howard Chu wrote: > >> Jonathan Clarke wrote: >> >>> hyc(a)symas.com wrote: >>> >>>> Ah right. For the serverID code, we're doing a liberal match because >>>> anything >>>> that matches the current name:port is obviously the current server, >>>> and we >>>> want it to be identified as such. >>>> >>>> For syncrepl, we know full well that it may be the current server, >>>> but for >>>> whatever reason you may want to replicate against yourself anyway >>>> (e.g., >>>> against a different baseDN, etc...). >>>> >>> Actually, this comes straight from test049 (config replication). With >>> multimaster config replication, it starts by replicating itself >>> (useless, but necessary for other masters). This problem doesn't appear >>> in the test case, since a variable ($URI1) is used for both the slapd -h >>> $URI1 option, and in the syncrepl provider=$URI1 LDIF. Otherwise it >>> would produce weird results. >>> >> 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. Oops, sorry, I've been mixing 049 and 050 in my head. My bad, this isn't a problem for test049 indeed. Although I am curious as to why test049 creates a syncrepl consumer targeted at itself? Can't quite get my head around it yet, but will keep thinking, with regard to multimaster. --------------030704040902090700090604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <meta content="text/html; charset=ISO-8859-1" http-equiv="Content-Type"> </head> <body text="#000000" bgcolor="#ffffff"> On 13.02.2009 14:29, <a class="moz-txt-link-abbreviated" href="mailto:jclarke@linagora.com">jclarke(a)linagora.com</a> wrote: <blockquote cite="mid:200902131329.n1DDTKF6072656@boole.openldap.org" type="cite"> <pre wrap="">On 13.02.2009 01:23, Howard Chu wrote: </pre> <blockquote type="cite"> <pre wrap="">Jonathan Clarke wrote: </pre> <blockquote type="cite"> <pre wrap=""><a class="moz-txt-link-abbreviated" href="mailto:hyc@symas.com">hyc(a)symas.com</a> wrote: </pre> <blockquote type="cite"> <pre wrap="">Ah right. For the serverID code, we're doing a liberal match because anything that matches the current name:port is obviously the current server, and we want it to be identified as such. For syncrepl, we know full well that it may be the current server, but for whatever reason you may want to replicate against yourself anyway (e.g., against a different baseDN, etc...). </pre> </blockquote> <pre wrap="">Actually, this comes straight from test049 (config replication). With multimaster config replication, it starts by replicating itself (useless, but necessary for other masters). This problem doesn't appear in the test case, since a variable ($URI1) is used for both the slapd -h $URI1 option, and in the syncrepl provider=$URI1 LDIF. Otherwise it would produce weird results. </pre> </blockquote> <pre wrap="">If you want a setup similar to test049, follow what it does. If you want to something else, do otherwise. </pre> </blockquote> <pre wrap="">I am following what test049 does.</pre> </blockquote> Oops, sorry, I've been mixing 049 and 050 in my head. My bad, this isn't a problem for test049 indeed. Although I am curious as to why test049 creates a syncrepl consumer targeted at itself? Can't quite get my head around it yet, but will keep thinking, with regard to multimaster. </body> </html> --------------030704040902090700090604--

1 0

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

13 Feb '09

On 13.02.2009 01:23, Howard Chu wrote: > Jonathan Clarke wrote: >> hyc(a)symas.com wrote: >>> Ah right. For the serverID code, we're doing a liberal match because >>> anything >>> that matches the current name:port is obviously the current server, >>> and we >>> want it to be identified as such. >>> >>> For syncrepl, we know full well that it may be the current server, >>> but for >>> whatever reason you may want to replicate against yourself anyway >>> (e.g., >>> against a different baseDN, etc...). >> Actually, this comes straight from test049 (config replication). With >> multimaster config replication, it starts by replicating itself >> (useless, but necessary for other masters). This problem doesn't appear >> in the test case, since a variable ($URI1) is used for both the slapd -h >> $URI1 option, and in the syncrepl provider=$URI1 LDIF. Otherwise it >> would produce weird results. > > 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. If you patch the test as follows, it fails: 8<---------------------------------------------------- --- tests/scripts/test049-sync-config 10 Feb 2009 12:29:01 -0000 1.4.2.9 +++ tests/scripts/test049-sync-config 13 Feb 2009 10:11:22 -0000 @@ -112,7 +112,7 @@ $LDAPMODIFY -D cn=config -H $URI1 -y $CO -olcSyncRepl: rid=001 provider=$URI1 binddn="cn=config" bindmethod=simple +olcSyncRepl: rid=001 provider=`echo $URI1 | sed "s/localhost/127.0.0.1/"` binddn="cn=config" bindmethod=simple 8<---------------------------------------------------- Error: 8<---------------------------------------------------- Running ./scripts/test049-sync-config... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Inserting syncprov overlay on producer... ldapmodify failed for syncrepl config (10)! 8<---------------------------------------------------- > 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. 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? Jonathan

1 0

Re: (ITS#5756) 2.4 slapo-pcache only caches first lookup for certain templates
by toby＠inf.ed.ac.uk 13 Feb '09

13 Feb '09

Hi there, I've put this patched version on a small lab of clients (about 23) and on one of them slapd has segfaulted and dumped core. Here's the backtrace: Program terminated with signal 11, Segmentation fault. #0 pcache_filter_cmp (f1=0x8af09f8, f2=0x39) at pcache.c:608 608 switch( f2->f_choice ) { (gdb) bt #0 pcache_filter_cmp (f1=0x8af09f8, f2=0x39) at pcache.c:608 #1 0x08155862 in tavl_insert (root=0x8afe590, data=0x8aefb88, fcmp=0x81399b0 <pcache_query_cmp>, fdup=0x8154700 <avl_dup_error>) at tavl.c:82 #2 0x0813a95d in add_query (op=0x8ae3658, qm=0x8a74cc0, query=0xb55af394, templ=0x8a90f88, why=PC_POSITIVE, wlock=1) at pcache.c:1252 #3 0x0813d7f1 in pcache_op_cleanup (op=0x8ae3658, rs=0xb5eb1148) at pcache.c:2041 #4 0x08076a04 in slap_cleanup_play (op=0x8ae3658, rs=0xb5eb1148) at result.c:341 #5 0x08079a56 in send_ldap_response (op=0x8ae3658, rs=0xb5eb1148) at result.c:522 #6 0x0807aa42 in slap_send_ldap_result (op=0x8ae3658, rs=0xb5eb1148) at result.c:650 #7 0x080f4fef in ldap_back_search (op=0x8ae3658, rs=0xb5eb1148) at search.c:549 #8 0x080cf431 in overlay_op_walk (op=0x8ae3658, rs=0xb5eb1148, which=op_search, oi=0x8a74ff0, on=0x8a750f0) at backover.c:670 #9 0x080cf9ed in over_op_func (op=0x8ae3658, rs=0xb5eb1148, which=op_search) at backover.c:722 #10 0x08069016 in fe_op_search (op=0x8ae3658, rs=0xb5eb1148) at search.c:366 #11 0x0806989b in do_search (op=0x8ae3658, rs=0xb5eb1148) at search.c: 217 #12 0x08066a66 in connection_operation (ctx=0xb5eb1218, arg_v=0x8ae3658) at connection.c:1090 #13 0x08067082 in connection_read_thread (ctx=0xb5eb1218, argv=0xf) at connection.c:1216 #14 0x08159704 in ldap_int_thread_pool_wrapper (xpool=0x8a52f90) at tpool.c:663 #15 0x0064f46b in start_thread () from /lib/libpthread.so.0 #16 0x005a6dbe in clone () from /lib/libc.so.6 This looks a little strange to me... (gdb) p f2->f_choice Cannot access memory at address 0x39 (gdb) up #1 0x08155862 in tavl_insert (root=0x8afe590, data=0x8aefb88, fcmp=0x81399b0 <pcache_query_cmp>, fdup=0x8154700 <avl_dup_error>) at tavl.c:82 82 cmp = fcmp( data, p->avl_data ); (gdb) p p->avl_data $1 = (void *) 0x8af62e0 (gdb) Cheers Toby -- The University of Edinburgh is a charitable body, registered in Scotland, with registration number SC005336.

1 0

Re: (ITS#5919) URI syntaxe (ldap:///dc=my%2cdc=domaine)
by philippe.eychart＠informatique.gov.pf 13 Feb '09

13 Feb '09

This is a multi-part message in MIME format. ------=_NextPart_000_00A9_01C98D2A.7E1AFAD0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Here is a first result (patch integration) ... It doen't more remains to write the actual SRV search ... (coming soon) Here is a running log : root@testldap0:/var/log# >syslog root@testldap0:/var/log# grep "^[^#].*ldapsam:" /etc/samba/smb.conf passdb backend = ldapsam:"ldap://ns0 ldap://ns0/ou=profile%2cdc=gov%2cdc=pf??sub?(objectClass=*)?x-dnssrv=dc=gov% 2cdc=pf ldap://newldap/dc=srv%2cdc=gov%2cdc=pf??sub?(objectClass=*)?toto ldap:///dc=srv%2cdc=gov%2cdc=pf??sub??toto" root@testldap0:/var/log# /etc/rc.d/rc.samba restart Starting Samba: /usr/local/samba/sbin/smbd -D /usr/local/samba/sbin/nmbd -D root@testldap0:/var/log# cat syslog Feb 13 01:38:25 testldap0 smbd: the final url is: "ldap://ns0 ldap://ldap1.gov.pf ldap://ldap2.gov.pf ldap://ldap3.gov.pf ldap://newldap/dc=srv%2cdc=gov%2cdc=pf??sub?(objectClass=*)?toto ldap://ldap1.gov.pf ldap://ldap2.gov.pf ldap://ldap3.gov.pf-" -- PE ------=_NextPart_000_00A9_01C98D2A.7E1AFAD0 Content-Type: application/octet-stream; name="open.c.patch" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="open.c.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-13 = 01:30:35.000000000 +0000=0A= @@ -212,19 +212,128 @@=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= +=0A= +if ( (*result =3D ldap_str2charray( "ldap://ldap1.gov.pf = ldap://ldap2.gov.pf ldap://ldap3.gov.pf", " " )) !=3D NULL ) rc =3D 3; = // line to delete ...=0A= +=0A= + // Coming soon ...=0A= +=0A= + return rc;=0A= +}=0A= +=0A= +char *=0A= +expand_dnssrv_definitions ( LDAP_CONST char *url_in )=0A= +{=0A= + char *dom, *s, *dn =3D NULL, **srvSearchResult =3D NULL;=0A= + char **urls =3D NULL, **extentions =3D NULL;=0A= + int i, ii, urlsNb=3D0;=0A= +=0A= + if( url_in =3D=3D NULL ) {=0A= + return NULL;=0A= + }=0A= +=0A= + urls =3D ldap_str2charray( url_in, " " );=0A= +=0A= + while( urls[urlsNb] ) urlsNb++; // How many urls is there ?...=0A= +=0A= + for( i=3D0; (dom=3Durls[i]); i++ ) { // for each URL, search SRV = domain ...=0A= +=0A= + // Search for "x-dnssrv" extention (fifth field) ...=0A= + if ( *(dom =3D (char *)strchrnul( dom, '?' )) !=3D '?' || ! *(++dom) = ) continue;=0A= + if ( *(dom =3D (char *)strchrnul( dom, '?' )) !=3D '?' || ! *(++dom) = ) continue;=0A= + if ( *(dom =3D (char *)strchrnul( dom, '?' )) !=3D '?' || ! *(++dom) = ) continue;=0A= + if ( *(dom =3D (char *)strchrnul( dom, '?' )) !=3D '?' || ! *(++dom) = ) continue;=0A= + extentions =3D ldap_str2charray( dom, "," );=0A= + for ( dom=3DNULL,ii=3D0; extentions[ii]; ii++ ) {=0A= + ldap_pvt_str2lower ( extentions[ii]+1 );=0A= + if ( strncmp( extentions[ii], "x-dnssrv=3D", sizeof ( "x-dnssrv=3D" = )-1) =3D=3D 0 ) {=0A= + dom =3D extentions[ii] + sizeof ( "x-dnssrv=3D" ) - 1;=0A= + break;=0A= + } }=0A= +=0A= + // Search for dn =3D=3D "dc=3D.*[,dc=3D.*]*" - only in case there was = not any "x-dnssrv" extension ...=0A= + if ( ! dom ) { dom=3Durls[i];=0A= + if ( *(dom =3D (char *)strchrnul( dom, '/' )) !=3D '/' = || !strncmp ( dom, "///dc=3D", 6 ) =3D=3D 0 ) continue;=0A= + dom=3Ddn=3D (char *) LDAP_STRDUP ( dom+3 );=0A= + if ( dom ) *(char *)strchrnul( dom, '?' ) =3D '\0';=0A= + }=0A= + =0A= + // Does dom realy look like a domain name (if a dn format is = detected) ?...=0A= + if ( dom && strncmp(dom, "dc=3D", 3) =3D=3D 0 ) // It's effectively a = dn definition (not just a domaine name) ?...=0A= + for ( s=3Ddom+3; *s; s++ ) // Nothing else than "dc=3D" in the = string ?...=0A= + if ( *s =3D=3D '=3D' && *(s-1) !=3D 'c' && *(s-2) !=3D 'd') {=0A= + dom =3D NULL; // never mind, a next time !...=0A= + break; =0A= + }=0A= +=0A= + // Replace the current url with the result of the SRV search ...=0A= + if ( dom ) {=0A= + int rc =3D url_expand_on_srv_search ( &srvSearchResult, urls[i], dom = );=0A= +=0A= + if ( rc > 0 ) { // Substitution (must keep the initial order of = the urls) ...=0A= + char **u, **result =3D srvSearchResult;=0A= + if ( (u =3D (char **)LDAP_MALLOC( (urlsNb + rc) * sizeof(char *) )) = ) {=0A= + for ( ii=3DurlsNb + rc; ii; ) u[--ii] =3D NULL;=0A= + while ( ii<i ) {=0A= + u[ii] =3D urls[ii];=0A= + ii++;=0A= + } while ( ii<i+rc && rc ) { // replace url[i] with url(s) = resulting from the SRV search ...=0A= + u[ii] =3D *result++;=0A= + ii++;=0A= + } while ( urls[ii-rc+1] && rc ) {=0A= + u[ii] =3D urls[ii-rc+1];=0A= + ii++;=0A= + } u[ii] =3D NULL;=0A= + LDAP_FREE ( urls );=0A= + urls =3D u;=0A= + rc--; i +=3D rc; urlsNb +=3D rc;=0A= + }=0A= + LDAP_FREE ( srvSearchResult );=0A= + } }=0A= +=0A= + // it's done for the current url ...=0A= + LDAP_FREE( dn );=0A= + ldap_charray_free( extentions );=0A= + }=0A= +=0A= + // last job : to construct the result string ...=0A= + for ( i=3D0; urls[i]; i++ ) {=0A= + urlsNb +=3D strlen( urls[i] );=0A= + urlsNb++; // for urls separator: ' ' ...=0A= + } if ( (s =3D (char *)LDAP_MALLOC( ++urlsNb )) !=3D NULL ) {=0A= + for ( *s=3D'\0',i=3D0; urls[i]; i++ )=0A= + sprintf ( &s[strlen(s)], "%s ", urls[i] );=0A= + s[strlen(s)-1] =3D '\0'; // delete last ' ' ...=0A= + }=0A= +=0A= + ldap_charray_free( urls );=0A= +=0A= + // bye ...=0A= + return ( s );=0A= +}=0A= +=0A= =0A= int=0A= -ldap_initialize( LDAP **ldp, LDAP_CONST char *url )=0A= +ldap_initialize( LDAP **ldp, LDAP_CONST char *url_in )=0A= {=0A= int rc;=0A= LDAP *ld;=0A= + char *url;=0A= =0A= *ldp =3D NULL;=0A= rc =3D ldap_create(&ld);=0A= if ( rc !=3D LDAP_SUCCESS )=0A= return rc;=0A= =0A= - if (url !=3D NULL) {=0A= + if (url_in !=3D NULL) {=0A= + url =3D expand_dnssrv_definitions ( url_in );=0A= + if ( url =3D=3D NULL ) {=0A= + return LDAP_URL_ERR_MEM;=0A= + }=0A= +syslog ( 3, "the final url is: \"%s-\"", url ); // to delete ...=0A= +=0A= rc =3D ldap_set_option(ld, LDAP_OPT_URI, url);=0A= if ( rc !=3D LDAP_SUCCESS ) {=0A= ldap_ld_free(ld, 1, NULL, NULL);=0A= @@ -234,6 +343,7 @@=0A= if (ldap_is_ldapc_url(url))=0A= LDAP_IS_UDP(ld) =3D 1;=0A= #endif=0A= + LDAP_FREE( url );=0A= }=0A= =0A= *ldp =3D ld;=0A= ------=_NextPart_000_00A9_01C98D2A.7E1AFAD0--

1 0

Re: (ITS#5942) URI matching of "self" in add_syncrepl is incomplete
by hyc＠symas.com 13 Feb '09

13 Feb '09

Jonathan Clarke wrote: > hyc(a)symas.com wrote: >> Ah right. For the serverID code, we're doing a liberal match because anything >> that matches the current name:port is obviously the current server, and we >> want it to be identified as such. >> >> For syncrepl, we know full well that it may be the current server, but for >> whatever reason you may want to replicate against yourself anyway (e.g., >> against a different baseDN, etc...). > Actually, this comes straight from test049 (config replication). With > multimaster config replication, it starts by replicating itself > (useless, but necessary for other masters). This problem doesn't appear > in the test case, since a variable ($URI1) is used for both the slapd -h > $URI1 option, and in the syncrepl provider=$URI1 LDIF. Otherwise it > would produce weird results. If you want a setup similar to test049, follow what it does. If you want to something else, do otherwise. 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. As usual, when you're configuring a server, you have to pay attention to what you're doing and what effect you want to accomplish. -- -- 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