openldap-bugs

openldap-bugs@openldap.org

1 participants
21000 discussions

(ITS#7050) meta stop at the first unreachable candidate
by victor.gattegno＠gmail.com 23 Sep '11

23 Sep '11

Full_Name: victor gattegno Version: 2.4.26 OS: CentOS 5.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (88.181.196.138) Hello, With OpenLDAP 2.4.26, as soon as a candidate directory is unreachable, other directories are not requested by the proxy ; that problem doesn't occur in 2.4.23. It is described in: http://www.openldap.org/lists/openldap-technical/201108/msg00221.html and there is a complete example in: http://www.openldap.org/lists/openldap-technical/201109/msg00044.html I modified openldap-2.4.26/servers/slapd/back-meta/search.c (lines 192 to 198) as follow, and then the problem is solved. I replaced in OpenLDAP 2.4.26 search.c, (from line 192): switch ( rc ) { case LDAP_SUCCESS: break; case LDAP_UNAVAILABLE: goto down; default: goto other; } by (like it was in 2.4.23): if ( rc != LDAP_SUCCESS ) { goto down; } Here is the diff : 192,195c192 < switch ( rc ) { < case LDAP_SUCCESS: < break; < case LDAP_UNAVAILABLE: --- > if ( rc != LDAP_SUCCESS ) { 197,198d193 < default: < goto other; Rgds.

1 0

(ITS#7049) DEL/LDAP_SYNC_DELETE race touching entryCSN
by ebackes＠symas.com 22 Sep '11

22 Sep '11

Full_Name: Emily Backes Version: 2.4.26 OS: any URL: Submission from: (NULL) (76.88.107.46) Similar to the recent overlay fixes to prevent updating entryCSN/contextCSN on local changes, delete operations can cause inappropriate CSN setting on remote servers. Given a multi-master setup (normal syncrepl tested), so that each server has a serverID set, with no overlays loaded other than syncprov, set up two or more threads of delete operations; three or more seems to most reliably reproduce the problem on the systems I've tested. As the deletes are happening, the server1 side should of course show it's entryCSN updating: dn: dc=example,dc=com contextCSN: 20110923044343.412634Z#000000#001#000000 This should of course be mirrored on the server2 side with contextCSN exactly matching the set of CSN's from the server1 side. Instead, after enough concurrent deletes to hit the race: dn: dc=example,dc=com contextCSN: 20110923044343.412634Z#000000#001#000000 contextCSN: 20110923044349.314803Z#000000#002#000000 This happens even though server2 has never received any local write operations (or indeed any connection other than the syncrepl search from server1 and my searches to retrieve contextCSN). Again, no overlays are loaded. This breaks syncrepl's assumptions and can result in other replication problems as a result of CSN desync. Working on tracing out exactly where it goes awry...

1 0

Re: (ITS#7047) slapd crash on bad indexed translucent
by Pierangelo Masarati 21 Sep '11

21 Sep '11

Can you reproduce with latest release/master? Can you provide a minimal configuration+data that allows to reproduce the issue? p.

1 0

Re: (ITS#7048) Non root binding causes assert
by Pierangelo Masarati 21 Sep '11

21 Sep '11

> Full_Name: Aitor Carrera Please check with latest release (or master code); please upload patches according to <http://www.openldap.org/devel/contributing.html>. p.

1 0

Re: (ITS#7048) Non root binding causes assert
by aitor.carrera＠edosoftfactory.com 21 Sep '11

21 Sep '11

--20cf307abe69d114a404ad78b34e Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable With this pacth it is solved, we added a precompiler macro to contribute th= e patch because we are not sure about security issues related this problem. META_BACK_REFCNT_MUST_BE_ZERO_FOR_INVALIDATING_EXPIRED_CONNECTION =3D> It m= ust be defined for solving this issue diff -Naur openldap-2.4.21.orig/servers/slapd/back-meta/conn.c openldap-2.4.21/servers/slapd/back-meta/conn.c --- openldap-2.4.21.orig/servers/slapd/back-meta/conn.c 2011-07-26 13:40:40.989376998 +0200 +++ openldap-2.4.21/servers/slapd/back-meta/conn.c 2011-07-26 13:51:40.537383269 +0200 @@ -1156,6 +1156,9 @@ mc =3D NULL; } else { +#ifdef META_BACK_REFCNT_MUST_BE_ZERO_FOR_INVALIDATING_EXPIRED_CONNECTION + if ( mc->mc_refcnt =3D=3D 0) +#endif if ( ( mi->mi_conn_ttl !=3D 0 && op->o_time > mc->mc_create_time + mi->mi_conn_ttl ) || ( mi->mi_idle_timeout !=3D 0 && op->o_time > mc->mc_time + mi->mi_idle_timeout ) ) { Regards -------------------------------------------------------- Aitor Carrera Hern=E1ndez - Edosoft Factory Telf. +34 828021575 Fax. +34 828066081 Antonio Mar=EDa Manrique 3, Planta 2 - Oficina 6. 35011 Las Palmas de Gran Canaria -------------------------------------------------------- --20cf307abe69d114a404ad78b34e Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div>With this pacth it is solved, we added a precompiler macro to contribu= te the patch because we are not sure about security issues related this pro= blem.</div><div><br></div><div>META_BACK_REFCNT_MUST_BE_ZERO_FOR_INVALIDATI= NG_EXPIRED_CONNECTION =3D> It must be defined for solving this issue</di= v> <div><br></div><div><br></div><div><span class=3D"Apple-style-span" style= =3D"font-family: 'Times New Roman'; font-size: medium; "><pre style= =3D"word-wrap: break-word; white-space: pre-wrap; ">diff -Naur openldap-2.4= .21.orig/servers/slapd/back-meta/conn.c openldap-2.4.21/servers/slapd/back-= meta/conn.c --- openldap-2.4.21.orig/servers/slapd/back-meta/conn.c 2011-07-26 13:40:40= .989376998 +0200 +++ openldap-2.4.21/servers/slapd/back-meta/conn.c 2011-07-26 13:51:40.5373= 83269 +0200 @@ -1156,6 +1156,9 @@ mc =3D NULL; =20 } else { +#ifdef META_BACK_REFCNT_MUST_BE_ZERO_FOR_INVALIDATING_EXPIRED_CONNECTION + if ( mc->mc_refcnt =3D=3D 0) +#endif if ( ( mi->mi_conn_ttl !=3D 0 && op->o_time > mc->= mc_create_time + mi->mi_conn_ttl ) || ( mi->mi_idle_timeout !=3D 0 && op->o_time > mc-&= gt;mc_time + mi->mi_idle_timeout ) ) {</pre><pre style=3D"word-wrap: break-word; white-space: pre-wrap; "><= br></pre><pre style=3D"word-wrap: break-word; white-space: pre-wrap; ">Rega= rds</pre></span></div><div><br></div>--------------------------------------= ------------------<br> Aitor Carrera Hern=E1ndez - Edosoft Factory<br>Telf. +34 828021575<br>Fax. = +34 828066081<br>Antonio Mar=EDa Manrique 3, Planta 2 - Oficina 6.<br>35011= Las Palmas de Gran Canaria<br>--------------------------------------------= ------------<br> --20cf307abe69d114a404ad78b34e--

1 0

(ITS#7048) Non root binding causes assert
by aitor.carrera＠edosoftfactory.com 21 Sep '11

21 Sep '11

Full_Name: Aitor Carrera Version: 2.4.21 OS: SLES10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (95.126.219.248) When we use a non root user to bind, with multiple threads and some concurrent proxies 1 .- In meta_back_bind_op_result method, in back-meta bind.c file the assert "assert( LDAP_BACK_CONN_BINDING( msc ) );" is evaluated to false. 2.- Next, calls meta_back_cancel (bind.c) and then ldap_abandon_ext and other assert is evaluated to false: slapd: sasl.c:74: ldap_sasl_bind: Assertion `ld != ((void *)0)' failed. That crash the slapd.

1 0

Re: (ITS#7027) [PATCH] Implement priority/weigh for DNS SRV records
by james.leddy＠redhat.com 20 Sep '11

20 Sep '11

> In addition, random seed has to be initialized, otherwise the behavior > is predictable. I didn't think it too big of a deal, since it doesn't have to be cryptographically random. I can submit a patch to call srandom() first. > On the other side, I do not think that calling srand() > in libldap is a good idea. The client application should do that. Or > is there any other option? The function ldap_domain2hostlist returns a list of strings, there isn't any weight/prio information for the client to act on. Furthermore the weight prio section was commented out, I figured the library was the right place to do it. The algo specified in rfc2782 is detailed, and specifies a random number should be generated., I didn't want to implement it because it results in sorting once by prio, once by weight instead of one sort that does both. -- James M. Leddy Technical Account Manager Red Hat Inc.

1 0

(ITS#7047) slapd crash on bad indexed translucent
by hugo.monteiro＠fct.unl.pt 20 Sep '11

20 Sep '11

Full_Name: Hugo Monteiro Version: 2.4.23 OS: Debian Squeeze 64bits URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.136.124.150) Performing a substring query on a locally stored attribute of a translucent database, with only equality index will result on slapd crash. We have a translucent database set up to handle samba attributes and we observed that some client operations would crash slapd (like when performing user enumeration, while changind folder ACLs). The last logged query was "(&(objectClass=sambaGroupMapping)(sambaGroupType=4)(sambaSID=<OUR_DOMAINSID_HERE>*))" As per samba documentation we only had equality index on sambaSID attribute. We have then reconfigured that attribute to use eq,sub,pres indexes, ran slapindex on the database and slapd stopped crashing with that query.

1 0

Re: (ITS#7027) [PATCH] Implement priority/weight for DNS SRV records
by jvcelak＠redhat.com 20 Sep '11

20 Sep '11

On Wednesday 24 August 2011 21:28:03, James Leddy wrote: > on incoming ftp There is a typo in the patch: + hostent_head[hostent_count].priority=priority; -+ hostent_head[hostent_count].weight=priority; ++ hostent_head[hostent_count].weight=weight; + hostent_head[hostent_count].port=port; + strncpy(hostent_head[hostent_count].hostname, host,255); + hostent_count=hostent_count+1; In addition, random seed has to be initialized, otherwise the behavior is predictable. On the other side, I do not think that calling srand() in libldap is a good idea. The client application should do that. Or is there any other option? Jan

1 0

(ITS#7046) OpenLDAP logs nothing at info priority, excessive at debug priority
by nick.urbanik＠optusnet.com.au 19 Sep '11

19 Sep '11

Full_Name: Nick Urbanik Version: 2.3.43-12 and 2.4.23-15 OS: CentOS 5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.10.68.69) To my great surprise, OpenLDAP logs nothing at info priority, but excessive amounts at debug priority, even when the loglevel is set to stats. Here are examples of the size of log files holding *nothing* but OpenLDAP stats logging in a production server: # ls -lSr | tail -n4 -rw------- 1 root root 7160148590 Jul 28 10:48 ldap -rw------- 1 root root 24102619198 Jul 26 04:02 ldap.3 -rw------- 1 root root 25034865261 Jul 27 04:02 ldap.2 -rw------- 1 root root 25504838803 Jul 28 04:02 ldap.1 $ bc -ql scale = 6 25504838803 / 2^30 23.753232 In other words, we were getting nearly 24 gigabytes of logging *each* *day*. I raised this in the openldap-technical mailing list: http://www.openldap.org/lists/openldap-technical/201107/msg00205.html but found that this is by design: http://www.openldap.org/lists/openldap-technical/201109/msg00223.html OpenLDAP should log at info priority at least the following: * when it is starting up * when it is shutting down cleanly * any errors, indicating issues that the sys admin should pay attention to * (perhaps): one line for each connection.

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