- openldap-bugs - openldap.org

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

13 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 13 Feb '09

13 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

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

13 Feb '09

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. -- -- 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#5945) --enable-backends=auto support
by Kurt＠OpenLDAP.org 13 Feb '09

13 Feb '09

On Feb 13, 2009, at 5:55 PM, hyc(a)symas.com wrote: > quanah(a)OpenLDAP.org wrote: >> Full_Name: Quanah Gibson-Mount >> Version: 2.4.13 >> OS: NA >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (75.111.29.239) >> >> >> It would be handy to allow --enable-backends to have auto support >> so that all >> available backends can be selected. The current behavior is "yes", >> which means >> that if you don't have the requisites for a given backend, >> configure stops. > > Accommodating this request would make other things much more > inconvenient. > > Currently the backends and overlay options toggle between "no | yes > | mod" > where "yes" means "yes+static" and "mod" means "yes+dynamic". An > "auto" option > here doesn't allow you to select static vs dynamic. We could have auto => yes+static and automod => yes+dyanmic. But that might be too cumbersome as well. > Adding "auto" would revert > us back to OpenLDAP 2.0's behavior, where every backend required two > enable > switches "--enable-bdb" and "--enable-bdb-mod=static" (or dynamic) > which IMO > was far too cumbersome. > > > Likewise it would require rewriting most of the backends' detection > tests in > configure.in, which currently use AC_MSG_ERROR when a prereq isn't > found. All > of those would have to be turned into warnings/bailouts in the > "auto" case, > instead of aborting the configure run. There's still a lot of old auto tests in configure.in, even for new things like ndb. :-) > > > IMO, seems like more effort than it's worth. possibly. 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. > > -- > -- 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#5945) --enable-backends=auto support
by hyc＠symas.com 13 Feb '09

13 Feb '09

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.13 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > It would be handy to allow --enable-backends to have auto support so that all > available backends can be selected. The current behavior is "yes", which means > that if you don't have the requisites for a given backend, configure stops. Accommodating this request would make other things much more inconvenient. Currently the backends and overlay options toggle between "no | yes | mod" where "yes" means "yes+static" and "mod" means "yes+dynamic". An "auto" option here doesn't allow you to select static vs dynamic. Adding "auto" would revert us back to OpenLDAP 2.0's behavior, where every backend required two enable switches "--enable-bdb" and "--enable-bdb-mod=static" (or dynamic) which IMO was far too cumbersome. Likewise it would require rewriting most of the backends' detection tests in configure.in, which currently use AC_MSG_ERROR when a prereq isn't found. All of those would have to be turned into warnings/bailouts in the "auto" case, instead of aborting the configure run. IMO, seems like more effort than it's worth. -- -- 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#5945) --enable-backends=auto support
by quanah＠OpenLDAP.org 13 Feb '09

13 Feb '09

Full_Name: Quanah Gibson-Mount Version: 2.4.13 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) It would be handy to allow --enable-backends to have auto support so that all available backends can be selected. The current behavior is "yes", which means that if you don't have the requisites for a given backend, configure stops.

1 0

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

13 Feb '09

jclarke(a)linagora.com wrote: > This is a multi-part message in MIME format. Please do not send HTML/MIME emails here. > On 13.02.2009 14:29, jclarke(a)linagora.com wrote: > 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. Very simple. Once the real consumer connects to the master and replicates, it will acquire whatever config was on the master. If the master doesn't have a consumer pointed at itself, then once the consumer acquires the master's configuration, the consumer's syncrepl config will disappear, and replication will stop. -- -- 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#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_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 13 Feb '09

13 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 13 Feb '09

13 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 12 Feb '09

12 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 12 Feb '09

12 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

Re: (ITS#5940) crash in slapo-rwm when modifying olcRwmRewrite
by ando＠sys-net.it 12 Feb '09

12 Feb '09

ando(a)sys-net.it wrote: > Also, please note that modifications to olcRwmRewrite is not allowed, > unless consisting in a full replace without {} idxes. The operation you > were trying, More about this: now slapo-rwm supports add/delete/modify olcRwmRewrite values (in a far from optimal manner). 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#5940) crash in slapo-rwm when modifying olcRwmRewrite
by ando＠sys-net.it 12 Feb '09

12 Feb '09

ando(a)sys-net.it wrote: > Please forget my previous posting. Your issue should now be solved in > HEAD. Please test. p. Also, please note that modifications to olcRwmRewrite is not allowed, unless consisting in a full replace without {} idxes. The operation you were trying, 8<---------------------------- dn: olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config changeType: modify replace: olcRwmRewrite olcRwmRewrite: {0}rwm-suffixmassage "o=proxy" "dc=demo,dc=lan" 8<---------------------------- is not allowed. This is allowed, though: 8<---------------------------- dn: olcOverlay={0}rwm,olcDatabase={1}ldap,cn=config changeType: modify replace: olcRwmRewrite olcRwmRewrite: rwm-suffixmassage "o=proxy" "dc=demo,dc=lan" 8<---------------------------- note the missing {0}. Support for renumbering of olcRwmRewrite could be introduced by removing rewrite info and regenerating it from the saved values. 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#5942) URI matching of "self" in add_syncrepl is incomplete
by jclarke＠linagora.com 12 Feb '09

12 Feb '09

hyc(a)symas.com wrote: > Howard Chu wrote: > >> hyc(a)symas.com wrote: >> >>> jclarke(a)linagora.com wrote: >>> >>>> I saw the comment in the code that clarifies this behaviour. However, it's a >>>> surprising behaviour, and I think there is code to parse this kind of thing in >>>> the serverID detection now. Maybe it could be reused? >>>> >> Oops, never mind. I was thinking of the serverID code, and you're talking >> about the syncrepl code. >> >> I'll have to think a bit about why the two aren't behaving identically; >> probably they should both use the same code. >> >> > 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. Jon

1 0

Re: (ITS#5940) crash in slapo-rwm when modifying olcRwmRewrite
by ando＠sys-net.it 12 Feb '09

12 Feb '09

jclarke(a)linagora.com wrote: > Given a simple setup involving back-ldap with slapo-rwm on top, modifying the > attribute "olcRwmRewrite" causes a crash. This seems to happen both while > modifying an existing value, or when deleting one. Please forget my previous posting. Your issue should now be solved in HEAD. Please 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#5943) back-relay does not recognize when would call self
by ando＠sys-net.it 12 Feb '09

12 Feb '09

ando(a)sys-net.it wrote: > Simply comparing the BackendDB pointers of the operation and of the operation's > DN does not detect when back-relay would call self, possibly resulting in > endless loop. should be fixed in HEAD. Please 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

(ITS#5943) back-relay does not recognize when would call self
by ando＠sys-net.it 12 Feb '09

12 Feb '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.72.89.40) Submitted by: ando Simply comparing the BackendDB pointers of the operation and of the operation's DN does not detect when back-relay would call self, possibly resulting in endless loop. p.

1 0

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

12 Feb '09

Le Jeu 12 février 2009 20:41, Howard Chu a écrit : > jclarke(a)linagora.com wrote: >> Full_Name: Jonathan Clarke >> Version: RE24 >> OS: irrelevant >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (213.41.243.192) >> >> >> Hi, >> >> When adding a syncrepl config, the function add_syncrepl performs a >> "check if >> URL points to current server". This check is based on an exact match >> between the >> provider parameter from the syncrepl config line, and the URIs given to >> slapd on >> startup. >> >> If this doesn't match when it should, the database is marked as a >> shadow, and >> all following updates fail with "shadow context; no update refs". This >> is quite >> a pain when it happens on cn=config :) >> >> There are multiple cases when this happens: >> 1) If no specific URI was specified on launch (no -h option) >> 2) Port numbers are explicitly specified or not (":389") >> 3) Trailing slash (for example "ldap://1.2.3.4" != "ldap://1.2.3.4/") >> 4) IP is specified rather than DNS name ("ldap://localhost" != >> "ldap://127.0.0.1") >> >> I saw the comment in the code that clarifies this behaviour. However, >> it's a >> surprising behaviour, and I think there is code to parse this kind of >> thing in >> the serverID detection now. Maybe it could be reused? >> >> Otherwise, we should probably document this behaviour, to avoid >> headaches :) > > The manpage says the serverID URL must use an FQDN. We already do a number > of > guesses in the code, I don't see any reason to extend this further. I'm sorry, but I was not referring to the serverID URI matching. I'm referring to syncrepl provider matching to listeners. I mentioned the serverID matching since it seems to work like syncrepl provider matching should. Regards, Jonathan

1 0

Re: (ITS#5941) Problem when stacking rwm and translucent overlays together
by ando＠sys-net.it 12 Feb '09

12 Feb '09

The problem can be easily reproduced, no need for further testing. However, I don't see an easy and clear fix right now. In the meanwhile, you should stack something in between to obtain the desired result. Having another proxy in between that deals with rwm could help. 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs