openldap-bugs

openldap-bugs@openldap.org

1 participants
20965 discussions

Re: (ITS#5709) slapd sync provider skips some objects
by sylvain.thomas＠gmail.com 24 Sep '08

24 Sep '08

------=_Part_8723_3706532.1222271104834 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline May be this helps to better localize the origin of the problem : After adding log messages in the different functions of the file syncprov.c I find that for an object replicated successfully the following functions are called in order : syncprov_op_mod() syncprov_op_response() syncprov_matchops() syncprov_qresp() syncprov_qstart() syncprov_qtask() syncprov_qplay() syncprov_sendresp() But in the for an object skipped by the sync provider only the first two functions are called (no call is made to syncprov_matchops() etc. Best Regards Sylvain Thomas ------=_Part_8723_3706532.1222271104834 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline <div dir="ltr"> May be this helps to better localize the origin of the problem : After adding log messages in the different functions of the file syncprov.c I find that for an object replicated successfully the following functions are called in order : syncprov_op_mod() syncprov_op_response() syncprov_matchops() syncprov_qresp() syncprov_qstart() syncprov_qtask() syncprov_qplay() syncprov_sendresp() But in the for an object skipped by the sync provider only the first two functions are called (no call is made to syncprov_matchops() etc. Best Regards Sylvain Thomas </div> ------=_Part_8723_3706532.1222271104834--

1 0

Re: ITS#5581 reopened
by stef＠memberwebs.com 24 Sep '08

24 Sep '08

Sorry for the delay. Yes I can confirm this has been fixed. Thanks for your attention to this problem. Pierangelo Masarati wrote: > I have re-opened this bug. I have a fix, will commit ASAP. I confirm the bug only seems to affect malformed filters in the URI. > > p. > > > Ing. Pierangelo Masarati > OpenLDAP Core Team > > SysNet s.r.l. > via Dossi, 8 - 27100 Pavia - ITALIA > http://www.sys-net.it > ----------------------------------- > Office: +39 02 23998309 > Mobile: +39 333 4963172 > Fax: +39 0382 476497 > Email: ando(a)sys-net.it > ----------------------------------- > >

1 0

(ITS#5710) syncrepl event loss with ppolicy and multiple masters
by mbackes＠symas.com 23 Sep '08

23 Sep '08

Full_Name: Matthew Backes Version: 2.4, head OS: all URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.88.99.93) When using multiple masters replicating from each other with ppolicy enabled, bind failure events fail to propagate the pwdFailureTime changes. The pwdFailureTime's appear on the directory receiving the change and contextCSN updates, but the replica-side disregards the event. In syncprov.c:1646: /* Don't do any processing for consumer contextCSN updates */ if ( SLAP_SYNC_SHADOW( op->o_bd ) && op->o_msgid == SLAP_SYNC_UPDATE_MSGID ) { ldap_pvt_thread_rdwr_wunlock( &si->si_csn_rwlock ); return SLAP_CB_CONTINUE; } This seems to be designed so that when the local side applies remote changes, the resulting contextCSN update does not get sent back out to any persistent searchers. Unfortuantely, this path is also taken for the pwdFailureTime as a result of a bad (or good) BIND op on a new connection. This means the change is applied to the directory receving the BIND, but replicas of it in multi-master situations discard the change. This definitely seems to be the MSGID issue because if the BIND is not the first thing being done, then the pwdFailureTime messages propagate correctly; e.g. if using STARTTLS and then BIND, no replication problem exists. So... any consensus on the right way to do this test? We could start looking specifically for changes to contextCSN, but that's sort of ugly. A generic don't-replicate-this flag seems like a better approach but looks somewhat invasive. Matthew Backes Symas Corporation mbackes(a)symas.com

1 0

Re: (ITS#5678) slurpd stops processing the replication log if consecutive blank lines are encountered
by michael＠stroeder.com 23 Sep '08

23 Sep '08

mgwin(a)escp-eap.net wrote: > On Tue, 23 Sep 2008 15:33:47 +0200 > Michael Ströder <michael(a)stroeder.com> wrote: > >> Which version 2.3? It is definitely more stable than slurpd in recent >> versions of 2.3 (2.3.43 is most recent release). > > 2.3.30, the debian etch package According to CHANGES 2.3.30 was released almost two years ago. There have been so many fixes since then. You shouldn't ignore that fact if OpenLDAP is a critical part of your infrastructure. > unfortunately upgrading isn't really an option here. Why? > I experienced segfaults on the provider server. Although I'm not > entirely sure the provider was initialised properly*, the fact that > slapd would crash seemed a sufficient indication we should bide our time > and wait till 2.4 hit debian stable. You should upgrade to either 2.3.43 or 2.4.11. Whatever Debian thinks of being a stable version isn't necessarily what the upstream developers think is stable. Actually we have this discussion quite often. Ciao, Michael.

1 0

Re: (ITS#5678) slurpd stops processing the replication log if consecutive blank lines are encountered
by mgwin＠escp-eap.net 23 Sep '08

23 Sep '08

On Tue, 23 Sep 2008 15:33:47 +0200 Michael Ströder <michael(a)stroeder.com> wrote: > Which version 2.3? It is definitely more stable than slurpd in recent > versions of 2.3 (2.3.43 is most recent release). 2.3.30, the debian etch package - unfortunately upgrading isn't really an option here. I experienced segfaults on the provider server. Although I'm not entirely sure the provider was initialised properly*, the fact that slapd would crash seemed a sufficient indication we should bide our time and wait till 2.4 hit debian stable. - Michael *The 2.3 admin guide states: The provider slapd (8) is not required to be restarted. contextCSN is automatically generated as needed: it might be originally contained in the LDIF file, generated by slapadd (8), generated upon changes in the context, or generated when the first LDAP Sync search arrives at the provider. If an LDIF file is being loaded which did not previously contain the contextCSN, the -w option should be used with slapadd (8) to cause it to be generated. This will allow the server to startup a little quicker the first time it runs. This doesn't seem very clear to me - should I re-import the database with the -w option, or should adding the overlay and syncprov-* directives to slapd.conf and restarting be sufficient?

1 0

(ITS#5709) slapd sync provider skips some objects
by sylvain.thomas＠gmail.com 23 Sep '08

23 Sep '08

Full_Name: Sylvain Thomas Version: 2.4.11 OS: Linux 2.6 (Fedora) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (145.242.11.3) I have a test platform with one master and one simple replica. I perform rapid write operations on the master through 8 parallel connections, and I find that some objects are missing in the replica. More investigation shows that the sync provider skips the objects if they are processed faster than the preceding ones. Below, I produce a sample log (sync + stats) of the problem. In the sample log the object uid=5030708029E1 is not sent to the replica (no call to syncprov_sendresp() ) but the object uid=50307080309A is sent. ..... Sep 23 10:09:03 ldap_mirror1 slapd[2020]: conn=331 op=1 ADD dn="uid=50307080309A,ou=A,ou=9,ou=abonnes,ou=test,c=fr" Sep 23 10:09:03 ldap_mirror1 slapd[2020]: slap_queue_csn: queing 0xa2f6cac0 20080923080903.375249Z#000000#001#000000 Sep 23 10:09:03 ldap_mirror1 slapd[2020]: conn=333 op=1 ADD dn="uid=5030708029E1,ou=1,ou=E,ou=abonnes,ou=test,c=fr" Sep 23 10:09:03 ldap_mirror1 slapd[2020]: slap_queue_csn: queing 0xa14feac0 20080923080903.376369Z#000000#001#000000 Sep 23 10:09:03 ldap_mirror1 slapd[2020]: conn=332 op=1 RESULT tag=105 err=0 text= Sep 23 10:09:03 ldap_mirror1 slapd[2020]: slap_graduate_commit_csn: removing 0x9179420 20080923080903.373805Z#000000#001#000000 Sep 23 10:09:03 ldap_mirror1 slapd[2020]: syncprov_sendresp: cookie=rid=003,csn=20080923080903.373805Z#000000#001#000000 Sep 23 10:09:03 ldap_mirror1 slapd[2020]: conn=333 op=1 RESULT tag=105 err=0 text= Sep 23 10:09:03 ldap_mirror1 slapd[2020]: slap_graduate_commit_csn: removing 0x917b428 20080923080903.376369Z#000000#001#000000 Sep 23 10:09:03 ldap_mirror1 slapd[2020]: conn=331 op=1 RESULT tag=105 err=0 text= Sep 23 10:09:03 ldap_mirror1 slapd[2020]: slap_graduate_commit_csn: removing 0xa242aa38 20080923080903.375249Z#000000#001#000000 Sep 23 10:09:03 ldap_mirror1 slapd[2020]: syncprov_sendresp: cookie=rid=003,csn=20080923080903.375249Z#000000#001#000000 ...... I think the reason is that the ADD request for uid=5030708029E1 is received after that of uid=50307080309A, so it takes a bigger csn (20080923080903.376369Z#000000#001#000000) but its processing takes less time (slap_graduate_commit_csn() comes first). I can provide a detailed log (loglevel -1) and any other information required. The environment and the configuration files are the same as for ITS 5661, but I do not use the mirror mode. Thanks for your help Best Regards Sylvain Thomas

1 0

Re: (ITS#5678) slurpd stops processing the replication log if consecutive blank lines are encountered
by michael＠stroeder.com 23 Sep '08

23 Sep '08

Michael Gwin wrote: > On Fri, 05 Sep 2008 16:21:36 +0200 > Michael Ströder <michael(a)stroeder.com> wrote: > >> That's pretty much the reason why syncrepl was invented/implemented in >> OpenLDAP 2.2 and slurpd is deprecated and abandoned from 2.4. >> >> http://www.openldap.org/doc/admin24/replication.html >> >> Likely everybody here will simply recommend to migrate to syncrepl. > > Thanks for the suggestion. I agree with the design and goals of > syncrepl, and will indeed migrate in the future. However, having tried > it, it didn't seem production-worthy in openldap 2.3. Which version 2.3? It is definitely more stable than slurpd in recent versions of 2.3 (2.3.43 is most recent release). Ciao, Michael.

1 0

Re: (ITS#5678) slurpd stops processing the replication log if consecutive blank lines are encountered
by mgwin＠escp-eap.net 23 Sep '08

23 Sep '08

On Fri, 05 Sep 2008 16:21:36 +0200 Michael Ströder <michael(a)stroeder.com> wrote: > That's pretty much the reason why syncrepl was invented/implemented in > OpenLDAP 2.2 and slurpd is deprecated and abandoned from 2.4. > > http://www.openldap.org/doc/admin24/replication.html > > Likely everybody here will simply recommend to migrate to syncrepl. Thanks for the suggestion. I agree with the design and goals of syncrepl, and will indeed migrate in the future. However, having tried it, it didn't seem production-worthy in openldap 2.3. Just in case it can help anyone, I solved my problem by removing the attribute filtering from my replica. No blank lines since. Regards, Michael

1 0

(ITS#5708) nss-ldap not responding properly
by harpreet＠deeproot.co.in 23 Sep '08

23 Sep '08

Full_Name: Harpreet Singh Wadhwa Version: 2.4.11 OS: Debian URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (61.95.198.26) Hi to all, I don't know if this has been posted earlier as I was not able to find it in the list. The issue is I have openldap working with PAM and NSS to do the authentication stuff for courier services. But at times users are unable to log into their accounts, restarting NSCD and SLAPD solves the problem but that too for a short time. These are some details and errors which I have. ##libnss-ldap.conf host 127.0.0.1 base dc=com ldap_version 3 binddn uid=example,dc=com bindpw secret bind_policy soft ##nsswitch.conf passwd: compat ldap group: compat ldap shadow: compat ldap hosts: files dns networks: files protocols: db files services: db files ethers: db files rpc: db files netgroup: nis And the errors which I get are --> user.info: Sep 18 11:24:35 nscd: nss_ldap: reconnecting to LDAP server... user.err: Sep 18 11:24:35 nscd: nss_ldap: could not connect to any LDAP server as uid=example,dc=com - Can't contact LDAP server And some time I get --> local4.debug: Sep 23 11:21:40 slapd[8880]: conn=224 fd=20 closed (connection lost) or local4.debug: Sep 23 11:15:21 slapd[8880]: connection_read(20): no connection! Please respond to me. Regards.

1 0

Re: (ITS#5707) HEAD/RE24 and BDB 4.7.25p1 hanging
by hyc＠symas.com 22 Sep '08

22 Sep '08

hyc(a)symas.com wrote: > I was unable to reproduce the problem on my multi-core machines, but I do see > it on a single-core machine. I've sent a backtrace and other debug info to the > Oracle folks, will see what they have to say. I see the problem; it's a bug in BDB's multi-partition lock manager. When using multiple lock table partitions, it obtains a lock on the system-wide lock mutex and a lock on the per-region mutex. On a single core system it defaults to a single lock table. In this case, the macro that obtains the system-wide lock behaves identically to the per-region lock. I.e., both attempt to acquire the exact same mutex. Since it's already held, the process deadlocks. (gdb) bt #0 0xb7f37424 in __kernel_vsyscall () #1 0xb7b36c4e in __lll_mutex_lock_wait () from /lib/libpthread.so.0 #2 0xb7b32a3c in _L_mutex_lock_88 () from /lib/libpthread.so.0 #3 0xb7b3242d in pthread_mutex_lock () from /lib/libpthread.so.0 #4 0xb7d00819 in __db_pthread_mutex_lock (env=0x8a84550, mutex=104) at ../dist/../mutex/mut_pthread.c:207 #5 0xb7daad19 in __lock_getobj (lt=0x8a84848, obj=0xbfd492ec, ndx=492, create=1, retp=0xbfd491e4) at ../dist/../lock/lock.c:1470 #6 0xb7da7f53 in __lock_get_internal (lt=0x8a84848, sh_locker=0xb776d508, flags=1, obj=0xbfd492ec, lock_mode=DB_LOCK_READ, timeout=0, lock=0xbfd493cc) at ../dist/../lock/lock.c:588 #7 0xb7da77d6 in __lock_get_api (env=0x8a84550, locker=2147483659, flags=1, obj=0xbfd492ec, lock_mode=DB_LOCK_READ, lock=0xbfd493cc) at ../dist/../lock/lock.c:423 #8 0xb7da765b in __lock_get_pp (dbenv=0x8a841c0, locker=2147483659, flags=1, obj=0xbfd492ec, lock_mode=DB_LOCK_READ, lock=0xbfd493cc) at ../dist/../lock/lock.c:395 #9 0x08124fb8 in bdb_dn2id_lock (bdb=0x8a68620, dn=0xbfd493f0, rw=0, txn=0x8a890b8, lock=0xbfd493cc) at ../../../../head/servers/slapd/back-bdb/dn2id.c:47 #10 0x08125d7d in bdb_dn2id (op=0xbfd49640, dn=0xbfd493f0, ei=0xbfd493e0, txn=0x8a890b8, lock=0xbfd493cc) at ../../../../head/servers/slapd/back-bdb/dn2id.c:307 ---Type <return> to continue, or q <return> to quit---q Quit (gdb) frame 4 #4 0xb7d00819 in __db_pthread_mutex_lock (env=0x8a84550, mutex=104) at ../dist/../mutex/mut_pthread.c:207 207 RET_SET((pthread_mutex_lock(&mutexp->mutex)), ret); (gdb) p *mutexp $1 = {mutex = {__data = {__lock = 2, __count = 0, __owner = 29470, __kind = 0, __nusers = 1, {__spins = 0, __list = {__next = 0x0}}}, __size = "\002\000\000\000\000\000\000\000\036s\000\000\000\000\000\000\001\000\000\000\000\000\000", __align = 2}, cond = {__data = {__lock = 0, __futex = 0, __total_seq = 0, __wakeup_seq = 0, __woken_seq = 0, __mutex = 0x0, __nwaiters = 0, __broadcast_seq = 0}, __size = '\0' <repeats 47 times>, __align = 0}, pid = 29470, tid = 3080046272, mutex_next_link = 0, alloc_id = 6, mutex_set_wait = 1, mutex_set_nowait = 129, flags = 3} (gdb) The mutex being acquired in frame 4 is the same one that was already acquired in frame 7, __lock_get_api line 418. -- -- 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