- openldap-bugs - openldap.org

Re: (ITS#7844) LMDB Delete Cursor inconsistencies
by dw＠hmmz.org 14 May '14

14 May '14

This sounds very much like a known regression in mdb.master in the past few months. If you are still affected, please retest against LMDB 0.9.11 which at least was not affected by the regression. David

1 0

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

14 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 14 May '14

14 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 12 May '14

12 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 12 May '14

12 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 09 May '14

09 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 06 May '14

06 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 06 May '14

06 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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs