openldap-bugs

openldap-bugs@openldap.org

1 participants
21065 discussions

(ITS#6792) rwm with broken config suppresses LDAP response
by h.b.furuseth＠usit.uio.no 17 Jan '11

17 Jan '11

Full_Name: Hallvard B Furuseth Version: RE24, HEAD OS: Linux x86_64 URL: http://folk.uio.no/hbf/OpenLDAP/rwmhang-draft.txt Submission from: (NULL) (193.157.201.147) Submitted by: hallvard rwm suppresses the LDAP response message if rwm_response() fails. This hangs waiting for the response: include servers/slapd/schema/core.schema database monitor overlay rwm rwm-rewriteEngine on rwm-rewriteContext matchedDN # Rewrite to nonexistent $1 or broken DN rwm-rewriteRule ".*time.*" "cn=test,$1" : rwm-rewriteRule ".*" "urgle" : ldapcompare -x cn=hello,cn=time,cn=monitor l:x ldapsearch -xLLL -b cn=hello,cn=monitor The enclosed patch seems to fix it, but I've only looked briefly at what's going on.

1 0

(ITS#6791) Patch - Mozilla NSS - cert verify uses incorrect values
by rmeggins＠redhat.com 15 Jan '11

15 Jan '11

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-cert-verify-uses-incorrect-… Submission from: (NULL) (76.113.111.209) The cert verify routines were using type SECCertUsage instead of type SECCertificateUsage. The values are similar, and this was causing verify errors of SEC_ERROR_INADEQUATE_KEY_USAGE and SEC_ERROR_INADEQUATE_CERT_TYPE. MozNSS only checks the usage if the cert includes the usage extensions which is why I didn't see this error earlier. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#6790) Patch - Mozilla NSS - fix default cipher suite list
by rmeggins＠redhat.com 15 Jan '11

15 Jan '11

Full_Name: Rich Megginson Version: 2.4.23 (current CVS HEAD) OS: RHEL6 URL: ftp://ftp.openldap.org/incoming/openldap-2.4.23-fix-default-cipher-suite-li… Submission from: (NULL) (76.113.111.209) If no TLS cipher suites are specified, the list of default cipher suites used with moznss is somewhat lacking. This patch makes tls_m use the "DEFAULT" list, and adds more cipher suites to the default list. These patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Rich Megginson am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by hyc＠symas.com 14 Jan '11

14 Jan '11

Rein Tollevik wrote: > On 13.01.11 21.31, hyc(a)symas.com wrote: >> cmikk(a)qwest.net wrote: >>> On Sun, Dec 12, 2010 at 06:22:38PM +0100, Rein Tollevik wrote: >>>> On 11/19/10 23:55 , cmikk(a)qwest.net wrote: >>>> >>>>> will evaluate to true in cases where it should not. A quick fix would be to >>>>> compare directly against the CSN of the sessionlog's head: >>>> >>>> An extended version of this fix, which also ensures that the >>>> sessionlog is kept in csn order, is now in head. Please test, >>>> syncprov.c revision 1.320. >>> >>> Looks good to me. Thank you. >>> >>> I discovered this bug while trying to reproduce ITS#6717. >>> >>> I've attached a patch to that ITS which appears to fix >>> that problem. If you have the time, I'd appreciate some >>> feedback on that patch. The issue makes it very inefficient >>> to run a slave in refreshOnly mode with a multimaster / >>> mirrormode master. >>> >>> Best Regards, >> >> The current code is broken. > > Which current code? My patch for this its, or his patch for its#6717? We're only talking about this specific ITS here, and that comment applied to the ITS before my last patch. I reopened the ITS, patched again, and then marked it Test again. >>> Other than the patch I suggested (using the list head's >>> CSN value directly), I can think of two other approaches: >>> >>> 1) When adding an entry to the sessionlog, check >>> if sl_mincsn is empty. If it is, update sl_mincsn >>> to the new entry's CSN. >>> >>> 2) When initializing the sessionlog, set sl_mincsn >>> to the maximum contextCSN value of the underlying >>> database. >>> >>> #2 seems ideal from an efficiency standpoint, although it >>> differs from the algorithm the current code appears to be >>> intended to implement. >> >> We should have gone with #2. The problem scenario: >> >> 1: Provider and consumer in sync, both started fresh, sessionlog is empty. >> 2: stop consumer >> 3: write on provider >> 4: start consumer >> >> Result: the sessionlog is ignored, because the sl_head is newer than the >> consumer's cookie. >> >> After the consumer syncs, you can repeat steps 2-4 and see that the sessionlog >> is used from then on. > > Initializing sl_mincsn from the maximum csn won't do much good here, as > long as the (current) requirement to use the log is that the consumers > mincsn is greater or equal to sl_mincsn. Assuming there is more than > one csn in the set that is.. > Initializing with the minimum csn should cause the current log to be > used in this scenario. But, if the provider restarts between 3 and 4 it > would incorrectly appear that replaying the log would be sufficient to > bring the consumer in sync. A situation far worse than doing a refresh > when replaying the log would have been sufficient. Which is why I chose the maximum CSN. It will work fine in most cases. In the rare cases where it doesn't work, the log will be ignored and no harm is done. I.e., when writes are always received in order, the max CSN is the only one that matters. > More on possible fixes in my reply to your other message. > > Rein > -- -- 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#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by rein＠OpenLDAP.org 14 Jan '11

14 Jan '11

On 13.01.11 21.48, hyc(a)symas.com wrote: > rein(a)OpenLDAP.org wrote: >> On 09.12.10 09.09, masarati(a)aero.polimi.it wrote: >>> I think the best (blind) fix consists in only performing that test if >>> sl_mincsn is assigned a value; something like >> >> I'm looking at an extended fix. The problem with the current >> implementation is that is assumes the entries arrives in CSN order, >> which isn't necessarily true in a MMR configuration. >> >> My fix drops sl_mincsn, keeps the log queue in CSN order and compares >> with the head entry. It also wipes the log if it receives any changes >> without CSN (i.e during refresh). > > I'm not sure this latter is a good idea, in an MMR setup. In that case, we > should ensure that only CSNs matching the current SID are added to the log, > and we should always leave the log intact. I.e., the server is always > authoritative about its own writes. That implies that all servers must be interconnected in order to sync, which is a requirement I really hope nor think you want to introduce.. In any properly configured setup where the sessionlog is used I assume it is used on all the servers, and that the log is large enough to hold all changes occurring during reasonable consumer downtimes. In which case there will rarely be any refresh phases and wiping of the queue. My fix was more concerned with ensuring that replaying the log gave a correct synchronization than to use it in all possible cases. > But this kind of begs the question of whether the log should actually maintain > N mincsns, one for each known SID, the same way we do now for contextCSN. Yes, I've been wondering about that I too. I'm inclined to say that all entries in the log should hold the entire csn set as if was when the entry was added. The log could be initialized with an empty log entry holding the startup csn set, and kept in change fifo order. Mods without csn (i.e refresh mods) could then be stored on the log as well. But once one of them reaches the head of the list and gets removed then the list must be truncated up to the point where all remaining entries have a csn. The log should be reinitialized with the current csn set if the truncation caused it to end up empty. New consumers can replay the log if they present a csn set greater or equal to the set at the head of the log list. Rein

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by rein＠OpenLDAP.org 14 Jan '11

14 Jan '11

On 13.01.11 21.31, hyc(a)symas.com wrote: > cmikk(a)qwest.net wrote: >> On Sun, Dec 12, 2010 at 06:22:38PM +0100, Rein Tollevik wrote: >>> On 11/19/10 23:55 , cmikk(a)qwest.net wrote: >>> >>>> will evaluate to true in cases where it should not. A quick fix would be to >>>> compare directly against the CSN of the sessionlog's head: >>> >>> An extended version of this fix, which also ensures that the >>> sessionlog is kept in csn order, is now in head. Please test, >>> syncprov.c revision 1.320. >> >> Looks good to me. Thank you. >> >> I discovered this bug while trying to reproduce ITS#6717. >> >> I've attached a patch to that ITS which appears to fix >> that problem. If you have the time, I'd appreciate some >> feedback on that patch. The issue makes it very inefficient >> to run a slave in refreshOnly mode with a multimaster / >> mirrormode master. >> >> Best Regards, > > The current code is broken. Which current code? My patch for this its, or his patch for its#6717? >> Other than the patch I suggested (using the list head's >> CSN value directly), I can think of two other approaches: >> >> 1) When adding an entry to the sessionlog, check >> if sl_mincsn is empty. If it is, update sl_mincsn >> to the new entry's CSN. >> >> 2) When initializing the sessionlog, set sl_mincsn >> to the maximum contextCSN value of the underlying >> database. >> >> #2 seems ideal from an efficiency standpoint, although it >> differs from the algorithm the current code appears to be >> intended to implement. > > We should have gone with #2. The problem scenario: > > 1: Provider and consumer in sync, both started fresh, sessionlog is empty. > 2: stop consumer > 3: write on provider > 4: start consumer > > Result: the sessionlog is ignored, because the sl_head is newer than the > consumer's cookie. > > After the consumer syncs, you can repeat steps 2-4 and see that the sessionlog > is used from then on. Initializing sl_mincsn from the maximum csn won't do much good here, as long as the (current) requirement to use the log is that the consumers mincsn is greater or equal to sl_mincsn. Assuming there is more than one csn in the set that is.. Initializing with the minimum csn should cause the current log to be used in this scenario. But, if the provider restarts between 3 and 4 it would incorrectly appear that replaying the log would be sufficient to bring the consumer in sync. A situation far worse than doing a refresh when replaying the log would have been sufficient. More on possible fixes in my reply to your other message. Rein

