- openldap-bugs - openldap.org

Re: (ITS#7853) Improve safety of mdb_env_close
by dw＠botanicus.net 13 May '14

13 May '14

It's worth mentioning that this is not a theoretical issue, I've already hit it while writing unit tests.

1 0

(ITS#7853) Improve safety of mdb_env_close
by dw＠botanicus.net 13 May '14

13 May '14

Full_Name: David Wilson Version: LMDB 0.9.11 OS: URL: https://raw.githubusercontent.com/dw/py-lmdb/master/misc/readers_mrb_env.pa… Submission from: (NULL) (178.238.153.20) Currently if a user (wilfully or accidentally, say, through composition of third party libs) opens the same LMDB environment twice within a process, and maintains active read transactions at the time one mdb_env_close() is called, all reader slots will be deallocated in all environments due to the logic around line 4253 that unconditionally clears reader slots based on PID. I'd like to avoid this in py-lmdb, and seems there are a few alternatives to fix it: 1) Tell users not to do that (doc fix, nobody reads docs) 2) Externally maintain a set of (st_dev, st_ino) keys representing already opened environments, and check any attempt to open an environment against this list, failing if data.mdb's key already appears. 3) Disable the mdb_env_close() cleanup loop when MDB_NOTLS is enabled. Since no reader slot will ever exist in TLS in this mode, the existing mdb_env_close() doc "All transactions, databases, and cursors must already be closed before calling this function." ensures no readers exist at close time, and the loop need not run. 4) Modify lock.mdb to include MDB_env* address within the process, and update mdb_env_close() to invalidate only readers associated with the environment being closed. I dislike using the MDB_env* as an opaque publicly visible cookie, but perhaps storing this field might be reused for other things in future. Option 3 lets the user wilfully mix py-lmdb Environment objects within the process, since py-lmdb always enables NOTLS, but it does not fix the case where the user is integrating a Python application with a C library with some opaque interface, and both the application and the library independently have need to access the environment. This kind of scenario regularly crops up in huge software projects, the user may not even be aware the library uses LMDB internally. In that case, the user is again exposed to having their reader slots silently become deallocated through no fault of their own. Option 4 is the least aesthetic, but has all the benefits of option 3 in addition to preventing the "accidental integration" scenario. I've attached a patch for it (against 0.9.11), although I completely understand if it does not get applied. :) One alternative would be instead of using MDB_env* address, using a monotonically increasing counter based on a static global, say, "mrb_token", but this might break in the case two copies of LMDB were somehow linked in the application. (It's easy to argue the user is an idiot in this case ;) David

1 0

Re: (ITS#7852) problems in memberof overlay
by quanah＠zimbra.com 12 May '14

12 May '14

--On May 12, 2014 at 10:20:24 AM +0000 efbt(a)hotmail.com wrote: > Full_Name: jeff.gao > Version: 2.4.23 The ITS system is for reporting software bugs, not for asking usage questions. Please redirect your question to the openldap-technical(a)openldap.org list. I would note that the OpenLDAP 2.4.23 build shipped by RHEL is utterly broken. I strongly advise you obtain a working build. If you are unable to build OpenLDAP yourself, you can obtain a working build from Symas or the LTB project. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7852) problems in memberof overlay
by efbt＠hotmail.com 12 May '14

12 May '14

Full_Name: jeff.gao Version: 2.4.23 OS: centos URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (114.242.123.100) hi. I configured the function of 'memberof overlay' these days, but At first I used the methods on the webpage of http://www.openldap.org/doc/admin24/overlays.html, I add the codes of "overlay memeberof" in the file of slapd.conf,then I started the slapd service, the system give me an error "overlay "memberof" not found" . second,I googled the internet and found an article on this webpage:http://www.redmine.org/projects/redmine/wiki/RedmineLDAP,so I create two LDIF files as follow: the first file : dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulePath: /usr/lib/ldap olcModuleLoad: memberof the second file: dn: olcOverlay=memberof,olcDatabase={1}hdb,cn=config objectClass: olcMemberOf objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top olcOverlay: memberof olcMemberOfDangling: ignore olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf after I entered the command "ldapadd -x -D 'cn=Manager,dc=example,dc=com' -W -f 1.ldif",the system give an error:"ldap_add: Insufficient access (50)" please help me ,thanks.

1 0

Re: (ITS#7851) [PATCH] buffer overrun in password checkers with malformed hash
by ryan＠nardis.ca 11 May '14

11 May '14

Sorry, I missed a line from the patch. Corrected one: ftp://ftp.openldap.org/incoming/rtandy_20140511_fix-passwd-b64-buffer_v2.pa…

1 0

(ITS#7851) [PATCH] buffer overrun in password checkers with malformed hash
by ryan＠nardis.ca 11 May '14

11 May '14

Full_Name: Ryan Tandy Version: master, commit 141f1680 OS: Ubuntu 14.04 URL: ftp://ftp.openldap.org/incoming/rtandy_20140511_fix-passwd-b64-buffer.patch Submission from: (NULL) (24.68.121.206) The password checkers call lutil_b64_pton like this: rc = lutil_b64_pton(passwd->bv_val, orig_pass, passwd->bv_len); However, the size of orig_pass is actually only 3/4 of passwd->bv_len. Normally this isn't a problem; however, if the length of the password hash is not a multiple of 4, then LUTIL_BASE64_DECODE_LEN rounds down, orig_pass gets a shorter buffer allocated than is actually needed, and it's possible for lutil_b64_pton to write past its end. (How can that happen? An admin could mess up copy-pasting from slappasswd to userPassword/olcRootPW, as could a user with write access to their own userPassword who decided to set it manually.) Example: $ slappasswd -s secret -h '{SSHA}' {SSHA}86ks4vJqfruLKer9skuEpTmgPxcaqSLe If we lose the last character ('e') and try to authenticate against the length 31 string, clang's AddressSanitizer notices: ==15335==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x603000049736 at pc 0xef0720 bp 0x7fa9b38d1c10 sp 0x7fa9b38d1c08 WRITE of size 1 at 0x603000049736 thread T2 #0 0xef071f in lutil_b64_pton (libraries/liblutil/base64.c:225) #1 0xe9547c in chk_ssha1 (libraries/liblutil/passwd.c:508) #2 0xe90a09 in lutil_passwd (libraries/liblutil/passwd.c:327) #3 0x7d5e1c in slap_passwd_check (servers/slapd/passwd.c:529) [snip ...] 0x603000049736 is located 0 bytes to the right of 22-byte region [0x603000049720,0x603000049736) allocated by thread T2 here: #0 0x43c9a4 in malloc (/opt/openldap/libexec/slapd+0x43c9a4) #1 0x112903f in ber_memalloc_x (libraries/liblber/memory.c:228) #2 0x1129396 in ber_memalloc (libraries/liblber/memory.c:244) #3 0xe952ea in chk_ssha1 (libraries/liblutil/passwd.c:503) #4 0xe90a09 in lutil_passwd (libraries/liblutil/passwd.c:327) #5 0x7d5e1c in slap_passwd_check (servers/slapd/passwd.c:529) [snip...] (Built with ./configure CC=clang CFLAGS="-O0 -g -fsanitize=address") Patch in URL. (Apparently the apr1 passwd module has CRLF endings; sorry for the noisy diff.) BTW, I noticed in the same routines that orig_pass is allocated with + 1 to the required length, as if it were to be null-terminated, but that's never done. Is that intentional? (AFAICS ber_memalloc doesn't zero memory, maybe I'm wrong.) thanks, Ryan

1 0

Re: (ITS#7850) slapd crashes on modrdn to an attr with no equality matching rule
by ryan＠nardis.ca 09 May '14

09 May '14

On Fri, May 9, 2014 at 11:33 AM, Howard Chu <hyc(a)symas.com> wrote: > Thanks for the report. Should be fixed now in git master, please test. $ ldapmodrdn -x -D cn=root,dc=example,dc=com -W 'cn=Ryan Tandy,dc=example,dc=com' 'jpegPhoto=test' Enter LDAP Password: Rename Result: Naming violation (64) Additional info: naming attribute has no equality matching rule Confirmed fixed.

1 0

Re: (ITS#7850) slapd crashes on modrdn to an attr with no equality matching rule
by hyc＠symas.com 09 May '14

09 May '14

ryan(a)nardis.ca wrote: > Full_Name: Ryan Tandy > Version: HEAD > OS: Ubuntu 14.04 > URL: > Submission from: (NULL) (142.32.208.226) > > > Debian bug report: http://bugs.debian.org/666515 > > Confirmed on master (at commit fcdd3a06) and RE24 (at commit 1253d7c1). Thanks for the report. Should be fixed now in git master, please test. > > ldapadd or slapadd of an entry with a naming attribute such as 'audio' or > 'jpegPhoto' is rejected with a reasonable error message: > > $ slapadd > dn: jpegPhoto=test,dc=example,dc=com > objectClass: inetOrgPerson > > slapadd: dn="jpegPhoto=test,dc=example,dc=com" (line=1): (64) naming attribute > 'jpegPhoto' has no equality matching rule > > However, creating an entry with a valid DN and using ldapmodrdn to request a > change of the naming attr to 'jpegPhoto' crashes slapd: > > $ slapadd > dn: cn=Ryan Tandy,dc=example,dc=com > objectClass: inetOrgPerson > sn: Tandy > jpegPhoto: test > > $ [start slapd...] > $ ldapmodrdn -x -D cn=root,dc=example,dc=com -W 'cn=Ryan > Tandy,dc=example,dc=com' 'jpegPhoto=test' > Enter LDAP Password: > ldap_result: Can't contact LDAP server (-1) > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7ffd81a60700 (LWP 9095)] > 0x00000000004667f3 in slap_modrdn2mods (op=0x7ffd740026b0, rs=0x7ffd81a5faf0) at > modrdn.c:448 > 448 if( desc->ad_type->sat_equality->smr_normalize) { > (gdb) bt full > #0 0x00000000004667f3 in slap_modrdn2mods (op=0x7ffd740026b0, > rs=0x7ffd81a5faf0) at modrdn.c:448 > desc = 0x9add80 > mod_tmp = 0x7ffd74002670 > a_cnt = 0 > d_cnt = 32765 > old_rdn = 0x0 > new_rdn = 0x7ffd74003090 > __PRETTY_FUNCTION__ = "slap_modrdn2mods" > #1 0x0000000000465688 in do_modrdn (op=0x7ffd740026b0, rs=0x7ffd81a5faf0) at > modrdn.c:179 > dn = {bv_len = 31, bv_val = 0x7ffd74102c77 "cn=Ryan > Tandy,dc=example,dc=com"} > newrdn = {bv_len = 14, bv_val = 0x7ffd74102c98 "jpegPhoto=test"} > newSuperior = {bv_len = 0, bv_val = 0x0} > deloldrdn = 0 > pnewSuperior = {bv_len = 0, bv_val = 0x0} > nnewSuperior = {bv_len = 0, bv_val = 0x0} > length = 0 > #2 0x000000000044029f in connection_operation (ctx=0x7ffd81a5fc40, > arg_v=0x7ffd740026b0) at connection.c:1134 > rc = 80 > cancel = 0 > op = 0x7ffd740026b0 > rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, > sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, > sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = > 0, r_operational_attrs = 0x0, r_attrs = 0x0, > r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, > sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, > sr_flags = 0} > tag = 108 > opidx = SLAP_OP_MODRDN > conn = 0x7ffff7e6ae90 > memctx = 0x7ffd74002bf0 > memctx_null = 0x0 > memsiz = 1048576 > __PRETTY_FUNCTION__ = "connection_operation" > #3 0x00000000004408f8 in connection_read_thread (ctx=0x7ffd81a5fc40, argv=0x10) > at connection.c:1270 > rc = 0 > cri = {op = 0x7ffd740026b0, func = 0x0, arg = 0x0, ctx = 0x7ffd81a5fc40, > nullop = 0} > s = 16 > #4 0x00007ffff7b89e5e in ldap_int_thread_pool_wrapper (xpool=0x7fa480) at > tpool.c:945 > pq = 0x7fa480 > pool = 0x7fa370 > task = 0x7ffd7c0008c0 > work_list = 0x7fa4f0 > ctx = {ltu_pq = 0x7fa480, ltu_id = 140726778595072, ltu_key = {{ltk_key > = 0x43fd34 <conn_counter_init>, > ltk_data = 0x7ffd74002ae0, ltk_free = 0x43fb86 > <conn_counter_destroy>}, {ltk_key = 0x4b9a08 <slap_sl_mem_init>, > ltk_data = 0x7ffd74002bf0, ltk_free = 0x4b982d > <slap_sl_mem_destroy>}, {ltk_key = 0x45c06b <slap_op_free>, > ltk_data = 0x0, ltk_free = 0x45bfbe <slap_op_q_destroy>}, {ltk_key > = 0x0, ltk_data = 0x0, > ltk_free = 0x0} <repeats 23 times>, {ltk_key = 0x0, ltk_data = > 0xe81b289de6cb1252, ltk_free = 0x80}, {ltk_key = 0x0, > ltk_data = 0x0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, > ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, > ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}, > {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}}} > kctx = 0x0 > i = 32 > keyslot = 586 > hash = 2858034762 > pool_lock = 0 > freeme = 0 > __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" > #5 0x00007ffff5dbf062 in start_thread (arg=0x7ffd81a60700) at > pthread_create.c:312 > __res = <optimized out> > pd = 0x7ffd81a60700 > now = <optimized out> > unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140726778595072, > 1720423256181903954, 1, 140737354125408, 0, 140726778595072, > -1721737773892038062, -1720445005621816750}, mask_was_saved = > 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = { > prev = 0x0, cleanup = 0x0, canceltype = 0}}} > not_first_call = <optimized out> > pagesize_m1 = <optimized out> > sp = <optimized out> > freesize = <optimized out> > __PRETTY_FUNCTION__ = "start_thread" > #6 0x00007ffff5af2bfd in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 > No locals. > > The problem is a dereference of the missing equality rule: > > (gdb) p desc->ad_type > $1 = (AttributeType *) 0x83ec70 > (gdb) p desc->ad_type->sat_equality > $2 = (MatchingRule *) 0x0 > > -- -- 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#6890) SHA2 Password Hashing not working
by ryan＠nardis.ca 09 May '14

09 May '14

Hi, This is fixed by ITS#7284, included since 2.4.32. slappasswd -o module-load=pw-sha2 -h '{SHA512}' thanks, Ryan

1 0

Re: (ITS#6939) slapd double free corruption with olcTlsCipherSuite and GnuTLS
by quanah＠zimbra.com 08 May '14

08 May '14

Thanks, marked duplicate and closed. --Quanah --On May 8, 2014 at 9:42:07 PM +0000 ryan(a)nardis.ca wrote: > I think this might be a duplicate of ITS#7500. > > -- Quanah Gibson-Mount Server Architect Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6939) slapd double free corruption with olcTlsCipherSuite and GnuTLS
by ryan＠nardis.ca 08 May '14

08 May '14

I think this might be a duplicate of ITS#7500.

1 0

(ITS#7850) slapd crashes on modrdn to an attr with no equality matching rule
by ryan＠nardis.ca 08 May '14

08 May '14

Full_Name: Ryan Tandy Version: HEAD OS: Ubuntu 14.04 URL: Submission from: (NULL) (142.32.208.226) Debian bug report: http://bugs.debian.org/666515 Confirmed on master (at commit fcdd3a06) and RE24 (at commit 1253d7c1). ldapadd or slapadd of an entry with a naming attribute such as 'audio' or 'jpegPhoto' is rejected with a reasonable error message: $ slapadd dn: jpegPhoto=test,dc=example,dc=com objectClass: inetOrgPerson slapadd: dn="jpegPhoto=test,dc=example,dc=com" (line=1): (64) naming attribute 'jpegPhoto' has no equality matching rule However, creating an entry with a valid DN and using ldapmodrdn to request a change of the naming attr to 'jpegPhoto' crashes slapd: $ slapadd dn: cn=Ryan Tandy,dc=example,dc=com objectClass: inetOrgPerson sn: Tandy jpegPhoto: test $ [start slapd...] $ ldapmodrdn -x -D cn=root,dc=example,dc=com -W 'cn=Ryan Tandy,dc=example,dc=com' 'jpegPhoto=test' Enter LDAP Password: ldap_result: Can't contact LDAP server (-1) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7ffd81a60700 (LWP 9095)] 0x00000000004667f3 in slap_modrdn2mods (op=0x7ffd740026b0, rs=0x7ffd81a5faf0) at modrdn.c:448 448 if( desc->ad_type->sat_equality->smr_normalize) { (gdb) bt full #0 0x00000000004667f3 in slap_modrdn2mods (op=0x7ffd740026b0, rs=0x7ffd81a5faf0) at modrdn.c:448 desc = 0x9add80 mod_tmp = 0x7ffd74002670 a_cnt = 0 d_cnt = 32765 old_rdn = 0x0 new_rdn = 0x7ffd74003090 __PRETTY_FUNCTION__ = "slap_modrdn2mods" #1 0x0000000000465688 in do_modrdn (op=0x7ffd740026b0, rs=0x7ffd81a5faf0) at modrdn.c:179 dn = {bv_len = 31, bv_val = 0x7ffd74102c77 "cn=Ryan Tandy,dc=example,dc=com"} newrdn = {bv_len = 14, bv_val = 0x7ffd74102c98 "jpegPhoto=test"} newSuperior = {bv_len = 0, bv_val = 0x0} deloldrdn = 0 pnewSuperior = {bv_len = 0, bv_val = 0x0} nnewSuperior = {bv_len = 0, bv_val = 0x0} length = 0 #2 0x000000000044029f in connection_operation (ctx=0x7ffd81a5fc40, arg_v=0x7ffd740026b0) at connection.c:1134 rc = 80 cancel = 0 op = 0x7ffd740026b0 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 108 opidx = SLAP_OP_MODRDN conn = 0x7ffff7e6ae90 memctx = 0x7ffd74002bf0 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #3 0x00000000004408f8 in connection_read_thread (ctx=0x7ffd81a5fc40, argv=0x10) at connection.c:1270 rc = 0 cri = {op = 0x7ffd740026b0, func = 0x0, arg = 0x0, ctx = 0x7ffd81a5fc40, nullop = 0} s = 16 #4 0x00007ffff7b89e5e in ldap_int_thread_pool_wrapper (xpool=0x7fa480) at tpool.c:945 pq = 0x7fa480 pool = 0x7fa370 task = 0x7ffd7c0008c0 work_list = 0x7fa4f0 ctx = {ltu_pq = 0x7fa480, ltu_id = 140726778595072, ltu_key = {{ltk_key = 0x43fd34 <conn_counter_init>, ltk_data = 0x7ffd74002ae0, ltk_free = 0x43fb86 <conn_counter_destroy>}, {ltk_key = 0x4b9a08 <slap_sl_mem_init>, ltk_data = 0x7ffd74002bf0, ltk_free = 0x4b982d <slap_sl_mem_destroy>}, {ltk_key = 0x45c06b <slap_op_free>, ltk_data = 0x0, ltk_free = 0x45bfbe <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 23 times>, {ltk_key = 0x0, ltk_data = 0xe81b289de6cb1252, ltk_free = 0x80}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0}}} kctx = 0x0 i = 32 keyslot = 586 hash = 2858034762 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #5 0x00007ffff5dbf062 in start_thread (arg=0x7ffd81a60700) at pthread_create.c:312 __res = <optimized out> pd = 0x7ffd81a60700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140726778595072, 1720423256181903954, 1, 140737354125408, 0, 140726778595072, -1721737773892038062, -1720445005621816750}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = { prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = <optimized out> pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #6 0x00007ffff5af2bfd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 No locals. The problem is a dereference of the missing equality rule: (gdb) p desc->ad_type $1 = (AttributeType *) 0x83ec70 (gdb) p desc->ad_type->sat_equality $2 = (MatchingRule *) 0x0

1 0

Re: (ITS#7845) slapd debug in the background
by quanah＠zimbra.com 07 May '14

07 May '14

--On April 29, 2014 at 2:21:18 AM +0000 wingcheungma(a)gmail.com wrote: > Full_Name: Wing Cheung Ma > Version: 2.4.23 > OS: Rhel5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (54.240.196.185) This ITS system is for reporting bugs, not asking usage questions. Please direct usage questions to the openldap-technical(a)openldap.org list. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7849) MMR can lose track of its serverID, go into loop
by quanah＠OpenLDAP.org 07 May '14

07 May '14

Full_Name: Quanah Gibson-Mount Version: 2.4.39 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (107.207.38.73) 2 reports now of MMR (delta-syncrepl specifically at this point) going into endless loops replicating changes. In both cases, it appears that all the servers lose track of their serverIDs (reverting to 000), which causes the change(s) to never get dropped, causing all servers to go into endless loops, eating up CPU and causing massive growth of the accesslog DB.

1 0

Re: (ITS#7848) openldap n-way multi-master replication
by quanah＠zimbra.com 05 May '14

05 May '14

--On Tuesday, May 06, 2014 2:47 AM +0000 idpbg-it-dba(a)mail.foxconn.com wrote: > Full_Name: Robert.YQ.Feng > Version: 2.4.23-31 Stop wasting your time using RHEL's utterly broken packages. Please do not file bug reports on builds that are years out of date. Please do use a current, sanely built and linked package of OpenLDAP, such as the builds from Symas or the LTB project. Thanks. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7848) openldap n-way multi-master replication
by idpbg-it-dba＠mail.foxconn.com 05 May '14

05 May '14

Full_Name: Robert.YQ.Feng Version: 2.4.23-31 OS: redhat linux 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (218.29.136.228) Hello: my issuse is under bellow: 1. My ldapserver01's cn=config file is enable to replicat with ldapserver02 but the entries(just like users ,ou etc.) in olcDatabase={2}bdb is not. 2. When i delete a user in ldapserver01 ,the same entry in ldapserver02 was delted too. 3. when i add a new user to ldapserver01 ,the entries in ldapserver02 change to old(primitive) data 4. when i add a new user to ldapserver02 ,the entries in ldapserver01 change to old(primitive) data,the new entry in ldapserver01 just add no longer is disappear!! Ldapserv01 1. slapd port 389 [root@ldapserver01 ~]# netstat -anulpt |grep slapd tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 21555/slapd tcp 0 0 10.195.157.170:389 10.195.143.28:54866 ESTABLISHED 21555/slapd tcp 0 0 10.195.157.170:35366 10.195.157.170:389 ESTABLISHED 21555/slapd tcp 0 0 10.195.157.170:389 10.195.157.170:35366 ESTABLISHED 21555/slapd tcp 0 0 10.195.157.170:57629 10.195.143.28:389 ESTABLISHED 21555/slapd tcp 0 0 :::389 :::* LISTEN 21555/slapd 2. openldap version 2.4.23 [root@ldapserver01 ~]# rpm -qa openldap* openldap-clients-2.4.23-31.el6.x86_64 openldap-devel-2.4.23-31.el6.x86_64 openldap-servers-2.4.23-31.el6.x86_64 openldap-2.4.23-31.el6.x86_64 3. serverhostname [root@ldapserver01 ~]# hostname ldapserver01 4. host content [root@ldapserver01 ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 10.195.157.170 ldapserver01 ldapserver01.ldap.idpbg.com 10.195.143.28 ldapserver02 ldapserver02.ldap.idpbg.com 5. os version [root@ldapserver01 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.4 (Santiago) Ldapserver02 [root@ldapserver02 ~]# netstat -anulpt |grep slapd tcp 0 0 0.0.0.0:389 0.0.0.0:* LISTEN 1625/slapd tcp 0 0 10.195.143.28:389 10.195.157.170:57629 ESTABLISHED 1625/slapd tcp 0 0 10.195.143.28:54866 10.195.157.170:389 ESTABLISHED 1625/slapd tcp 0 0 10.195.143.28:51667 10.195.143.28:389 ESTABLISHED 1625/slapd tcp 0 0 10.195.143.28:389 10.195.143.28:51667 ESTABLISHED 1625/slapd tcp 0 0 :::389 :::* LISTEN 1625/slapd [root@ldapserver02 ~]# rpm -qa openldap* openldap-2.4.23-31.el6.x86_64 openldap-clients-2.4.23-31.el6.x86_64 openldap-servers-2.4.23-31.el6.x86_64 openldap-devel-2.4.23-31.el6.x86_64 [root@ldapserver02 ~]# hostname ldapserver02 [root@ldapserver02 ~]# cat /etc/hosts 127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4 ::1 localhost localhost.localdomain localhost6 localhost6.localdomain6 10.195.143.28 ldapserver02 ldapserver02.ldap.idpbg.com 10.195.157.170 ldapserver01 ldapserver01.ldap.idpbg.com [root@ldapserver02 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 6.4 (Santiago) ldapserver02's cn=config configuration file -------------------------------------------------------------------------------------------------------------------------- [root@ldapserver02 ~]# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config "(|(cn=config)(olcDatabase={0}config))" dn: cn=config objectClass: olcGlobal cn: config olcConfigFile: /etc/openldap/slapd.conf olcConfigDir: /etc/openldap/slapd.d olcAllows: bind_v2 olcArgsFile: /var/run/openldap/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConcurrency: 0 olcConnMaxPending: 100 olcConnMaxPendingAuth: 1000 olcGentleHUP: FALSE olcIdleTimeout: 0 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexIntLen: 4 olcLocalSSF: 71 olcPidFile: /var/run/openldap/slapd.pid olcReadOnly: FALSE olcReverseLookup: FALSE olcSaslSecProps: noplain,noanonymous olcServerID: 1 ldap://ldapserver01.ldap.idpbg.com olcServerID: 2 ldap://ldapserver02.ldap.idpbg.com olcSockbufMaxIncoming: 262143 olcSockbufMaxIncomingAuth: 16777215 olcThreads: 16 olcTLSCACertificatePath: /etc/openldap/certs olcTLSCertificateFile: "OpenLDAP Server" olcTLSCertificateKeyFile: /etc/openldap/certs/password olcTLSVerifyClient: never olcToolThreads: 1 olcWriteTimeout: 0 dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=externa l,cn=auth" manage by * break olcAddContentAcl: TRUE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=admin,cn=config olcRootPW: {SSHA}hI5Dhjq/poZ0Wvu5B7ovYKPiNWAIMqR+ olcSyncUseSubentry: FALSE olcSyncrepl: {0}rid=001 provider=ldap://ldapserver01.ldap.idpbg.com binddn="cn =admin,cn=config" bindmethod=simple credentials=ldap searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncrepl: {1}rid=002 provider=ldap://ldapserver02.ldap.idpbg.com binddn="cn =admin,cn=config" bindmethod=simple credentials=ldap searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1 olcMirrorMode: TRUE olcMonitoring: FALSE ldapserver02's olcDatabase configuration ---------------------------------------------------------------------------------------------- [root@ldapserver02 ~]# ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config "(| (olcDatabase={2}bdb)(olcOverlay=syncprov))" dn: olcOverlay={0}syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov dn: olcDatabase={2}bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: {2}bdb olcDbDirectory: /var/lib/ldap olcSuffix: dc=ldap,dc=idpbg,dc=com olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 15 olcReadOnly: FALSE olcRootDN: cn=Manager,dc=ldap,dc=idpbg,dc=com olcRootPW: {SSHA}hI5Dhjq/poZ0Wvu5B7ovYKPiNWAIMqR+ olcSyncUseSubentry: FALSE olcSyncrepl: {0}rid=004 provider=ldap://ldapserver01.ldap.idpbg.com binddn=" cn=Manager,dc=ldap,dc=idpbg,dc=com" bindmethod=simple credentials=ldap sear chbase="dc=ldap,dc=idpbg,dc=com" type=refreshOnly interval=00:00:00:10 r etry="5 5 300 5" timeout=1 olcSyncrepl: {1}rid=005 provider=ldap://ldapserver02.ldap.idpbg.com binddn=" cn=Manager,dc=ldap,dc=idpbg,dc=com" bindmethod=simple credentials=ldap sear chbase="dc=ldap,dc=idpbg,dc=com" type=refreshOnly interval=00:00:00:10 r etry="5 5 300 5" timeout=1 olcMirrorMode: TRUE olcMonitoring: TRUE olcDbCacheSize: 1000 olcDbCheckpoint: 1024 15 olcDbConfig: {0}# $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.3.2.4 2007/1 2/18 11:53:27 ghenry Exp $ olcDbConfig: {1}# Example DB_CONFIG file for use with slapd(8) BDB/HDB databas es. olcDbConfig: {2}# olcDbConfig: {3}# See the Oracle Berkeley DB documentation olcDbConfig: {4}# <http://www.oracle.com/technology/documentation/berkeley-d b/db/ref/env/db_config.html> olcDbConfig: {5}# for detail description of DB_CONFIG syntax and semantics. olcDbConfig: {6}# olcDbConfig: {7}# Hints can also be found in the OpenLDAP Software FAQ olcDbConfig:: ezh9Iwk8aHR0cDovL3d3dy5vcGVubGRhcC5vcmcvZmFxL2luZGV4LmNnaT9maWxl PTI+ olcDbConfig: {9}# in particular: olcDbConfig: {10}# <http://www.openldap.org/faq/index.cgi?file=1075> olcDbConfig: {11} olcDbConfig: {12}# Note: most DB_CONFIG settings will take effect only upon re building olcDbConfig: {13}# the DB environment. olcDbConfig: {14} olcDbConfig: {15}# one 0.25 GB cache olcDbConfig: {16}set_cachesize 0 268435456 1 olcDbConfig: {17} olcDbConfig: {18}# Data Directory olcDbConfig: {19}#set_data_dir db olcDbConfig: {20} olcDbConfig: {21}# Transaction Log settings olcDbConfig: {22}set_lg_regionmax 262144 olcDbConfig: {23}set_lg_bsize 2097152 olcDbConfig: {24}#set_lg_dir logs olcDbConfig: {25} olcDbConfig: {26}# Note: special DB_CONFIG flags are no longer needed for "qui ck" olcDbConfig:: ezI3fSMgc2xhcGFkZCg4KSBvciBzbGFwaW5kZXgoOCkgYWNjZXNzIChzZWUgdGhl aXIgLXEgb3B0aW9uKS4g olcDbNoSync: FALSE olcDbDirtyRead: FALSE olcDbIDLcacheSize: 0 olcDbIndex: objectClass pres,eq olcDbIndex: cn pres,eq,sub olcDbIndex: uid pres,eq,sub olcDbIndex: uidNumber pres,eq olcDbIndex: gidNumber pres,eq olcDbIndex: memberUid pres,eq,sub olcDbIndex: mail pres,eq,sub olcDbIndex: sn pres,eq,sub olcDbIndex: givenName pres,eq,sub olcDbIndex: loginShell pres,eq olcDbIndex: ou pres,eq,sub olcDbIndex: nisMapName pres,eq,sub olcDbIndex: nisMapEntry pres,eq,sub olcDbIndex: sambaSID pres,eq olcDbIndex: sambaSIDList pres,eq olcDbIndex: sambaGroupType pres,eq olcDbLinearIndex: FALSE olcDbMode: 0600 olcDbSearchStack: 16 olcDbShmKey: 0 olcDbCacheFree: 1 olcDbDNcacheSize: 0 dn: olcOverlay={0}syncprov,olcDatabase={2}bdb,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: {0}syncprov ------------------------------------------------------------------------------------------------- [root@ldapserver02 ~]# ll /var/lib/ldap/ total 11780 -rw-r--r--. 1 ldap ldap 4096 May 5 17:48 alock -rw-------. 1 ldap ldap 8192 May 6 09:05 cn.bdb -rw-------. 1 ldap ldap 24576 May 5 17:48 __db.001 -rw-------. 1 ldap ldap 9093120 May 6 09:05 __db.002 -rw-------. 1 ldap ldap 335552512 May 6 09:05 __db.003 -rw-------. 1 ldap ldap 2359296 May 6 09:05 __db.004 -rw-------. 1 ldap ldap 753664 May 6 09:05 __db.005 -rw-------. 1 ldap ldap 32768 May 6 09:05 __db.006 -rw-r--r--. 1 root root 921 Apr 22 16:03 DB_CONFIG -rw-------. 1 ldap ldap 8192 May 6 09:05 dn2id.bdb -rw-------. 1 ldap ldap 8192 May 6 09:05 gidNumber.bdb -rw-------. 1 ldap ldap 32768 May 6 09:05 id2entry.bdb -rw-------. 1 ldap ldap 10485760 May 6 09:05 log.0000000001 -rw-------. 1 ldap ldap 8192 May 6 09:05 loginShell.bdb -rw-------. 1 ldap ldap 8192 May 6 09:05 objectClass.bdb -rw-------. 1 ldap ldap 8192 May 5 14:20 ou.bdb -rw-------. 1 ldap ldap 8192 May 6 09:05 uid.bdb -rw-------. 1 ldap ldap 8192 May 6 09:05 uidNumber.bdb [root@ldapserver01 userinfo]# ll /var/lib/ldap/ total 11996 -rw-r--r--. 1 ldap ldap 2048 May 5 16:59 alock -rw-------. 1 ldap ldap 8192 May 5 17:14 cn.bdb -rw-------. 1 ldap ldap 24576 May 5 16:59 __db.001 -rw-------. 1 ldap ldap 9093120 May 6 09:14 __db.002 -rw-------. 1 ldap ldap 335552512 May 6 09:05 __db.003 -rw-------. 1 ldap ldap 2359296 May 6 09:05 __db.004 -rw-------. 1 ldap ldap 753664 May 6 09:05 __db.005 -rw-------. 1 ldap ldap 32768 May 6 09:05 __db.006 -rw-r--r--. 1 ldap ldap 921 Apr 22 16:06 DB_CONFIG -rw-------. 1 ldap ldap 8192 May 6 09:05 dn2id.bdb -rw-------. 1 ldap ldap 8192 May 5 17:14 gidNumber.bdb -rw-------. 1 ldap ldap 32768 May 6 09:05 id2entry.bdb -rw-------. 1 ldap ldap 10485760 May 6 09:05 log.0000000001 -rw-------. 1 ldap ldap 8192 May 5 17:14 loginShell.bdb -rw-------. 1 ldap ldap 8192 May 6 09:05 objectClass.bdb -rw-------. 1 ldap ldap 8192 May 6 09:05 ou.bdb -rw-------. 1 ldap ldap 8192 May 5 17:14 uid.bdb -rw-------. 1 ldap ldap 8192 May 5 17:14 uidNumber.bdb ldapserver02 slapd.conf file content --------------------------------------------------------------------------------------------- [root@ldapserver02 ~]# cat /etc/openldap/slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/corba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema ##add a line underline include /etc/openldap/schema/samba.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # Load dynamic backend modules # - modulepath is architecture dependent value (32/64-bit system) # - back_sql.la overlay requires openldap-server-sql package # - dyngroup.la and dynlist.la cannot be used at the same time # modulepath /usr/lib/openldap # modulepath /usr/lib64/openldap # moduleload accesslog.la # moduleload auditlog.la # moduleload back_sql.la # moduleload chain.la # moduleload collect.la # moduleload constraint.la # moduleload dds.la # moduleload deref.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload memberof.la # moduleload pbind.la # moduleload pcache.la # moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # moduleload rwm.la # moduleload seqmod.la # moduleload smbk5pwd.la # moduleload sssvlv.la moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by running # /usr/libexec/openldap/generate-server-cert.sh. Your client software may balk # at self-signed certificates, however. TLSCACertificatePath /etc/openldap/certs TLSCertificateFile "\"OpenLDAP Server\"" TLSCertificateKeyFile /etc/openldap/certs/password # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! # enable on-the-fly configuration (cn=config) database config rootdn "cn=admin,cn=config" rootpw {SSHA}hI5Dhjq/poZ0Wvu5B7ovYKPiNWAIMqR+ access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * break # enable server status monitoring (cn=monitor) database monitor access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.exact="cn=Manager,dc=ldap,dc=idpbg,dc=com" read by * none ####################################################################### # database definitions ####################################################################### database bdb suffix "dc=ldap,dc=idpbg,dc=com" checkpoint 1024 15 rootdn "cn=Manager,dc=ldap,dc=idpbg,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # rootpw secret # rootpw {crypt}ijFYNcSNctBYg rootpw {SSHA}hI5Dhjq/poZ0Wvu5B7ovYKPiNWAIMqR+ # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub ###add a line under index sambaSID,sambaSIDList,sambaGroupType eq,pres # Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM -------------------------------------------------------------------------------- ldapserver01 slapd.conf file content ----------------------------------------------------------------------------- [root@ldapserver01 userinfo]# cat /etc/openldap/slapd.conf # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/corba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema ##add a line underline include /etc/openldap/schema/samba.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldap.org pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # Load dynamic backend modules # - modulepath is architecture dependent value (32/64-bit system) # - back_sql.la overlay requires openldap-server-sql package # - dyngroup.la and dynlist.la cannot be used at the same time # modulepath /usr/lib/openldap # modulepath /usr/lib64/openldap # moduleload accesslog.la # moduleload auditlog.la # moduleload back_sql.la # moduleload chain.la # moduleload collect.la # moduleload constraint.la # moduleload dds.la # moduleload deref.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload memberof.la # moduleload pbind.la # moduleload pcache.la # moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la # moduleload rwm.la # moduleload seqmod.la # moduleload smbk5pwd.la # moduleload sssvlv.la moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by running # /usr/libexec/openldap/generate-server-cert.sh. Your client software may balk # at self-signed certificates, however. TLSCACertificatePath /etc/openldap/certs TLSCertificateFile "\"OpenLDAP Server\"" TLSCertificateKeyFile /etc/openldap/certs/password # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! # enable on-the-fly configuration (cn=config) database config rootdn "cn=admin,cn=config" rootpw {SSHA}hI5Dhjq/poZ0Wvu5B7ovYKPiNWAIMqR+ access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * break # enable server status monitoring (cn=monitor) database monitor access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.exact="cn=Manager,dc=ldap,dc=idpbg,dc=com" read by * none ####################################################################### # database definitions ####################################################################### database bdb suffix "dc=ldap,dc=idpbg,dc=com" checkpoint 1024 15 rootdn "cn=Manager,dc=ldap,dc=idpbg,dc=com" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # rootpw secret # rootpw {crypt}ijFYNcSNctBYg rootpw {SSHA}hI5Dhjq/poZ0Wvu5B7ovYKPiNWAIMqR+ # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub ###add a line under index sambaSID,sambaSIDList,sambaGroupType eq,pres # Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM

1 0

Re: (ITS#7847) syncrepl attrs should allow to explicitly exclude attributes
by quanah＠zimbra.com 05 May '14

05 May '14

--On Monday, May 05, 2014 5:49 PM +0000 quanah(a)zimbra.com wrote: > --On Sunday, May 04, 2014 5:57 PM +0000 hyc(a)symas.com wrote: > >> Michael Str?der wrote: >>> hyc(a)symas.com wrote: >>>> Use "exattrs" to exclude specific attrs. This has been supported since >>>> 2004, ITS#3289 >>> >>> Sorry, missed that. It seems not to be documented in RE24 yet. >>> >>> Ciao, Michael. >>> >> Feel free to submit a doc patch, thanks. > > I see it documented: > > quanah@zre-ldap001:~/src/openldap/openldap-2-4/doc/man/man5$ grep exattrs > * slapd-config.5:.B [exattrs=<attr list>] > slapd-config.5:.B exattrs > slapd-config.5:attributes, and \fBattrsonly\fP and \fBexattrs\fP are > unset by default. > slapo-dds.5: exattrs=entryTtl,entryExpireTimestamp > quanah@zre-ldap001:~/src/openldap/openldap-2-4/doc/man/man5$ It was missing from slapd.conf(5) however. This is now fixed. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7847) syncrepl attrs should allow to explicitly exclude attributes
by quanah＠zimbra.com 05 May '14

05 May '14

--On Sunday, May 04, 2014 5:57 PM +0000 hyc(a)symas.com wrote: > Michael Str?der wrote: >> hyc(a)symas.com wrote: >>> Use "exattrs" to exclude specific attrs. This has been supported since >>> 2004, ITS#3289 >> >> Sorry, missed that. It seems not to be documented in RE24 yet. >> >> Ciao, Michael. >> > Feel free to submit a doc patch, thanks. I see it documented: quanah@zre-ldap001:~/src/openldap/openldap-2-4/doc/man/man5$ grep exattrs * slapd-config.5:.B [exattrs=<attr list>] slapd-config.5:.B exattrs slapd-config.5:attributes, and \fBattrsonly\fP and \fBexattrs\fP are unset by default. slapo-dds.5: exattrs=entryTtl,entryExpireTimestamp quanah@zre-ldap001:~/src/openldap/openldap-2-4/doc/man/man5$ --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7847) syncrepl attrs should allow to explicitly exclude attributes
by hyc＠symas.com 04 May '14

04 May '14

Michael Ströder wrote: > hyc(a)symas.com wrote: >> Use "exattrs" to exclude specific attrs. This has been supported since 2004, >> ITS#3289 > > Sorry, missed that. It seems not to be documented in RE24 yet. > > Ciao, Michael. > Feel free to submit a doc patch, thanks. -- -- 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#7847) syncrepl attrs should allow to explicitly exclude attributes
by michael＠stroeder.com 03 May '14

03 May '14

hyc(a)symas.com wrote: > Use "exattrs" to exclude specific attrs. This has been supported since 2004, > ITS#3289 Sorry, missed that. It seems not to be documented in RE24 yet. Ciao, Michael.

1 0

Re: (ITS#7847) syncrepl attrs should allow to explicitly exclude attributes
by hyc＠symas.com 03 May '14

03 May '14

michael(a)stroeder.com wrote: > Full_Name: > Version: > OS: > URL: > Submission from: (NULL) (79.227.159.237) > > > In some cases it would be handy to explicitly exclude attributes from getting > replicated with parameter 'attrs' in the syncrepl statements. > > Example for working around slapo-accesslog's operational attributes getting > replicated: Use "exattrs" to exclude specific attrs. This has been supported since 2004, ITS#3289 > syncrepl > [..] > attrs="*,+,!allowedAttributes,!allowedAttributesEffective,!allowedChildClasses,!allowedChildClassesEffective" > [..] > > -- -- 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#7847) syncrepl attrs should allow to explicitly exclude attributes
by michael＠stroeder.com 03 May '14

03 May '14

Full_Name: Version: OS: URL: Submission from: (NULL) (79.227.159.237) In some cases it would be handy to explicitly exclude attributes from getting replicated with parameter 'attrs' in the syncrepl statements. Example for working around slapo-accesslog's operational attributes getting replicated: syncrepl [..] attrs="*,+,!allowedAttributes,!allowedAttributesEffective,!allowedChildClasses,!allowedChildClassesEffective" [..]

1 0

Re: (ITS#7846) LMDB failing on ARM9/linux-3.3.0
by ravas＠tind.sk 02 May '14

02 May '14

Please close this bug, it was caused by uclibc's invalid pread / pwrite emulation. Sorry for invalid bugreport.

1 0

(ITS#7846) LMDB failing on ARM9/linux-3.3.0
by ravas＠tind.sk 02 May '14

02 May '14

Full_Name: Stanislav Ravas Version: 49ae28a2eec73bdf8e5811a1880ea6229ad10b38 OS: buildroot, gcc-4.7.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (193.87.79.243) LMDB mtest fails when running on ARM platform (kernel v3.3.0, gcc-4.7.3 with uclibc-0.9.33.2, ARM926ejs CPU). mtest output: Adding 348 values 58 duplicates skipped Deleted 0 values Cursor next Cursor last mtest.c:111: mdb_cursor_get(cursor, &key, &data, MDB_LAST): MDB_NOTFOUND: No matching key/data pair found Aborted I've discovered this bug when debugging my application. mdb_cursor_put() was returning MDB_NOTFOUND, I think it came from mdb_page_search(). So I ran mtest to rule out my application as the cause. So far I can provide mtest strace log: execve("./lmdb6-mtest", ["./lmdb6-mtest"], [/* 22 vars */]) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_UNINITIALIZED, -1, 0) = 0xb6ffa000 stat("/etc/ld.so.cache", {st_mode=S_IFREG|0644, st_size=8680, ...}) = 0 open("/etc/ld.so.cache", O_RDONLY|O_CLOEXEC) = 3 mmap2(NULL, 8680, PROT_READ, MAP_SHARED, 3, 0) = 0xb6ff7000 close(3) = 0 open("/lib/libpthread.so.0", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0755, st_size=95305, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_UNINITIALIZED, -1, 0) = 0xb6ff6000 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\260C\0\0004\0\0\0"..., 4096) = 4096 mmap2(NULL, 114688, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6fd1000 mmap2(0xb6fd1000, 67452, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6fd1000 mmap2(0xb6fe9000, 4124, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x10000) = 0xb6fe9000 mmap2(0xb6feb000, 4328, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6feb000 close(3) = 0 munmap(0xb6ff6000, 4096) = 0 open("/lib/libc.so.0", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0755, st_size=358156, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_UNINITIALIZED, -1, 0) = 0xb6ff6000 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\360\253\0\0004\0\0\0"..., 4096) = 4096 mmap2(NULL, 413696, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f6c000 mmap2(0xb6f6c000, 354188, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6f6c000 mmap2(0xb6fca000, 4852, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x56000) = 0xb6fca000 mmap2(0xb6fcc000, 17520, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0xb6fcc000 close(3) = 0 munmap(0xb6ff6000, 4096) = 0 stat("/lib/ld-uClibc.so.0", {st_mode=S_IFREG|0755, st_size=29392, ...}) = 0 open("/lib/libdl.so.0", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0755, st_size=13216, ...}) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_UNINITIALIZED, -1, 0) = 0xb6ff6000 read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0(\0\1\0\0\0\200\v\0\0004\0\0\0"..., 4096) = 4096 mmap2(NULL, 49152, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xb6f60000 mmap2(0xb6f60000, 8660, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_FIXED, 3, 0) = 0xb6f60000 mmap2(0xb6f6a000, 4120, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3, 0x2000) = 0xb6f6a000 close(3) = 0 munmap(0xb6ff6000, 4096) = 0 open("/lib/libc.so.0", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0755, st_size=358156, ...}) = 0 close(3) = 0 open("/lib/libc.so.0", O_RDONLY) = 3 fstat(3, {st_mode=S_IFREG|0755, st_size=358156, ...}) = 0 close(3) = 0 munmap(0xb6ff7000, 8680) = 0 mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_UNINITIALIZED, -1, 0) = 0xb6ff9000 set_tls(0xb6ff9480, 0xb6ff9b20, 0xb6ff9b28, 0xb6ff9480, 0xb6ffbf74) = 0 mprotect(0xb6fe9000, 4096, PROT_READ) = 0 mprotect(0xb6fca000, 4096, PROT_READ) = 0 mprotect(0xb6ffb000, 4096, PROT_READ) = 0 mprotect(0xb6f6a000, 4096, PROT_READ) = 0 set_tid_address(0xb6ff9068) = 1748 set_robust_list(0xb6ff9070, 12) = 0 rt_sigaction(SIGRTMIN, {0xb6fda708, [], SA_SIGINFO|0x4000000}, NULL, 8) = 0 rt_sigaction(SIGRT_1, {0xb6fda5ac, [], SA_RESTART|SA_SIGINFO|0x4000000}, NULL, 8) = 0 rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=18014398505295872*1024, rlim_max=1152921524856792492}) = 0 ioctl(0, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 ioctl(1, SNDCTL_TMR_TIMEBASE or SNDRV_TIMER_IOCTL_NEXT_DEVICE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 gettimeofday({1399032254, 599658}, NULL) = 0 brk(0) = 0x355000 brk(0x356000) = 0x356000 mmap2(NULL, 528384, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0xb6edf000 mmap2(NULL, 1052672, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, 0, 0) = 0xb6dde000 open("./testdb/lock.mdb", O_RDWR|O_CREAT|O_CLOEXEC, 0664) = 3 fcntl64(3, 0x6 /* F_??? */, 0xbef42940) = 0 lseek(3, 0, SEEK_END) = 0 ftruncate(3, 8192) = 0 mmap2(NULL, 8192, PROT_READ|PROT_WRITE, MAP_SHARED, 3, 0) = 0xb6ff7000 open("./testdb/data.mdb", O_RDWR|O_CREAT, 0664) = 4 pread(4, "", 92, 0) = 0 mmap2(NULL, 10485760, PROT_READ, MAP_SHARED, 4, 0) = 0xb63de000 brk(0x358000) = 0x358000 pwrite(4, "\0\0\0\0\0\0\10\0\0\0\0\0\336\300\357\276\1\0\0\0\0\340=\266\0\0\240\0\0\20\0\0"..., 8192, 0) = 8192 open("./testdb/data.mdb", O_RDWR|O_SYNC) = 5 fcntl64(3, 0x6 /* F_??? */, 0xbef42984) = 0 write(1, "Adding 79 values\n", 17Adding 79 values ) = 17 write(1, "2 duplicates skipped\n", 212 duplicates skipped ) = 21 pwrite(4, "\2\0\0\0\0\0\2\0\246\0\304\2\204\5\20\7H\16\354\7\244\t0\v\30\10L\t\360\r\344\6"..., 4096, 0) = 4096 fdatasync(4) = 0 pwrite(5, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\377\377\377\377\0\0\0\0\0\0\1\0\0\0"..., 58, 0) = 58 write(1, "Deleted 0 values\n", 17Deleted 0 values ) = 17 write(1, "Cursor next\n", 12Cursor next ) = 12 write(1, "Cursor last\n", 12Cursor last ) = 12 write(2, "mtest.c", 7mtest.c) = 7 write(2, ":", 1:) = 1 write(2, "111", 3111) = 3 write(2, ": ", 2: ) = 2 write(2, "mdb_cursor_get(cursor, &key, &da"..., 45mdb_cursor_get(cursor, &key, &data, MDB_LAST)) = 45 write(2, ": ", 2: ) = 2 write(2, "MDB_NOTFOUND: No matching key/da"..., 45MDB_NOTFOUND: No matching key/data pair found) = 45 write(2, "\n", 1 ) = 1 rt_sigprocmask(SIG_UNBLOCK, [ABRT], NULL, 8) = 0 tgkill(1748, 1748, SIGABRT) = 0 --- SIGABRT {si_signo=SIGABRT, si_code=SI_TKILL, si_pid=1748, si_uid=0} --- +++ killed by SIGABRT +++ Aborted

1 0

Re: (ITS#7723) slapd crashes on multi core machines if a search request is *immediately* followed by an unbind
by quanah＠zimbra.com 29 Apr '14

29 Apr '14

--On April 29, 2014 at 2:42:19 PM +0000 konrad.windszus(a)netcentric.biz wrote: > > --Apple-Mail=_78FDB261-EA91-4040-8A46-100A6608DDC6 > Content-Transfer-Encoding: quoted-printable > Content-Type: text/plain; /builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23 You waste yours and everyone else's time using the RHEL/CentOS build of OpenLDAP. Get a real build from Symas or the LTB project. --Quanah -- Quanah Gibson-Mount Server Architect Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7723) slapd crashes on multi core machines if a search request is *immediately* followed by an unbind
by konrad.windszus＠netcentric.biz 29 Apr '14

29 Apr '14

--Apple-Mail=_78FDB261-EA91-4040-8A46-100A6608DDC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I got a similar crash when issuing a Bind request.=20 GDB has the following information about that: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f0898ff9700 (LWP 17201)] 0x00007f08d0a409f8 in hdb_reader_get (op=3D<value optimized out>, = env=3D0x7f08d14c55a0, txn=3D0x7f0898ff80a8) at cache.c:1621 1621 rc =3D TXN_BEGIN( env, NULL, txn, = DB_READ_COMMITTED ); The stack trace exposes the following: (gdb) bt full #0 0x00007f08d0a409f8 in hdb_reader_get (op=3D<value optimized out>, = env=3D0x7f08d14c55a0, txn=3D0x7f0898ff80a8) at cache.c:1621 i =3D <value optimized out> rc =3D <value optimized out> data =3D <value optimized out> ctx =3D 0x7f0898ff8b70 #1 0x00007f08d0a4bca7 in hdb_entry_get (op=3D0x7f0860000970, = ndn=3D0x7f08600009a8, oc=3D0x0, at=3D0x0, rw=3D0, ent=3D0x7f0898ff8400) = at id2entry.c:343 bdb =3D 0x7f08d14cf5a0 boi =3D 0x0 txn =3D 0x0 e =3D 0x0 ei =3D <value optimized out> rc =3D <value optimized out> at_name =3D 0x7f08d0abdacd "(null)" lock =3D {off =3D 8, ndx =3D 4294967295, gen =3D 32520, mode =3D = DB_LOCK_WWRITE} #2 0x00007f08d09ef799 in overlay_entry_get_ov (op=3D0x7f0860000970, = dn=3D0x7f08600009a8, oc=3D0x0, ad=3D0x0, rw=3D0, e=3D0x7f0898ff8400, = on=3D0x0) at ../../../servers/slapd/backover.c:364 oi =3D 0x7f08d14bd9d0 be =3D 0x7f08d14cf410 db =3D {bd_info =3D 0x2, bd_self =3D 0x7f0898ff81f0, be_ctrls =3D = "\357\067\216\351\275q4\216\221\364\071\341\\nF\252\213K\022+\000\002\000\= 000\000\000\000\000ihdof", be_flags =3D 551504935474,=20 be_restrictops =3D 0, be_requires =3D 0, be_ssf_set =3D = {sss_ssf =3D 0, sss_transport =3D 0, sss_tls =3D 2566881772, sss_sasl =3D = 32520, sss_update_ssf =3D 0, sss_update_transport =3D 0,=20 sss_update_tls =3D 3081553768, sss_update_sasl =3D 32520, = sss_simple_bind =3D 3513539536}, be_suffix =3D 0x7f08b7acc768, = be_nsuffix =3D 0x7f08d16c5bd0, be_schemadn =3D {bv_len =3D 122,=20 bv_val =3D 0x7f08b7ace810 "z"}, be_schemandn =3D {bv_len =3D = 139675828497508, bv_val =3D 0x7f086010f0b0 "."}, be_rootdn =3D {bv_len =3D= 139675850001328, bv_val =3D 0x7f08d13bf590 ""}, be_rootndn =3D { bv_len =3D 139675417895224, bv_val =3D 0x7f08cc629670 ""}, = be_rootpw =3D {bv_len =3D 7786477098, bv_val =3D 0x28 <Address 0x28 out = of bounds>}, be_max_deref_depth =3D 2566882064, be_def_limit =3D { lms_t_soft =3D 32520, lms_t_hard =3D -781427760, lms_s_soft = =3D 32520, lms_s_hard =3D -1213413528, lms_s_unchecked =3D 32520, = lms_s_pr =3D -1728085380, lms_s_pr_hide =3D 32520,=20 lms_s_pr_total =3D -1213537992}, be_limits =3D = 0x7f0898ff8310, be_acl =3D 0x7f08d0243101, be_dfltaccess =3D = -1728085408, be_update_ndn =3D {bv_len =3D 139672336465920,=20 bv_val =3D 0x7f08d16c4bb0 "\220Ol\321\b\177"}, = be_update_refs =3D 0x7f08d16c5bd0, be_pending_csn_list =3D = 0x7f0898ff8310, be_pcl_mutex =3D {__data =3D {__lock =3D 0, __count =3D = 0, __owner =3D -791385128,=20 __nusers =3D 32520, __kind =3D -802934423, __spins =3D = 32520, __list =3D {__prev =3D 0x0, __next =3D 0x0}},=20 __size =3D = "\000\000\000\000\000\000\000\000\330k\324\320\b\177\000\000i1$\320\b\177"= , '\000' <repeats 17 times>, __align =3D 0}, be_syncinfo =3D 0x1, be_pb = =3D 0x7f08d16c4bb0,=20 be_cf_ocs =3D 0x7f0898ff8310, be_private =3D 0x7f08d14c5730, = be_next =3D {stqe_next =3D 0x7f08d0dc87a0}} bi =3D 0x7f08d14bd9d0 rc =3D 32768 #3 0x00007f08d09f02e7 in over_entry_get_rw (op=3D<value optimized out>, = dn=3D<value optimized out>, oc=3D<value optimized out>, ad=3D<value = optimized out>, rw=3D<value optimized out>, e=3D<value optimized out>) at ../../../servers/slapd/backover.c:396 oi =3D <value optimized out> on =3D <value optimized out> __PRETTY_FUNCTION__ =3D "over_entry_get_rw" #4 0x00007f08cca73cb3 in ppolicy_bind_response (op=3D0x7f0860000970, = rs=3D0x7f0898ff8920) at ../../../../servers/slapd/overlays/ppolicy.c:919 ppb =3D 0x7f0860001630 on =3D 0x7f08d14c7540 mod =3D 0x0 m =3D <value optimized out> pwExpired =3D 0 ngut =3D -1 warn =3D -1 age =3D <value optimized out> rc =3D <value optimized out> a =3D <value optimized out> now =3D <value optimized out> pwtime =3D -1 nowstr =3D = "\240\000\000\000\000\000\000\000\325M=3D\316\b\177\000\000\200\216n\316\b= \177" timestamp =3D {bv_len =3D 3978984383913624688, bv_val =3D = 0x7f0898ff8486 ""} bi =3D 0x7f08d14d03e0 e =3D <value optimized out> #5 0x00007f08d0993f5e in slap_response_play (op=3D0x7f0860000970, = rs=3D0x7f0898ff8920) at ../../../servers/slapd/result.c:402 sc_next =3D 0x7f08600014c8 ---Type <return> to continue, or q <return> to quit--- sc_nextp =3D 0x7f0860001610 rc =3D 32768 sc =3D 0x7f0860001610 scp =3D 0x7f0898ff85e8 #6 0x00007f08d0996cae in send_ldap_response (op=3D0x7f0860000970, = rs=3D0x7f0898ff8920) at ../../../servers/slapd/result.c:476 berbuf =3D { buffer =3D = "\a\000\000\000\032\000\000\000\020\000\000\000\035\000\000\000\003\000\00= 0\000r\000\000\000\002\000\000\000v\000\000\000\001\000\000\000\b\177\000\= 000 = \034\000\000\000\000\000\000\220\343;\321\b\177\000\000`\r\000`\b\177\000\= 000\220\210\377\230\b\177\000\000\313\003\237\320\b\177\000\000\310\024\00= 0`\b\177\000\000\240\365\236\320\b\177\000\000\000\000\000\000\000\000\000= \000\340\003M\321\b\177\000\000 = d\324\320\b\177\000\000\020\364L\321\b\177\000\000\200\v\021`\b\177\000\00= 0\000\000\000\000\000\000\000\000\001\000\001\001\000\000\000\000\214\000\= 000\000\000\000\000\000\200\v\021`\b\177\000\000\177\266_S", '\000' = <repeats 12 times>, "p\t\000`\b\177\000\000\330k\324\320\b\177\000\000 = \375\324\320\b\177\000\000 = \211\377\230\b\177\000\000`\r\000`\b\177\000\000\220\210\377\230\b\177\000= \000c\342C\316\b\177\000\000\060\000\000\000"..., ialign =3D 7, lalign =3D= 111669149703, falign =3D 9.80908925e-45, dalign =3D = 5.517189056855554e-313, palign =3D 0x1a00000007 <Address 0x1a00000007 = out of bounds>} ber =3D 0x7f0898ff8630 rc =3D 0 bytes =3D <value optimized out> __PRETTY_FUNCTION__ =3D "send_ldap_response" #7 0x00007f08d0997c70 in slap_send_ldap_result (op=3D0x7f0860000970, = rs=3D0x7f0898ff8920) at ../../../servers/slapd/result.c:750 tmp =3D 0x0 otext =3D 0x0 oref =3D 0x0 __PRETTY_FUNCTION__ =3D "slap_send_ldap_result" #8 0x00007f08d09a1ba9 in fe_op_bind_success (op=3D0x7f0860000970, = rs=3D0x7f0898ff8920) at ../../../servers/slapd/bind.c:440 No locals. #9 0x00007f08d09a233f in fe_op_bind (op=3D0x7f0860000970, = rs=3D0x7f0898ff8920) at ../../../servers/slapd/bind.c:386 bd =3D 0x7f08d0d505e0 #10 0x00007f08d09a2b19 in do_bind (op=3D0x7f0860000970, = rs=3D0x7f0898ff8920) at ../../../servers/slapd/bind.c:205 ber =3D 0x7f0860000d60 version =3D 3 method =3D 128 mech =3D {bv_len =3D 0, bv_val =3D 0x0} dn =3D {bv_len =3D 60, bv_val =3D 0x7f08600008ca = "uid=3Dkonrad.windszus,ou=3Dinternal,ou=3Dusers,dc=3Dradvision,dc=3Dbiz"} tag =3D <value optimized out> be =3D <value optimized out> #11 0x00007f08d09839f9 in connection_operation (ctx=3D0x7f0898ff8b70, = arg_v=3D0x7f0860000970) at ../../../servers/slapd/connection.c:1109 rc =3D 80 cancel =3D <value optimized out> op =3D 0x7f0860000970 rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 97, sr_msgid =3D 1, = sr_err =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, = sr_ctrls =3D 0x0, sr_un =3D {sru_search =3D {r_entry =3D 0x0, = r_attr_flags =3D 0,=20 r_operational_attrs =3D 0x0, r_attrs =3D 0x0, r_nentries =3D= 0, r_v2ref =3D 0x0}, sru_sasl =3D {r_sasldata =3D 0x0}, sru_extended =3D = {r_rspoid =3D 0x0, r_rspdata =3D 0x0}}, sr_flags =3D 0} tag =3D 96 opidx =3D SLAP_OP_BIND conn =3D 0x7f08d14e3350 memctx =3D 0x7f0860000ed0 memctx_null =3D 0x0 memsiz =3D 1048576 __PRETTY_FUNCTION__ =3D "connection_operation" #12 0x00007f08d098434d in connection_read_thread (ctx=3D0x7f0898ff8b70, = argv=3D<value optimized out>) at = ../../../servers/slapd/connection.c:1245 rc =3D <value optimized out> cri =3D {op =3D 0x7f0860000970, func =3D 0, arg =3D 0x0, ctx =3D = 0x7f0898ff8b70, nullop =3D <value optimized out>} s =3D <value optimized out> #13 0x00007f08d0a83dd8 in ldap_int_thread_pool_wrapper = (xpool=3D0x7f08d13ee170) at ../../../libraries/libldap_r/tpool.c:685 pool =3D 0x7f08d13ee170 task =3D 0x7f089c000f00 work_list =3D <value optimized out> ctx =3D {ltu_id =3D 139674903353088, ltu_key =3D {{ltk_key =3D = 0x7f08d0982540, ltk_data =3D 0x7f0860000dc0, ltk_free =3D 0x7f08d0982620 = <conn_counter_destroy>}, {ltk_key =3D 0x7f08d09dc7d0,=20 ---Type <return> to continue, or q <return> to quit--- ltk_data =3D 0x7f0860000ed0, ltk_free =3D 0x7f08d09dc6b0 = <slap_sl_mem_destroy>}, {ltk_key =3D 0x7f08d16c99e0, ltk_data =3D = 0x7f0860100f50, ltk_free =3D 0x7f08d0a40900 <bdb_reader_free>}, { ltk_key =3D 0x7f08d0998400, ltk_data =3D 0x0, ltk_free =3D = 0x7f08d09981e0 <slap_op_q_destroy>}, {ltk_key =3D 0x7f08d16c4f90, = ltk_data =3D 0x7f086010ead0,=20 ltk_free =3D 0x7f08d0a40900 <bdb_reader_free>}, {ltk_key =3D= 0x0, ltk_data =3D 0x7f0854000ac0, ltk_free =3D 0}, {ltk_key =3D 0x0, = ltk_data =3D 0x0, ltk_free =3D 0} <repeats 26 times>}} kctx =3D <value optimized out> keyslot =3D <value optimized out> hash =3D <value optimized out> __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper" #14 0x00007f08ce8ff9d1 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #15 0x00007f08ce441b6d in clone () from /lib64/libc.so.6 No symbol table info available. I am using the binary=20 @(#) $OpenLDAP: slapd 2.4.23 (Feb 3 2014 19:11:35) $ = mockbuild@c6b10.bsys.dev.centos.org:/builddir/build/BUILD/openldap-2.4.23/= openldap-2.4.23/build-servers/servers/slapd That should have the patch from Jan included, so I am wondering whether = the original issue is still not solved or whether this is a separate = issue. Thanks, Konrad --Apple-Mail=_78FDB261-EA91-4040-8A46-100A6608DDC6 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii <html><head><meta http-equiv=3D"Content-Type" content=3D"text/html = charset=3Dus-ascii"></head><body style=3D"word-wrap: break-word; = -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">I got = a similar crash when issuing a Bind request. <div>GDB has the = following information about that:</div><div><br></div><div><div = style=3D"margin: 0px; font-size: 11px; font-family: Menlo;"><div = style=3D"margin: 0px;"><div style=3D"margin: 0px;">Program received = signal SIGSEGV, Segmentation fault.</div><div style=3D"margin: = 0px;">[Switching to Thread 0x7f0898ff9700 (LWP 17201)]</div><div = style=3D"margin: 0px;">0x00007f08d0a409f8 in hdb_reader_get = (op=3D<value optimized out>, env=3D0x7f08d14c55a0, = txn=3D0x7f0898ff80a8) at cache.c:1621</div><div style=3D"margin: = 0px;">1621<span class=3D"Apple-tab-span" style=3D"white-space:pre"> = </span>rc =3D TXN_BEGIN( env, NULL, txn, = DB_READ_COMMITTED );</div></div><div style=3D"margin: = 0px;"><br></div><div style=3D"margin: 0px;">The stack trace exposes the = following:</div><div style=3D"margin: 0px;"><div style=3D"margin: = 0px;">(gdb) bt full</div><div style=3D"margin: 0px;">#0  = 0x00007f08d0a409f8 in hdb_reader_get (op=3D<value optimized out>, = env=3D0x7f08d14c55a0, txn=3D0x7f0898ff80a8) at cache.c:1621</div><div = style=3D"margin: 0px;">        i =3D <value = optimized out></div><div style=3D"margin: 0px;">      =   rc =3D <value optimized out></div><div style=3D"margin: = 0px;">        data =3D <value optimized = out></div><div style=3D"margin: 0px;">        ctx = =3D 0x7f0898ff8b70</div><div style=3D"margin: 0px;">#1  = 0x00007f08d0a4bca7 in hdb_entry_get (op=3D0x7f0860000970, = ndn=3D0x7f08600009a8, oc=3D0x0, at=3D0x0, rw=3D0, ent=3D0x7f0898ff8400) = at id2entry.c:343</div><div style=3D"margin: 0px;">      =   bdb =3D 0x7f08d14cf5a0</div><div style=3D"margin: 0px;">  =       boi =3D 0x0</div><div style=3D"margin: 0px;">  =       txn =3D 0x0</div><div style=3D"margin: 0px;">  =       e =3D 0x0</div><div style=3D"margin: 0px;">  =       ei =3D <value optimized out></div><div = style=3D"margin: 0px;">        rc =3D <value = optimized out></div><div style=3D"margin: 0px;">      =   at_name =3D 0x7f08d0abdacd "(null)"</div><div style=3D"margin: = 0px;">        lock =3D {off =3D 8, ndx =3D = 4294967295, gen =3D 32520, mode =3D DB_LOCK_WWRITE}</div><div = style=3D"margin: 0px;">#2  0x00007f08d09ef799 in = overlay_entry_get_ov (op=3D0x7f0860000970, dn=3D0x7f08600009a8, oc=3D0x0, = ad=3D0x0, rw=3D0, e=3D0x7f0898ff8400, on=3D0x0) at = ../../../servers/slapd/backover.c:364</div><div style=3D"margin: = 0px;">        oi =3D 0x7f08d14bd9d0</div><div = style=3D"margin: 0px;">        be =3D = 0x7f08d14cf410</div><div style=3D"margin: 0px;">      =   db =3D {bd_info =3D 0x2, bd_self =3D 0x7f0898ff81f0, be_ctrls =3D = "\357\067\216\351\275q4\216\221\364\071\341\\nF\252\213K\022+\000\002\000\= 000\000\000\000\000ihdof", be_flags =3D 551504935474, </div><div = style=3D"margin: 0px;">          be_restrictops = =3D 0, be_requires =3D 0, be_ssf_set =3D {sss_ssf =3D 0, sss_transport =3D= 0, sss_tls =3D 2566881772, sss_sasl =3D 32520, sss_update_ssf =3D 0, = sss_update_transport =3D 0, </div><div style=3D"margin: = 0px;">            sss_update_tls =3D = 3081553768, sss_update_sasl =3D 32520, sss_simple_bind =3D 3513539536}, = be_suffix =3D 0x7f08b7acc768, be_nsuffix =3D 0x7f08d16c5bd0, be_schemadn = =3D {bv_len =3D 122, </div><div style=3D"margin: 0px;">  =           bv_val =3D 0x7f08b7ace810 "z"}, = be_schemandn =3D {bv_len =3D 139675828497508, bv_val =3D 0x7f086010f0b0 = "."}, be_rootdn =3D {bv_len =3D 139675850001328, bv_val =3D = 0x7f08d13bf590 ""}, be_rootndn =3D {</div><div style=3D"margin: = 0px;">            bv_len =3D = 139675417895224, bv_val =3D 0x7f08cc629670 ""}, be_rootpw =3D {bv_len =3D = 7786477098, bv_val =3D 0x28 <Address 0x28 out of bounds>}, = be_max_deref_depth =3D 2566882064, be_def_limit =3D {</div><div = style=3D"margin: 0px;">            = lms_t_soft =3D 32520, lms_t_hard =3D -781427760, lms_s_soft =3D 32520, = lms_s_hard =3D -1213413528, lms_s_unchecked =3D 32520, lms_s_pr =3D = -1728085380, lms_s_pr_hide =3D 32520, </div><div style=3D"margin: = 0px;">            lms_s_pr_total =3D = -1213537992}, be_limits =3D 0x7f0898ff8310, be_acl =3D 0x7f08d0243101, = be_dfltaccess =3D -1728085408, be_update_ndn =3D {bv_len =3D = 139672336465920, </div><div style=3D"margin: 0px;">    =         bv_val =3D 0x7f08d16c4bb0 = "\220Ol\321\b\177"}, be_update_refs =3D 0x7f08d16c5bd0, = be_pending_csn_list =3D 0x7f0898ff8310, be_pcl_mutex =3D {__data =3D = {__lock =3D 0, __count =3D 0, __owner =3D -791385128, </div><div = style=3D"margin: 0px;">              = __nusers =3D 32520, __kind =3D -802934423, __spins =3D 32520, __list =3D = {__prev =3D 0x0, __next =3D 0x0}}, </div><div style=3D"margin: = 0px;">            __size =3D = "\000\000\000\000\000\000\000\000\330k\324\320\b\177\000\000i1$\320\b\177"= , '\000' <repeats 17 times>, __align =3D 0}, be_syncinfo =3D 0x1, = be_pb =3D 0x7f08d16c4bb0, </div><div style=3D"margin: 0px;">  =         be_cf_ocs =3D 0x7f0898ff8310, be_private =3D = 0x7f08d14c5730, be_next =3D {stqe_next =3D 0x7f08d0dc87a0}}</div><div = style=3D"margin: 0px;">        bi =3D = 0x7f08d14bd9d0</div><div style=3D"margin: 0px;">      =   rc =3D 32768</div><div style=3D"margin: 0px;">#3  = 0x00007f08d09f02e7 in over_entry_get_rw (op=3D<value optimized = out>, dn=3D<value optimized out>, oc=3D<value optimized = out>, ad=3D<value optimized out>, rw=3D<value optimized = out>, e=3D<value optimized out>)</div><div style=3D"margin: = 0px;">    at ../../../servers/slapd/backover.c:396</div><div = style=3D"margin: 0px;">        oi =3D <value = optimized out></div><div style=3D"margin: 0px;">      =   on =3D <value optimized out></div><div style=3D"margin: = 0px;">        __PRETTY_FUNCTION__ =3D = "over_entry_get_rw"</div><div style=3D"margin: 0px;">#4  = 0x00007f08cca73cb3 in ppolicy_bind_response (op=3D0x7f0860000970, = rs=3D0x7f0898ff8920) at = ../../../../servers/slapd/overlays/ppolicy.c:919</div><div = style=3D"margin: 0px;">        ppb =3D = 0x7f0860001630</div><div style=3D"margin: 0px;">      =   on =3D 0x7f08d14c7540</div><div style=3D"margin: 0px;">  =       mod =3D 0x0</div><div style=3D"margin: 0px;">  =       m =3D <value optimized out></div><div = style=3D"margin: 0px;">        pwExpired =3D = 0</div><div style=3D"margin: 0px;">        ngut =3D = -1</div><div style=3D"margin: 0px;">        warn =3D = -1</div><div style=3D"margin: 0px;">        age =3D = <value optimized out></div><div style=3D"margin: 0px;">  =       rc =3D <value optimized out></div><div = style=3D"margin: 0px;">        a =3D <value = optimized out></div><div style=3D"margin: 0px;">      =   now =3D <value optimized out></div><div style=3D"margin: = 0px;">        pwtime =3D -1</div><div style=3D"margin:= 0px;">        nowstr =3D = "\240\000\000\000\000\000\000\000\325M=3D\316\b\177\000\000\200\216n\316\b= \177"</div><div style=3D"margin: 0px;">        = timestamp =3D {bv_len =3D 3978984383913624688, bv_val =3D 0x7f0898ff8486 = ""}</div><div style=3D"margin: 0px;">        bi =3D = 0x7f08d14d03e0</div><div style=3D"margin: 0px;">      =   e =3D <value optimized out></div><div style=3D"margin: = 0px;">#5  0x00007f08d0993f5e in slap_response_play = (op=3D0x7f0860000970, rs=3D0x7f0898ff8920) at = ../../../servers/slapd/result.c:402</div><div style=3D"margin: = 0px;">        sc_next =3D 0x7f08600014c8</div><div = style=3D"margin: 0px;">---Type <return> to continue, or q = <return> to quit---</div><div style=3D"margin: 0px;">    =     sc_nextp =3D 0x7f0860001610</div><div style=3D"margin: = 0px;">        rc =3D 32768</div><div style=3D"margin: = 0px;">        sc =3D 0x7f0860001610</div><div = style=3D"margin: 0px;">        scp =3D = 0x7f0898ff85e8</div><div style=3D"margin: 0px;">#6  = 0x00007f08d0996cae in send_ldap_response (op=3D0x7f0860000970, = rs=3D0x7f0898ff8920) at ../../../servers/slapd/result.c:476</div><div = style=3D"margin: 0px;">        berbuf =3D = {</div><div style=3D"margin: 0px;">          = buffer =3D = "\a\000\000\000\032\000\000\000\020\000\000\000\035\000\000\000\003\000\00= 0\000r\000\000\000\002\000\000\000v\000\000\000\001\000\000\000\b\177\000\= 000 = \034\000\000\000\000\000\000\220\343;\321\b\177\000\000`\r\000`\b\177\000\= 000\220\210\377\230\b\177\000\000\313\003\237\320\b\177\000\000\310\024\00= 0`\b\177\000\000\240\365\236\320\b\177\000\000\000\000\000\000\000\000\000= \000\340\003M\321\b\177\000\000 = d\324\320\b\177\000\000\020\364L\321\b\177\000\000\200\v\021`\b\177\000\00= 0\000\000\000\000\000\000\000\000\001\000\001\001\000\000\000\000\214\000\= 000\000\000\000\000\000\200\v\021`\b\177\000\000\177\266_S", '\000' = <repeats 12 times>, = "p\t\000`\b\177\000\000\330k\324\320\b\177\000\000 = \375\324\320\b\177\000\000 = \211\377\230\b\177\000\000`\r\000`\b\177\000\000\220\210\377\230\b\177\000= \000c\342C\316\b\177\000\000\060\000\000\000"..., ialign =3D 7, lalign =3D= 111669149703, falign =3D 9.80908925e-45, dalign =3D = 5.517189056855554e-313, palign =3D 0x1a00000007 <Address 0x1a00000007 = out of bounds>}</div><div style=3D"margin: 0px;">      =   ber =3D 0x7f0898ff8630</div><div style=3D"margin: 0px;">  =       rc =3D 0</div><div style=3D"margin: 0px;">  =       bytes =3D <value optimized out></div><div = style=3D"margin: 0px;">        __PRETTY_FUNCTION__ =3D= "send_ldap_response"</div><div style=3D"margin: 0px;">#7  = 0x00007f08d0997c70 in slap_send_ldap_result (op=3D0x7f0860000970, = rs=3D0x7f0898ff8920) at ../../../servers/slapd/result.c:750</div><div = style=3D"margin: 0px;">        tmp =3D 0x0</div><div = style=3D"margin: 0px;">        otext =3D = 0x0</div><div style=3D"margin: 0px;">        oref =3D = 0x0</div><div style=3D"margin: 0px;">        = __PRETTY_FUNCTION__ =3D "slap_send_ldap_result"</div><div style=3D"margin:= 0px;">#8  0x00007f08d09a1ba9 in fe_op_bind_success = (op=3D0x7f0860000970, rs=3D0x7f0898ff8920) at = ../../../servers/slapd/bind.c:440</div><div style=3D"margin: 0px;">No = locals.</div><div style=3D"margin: 0px;">#9  0x00007f08d09a233f in = fe_op_bind (op=3D0x7f0860000970, rs=3D0x7f0898ff8920) at = ../../../servers/slapd/bind.c:386</div><div style=3D"margin: = 0px;">        bd =3D 0x7f08d0d505e0</div><div = style=3D"margin: 0px;">#10 0x00007f08d09a2b19 in do_bind = (op=3D0x7f0860000970, rs=3D0x7f0898ff8920) at = ../../../servers/slapd/bind.c:205</div><div style=3D"margin: = 0px;">        ber =3D 0x7f0860000d60</div><div = style=3D"margin: 0px;">        version =3D = 3</div><div style=3D"margin: 0px;">        method =3D = 128</div><div style=3D"margin: 0px;">        mech =3D = {bv_len =3D 0, bv_val =3D 0x0}</div><div style=3D"margin: 0px;">  =       dn =3D {bv_len =3D 60, bv_val =3D 0x7f08600008ca = "uid=3Dkonrad.windszus,ou=3Dinternal,ou=3Dusers,dc=3Dradvision,dc=3Dbiz"}<= /div><div style=3D"margin: 0px;">        tag =3D = <value optimized out></div><div style=3D"margin: 0px;">  =       be =3D <value optimized out></div><div = style=3D"margin: 0px;">#11 0x00007f08d09839f9 in connection_operation = (ctx=3D0x7f0898ff8b70, arg_v=3D0x7f0860000970) at = ../../../servers/slapd/connection.c:1109</div><div style=3D"margin: = 0px;">        rc =3D 80</div><div style=3D"margin: = 0px;">        cancel =3D <value optimized = out></div><div style=3D"margin: 0px;">        op = =3D 0x7f0860000970</div><div style=3D"margin: 0px;">      =   rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 97, sr_msgid =3D 1, = sr_err =3D 0, sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, = sr_ctrls =3D 0x0, sr_un =3D {sru_search =3D {r_entry =3D 0x0, = r_attr_flags =3D 0, </div><div style=3D"margin: 0px;">    =           r_operational_attrs =3D 0x0, r_attrs = =3D 0x0, r_nentries =3D 0, r_v2ref =3D 0x0}, sru_sasl =3D {r_sasldata =3D = 0x0}, sru_extended =3D {r_rspoid =3D 0x0, r_rspdata =3D 0x0}}, sr_flags = =3D 0}</div><div style=3D"margin: 0px;">        tag = =3D 96</div><div style=3D"margin: 0px;">        = opidx =3D SLAP_OP_BIND</div><div style=3D"margin: 0px;">    =     conn =3D 0x7f08d14e3350</div><div style=3D"margin: = 0px;">        memctx =3D 0x7f0860000ed0</div><div = style=3D"margin: 0px;">        memctx_null =3D = 0x0</div><div style=3D"margin: 0px;">        memsiz = =3D 1048576</div><div style=3D"margin: 0px;">        = __PRETTY_FUNCTION__ =3D "connection_operation"</div><div style=3D"margin: = 0px;">#12 0x00007f08d098434d in connection_read_thread = (ctx=3D0x7f0898ff8b70, argv=3D<value optimized out>) at = ../../../servers/slapd/connection.c:1245</div><div style=3D"margin: = 0px;">        rc =3D <value optimized = out></div><div style=3D"margin: 0px;">        cri = =3D {op =3D 0x7f0860000970, func =3D 0, arg =3D 0x0, ctx =3D = 0x7f0898ff8b70, nullop =3D <value optimized out>}</div><div = style=3D"margin: 0px;">        s =3D <value = optimized out></div><div style=3D"margin: 0px;">#13 = 0x00007f08d0a83dd8 in ldap_int_thread_pool_wrapper = (xpool=3D0x7f08d13ee170) at = ../../../libraries/libldap_r/tpool.c:685</div><div style=3D"margin: = 0px;">        pool =3D 0x7f08d13ee170</div><div = style=3D"margin: 0px;">        task =3D = 0x7f089c000f00</div><div style=3D"margin: 0px;">      =   work_list =3D <value optimized out></div><div = style=3D"margin: 0px;">        ctx =3D {ltu_id =3D = 139674903353088, ltu_key =3D {{ltk_key =3D 0x7f08d0982540, ltk_data =3D = 0x7f0860000dc0, ltk_free =3D 0x7f08d0982620 = <conn_counter_destroy>}, {ltk_key =3D = 0x7f08d09dc7d0, </div><div style=3D"margin: 0px;">---Type = <return> to continue, or q <return> to quit---</div><div = style=3D"margin: 0px;">              = ltk_data =3D 0x7f0860000ed0, ltk_free =3D 0x7f08d09dc6b0 = <slap_sl_mem_destroy>}, {ltk_key =3D 0x7f08d16c99e0, ltk_data =3D = 0x7f0860100f50, ltk_free =3D 0x7f08d0a40900 <bdb_reader_free>}, = {</div><div style=3D"margin: 0px;">          =     ltk_key =3D 0x7f08d0998400, ltk_data =3D 0x0, ltk_free =3D = 0x7f08d09981e0 <slap_op_q_destroy>}, {ltk_key =3D 0x7f08d16c4f90, = ltk_data =3D 0x7f086010ead0, </div><div style=3D"margin: = 0px;">              ltk_free =3D = 0x7f08d0a40900 <bdb_reader_free>}, {ltk_key =3D 0x0, ltk_data =3D = 0x7f0854000ac0, ltk_free =3D 0}, {ltk_key =3D 0x0, ltk_data =3D 0x0, = ltk_free =3D 0} <repeats 26 times>}}</div><div style=3D"margin: = 0px;">        kctx =3D <value optimized = out></div><div style=3D"margin: 0px;">        = keyslot =3D <value optimized out></div><div style=3D"margin: = 0px;">        hash =3D <value optimized = out></div><div style=3D"margin: 0px;">        = __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper"</div><div = style=3D"margin: 0px;">#14 0x00007f08ce8ff9d1 in start_thread () from = /lib64/libpthread.so.0</div><div style=3D"margin: 0px;">No symbol table = info available.</div><div style=3D"margin: 0px;">#15 0x00007f08ce441b6d = in clone () from /lib64/libc.so.6</div><div style=3D"margin: 0px;">No = symbol table info available.</div></div><div style=3D"margin: = 0px;"><br></div><div style=3D"margin: 0px;">I am using the = binary </div><div style=3D"margin: 0px;"><div style=3D"margin: = 0px;">@(#) $OpenLDAP: slapd 2.4.23 (Feb  3 2014 19:11:35) = $</div><div style=3D"margin: 0px;"><span class=3D"Apple-tab-span" = style=3D"white-space:pre"> </span><a = href=3D"mailto:mockbuild@c6b10.bsys.dev.centos.org">mockbuild(a)c6b10.bsys.d= ev.centos.org</a>:/builddir/build/BUILD/openldap-2.4.23/openldap-2.4.23/bu= ild-servers/servers/slapd</div></div></div></div><div><br></div><div>That = should have the patch from Jan included, so I am wondering whether the = original issue is still not solved or whether this is a separate = issue.</div><div>Thanks,</div><div>Konrad</div><div><br></div></body></htm= l>= --Apple-Mail=_78FDB261-EA91-4040-8A46-100A6608DDC6--

1 0

(ITS#7845) slapd debug in the background
by wingcheungma＠gmail.com 28 Apr '14

28 Apr '14

Full_Name: Wing Cheung Ma Version: 2.4.23 OS: Rhel5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (54.240.196.185) Hello, I have been running slapd with -d 1 and the logfile directive in my slapd.conf file. The issue is that I also want slapd to fork into the background once the process starts. The bash script that starts up this process needs to exit before the deployment is considered a success. Is there a way to get debugging information in my logs without using syslog and without having slapd running the foreground? Thanks -Wing

1 0

(ITS#7844) LMDB Delete Cursor inconsistencies
by armon.dadgar＠gmail.com 26 Apr '14

26 Apr '14

Full_Name: Armon Dadgar Version: OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.200.38.131) When using a transaction across multiple named tables, it seems that if I am iterating and deleting I can trigger a condition that causes some rows to be missed by the cursor. There is a test case here that can reproduce it: https://gist.github.com/armon/11338944 You can run it using: go run test.go mdb_table.go Here is one of my test runs: https://gist.github.com/armon/11338967 In that test, I would expect all 128 entries to be deleted, but only 43 are before the cursor stops returning new rows.

1 0

(ITS#7843) ldap_set_option on LDAP not working
by korylprince＠gmail.com 25 Apr '14

25 Apr '14

Full_Name: Kory Prince Version: 2.4.39 OS: Linux (Arch/Ubuntu) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (71.49.164.94) Consider the following code: #include <stdio.h> #include <ldap.h> void main() { LDAP *ld; int status = ldap_initialize(&ld, "ldaps://server:636"); if (status == LDAP_SUCCESS) { printf("initialize success\n"); } status = ldap_set_option(NULL, LDAP_OPT_X_TLS_CACERTFILE, "/etc/ssl/certs/ca-certificates.crt"); status = ldap_simple_bind_s(ld, "bindDN", "pass"); if (status == LDAP_SUCCESS) { printf("bind success\n"); } else { printf("%s\n", ldap_err2string(status)); } } This works as expected. However changing the set_option line to status = ldap_set_option(ld, LDAP_OPT_X_TLS_CACERTFILE, "/etc/ssl/certs/ca-certificates.crt"); (setting the option on the LDAP) causes the bind to fail. Using python-ldap gives me a bit more info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed (unable to get local issuer certificate) I have compiled libldap 2.4.39 on Arch and Ubuntu and am getting the same result. Interestingly enough, the version that comes packaged on Ubuntu 12.04 (2.4.28) works fine, but compiling that version myself gives the same error.

1 0

(ITS#7842) mdb readers/writer exclusion protocol, as implemented, is racy.
by rsbx＠acm.org 22 Apr '14

22 Apr '14

Full_Name: Raymond S Brand Version: mdb.master OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (107.145.137.13) [I would have uploaded this to the ftp.openldap.org but there was no space.] As implemented, the mdb readers/writer exclusion protocol has a race condition that could result in a writer reclaiming and over-writing pages still in use by a reader. Pseudo code of the snapshot locking protocols of reader and writer transactions. The labeled sections, for the purposes of this analysis, can be assumed to execute atomically. READER ====== *R1* t0 = meta[0].txid; t1 = meta[1].txid if (t1 > t0) t0 = t1 *R2* readers[me].txid = t0 *R3* snapshot_root = meta[t0&1].snapshot *R4* /* lookup data */ *R5* readers[me].txid = -1 // Release snapshot WRITER ====== *W1* lock(writer, EXCLUSIVE) curr_txid = meta[0].txid if (meta[1].txid > curr_txid) curr_txid = meta[1].txid *W2* oldest = curr_txid for (i=0; i<reader_slots; i++) t = readers[i].txid if (t != -1 && t < oldest) oldest = t *W3* reclaim_old_pages(oldest) /* ** Commit new transaction */ *W4* unlock(writer) --------------------------------------------------------------------------- Adversarial scheduling analysis: The following timeline demonstrates that a writer can reclaim pages in use by a reader. T0 T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 R1 R2 R3 R4 W1 W2 W3 W4 * W1 W2 W3 T0 Reader has found the latest txid, Xn. T1->T4 Reader is not scheduled to run and a write transaction commits, Xn+1. T5 Reader is still not scheduled and another write transaction starts. T6 Writer finds that the oldest referenced transaction is the last committed transaction, Xn+1. T7 Reader records Xn in the reader table. T8 Reader gets the snapshot root page for transaction Xn. T9 Writer, believing that Xn+1 is the oldest reference transaction, reclaims the pages of transaction Xn. T10 Reader attempts to navigate pages of a transaction, Xn, that has been reclaimed and "Bad Things Happen". In fact, bad things will happen if an even number of write transactions commit between W4 and W1, represented by the '*', in the timeline above. The fix is to search for the highest txid in R1 and between R2 and R3. Optionally, followed by recording the txid, of the snapshot root found in R3, in the reader's reader table slot to, possibly, increase the number of reclaimable transactions. The lack of compiler and memory barriers in the implementation of the locking protocol is also of concern. Beyond the above, the code in mdb_txn_renew0() after the "/* Copy the DB info and flags */" comment appears to have a number of data races. --- libraries/liblmdb/mdb.c | 24 +++++++++++++++--------- 1 file changed, 15 insertions(+), 9 deletions(-) diff --git a/libraries/liblmdb/mdb.c b/libraries/liblmdb/mdb.c index e0f551e..908417c 100644 --- a/libraries/liblmdb/mdb.c +++ b/libraries/liblmdb/mdb.c @@ -533,11 +533,11 @@ typedef struct MDB_rxbody { * started from so we can avoid overwriting any data used in that * particular version. */ - txnid_t mrb_txnid; + volatile txnid_t mrb_txnid; /** The process ID of the process owning this reader txn. */ - MDB_PID_T mrb_pid; + volatile MDB_PID_T mrb_pid; /** The thread ID of the thread owning this txn. */ - pthread_t mrb_tid; + volatile pthread_t mrb_tid; } MDB_rxbody; /** The actual reader record, with cacheline padding. */ @@ -585,12 +585,12 @@ typedef struct MDB_txbody { * This is recorded here only for convenience; the value can always * be determined by reading the main database meta pages. */ - txnid_t mtb_txnid; + volatile txnid_t mtb_txnid; /** The number of slots that have been used in the reader table. * This always records the maximum count, it is not decremented * when readers release their slots. */ - unsigned mtb_numreaders; + volatile unsigned mtb_numreaders; } MDB_txbody; /** The actual reader table definition. */ @@ -854,7 +854,7 @@ typedef struct MDB_meta { /** Any persistent environment flags. @ref mdb_env */ #define mm_flags mm_dbs[0].md_flags pgno_t mm_last_pg; /**< last used page in file */ - txnid_t mm_txnid; /**< txnid that committed this page */ + volatile txnid_t mm_txnid; /**< txnid that committed this page */ } MDB_meta; /** Buffer for a stack-allocated meta page. @@ -2303,10 +2303,12 @@ mdb_txn_renew0(MDB_txn *txn) if (txn->mt_flags & MDB_TXN_RDONLY) { if (!ti) { + /* No readers table; app responsible for locking */ meta = env->me_metas[ mdb_env_pick_meta(env) ]; txn->mt_txnid = meta->mm_txnid; txn->mt_u.reader = NULL; } else { + /* Has readers table */ MDB_reader *r = (env->me_flags & MDB_NOTLS) ? txn->mt_u.reader : pthread_getspecific(env->me_txkey); if (r) { @@ -2347,8 +2349,12 @@ mdb_txn_renew0(MDB_txn *txn) return rc; } } - txn->mt_txnid = r->mr_txnid = ti->mti_txnid; txn->mt_u.reader = r; + r->mr_txnid = ti->mti_txnid; + + /* Really need a memory barrier here */ + + txn->mt_txnid = r->mr_txnid = ti->mti_txnid; meta = env->me_metas[txn->mt_txnid & 1]; } } else { @@ -2376,10 +2382,10 @@ mdb_txn_renew0(MDB_txn *txn) } /* Copy the DB info and flags */ - memcpy(txn->mt_dbs, meta->mm_dbs, 2 * sizeof(MDB_db)); + memcpy(txn->mt_dbs, meta->mm_dbs, 2 * sizeof(MDB_db)); /* Racy */ /* Moved to here to avoid a data race in read TXNs */ - txn->mt_next_pgno = meta->mm_last_pg+1; + txn->mt_next_pgno = meta->mm_last_pg+1; /* Racy */ for (i=2; i<txn->mt_numdbs; i++) { x = env->me_dbflags[i]; -- 1.9.0.138.g2de3478

1 0

Re: (ITS#7840) bug with initial/seed syncrepl
by jephte.clain＠univ-reunion.fr 22 Apr '14

22 Apr '14

hello, FYI, I just stumbled on an old topic from 2011: --------------------------------- 8< --------------------------------- Re: cn=config replication to consumer / slave servers ________________________________ To: Christopher Strider Cook <ccook(a)pandora.com> Subject: Re: cn=config replication to consumer / slave servers From: Howard Chu <hyc(a)symas.com> Date: Tue, 19 Apr 2011 17:27:58 -0700 Cc: Quanah Gibson-Mount <quanah(a)zimbra.com>, openldap-technical(a)openldap.org ________________________________ Christopher Strider Cook wrote: > So, the pointer to test059 was exactly what this issue needed and > following it has lead me to an very good working setup with one puzzling > final step. > The problem I now face is that the initial cn=config entries used to do > the first sync do not get overwritten by the data from the master. So > the install password doesn't get replaced nor do the updated retry > timeouts for olcSyncRepl, because, I'm assuming, the 'stub' entries have > newer timestamps than those on the master. > How can this be overcome from the perspective of the slave server. > Updating the entries on the master triggers the update as you would > expect. Is there a way to put the stub entries onto the slave with a > timestamp in the past so that they get overwritten during the first > sync? Or is there another way to trigger them to be updated? Use slapd -c. Read the slapd(8) manpage. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------------------------- 8< --------------------------------- you always answer "use slapd -c" to this type of question, but you _never_ mention that newer entries are never overwritten by older entries. so _in this context_ this answer is useless building the consumer before the provider is not an option, also _in this context_ so the only option left is to update the master with an empty modify ldif to force update of the timestamps I personnaly use --------------------------------- 8< --------------------------------- dn: cn=config changetype: modify dn: olcDatabase={-1}frontend,cn=config changetype: modify dn: olcDatabase={0}config,cn=config changetype: modify --------------------------------- 8< --------------------------------- besides, if you do this update with a user from a different database, e.g cn=admin,dc=my,dc=tld the seed replication fails because modifiersName contains a non existing DN (at the time of the replication). I consider this a bug also. anyway, thanks for your dedicated time and effort. OpenLDAP is really a great software. I have a lot to learn yet. so please bear with me :-) best regards, 2014-04-20 11:33 GMT+04:00 Jephte Clain <jephte.clain(a)univ-reunion.fr>: > hello, > > thanks for your answer. > see my response below > > 2014-04-20 7:13 GMT+04:00 Howard Chu <hyc(a)symas.com>: >> Jephte.Clain(a)univ-reunion.fr wrote: >>> >>> Full_Name: Jephte CLAIN >>> Version: 2.4.39 >>> OS: Debian 6 64bits >>> URL: http://jclain.fr/openldap-its/ >>> Submission from: (NULL) (93.176.62.129) >>> >>> >>> I have scripts to test several replication scenarii, that setup the LDAP >>> environment then allow me to play with parameters as I see fit. >>> >>> I believe that there is a bug with the "seed replication" that allow one >>> to >>> build an exact clone of a master with minimal configuration on the slave >>> side. >> >> >> There is no bug. The syncrepl consumer is working as designed. If you want >> the consumer's entries to be automatically overwritten, create the consumer >> first so that its seed entries have older timestamps than the provider. > > ok, it works as designed. I just didn't know what the design was :-) > quoting man slapd: > Use only the rid part to force a full reload. > I guess I didn't notice that the word "full" have a different meaning > here than usual > > about creating the consumer first. you are kidding, right? in > production, the provider exists long before the consumer is set up. > the tests I do are based on the production state. > > anyway, my automated scripts "touch" the provider after setting up the > slave, so this is not a problem. > It's just that I would prefer not to have wasted time wondering why > the slave was not being updated even though I asked for a "full" > reload > > Thanks for your answer. It's now clearer in my mind. > I Cc the openldap-technical list, this can help others. > >> >>> note: the tests below require 2 VMs, or running the two slapd instances in >>> chroots, because a clone replica requires the data files to be in the same >>> path... >> >> >> That's far overkill. All you need to do is configure your test scripts to >> use relative pathnames. test049 (and others) in the test suite already >> operates this way. > > ok thanks for pointing this out > It has been a while since I read the tests scripts. I should have paid > more attention... > >> >> Closing this ITS. >> >>> I attach two scripts to replicate the problem. they require root (they >>> uses >>> chroots) >>> this is with openldap 2.4.39 on debian squeeze. some paths may have to be >>> fixed >>> in the scripts below >>> >>> use jclain-20140419-0start.sh to: >>> - create a ldap server to be served on ldap://localhost:3890 >>> - start the master in chroot >>> (the logs are in /jclain-slapd-test/master.data/slapd.log) >>> - create a seed ldap replica to be served on ldap://localhost:3891 with >>> ldap://localhost:3890 as the provider >>> - start it in chroot with option -c rid=0 >>> (the logs are in /jclain-slapd-test/slave.data/slapd.log) >>> >>> use jclain-20140419-1stop.sh to: >>> - stop the servers >>> - umount the chroots >>> >>> If I understand the manual correctly, after 0start.sh, the replica should >>> be >>> identical to the master thanks to -c rid=0 >>> BUT, the log on the replica says: >>> >>> 534d5481 dn_callback : new entry is older than ours cn=config ours >>> 20140415154713.807278Z#000000#000#000000, new >>> 20140415154704.888204Z#000000#000#000000 >>> >>> and indeed, the seed entries are NOT overwritten >>> I have to "touch" them on the master to force the replication. >>> >>> I have uploaded the scripts to http://jclain.fr/openldap-its/ >>> >>> thanks in advance >>> >>> -- Jephté Clain Direction des Systèmes d'Information et des Usages Numériques - 2IG Tél. 0262 93 86 31 Fax. 0262 93 81 06

1 0

(ITS#7841) high disk utilization
by dmitrii.fonariuk＠gmail.com 21 Apr '14

21 Apr '14

Full_Name: Dmitrii Fonariuk Version: 2.4.38 OS: rhEL6.x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (91.210.4.1) There is a big value of DISK WRITE parameter in utility Iotop when in MDB a lot of Free pages (Freelist Status). Supposedly this situation arises from memory management algorithm. The algorithm FIFO is used for pages block allocation in free pages pool. We touched and dirty different pages on every modification transaction, which then flushed to disk by system process Flush. Perhaps it would be better to use the LIFO, which will to dirty the same pages by different transactions, which reduces the load on the disk? we use MDB with EnvFlags writemap and mapasync.

1 0

Re: (ITS#7840) bug with initial/seed syncrepl
by jephte.clain＠univ-reunion.fr 20 Apr '14

20 Apr '14

hello, thanks for your answer. see my response below 2014-04-20 7:13 GMT+04:00 Howard Chu <hyc(a)symas.com>: > Jephte.Clain(a)univ-reunion.fr wrote: >> >> Full_Name: Jephte CLAIN >> Version: 2.4.39 >> OS: Debian 6 64bits >> URL: http://jclain.fr/openldap-its/ >> Submission from: (NULL) (93.176.62.129) >> >> >> I have scripts to test several replication scenarii, that setup the LDAP >> environment then allow me to play with parameters as I see fit. >> >> I believe that there is a bug with the "seed replication" that allow one >> to >> build an exact clone of a master with minimal configuration on the slave >> side. > > > There is no bug. The syncrepl consumer is working as designed. If you want > the consumer's entries to be automatically overwritten, create the consumer > first so that its seed entries have older timestamps than the provider. ok, it works as designed. I just didn't know what the design was :-) quoting man slapd: Use only the rid part to force a full reload. I guess I didn't notice that the word "full" have a different meaning here than usual about creating the consumer first. you are kidding, right? in production, the provider exists long before the consumer is set up. the tests I do are based on the production state. anyway, my automated scripts "touch" the provider after setting up the slave, so this is not a problem. It's just that I would prefer not to have wasted time wondering why the slave was not being updated even though I asked for a "full" reload Thanks for your answer. It's now clearer in my mind. I Cc the openldap-technical list, this can help others. > >> note: the tests below require 2 VMs, or running the two slapd instances in >> chroots, because a clone replica requires the data files to be in the same >> path... > > > That's far overkill. All you need to do is configure your test scripts to > use relative pathnames. test049 (and others) in the test suite already > operates this way. ok thanks for pointing this out It has been a while since I read the tests scripts. I should have paid more attention... > > Closing this ITS. > >> I attach two scripts to replicate the problem. they require root (they >> uses >> chroots) >> this is with openldap 2.4.39 on debian squeeze. some paths may have to be >> fixed >> in the scripts below >> >> use jclain-20140419-0start.sh to: >> - create a ldap server to be served on ldap://localhost:3890 >> - start the master in chroot >> (the logs are in /jclain-slapd-test/master.data/slapd.log) >> - create a seed ldap replica to be served on ldap://localhost:3891 with >> ldap://localhost:3890 as the provider >> - start it in chroot with option -c rid=0 >> (the logs are in /jclain-slapd-test/slave.data/slapd.log) >> >> use jclain-20140419-1stop.sh to: >> - stop the servers >> - umount the chroots >> >> If I understand the manual correctly, after 0start.sh, the replica should >> be >> identical to the master thanks to -c rid=0 >> BUT, the log on the replica says: >> >> 534d5481 dn_callback : new entry is older than ours cn=config ours >> 20140415154713.807278Z#000000#000#000000, new >> 20140415154704.888204Z#000000#000#000000 >> >> and indeed, the seed entries are NOT overwritten >> I have to "touch" them on the master to force the replication. >> >> I have uploaded the scripts to http://jclain.fr/openldap-its/ >> >> thanks in advance >> >> > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ -- cordialement, Jephté Clain Direction des Systèmes d'Information et des Usages Numériques - 2IG Tél. 0262 93 86 31 Fax. 0262 93 81 06

1 0

Re: (ITS#7840) bug with initial/seed syncrepl
by hyc＠symas.com 19 Apr '14

19 Apr '14

Jephte.Clain(a)univ-reunion.fr wrote: > Full_Name: Jephte CLAIN > Version: 2.4.39 > OS: Debian 6 64bits > URL: http://jclain.fr/openldap-its/ > Submission from: (NULL) (93.176.62.129) > > > I have scripts to test several replication scenarii, that setup the LDAP > environment then allow me to play with parameters as I see fit. > > I believe that there is a bug with the "seed replication" that allow one to > build an exact clone of a master with minimal configuration on the slave side. There is no bug. The syncrepl consumer is working as designed. If you want the consumer's entries to be automatically overwritten, create the consumer first so that its seed entries have older timestamps than the provider. > note: the tests below require 2 VMs, or running the two slapd instances in > chroots, because a clone replica requires the data files to be in the same > path... That's far overkill. All you need to do is configure your test scripts to use relative pathnames. test049 (and others) in the test suite already operates this way. Closing this ITS. > I attach two scripts to replicate the problem. they require root (they uses > chroots) > this is with openldap 2.4.39 on debian squeeze. some paths may have to be fixed > in the scripts below > > use jclain-20140419-0start.sh to: > - create a ldap server to be served on ldap://localhost:3890 > - start the master in chroot > (the logs are in /jclain-slapd-test/master.data/slapd.log) > - create a seed ldap replica to be served on ldap://localhost:3891 with > ldap://localhost:3890 as the provider > - start it in chroot with option -c rid=0 > (the logs are in /jclain-slapd-test/slave.data/slapd.log) > > use jclain-20140419-1stop.sh to: > - stop the servers > - umount the chroots > > If I understand the manual correctly, after 0start.sh, the replica should be > identical to the master thanks to -c rid=0 > BUT, the log on the replica says: > > 534d5481 dn_callback : new entry is older than ours cn=config ours > 20140415154713.807278Z#000000#000#000000, new > 20140415154704.888204Z#000000#000#000000 > > and indeed, the seed entries are NOT overwritten > I have to "touch" them on the master to force the replication. > > I have uploaded the scripts to http://jclain.fr/openldap-its/ > > thanks in advance > > -- -- 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#7840) bug with initial/seed syncrepl
by Jephte.Clain＠univ-reunion.fr 19 Apr '14

19 Apr '14

Full_Name: Jephte CLAIN Version: 2.4.39 OS: Debian 6 64bits URL: http://jclain.fr/openldap-its/ Submission from: (NULL) (93.176.62.129) I have scripts to test several replication scenarii, that setup the LDAP environment then allow me to play with parameters as I see fit. I believe that there is a bug with the "seed replication" that allow one to build an exact clone of a master with minimal configuration on the slave side. note: the tests below require 2 VMs, or running the two slapd instances in chroots, because a clone replica requires the data files to be in the same path... I attach two scripts to replicate the problem. they require root (they uses chroots) this is with openldap 2.4.39 on debian squeeze. some paths may have to be fixed in the scripts below use jclain-20140419-0start.sh to: - create a ldap server to be served on ldap://localhost:3890 - start the master in chroot (the logs are in /jclain-slapd-test/master.data/slapd.log) - create a seed ldap replica to be served on ldap://localhost:3891 with ldap://localhost:3890 as the provider - start it in chroot with option -c rid=0 (the logs are in /jclain-slapd-test/slave.data/slapd.log) use jclain-20140419-1stop.sh to: - stop the servers - umount the chroots If I understand the manual correctly, after 0start.sh, the replica should be identical to the master thanks to -c rid=0 BUT, the log on the replica says: 534d5481 dn_callback : new entry is older than ours cn=config ours 20140415154713.807278Z#000000#000#000000, new 20140415154704.888204Z#000000#000#000000 and indeed, the seed entries are NOT overwritten I have to "touch" them on the master to force the replication. I have uploaded the scripts to http://jclain.fr/openldap-its/ thanks in advance

1 0

Re: (ITS#7839) openldap libdb5 support
by michael＠stroeder.com 17 Apr '14

17 Apr '14

hyc(a)symas.com wrote: > Further footnote - this is why we recommend nss-pam-ldapd or nssov, which > fully isolates applications from the underlying nss/pam libraries. And why we > don't recommend SSSD. A shame they had to go off and reinvent the wheel > without actually fixing its underlying problems. Some people never learn. Hmm. AFAICT sssd also isolates from the nss/pam libraries. The pam_sss and libnss_sss modules also communicate with sssd over a Unix domain socket just like the other demons and accompanying modules you prefer do. Ciao, Michael.

1 0

Re: (ITS#7839) openldap libdb5 support
by hyc＠symas.com 17 Apr '14

17 Apr '14

quanah(a)zimbra.com wrote: > --On Thursday, April 17, 2014 2:55 PM +0000 marc.schildt(a)idealo.de wrote: > >> Full_Name: Marc Schildt >> Version: 2.4.24 - 2.4.39 > > The OpenLDAP project is in no way associated with the utterly broken builds > provided by Debian. I would note that you cannot simply change the version > of BDB that OpenLDAP is linked to and expect your database to work. You > *must* slapcat your db using the old version of BDB, then upgrade openldap, > then import with slapdd into the new build of OpenLDAP with the newer BDB. > Nothing in your report specifically sounds like an issue with OpenLDAP > itself. > > I've been using OpenLDAP with BDB 5.2 for many years, no issue. This ITS > will be closed. As a footnote - you cannot have two versions of BDB linked into the same process and expect things to work. If changing the version of BDB that OpenLDAP is built with breaks SSSD, then you have a runtime linking problem, and again, that's something to take up with your distro. Not an OpenLDAP issue. Further footnote - this is why we recommend nss-pam-ldapd or nssov, which fully isolates applications from the underlying nss/pam libraries. And why we don't recommend SSSD. A shame they had to go off and reinvent the wheel without actually fixing its underlying problems. Some people never learn. -- -- 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#7839) openldap libdb5 support
by quanah＠zimbra.com 17 Apr '14

17 Apr '14

--On Thursday, April 17, 2014 2:55 PM +0000 marc.schildt(a)idealo.de wrote: > Full_Name: Marc Schildt > Version: 2.4.24 - 2.4.39 The OpenLDAP project is in no way associated with the utterly broken builds provided by Debian. I would note that you cannot simply change the version of BDB that OpenLDAP is linked to and expect your database to work. You *must* slapcat your db using the old version of BDB, then upgrade openldap, then import with slapdd into the new build of OpenLDAP with the newer BDB. Nothing in your report specifically sounds like an issue with OpenLDAP itself. I've been using OpenLDAP with BDB 5.2 for many years, no issue. This ITS will be closed. --Quanah -- Quanah Gibson-Mount Architect - Server Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7839) openldap libdb5 support
by marc.schildt＠idealo.de 17 Apr '14

17 Apr '14

Full_Name: Marc Schildt Version: 2.4.24 - 2.4.39 OS: Debian wheezy URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (212.162.49.126) Hello, we identified problems with the slapd version provided with debian wheezy. Our workstations are using sssd for auth against our openldap-server. The setup works well with slapd 2.4.23-7.3 on Debian squeeze. But, after building a new LDAP server on Debian wheezy, sssd stops working correctly and authentification of the workstations is not working anymore. Debian wheezy is using the slapd 2.4.31-1+nmu2. The following sssd versions we had tested with on different OS: sssd.x86_64 1.9.2-129.el6_5.4 @rhel-6-server-rpms sssd-client.x86_64 1.9.2-129.el6_5.4 @rhel-6-server-rpms sssd 1.8.6-0ubuntu0.3 We then tried to self compile openldap on debian wheezy (source from openldap.org). >From openldap2.4.39 down to 2.4.24 the built packages still did not work correctly with sssd. Reaching 2.4.23, the source won't compile anymore. So, after checking the change log, we saw that in 2.4.24 support for Berkley DB 5.1 was introduced in the source and for 2.4.23, db4.8 is needed. We have then compiled the Berkley DB 4.8 source from debian squeeze on debian wheezy and 2.4.23 was compiling cleanly. And, surprise, the combination of openldap and sssd was working as expected. After this success, we continued with a rebuild of openldap 2.4.31-1+nmu2 against the newly installed libdb4.8-dev libs. And again, we happily seeing openldap 2.4.31-1+nmu2 (built against libdb4.8) working like a charm together with sssd. So, maybe there is a major problem with libdb5 support introduced in openldap version 2.4.24 ? slapd.conf: # This is the main slapd configuration file. See slapd.conf(5) for more # info on the configuration options. ######################### # Global Directives # ######################### # Schema and objectClass definitions include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/samba.schema include /etc/ldap/schema/my.schema # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile /var/run/slapd/slapd.args # Where the dynamically loaded modules are stored modulepath /usr/lib/ldap moduleload back_hdb moduleload memberof moduleload refint # The maximum number of entries that is returned for a search operation sizelimit unlimited loglevel stats # The tool-threads parameter sets the actual amount of cpu's that is used # for indexing. tool-threads 1 # Global ACL's access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by * read ######################### # DB Directives # ######################### database hdb cachesize 20000 suffix "dc=example,dc=com" rootdn "cn=admin,dc=example,dc=com" rootpw {SSHA}123456 directory "/var/lib/ldap" checkpoint 1024 5 # INDEXING index default eq index objectClass,memberUid,uidNumber,gidNumber eq,pres index givenName,dc,displayName,distinguishedName eq,pres index cn,sn,mail,uid eq,pres,sub index member,memberOf,uniqueMember eq,pres # syncprov index entryUUID,entryCSN,ou eq index nisMapName,nisMapEntry eq,pres,sub # samba index sambaSID,sambaPrimaryGroupSID,sambaDomainName,sambaGroupType,sambaSIDList eq syncrepl rid="200" provider="ldaps://ldap-provider.example.com" searchbase="dc=example,dc=com" type="refreshAndPersist" retry="2 30 60 +" filter="objectClass=*" scope="sub" attrs="*,+" sizelimit="unlimited" timelimit="unlimited" binddn="cn=replicator.ldap-consumer2.example.com,dc=example,dc=com" bindmethod="simple" credentials="123456" tls_reqcert="allow" # DB ACL's access to * by dn.exact="cn=replicator.ldap-consumer2.example.com,dc=example,dc=com" write by * break limits dn.exact="cn=replicator.ldap-consumer2.example.com,dc=example,dc=com" size=unlimited time=unlimited access to attrs=sambaNTPassword by dn.exact="cn=sambaconnect,dc=example,dc=com" read by self write by * none limits dn.exact="cn=sambaconnect,dc=example,dc=com" size=unlimited time=unlimited access to attrs=userPassword,userPKCS12 by self write by * auth access to * by dn.exact="cn=accessuser,dc=example,dc=com" read by * break limits dn.exact="cn=accessuser,dc=example,dc=com" size=unlimited time=unlimited # Overlay Config overlay memberof memberof-refint true memberof-dangling error memberof-dn cn=memberof-overlay overlay refint refint_attributes member memberOf manager owner seeAlso refint_nothing cn=refinit.nothing,ou=system,dc=example,dc=com TLSCACertificateFile /etc/ldap/certs/ldap-ca.pem TLSCertificateFile /etc/ldap/certs/ldap-consumer2.example.com.pem TLSCertificateKeyFile /etc/ldap/certs/ldap-consumer2.example.com.key TLSVerifyClient allow sssd.conf: # # RESET SSS cache: # service sssd stop # rm /var/lib/sss/db/cache_* # service sssd start [sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = INTERN [nss] filter_groups = root filter_users = root reconnection_retries = 3 entry_cache_timeout = 300 entry_cache_nowait_percentage = 50 entry_negative_timeout = 15 [pam] reconnection_retries = 3 offline_credentials_expiration = 30 offline_failed_login_attempts = 0 offline_failed_login_delay = 5 [domain/LDAP] enumerate = true cache_credentials = true id_provider = ldap auth_provider = ldap chpass_provider = ldap ldap_uri = ldaps://ldap-consumer2.example.com ldap_search_base = dc=example,dc=com ldap_tls_reqcert = allow ldap_tls_cacert = /etc/ssl/certs/ldap-ca.pem slapd_sssd_request_succsess.log → slapd 2.4.23-7.3 / libdb 4.8.30-2: Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 fd=17 ACCEPT from IP=172.30.2.191:49845 (IP=0.0.0.0:636) Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 fd=17 TLS established tls_ssf=128 ssf=128 Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=0 SRCH attr=* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms defaultNamingContext lastUSN highestCommittedUSN Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=1 BIND dn="" method=128 Apr 15 17:43:45 ldap-slave slapd[1810]: slap_global_control: unrecognized control: 1.3.6.1.4.1.42.2.27.8.5.1 Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=1 RESULT tag=97 err=0 text= Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=2 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*))" Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=2 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=2 SEARCH RESULT tag=101 err=0 nentries=1000 text= Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*))" Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=3 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap Apr 15 17:43:45 ldap-slave slapd[1810]: conn=1001 op=3 SEARCH RESULT tag=101 err=0 nentries=181 text= Apr 15 17:43:46 ldap-slave slapd[1810]: conn=1001 op=4 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))" Apr 15 17:43:46 ldap-slave slapd[1810]: conn=1001 op=4 SRCH attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp modifyTimestamp Apr 15 17:43:46 ldap-slave slapd[1810]: conn=1001 op=4 SEARCH RESULT tag=101 err=0 nentries=253 text= Apr 15 17:43:48 ldap-slave slapd[1810]: conn=1001 op=5 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=ipService)(cn=*)(ipServicePort=*)(ipServiceProtocol=*))" Apr 15 17:43:48 ldap-slave slapd[1810]: conn=1001 op=5 SRCH attr=objectClass cn ipServicePort ipServiceProtocol modifyTimestamp Apr 15 17:43:48 ldap-slave slapd[1810]: conn=1001 op=5 SEARCH RESULT tag=101 err=0 nentries=0 text= Apr 15 17:43:58 ldap-slave slapd[1810]: conn=1001 op=6 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(uid=test.user)(objectClass=posixAccount))" Apr 15 17:43:58 ldap-slave slapd[1810]: conn=1001 op=6 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap Apr 15 17:43:58 ldap-slave slapd[1810]: conn=1001 op=6 SEARCH RESULT tag=101 err=0 nentries=1 text= Apr 15 17:43:58 ldap-slave slapd[1810]: conn=1001 op=7 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(memberUid=test.user)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))" Apr 15 17:43:58 ldap-slave slapd[1810]: conn=1001 op=7 SRCH attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp modifyTimestamp Apr 15 17:43:58 ldap-slave slapd[1810]: conn=1001 op=7 SEARCH RESULT tag=101 err=0 nentries=22 text= Apr 15 17:46:14 ldap-slave slapd[1810]: conn=1001 op=8 UNBIND Apr 15 17:46:14 ldap-slave slapd[1810]: conn=1001 fd=17 closed slapd_sssd_request_no_succsess.log → slapd 2.4.31-1+nmu2 / libdb 5.1.29-5: Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 fd=28 ACCEPT from IP=172.30.2.191:58270 (IP=0.0.0.0:636) Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 fd=28 TLS established tls_ssf=128 ssf=128 Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)" Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=0 SRCH attr=* altServer namingContexts supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms defaultNamingContext lastUSN highestCommittedUSN Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text= Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=1 BIND dn="" method=128 Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=1 RESULT tag=97 err=0 text= Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=2 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*))" Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=2 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=2 SEARCH RESULT tag=101 err=0 nentries=0 text= Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=3 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))" Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=3 SRCH attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp modifyTimestamp Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=3 SEARCH RESULT tag=101 err=0 nentries=0 text= Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=4 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(objectClass=ipService)(cn=*)(ipServicePort=*)(ipServiceProtocol=*))" Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=4 SRCH attr=objectClass cn ipServicePort ipServiceProtocol modifyTimestamp Apr 15 17:18:15 ldap-consumer2 slapd[16228]: conn=1116 op=4 SEARCH RESULT tag=101 err=0 nentries=0 text= Apr 15 17:18:37 ldap-consumer2 slapd[16228]: conn=1116 op=5 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(uid=test.user)(objectClass=posixAccount))" Apr 15 17:18:37 ldap-consumer2 slapd[16228]: conn=1116 op=5 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap Apr 15 17:18:37 ldap-consumer2 slapd[16228]: conn=1116 op=5 SEARCH RESULT tag=101 err=0 nentries=1 text= Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=6 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(gidNumber=20001)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))" Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=6 SRCH attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp modifyTimestamp Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=6 SEARCH RESULT tag=101 err=0 nentries=0 text= Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=7 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(uid=test.user)(objectClass=posixAccount))" Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=7 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn modifyTimestamp modifyTimestamp shadowLastChange shadowMin shadowMax shadowWarning shadowInactive shadowExpire shadowFlag krbLastPwdChange krbPasswordExpiration pwdAttribute authorizedService accountExpires userAccountControl nsAccountLock host loginDisabled loginExpirationTime loginAllowedTimeMap Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=7 SEARCH RESULT tag=101 err=0 nentries=1 text= Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=8 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(memberUid=test.user)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))" Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=8 SRCH attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp modifyTimestamp Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=8 SEARCH RESULT tag=101 err=0 nentries=0 text= Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=9 SRCH base="dc=example,dc=com" scope=2 deref=0 filter="(&(gidNumber=20001)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))" Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=9 SRCH attr=objectClass cn userPassword gidNumber memberuid modifyTimestamp modifyTimestamp Apr 15 17:18:38 ldap-consumer2 slapd[16228]: conn=1116 op=9 SEARCH RESULT tag=101 err=0 nentries=0 text= Apr 15 17:18:58 ldap-consumer2 slapd[16228]: conn=1116 op=10 UNBIND Apr 15 17:18:58 ldap-consumer2 slapd[16228]: conn=1116 fd=28 closed

1 0

Re: (ITS#7837) slapd seg faults in slapo-rwm
by michael＠stroeder.com 16 Apr '14

16 Apr '14

One more thing to note: We see some coincidence between the seg faults and situations where the load on the machine goes up and number of pending threads in back-monitor had values in the range of 16 to 22 (threads is 16 for four cores).

1 0

Re: (ITS#7837) slapd seg faults in slapo-rwm
by hyc＠symas.com 15 Apr '14

15 Apr '14

Michael Ströder wrote: > On Tue, 15 Apr 2014 04:35:26 -0700 Howard Chu <hyc(a)symas.com> wrote >> Can you run slapd with ElectricFence and post stack traces and diagnostics >> from any crashes there? > > Hmm, I will look into it. > But I'm a bit cautious running such a component in production. > Would running with MALLOC_CHECK_ be also reasonable helpful? Possibly using MALLOC_CHECK_=3 could give us a clue, yes. > > BTW: The configuration uses back-mdb. > > Another strange thing to note: > The archived syslog files revealed that the bind-DN rewriting is currently > *not* used by the LDAP clients at all. So I really wonder where it even calls > into slapo-rwm during normal operation. Good question. > > Ciao, Michael. > > > -- -- 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#7837) slapd seg faults in slapo-rwm
by michael＠stroeder.com 15 Apr '14

15 Apr '14

On Tue, 15 Apr 2014 04:35:26 -0700 Howard Chu <hyc(a)symas.com> wrote > Can you run slapd with ElectricFence and post stack traces and diagnostics > from any crashes there? Hmm, I will look into it. But I'm a bit cautious running such a component in production. Would running with MALLOC_CHECK_ be also reasonable helpful? BTW: The configuration uses back-mdb. Another strange thing to note: The archived syslog files revealed that the bind-DN rewriting is currently *not* used by the LDAP clients at all. So I really wonder where it even calls into slapo-rwm during normal operation. Ciao, Michael.

1 0

Re: (ITS#7838) add ORDERING matching rules to ppolicy attribute type descriptions
by michael＠stroeder.com 15 Apr '14

15 Apr '14

----==c72dbb1057ded1e9651a6f0c83ebf46f Content-Type: text/plain; charset=UTF-8; format=fixed Content-Transfer-Encoding: 8bit Attached a patch against git master. Hopefully I did not mess up the ppolicy.ldif with the wrapped lines. I, Michael Ströder, hereby place the attached 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. ----==c72dbb1057ded1e9651a6f0c83ebf46f Content-Type: text/x-patch; name="openldap-its-7838.patch" Content-Disposition: attachment; filename="openldap-its-7838.patch" Content-Transfer-Encoding: base64 ZGlmZiAtLWdpdCBhL3NlcnZlcnMvc2xhcGQvc2NoZW1hL3Bwb2xpY3kubGRpZiBiL3NlcnZlcnMv c2xhcGQvc2NoZW1hL3Bwb2xpY3kubGRpZgppbmRleCBiMmYzODY3Li5mYTEwYjg4IDEwMDY0NAot LS0gYS9zZXJ2ZXJzL3NsYXBkL3NjaGVtYS9wcG9saWN5LmxkaWYKKysrIGIvc2VydmVycy9zbGFw ZC9zY2hlbWEvcHBvbGljeS5sZGlmCkBAIC0zNSwyOCArMzUsMzcgQEAgY246IHBwb2xpY3kKIG9s Y0F0dHJpYnV0ZVR5cGVzOiB7MH0oIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjEgTkFNRSAncHdk QXR0cmlidXRlJyBFUVVBTElUWQogICBvYmplY3RJZGVudGlmaWVyTWF0Y2ggU1lOVEFYIDEuMy42 LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjM4ICkKIG9sY0F0dHJpYnV0ZVR5cGVzOiB7MX0oIDEuMy42 LjEuNC4xLjQyLjIuMjcuOC4xLjIgTkFNRSAncHdkTWluQWdlJyBFUVVBTElUWSBpbgotIHRlZ2Vy TWF0Y2ggU1lOVEFYIDEuMy42LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjI3IFNJTkdMRS1WQUxVRSAp CisgdGVnZXJNYXRjaCBPUkRFUklORyBpbnRlZ2VyT3JkZXJpbmdNYXRjaCBTWU5UQVggMS4zLjYu MS40LjEuMTQ2Ni4xMTUuMTIxLjEuMjcKKyAgU0lOR0xFLVZBTFVFICkKIG9sY0F0dHJpYnV0ZVR5 cGVzOiB7Mn0oIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjMgTkFNRSAncHdkTWF4QWdlJyBFUVVB TElUWSBpbgotIHRlZ2VyTWF0Y2ggU1lOVEFYIDEuMy42LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjI3 IFNJTkdMRS1WQUxVRSApCisgdGVnZXJNYXRjaCBPUkRFUklORyBpbnRlZ2VyT3JkZXJpbmdNYXRj aCBTWU5UQVggMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMTIxLjEuMjcKKyAgU0lOR0xFLVZBTFVFICkK IG9sY0F0dHJpYnV0ZVR5cGVzOiB7M30oIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjQgTkFNRSAn cHdkSW5IaXN0b3J5JyBFUVVBTElUWQotICBpbnRlZ2VyTWF0Y2ggU1lOVEFYIDEuMy42LjEuNC4x LjE0NjYuMTE1LjEyMS4xLjI3IFNJTkdMRS1WQUxVRSApCisgIGludGVnZXJNYXRjaCBPUkRFUklO RyBpbnRlZ2VyT3JkZXJpbmdNYXRjaCBTWU5UQVggMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMTIxLjEK KyAgLjI3IFNJTkdMRS1WQUxVRSApCiBvbGNBdHRyaWJ1dGVUeXBlczogezR9KCAxLjMuNi4xLjQu MS40Mi4yLjI3LjguMS41IE5BTUUgJ3B3ZENoZWNrUXVhbGl0eScgRVFVQUwKLSBJVFkgaW50ZWdl ck1hdGNoIFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4yNyBTSU5HTEUtVkFMVUUg KQorIElUWSBpbnRlZ2VyTWF0Y2ggT1JERVJJTkcgaW50ZWdlck9yZGVyaW5nTWF0Y2ggU1lOVEFY IDEuMy42LjEuNC4xLjE0NjYuMTE1LjEyCisgMS4xLjI3IFNJTkdMRS1WQUxVRSApCiBvbGNBdHRy aWJ1dGVUeXBlczogezV9KCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS42IE5BTUUgJ3B3ZE1pbkxl bmd0aCcgRVFVQUxJVFkKLSAgaW50ZWdlck1hdGNoIFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjEx NS4xMjEuMS4yNyBTSU5HTEUtVkFMVUUgKQorICBpbnRlZ2VyTWF0Y2ggT1JERVJJTkcgaW50ZWdl ck9yZGVyaW5nTWF0Y2ggIFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuCisgIDEuMjcg U0lOR0xFLVZBTFVFICkKIG9sY0F0dHJpYnV0ZVR5cGVzOiB7Nn0oIDEuMy42LjEuNC4xLjQyLjIu MjcuOC4xLjcgTkFNRSAncHdkRXhwaXJlV2FybmluZycgRVFVQQotIExJVFkgaW50ZWdlck1hdGNo IFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4yNyBTSU5HTEUtVkFMVUUgKQorIExJ VFkgaW50ZWdlck1hdGNoIE9SREVSSU5HIGludGVnZXJPcmRlcmluZ01hdGNoICBTWU5UQVggMS4z LjYuMS40LjEuMTQ2Ni4xMTUuCisgMTIxLjEuMjcgU0lOR0xFLVZBTFVFICkKIG9sY0F0dHJpYnV0 ZVR5cGVzOiB7N30oIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjggTkFNRSAncHdkR3JhY2VBdXRo TkxpbWl0JyBFUQotIFVBTElUWSBpbnRlZ2VyTWF0Y2ggU1lOVEFYIDEuMy42LjEuNC4xLjE0NjYu MTE1LjEyMS4xLjI3IFNJTkdMRS1WQUxVRSApCisgVUFMSVRZIGludGVnZXJNYXRjaCBPUkRFUklO RyBpbnRlZ2VyT3JkZXJpbmdNYXRjaCAgU1lOVEFYIDEuMy42LjEuNC4xLjE0NjYuMTEKKyA1LjEy MS4xLjI3IFNJTkdMRS1WQUxVRSApCiBvbGNBdHRyaWJ1dGVUeXBlczogezh9KCAxLjMuNi4xLjQu MS40Mi4yLjI3LjguMS45IE5BTUUgJ3B3ZExvY2tvdXQnIEVRVUFMSVRZIGIKICBvb2xlYW5NYXRj aCBTWU5UQVggMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMTIxLjEuNyBTSU5HTEUtVkFMVUUgKQogb2xj QXR0cmlidXRlVHlwZXM6IHs5fSggMS4zLjYuMS40LjEuNDIuMi4yNy44LjEuMTAgTkFNRSAncHdk TG9ja291dER1cmF0aW9uJyBFCi0gUVVBTElUWSBpbnRlZ2VyTWF0Y2ggU1lOVEFYIDEuMy42LjEu NC4xLjE0NjYuMTE1LjEyMS4xLjI3IFNJTkdMRS1WQUxVRSApCisgUVVBTElUWSBpbnRlZ2VyTWF0 Y2ggT1JERVJJTkcgaW50ZWdlck9yZGVyaW5nTWF0Y2ggIFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2 LjEKKyAxNS4xMjEuMS4yNyBTSU5HTEUtVkFMVUUgKQogb2xjQXR0cmlidXRlVHlwZXM6IHsxMH0o IDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjExIE5BTUUgJ3B3ZE1heEZhaWx1cmUnIEVRVUFMCi0g SVRZIGludGVnZXJNYXRjaCBTWU5UQVggMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMTIxLjEuMjcgU0lO R0xFLVZBTFVFICkKKyBJVFkgaW50ZWdlck1hdGNoIE9SREVSSU5HIGludGVnZXJPcmRlcmluZ01h dGNoICBTWU5UQVggMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMQorIDIxLjEuMjcgU0lOR0xFLVZBTFVF ICkKIG9sY0F0dHJpYnV0ZVR5cGVzOiB7MTF9KCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS4xMiBO QU1FICdwd2RGYWlsdXJlQ291bnRJbnRlcgotIHZhbCcgRVFVQUxJVFkgaW50ZWdlck1hdGNoIFNZ TlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4yNyBTSU5HTEUtVkFMVUUgCi0gKQorIHZh bCcgRVFVQUxJVFkgaW50ZWdlck1hdGNoIE9SREVSSU5HIGludGVnZXJPcmRlcmluZ01hdGNoICBT WU5UQVggMS4zLjYuMS40LjEuCisgMTQ2Ni4xMTUuMTIxLjEuMjcgU0lOR0xFLVZBTFVFICkKIG9s Y0F0dHJpYnV0ZVR5cGVzOiB7MTJ9KCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS4xMyBOQU1FICdw d2RNdXN0Q2hhbmdlJyBFUVVBTAogIElUWSBib29sZWFuTWF0Y2ggU1lOVEFYIDEuMy42LjEuNC4x LjE0NjYuMTE1LjEyMS4xLjcgU0lOR0xFLVZBTFVFICkKIG9sY0F0dHJpYnV0ZVR5cGVzOiB7MTN9 KCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS4xNCBOQU1FICdwd2RBbGxvd1VzZXJDaGFuZ2UnIApk aWZmIC0tZ2l0IGEvc2VydmVycy9zbGFwZC9zY2hlbWEvcHBvbGljeS5zY2hlbWEgYi9zZXJ2ZXJz L3NsYXBkL3NjaGVtYS9wcG9saWN5LnNjaGVtYQppbmRleCA2YzVmYjcwLi5hYjE1NTgzIDEwMDY0 NAotLS0gYS9zZXJ2ZXJzL3NsYXBkL3NjaGVtYS9wcG9saWN5LnNjaGVtYQorKysgYi9zZXJ2ZXJz L3NsYXBkL3NjaGVtYS9wcG9saWN5LnNjaGVtYQpAQCAtMTEwLDYgKzExMCw3IEBAIGF0dHJpYnV0 ZXR5cGUgKCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS4xCiBhdHRyaWJ1dGV0eXBlICggMS4zLjYu MS40LjEuNDIuMi4yNy44LjEuMgogICAgICAgTkFNRSAncHdkTWluQWdlJwogICAgICAgRVFVQUxJ VFkgaW50ZWdlck1hdGNoCisgICAgICBPUkRFUklORyBpbnRlZ2VyT3JkZXJpbmdNYXRjaAogICAg ICAgU1lOVEFYIDEuMy42LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjI3CiAgICAgICBTSU5HTEUtVkFM VUUgKQogCkBAIC0xMjUsNiArMTI2LDcgQEAgYXR0cmlidXRldHlwZSAoIDEuMy42LjEuNC4xLjQy LjIuMjcuOC4xLjIKIGF0dHJpYnV0ZXR5cGUgKCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS4zCiAg ICAgICBOQU1FICdwd2RNYXhBZ2UnCiAgICAgICBFUVVBTElUWSBpbnRlZ2VyTWF0Y2gKKyAgICAg IE9SREVSSU5HIGludGVnZXJPcmRlcmluZ01hdGNoCiAgICAgICBTWU5UQVggMS4zLjYuMS40LjEu MTQ2Ni4xMTUuMTIxLjEuMjcKICAgICAgIFNJTkdMRS1WQUxVRSApCiAKQEAgLTE0MCw2ICsxNDIs NyBAQCBhdHRyaWJ1dGV0eXBlICggMS4zLjYuMS40LjEuNDIuMi4yNy44LjEuMwogYXR0cmlidXRl dHlwZSAoIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjQKICAgICAgIE5BTUUgJ3B3ZEluSGlzdG9y eScKICAgICAgIEVRVUFMSVRZIGludGVnZXJNYXRjaAorICAgICAgT1JERVJJTkcgaW50ZWdlck9y ZGVyaW5nTWF0Y2gKICAgICAgIFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4yNwog ICAgICAgU0lOR0xFLVZBTFVFICkKIApAQCAtMTY2LDYgKzE2OSw3IEBAIGF0dHJpYnV0ZXR5cGUg KCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS40CiBhdHRyaWJ1dGV0eXBlICggMS4zLjYuMS40LjEu NDIuMi4yNy44LjEuNQogICAgICAgTkFNRSAncHdkQ2hlY2tRdWFsaXR5JwogICAgICAgRVFVQUxJ VFkgaW50ZWdlck1hdGNoCisgICAgICBPUkRFUklORyBpbnRlZ2VyT3JkZXJpbmdNYXRjaAogICAg ICAgU1lOVEFYIDEuMy42LjEuNC4xLjE0NjYuMTE1LjEyMS4xLjI3CiAgICAgICBTSU5HTEUtVkFM VUUgKQogCkBAIC0xODIsNiArMTg2LDcgQEAgYXR0cmlidXRldHlwZSAoIDEuMy42LjEuNC4xLjQy LjIuMjcuOC4xLjUKIGF0dHJpYnV0ZXR5cGUgKCAxLjMuNi4xLjQuMS40Mi4yLjI3LjguMS42CiAg ICAgICBOQU1FICdwd2RNaW5MZW5ndGgnCiAgICAgICBFUVVBTElUWSBpbnRlZ2VyTWF0Y2gKKyAg ICAgIE9SREVSSU5HIGludGVnZXJPcmRlcmluZ01hdGNoCiAgICAgICBTWU5UQVggMS4zLjYuMS40 LjEuMTQ2Ni4xMTUuMTIxLjEuMjcKICAgICAgIFNJTkdMRS1WQUxVRSApCiAKQEAgLTE5OCw2ICsy MDMsNyBAQCBhdHRyaWJ1dGV0eXBlICggMS4zLjYuMS40LjEuNDIuMi4yNy44LjEuNgogYXR0cmli dXRldHlwZSAoIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjcKICAgICAgIE5BTUUgJ3B3ZEV4cGly ZVdhcm5pbmcnCiAgICAgICBFUVVBTElUWSBpbnRlZ2VyTWF0Y2gKKyAgICAgIE9SREVSSU5HIGlu dGVnZXJPcmRlcmluZ01hdGNoCiAgICAgICBTWU5UQVggMS4zLjYuMS40LjEuMTQ2Ni4xMTUuMTIx LjEuMjcKICAgICAgIFNJTkdMRS1WQUxVRSApCiAKQEAgLTIxMCw2ICsyMTYsNyBAQCBhdHRyaWJ1 dGV0eXBlICggMS4zLjYuMS40LjEuNDIuMi4yNy44LjEuNwogYXR0cmlidXRldHlwZSAoIDEuMy42 LjEuNC4xLjQyLjIuMjcuOC4xLjgKICAgICAgIE5BTUUgJ3B3ZEdyYWNlQXV0aE5MaW1pdCcKICAg ICAgIEVRVUFMSVRZIGludGVnZXJNYXRjaAorICAgICAgT1JERVJJTkcgaW50ZWdlck9yZGVyaW5n TWF0Y2gKICAgICAgIFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4yNwogICAgICAg U0lOR0xFLVZBTFVFICkKIApAQCAtMjQxLDYgKzI0OCw3IEBAIGF0dHJpYnV0ZXR5cGUgKCAxLjMu Ni4xLjQuMS40Mi4yLjI3LjguMS45CiBhdHRyaWJ1dGV0eXBlICggMS4zLjYuMS40LjEuNDIuMi4y Ny44LjEuMTAKICAgICAgIE5BTUUgJ3B3ZExvY2tvdXREdXJhdGlvbicKICAgICAgIEVRVUFMSVRZ IGludGVnZXJNYXRjaAorICAgICAgT1JERVJJTkcgaW50ZWdlck9yZGVyaW5nTWF0Y2gKICAgICAg IFNZTlRBWCAxLjMuNi4xLjQuMS4xNDY2LjExNS4xMjEuMS4yNwogICAgICAgU0lOR0xFLVZBTFVF ICkKIApAQCAtMjU0LDYgKzI2Miw3IEBAIGF0dHJpYnV0ZXR5cGUgKCAxLjMuNi4xLjQuMS40Mi4y LjI3LjguMS4xMAogYXR0cmlidXRldHlwZSAoIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjExCiAg ICAgICBOQU1FICdwd2RNYXhGYWlsdXJlJwogICAgICAgRVFVQUxJVFkgaW50ZWdlck1hdGNoCisg ICAgICBPUkRFUklORyBpbnRlZ2VyT3JkZXJpbmdNYXRjaAogICAgICAgU1lOVEFYIDEuMy42LjEu NC4xLjE0NjYuMTE1LjEyMS4xLjI3CiAgICAgICBTSU5HTEUtVkFMVUUgKQogCkBAIC0yNjksNiAr Mjc4LDcgQEAgYXR0cmlidXRldHlwZSAoIDEuMy42LjEuNC4xLjQyLjIuMjcuOC4xLjExCiBhdHRy aWJ1dGV0eXBlICggMS4zLjYuMS40LjEuNDIuMi4yNy44LjEuMTIKICAgICAgIE5BTUUgJ3B3ZEZh aWx1cmVDb3VudEludGVydmFsJwogICAgICAgRVFVQUxJVFkgaW50ZWdlck1hdGNoCisgICAgICBP UkRFUklORyBpbnRlZ2VyT3JkZXJpbmdNYXRjaAogICAgICAgU1lOVEFYIDEuMy42LjEuNC4xLjE0 NjYuMTE1LjEyMS4xLjI3CiAgICAgICBTSU5HTEUtVkFMVUUgKQogCg== ----==c72dbb1057ded1e9651a6f0c83ebf46f--

1 0

(ITS#7838) add ORDERING matching rules to ppolicy attribute type descriptions
by michael＠stroeder.com 15 Apr '14

15 Apr '14

Full_Name: Version: HEAD and RE24 OS: URL: Submission from: (NULL) (212.227.35.93) For search pwdPolicy entries with certain parameters it would be handy to be able to search e.g. with (pwdMaxAge>=1). Therefore ORDERING integerOrderingMatch should be added to all Integer attribute types in ppolicy.schema and ppolicy.ldif.

1 0

Re: (ITS#7837) slapd seg faults in slapo-rwm
by hyc＠symas.com 15 Apr '14

15 Apr '14

Michael Ströder wrote: > hyc(a)symas.com wrote: >>> slapd occasionally seg faults. >>> We can't reproduce it with a certain configuration. >>> >>> This is a custom Debian Wheezy package based on OpenLDAP 2.4.39 >>> linked against OpenSSL under a separate prefix. >>> >>> slapo-rwm is patched according to ITS#7723 but I can't tell whether >>> it's related to ITS#7723 or not. Hence the separate ITS. >> >> What behavior do you get by reverting the #7723 patch? > > The patch was applied because we had these seg faults before. > I'd rather say nothing changed in our case with the patch. > Crashes happen once or twice a week or so. > Also it was impossible to crash the non-patched installation with a test > script acting like described in ITS#7723. > > Fixing this would be highly appreciated but I can't provide a simple config > reproducing it. Can you run slapd with ElectricFence and post stack traces and diagnostics from any crashes there? > > The following rwm directives are in the frontend part: > > overlay rwm > rwm-rewriteEngine on > rwm-drop-unrequested-attrs no > # uid=foo,ou=xxxxx -> entryDN of entry within ou=xxxxx matching (uid=foo) > rwm-rewriteMap slapd uid2dn "ldap:///ou=xxxxx?entryDN?sub?" > rwm-rewriteContext bindDN > rwm-rewriteRule "^(uid=[^,]+),ou=xxxxx$" "${uid2dn($1)}" ":@I" > # serverFqdn=foo,ou=xxxxx -> entryDN of entry within ou=xxxxx matching > (serverFqdn=foo) > rwm-rewriteMap slapd fqdn2dn "ldap:///ou=xxxxx?entryDN?sub?" > rwm-rewriteContext bindDN > rwm-rewriteRule "^(serverFqdn=[^,]+),ou=xxxxx$" "${fqdn2dn($1)}" ":@I" > > In a former configuration version these directives were in the backend > ou=xxxxx part. Because of the seg faults I moved it which made things slightly > better but hard to tell. In another configuration variant I even experienced > seg faults with *slapcat*. > > This is a two-layer replication topology with several MMR providers and > read-only consumers which use SASL/EXTERNAL with client certs for > authentication and authz-regexp mapping to authz-DNs. If things are wrong > during consumer initialization sometimes even the providers crashes. > > Ciao, Michael. > -- -- 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#7837) slapd seg faults in slapo-rwm
by michael＠stroeder.com 14 Apr '14

14 Apr '14

hyc(a)symas.com wrote: >> slapd occasionally seg faults. >> We can't reproduce it with a certain configuration. >> >> This is a custom Debian Wheezy package based on OpenLDAP 2.4.39 >> linked against OpenSSL under a separate prefix. >> >> slapo-rwm is patched according to ITS#7723 but I can't tell whether >> it's related to ITS#7723 or not. Hence the separate ITS. > > What behavior do you get by reverting the #7723 patch? The patch was applied because we had these seg faults before. I'd rather say nothing changed in our case with the patch. Crashes happen once or twice a week or so. Also it was impossible to crash the non-patched installation with a test script acting like described in ITS#7723. Fixing this would be highly appreciated but I can't provide a simple config reproducing it. The following rwm directives are in the frontend part: overlay rwm rwm-rewriteEngine on rwm-drop-unrequested-attrs no # uid=foo,ou=xxxxx -> entryDN of entry within ou=xxxxx matching (uid=foo) rwm-rewriteMap slapd uid2dn "ldap:///ou=xxxxx?entryDN?sub?" rwm-rewriteContext bindDN rwm-rewriteRule "^(uid=[^,]+),ou=xxxxx$" "${uid2dn($1)}" ":@I" # serverFqdn=foo,ou=xxxxx -> entryDN of entry within ou=xxxxx matching (serverFqdn=foo) rwm-rewriteMap slapd fqdn2dn "ldap:///ou=xxxxx?entryDN?sub?" rwm-rewriteContext bindDN rwm-rewriteRule "^(serverFqdn=[^,]+),ou=xxxxx$" "${fqdn2dn($1)}" ":@I" In a former configuration version these directives were in the backend ou=xxxxx part. Because of the seg faults I moved it which made things slightly better but hard to tell. In another configuration variant I even experienced seg faults with *slapcat*. This is a two-layer replication topology with several MMR providers and read-only consumers which use SASL/EXTERNAL with client certs for authentication and authz-regexp mapping to authz-DNs. If things are wrong during consumer initialization sometimes even the providers crashes. Ciao, Michael.

1 0

Re: (ITS#7837) slapd seg faults in slapo-rwm
by hyc＠symas.com 14 Apr '14

14 Apr '14

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: 2.4.39 with patches > OS: > URL: > Submission from: (NULL) (212.227.35.93) > > > slapd occasionally seg faults. > We can't reproduce it with a certain configuration. > > This is a custom Debian Wheezy package based on OpenLDAP 2.4.39 > linked against OpenSSL under a separate prefix. > > slapo-rwm is patched according to ITS#7723 but I can't tell whether > it's related to ITS#7723 or not. Hence the separate ITS. What behavior do you get by reverting the #7723 patch? > > master commit for the reference counting patch used: > http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commit;h=5f524c44… > > Here's the stack trace (obfuscated filter and search base): > > Program terminated with signal 11, Segmentation fault. > #0 0x00007f8ca2d8a29d in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > (gdb) bt full > #0 0x00007f8ca2d8a29d in ?? () from /lib/x86_64-linux-gnu/libc.so.6 > No symbol table info available. > #1 0x00000000004f776b in rewrite_var_cmp (c1=0x7f8abaffb680, c2=0x7f8a884fba80) > at var.c:43 > v1 = 0x7f8abaffb680 > v2 = 0x7f8a884fba80 > __PRETTY_FUNCTION__ = "rewrite_var_cmp" > #2 0x0000000000500920 in avl_find (root=0x7f8a892823b0, data=0x7f8abaffb680, > fcmp=0x4f76a8 <rewrite_var_cmp>) at avl.c:545 > cmp = 0 > #3 0x00000000004f797e in rewrite_var_find (tree=0x7f8a892823b0, > name=0x7f8c9ff4b319 "searchFilter") at var.c:115 > var = {lv_name = 0x7f8c9ff4b319 "searchFilter", lv_flags = -1534643252, > lv_value = {bv_len = 140233568059984, bv_val = 0x7f8a89523fa0 ""}} > __PRETTY_FUNCTION__ = "rewrite_var_find" > #4 0x00000000004f5f51 in rewrite_session_var_set_f (info=0x1b4f770, > cookie=0x7f8c9fee2510, name=0x7f8c9ff4b319 "searchFilter", > value=0x7f8aac1d93a0 > "(&(member=uid=xxxxx,cn=yyyyy,ou=zzzzz)(objectClass=posixGroup)(cn=*))", > flags=15) at session.c:222 > session = 0x7f8a89523f90 > var = 0x1ffb > __PRETTY_FUNCTION__ = "rewrite_session_var_set_f" > #5 0x00007f8c9ff41836 in rwm_op_search (op=0x7f8aadb03a70, rs=0x7f8abaffcac0) > at rwm.c:955 > on = 0x1b4f530 > rwmap = 0x1b4f710 > rc = 32652 > dc = {rwmap = 0x7f8abaffb960, conn = 0x0, ctx = 0xffffffffffffffa8 > <Address 0xffffffffffffffa8 out of bounds>, rs = 0x2e90e50} > fstr = {bv_len = 0, bv_val = 0x0} > f = 0x0 > an = 0x0 > text = 0x0 > roc = 0x7f8aac1d95e8 > #6 0x00000000004cf13b in overlay_op_walk (op=0x7f8aadb03a70, rs=0x7f8abaffcac0, > which=op_search, oi=0x1b4d270, on=0x1b4f530) at backover.c:661 > func = 0x1b4f588 > rc = 32768 > #7 0x00000000004cf3ef in over_op_func (op=0x7f8aadb03a70, rs=0x7f8abaffcac0, > which=op_search) at backover.c:723 > oi = 0x1b4d270 > on = 0x1b4f530 > be = 0x772340 > db = {bd_info = 0x1b4f530, bd_self = 0x772340, be_ctrls = "\000", '\001' > <repeats 16 times>, '\000' <repeats 15 times>, be_flags = 131840, be_restrictops > = 0, be_requires = 19, be_ssf_set = { > sss_ssf = 128, sss_transport = 0, sss_tls = 0, sss_sasl = 0, > sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, > sss_update_sasl = 0, sss_simple_bind = 0}, > be_suffix = 0x1acae40, be_nsuffix = 0x1acae90, be_schemadn = {bv_len = > 12, bv_val = 0x1ba32d0 "cn=Subschema"}, be_schemandn = {bv_len = 12, bv_val = > 0x1ba2c80 "cn=subschema"}, be_rootdn = { > bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0}, > be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 0, be_def_limit = > {lms_t_soft = 3600, lms_t_hard = 0, > lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = > 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x1b54bd0, > be_dfltaccess = ACL_READ, > be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, > be_update_refs = 0x0, be_pending_csn_list = 0x0, be_pcl_mutex = {__data = > {__lock = 0, __count = 0, __owner = 0, __nusers = 0, > __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, > __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = > 0x0, be_cf_ocs = 0x768e88, be_private = 0x0, > be_next = {stqe_next = 0x1acaee0}} > cb = {sc_next = 0x0, sc_response = 0x4ce266 <over_back_response>, > sc_cleanup = 0, sc_private = 0x1b4d270} > sc = 0x7f8aac1d9578 > rc = 32768 > __PRETTY_FUNCTION__ = "over_op_func" > #8 0x00000000004cf4cf in over_op_search (op=0x7f8aadb03a70, rs=0x7f8abaffcac0) > at backover.c:750 > No locals. > #9 0x0000000000440982 in do_search (op=0x7f8aadb03a70, rs=0x7f8abaffcac0) at > search.c:247 > base = {bv_len = 8, bv_val = 0x7f8a8801d589 "ou=zzzzz"} > siz = 7 > off = 0 > i = 7 > #10 0x000000000043d2da in connection_operation (ctx=0x7f8abaffcba0, > arg_v=0x7f8aadb03a70) at connection.c:1155 > rc = 80 > cancel = 32650 > op = 0x7f8aadb03a70 > rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, > sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = > {sru_search = {r_entry = 0x0, r_attr_flags = 0, > r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref > = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata > = 0x0}}, sr_flags = 0} > tag = 99 > opidx = SLAP_OP_SEARCH > conn = 0x7f8c9fee2510 > memctx = 0x7f8aac028250 > memctx_null = 0x0 > memsiz = 1048576 > __PRETTY_FUNCTION__ = "connection_operation" > #11 0x00007f8ca4871c81 in ldap_int_thread_pool_wrapper (xpool=0x1aa7f70) at > tpool.c:688 > pool = 0x1aa7f70 > task = 0x7f8aa57bb7a0 > work_list = 0x1aa8008 > ctx = {ltu_id = 140233819543296, ltu_key = {{ltk_key = 0x43ce31, > ltk_data = 0x7f8aac028140, ltk_free = 0x43cc83 <conn_counter_destroy>}, {ltk_key > = 0x4af7af, ltk_data = 0x7f8aac028250, > ltk_free = 0x4af5d4 <slap_sl_mem_destroy>}, {ltk_key = 0x1c58fc0, > ltk_data = 0x7f8aac024fb0, ltk_free = 0x7f8ca15c4122 <mdb_reader_free>}, > {ltk_key = 0x7f8ca15b6b94, > ltk_data = 0x7f8a9f0f7010, ltk_free = 0x7f8ca15b6b4c > <scope_chunk_free>}, {ltk_key = 0x457c69, ltk_data = 0x7f8a88063040, ltk_free = > 0x457bbc <slap_op_q_destroy>}, { > ltk_key = 0x7f8ca15b9a39, ltk_data = 0x7f8a94be7010, ltk_free = > 0x7f8ca15b9a16 <search_stack_free>}, {ltk_key = 0x1c67c80, ltk_data = > 0x7f8ab46aadb0, > ltk_free = 0x7f8ca15c4122 <mdb_reader_free>}, {ltk_key = 0x0, > ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} > kctx = 0x0 > ---Type <return> to continue, or q <return> to quit--- > i = 32 > keyslot = 377 > hash = 3746453881 > __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" > #12 0x00007f8ca2feab50 in start_thread () from > /lib/x86_64-linux-gnu/libpthread.so.0 > No symbol table info available. > #13 0x00007f8ca2d350ed in clone () from /lib/x86_64-linux-gnu/libc.so.6 > No symbol table info available. > #14 0x0000000000000000 in ?? () > No symbol table info available. > > -- -- 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#7837) slapd seg faults in slapo-rwm
by michael＠stroeder.com 14 Apr '14

14 Apr '14

Full_Name: Michael Ströder Version: 2.4.39 with patches OS: URL: Submission from: (NULL) (212.227.35.93) slapd occasionally seg faults. We can't reproduce it with a certain configuration. This is a custom Debian Wheezy package based on OpenLDAP 2.4.39 linked against OpenSSL under a separate prefix. slapo-rwm is patched according to ITS#7723 but I can't tell whether it's related to ITS#7723 or not. Hence the separate ITS. master commit for the reference counting patch used: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commit;h=5f524c44… Here's the stack trace (obfuscated filter and search base): Program terminated with signal 11, Segmentation fault. #0 0x00007f8ca2d8a29d in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt full #0 0x00007f8ca2d8a29d in ?? () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #1 0x00000000004f776b in rewrite_var_cmp (c1=0x7f8abaffb680, c2=0x7f8a884fba80) at var.c:43 v1 = 0x7f8abaffb680 v2 = 0x7f8a884fba80 __PRETTY_FUNCTION__ = "rewrite_var_cmp" #2 0x0000000000500920 in avl_find (root=0x7f8a892823b0, data=0x7f8abaffb680, fcmp=0x4f76a8 <rewrite_var_cmp>) at avl.c:545 cmp = 0 #3 0x00000000004f797e in rewrite_var_find (tree=0x7f8a892823b0, name=0x7f8c9ff4b319 "searchFilter") at var.c:115 var = {lv_name = 0x7f8c9ff4b319 "searchFilter", lv_flags = -1534643252, lv_value = {bv_len = 140233568059984, bv_val = 0x7f8a89523fa0 ""}} __PRETTY_FUNCTION__ = "rewrite_var_find" #4 0x00000000004f5f51 in rewrite_session_var_set_f (info=0x1b4f770, cookie=0x7f8c9fee2510, name=0x7f8c9ff4b319 "searchFilter", value=0x7f8aac1d93a0 "(&(member=uid=xxxxx,cn=yyyyy,ou=zzzzz)(objectClass=posixGroup)(cn=*))", flags=15) at session.c:222 session = 0x7f8a89523f90 var = 0x1ffb __PRETTY_FUNCTION__ = "rewrite_session_var_set_f" #5 0x00007f8c9ff41836 in rwm_op_search (op=0x7f8aadb03a70, rs=0x7f8abaffcac0) at rwm.c:955 on = 0x1b4f530 rwmap = 0x1b4f710 rc = 32652 dc = {rwmap = 0x7f8abaffb960, conn = 0x0, ctx = 0xffffffffffffffa8 <Address 0xffffffffffffffa8 out of bounds>, rs = 0x2e90e50} fstr = {bv_len = 0, bv_val = 0x0} f = 0x0 an = 0x0 text = 0x0 roc = 0x7f8aac1d95e8 #6 0x00000000004cf13b in overlay_op_walk (op=0x7f8aadb03a70, rs=0x7f8abaffcac0, which=op_search, oi=0x1b4d270, on=0x1b4f530) at backover.c:661 func = 0x1b4f588 rc = 32768 #7 0x00000000004cf3ef in over_op_func (op=0x7f8aadb03a70, rs=0x7f8abaffcac0, which=op_search) at backover.c:723 oi = 0x1b4d270 on = 0x1b4f530 be = 0x772340 db = {bd_info = 0x1b4f530, bd_self = 0x772340, be_ctrls = "\000", '\001' <repeats 16 times>, '\000' <repeats 15 times>, be_flags = 131840, be_restrictops = 0, be_requires = 19, be_ssf_set = { sss_ssf = 128, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x1acae40, be_nsuffix = 0x1acae90, be_schemadn = {bv_len = 12, bv_val = 0x1ba32d0 "cn=Subschema"}, be_schemandn = {bv_len = 12, bv_val = 0x1ba2c80 "cn=subschema"}, be_rootdn = { bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 0, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x1b54bd0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x768e88, be_private = 0x0, be_next = {stqe_next = 0x1acaee0}} cb = {sc_next = 0x0, sc_response = 0x4ce266 <over_back_response>, sc_cleanup = 0, sc_private = 0x1b4d270} sc = 0x7f8aac1d9578 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #8 0x00000000004cf4cf in over_op_search (op=0x7f8aadb03a70, rs=0x7f8abaffcac0) at backover.c:750 No locals. #9 0x0000000000440982 in do_search (op=0x7f8aadb03a70, rs=0x7f8abaffcac0) at search.c:247 base = {bv_len = 8, bv_val = 0x7f8a8801d589 "ou=zzzzz"} siz = 7 off = 0 i = 7 #10 0x000000000043d2da in connection_operation (ctx=0x7f8abaffcba0, arg_v=0x7f8aadb03a70) at connection.c:1155 rc = 80 cancel = 32650 op = 0x7f8aadb03a70 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x7f8c9fee2510 memctx = 0x7f8aac028250 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #11 0x00007f8ca4871c81 in ldap_int_thread_pool_wrapper (xpool=0x1aa7f70) at tpool.c:688 pool = 0x1aa7f70 task = 0x7f8aa57bb7a0 work_list = 0x1aa8008 ctx = {ltu_id = 140233819543296, ltu_key = {{ltk_key = 0x43ce31, ltk_data = 0x7f8aac028140, ltk_free = 0x43cc83 <conn_counter_destroy>}, {ltk_key = 0x4af7af, ltk_data = 0x7f8aac028250, ltk_free = 0x4af5d4 <slap_sl_mem_destroy>}, {ltk_key = 0x1c58fc0, ltk_data = 0x7f8aac024fb0, ltk_free = 0x7f8ca15c4122 <mdb_reader_free>}, {ltk_key = 0x7f8ca15b6b94, ltk_data = 0x7f8a9f0f7010, ltk_free = 0x7f8ca15b6b4c <scope_chunk_free>}, {ltk_key = 0x457c69, ltk_data = 0x7f8a88063040, ltk_free = 0x457bbc <slap_op_q_destroy>}, { ltk_key = 0x7f8ca15b9a39, ltk_data = 0x7f8a94be7010, ltk_free = 0x7f8ca15b9a16 <search_stack_free>}, {ltk_key = 0x1c67c80, ltk_data = 0x7f8ab46aadb0, ltk_free = 0x7f8ca15c4122 <mdb_reader_free>}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = 0x0 ---Type <return> to continue, or q <return> to quit--- i = 32 keyslot = 377 hash = 3746453881 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #12 0x00007f8ca2feab50 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 No symbol table info available. #13 0x00007f8ca2d350ed in clone () from /lib/x86_64-linux-gnu/libc.so.6 No symbol table info available. #14 0x0000000000000000 in ?? () No symbol table info available.

1 0

(ITS#7836) Incorrect behavior with problematic LDAP server
by tarkhil＠over.ru 13 Apr '14

13 Apr '14

Full_Name: Alex Povolotsky Version: 2.4.36 OS: FreeBSD 9.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.178.228.111) Hello I'm using failover setup for my LDAP authentication === ldap.conf === BASE dc=org,dc=ru URI ldap://serv1 ldap://serv2 TIMEOUT 3 NETWORK_TIMEOUT 3 TIMELIMIT 3 SUDOERS_BASE ou=sudoers,dc= nss_base_passwd o=infotel,dc= pam_filter objectClass=posixAccount === Today, serv1 failed, become unaccessible but not down. I can connect to LDAP port, but server closes the connection immediately. In this case, second URI does not work. Any ldap tool fails ("Cannot connect to server"). Shutting down interface helped, but I suppose that there must be an option to try second URI on such an error.

1 0

(ITS#7835) slapadd should ignore comment lines in LDIF input
by michael＠stroeder.com 13 Apr '14

13 Apr '14

Full_Name: Version: HEAD OS: not relevant here URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (79.227.190.41) slapadd should be capable of reading LDIFv1 compliant files with comment lines. Currently it refuses to read/parse a LDIF file beginning with a comment line: 534a67f0 str2entry: entry -1 has no dn slapadd: could not parse entry (line=1)

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs