(ITS#7089) ppolicy adds PWDFAILURETIME to organizationalUnit
by noel＠debian.org
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
11 years, 10 months
Re: (ITS#7087) test050-syncrepl-multimaster failed for mdb
by michael＠stroeder.com
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.
11 years, 10 months
Re: (ITS#7087) test050-syncrepl-multimaster failed for mdb
by hyc＠symas.com
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/
11 years, 10 months
Re: (ITS#7087) test050-syncrepl-multimaster failed for mdb
by hyc＠symas.com
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/
11 years, 10 months
Re: (ITS#7088) slapo-accesslog makes OpenLDAP hang
by michael＠stroeder.com
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.
11 years, 10 months
(ITS#7088) slapo-accesslog makes OpenLDAP hang
by raphael.ouazana＠linagora.com
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.
11 years, 10 months
RE: (ITS#7061) Only return requested attrs in sssvlv response
by ctcard＠hotmail.com
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.
> >
> >
>
>
>
11 years, 10 months
RE: (ITS#7061) Only return requested attrs in sssvlv response
by ctcard＠hotmail.com
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.
>
>
11 years, 10 months
Re: (ITS#7087) test050-syncrepl-multimaster failed for mdb
by michael＠stroeder.com
Hmm, after 12 iterations slapd instances are blocked:
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..]
11 years, 10 months