openldap-bugs February 2016

openldap-bugs@openldap.org

15 participants
45 discussions

Re: (ITS#8378) idlcache in back hdb doesn't update existing caches on a subtree rename, causing bad search results
by jonathan＠phillipoux.net 29 Feb '16

29 Feb '16

The patch I originally sent works only for MODRDN operations, but causes a segfault on plain old ADD operations in some cases. This is caused by the hdb_dn2id_children function trying to update dkids inside a non-initialised structure. I figure that if we don't have the structure we don't need to update it, since this function is mostly a "search" function. Hope that makes sense. A new patch is here: ftp://www.openldap.org/incoming/openldap-dn2id-modrdn-idlcache-sub-delete-2… Jonathan

1 0

Re: (ITS#8303) An Asynchronous meta back-end for OpenLDAP
by nivanova＠symas.com 29 Feb '16

29 Feb '16

This patch fixes a problem in the closing of timed-out connections to targets in back-asyncmeta. If a a_metaconn is still in use for another target, the connections to other targets might not be reset while the mc is still active, even if these targets are no longer in use. This patch introduces counters for pending operations per a_metasingleconn, and resets a metasingleconn if it has timed out and has no pending operations. ftp://ftp.openldap.org/incoming/nadezhda-ivanova-160229.patch

1 0

Re: RE : Re: Fwd: (ITS#8331) Download mirror list needs updating
by hyc＠symas.com 26 Feb '16

26 Feb '16

For tracking: David Coutadeur wrote: > > Hi Howard, > > Job done. The repository is available at: > http://repository.linagora.com/OpenLDAP/ > > > Regards, > > David > > Le 17/02/2016 14:59, Howard Chu a écrit : >> David Coutadeur wrote: >>> >>> Hi Howard, >>> >>> I didn't came back on you with that, but the proposition is still opened >>> if it is ok for you. >> >> Sure, sounds great. >> >> It turns out to be very simple, just use rsync. The set of available >> targets can be seen using >> rsync --list-only rsync://openldap.org >> >> The releases are in OpenLDAP-ftp. The CVS repo is also available but >> that's only of historical interest since we're now on git. >> >>> >>> David >>> >>> >>> Le 10/12/2015 09:08, dcoutadeur a écrit : >>>> Ok, thank you for the reply. >>>> Let me know when you have the information. >>>> >>>> David >>>> >>>> >>>> >>>> -------- Message d'origine -------- De : Howard Chu >>>> <hyc(a)symas.com> Date : 08/12/2015 17:49 (GMT+01:00) À >>>> : David Coutadeur <dcoutadeur(a)linagora.com> Objet : Re: >>>> Fwd: (ITS#8331) Download mirror list needs updating >>>> >>>> >>>> >>>> David Coutadeur wrote: >>>> > >>>> > Hi Howard, >>>> >>>> Hi David, thanks for the offer. I'm checking with Kurt to see what the >>>> procedure is for initializing a mirror. >>>> > >>>> > Linagora (France) would be very interested to host a new mirror >>>> for OpenLDAP. >>>> > Do you have an idea of how many connections we should support ? >>>> And what >>>> > bandwidth ? I have made some statistics on an active mirror to >>>> find out the >>>> > data volume. For now it is about 1GB, so I assume 10 GB will be >>>> sufficient for >>>> > many years ? >>>> > >>>> > If you have one, can you also give me a procedure / indications >>>> for building >>>> > the platform ? >>>> > >>>> > Regards, >>>> > >>>> > >>>> > Le 04/12/2015 16:04, Howard Chu a écrit : >>>> >> A number of the mirror sites have gone offline over the years. >>>> Anyone >>>> >> interested in running a new mirror for us? >>>> >> >>>> >> -------- Forwarded Message -------- >>>> >> Subject: (ITS#8331) Download mirror list needs updating >>>> >> Date: Fri, 04 Dec 2015 10:01:12 +0000 >>>> >> From: andrew.findlay(a)skills-1st.co.uk >>>> >> To: openldap-its(a)OpenLDAP.org >>>> >> >>>> >> Full_Name: Andrew Findlay >>>> >> Version: >>>> >> OS: >>>> >> URL: ftp://ftp.openldap.org/incoming/ >>>> >> Submission from: (NULL) (2001:8b0:8d0:f7e1::94) >>>> >> >>>> >> >>>> >> The Netherlands mirror has vanished: ftp.nl.uu.net does not >>>> resolve in DNS. >>>> >> >>>> >> >>>> >> >>>> >> >>>> > >>>> > >>>> >>>> >>>> -- >>>> -- Howard Chu >>>> CTO, Symas Corp. http://www.symas.com >>>> Director, Highland Sun http://highlandsun.com/hyc/ >>>> Chief Architect, OpenLDAP http://www.openldap.org/project/ >>>> >>>> >>>> >>>> David Coutadeur wrote: >>>>> >>>>> Hi Howard, >>>> >>>> Hi David, thanks for the offer. I'm checking with Kurt to see what the >>>> procedure is for initializing a mirror. >>>>> >>>>> Linagora (France) would be very interested to host a new mirror for >>>>> OpenLDAP. >>>>> Do you have an idea of how many connections we should support ? And >>>>> what >>>>> bandwidth ? I have made some statistics on an active mirror to find >>>>> out the >>>>> data volume. For now it is about 1GB, so I assume 10 GB will be >>>>> sufficient for >>>>> many years ? >>>>> >>>>> If you have one, can you also give me a procedure / indications for >>>>> building >>>>> the platform ? >>>>> >>>>> Regards, >>>>> >>>>> >>>>> Le 04/12/2015 16:04, Howard Chu a écrit : >>>>>> A number of the mirror sites have gone offline over the years. Anyone >>>>>> interested in running a new mirror for us? >>>>>> >>>>>> -------- Forwarded Message -------- >>>>>> Subject: (ITS#8331) Download mirror list needs updating >>>>>> Date: Fri, 04 Dec 2015 10:01:12 +0000 >>>>>> From: andrew.findlay(a)skills-1st.co.uk >>>>>> To: openldap-its(a)OpenLDAP.org >>>>>> >>>>>> Full_Name: Andrew Findlay >>>>>> Version: >>>>>> OS: >>>>>> URL: ftp://ftp.openldap.org/incoming/ >>>>>> Submission from: (NULL) (2001:8b0:8d0:f7e1::94) >>>>>> >>>>>> >>>>>> The Netherlands mirror has vanished: ftp.nl.uu.net does not resolve >>>>>> in DNS. -- -- 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#8378) idlcache in back hdb doesn't update existing caches on a subtree rename, causing bad search results
by jonathan＠phillipoux.net 22 Feb '16

22 Feb '16

Full_Name: Jonathan Clarke Version: 2.4.44 OS: GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (176.182.31.158) Hi there, I found a bug in the handling of idl_cache when doing a MODRDN operation on an entry with children. The existing code to add an entry in hdb_dn2id_add (dn2id.c) cleverly updates any existing IDL caches on the new parent and any grand-parents, both for "one" and "sub" level searches by adding the new entry in those cache lists. However, if you MODRDN an entry that also has children, this same hdb_dn2id_add function is called, and will erroneously update the "sub" level search caches on the new parent and any grand-parents, adding only the new entry, and not it's children. The result is that a search that hits that IDL cache will return partial results, including the entry that was moved, but missing it's children. You can observe this behaviour by compiling a standard OpenLDAP server, configuring a simple hdb backend, including a non-zero idlcachesize and running the following commands: 1) ldapadd < tesldldif 2) ldapsearch -b "ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration" -s sub objectClass=organizationalUnit 3) ldapmodrdn -s "ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration" "ou=1234,ou=Pending Inventories,ou=Inventorie2C2Ccn=rudder-configuration" "ou=1234" 4) ldapsearch -b "ou=Accepted Inventories,ou=Inventories,cn=rudder-configuration" -s sub objectClass=organizationalUnit It is important to run the initial search in step 2, before the MODRDN operation itself, to ensure an IDL cache entry is created for that search. The final search in step 4 will not show the sub-entry ou=1234-sub,ou=1234. The test.ldif file is here: ftp://ftp.openldap.org/incoming/test.ldif I've created a quick'n'dirty patch to hide this issue, which detects the situation (if adding an entry that already has children, this is when the bug occurs) and simply removes the IDL cache to avoid future searches using it. It's available here: ftp://ftp.openldap.org/incoming/openldap-dn2id-modrdn-idlcache-sub-delete.p…. A better solution would probably be to write the code to add each child of the new entry to existing caches, but I couldn't immediately see how to do this. Hopefully my patch above will easily show where this needs doing. Regards, Jonathan

1 0

(ITS#8377) Normalized 'olcDbIndex' values
by michael＠stroeder.com 22 Feb '16

22 Feb '16

Full_Name: Version: master OS: URL: Submission from: (NULL) (213.240.182.49) A suggestion for 2.5: Index lines read from slapd.conf should be converted to normalized 'olcDbIndex' values. With this approach it would be possible to determine index configuration for a certain attribute type. Likewise the format of accepted attribute values should be constrained. Example from slapd.conf: index foo,bar eq,sub would be normalized to 4 values: olcDbIndex: foo eq olcDbIndex: foo sub olcDbIndex: bar eq olcDbIndex: bar sub

1 0

(ITS#8376) Use getaddrinfo to resolve FQDN
by hguo＠suse.com 22 Feb '16

22 Feb '16

Full_Name: Howard Guo Version: 2.4.44 OS: openSUSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.135.221.2) In a pure IPv6 environment, if LDAP is used as the host resolve, the host may hang when it attempts to resolve its own host name due to usage of gethostbyname*, in the following sequence of events: nss_ldap: locks mutex nss_ldap: calls libldapA-A-> libldap: gethostbyname -> nss_ldap: lock mutex and hang See patch file "howard-guo-160222.patch".

1 0

(ITS#8375) paged results control results in full db search?
by geert＠hendrickx.be 21 Feb '16

21 Feb '16

Full_Name: Geert Hendrickx Version: 2.4.44 OS: Linux URL: http://www.openldap.org/lists/openldap-technical/201602/msg00094.html Submission from: (NULL) (2a02:1810:4d03:d00:18e9:3ca5:a68f:c7f4) We found an odd issue when using LDAP Admin (www.ldapadmin.org), which by defaults uses the paged results control (RFC 2696) to limit search results. This client initially issues an objectclass=* search with one-level scope to list the first-level objects/trees on the LDAP DIT, which you can then browse/expand by clicking on them. On a large db, we noticed this initial search hits the timelimit, even though the equivalent command line search is instant. I found the difference is in using the paged result control: ldapsearch -s one -E \!pr=100 objectclass=\* objectclass => slow ldapsearch -s one objectclass=\* objectclass => fast The slapd stats+trace logging of each is in attachment. Notice the large number of objects being skipped with "scope not okay" in the first, where this does not happen in the second. This slows down the search, and on a very large db, makes it exceed the configured 60 seconds timelimit. A third variant, setting the sizelimit explicitly, avoids the issue: ldapsearch -s one -E \!pr=100 -z 100 objectclass=\* objectclass => fast Is this expected behaviour?

1 0

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com 20 Feb '16

20 Feb '16

Ok, retested with latest code built from source. I also reconfirmed using a publicly available openldap server, to make sure it isn't something stupid I am doing locally. So you can reproduce easily, the test pseudo code is: ldap_initialize (ldaps://ldap.andrew.cmu.edu) ldap_set_option LDAP_OPT_X_TLS_REQUIRE_CERT (enumerate options) ldap_sasl_bind_s ldap_initialize (ldap://128.2.11.104) ldap_set_option LDAP_OPT_X_TLS_REQUIRE_CERT (enumerate options) ldap_start_tls_s ldap_sasl_bind_s The results are: Server with valid certificate, all values of LDAP_OPT_X_TLS_REQUIRE_CERT for both ldaps and ldap+starttls connect. This is what I would expect. Server with invalid certificate (IP does not match the cert FQDN), only NEVER and ALLOW values of LDAP_OPT_X_TLS_REQUIRE_CERT succeed for ldaps (this is what I would expect) however all values of LDAP_OPT_X_TLS_REQUIRE_CERT for ldap+starttls succeed, which is not what I would expect: I think that the certificate check should fail the connection, as per the ldaps behaviour. Martin...

1 0

RE: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by dog＠pavlov.com 20 Feb '16

20 Feb '16

Hi, This is a piece of code that I'm working on, rather than any bundled commands. The code works just fine (has for months) however I noticed in unit testing the operations empirically that the LDAP_OPT_X_TLS_REQUIRE_CERT option was handled differently depending on whether the TLS was provided implicitly over an ldaps: URI, or explicitly on an ldap: URI with STARTTLS. The pseudo sequence of functions is as follows: ldap_initialize ldap_set_option (various) if uri != ldaps: then ldap_start_tls_s ldap_sasl_bind_s Martin...

1 0

Re: (ITS#8374) LDAP_OPT_X_TLS_REQUIRE_CERT handling differences between ldaps:// and STARTTLS
by hyc＠symas.com 20 Feb '16

20 Feb '16

dog(a)pavlov.com wrote: > Hi, > > The box was running Ubuntu vivid so bumped to wily, which took openldap to 2.4.41, and the results are identical. > > If I get time I'll run up a test platform and install from source, then drop you a line with the results. What commands are you testing with? Are you using STARTTLS as a critical extension? If not, failures will be ignored. Note that this is already documented. -- -- 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

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs February 2016