1 0

(ITS#6789)
by sgallagh＠redhat.com 14 Jan '11

14 Jan '11

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 I just determined that this didn't occur on openldap-2.4.21, (on that version, we properly get a lot of useful information about why the connection failed). This leads me to believe that this issue is likely related to the recent switch to Mozilla NSS for crypto support. - -- Stephen Gallagher RHCE 804006346421761 Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0wTkYACgkQeiVVYja6o6OFTQCeK7qYIw3754PfDolxkcld/D/B CpoAn0ubzxgg3ekr7Ik1SydV9NkS36ln =r+Ff -----END PGP SIGNATURE-----

1 0

(ITS#6789) SDAP_DIAGNOSTIC_MESSAGE returns (null) for ldap_install_tls() failures
by sgallagh＠redhat.com 14 Jan '11

14 Jan '11

Full_Name: Stephen Gallagher Version: openldap-2.4.23 OS: Fedora 14 x86_64 URL: https://fedorahosted.org/sssd/ticket/699 Submission from: (NULL) (98.110.239.235) We have this code in the SSSD (which uses the openldap shared libraries for LDAP communication). ret = ldap_install_tls(state->sh->ldap); if (ret != LDAP_SUCCESS) { optret = ldap_get_option(state->sh->ldap, SDAP_DIAGNOSTIC_MESSAGE, (void*)&tlserr); if (optret == LDAP_SUCCESS) { DEBUG(3, ("ldap_install_tls failed: [%s] [%s]\n", ldap_err2string(ret), tlserr)); sss_log(SSS_LOG_ERR, "Could not start TLS encryption. %s", tlserr); ldap_memfree(tlserr); } else { DEBUG(3, ("ldap_install_tls failed: [%s]\n", ldap_err2string(ret))); sss_log(SSS_LOG_ERR, "Could not start TLS encryption. " "Check for certificate issues."); } However, whenever there is an issue (such as an invalid/expired certificate) our logs read: (Fri Dec 3 14:13:33 2010) [sssd[be[LDAP]]] [sdap_connect_done] (3): ldap_install_tls failed: [Connect error] [(null)] This means that the ldap_get_option(SDAP_DIAGNOSTIC_MESSAGE) is returning LDAP_SUCCESS, but the returned message is "(null)". This is not the same behavior as with an LDAPS connection, where it will in fact return a message indicating what certificate error was.

1 0

(ITS#6788) Only one reference when ldap_open_internal_connection
by jgiesl＠monetplus.cz 14 Jan '11

14 Jan '11

Full_Name: Jiri Giesl Version: 2.3.43 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.111.5.220) We tried to estalish connection to LDAP server by our own (because of proxy usage) and then use "ldap_open_internal_connection" function to initialize internal structures of openldap. After successful SASL binding we realized that the connection to LDAP server has been closed. We found out that there is checking for reference count in "wait4msg" function (result.c file) this way: if ( lc->lconn_refcnt <= 1 ) During classic initialization and SASL binding we get 2 references, however when using "ldap_open_internal_connection" and SASL binding we get only 1 reference. We realized that in "ldap_open_defconn" (function which is called for establishing of a new connection) there is reference counter which is increased this way: ++ld->ld_defconn->lconn_refcnt; /* so it never gets closed/freed */ When we added this incrementation also into "ldap_open_internal_connection" (open.c file), everything goes well (it is obvious). Are we wrong or this is really minor bug (missing incrementation of reference counter in "ldap_open_internal_connection")?

1 0

Re: (ITS#6716) syncprov sessionlog 'sl_mincsn' not assigned a value.
by hyc＠symas.com 13 Jan '11

13 Jan '11

rein(a)OpenLDAP.org wrote: > On 09.12.10 09.09, masarati(a)aero.polimi.it wrote: >> I think the best (blind) fix consists in only performing that test if >> sl_mincsn is assigned a value; something like > > I'm looking at an extended fix. The problem with the current > implementation is that is assumes the entries arrives in CSN order, > which isn't necessarily true in a MMR configuration. > > My fix drops sl_mincsn, keeps the log queue in CSN order and compares > with the head entry. It also wipes the log if it receives any changes > without CSN (i.e during refresh). I'm not sure this latter is a good idea, in an MMR setup. In that case, we should ensure that only CSNs matching the current SID are added to the log, and we should always leave the log intact. I.e., the server is always authoritative about its own writes. But this kind of begs the question of whether the log should actually maintain N mincsns, one for each known SID, the same way we do now for contextCSN. > There might still be a theoretical problem there, if the sid of an entry > in the log is not in the set sent by the consumer. But since we know > they have the same number of CSNs this can only happen during initial > setup of a multi-master configuration. In which case the admins real > problem is that he didn't bring the servers online in a controlled order.. > > Rein > > > -- -- 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