- openldap-bugs - openldap.org

Re: (ITS#7537) ppolicy hangs slapd on 64bit version debian
by ryan＠nardis.ca 26 Aug '15

26 Aug '15

I reproduced this with current RE24. It seems to be caused by setting pwdMaxAge to a very large value. In Marek's previous debug output you can see his policy object as returned from a search. Among other attrs it has: pwdMaxAge: 2592000000 I reproduced the report with the following setup: ### slapd.conf include ../openldap/servers/slapd/schema/core.schema include ../openldap/servers/slapd/schema/ppolicy.schema moduleload back_hdb moduleload ppolicy database hdb directory db suffix dc=example,dc=com rootdn cn=root,dc=example,dc=com rootpw secret access to * by dn="cn=admin,dc=example,dc=com" manage by * read index objectClass eq overlay ppolicy ppolicy_default cn=default,ou=policies,dc=example,dc=com ### init.ldif dn: dc=example,dc=com objectClass: domain dn: cn=admin,dc=example,dc=com objectClass: organizationalRole objectClass: simpleSecurityObject userPassword: secret dn: ou=policies,dc=example,dc=com objectClass: organizationalUnit dn: cn=default,ou=policies,dc=example,dc=com objectClass: organizationalRole objectClass: pwdPolicy pwdAttribute: userPassword pwdMaxAge: 2592000000 ### mod.ldif dn: cn=default,ou=policies,dc=example,dc=com add: pwdMaxFailure pwdMaxFailure: 7 Launched slapd and triggered via: $ ldapmodify -x -D cn=admin,dc=example,dc=com -W -f mod.ldif slapd hangs, ldapmodify is still waiting for it, and gdb says: Program received signal SIGINT, Interrupt. 0x00007ffff75f24db in pthread_join (threadid=140737286698752, thread_return=0x0) at pthread_join.c:92 92 pthread_join.c: No such file or directory. (gdb) thread apply all bt Thread 3 (Thread 0x7ffff3faf700 (LWP 25350)): #0 0x00007ffff7326653 in epoll_wait () at ../sysdeps/unix/syscall-template.S:81 #1 0x00000000004257b9 in slapd_daemon_task (ptr=0xa83a10) at daemon.c:2539 #2 0x00007ffff75f10a4 in start_thread (arg=0x7ffff3faf700) at pthread_create.c:309 #3 0x00007ffff732607d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 2 (Thread 0x7ffff37ae700 (LWP 25353)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:185 #1 0x00007ffff7a4e79d in __db_pthread_mutex_lock () from /usr/lib/x86_64-linux-gnu/libdb-5.3.so #2 0x00007ffff7af74e0 in __lock_get_internal () from /usr/lib/x86_64-linux-gnu/libdb-5.3.so #3 0x00007ffff7af8719 in __lock_vec () from /usr/lib/x86_64-linux-gnu/libdb-5.3.so #4 0x00007ffff7af8e9f in __lock_vec_pp () from /usr/lib/x86_64-linux-gnu/libdb-5.3.so #5 0x000000000052f7ed in hdb_cache_entry_db_relock (bdb=0x934920, txn=0x7fffe4102810, ei=0x7fffe4101e80, rw=1, tryOnly=0, lock=0x7ffff37ac340) at cache.c:198 #6 0x0000000000531a43 in hdb_cache_modify (bdb=0x934920, e=0x9aca18, newAttrs=0x9c0690, txn=0x7fffe4102810, lock=0x7ffff37ac340) at cache.c:1231 #7 0x00000000004d85f6 in hdb_modify (op=0x7fffe4000aa0, rs=0x7ffff37adae0) at modify.c:764 #8 0x00000000004b740c in overlay_op_walk (op=0x7fffe4000aa0, rs=0x7ffff37adae0, which=op_modify, oi=0x936420, on=0x0) at backover.c:677 #9 0x00000000004b7637 in over_op_func (op=0x7fffe4000aa0, rs=0x7ffff37adae0, which=op_modify) at backover.c:730 #10 0x00000000004b776b in over_op_modify (op=0x7fffe4000aa0, rs=0x7ffff37adae0) at backover.c:769 #11 0x0000000000449541 in fe_op_modify (op=0x7fffe4000aa0, rs=0x7ffff37adae0) at modify.c:303 #12 0x0000000000448e13 in do_modify (op=0x7fffe4000aa0, rs=0x7ffff37adae0) at modify.c:177 #13 0x0000000000429a3f in connection_operation (ctx=0x7ffff37adc10, arg_v=0x7fffe4000aa0) at connection.c:1155 #14 0x0000000000429fdb in connection_read_thread (ctx=0x7ffff37adc10, argv=0xe) at connection.c:1291 #15 0x000000000058415d in ldap_int_thread_pool_wrapper (xpool=0x909fd0) at tpool.c:696 #16 0x00007ffff75f10a4 in start_thread (arg=0x7ffff37ae700) at pthread_create.c:309 #17 0x00007ffff732607d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 Thread 1 (Thread 0x7ffff7fec700 (LWP 25346)): #0 0x00007ffff75f24db in pthread_join (threadid=140737286698752, thread_return=0x0) at pthread_join.c:92 #1 0x00000000005855f3 in ldap_pvt_thread_join (thread=140737286698752, thread_return=0x0) at thr_posix.c:197 #2 0x0000000000426986 in slapd_daemon () at daemon.c:2932 #3 0x000000000040602d in main (argc=8, argv=0x7fffffffe598) at main.c:1017 If I change the config to use back-mdb instead, I get a crash: 55dce2bf conn=1000 op=1 MOD dn="cn=default,ou=policies,dc=example,dc=com" 55dce2bf conn=1000 op=1 MOD attr=pwdMaxFailure slapd: id2entry.c:520: mdb_opinfo_get: Assertion `!rc' failed. [New Thread 0x7ffff2caf700 (LWP 25374)] [New Thread 0x7ffff34b0700 (LWP 25371)] Program received signal SIGABRT, Aborted. [Switching to Thread 0x7ffff2caf700 (LWP 25374)] 0x00007ffff7275107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56 ../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x00007ffff7275107 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x00007ffff72764e8 in __GI_abort () at abort.c:89 #2 0x00007ffff726e226 in __assert_fail_base (fmt=0x7ffff73a4d08 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=assertion@entry=0x5f29e4 "!rc", file=file@entry=0x5f2975 "id2entry.c", line=line@entry=520, function=function@entry=0x5f2b30 <__PRETTY_FUNCTION__.12200> "mdb_opinfo_get") at assert.c:92 #3 0x00007ffff726e2d2 in __GI___assert_fail (assertion=0x5f29e4 "!rc", file=0x5f2975 "id2entry.c", line=520, function=0x5f2b30 <__PRETTY_FUNCTION__.12200> "mdb_opinfo_get") at assert.c:101 #4 0x0000000000553a71 in mdb_opinfo_get (op=0x7fffe4000aa0, mdb=0x7ffff7f2a010, rdonly=1, moip=0x7ffff2cacf18) at id2entry.c:520 #5 0x000000000055306b in mdb_entry_get (op=0x7fffe4000aa0, ndn=0x7fffe4000ad8, oc=0x0, at=0x0, rw=0, ent=0x7ffff2cad2c8) at id2entry.c:327 #6 0x00000000004b6a41 in overlay_entry_get_ov (op=0x7fffe4000aa0, dn=0x7fffe4000ad8, oc=0x0, ad=0x0, rw=0, e=0x7ffff2cad2c8, on=0x0) at backover.c:364 #7 0x00000000004b6b11 in over_entry_get_rw (op=0x7fffe4000aa0, dn=0x7fffe4000ad8, oc=0x0, ad=0x0, rw=0, e=0x7ffff2cad2c8) at backover.c:396 #8 0x000000000043ca86 in be_entry_get_rw (op=0x7fffe4000aa0, ndn=0x7fffe4000ad8, oc=0x0, at=0x0, rw=0, e=0x7ffff2cad2c8) at backend.c:1366 #9 0x0000000000561e6c in ppolicy_modify (op=0x7fffe4000aa0, rs=0x7ffff2caeae0) at ppolicy.c:1626 #10 0x00000000004b7362 in overlay_op_walk (op=0x7fffe4000aa0, rs=0x7ffff2caeae0, which=op_modify, oi=0x935700, on=0x9358e0) at backover.c:661 #11 0x00000000004b7637 in over_op_func (op=0x7fffe4000aa0, rs=0x7ffff2caeae0, which=op_modify) at backover.c:730 #12 0x00000000004b776b in over_op_modify (op=0x7fffe4000aa0, rs=0x7ffff2caeae0) at backover.c:769 #13 0x0000000000449541 in fe_op_modify (op=0x7fffe4000aa0, rs=0x7ffff2caeae0) at modify.c:303 #14 0x0000000000448e13 in do_modify (op=0x7fffe4000aa0, rs=0x7ffff2caeae0) at modify.c:177 #15 0x0000000000429a3f in connection_operation (ctx=0x7ffff2caec10, arg_v=0x7fffe4000aa0) at connection.c:1155 #16 0x0000000000429fdb in connection_read_thread (ctx=0x7ffff2caec10, argv=0xb) at connection.c:1291 #17 0x000000000058415d in ldap_int_thread_pool_wrapper (xpool=0x909fd0) at tpool.c:696 #18 0x00007ffff75f10a4 in start_thread (arg=0x7ffff2caf700) at pthread_create.c:309 #19 0x00007ffff732607d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 It seems like the crash does not happen if I bind as the rootdn, only when using the admin DN. The hang with back-hdb happens with both. Like I mentioned above, the problem seems to be related to the large pwdMaxAge value. If I drop a few 0s off the end of it, everything works properly. That might be related to Marek's statement that he only experienced the problem on 64-bit...

1 0

(ITS#8222) memory administration in ldap_parse_result()
by lawrence.newman＠alcatel-lucent.com 25 Aug '15

25 Aug '15

Full_Name: Larry Newman Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (135.245.10.2) My application uses OpenLDAP as a client with long duration connections used to send many requests - multiple TCP connections are pre-established and then ldap_init_fd() is invoked for each of them. After a while (and many request/response exchanges) memory exhaustion is observed, and this report relates to the possibility that ldap_parse_result() might be leaking memory. I believe the ber_scanf() calls in ldap_parse_result() that search for matched DN/error message/referrals can dynamically allocate memory (in my case, for an error message) that is being linked to the LDAP structure. This memory doesn't appear to be freed before ldap_parse_result() returns and the allocation isn't visible to the caller (the LDAP structure is supposed to be "opaque"). This appears to be different memory from that passed back to the caller via the ldap_parse_result() pointer parameters (that memory is conditionally created by LDAP_STRDUP() and can/should be freed by the caller if requested) E Early in ldap_parse_result(), there is some code that invokes LDAP_FREE()/LDAP_VFREE() for these dynamic memory pointers in the LDAP structure - but it doesn't seem like that will happen until the next invocation of ldap_parse_result() (if ever). The implementation of ldap_parse_extended_result() seems similar. Shouldn't memory allocated (for internal use only) by these functions be freed before the functions return?

1 0

(ITS#8221) getting MDB_PAGE_FULL using mdb_cursor_del
by sergej.jurecko＠gmail.com 25 Aug '15

25 Aug '15

Full_Name: Sergej Jure&#269;ko Version: lmdb 0.9.16 OS: osx URL: ftp://ftp.openldap.org/incoming/delerror.zip Submission from: (NULL) (193.189.172.218) Code and lmdb file is uploaded to ftp. Code is also here: https://gist.github.com/SergejJurecko/68979ff6460806581ad5 If you run the code on the uploaded lmdb file, it will result in MDB_PAGE_FULL error out of mdb_cursor_del. I use dupsorts a lot in my app. Every value in the dupsort has 2 64bit integers and 1 u8 in the beginning, which are used in the custom comparison function to sort the values. During normal operation values are added to the end of the dupsort and eventually a cleanup operation occurs that deletes unused values. The example app tries to delete the first value in the dupsort. But it will fail the same if it tries to delete the next one instead.

1 0

Re: (ITS#8198) pw-pbkdf2: optionally use libnettle for crypto
by ryan＠nardis.ca 23 Aug '15

23 Aug '15

On Mon, Jul 13, 2015 at 08:44:49PM +0000, luca.bruno(a)rocket-internet.de wrote: >This is a followup to ITS#7977. >Here below are two patches against the pw-pbkdf2 contrib module to: > 1) fix an always-true check > 2) optionally make use of libnettle These are in git master now, along with the #else->#elif fixup. Thank you for the contribution!

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao＠computer.org 20 Aug '15

20 Aug '15

On 08/14/2015 10:25 AM, Howard Chu wrote: > I've added a pwdMaxRecordedFailure attribute to the policy schema. > Overloading pwdMaxFailure would be a mistake. > > MaxRecordedFailure will default to MaxFailure if that is set. It > defaults to 5 if nothing is set. There's no good reason to allow the > timestamps to accumulate without bound. > > This is now available for testing in git master. Tested on Ubuntu 14.04, works great. Thanks again Howard! -Kartik

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao＠computer.org 20 Aug '15

20 Aug '15

On 08/14/2015 10:25 AM, Howard Chu wrote: > I've added a pwdMaxRecordedFailure attribute to the policy schema. > Overloading pwdMaxFailure would be a mistake. > > MaxRecordedFailure will default to MaxFailure if that is set. It > defaults to 5 if nothing is set. There's no good reason to allow the > timestamps to accumulate without bound. > > This is now available for testing in git master. Howard, I just saw this message from you today, when I happened to be looking through my gmail spam folder -- no idea why it ended up there! On Friday, I only saw your subsequent message and responded to it without knowing that you had already implemented this enhancement. So I didn't fully understand the context in which you had written that message. Thanks very much for implementing this enhancement! I will check out the code. Regards, -Kartik

1 0

Re: (ITS#8173)
by hyc＠symas.com 20 Aug '15

20 Aug '15

Adrian.Raemy(a)vtg.admin.ch wrote: > Dear Howard, > > The fix runs stable now over weeks.=20 > slapd didn't crashed anymore. Thank you for the help. > > I guess we can close the ticket. Thanks for the followup. -- -- 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#8218) segfault on sasl auth with malformed URI in config
by hyc＠symas.com 20 Aug '15

20 Aug '15

best(a)univention.de wrote: > Full_Name: > Version: 2.4.40-1 > OS: debian / UCS 4.1 amd64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.198.197.8) > > > A malformed URI in the sasl-regexp directive of slapd.conf caused a segfault of > slapd. > > """ > sasl-regexp > uid=(.*),cn=saml,cn=auth > ldap:///0.0.0.0:7389,389/"dc=dev,dc=local"??sub?uid=$1 > """ > The URI starts with 3 slashes after the scheme instead of 2 slashes. > > When doing authentication via SASL /usr/sbin/slapd segfaults. Thanks for the report, fixed in git master. -- -- 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#8046) query caused slapd to stop
by hyc＠symas.com 20 Aug '15

20 Aug '15

Howard Chu wrote: > Ryan Tandy wrote: >> Hi again, >> >> 9d9913392a0346e23f07e65d7d0964c84e2c1277 is the first bad commit >> commit 9d9913392a0346e23f07e65d7d0964c84e2c1277 >> Author: Howard Chu <hyc(a)openldap.org> >> Date: Thu Sep 18 02:06:38 2014 +0100 >> >> ITS#7942 plug leak in controls >> >> Reverting 8bdd54c and 9d99133 fixes the crash. >> >> I suppose it should probably get a CVE, and so on... >> > git history shows vrFilter_free has been broken ever since Kurt wrote it in > 2002. Which pretty much means it was never getting called until #7942 plugged > that memory leak. > For future reference, this was registered as CVE-2015-1546 -- -- 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#8027) ldapsearch -E deref=member: crashes slapd
by hyc＠symas.com 20 Aug '15

20 Aug '15

Howard Chu wrote: > ryan(a)nardis.ca wrote: >> Full_Name: Ryan Tandy >> Version: master (7df548d), RE24 (2b14bbc) >> OS: Debian unstable >> URL: >> Submission from: (NULL) (142.32.208.227) >> >> >> If you use the deref control but leave the list of requested attributes empty, >> slapd crashes. >> >> ldapsearch [...] -E deref=member: > >> The ldapsearch manpage implies this probably isn't valid, but it still accepted >> it. (FWIW, I tried it just to see whether it would return all attributes or >> none.) I couldn't tell from draft-ldap-deref-00 whether an empty attr list is >> considered a valid request. >> > Patched in master to reject a request with an empty attr list. > For future reference, this was registered as CVE-2015-1545. -- -- 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#8114) [WIP] WiredTiger Backend for OpenLDAP
by hyc＠symas.com 19 Aug '15

19 Aug '15

hamano(a)osstech.co.jp wrote: > Full_Name: HAMANO Tsukasa > Version: master > OS: Linux > URL: https://www.osstech.co.jp/download/hamano/openldap/0001-OpenLDAP-WiredTiger… > Submission from: (NULL) (183.77.250.155) > > > The attached patch file is derived from OpenLDAP Software. All of the > modifications to OpenLDAP Software represented in the following > patch(es) were developed by HAMANO Tsukasa <hamano(a)osstech.co.jp>. I > have not assigned rights and/or interest in this work to any party. > > Copyright 2015 HAMANO Tsukasa <hamano(a)osstech.co.jp> > Redistribution and use in source and binary forms, with or without > modification, are permitted only as authorized by the OpenLDAP Public > License. I've merged patches 0001-0004 and added this to git master. Thanks for the contribution. -- -- 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#8069) MDb library patch: Use explicit Windows API functions for char* strings
by hyc＠symas.com 19 Aug '15

19 Aug '15

pmedvedev(a)gmail.com wrote: > Full_Name: Pavel Medvedev > Version: > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.25.225.40) > > > Most Windows API functions such as CreateFile(), CreateMutex(), > OpenMutex() that accept string arguments, are defined with suffix W or A > for appropriate wchar_t* or char* strings, depending of _UNICODE > preprocessor define. Calling explicit functions with A suffix would eliminate > compile errors when _UNICODE is defined. Thanks, committed to mdb.master. > > As a further enhancement, I think path argument encoding should be documented > (probably UTF-8?) for such functions as mdb_env_open(), mdb_env_copy(), > mdb_env_copy2(), and mdb_env_get_path(). This prevent possible problems with > non-latin characters in path names on Windows. > > In this case, LMDB implementation on Windows should perform path > conversion to UTF-16 and explicit call to CreateFileW() in mdb_env_open() > and mdb_env_copy2() functions. We've been discussing this change on and off for a while. That sounds like the correct approach; patches welcome. -- -- 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#8068) MDB library patch: Using IsWindowsVersionOrGreater() instead of obsolete GetVersion()
by hyc＠symas.com 19 Aug '15

19 Aug '15

pmedvedev(a)gmail.com wrote: > Full_Name: Pavel Medvedev > Version: > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.25.225.40) I'm unable to compile with this patch. The API appears to be missing from older versions of the Windows SDK. MSDN says it's from the Windows 8.1 SDK. Closing this ITS. > > > --- > libraries/liblmdb/mdb.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c > index 65293f4..a54ce83 100644 > --- a/libraries/liblmdb/mdb.c > +++ b/libraries/liblmdb/mdb.c > @@ -239,6 +239,7 @@ union semun { > #endif > > #ifdef _WIN32 > +#include <VersionHelpers.h> > #define MDB_USE_HASH 1 > #define MDB_PIDLOCK 0 > #define THREAD_RET DWORD > @@ -3998,8 +3999,7 @@ mdb_env_open2(MDB_env *env) > > #ifdef _WIN32 > /* See if we should use QueryLimited */ > - rc = GetVersion(); > - if ((rc & 0xff) > 5) > + if (IsWindowsVersionOrGreater(6, 0, 0)) > env->me_pidquery = MDB_PROCESS_QUERY_LIMITED_INFORMATION; > else > env->me_pidquery = PROCESS_QUERY_INFORMATION; > -- -- 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#8217) Add msvc support to lmdb
by nacho.resa＠gmail.com 19 Aug '15

19 Aug '15

--001a113449f0607d15051daaa7f8 Content-Type: text/plain; charset=UTF-8 well, those bug reports overlap with my patch, but they completely lack adding the MSVC project, should I attach my patch there? On Wed, Aug 19, 2015 at 3:57 PM, Howard Chu <hyc(a)symas.com> wrote: > nacho.resa(a)gmail.com wrote: > >> Full_Name: Ignacio Casal Quinteiro >> Version: >> OS: Windows 7 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.30.165.68) >> >> >> On the url below you can find a fork that adds support for msvc builds: >> https://github.com/nice-software/lmdb/tree/wip/msvc >> >> https://github.com/nice-software/lmdb/commit/e871e736949dafee4e84f07c6cfb1b… >> > > This patch is largely a dup of ITSs #8067,8068,8069. > > Closing this ITS, use the previous ones instead. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > -- Ignacio Casal Quinteiro --001a113449f0607d15051daaa7f8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">well, those bug reports overlap with my patch, but they co= mpletely lack adding the MSVC project, should I attach my patch there?<br><= /div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Wed, Aug = 19, 2015 at 3:57 PM, Howard Chu <span dir=3D"ltr"><<a href=3D"mailto:hyc= @symas.com" target=3D"_blank">hyc(a)symas.com</a>></span> wrote:<br><block= quote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc= solid;padding-left:1ex"><a href=3D"mailto:nacho.resa@gmail.com" target=3D"= _blank">nacho.resa(a)gmail.com</a> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> Full_Name: Ignacio Casal Quinteiro<br> Version:<br> OS: Windows 7<br> URL: <a href=3D"ftp://ftp.openldap.org/incoming/" rel=3D"noreferrer" target= =3D"_blank">ftp://ftp.openldap.org/incoming/</a><br> Submission from: (NULL) (83.30.165.68)<br> <br> <br> On the url below you can find a fork that adds support for msvc builds:<br> <a href=3D"https://github.com/nice-software/lmdb/tree/wip/msvc" rel=3D"nore= ferrer" target=3D"_blank">https://github.com/nice-software/lmdb/tree/wip/ms= vc</a><br> <a href=3D"https://github.com/nice-software/lmdb/commit/e871e736949dafee4e8= 4f07c6cfb1b1eceb57089" rel=3D"noreferrer" target=3D"_blank">https://github.= com/nice-software/lmdb/commit/e871e736949dafee4e84f07c6cfb1b1eceb57089</a><= br> </blockquote> <br> This patch is largely a dup of ITSs #8067,8068,8069.<br> <br> Closing this ITS, use the previous ones instead.<span class=3D"HOEnZb"><fon= t color=3D"#888888"><br> <br> -- <br> =C2=A0 -- Howard Chu<br> =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" rel=3D"noreferrer" target=3D"_blank">http://www.symas= .com</a><br> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" rel=3D"noreferrer" target=3D"_blank">http://highlandsun.com/h= yc/</a><br> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" rel=3D"noreferrer" target=3D"_blank">http://www.openldap.org/proje= ct/</a><br> </font></span></blockquote></div><br><br clear=3D"all"><br>-- <br><div clas= s=3D"gmail_signature">Ignacio Casal Quinteiro</div> </div> --001a113449f0607d15051daaa7f8--

1 0

Re: (ITS#8217) Add msvc support to lmdb
by hyc＠symas.com 19 Aug '15

19 Aug '15

nacho.resa(a)gmail.com wrote: > Full_Name: Ignacio Casal Quinteiro > Version: > OS: Windows 7 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.30.165.68) > > > On the url below you can find a fork that adds support for msvc builds: > https://github.com/nice-software/lmdb/tree/wip/msvc > https://github.com/nice-software/lmdb/commit/e871e736949dafee4e84f07c6cfb1b… This patch is largely a dup of ITSs #8067,8068,8069. Closing this ITS, use the previous ones instead. -- -- 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

(ITS#8220) refint performance issue
by hyc＠openldap.org 19 Aug '15

19 Aug '15

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (78.155.231.135) Submitted by: hyc The fix for ITS#5097 changed refint to support subtree renames. Unfortunately this required using dnSubtreeMatch extended search filters, which are not indexable, so every refint invocation invokes a search that scans the entire DB. This behavior isn't necessary; such an extensive search is only needed if we know that the entry being modified actually has children. If we know that the entry has no children, we can use the original code which used an equality match, which *is* indexable, and save significant overhead. Patch coming shortly.

1 0

(ITS#8218) segfault on sasl auth with malformed URI in config
by best＠univention.de 19 Aug '15

19 Aug '15

Full_Name: Version: 2.4.40-1 OS: debian / UCS 4.1 amd64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.198.197.8) A malformed URI in the sasl-regexp directive of slapd.conf caused a segfault of slapd. """ sasl-regexp uid=(.*),cn=saml,cn=auth ldap:///0.0.0.0:7389,389/"dc=dev,dc=local"??sub?uid=$1 """ The URI starts with 3 slashes after the scheme instead of 2 slashes. When doing authentication via SASL /usr/sbin/slapd segfaults. I think it is easy to reproduce. I can provide a core dump if needed. The backtrace: Thread 1 (Thread 0x7f933827c700 (LWP 18575)): #0 *__GI___li_freree (mem=0x20) at malloc.c:3709 #1 0x000000000044d08e in ava_free (op=0x1aa6ce0, ava=0x1aa8410, freeit=1) at ../../../../servers/slapd/ava.c:50 #2 0x00000000004354aa in filter_free_x (op=0x1aa6ce0, f=0x1aa8450, freeme=1) at ../../../%./servers/slapd/filter.c:531 #3 0x00000000004798a3 in slap_sasl2dn (opx=opx@entry=0x1aa6ce0, saslname=saslname@entry=0x7f933827b600, sasldn=sasldn@entry=0x7f933827b450, flags=flags@entry=2) at ../../../../servers/slapd/saslauthz.c:2018 #4 0x0000000000480c0f in slap_sasl_getdn (conn=<optimized out>, op=0x1aa6ce0, op@entry=0x0, id=id@entry=0x7f933827b610, user_realm=user_realm@entry=0x0, dn=dn@entry=0x7f933827b600, flags=2) at ../../../../servers/slapd/sasl.c:1884 #5 0x00000000004811a1 in slap_sasl_canonicalize (sconn=0x190a7e0, context=<optimized out>, in=0x1a864b0 "Administrator", inlen=13, flags=<optimized out>, user_realm=0x0, out=0x190b581 "", out_max=1024, out_len=0x190b06c) at ../../../../servers/slapd/sasl.c:656 #6 0x00007f93c16b2558 in _sasl_canon_user (conn=conn@entry=0x190a7e0, user=0x1a864b0 "Administrator", ulen=13, flags=flags@entry=3, oparams=oparams@entry=0x190b050) at ../../lib/canonusr.c:109 #7 0x00007f93c16b2870 in _sasl_canon_user_lookup (conn=0x190a7e0, user=<optimized out>, ulen=<optimized out>, flags=3, oparams=0x190b050) at ../../lib/canonusr.c:273 #8 0x00007f93bd46b936 in saml_server_mech_step (conn_context=0x1a2e8e0, params=0x190b9f0, clientin=0x1a55bea "", clientinlen=<optimized out>, serverout=<optimized out>, serveroutlen=<optimized out>, oparams=0x190b050) at cy2_saml.c:281 #9 0x00007f93c16be605 in sasl_server_step (serveroutlen=<optimized out>, serverout=0x7f933827b958, clientinlen=<optimized out>, clientin=<optimized out>, conn=0x190a7e0) at ../../lib/server.c:1614 #10 sasl_server_ste%2(conn=0x190a7e0, clientin=<optimized out>, clientinlen=<optimized out>, serverout=0x7f933827b958, serveroutlen=<optimized out>) at ../../lib/server.c:1585 #11 0x00007f93c16beb44 in sasl_server_start (conn=<optimized out>, mech=<optimized out>, clientin=0x1a55bea "", clientinlen=<optimized out>, serverout=serverout@entry=0x7f933827b958, serveroutlen=serveroutlen@entry=0x7f933827b938) at ../../lib/server.c:1529 #12 0x000000000048020e in slap_sasl_bind (op=op@entry=0x1aa6ce0, rs=rs@entry=0x7f933827ba60) at ../../../../servers/slapd/sasl.c:1512 #13 0x000000000044e217 in fe_op_bind (op=0x1aa6ce0, rs=0x7f933827ba60) at ../../../../servers/slapd/bind.c:280 #14 0x000000000044dab1 in do_bind (op=0x1aa6ce0, rs=0x7f933827ba60) at ../../../../servers/slapd/bind.c:205 #15 0x00000000004315d5 in connection_operation (ctx=ctx@entry=0x7f933827bba0, arg_v=arg_v@entry=0x1aa6ce0) at ../../../../servers/slapd/connection.c:1155 #16 0x00000000004318be in connection_read_thread (ctx=0x7f933827bba0, argv=<optimized out>) at ../../../../servers/slapd/connection.c:1291 #17 0x00007f93c22e4c33 in ldap_int_thread_pool_wrapper (xpool=0x1447450) at ../../../../libraries/libldap_r/tpool.c:688 #18 0x00007f93c03c3b50 in start_thread (arg=<optimized out>) at pthread_create.c:304 #19 0x00007f93c010d70d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #20 0x0000000000000000 in ?? () Some more context: (gdb) f 1 #1 0x000000000044d08e in ava_free (op=0x1aa6ce0, ava=0x1aa8410, freeit=1) at ../../../../servers/slapd/ava.c:50 50 op->o_tmpfree( ava->aa_value.bv_val, op->o_tmpmemctx ); (gdb) list 45 { 46 #ifdef LDAP_COMP_MATCH 47 if ( ava->aa_cf && ava->aa_cf->cf_ca->ca_comp_data.cd_mem_op ) 48 nibble_mem_free ( ava->aa_cf->cf_ca->ca_comp_data.cd_mem_op ); 49 #endif 50 op->o_tmpfree( ava->aa_value.bv_val, op->o_tmpmemctx ); 51 if ( ava->aa_desc->ad_flags & SLAP_DESC_TEMPORARY ) 52 op->o_tmpfree( ava->aa_desc, op->o_tmpmemctx ); 53 if ( freeit ) op->o_tmpfree( (char *) ava, op->o_tmpmemctx ); 54 } (gdb) up #2 0x00000000004354aa in filter_free_x (op=0x1aa6ce0, f=0x1aa8450, freeme=1) at ../../../../servers/slapd/filter.c:531 531 ava_free( op, f->f_ava, 1 ); (gdb) list 526 527 case LDAP_FILTER_EQUALITY: 528 case LDAP_FILTER_GE: 529 case LDAP_FILTER_LE: 530 case LDAP_FILTER_APPROX: 531 ava_free( op, f->f_ava, 1 ); 532 break; 533 534 case LDAP_FILTER_SUBSTRINGS: 535 if ( f->f_sub_initial.bv_val != NULL ) { (gdb) up #3 0x00000000004798a3 in slap_sasl2dn (opx=opx@entry=0x1aa6ce0, saslname=saslname@entry=0x7f933827b600, sasldn=sasldn@entry=0x7f933827b450, flags=flags@entry=2) at ../../../../servers/slapd/saslauthz.c:2018 2018 filter_free_x( opx, op.ors_filter, 1 ); (gdb) list 1313 } 2014 if( !BER_BVISNULL( &op.o_req_ndn ) ) { 2015 slap_sl_free( op.o_req_ndn.bv_val, opx->o_tmpmemctx ); 2016 } 2017 if( op.ors_filter ) { 2018 filter_free_x( opx, op.ors_filter! 1 ); 2019 } 2020 if( !BER_BVISNULL( &op.ors_filterstr ) ) { 2021 ch_free( op.ors_filterstr.bv_val ); 2022 } (gdb) up (gdb) up #4 0x0000000000480c0f in slap_sasl_getdn (conn=<optimized out>, op=0x1aa6ce0, op@entry=0x0, id=id@entry=0x7f933827b610, user_realm=user_realm@entry=0x0, dn=dn@entry=0x7f933827b600, flags=2) at ../../../../servers/slapd/sasl.c:1884 1884 slap_sasl2dn( op, dn, &dn2, flags ); (gdb) list 1879 } 1880 *dn = dn2; 1881 } 1882 1883 /* Run thru regexp */ 1884 slap_sasl2dn( op, dn, &dn2, flags ); 1885 if( !BER_BVISNULL( &dn2 ) ) { 1886 slap_sl_free( dn->bv_val, op->o_tmpmemctx ); 1887 *dn = dn2; 1888 Debug( LDAP_DEBUG_TRACE, (gdb) up #5 0x00000000004811a1 in slap_sasl_canonicalize (sconn=0x190a7e0, context=<optimized out>, in=0x1a864b0 "Administrator", inlen=13, flags=<optimized out>,seser_realm=0x0, out=0x190b581 "", out_max=1024, out_len=0x190b06c) at ../../../../servers/slapd/sasl.c:656 656 rc = slap_sasl_getdn( conn, NULL, &bvin, (char *)user_realm, &dn, (gdb) list 651 if ( !rc ) goto nene; 652 } 653 654 bvin.bv_val = (char *)in; 655 bvin.bv_len = inlen; 656 rc = slap_sasl_getdn( conn, NULL, &bvin, (char *)user_realm, &dn, 657 (flags & SASL_CU_AUTHID) ? SLAP_GETDN_AUTIDID : SLAP_GETDN_AUTHZID ); 658 if ( rc != LDAP_SUCCESS ) { 659 sasl_seterror( sconn, 0, ldap_err2string( rc ) ); 660 return SASL_NOAUTHZ; (gdb) up #6 0x00007f93c16b2558 in _sasl_canon_user (conn=conn@entry=0x190a7e0, user=0x1a864b0 "Administrator", ulen=13, flags=flags@entry=3, oparams=oparams@entry=0x190b050) at ../../lib/canonusr.c:109 109 ../../lib/canonusr.c: Datei oder Verzeichnis nicht gefunden. (gdb) list 104 result = _sasl_getcallback(conn, 105 SASL_CB_CANON_USER, 106 (sasl_callback_ft *)&cuser_cb, 107 &context); 108 if(result == SASL_OK && cuser_cb) { 109 result = cuser_cb(conn, 110 context, 111 user, 112 ulen, 113 flags, 114 (conn->type == SASL_CONN_SERVER ? 115 sconn->user_realm : 116 NULL), 117 user_buf, 118 CANON_BUF_SIZE, 119 lenp); (gdb) up #7 0x00007f93c16b2870 in _sasl_canon_user_lookup (conn=0x190a7e0, user=<optimized out>, ulen=<optimized out>, flags=3, oparams=0x190b050) at ../../lib/canonusr.c:273 271 int result; 272 273 result = _sasl_canon_user (conn, 274 user, 275 ulen, 276 flags, 277 oparams); (gdb) up #8 0x00007f93bd46b936 in saml_server_mech_step (conn_context=0x1a2e8e0, params=0x190b9f0, clientin=0x1a55bea "", clientinlen=<optimized out>, serverout=<optimized out>, serveroutlen=<optimized out>, oparams=0x190b050) at cy2_saml.c:281 281 if ((error = params->canon_user(params->utils->conn, userid, 0, (gdb) list 276 goto out; 277 if ((error = params->canon_user(params->utils->conn, userid, 0, 278 SASL_CU_AUTHID, oparams)) != SASL_OK) 279 goto out; 280 } else { 281 if ((error = params->canon_user(params->utils->conn, userid, 0, 282 SASL_CU_AUTHID|SASL_CU_AUTHZID, oparams)) != SASL_OK) 283 goto out; 284 } 285 Memory information: In frame1 ava->bv_val is not "Administrator" (the user I authenticated with) but the bv_len is 13. (gdb) print *ava $13 = {aa_desc = 0x1444650, aa_value = {bv_len = 13, bv_val = 0x20 <Address 0x20 out of bounds>}}

1 0

Re: (ITS#8111) Re-ordering schema attributeTypes crashes slapd
by zach＠puppetlabs.com 18 Aug '15

18 Aug '15

--cDyoBSpeMmeqjtIY Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 17, 2015 at 05:35:11PM -0700, Ryan Tandy wrote: >Hi Zach, > >I just pushed a patch for another ITS that reminded me of this one. > >Assuming you can still reproduce this, would you please try the patch=20 >mentioned at the end of http://www.openldap.org/its/?findid=3D8199 and=20 >let us know whether it resolves your crash? I've upgraded to 2.4.41.1 from the LTB packages an no longer have the=20 issue. --=20 Zach Leslie :: Puppet Labs --cDyoBSpeMmeqjtIY Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- iQEcBAABCgAGBQJV02IGAAoJEH5UaJShK/iwqlwH/2Dc1xZor0I4of/4wWKN/o/y 73ZrwM/jsYsGez9jxU2t4gIhDfSBx38hqBFj801hGmF0Ef3xY8fDTlv7nEhXZ30J CEk2zQ4py0aBJG6kAe8sfZdmS8SPS6o2FzNoCR4w833oj11qYMIUbJLHzLsA6LWg STCcBapBIf0iHSfDBlwN3w93C5UXp71pWLAJEqcfSCtxhCCpAJr3WdndLjboN89c YVKl5NzDTmgInHmne4Ob+QFCN1nNw5z1uE2tkhV0FAw3QpVZsnDXIVW9Gjmr835c +UfQHqErY5PstxHY1V42h6CyX8IDby3rB5NuR31H/8uI0ToNaQry5EX40ZCvaa4= =BGFe -----END PGP SIGNATURE----- --cDyoBSpeMmeqjtIY--

1 0

(ITS#8173)
by Adrian.Raemy＠vtg.admin.ch 18 Aug '15

18 Aug '15

Dear Howard, The fix runs stable now over weeks.=20 slapd didn't crashed anymore. Thank you for the help. I guess we can close the ticket. Best Regards Adrian=20

1 0

Re: (ITS#8212) slapd stops on consumer node
by ryan＠openldap.org 15 Aug '15

15 Aug '15

Hi, I experimented with openldap 2.4.41 and the files you posted and did not experience any crashes. Please try to reduce the example setup as far as possible, until you find that the crash disappears after you disable a particular directive. Please also make sure you have the debugging symbols for slapd and libldap installed, and then try to provide a backtrace from gdb after triggering the crash, as well as the exact config files (and, if possible, relevant DIT contents, such as ppolicy configuration) that were in use at the time. Thanks for your help, Ryan

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by subbarao＠computer.org 14 Aug '15

14 Aug '15

On 08/14/2015 10:38 AM, Howard Chu wrote: > subbarao(a)computer.org wrote: >> In the particular situation that's prompting this request, it's not just >> two or three values -- for one entry it was over 38000 values that had >> accumulated over time! (and generally high values for many other >> entries). > > If you have entries with tens of thousands of Bind failures being > recorded, you have a security monitoring problem. The limit applied by > the patch for this ITS will only mask the problem. The fact that your > security auditors haven't already noticed these tens of thousands of > Bind failures and stopped them at their source means you've got a > major vulnerability in your network security. Hi Howard, what's happening here is that an application account's password has expired, and its owners have neglected to change the password. Meanwhile, the old password remains hardcoded in the application, which continues to issue BIND requests that fail. The functionality of this particular application isn't mission-critical -- it may even be deprecated at this point by another application, so it's likely not a priority for the account owners given everything else on their plates. In this customer environment, the monitoring of password failures has historically been done outside of LDAP, and focuses on user accounts which tend to have higher privileges. LDAP application accounts (which tend to have minimal privileges) aren't treated the same. These bind failures may get cleaned up at some point during a periodic review of application accounts with expired passwords, but it's not likely to happen soon, given the lower level of risk/impact. Given that the bind failures themselves aren't causing a problem (the system as a whole has ample capacity), the only operations-impacting issue is the continually increasing entry size. So for this customer environment, I feel the best approach for now is to simply purge the stale failure timestamps (which I would prefer to do with a standard OpenLDAP configuration setting than with an external script). As I mentioned in an earlier message, I see the slapo-ppolicy man page as being friendly to this feature request: "Excess timestamps beyond those allowed by pwdMaxFailure may also be purged." From my perspective, it's a valuable hygienic feature for environments such as this one. Regards, -Kartik

1 0

Re: (ITS#8133) segfault at startup with memberof+dds
by ryan＠nardis.ca 14 Aug '15

14 Aug '15

Hi, On Wed, May 06, 2015 at 05:48:53PM +0000, alexoz66(a)gmail.com wrote: >When those two overlays are configured in this order: {0}memberof, {1}dds, slapd >will segfault at startup if dds finds a dynamicObject entry that is past its >expiration time. This does not occur if an object expires while slapd is >running, only during startup. A patch for this is in git master now. Please test it. http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=patch;h=1c4942413… thanks, Ryan

1 0

Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by hyc＠symas.com 14 Aug '15

14 Aug '15

subbarao(a)computer.org wrote: > In the particular situation that's prompting this request, it's not just > two or three values -- for one entry it was over 38000 values that had > accumulated over time! (and generally high values for many other entries). If you have entries with tens of thousands of Bind failures being recorded, you have a security monitoring problem. The limit applied by the patch for this ITS will only mask the problem. The fact that your security auditors haven't already noticed these tens of thousands of Bind failures and stopped them at their source means you've got a major vulnerability in your network security. -- -- 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#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes
by hyc＠symas.com 14 Aug '15

14 Aug '15

subbarao(a)computer.org wrote: > On 07/06/2015 01:30 PM, Michael Ströder wrote: >> Consider that you are under on-going attack with many different >> accounts affected by the lockout treshold. Then you cannot simply wait >> for pwdFailureCountInterval seconds because your system is changing >> all the time. >> >> Such a situation is a real world scenario. > > Ok -- I'm probably not understanding enough about your particular > scenario to fully appreciate the concerns that you express. But I think > there could be ways to address them in this enhancement -- for instance, > by adding optional parameter(s) like ppolicy_purge_failures <nfailures> > and/or ppolicy_purge_olderthan <timestamp>, which could then be > configured to accommodate the scenario you describe. > > At this point, I'll think I'll leave it up to the OpenLDAP developers as > to how they want to proceed on this, and/or to ask for more information. I've added a pwdMaxRecordedFailure attribute to the policy schema. Overloading pwdMaxFailure would be a mistake. MaxRecordedFailure will default to MaxFailure if that is set. It defaults to 5 if nothing is set. There's no good reason to allow the timestamps to accumulate without bound. This is now available for testing in git master. -- -- 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

(ITS#8217) Add msvc support to lmdb
by nacho.resa＠gmail.com 13 Aug '15

13 Aug '15

Full_Name: Ignacio Casal Quinteiro Version: OS: Windows 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.30.165.68) On the url below you can find a fork that adds support for msvc builds: https://github.com/nice-software/lmdb/tree/wip/msvc https://github.com/nice-software/lmdb/commit/e871e736949dafee4e84f07c6cfb1b…

1 0

(ITS#8216) Windows 'make test' failures
by mhardin＠symas.com 11 Aug '15

11 Aug '15

Full_Name: Matthew Hardin Version: 2.4.40 OS: Windows 7/64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (69.43.206.100) Many 'make test' test fail, for a variety of reasons, with LMDB and BDB/HDB backends. OpenLDAP 2.4.40 Berkeley DB 4.8.30 Environment: MSYS from MinGW/MSYS 2013072300 Win-Builds MinGW 32- and 64-bit toolchain The following tests fail: test0-c-concurrency: problems reported by slapd-tester test039-glue-ldap-concurrency: seems to fail for the same reasons as test008 test043-delta-syncrepl: lmdb always fails, hdb/bdb sometimes test049-sync-config: config parsing problems test050-syncrepl-multimaster: config parsing problems test056-monitor: incorrect monitor output test058-syncrepl-asymmetric: parsing problems test059-slave-config: parsing problems test061-syncreplication-initiation: parsing prlelems test063-delta-multimaster: undetermined test064-constraint: include file processing (parsing?)

1 0

(ITS#8215) Slapmodify delete support and documentation
by ondra＠mistotebe.net 11 Aug '15

11 Aug '15

Full_Name: Ond&#345;ej Kuzn.k Version: master OS: URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20150811-slapmodify-delete-su… Submission from: (NULL) (62.84.155.99) It is only possible to delete entries in a back-ldif database. This patchset implements the equivalent functionality in the other core databases, enables the same in back-config and adds a slapmodify manpage. With that in place, test007-slapmodify is switched to fail on errors now. ModRDN stays unimplemented at this point. An outstanding issue is that valgrind complains about a memory leak in bdb on entry delete, which I have not been able to pinpoint nor fix. The above patch is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the above patches were developed by Ondřej Kuzník <ondra(a)mistotebe.net>. I have not assigned rights and/or interest in this work to any party. I, Ondřej Kuzník, hereby place the above 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#8210) slapd-sock: second subsequent bind fails
by michael＠stroeder.com 10 Aug '15

10 Aug '15

This is a cryptographically signed message in MIME format. --------------ms010905090300000505030204 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Ouch! This was caused by a stupid typo in my test script (not even the so= cket listener demon). =3D> you can close this ITS --------------ms010905090300000505030204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBkUwggUtoAMCAQICAwtNUDANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTE0MDkyMzIw NDc1NVoXDTE1MDkyNDIyMDUxOFowXzEZMBcGA1UEDRMQNk0yWTdpOXpEdGU2alV3MDEdMBsG A1UEAwwUbWljaGFlbEBzdHJvZWRlci5jb20xIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ry b2VkZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAynIH09fU597v4fg4 uwqFJDPUxQHV9qxrfM/c3veStPyYl0JorqKHrD+hfCNZ+Toy65NN9f9vO26WnnLoDF+FE2Dk Qi61iTgK5jZTr5dJG1WQkk698UNWO87lUWBRYYiUM7wC3ek2E0rzR99qIxE4dG9wws19F3KK JvNN8tMTyoPw5Vkw4qx2SW54WEBMx7oCXBIZPPDD8ovled6vDVweVSaYXFUbkxbKJR87Msih 34Ba+cM5SAHQNQ11jaSJjFeqbQnXjf0nESnvo0XIckc9w240w3jcgu6b5SIQBI2vv5TaIv7v KqNk0o+cGc9NnCw5/xD/OAB9Aj/qDca6NheHCQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTj z1BhELZO3zEJfmZQ4I+c6NCXIjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAf BgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYL KwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0 byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20g Q0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns YXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2Nl cnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAfByd9CEZ5pYuRa3XuE5xeJoIpDol22 A1mIGuRqxaBFIummmDoYr/tVgFod/3evQJO+ad8T5wpooY422HkHN4a1UI7ujCKcU/PrQSxm v28AAsl4Fo/InY1nSFjMy8Ywj3EG+Edj1ZpCkzTRNGZjBa6Uj7UY7UW71kYcSdCBe8vc9Zi3 6OnHGkXROWIii3wBKLDEZqxknw0Cj9TTy5lyllYzyHku4aXLDPhiYrTzhWiwgYmweaLvW/yq YVsHRpW8udzqOr6xvUVcuRmfMTENM7RSlRZVw2+5+I+zn7jqOrrULO1FP7Lo5cPilsMpSMOw oJnPLQgNZvXOPFO6VaDCOboxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBAgMLTVAwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDgxMDIwMTYzOVowLwYJKoZIhvcNAQkEMSIE IN0rkT8RP7qlBKrXk/xlwi5XOTHkEhE0LBzpK0MTyVPiMGwGCSqGSIb3DQEJDzFfMF0wCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwgacGCyqGSIb3DQEJ EAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwtNUDANBgkq hkiG9w0BAQEFAASCAQA6PYpjB145s6zVte9XShsZ6a5c8BzGgSr+igVbZKSCeOJXdMnfh7vC NbsXC33U8E534/tSvho+oY3SkSUl2VyxASEIWywl0Xsl6ij/0IwPdF7mMci0ARJj2TIs/uwV FXMWMZqMBq5Yc/3Br9PVMkAsocAOWUxrlkzFZQlw4mk7NM1J5yrO9Rvh4ivdf0Pap1B8WzrO pOE488SO3Q53i2dJMX1N+am0SAfvEu+Q+/s4lTVzA3uvsWt4AGNqjmRgZMLJbJy1ecNTyk/E LzLJtyC4NwHEutomoQGP/MczC3iXMflxmvdaPRJlpWu2DhxU+GlBVMZTD8oBfG+ZfkxXvYaq AAAAAAAA --------------ms010905090300000505030204--

1 0

Re: (ITS#8054) Operation duration logging
by hyc＠symas.com 10 Aug '15

10 Aug '15

Hallvard Breien Furuseth wrote: > Den 10. aug. 2015 14:41, skrev Hallvard Breien Furuseth: >> It's total time which is interesting when looking for hot spots >> which need attention. So I suggest that plus either one of the >> others, or percentage of the total spent doing one of the others. > > Sorry - total+one of the other was silly probably, it just > leaves us calculating the missing one when looking for that > one. Total + percentage of one of the others makes sense, > or (etime, qtime) since a high value still will stand out. > Yes, I prefer explicit (etime, qtime) - anyone who needs the total can add it up themselves. -- -- 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#8054) Operation duration logging
by h.b.furuseth＠usit.uio.no 10 Aug '15

10 Aug '15

Den 10. aug. 2015 14:41, skrev Hallvard Breien Furuseth: > It's total time which is interesting when looking for hot spots > which need attention. So I suggest that plus either one of the > others, or percentage of the total spent doing one of the others. Sorry - total+one of the other was silly probably, it just leaves us calculating the missing one when looking for that one. Total + percentage of one of the others makes sense, or (etime, qtime) since a high value still will stand out. -- Hallvard

1 0

Re: (ITS#8054) Operation duration logging
by h.b.furuseth＠usit.uio.no 10 Aug '15

10 Aug '15

Den 05. aug. 2015 18:38, skrev hyc(a)symas.com: >clem.oudot(a)gmail.com wrote: >> Seems other LDAP servers have choosen 'etime' (see >> http://ludopoitou.com/2015/02/24/about-auditing-ldap-operations/). Why >> not try to use the same word? > > etime is fine with me. The other problem here is that it's counting duration > from when slapd received the request (which is fine) but usually the op gets > queued immediately after. For this etime to be useful we need to know both the > amount of time spent queued, and the amount of time spent actually executing. > qtime and etime? It's total time which is interesting when looking for hot spots which need attention. So I suggest that plus either one of the others, or percentage of the total spent doing one of the others. -- Hallvard

1 0

Re: (ITS#8198)
by peter＠adpm.de 08 Aug '15

08 Aug '15

Hi, you may want to have a look at Followup 1 for ITS#8205: I added a manual page for pbkdf2 and adapted it's Makefile to install it too. The commit can be found on my github repo: https://github.com/marschap/openldap/commit/f63202e8aa68e3391f52d2481f649ca… BTW: I successfully tested your nettle patch with by Debian-based server. Thank you! Best Peter -- Peter Marschall peter(a)adpm.de

1 0

(ITS#8205)
by peter＠adpm.de 08 Aug '15

08 Aug '15

Hi, I extended the patch series with a manual page for pbkdf2 * https://github.com/marschap/openldap/commit/f63202e8aa68e3391f52d2481f649ca… contrib/passwd/pbkdf2: add man page, install it too Best Peter -- Peter Marschall peter(a)adpm.de

1 0

(ITS#8214) slapo-rwm silently fails to convert config lines without rwm- prefix to cn=config
by ryan＠openldap.org 08 Aug '15

08 Aug '15

Full_Name: Ryan Tandy Version: OS: URL: Submission from: (NULL) (24.68.37.4) Submitted by: ryan A slapd.conf stanza like: overlay rwm rewriteEngine on works correctly in normal usage. Converting this to cn=config does not emit any olcRwmRewrite values, but succeeds nonetheless. The prefixed version: overlay rwm rwm-rewriteEngine on is converted correctly. In general, cn=config doesn't accept the unprefixed values at all, which is fine, but at least trying to ldapadd such a value returns an error. Considering this unimportant for now since the omitting the prefix is "strongly discouraged" by the man page.

1 0

Re: (ITS#8213) When using the rwm, openldap down
by ryan＠nardis.ca 08 Aug '15

08 Aug '15

Hi, Patched in git master: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=7380… Please test the patch, and report any problems with it. Thanks!

1 0

(ITS#8213) When using the rwm, openldap down
by ohno＠designet.co.jp 08 Aug '15

08 Aug '15

Full_Name: Kimiyoshi Ohno Version: 2.4.41 OS: CentOS 7 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (220.211.13.215) When I changed configuration for openldap, openldap stopped. (Aborted) I was carried out the following operations. (1) I created the following environment. ---- ---- ---- ---- # ldapsearch -LLL -Y EXTERNAL -b 'olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config' -H ldapi:/// SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 dn: olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcRwmConfig olcOverlay: {0}rwm olcRwmRewrite: {0}rwm-rewriteEngine on olcRwmRewrite: {1}rwm-rewriteContext searchFilter olcRwmRewrite: {2}rwm-rewriteRule "aaa" "111" ":@" olcRwmRewrite: {3}rwm-rewriteRule "bbb" "222" ":@" ---- ---- ---- ---- (2) I created the following ldif file. ---- ---- ---- ---- dn: olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config changetype: modify delete: olcRwmRewrite olcRwmRewrite: rwm-rewriteRule "aaa" "111" ":@" - ---- ---- ---- ---- (3) I was carried out ldapmodify. ---- ---- ---- ---- # ldapmodify -Y EXTERNAL -H ldapi:/// -f down.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config" ldap_result: Can't contact LDAP server (-1) ---- ---- ---- ---- In this case, openldap has stopped. : : 55c45c8b connection_get(16) 55c45c8b ==> sasl_bind: dn="" mech=EXTERNAL datalen=0 55c45c8b SASL Canonicalize [conn=1000]: authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" 55c45c8b slap_sasl_getdn: conn 1000 id=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth [len=55] 55c45c8b SASL Canonicalize [conn=1000]: slapAuthcDN="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" 55c45c8b SASL proxy authorize [conn=1000]: authcid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" authzid="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" 55c45c8b connection_get(16) 55c45c8b conn=1000 op=1 do_modify: dn (olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config) => ldap_bv2dn(olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config,0) <= ldap_bv2dn(olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(clcOverlay={0}rwm,olcDatabase={1}bdb,cn=config)=0 => ldap_dn2bv(272) <= ldap_dn2bv(olcOverlay={0}rwm,olcDatabase={1}bdb,cn=config)=0 55c45c8b conn=1000 op=1 modifications: 55c45c8b delete: olcRwmRewrite 55c45c8b one value, length 32 55c45c8b [slapd:0] unknown command '' slapd: rwm.c:2195: rwm_cf_gen: Assertion `rc == 0' failed. Aborted Is this openldap BUG?

1 0

Re: (ITS#8054) Operation duration logging
by hyc＠symas.com 05 Aug '15

05 Aug '15

clem.oudot(a)gmail.com wrote: > 2015-02-11 18:33 GMT+01:00 <h.b.furuseth(a)usit.uio.no>: >> On 11. feb. 2015 12:38, Michael Str=C3=B6der wrote: >>> h.b.furuseth(a)usit.uio.no wrote: >>>> Cool feture, but please use fewer characteres in the already >>>> bloated log. How about "time=3D<integer>us" or even omit the "us"? >>> >>> +1 >>> >>> But 'time' sounds a bit general. >>> How about 'tdu' or even 'td' as abbreviation for "time duration"? >> >> I don't think so. You can't see from that what it means unless you >> already know, so you have to look it up just to see if you're >> interested. 'time' you can decide to look up if you are interested. >> > > Seems other LDAP servers have choosen 'etime' (see > http://ludopoitou.com/2015/02/24/about-auditing-ldap-operations/). Why > not try to use the same word? etime is fine with me. The other problem here is that it's counting duration from when slapd received the request (which is fine) but usually the op gets queued immediately after. For this etime to be useful we need to know both the amount of time spent queued, and the amount of time spent actually executing. qtime and etime? -- -- 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#8212) slapd stops on consumer node
by Steen.Brandtmar＠ibapplications.com 05 Aug '15

05 Aug '15

--_003_DB4PR03MB0911E60223F1AE5F6D332DA881750DB4PR03MB0911eurp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi I did an upgrade to 2.4.41 on the consumer node. Then restarted. Consumer IP =3D 10.0.100.6 Provider IP=3D10.0.100.5 Then - on consumer - I executed this command: /usr/local/bin/ldappasswd -x -D uid=3Dxxxxxx,ou=3DPeople,dc=3Diba,dc=3Dloca= l -w oldpasswod -H ldap://10.0.100.6 -Z -s newpassword uid=3Dxxxxxx,ou=3DPe= ople,dc=3Diba,dc=3Dlocal ldap_result: Can't contact LDAP server (-1) And logfile writes: Aug 4 16:33:40 mgmt1 slapd[17418]: conn=3D1141 fd=3D18 ACCEPT from IP=3D10= .0.100.6:42621 (IP=3D0.0.0.0:389) Aug 4 16:33:40 mgmt1 slapd[17418]: conn=3D1141 op=3D0 EXT oid=3D1.3.6.1.4.= 1.1466.20037 Aug 4 16:33:40 mgmt1 slapd[17418]: conn=3D1141 op=3D0 STARTTLS Aug 4 16:33:40 mgmt1 slapd[17418]: conn=3D1141 op=3D0 RESULT oid=3D err=3D= 0 text=3D Aug 4 16:33:40 mgmt1 slapd[17418]: conn=3D1141 fd=3D18 TLS established tls= _ssf=3D128 ssf=3D128 Aug 4 16:33:40 mgmt1 slapd[17418]: conn=3D1141 op=3D1 BIND dn=3D"uid=3Dxxx= xxx,ou=3DPeople,dc=3Diba,dc=3Dlocal" method=3D128 Aug 4 16:33:40 mgmt1 slapd[17418]: conn=3D1141 op=3D1 BIND dn=3D"uid=3Dxxx= xxx,ou=3DPeople,dc=3Diba,dc=3Dlocal" mech=3DSIMPLE ssf=3D0 Aug 4 16:33:40 mgmt1 slapd[17418]: ppolicy_bind: Entry uid=3Dxxxxxx,ou=3DP= eople,dc=3Diba,dc=3Dlocal has an expired password: 6 grace logins Aug 4 16:33:41 mgmt1 slapd[17418]: conn=3D1141 op=3D1 RESULT tag=3D97 err= =3D0 text=3D Aug 4 16:33:41 mgmt1 slapd[17418]: conn=3D1141 op=3D2 EXT oid=3D1.3.6.1.4.= 1.4203.1.11.1 Aug 4 16:33:41 mgmt1 slapd[17418]: conn=3D1141 op=3D2 PASSMOD id=3D"uid=3D= xxxxxx,ou=3DPeople,dc=3Diba,dc=3Dlocal" new and slapd stops. I've attached configs for consumer and provider. Regards Steen Steen Brandtmar +45 2893 5392 Insurance Business Applications Gammel Kongevej 1, 4. sal 1610 K=F8benhavn, Danmark =A0=A0=A0 -----Original Message----- From: openldap-its(a)OpenLDAP.org [mailto:openldap-its@OpenLDAP.org]=20 Sent: 4. august 2015 13:55 To: Steen Brandtmar <Steen.Brandtmar(a)ibapplications.com> Subject: Re: (ITS#8212) slapd stops on consumer node *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report = has been assigned the tracking number ITS#8212. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunte= ers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue repo= rt, you may do so by replying to this message. Note that any mail sent to = openldap-its(a)openldap.org with (ITS#8212) in the subject will automatically= be attached to the issue report. mailto:openldap-its@openldap.org?subject=3D(ITS#8212) You may follow the progress of this report by loading the following URL in = a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=3D8212 Please remember to retain your issue tracking number (ITS#8212) on any furt= her messages you send to us regarding this report. If you don't then you'l= l just waste our time and yours because we won't be able to properly track = the report. Please note that the Issue Tracking System is not intended to be used to se= ek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. --_003_DB4PR03MB0911E60223F1AE5F6D332DA881750DB4PR03MB0911eurp_ Content-Type: text/plain; name="slapd.provider.conf.txt" Content-Description: slapd.provider.conf.txt Content-Disposition: attachment; filename="slapd.provider.conf.txt"; size=4671; creation-date="Tue, 04 Aug 2015 14:52:51 GMT"; modification-date="Tue, 04 Aug 2015 14:52:51 GMT" Content-Transfer-Encoding: base64 Iw0KIyBTZWUgc2xhcGQuY29uZig1KSBmb3IgZGV0YWlscyBvbiBjb25maWd1cmF0aW9uIG9wdGlv bnMuDQojIFRoaXMgZmlsZSBzaG91bGQgTk9UIGJlIHdvcmxkIHJlYWRhYmxlLg0KIw0KaW5jbHVk ZSAgICAgICAgIC91c3IvbG9jYWwvZXRjL29wZW5sZGFwL3NjaGVtYS9jb3JlLnNjaGVtYQ0KaW5j bHVkZSAgICAgICAgIC91c3IvbG9jYWwvZXRjL29wZW5sZGFwL3NjaGVtYS9jb3NpbmUuc2NoZW1h DQppbmNsdWRlICAgICAgICAgL3Vzci9sb2NhbC9ldGMvb3BlbmxkYXAvc2NoZW1hL25pcy5zY2hl bWENCmluY2x1ZGUgICAgICAgICAvdXNyL2xvY2FsL2V0Yy9vcGVubGRhcC9zY2hlbWEvaW5ldG9y Z3BlcnNvbi5zY2hlbWENCmluY2x1ZGUgICAgICAgICAvdXNyL2xvY2FsL2V0Yy9vcGVubGRhcC9z Y2hlbWEvc2FtYmEuc2NoZW1hDQppbmNsdWRlICAgICAgICAgL3Vzci9sb2NhbC9ldGMvb3Blbmxk YXAvc2NoZW1hL3Bwb2xpY3kuc2NoZW1hDQppbmNsdWRlICAgICAgICAgL3Vzci9sb2NhbC9ldGMv b3BlbmxkYXAvc2NoZW1hL2liYS5zY2hlbWENCmluY2x1ZGUgICAgICAgICAvdXNyL2xvY2FsL2V0 Yy9vcGVubGRhcC9zY2hlbWEvcmFkaXVzLnNjaGVtYQ0KIw0KIyBEZWZpbmUgZ2xvYmFsIEFDTHMg dG8gZGlzYWJsZSBkZWZhdWx0IHJlYWQgYWNjZXNzLg0KIw0KIyBEbyBub3QgZW5hYmxlIHJlZmVy cmFscyB1bnRpbCBBRlRFUiB5b3UgaGF2ZSBhIHdvcmtpbmcgZGlyZWN0b3J5DQojIHNlcnZpY2Ug QU5EIGFuIHVuZGVyc3RhbmRpbmcgb2YgcmVmZXJyYWxzLg0KI3JlZmVycmFsICAgICAgIGxkYXA6 Ly9yb290Lm9wZW5sZGFwLm9yZw0KIw0KcGlkZmlsZSAgL3Vzci9sb2NhbC92YXIvcnVuL3NsYXBk LnBpZA0KYXJnc2ZpbGUgL3Vzci9sb2NhbC92YXIvcnVuL3NsYXBkLmFyZ3MNCmxvZ2xldmVsIDI1 Ng0KIw0KIyBMb2FkIGR5bmFtaWMgYmFja2VuZCBtb2R1bGVzOg0KIyAgICAgICBjaGVja19wYXNz d29yZCBpcyBJQkFzIHNwZWNpYWwgcGFzc3dvcmQgY29tcGxpYW5jZSBtb2R1bGUNCiMgICAgICAg c21iazVwd2QgaXMgYSBtb2R1bGUgdGhhdCB1cGRhdGVzIHNhbWJhcHdkcyB3aGVuIHVzZXJwd2Rz IGNoYW5nZQ0KbW9kdWxlcGF0aCAgICAgIC91c3IvbG9jYWwvZXRjL29wZW5sZGFwL2liYQ0KbW9k dWxlbG9hZCAgICAgIGNoZWNrX3Bhc3N3b3JkLnNvDQptb2R1bGVsb2FkICAgICAgc21iazVwd2Qu c28NCiMgbW9kdWxlbG9hZCAgICBiYWNrX2JkYi5sYQ0KIyBtb2R1bGVsb2FkICAgIGJhY2tfaGRi LmxhDQojIG1vZHVsZWxvYWQgICAgYmFja19sZGFwLmxhDQojDQojIFNhbXBsZSBzZWN1cml0eSBy ZXN0cmljdGlvbnMNCiMgICAgICAgUmVxdWlyZSBpbnRlZ3JpdHkgcHJvdGVjdGlvbiAocHJldmVu dCBoaWphY2tpbmcpDQojICAgICAgIFJlcXVpcmUgMTEyLWJpdCAoM0RFUyBvciBiZXR0ZXIpIGVu Y3J5cHRpb24gZm9yIHVwZGF0ZXMNCiMgICAgICAgUmVxdWlyZSA2My1iaXQgZW5jcnlwdGlvbiBm b3Igc2ltcGxlIGJpbmQNCiMgc2VjdXJpdHkgc3NmPTEgdXBkYXRlX3NzZj0xMTIgc2ltcGxlX2Jp bmQ9NjQNCnNlY3VyaXR5IHNzZj0wIHVwZGF0ZV9zc2Y9MTI4DQojc2VjdXJpdHkgc3NmPTEyOA0K Iw0KVExTQ2VydGlmaWNhdGVGaWxlIC91c3IvbG9jYWwvZXRjL29wZW5sZGFwL2NlcnQuY3J0DQpU TFNDZXJ0aWZpY2F0ZUtleUZpbGUgL3Vzci9sb2NhbC9ldGMvb3BlbmxkYXAvY2VydC5rZXkNClRM U0NBQ2VydGlmaWNhdGVGaWxlIC91c3IvbG9jYWwvZXRjL29wZW5sZGFwL2NlcnQuY3J0DQojDQoj IFNhbXBsZSBhY2Nlc3MgY29udHJvbCBwb2xpY3k6DQojICAgICAgIFJvb3QgRFNFOiBhbGxvdyBh bnlvbmUgdG8gcmVhZCBpdA0KIyAgICAgICBTdWJzY2hlbWEgKHN1YillbnRyeSBEU0U6IGFsbG93 IGFueW9uZSB0byByZWFkIGl0DQojICAgICAgIE90aGVyIERTRXM6DQojICAgICAgICAgICAgICAg QWxsb3cgc2VsZiB3cml0ZSBhY2Nlc3MNCiMgICAgICAgICAgICAgICBBbGxvdyBhdXRoZW50aWNh dGVkIHVzZXJzIHJlYWQgYWNjZXNzDQojICAgICAgICAgICAgICAgQWxsb3cgYW5vbnltb3VzIHVz ZXJzIHRvIGF1dGhlbnRpY2F0ZQ0KIyAgICAgICBEaXJlY3RpdmVzIG5lZWRlZCB0byBpbXBsZW1l bnQgcG9saWN5Og0KIw0KIyBpZiBubyBhY2Nlc3MgY29udHJvbHMgYXJlIHByZXNlbnQsIHRoZSBk ZWZhdWx0IHBvbGljeQ0KIyBhbGxvd3MgYW55b25lIGFuZCBldmVyeW9uZSB0byByZWFkIGFueXRo aW5nIGJ1dCByZXN0cmljdHMNCiMgdXBkYXRlcyB0byByb290ZG4uICAoZS5nLiwgImFjY2VzcyB0 byAqIGJ5ICogcmVhZCIpDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj DQojIHBlcm1pc3Npb25zDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMN Ci4NCi4NCi5zZWNyZXQNCi4NCi4NCi4NCiMNCiMgR2xvYmFsIHNlY3Rpb24NCiAgICAgICBzZXJ2 ZXJJRCAgICAxDQojIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KIyBCREIgZGF0YWJhc2UgZGVmaW5pdGlvbnMNCiMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjDQojDQpkYXRhYmFzZSAgICAgICAgYmRiDQpzdWZmaXggICAgICAgICAgImRj PWliYSxkYz1sb2NhbCINCnJvb3RkbiAgICAgICAgICAiZGM9aWJhLGRjPWxvY2FsIg0KbW9uaXRv cmluZyAgICAgIG9mZg0KIyBDbGVhcnRleHQgcGFzc3dvcmRzLCBlc3BlY2lhbGx5IGZvciB0aGUg cm9vdGRuLCBzaG91bGQNCiMgYmUgYXZvaWQuICBTZWUgc2xhcHBhc3N3ZCg4KSBhbmQgc2xhcGQu Y29uZig1KSBmb3IgZGV0YWlscy4NCiMgVXNlIG9mIHN0cm9uZyBhdXRoZW50aWNhdGlvbiBlbmNv dXJhZ2VkLg0Kcm9vdHB3ICAgICAgICAgIHtTU0hBfQ0KIyBUaGUgZGF0YWJhc2UgZGlyZWN0b3J5 IE1VU1QgZXhpc3QgcHJpb3IgdG8gcnVubmluZyBzbGFwZCBBTkQNCiMgc2hvdWxkIG9ubHkgYmUg YWNjZXNzaWJsZSBieSB0aGUgc2xhcGQgYW5kIHNsYXAgdG9vbHMuDQojIE1vZGUgNzAwIHJlY29t bWVuZGVkLg0KZGlyZWN0b3J5ICAgICAgIC91c3IvbG9jYWwvdmFyL2liYS1kYXRhDQojIEluZGlj ZXMgdG8gbWFpbnRhaW4NCmluZGV4ICAgb2JqZWN0Q2xhc3MgICAgIGVxDQppbmRleCAgIGNuICAg ICAgICAgICAgICBlcQ0KaW5kZXggICBvdSAgICAgICAgICAgICAgZXENCmluZGV4ICAgZ2lkTnVt YmVyICAgICAgIGVxDQppbmRleCAgIHVpZE51bWJlciAgICAgICBlcQ0KaW5kZXggICBlbnRyeVVV SUQgICAgICAgZXENCmluZGV4ICAgZW50cnlDU04gICAgICAgIGVxDQppbmRleCAgIG1lbWJlciAg ICAgICAgICBlcQ0KIw0KaW5kZXggbG9naW5TaGVsbCBlcQ0KaW5kZXggdWlkIGVxLHByZXMsc3Vi DQppbmRleCBtZW1iZXJVaWQgZXEscHJlcyxzdWINCmluZGV4IHVuaXF1ZU1lbWJlciBlcSxwcmVz DQppbmRleCBzYW1iYVNJRCBlcQ0KaW5kZXggc2FtYmFQcmltYXJ5R3JvdXBTSUQgZXENCmluZGV4 IHNhbWJhR3JvdXBUeXBlIGVxDQppbmRleCBzYW1iYVNJRExpc3QgZXENCmluZGV4IHNhbWJhRG9t YWluTmFtZSBlcQ0KaW5kZXggZGVmYXVsdCBzdWINCmluZGV4IG1vZGlmeVRpbWVzdGFtcCBlcQ0K Iw0KIyBMZXQgdGhlIHJlcGxpY2EgRE4gaGF2ZSBsaW1pdGxlc3Mgc2VhcmNoZXMNCmxpbWl0cyBk bi5leGFjdD0ib3U9UmVwbGljYXRvcixjbj1NYW5hZ2VycyxkYz1pYmEsZGM9bG9jYWwiIHRpbWUu c29mdD11bmxpbWl0ZWQgdGltZS5oYXJkPXVubGltaXRlZCBzaXplLnNvZnQ9dW5saW1pdGVkIHNp emUuaGFyZD11bmxpbWl0ZWQNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0Kb3ZlcmxheSBzbWJrNXB3ZA0KIyAg ICAgICBzbWJrNXB3ZC1lbmFibGUgICAgICAgICBzYW1iYQ0KICAgICAgICBzbWJrNXB3ZC1tdXN0 LWNoYW5nZSAgICA1MTg0MDAwDQpvdmVybGF5IHN5bmNwcm92DQpzeW5jcHJvdi1jaGVja3BvaW50 IDEwIDUNCiMNCiMgc3luY3JlcGwgZGlyZWN0aXZlDQpzeW5jcmVwbCByaWQ9MDU2IHByb3ZpZGVy PWxkYXA6Ly8xMC4wLjEwMC42IGJpbmRtZXRob2Q9c2ltcGxlDQogICAgICAgICBiaW5kZG49Im91 PVJlcGxpY2F0b3IsY249TWFuYWdlcnMsZGM9aWJhLGRjPWxvY2FsIiBjcmVkZW50aWFscz1YeHh4 eA0KICAgICAgICAgc2VhcmNoYmFzZT0iZGM9aWJhLGRjPWxvY2FsIg0KICAgICAgICAgc2NoZW1h Y2hlY2tpbmc9b24gdHlwZT1yZWZyZXNoQW5kUGVyc2lzdCB0aW1lb3V0PTMgcmV0cnk9IjYwIDUg MTIwICsiDQogICAgICAgICBzdGFydHRscz15ZXMNCiMgICAgICAgICB0bHNfY2VydD0vdXNyL2xv Y2FsL2V0Yy9vcGVubGRhcC9zMDYuY3J0DQojICAgICAgICAgdGxzX2tleT0vdXNyL2xvY2FsL2V0 Yy9vcGVubGRhcC9zMDYua2V5DQojICAgICAgICAgdGxzX2NhY2VydD0vdXNyL2xvY2FsL2V0Yy9v cGVubGRhcC9zMDYuY3J0DQptaXJyb3Jtb2RlIG9uDQojDQpvdmVybGF5IHBwb2xpY3kNCnBwb2xp Y3lfZGVmYXVsdCAiY249ZGVmYXVsdHB3cG9saWN5LG91PXB3cG9saWNpZXMsZGM9aWJhLGRjPWxv Y2FsIg0KcHBvbGljeV91c2VfbG9ja291dA0KcHBvbGljeV9oYXNoX2NsZWFydGV4dA0KIw0K --_003_DB4PR03MB0911E60223F1AE5F6D332DA881750DB4PR03MB0911eurp_ Content-Type: text/plain; name="slapd.consumer.conf.txt" Content-Description: slapd.consumer.conf.txt Content-Disposition: attachment; filename="slapd.consumer.conf.txt"; size=4728; creation-date="Tue, 04 Aug 2015 14:48:34 GMT"; modification-date="Tue, 04 Aug 2015 14:48:34 GMT" Content-Transfer-Encoding: base64 Iw0KIyBTZWUgc2xhcGQuY29uZig1KSBmb3IgZGV0YWlscyBvbiBjb25maWd1cmF0aW9uIG9wdGlv bnMuDQojIFRoaXMgZmlsZSBzaG91bGQgTk9UIGJlIHdvcmxkIHJlYWRhYmxlLg0KIw0KaW5jbHVk ZSAgICAgICAgIC91c3IvbG9jYWwvZXRjL29wZW5sZGFwL3NjaGVtYS9jb3JlLnNjaGVtYQ0KaW5j bHVkZSAgICAgICAgIC91c3IvbG9jYWwvZXRjL29wZW5sZGFwL3NjaGVtYS9jb3NpbmUuc2NoZW1h DQppbmNsdWRlICAgICAgICAgL3Vzci9sb2NhbC9ldGMvb3BlbmxkYXAvc2NoZW1hL25pcy5zY2hl bWENCmluY2x1ZGUgICAgICAgICAvdXNyL2xvY2FsL2V0Yy9vcGVubGRhcC9zY2hlbWEvaW5ldG9y Z3BlcnNvbi5zY2hlbWENCmluY2x1ZGUgICAgICAgICAvdXNyL2xvY2FsL2V0Yy9vcGVubGRhcC9z Y2hlbWEvc2FtYmEuc2NoZW1hDQppbmNsdWRlICAgICAgICAgL3Vzci9sb2NhbC9ldGMvb3Blbmxk YXAvc2NoZW1hL3Bwb2xpY3kuc2NoZW1hDQppbmNsdWRlICAgICAgICAgL3Vzci9sb2NhbC9ldGMv b3BlbmxkYXAvc2NoZW1hL2liYS5zY2hlbWENCmluY2x1ZGUgICAgICAgICAvdXNyL2xvY2FsL2V0 Yy9vcGVubGRhcC9zY2hlbWEvcmFkaXVzLnNjaGVtYQ0KIw0KIyBEZWZpbmUgZ2xvYmFsIEFDTHMg dG8gZGlzYWJsZSBkZWZhdWx0IHJlYWQgYWNjZXNzLg0KDQojIERvIG5vdCBlbmFibGUgcmVmZXJy YWxzIHVudGlsIEFGVEVSIHlvdSBoYXZlIGEgd29ya2luZyBkaXJlY3RvcnkNCiMgc2VydmljZSBB TkQgYW4gdW5kZXJzdGFuZGluZyBvZiByZWZlcnJhbHMuDQojcmVmZXJyYWwgICAgICAgbGRhcDov L3Jvb3Qub3BlbmxkYXAub3JnDQoNCnBpZGZpbGUgICAgICAgICAvdXNyL2xvY2FsL3Zhci9ydW4v c2xhcGQucGlkDQphcmdzZmlsZSAgICAgICAgL3Vzci9sb2NhbC92YXIvcnVuL3NsYXBkLmFyZ3MN CmxvZ2xldmVsICAgICAgICAyNTYNCiMNCiMgTG9hZCBkeW5hbWljIGJhY2tlbmQgbW9kdWxlczoN CiMgICAgICAgY2hlY2tfcGFzc3dvcmQgaXMgSUJBcyBzcGVjaWFsIHBhc3N3b3JkIGNvbXBsaWFu Y2UgbW9kdWxlDQojICAgICAgIHNtYms1cHdkIGlzIGEgbW9kdWxlIHRoYXQgdXBkYXRlcyBzYW1i YXB3ZHMgd2hlbiB1c2VycHdkcyBjaGFuZ2UNCm1vZHVsZXBhdGggICAgICAvdXNyL2xvY2FsL2V0 Yy9vcGVubGRhcC9pYmENCm1vZHVsZWxvYWQgICAgICBjaGVja19wYXNzd29yZC5zbw0KbW9kdWxl bG9hZCAgICAgIHNtYms1cHdkLnNvDQojIG1vZHVsZXBhdGggICAgL3Vzci9sb2NhbC9saWJleGVj L29wZW5sZGFwDQojIG1vZHVsZWxvYWQgICAgYmFja19iZGIubGENCiMgbW9kdWxlbG9hZCAgICBi YWNrX2hkYi5sYQ0KIyBtb2R1bGVsb2FkICAgIGJhY2tfbGRhcC5sYQ0KIw0KIyBTYW1wbGUgc2Vj dXJpdHkgcmVzdHJpY3Rpb25zDQojICAgICAgIFJlcXVpcmUgaW50ZWdyaXR5IHByb3RlY3Rpb24g KHByZXZlbnQgaGlqYWNraW5nKQ0KIyAgICAgICBSZXF1aXJlIDExMi1iaXQgKDNERVMgb3IgYmV0 dGVyKSBlbmNyeXB0aW9uIGZvciB1cGRhdGVzDQojICAgICAgIFJlcXVpcmUgNjMtYml0IGVuY3J5 cHRpb24gZm9yIHNpbXBsZSBiaW5kDQpzZWN1cml0eSBzc2Y9MCB1cGRhdGVfc3NmPTEyOA0KIyAg ICAgICAgICAgICAgICBzaW1wbGVfYmluZD0xMjgNCiNzZWN1cml0eSBzc2Y9MTI4DQojDQpUTFND ZXJ0aWZpY2F0ZUZpbGUgL3Vzci9sb2NhbC9ldGMvb3BlbmxkYXAvY2VydC5jcnQNClRMU0NlcnRp ZmljYXRlS2V5RmlsZSAvdXNyL2xvY2FsL2V0Yy9vcGVubGRhcC9jZXJ0LmtleQ0KVExTQ0FDZXJ0 aWZpY2F0ZUZpbGUgL3Vzci9sb2NhbC9ldGMvb3BlbmxkYXAvY2VydC5jcnQNCiMNCiMgU2FtcGxl IGFjY2VzcyBjb250cm9sIHBvbGljeToNCiMgICAgICAgUm9vdCBEU0U6IGFsbG93IGFueW9uZSB0 byByZWFkIGl0DQojICAgICAgIFN1YnNjaGVtYSAoc3ViKWVudHJ5IERTRTogYWxsb3cgYW55b25l IHRvIHJlYWQgaXQNCiMgICAgICAgT3RoZXIgRFNFczoNCiMgICAgICAgICAgICAgICBBbGxvdyBz ZWxmIHdyaXRlIGFjY2Vzcw0KIyAgICAgICAgICAgICAgIEFsbG93IGF1dGhlbnRpY2F0ZWQgdXNl cnMgcmVhZCBhY2Nlc3MNCiMgICAgICAgICAgICAgICBBbGxvdyBhbm9ueW1vdXMgdXNlcnMgdG8g YXV0aGVudGljYXRlDQojICAgICAgIERpcmVjdGl2ZXMgbmVlZGVkIHRvIGltcGxlbWVudCBwb2xp Y3k6DQojDQojIGlmIG5vIGFjY2VzcyBjb250cm9scyBhcmUgcHJlc2VudCwgdGhlIGRlZmF1bHQg cG9saWN5DQojIGFsbG93cyBhbnlvbmUgYW5kIGV2ZXJ5b25lIHRvIHJlYWQgYW55dGhpbmcgYnV0 IHJlc3RyaWN0cw0KIyB1cGRhdGVzIHRvIHJvb3Rkbi4gIChlLmcuLCAiYWNjZXNzIHRvICogYnkg KiByZWFkIikNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCiMgcGVy bWlzc2lvbnMNCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIw0KLg0KLg0K Lg0Kc2VjcmV0DQouDQouDQouDQojIGFueW9uZSBlbHNlIGdldHMgbm90aGluZyAtIHNvIHB3J3Mg YXJlbid0IGxpc3RlZCB1bmxlc3MgeW91IGFyZSB0aGUgdXNlciBvcg0KIw0KIw0KIyBHbG9iYWwg c2VjdGlvbg0KICAgICAgIHNlcnZlcklEICAgIDINCiMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjDQojIEJEQiBkYXRh YmFzZSBkZWZpbml0aW9ucw0KIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMNCiMNCmRhdGFiYXNlICAgICAgICBiZGIN CnN1ZmZpeCAgICAgICAgICAiZGM9aWJhLGRjPWxvY2FsIg0Kcm9vdGRuICAgICAgICAgICJkYz1p YmEsZGM9bG9jYWwiDQptb25pdG9yaW5nICAgICAgb2ZmDQojIENsZWFydGV4dCBwYXNzd29yZHMs IGVzcGVjaWFsbHkgZm9yIHRoZSByb290ZG4sIHNob3VsZA0KIyBiZSBhdm9pZC4gIFNlZSBzbGFw cGFzc3dkKDgpIGFuZCBzbGFwZC5jb25mKDUpIGZvciBkZXRhaWxzLg0KIyBVc2Ugb2Ygc3Ryb25n IGF1dGhlbnRpY2F0aW9uIGVuY291cmFnZWQuDQpyb290cHcgICAgICAgICAge1NTSEF9DQojIFRo ZSBkYXRhYmFzZSBkaXJlY3RvcnkgTVVTVCBleGlzdCBwcmlvciB0byBydW5uaW5nIHNsYXBkIEFO RA0KIyBzaG91bGQgb25seSBiZSBhY2Nlc3NpYmxlIGJ5IHRoZSBzbGFwZCBhbmQgc2xhcCB0b29s cy4NCiMgTW9kZSA3MDAgcmVjb21tZW5kZWQuDQpkaXJlY3RvcnkgICAgICAgL3Vzci9sb2NhbC92 YXIvaWJhLWRhdGENCiMgSW5kaWNlcyB0byBtYWludGFpbg0KaW5kZXggICBvYmplY3RDbGFzcyAg ICAgZXENCmluZGV4ICAgY24gICAgICAgICAgICAgIGVxDQppbmRleCAgIG91ICAgICAgICAgICAg ICBlcQ0KaW5kZXggICBnaWROdW1iZXIgICAgICAgZXENCmluZGV4ICAgdWlkTnVtYmVyICAgICAg IGVxDQppbmRleCAgIGVudHJ5VVVJRCAgICAgICBlcQ0KaW5kZXggICBlbnRyeUNTTiAgICAgICAg ZXENCmluZGV4ICAgbWVtYmVyICAgICAgICAgIGVxDQojDQppbmRleCBsb2dpblNoZWxsIGVxDQpp bmRleCB1aWQgZXEscHJlcyxzdWINCmluZGV4IG1lbWJlclVpZCBlcSxwcmVzLHN1Yg0KaW5kZXgg dW5pcXVlTWVtYmVyIGVxLHByZXMNCmluZGV4IHNhbWJhU0lEIGVxDQppbmRleCBzYW1iYVByaW1h cnlHcm91cFNJRCBlcQ0KaW5kZXggc2FtYmFHcm91cFR5cGUgZXENCmluZGV4IHNhbWJhU0lETGlz dCBlcQ0KaW5kZXggc2FtYmFEb21haW5OYW1lIGVxDQppbmRleCBkZWZhdWx0IHN1Yg0KaW5kZXgg bW9kaWZ5VGltZXN0YW1wIGVxDQojDQojIExldCB0aGUgcmVwbGljYSBETiBoYXZlIGxpbWl0bGVz cyBzZWFyY2hlcw0KbGltaXRzIGRuLmV4YWN0PSJvdT1SZXBsaWNhdG9yLGNuPU1hbmFnZXJzLGRj PWliYSxkYz1sb2NhbCIgdGltZS5zb2Z0PXVubGltaXRlZCB0aW1lLmhhcmQ9dW5saW1pdGVkIHNp emUuc29mdD11bmxpbWl0ZWQgc2l6ZS5oYXJkPXVubGltaXRlZA0KIw0KIyMjIyMjIyMjIyMjIyMj IyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMjIyMj DQpvdmVybGF5IHNtYms1cHdkDQpvdmVybGF5IHN5bmNwcm92DQpzeW5jcHJvdi1jaGVja3BvaW50 IDEwIDUNCiMNCiMgc3luY3JlcGwgZGlyZWN0aXZlDQpzeW5jcmVwbCByaWQ9MDU2IHByb3ZpZGVy PWxkYXA6Ly8xMC4wLjEwMC41IGJpbmRtZXRob2Q9c2ltcGxlDQogICAgICAgICBiaW5kZG49Im91 PVJlcGxpY2F0b3IsY249TWFuYWdlcnMsZGM9aWJhLGRjPWxvY2FsIiBjcmVkZW50aWFscz1YeHh4 eA0KICAgICAgICAgc2VhcmNoYmFzZT0iZGM9aWJhLGRjPWxvY2FsIg0KICAgICAgICAgc2NoZW1h Y2hlY2tpbmc9b24gdHlwZT1yZWZyZXNoQW5kUGVyc2lzdCB0aW1lb3V0PTMgcmV0cnk9IjYwIDUg MTIwICsiDQogICAgICAgICBzdGFydHRscz15ZXMNCiMgICAgICAgICB0bHNfY2VydD0vdXNyL2xv Y2FsL2V0Yy9vcGVubGRhcC9zMDUuY3J0DQojICAgICAgICAgdGxzX2tleT0vdXNyL2xvY2FsL2V0 Yy9vcGVubGRhcC9zMDUua2V5DQojICAgICAgICAgdGxzX2NhY2VydD0vdXNyL2xvY2FsL2V0Yy9v cGVubGRhcC9zMDUuY3J0DQptaXJyb3Jtb2RlIG9uDQojDQpvdmVybGF5IHBwb2xpY3kNCnBwb2xp Y3lfZGVmYXVsdCAiY249ZGVmYXVsdHB3cG9saWN5LG91PXB3cG9saWNpZXMsZGM9aWJhLGRjPWxv Y2FsIg0KcHBvbGljeV91c2VfbG9ja291dA0KcHBvbGljeV9oYXNoX2NsZWFydGV4dA0KIw0K --_003_DB4PR03MB0911E60223F1AE5F6D332DA881750DB4PR03MB0911eurp_--

1 0

Re: (ITS#8212) slapd stops on consumer node
by michael＠stroeder.com 04 Aug '15

04 Aug '15

Steen.brandtmar(a)ibapplications.com wrote: > We are running two servers in mirrormode. > When we run ldappasswd on provider node all is OK and passwords are changed in > bdb. Logfile shows PASSMOD on relevant uid. > When we run the same ldappasswd command on consumer node, slapd stops abruptly > on this node and must be started manually. Could you please retry with 2.4.41? If it's still a problem with 2.4.41 a stripped down config for reproducing the issue would be good. Ciao, Michael.

1 0

(ITS#8212) slapd stops on consumer node
by Steen.brandtmar＠ibapplications.com 04 Aug '15

04 Aug '15

Full_Name: Steen Brandtmar Version: 2.4.40 OS: Linux Ubuntu 12.04 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.48.99.242) Hi We are running two servers in mirrormode. When we run ldappasswd on provider node all is OK and passwords are changed in bdb. Logfile shows PASSMOD on relevant uid. When we run the same ldappasswd command on consumer node, slapd stops abruptly on this node and must be started manually.

1 0

(ITS#8211) ssf does not reflect actual security of connection
by hkario＠redhat.com 03 Aug '15

03 Aug '15

Full_Name: Hubert Kario Version: all OS: Linux URL: Submission from: (NULL) (213.175.37.10) Section "14.2.1. Security Strength Factors"[1] states "A SSF greater than one (>1) roughly correlates to the effective encryption key length.". This is not the case more often than not. Problem is that ssf as it is calculated now doesn't take into consideration all the cryptographic primitives in use. In other words, a connection that uses a 512 bit RSA certificates and negotiates TLS_RSA_WITH_AES_128_CBC_SHA (AES256-SHA) certainly does not provide security equivalent to "modern strong ciphers"[2][3] and should be awarded "256". Similarly a connection that uses 512 bit DH parameters and negotiates TLS_DHE_RSA_WITH_AES_256_CBC_SHA (DHE-RSA-AES256-SHA) does not provide security that should be awarded "256"[5]. In fact, recommending use of high key sizes[2] will cause the connection to use _less_ secure CBC ciphersuites[5] with clients that support AEAD ciphersuites with AES-128 only (like Thunderbird and Firefox do). Section 8.4.9[2] also calls RC4 a "modern strong cipher", most cryptographers disagree[6]. So I think either: 1). ssf needs to be redefined to consider any value higher that "2" to be equal, and requiring the server administrators to enable only ciphersuites they consider secure, or 2). the whole code that calculates ssf needs to be updated to take into account many more things: * use of AEAD * use of Encrypt-then-MAC * the protocol version used (both because TLS1.0 specific attacks[7] as wewell as the use of SHA1+MD5 for signatures which limits the connection security to 80 bits[8] (optimistically) if client certificates are in use in TLS < 1.2) * encryption algorithm on session tickets * current state of attacks on a given ciphersuite * the size of ECDHE curve, FFDHE prime or server certificate key size, depending on ciphersuite negotiated * the signature algorithm used in Certificate Verify message * the key size of client certificate * the signature on the client certificate and key sizes in CA certificates * the HMAC used * key size of the symmetric cipher * (probably other things I didn't think about) 1 - http://www.openldap.org/doc/admin24/security.html 2 - http://w.w.openldap.org/doc/admin24/access-control.html section 8.4.9 3 - https://freakattack.com/ 4 - https://weakdh.org/ 5 - http://www.isg.rhul.ac.uk/tls/Lucky13.html 6 - https://tools.ietf.org/html/rfc7465 7 - https://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack 8 - https://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf

1 0

Re: (ITS#8209) Broken MDB_CP_COMPACT threading
by h.b.furuseth＠usit.uio.no 03 Aug '15

03 Aug '15

Okay, that was one confused ITS in response to equally confused code. Trying again. Draft fixes in my updated branch "mdb/copyfd1" (non-fast-forward). It's broken if mdb_env_copythr() has a write error: * copyfd1 can (A) overrun buffer mc_wlen, and (B) hang, if if cthr_toggle() is in cond_wait() when the error occurs: It sets mc_new and returns success. cwalk() proceeds to write at mc_wbuf+mc_wlen, but copythr() did not reset mc_wlen. Then copyfd1() waits for the now-dead copythr() to clear mc_new. Fixes: (A) join the if(mc_status) and while(mc_new==1) in cthr_toggle. (B) Drop the wait before THREAD_FINISH(), it seems pointless. Both Posix and Windows doc say that THREAD_FINISH waits. Or if Windows needs it for some reason, then copythr must live until it receives mc_new=-1, so it can set mc_new=0. * copyfd1() loses any error from the final cthr_toggle(). Fix: Return rc ? rc : my.mc_status. Tested on Linux with fake write errors, with/without fixes. While not a bug, I also see no point in both threads' initial waits. copyfd1() can own the buffer initially (set mc_new=0). I'm guessing the waits are there because the code tries to guide the threads from step to step, but it broke because you didn't think of every possibility. It's easier to define and maintain one cond_wait state per thread and keep things consistent there. More on error checking: copyfd1() omits most error checking and the cleanup after errors. E.g. it does not tell copythr to finish if txn_begin fails. Each thread is slow to react to errors in the other thread. I/O will cease quicker if both threads set and check mc_status. If so, mc_status can no longer be part of the cond_wait condition, since it won't be mutex-protected. So the threads might chat a bit more before finishing. I'd rename mc_status -> mc_error. "while (!my->mc_error && ...)" is quite self-explanatory, unlike "while (!my->mc_status && ...)". About lock/unlock outside vs. inside the loop: When outside, copythr() must block for the threads to exchange buffers. When inside, the slowest thread does not block, but there are more lock/unlock/wait calls. Testing: Locks inside is clearly faster on tmpfs. On a regular FS I don't know - it may have been a bit slower, but times varied more than the difference. Finally, cwalk() could re-use the page buffers it mallocs. -- Hallvard

1 0

(ITS#8210) slapd-sock: second subsequent bind fails
by michael＠stroeder.com 01 Aug '15

01 Aug '15

Full_Name: Version: OS: URL: Submission from: (NULL) (79.223.48.67) When using *one* connection for sending *two* sequential bind requests slapd-sock blocks. I have a working test case which I can send upon request.

1 0

Re: (ITS#8207) ppolicy: pwdMinLength not checked if pwdInHistory == 0
by michael＠stroeder.com 01 Aug '15

01 Aug '15

IanB wrote: > I've attempted to test with OpenLDAP 2.4.41 but cannot get password changing > to work at all, constantly getting error: "passwd: Authentication token > manipulation error" Greping through the source this message is output from slapo-nssov. Are you sure that you re-built and installed slapo-nssov from 2.4.41? Also you should always first test with ldappasswd command-line tool to avoid false interaction with other software. What else do you have configured? > Unfortunately, I cannot spend more time on this now. What does that mean? If you don't want to work on this ITS any further it's probably the best to close it. Ciao, Michael.

1 0

Re: (ITS#8207) ppolicy: pwdMinLength not checked if pwdInHistory == 0
by porjo38＠yahoo.com.au 01 Aug '15

01 Aug '15

I've attempted to test with OpenLDAP 2.4.41 but cannot get password changing to work at all, constantly getting error: "passwd: Authentication token manipulation error" Unfortunately, I cannot spend more time on this now. On 30/07/15 03:01, Michael Ströder wrote: > porjo38(a)yahoo.com.au wrote: >> Using password policy overlay, pwdMinLength is not checked when pwdInHistory == >> 0. > > I tried to reproduce this with my local OpenLDAP 2.4.41 installation. > In one case I thought to see this but I could not reproduce all the time. > Maybe there's another condition for this to happen. > > Could you please also test with release 2.4.41? > > And please also post the entry with the password (and relevant pwd* attrs) and > the pwdPolicy entry used, both as LDIF (minus sensitive data). > > Ciao, Michael. >

1 0

Re: (ITS#8181) LMDB page leaks etc when treating DBs as data
by hyc＠symas.com 30 Jul '15

30 Jul '15

juerg.bircher(a)helmedica.com wrote: > --_000_D1E06B6B7E2juergbircherhelmedicacom_ > Content-Type: text/plain; charset="iso-8859-1" > Content-Transfer-Encoding: quoted-printable > > Hi Howard, > > I am new to lmdb. I have been working with lmdb intensively for one month. = > I really appreciate your great work. Good efficient C code is not always fo= > und! > Well I like to follow up on that reported issue. > I am using multiple databases on the same environment. I was a bit confused= > about your statement that most application use never subDBs? I think it is= > a great feature that helps to support multiple indexes. > I ran unintentionally into a related problem as I set the compare function = > for the main db to an integer based one opposite to the literal compare fun= > ction which is the default. Therefore when opening a database by its name t= > he wrong database might be returned as the integer compare function might t= > hink names are equal as only 96 bits (in my function) are compared. So the = > compare function only compares the prefix of the database names! > Maybe the database meta should be kept in a private space. But I also agree= > on your statement to keep things simple. I solved the problem by never usi= > ng the main db so under no circumstances the database meta is corrupted. I = > think the price paid for having only named databases is very cheap as I ope= > n databases at startup and keep the database index (dbi). Thanks for the feedback. Yes, this is the best practice - if you're using named databases, you should not use the main DB. (Or just make sure you don't create name collisions.) -- -- 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#8181) LMDB page leaks etc when treating DBs as data
by juerg.bircher＠helmedica.com 30 Jul '15

30 Jul '15

Sorry the mail before was not as plain text. Here again... Hi Howard, I am new to lmdb. I have been working with lmdb intensively for one month. I really appreciate your great work. Good efficient C code is not always found! Well I like to follow up on that reported issue. I am using multiple databases on the same environment. I was a bit confused about your statement that most application use never subDBs? I think it is a great feature that helps to support multiple indexes. I ran unintentionally into a related problem as I set the compare function for the main db to an integer based one opposite to the literal compare function which is the default. Therefore when opening a database by its name the wrong database might be returned as the integer compare function might think names are equal as only 96 bits (in my function) are compared. So the compare function only compares the prefix of the database names! Maybe the database meta should be kept in a private space. But I also agree on your statement to keep things simple. I solved the problem by never using the main db so under no circumstances the database meta is corrupted. I think the price paid for having only named databases is very cheap as I open databases at startup and keep the database index (dbi). Regards J=FCrg Rockethealth by Helmedica AG Web: www.rockethealth.ch J=FCrg Bircher Chief Technology Officer Mail: juerg.bircher(a)helmedica.ch

1 0

Re: (ITS#8181) LMDB page leaks etc when treating DBs as data
by juerg.bircher＠helmedica.com 30 Jul '15

30 Jul '15

--_000_D1E06B6B7E2juergbircherhelmedicacom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Howard, I am new to lmdb. I have been working with lmdb intensively for one month. = I really appreciate your great work. Good efficient C code is not always fo= und! Well I like to follow up on that reported issue. I am using multiple databases on the same environment. I was a bit confused= about your statement that most application use never subDBs? I think it is= a great feature that helps to support multiple indexes. I ran unintentionally into a related problem as I set the compare function = for the main db to an integer based one opposite to the literal compare fun= ction which is the default. Therefore when opening a database by its name t= he wrong database might be returned as the integer compare function might t= hink names are equal as only 96 bits (in my function) are compared. So the = compare function only compares the prefix of the database names! Maybe the database meta should be kept in a private space. But I also agree= on your statement to keep things simple. I solved the problem by never usi= ng the main db so under no circumstances the database meta is corrupted. I = think the price paid for having only named databases is very cheap as I ope= n databases at startup and keep the database index (dbi). Regards J=FCrg Rockethealth by Helmedica AG Web: www.rockethealth.ch<http://www.rockethealth.ch/> J=FCrg Bircher Chief Technology Officer Mail: juerg.bircher(a)helmedica.ch<mailto:christoph.baumann@helmedica.ch> --_000_D1E06B6B7E2juergbircherhelmedicacom_ Content-Type: text/html; charset="iso-8859-1" Content-ID: <86943131EABB0349A4C3B75E01000508(a)eurprd03.prod.outlook.com> Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-= 1"> </head> <body style=3D"word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-lin= e-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-fami= ly: Calibri, sans-serif;"> <div>Hi Howard,</div> <div><br> </div> <div>I am new to lmdb. I have been working with lmdb intensively for one mo= nth. I really appreciate your great work. Good efficient C code is not alwa= ys found! </div> <div>Well I like to follow up on that reported issue.</div> <div>I am using multiple databases on the same environment. I was a bit con= fused about your statement that most application use never subDBs? I think = it is a great feature that helps to support multiple indexes. </div> <div>I ran unintentionally into a related problem as I set the compare func= tion for the main db to an integer based one opposite to the literal compar= e function which is the default. Therefore when opening a database by its n= ame the wrong database might be returned as the integer compare function might think names are equal as on= ly 96 bits (in my function) are compared. So the compare function only comp= ares the prefix of the database names!</div> <div>Maybe the database meta should be kept in a private space. But I also = agree on your statement to keep things simple. I solved the problem by neve= r using the main db so under no circumstances the database meta is corrupte= d. I think the price paid for having only named databases is very cheap as I open databases at startup and keep= the database index (dbi).</div> <div><br> </div> <div>Regards</div> <div>J=FCrg</div> <div><br> </div> <p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt; = line-height: 11pt;"> <b><span lang=3D"EN-US" style=3D"font-size: 9pt; color: rgb(139, 141, 141);= font-family: 'FS Joey Medium';">Rockethealth by Helmedica AG<o:p></o:p></s= pan></b></p> <p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt;"= ><span lang=3D"EN-US" style=3D"font-size: 9pt; color: gray;">Web</span><spa= n lang=3D"EN-US" style=3D"font-size: 9pt; color: rgb(31, 73, 125);">: = </span><span style=3D"font-size: 9pt; color: rgb(31, 73, 125);"><a href=3D"= http://www.rockethealth.ch/" style=3D"color: rgb(149, 79, 114);"><span lang= =3D"EN-US" style=3D"color: blue;">www.rockethealth.ch</span></a></span><spa= n style=3D"font-size: 9pt; color: rgb(31, 73, 125);"></span><span lang=3D"E= N-US" style=3D"color: rgb(31, 73, 125);"><o:p></o:p></span></p> <p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt;"= ><span lang=3D"EN-US" style=3D"font-size: 9pt; color: gray;">J=FCrg Bircher= </span></p> <p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt;"= ><span style=3D"color: gray; font-size: 9pt;">Chief Technology </span>= <span style=3D"color: rgb(128, 128, 128); font-size: 12px;">Officer</span><= /p> <p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt;"= ><span lang=3D"EN-US" style=3D"font-size: 9pt; color: gray;">Mail: </s= pan><span style=3D"font-size: 9pt; color: rgb(31, 73, 125);"><a href=3D"mai= lto:christoph.baumann@helmedica.ch" style=3D"color: rgb(149, 79, 114);"><sp= an lang=3D"EN-US" style=3D"color: blue;">juerg.bircher(a)helmedica.ch</span><= /a></span><span lang=3D"EN-US" style=3D"color: rgb(31, 73, 125);"><o:p></o:= p></span></p> <p class=3D"MsoNormal" style=3D"margin: 0cm 0cm 0.0001pt; font-size: 11pt;"= ><span style=3D"color: gray; font-size: 11pt;"> </span><span style=3D"= font-size: 14px;"> </span></p> </body> </html> --_000_D1E06B6B7E2juergbircherhelmedicacom_--

1 0

Re: (ITS#8207) ppolicy: pwdMinLength not checked if pwdInHistory == 0
by porjo38＠yahoo.com.au 30 Jul '15

30 Jul '15

Thanks, I will try with 2.4.41 and let you know. I may not get a chance to test until this weekend. Relevant output from slapcat: dn: uid=ian,ou=UserAccounts,o=cwa objectClass: posixAccount objectClass: top objectClass: inetOrgPerson objectClass: ldapPublicKey givenName: Ian displayName: Ian Bishop uid: ian homeDirectory: /home/ian loginShell: /bin/bash cn: Ian Bishop structuralObjectClass: inetOrgPerson entryUUID: 767c952c-c867-1034-933d-53d15af42765 creatorsName: cn=admin,o=cwa createTimestamp: 20150727045535Z gidNumber: 1000 sn: Bishop uidNumber: 10000 userPassword:: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx pwdChangedTime: 20150729140556Z pwdHistory: 20150729140556Z#1.3.6.1.4.1.1466.115.121.1.40#38#{SSHA}xxxxxxxxxx entryCSN: 20150729140556.659729Z#000000#000#000000 modifiersName: cn=admin,o=cwa modifyTimestamp: 20150729140556Z dn: cn=passwordDefault,ou=policies,o=cwa objectClass: pwdPolicy objectClass: person objectClass: top cn: passwordDefault sn: passwordDefault pwdAttribute: userPassword pwdCheckQuality: 0 pwdMinAge: 0 pwdMaxAge: 0 pwdMaxFailure: 3 pwdFailureCountInterval: 0 pwdLockout: TRUE pwdAllowUserChange: TRUE pwdExpireWarning: 0 pwdGraceAuthNLimit: 0 pwdMustChange: FALSE pwdSafeModify: TRUE structuralObjectClass: person entryUUID: 3314dc02-ca3f-1034-825a-9d42205b22be creatorsName: cn=config createTimestamp: 20150729131225Z pwdMinLength: 6 pwdLockoutDuration: 300 pwdInHistory: 1 entryCSN: 20150729135535.164545Z#000000#000#000000 modifiersName: cn=admin,o=cwa modifyTimestamp: 20150729135535Z On 30/07/15 03:01, Michael Ströder wrote: > porjo38(a)yahoo.com.au wrote: >> Using password policy overlay, pwdMinLength is not checked when pwdInHistory == >> 0. > > I tried to reproduce this with my local OpenLDAP 2.4.41 installation. > In one case I thought to see this but I could not reproduce all the time. > Maybe there's another condition for this to happen. > > Could you please also test with release 2.4.41? > > And please also post the entry with the password (and relevant pwd* attrs) and > the pwdPolicy entry used, both as LDIF (minus sensitive data). > > Ciao, Michael. >

1 0

Re: (ITS#8209) Broken MDB_CP_COMPACT threading
by h.b.furuseth＠usit.uio.no 29 Jul '15

29 Jul '15

On 29/07/15 21:25, h.b.furuseth(a)usit.uio.no wrote: > (...)And copythr should set mc_new=0 before exiting also when setting > mc_status. so copyfd1 won't just sit and wait. I forgot it clears mc_new before setting mc_status. It's if it didn't keep the mutex it would have to set mc_new afterwards (after locking the mutex).

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs