openldap-bugs January 2011

openldap-bugs@openldap.org

36 participants
177 discussions

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

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

13 Jan '11

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. > 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. -- -- 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#5048) Suspicious use of 'unchecked' limit syncprov
by hyc＠symas.com 13 Jan '11

13 Jan '11

h.b.furuseth(a)usit.uio.no wrote: > BTW, why do CSN times have 6-decimal precision when we only care > about 1/256 second? Or doesn't it matter if this test is gives > false positives for small time differences? > Yeah, we really just don't care. 6-decimal precision is for conflict resolution, this is just to determine if something is "new enough" where "enough" doesn't need to be exact. -- -- 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#5048) Suspicious use of 'unchecked' limit syncprov
by h.b.furuseth＠usit.uio.no 13 Jan '11

13 Jan '11

BTW, why do CSN times have 6-decimal precision when we only care about 1/256 second? Or doesn't it matter if this test is gives false positives for small time differences? -- Hallvard

1 0

Re: (ITS#5048) Suspicious use of 'unchecked' limit syncprov
by h.b.furuseth＠usit.uio.no 13 Jan '11

13 Jan '11

hyc(a)symas.com writes: > I guess that's a fair point, but operating without an entryCSN index would be > a config mistake anyway. (Note that the unchecked limit only has relevance on > backends that support indexing in the first place.) As a user that's a config mistake from which I'd expect poor performance or sizelimit warnings in syslog, not broken CSN handling. In particular when slapo-syncprov(5) does mention indexing without demanding it: "On databases that support inequality indexing, it is helpful to set an eq index on the entryCSN attribute when using this overlay." -- Hallvard

1 0

← Newer
1
...
8
9
10
11
12
13
14
...
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs January 2011