openldap-bugs

openldap-bugs@openldap.org

1 participants
20964 discussions

(ITS#7090) back-mdb produces wrong slapcat output
by michael＠stroeder.com 15 Nov '11

15 Nov '11

Full_Name: Michael Ströder Version: RE24 pulled from git OS: URL: Submission from: (NULL) (84.163.26.40) slapcat with back-mdb mixes entry data in the LDIF output. The entry affected had a DN of another entry while retrieving the same entry via LDAP worked correctly. I observed this for one entry of several hundred entries. I currently can't provide test data because this was my private address book data. But it was reproducable with slapadd-ed data from an older clean backup LDIF file. The last correct backup file I have slapcating with back-mdb is of 2011-11-12. I'm building RE24 almost daily from git. Maybe something bad happened at that time. Will try to reproduce with other data but be warned to keep an eye on that.

1 0

Re: (ITS#7089) ppolicy adds PWDFAILURETIME to organizationalUnit
by michael＠stroeder.com 15 Nov '11

15 Nov '11

noel(a)debian.org wrote: > IMHO it is a bug that the ppolicy adds the PWDFAILURETIME attribute to DN's > which don't have a userPassword attribute and cannot get one. Hmm, this is somewhat debatable. I'm not sure. But I also don't see any harm in the current behaviour. It's surely the client configuration which needs to be fixed. Ciao, Michael.

1 0

(ITS#7089) ppolicy adds PWDFAILURETIME to organizationalUnit
by noel＠debian.org 15 Nov '11

15 Nov '11

Full_Name: Noel Köthe Version: 2.4.25 OS: Debian GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (80.187.103.39) Hello, using the ppolicy overlay with no special options: slapd.conf ... overlay ppolicy ppolicy_default "cn=ppolicy,dc=domain,dc=lan" ppolicy_use_lockout ... cn=ppolicy,dc=domain,dc=lan objectClass: top objectClass: device objectClass: pwdPolicy objectClass: pwdPolicyChecker cn: ppolicy pwdMaxAge: 2592000 pwdExpireWarning: 3600 pwdMaxFailure: 5 pwdLockout: TRUE pwdMustChange: TRUE pwdMinLength: 6 pwdSafeModify: FALSE pwdAttribute: userPassword I'm scanning the LDAP data for PWDFAILURETIME attributes from time to time and found the following ou with this attribute (slapcat output): dn: ou=test,dc=domain,dc=lan objectClass: organizationalUnit ou: test structuralObjectClass: organizationalUnit entryUUID: ad5a6bc6-8a9c-1030-810d-db1b7d10e7b5 creatorsName: cn=admin,dc=domain,dc=lan createTimestamp: 20111014104028Z PWDFAILURETIME: 20111115101034Z PWDFAILURETIME: 20111115101036Z PWDFAILURETIME: 20111115101039Z PWDFAILURETIME: 20111115111624Z PWDFAILURETIME: 20111115111629Z PWDACCOUNTLOCKEDTIME: 20111115111629Z entryCSN: 20111115111629.327963Z#000000#000#000000 modifiersName: cn=admin,dc=domain,dc=lan modifyTimestamp: 20111115111629Z The PWDFAILURETIME on an organizationalUnit were created by: $ ldapsearch -x -W -D ou=test,dc=domain,dc=lan Enter LDAP Password: ldap_bind: Invalid credentials (49) IMHO it is a bug that the ppolicy adds the PWDFAILURETIME attribute to DN's which don't have a userPassword attribute and cannot get one. Do you aggree? Thanks for your answer. Regards Noel Köthe

1 0

Re: (ITS#7087) test050-syncrepl-multimaster failed for mdb
by michael＠stroeder.com 11 Nov '11

11 Nov '11

Howard Chu wrote: > michael(a)stroeder.com wrote: >> Hmm, after 12 iterations slapd instances are blocked: > > I believe I've reproduced this once. It looks like the background indexing > task was running and preventing a replicated cn=config change from completing. > Possibly a call to pausecheck() should be added in the indexer task, but the > more serious issue is that the indexer was re-indexing the same entry (entry > #1) over and over again, instead of progressing thru the DB. Still trying to > reproduce this to see what happened. It never seems to happen with > optimization disabled. Hmm, my build script has CFLAGS="-g -O0" Ciao, Michael.

1 0

Re: (ITS#7087) test050-syncrepl-multimaster failed for mdb
by hyc＠symas.com 10 Nov '11

10 Nov '11

michael(a)stroeder.com wrote: > Hmm, after 12 iterations slapd instances are blocked: I believe I've reproduced this once. It looks like the background indexing task was running and preventing a replicated cn=config change from completing. Possibly a call to pausecheck() should be added in the indexer task, but the more serious issue is that the indexer was re-indexing the same entry (entry #1) over and over again, instead of progressing thru the DB. Still trying to reproduce this to see what happened. It never seems to happen with optimization disabled. > > Cleaning up test run directory from this run. > Running 12 of 100 iterations > running defines.sh > Initializing server configurations... > Starting server 1 on TCP/IP port 9011... > Using ldapsearch to check that server 1 is running... > Inserting syncprov overlay on server 1... > Starting server 2 on TCP/IP port 9012... > Using ldapsearch to check that server 2 is running... > Configuring syncrepl on server 2... > Starting server 3 on TCP/IP port 9013... > Using ldapsearch to check that server 3 is running... > Configuring syncrepl on server 3... > Starting server 4 on TCP/IP port 9014... > Using ldapsearch to check that server 4 is running... > Configuring syncrepl on server 4... > Adding schema and databases on server 1... > Using ldapadd to populate server 1... > Waiting 15 seconds for syncrepl to receive changes... > Using ldapsearch to read config from server 1... > Using ldapsearch to read config from server 2... > Using ldapsearch to read config from server 3... > [..hangs..] > > > -- -- 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#7087) test050-syncrepl-multimaster failed for mdb
by hyc＠symas.com 10 Nov '11

10 Nov '11

michael(a)stroeder.com wrote: > Hmm, after 12 iterations slapd instances are blocked: Need a gdb trace from the hung slapd. > > Cleaning up test run directory from this run. > Running 12 of 100 iterations > running defines.sh > Initializing server configurations... > Starting server 1 on TCP/IP port 9011... > Using ldapsearch to check that server 1 is running... > Inserting syncprov overlay on server 1... > Starting server 2 on TCP/IP port 9012... > Using ldapsearch to check that server 2 is running... > Configuring syncrepl on server 2... > Starting server 3 on TCP/IP port 9013... > Using ldapsearch to check that server 3 is running... > Configuring syncrepl on server 3... > Starting server 4 on TCP/IP port 9014... > Using ldapsearch to check that server 4 is running... > Configuring syncrepl on server 4... > Adding schema and databases on server 1... > Using ldapadd to populate server 1... > Waiting 15 seconds for syncrepl to receive changes... > Using ldapsearch to read config from server 1... > Using ldapsearch to read config from server 2... > Using ldapsearch to read config from server 3... > [..hangs..] > > > -- -- 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#7088) slapo-accesslog makes OpenLDAP hang
by michael＠stroeder.com 10 Nov '11

10 Nov '11

raphael.ouazana(a)linagora.com wrote: > When using the following overlays: > - refint > - memberof > - ppolicy > - synprov > - accesslog Order of overlays is significant. I have a very similar setup running 2.4.26 but with this order at the end of all overlays: [..] accesslog syncprov Ciao, Michael.

1 0

(ITS#7088) slapo-accesslog makes OpenLDAP hang
by raphael.ouazana＠linagora.com 10 Nov '11

10 Nov '11

Full_Name: Raphael Ouazana Version: 2.4.26 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (213.41.232.151) When using the following overlays: - refint - memberof - ppolicy - synprov - accesslog OpenLDAP hangs. Here is the backtrace: (gdb) thread apply all bt Thread 5 (Thread 0x3355bb70 (LWP 11959)): #0 0xb7850424 in __kernel_vsyscall () #1 0xb7420c16 in epoll_wait () at ../sysdeps/unix/syscall-template.S:82 #2 0x080639fb in slapd_daemon_task (ptr=0x0) at daemon.c:2528 #3 0xb76aed31 in start_thread (arg=0x3355bb70) at pthread_create.c:304 #4 0xb74200ce in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Backtrace stopped: Not enough registers or memory available to unwind further Thread 4 (Thread 0x3315ab70 (LWP 11960)): #0 0xb7850424 in __kernel_vsyscall () #1 0xb76b2a5c in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:169 #2 0x081b3fae in ldap_int_thread_pool_wrapper (xpool=0x98a1b60) at tpool.c:672 #3 0xb76aed31 in start_thread (arg=0x3315ab70) at pthread_create.c:304 #4 0xb74200ce in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Backtrace stopped: Not enough registers or memory available to unwind further Thread 3 (Thread 0x32d59b70 (LWP 11961)): #0 0xb7850424 in __kernel_vsyscall () #1 0xb76b2a5c in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:169 #2 0x081b2a1c in ldap_pvt_thread_rmutex_lock (rmutex=0x992c0e0, owner=852859760) at rmutex.c:129 #3 0x081629c6 in accesslog_op_mod (op=0x9997840, rs=0x32d590fc) at accesslog.c:1889 #4 0x080d50e9 in overlay_op_walk (op=0x9997840, rs=0x32d590fc, which=op_add, oi=0x992bdd0, on=0x992bfa8) at backover.c:661 #5 0x080d52d2 in over_op_func (op=0x9997840, rs=0x32d590fc, which=op_add) at backover.c:723 #6 0x080702f6 in fe_op_add (op=0x9997840, rs=0x32d590fc) at add.c:334 #7 0x0807125f in do_add (op=0x9997840, rs=0x32d590fc) at add.c:194 #8 0x080692ee in connection_operation (ctx=0x32d591fc, arg_v=0x9997840) at connection.c:1138 #9 0x08069c6a in connection_read_thread (ctx=0x32d591fc, argv=0x10) at connection.c:1274 #10 0x081b3f56 in ldap_int_thread_pool_wrapper (xpool=0x98a1b60) at tpool.c:685 #11 0xb76aed31 in start_thread (arg=0x32d59b70) at pthread_create.c:304 #12 0xb74200ce in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Backtrace stopped: Not enough registers or memory available to unwind further Thread 2 (Thread 0x31f55b70 (LWP 11996)): #0 0xb7850424 in __kernel_vsyscall () #1 0xb76b2a5c in pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/i386/i686/../i486/pthread_cond_wait.S:169 #2 0x081b3fae in ldap_int_thread_pool_wrapper (xpool=0x98a1b60) at tpool.c:672 #3 0xb76aed31 in start_thread (arg=0x31f55b70) at pthread_create.c:304 #4 0xb74200ce in clone () at ../sysdeps/unix/sysv/linux/i386/clone.S:130 Backtrace stopped: Not enough registers or memory available to unwind further Thread 1 (Thread 0xb73326c0 (LWP 11954)): #0 0xb7850424 in __kernel_vsyscall () #1 0xb76afe2c in pthread_join (threadid=861256560, thread_return=0x0) at pthread_join.c:89 #2 0x080666de in slapd_daemon () at daemon.c:2922 #3 0x0804def9 in main (argc=7, argv=0xbfb125d4) at main.c:983 Regards, Raphaêl Ouazana.

1 0

RE: (ITS#7061) Only return requested attrs in sssvlv response
by ctcard＠hotmail.com 10 Nov '11

10 Nov '11

apologies, I just checked master and can see that a fix was put in on 1st Nov. ---------------------------------------- > Date: Thu, 10 Nov 2011 14:36:11 +0000 > From: ctcard(a)hotmail.com > To: openldap-its(a)openldap.org > Subject: RE: (ITS#7061) Only return requested attrs in sssvlv response > > > Is anyone looking at this? > > ---------------------------------------- > > Date: Tue, 11 Oct 2011 13:58:55 +0000 > > From: ctcard(a)hotmail.com > > To: openldap-its(a)openldap.org > > Subject: (ITS#7061) Only return requested attrs in sssvlv response > > > > Full_Name: Chris Card > > Version: 2.4.26 + patch > > OS: Centos 5.4 > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (91.194.158.133) > > > > > > There was a fix put into master on 18 Jul 2011 with subject "Only return > > requested attrs in sssvlv response" SHA: > > 8eecc9a017584ea0b56b25f0e4750e3b16929de6. > > > > I have patched openldap 2.4.26 with all the fixes to sssvlv.c, but there is > > still an issue with the attributes returned in an sssvlv response. > > > > On the first sssvlv request only the requested attributes are returned, but on > > subsequent sssvlv requests using the vlv context returned by the first requests, > > all the attributes are returned. > > > > > > >

1 0

RE: (ITS#7061) Only return requested attrs in sssvlv response
by ctcard＠hotmail.com 10 Nov '11

10 Nov '11

Is anyone looking at this? ---------------------------------------- > Date: Tue, 11 Oct 2011 13:58:55 +0000 > From: ctcard(a)hotmail.com > To: openldap-its(a)openldap.org > Subject: (ITS#7061) Only return requested attrs in sssvlv response > > Full_Name: Chris Card > Version: 2.4.26 + patch > OS: Centos 5.4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (91.194.158.133) > > > There was a fix put into master on 18 Jul 2011 with subject "Only return > requested attrs in sssvlv response" SHA: > 8eecc9a017584ea0b56b25f0e4750e3b16929de6. > > I have patched openldap 2.4.26 with all the fixes to sssvlv.c, but there is > still an issue with the attributes returned in an sssvlv response. > > On the first sssvlv request only the requested attributes are returned, but on > subsequent sssvlv requests using the vlv context returned by the first requests, > all the attributes are returned. > >

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