openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

(ITS#6999) retry: counter not reaching zero, continuing on
by ml+openldap＠esmtp.org 25 Jul '11

25 Jul '11

Full_Name: Claus Assmann Version: 2.4.23 OS: Red Hat Enterprise Linux Server release 5.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (63.211.143.38) While trying to determine how syncrepl behaves in various error conditions, I encountered an unexpected behaviour in which the retry specification doesn't seem to work. A MASTER is set up to use push replication to a REPLICA as follows: database ldap hidden on suffix "" rootdn "cn=slapd-ldap" uri ldap://REPLICA/ lastmod on restrict all sync_use_subentry true acl-bind bindmethod=simple binddn="cn=Monitor" credentials=password syncrepl rid=001 provider=ldapi://%2Fvar%2Frun%2Fldapi binddn="cn=Manager" bindmethod=simple credentials=passwd searchbase="" type=refreshAndPersist retry="5 5 60 +" When I stop the REPLICA and add an entry on the MASTER, then the MASTER is retrying every 5s and claims that 4 (sometimes 3) retries are left: Jul 22 13:12:52 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:12:57 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (3 retries left) Jul 22 13:13:02 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:07 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (3 retries left) Jul 22 13:13:12 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:17 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:22 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:28 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:33 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:38 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:43 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:48 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:53 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) Jul 22 13:13:58 MASTER slapd[23778]: do_syncrepl: rid=001 rc 52 retrying (4 retries left) When I start REPLICA again, syncrepl succeeds. Do I have to set some other option such that the retry specification is actually used? That is, try every 5s for 5 times, then try every 60s. Or is the retry logic dependent on the error syncrepl encounters? The full log for one failed retry is: conn=1004 op=0 BIND dn="cn=manager" method=128 conn=1004 op=0 BIND dn="cn=manager" mech=SIMPLE ssf=0 conn=1004 op=0 RESULT tag=97 err=0 text= conn=1004 op=1 SRCH base="" scope=2 deref=0 filter="(objectClass=*)" conn=1004 op=1 SRCH attr=* + srs csn 20110722201233.471069Z#000000#001#000000 log csn 20110722201233.471069Z#000000#001#000000 cmp 0, too old log csn 20110722201252.820971Z#000000#001#000000 Entry uid=user68,ou=People,dc=example,dc=com CSN 20110722201233.471069Z#000000#001#000000 older or equal to ctx 20110722201233.471069Z#000000#001#000000 syncprov_search_response: cookie=rid=001,sid=001,csn=20110722201252.820971Z#000000#001#000000 syncrepl_entry: rid=001 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=001 inserted UUID 95b838a2-4b55-4bcc-8b00-be329b138db0 conn=1004 fd=15 ACCEPT from PATH=/var/run/ldapi (PATH=/var/run/ldapi) syncrepl_entry: rid=001 be_search (52) syncrepl_entry: rid=001 uid=user69,ou=People,dc=example,dc=com null_callback : error code 0x34 syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com (52) syncrepl_entry: rid=001 be_add uid=user69,ou=People,dc=example,dc=com failed (52) do_syncrepl: rid=001 rc 52 retrying (4 retries left) conn=1004 op=2 UNBIND conn=1004 fd=15 closed connection_read(15): no connection! connection_read(15): no connection!

1 0

(ITS#6998) MozNSS: when server certificate is not required, ignore expired issuer errors
by jvcelak＠redhat.com 20 Jul '11

20 Jul '11

Full_Name: Jan Vcelak Version: 2.4.26 OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-nss-ignore-issuer-expiration-110720… Submission from: (NULL) (209.132.186.34) Hello. When the server certificate validity is not required in a TLS session (e.g. TLS_REQCERT is set to 'never'), expired certificate of the issuer of the server certificate causes the connection to be terminated. Uploaded patch fixes this by adding SEC_ERROR_EXPIRED_ISSUER_CERTIFICATE error to the list of ignored errors, when the certificate is not being checked. The patch is created against OPENLDAP_REL_ENG_2_4 branch. Jan

1 0

Re: (ITS#6770) Proxy authorization fails with SASL-GSSAPI
by c.waeschenfelder＠websale.de 20 Jul '11

20 Jul '11

> Something in this area should have been fixed in master code; some fixes > may have been released in 2.4.26. Can you indicate what version you're > using? In case you're using the latest, can you test with master code? > > p. The problem seems already solved in 2.4.26. The authorization seems to work reliable now, I couldn't recognize any authorization errors after upgrading to 2.4.26.

1 0

Re: (ITS#6770) Proxy authorization fails with SASL-GSSAPI
by masarati＠aero.polimi.it 20 Jul '11

20 Jul '11

Please keep replies in cc with the ITS. On 07/20/2011 10:28 AM, Christian Wäschenfelder wrote: > >> Something in this area should have been fixed in master code; some fixes >> may have been released in 2.4.26. Can you indicate what version you're >> using? In case you're using the latest, can you test with master code? >> >> p. >> > > At the moment I'm using 2.4.23-7 on debian squeeze. > I'll try it with 2.4.26 and master code. > > Ahhm... were can I get the master code, just download via git? yes. p.

1 0

Re: (ITS#6770) Proxy authorization fails with SASL-GSSAPI
by masarati＠aero.polimi.it 19 Jul '11

19 Jul '11

> Same problem here: > > If I use the cn=config style, proxy authorization works directly after > configuring it. > If I reboot the slave server the authorization fails to work and the > bindmethod switches from SASL/GSSAPI to SIMPLE. > > If I delete the configuration directory /etc/ldap/slapd.d and use a > simple /etc/ldap/slapd.conf and make the same configuration the old way > everything keeps working after reboots. > > So I think there is a Problem while loading the cn=config configuration. Something in this area should have been fixed in master code; some fixes may have been released in 2.4.26. Can you indicate what version you're using? In case you're using the latest, can you test with master code? p.

1 0

(ITS#6997) Segmentation fault when using slapo-rwm and slapo-chain
by mgaupp＠googlemail.com 19 Jul '11

19 Jul '11

Full_Name: Manuel Gaupp Version: 2.4.26 OS: Linux 2.6.18 (CentOS 5.6 x86_64) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.208.112.253) Under the following circumstances OpenLDAP crashes when a chained search does not return with result code 0: - "rwm" overlay used in a global context - "chain" overlay used in a database specifix context (gdb) bt #0 0x0000000400040004 in ?? () #1 0x000000000042e5c7 in slap_cleanup_play (op=0x197834b0, rs=0x42a07ca0) at result.c:539 #2 0x000000000042ef9b in send_ldap_response (op=0x197834b0, rs=0x42a07ca0) at result.c:724 #3 0x000000000042fcf9 in slap_send_ldap_result (op=0x197834b0, rs=0x42a07ca0) at result.c:851 #4 0x00000000004d982a in ldap_chain_response (op=0x197834b0, rs=0x42a07ca0) at chain.c:1165 #5 0x00000000004820ca in over_back_response (op=0x197834b0, rs=0x42a07ca0) at backover.c:237 #6 0x000000000042e535 in slap_response_play (op=0x197834b0, rs=0x42a07ca0) at result.c:505 #7 0x000000000042ef78 in send_ldap_response (op=0x197834b0, rs=0x42a07ca0) at result.c:579 #8 0x000000000042fcf9 in slap_send_ldap_result (op=0x197834b0, rs=0x42a07ca0) at result.c:851 #9 0x00000000004928f0 in bdb_search (op=0x197834b0, rs=0x42a07ca0) at search.c:499 #10 0x0000000000482352 in overlay_op_walk (op=0x197834b0, rs=0x42a07ca0, which=op_search, oi=0x196f3bb0, on=0x0) at backover.c:671 #11 0x00000000004828b7 in over_op_func (op=0x197834b0, rs=0x42a07ca0, which=op_search) at backover.c:723 #12 0x0000000000421cf9 in fe_op_search (op=0x197834b0, rs=0x42a07ca0) at search.c:402 #13 0x0000000000482352 in overlay_op_walk (op=0x197834b0, rs=0x42a07ca0, which=op_search, oi=0x1970fd30, on=0x0) at backover.c:671 #14 0x00000000004828b7 in over_op_func (op=0x197834b0, rs=0x42a07ca0, which=op_search) at backover.c:723 #15 0x0000000000422505 in do_search (op=0x197834b0, rs=0x42a07ca0) at search.c:247 #16 0x000000000041fa95 in connection_operation (ctx=0x42a07d70, arg_v=<value optimized out>) at connection.c:1138 #17 0x0000000000503d5c in ldap_int_thread_pool_wrapper (xpool=0x196beee0) at tpool.c:685 #18 0x000000316820673d in start_thread () from /lib64/libpthread.so.0 #19 0x0000003167ad44bd in clone () from /lib64/libc.so.6 OpenLDAP 2.4.26 was built using: ./configure --enable-rewrite --enable-ldap --enable-rwm --enable-bdb This issue can be reproduced using the following configuration (referred as 'slapd.conf.proxy') ------------------------------------------ overlay rwm # There might be some rewrite directives database bdb suffix "o=example" rootdn "cn=admin,o=example" rootpw secret directory /root/db.proxy overlay chain chain-return-error true chain-uri "ldap://localhost:38977" ------------------------------------------ The process is started on port 389 with plain ldap /usr/local/libexec/slapd -f slapd.conf.proxy -h "ldap://localhost:389" Create the following entry in this server: dn: cn=ldap,o=example objectclass: extensibleObject objectclass: referral ref: ldap://localhost:38977/cn=real,o=example To reproduce the error there has to be another server where the referral points to. It contains the following minimal configuration: (referred as 'slapd.conf.server') ------------------------------------------ database bdb suffix "cn=real,o=example" rootdn "cn=admin,cn=real,o=example" rootpw secret directory /root/db.server ------------------------------------------ The process is started on port 38977 with plain ldap /usr/local/libexec/slapd -f slapd.conf.server -h "ldap://localhost:38977" Using the following ldapsearch, slapd crashes: ldapsearch -h localhost -p 389 -D "cn=admin,o=example" -w secret \ -x -b "ou=abc,cn=ldap,o=example" 1.1 Whereas the following ldapsearch returns with "success" ldapsearch -h localhost -p 389 -D "cn=admin,o=example" -w secret \ -x -b "cn=ldap,o=example" 1.1 Deactivating the "rwm" overlay prevents from this issue. So I think the problem can be found somewhere in the rwm sources. -- Manuel

1 0

RE: (ITS#6985) sssvlv / greaterThanOrEqual problem
by ctcard＠hotmail.com 18 Jul '11

18 Jul '11

> ctcard(a)hotmail.com wrote: > > Full_Name: Chris Card > > Version: HEAD (on 30 June 2011) > > OS: Centos 5.4 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (91.194.158.133) > > > > > > I am running slapd built from HEAD on June 30th 2011, with back-sql backend, and > > pcache and sssvlv overlays. > > > > I am submitting a search request with vlv and sort controls. > > > > In the sort control I am specifying attributeType cn and orderingRule > > caseIgnoreOrderingMatch. > > > > If I specify 'd' as the greaterThanOrEqual value of the vlv control, beforeCount > > 0 and afterCount 4, I get 5 entries with the following cns returned: > > > > Dave Smith > > Fiona Smith > > Glynis Smith > > Jane Smith > > Jennifer Smith > > > > If I specify 'g' in greaterThanOrEqual I get: > > > > Glynis Smith > > Jane Smith > > Jennifer Smith > > Jim Smith > > Mark Smith > > > > But if I specify 'f' I get no entries returned. > > Now fixed in git master. > Thanks, I've tried that fix and it works (and is simpler than my suggestion). Chris

1 0

RE: (ITS#6985) sssvlv / greaterThanOrEqual problem
by ctcard＠hotmail.com 18 Jul '11

18 Jul '11

> > > >>>>>> Looking at the code in sssvlv.c, it uses tavl_find3() to search the values, but the > >>>>>> code in tavl_find3() looks to me that it only works properly with an exact match > >>>>>> type of matching rule: > >>>>>> > >>>>>> Avlnode * > >>>>>> tavl_find3( Avlnode *root, const void *data, AVL_CMP fcmp, int *ret ) > >>>>>> { > >>>>>> int cmp = -1, dir; > >>>>>> Avlnode *prev = root; > >>>>>> > >>>>>> while ( root != 0&& (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { > >>>>>> prev = root; > >>>>>> dir = cmp> 0; > >>>>>> root = avl_child( root, dir ); > >>>>>> } > >>>>>> *ret = cmp; > >>>>>> return root ? root : prev; > >>>>>> } > >>>>>> > >>>>>> since the while loop terminates when the fcmp function returns 0 (i.e. exact match). > >>>>>> > >>>>> > >>>>> I think I've worked out where the problem is. > >>>>> Firstly, there's a comment before tavl_find3() saying > >>>>> /* > >>>>> * tavl_find2 - returns Avlnode instead of data pointer. > >>>>> * tavl_find3 - as above, but returns Avlnode even if no match is found. > >>>>> * also set *ret = last comparison result, or -1 if root == NULL. > >>>>> */ > >>>>> > >>>>> but the "or -1 if root == NULL" is not done. > >> > >> Not true; since cmp is initialized to -1, it will return -1 when the function > >> is entered with root == NULL. There is no bug in this part.It depends how you read the comment. > > I wrote the code and the comment; it does what I intended it to do. There is > no "depends" about it. The comment is ambiguous, but in any case the code as it stands doesn't work with the way tavl_find3() is called in sssvlv.c.For example:if cmp > 0 when the while loop terminates, the sssvlv code treats that as if the search failed, whereas the search oughtto return the closest node > search node. My suggested patch does work with the way tavl_find3() is called in sssvlv.c, but I'd be happy with adding a new function, tavl_find4() say, to implement this functionality. In that case I'd suggest it look like this: Avlnode *tavl_find4( Avlnode *root, const void *data, AVL_CMP fcmp){ int cmp, dir; Avlnode *prev = root; Avlnode *prev_gt = 0; while ( root != 0 && (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { prev = root; dir = cmp > 0; prev_gt = (dir ? prev_gt : root); root = avl_child( root, dir ); } return (root ? root : (prev_gt ? prev_gt : prev));} tavl_find4() always returns the first node >= the search node, unless the search node is > all the nodes in the tree, in which case the last node is returned (or null if the tree is empty). Then replace cur_node = tavl_find3( so->so_tree, sn, node_cmp, &j ); /* didn't find >= match */ if ( j > 0 ) cur_node = NULL;by cur_node = tavl_find4( so->so_tree, sn, node_cmp); in sssvlv.c. Chris

1 0

Re: (ITS#6985) sssvlv / greaterThanOrEqual problem
by hyc＠symas.com 18 Jul '11

18 Jul '11

ctcard(a)hotmail.com wrote: > Full_Name: Chris Card > Version: HEAD (on 30 June 2011) > OS: Centos 5.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (91.194.158.133) > > > I am running slapd built from HEAD on June 30th 2011, with back-sql backend, and > pcache and sssvlv overlays. > > I am submitting a search request with vlv and sort controls. > > In the sort control I am specifying attributeType cn and orderingRule > caseIgnoreOrderingMatch. > > If I specify 'd' as the greaterThanOrEqual value of the vlv control, beforeCount > 0 and afterCount 4, I get 5 entries with the following cns returned: > > Dave Smith > Fiona Smith > Glynis Smith > Jane Smith > Jennifer Smith > > If I specify 'g' in greaterThanOrEqual I get: > > Glynis Smith > Jane Smith > Jennifer Smith > Jim Smith > Mark Smith > > But if I specify 'f' I get no entries returned. Now fixed in git master. -- -- 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#6985) sssvlv / greaterThanOrEqual problem
by hyc＠symas.com 18 Jul '11

18 Jul '11

Chris Card wrote: > >>>>>> Looking at the code in sssvlv.c, it uses tavl_find3() to search the values, but the >>>>>> code in tavl_find3() looks to me that it only works properly with an exact match >>>>>> type of matching rule: >>>>>> >>>>>> Avlnode * >>>>>> tavl_find3( Avlnode *root, const void *data, AVL_CMP fcmp, int *ret ) >>>>>> { >>>>>> int cmp = -1, dir; >>>>>> Avlnode *prev = root; >>>>>> >>>>>> while ( root != 0&& (cmp = (*fcmp)( data, root->avl_data )) != 0 ) { >>>>>> prev = root; >>>>>> dir = cmp> 0; >>>>>> root = avl_child( root, dir ); >>>>>> } >>>>>> *ret = cmp; >>>>>> return root ? root : prev; >>>>>> } >>>>>> >>>>>> since the while loop terminates when the fcmp function returns 0 (i.e. exact match). >>>>>> >>>>> >>>>> I think I've worked out where the problem is. >>>>> Firstly, there's a comment before tavl_find3() saying >>>>> /* >>>>> * tavl_find2 - returns Avlnode instead of data pointer. >>>>> * tavl_find3 - as above, but returns Avlnode even if no match is found. >>>>> * also set *ret = last comparison result, or -1 if root == NULL. >>>>> */ >>>>> >>>>> but the "or -1 if root == NULL" is not done. >> >> Not true; since cmp is initialized to -1, it will return -1 when the function >> is entered with root == NULL. There is no bug in this part.It depends how you read the comment. I wrote the code and the comment; it does what I intended it to do. There is no "depends" about it. -- -- 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