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

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

13 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

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