- openldap-bugs - openldap.org

(ITS#8104) Admin Guide 2.4 pdf
by it＠kotoc.cat 14 Apr '15

14 Apr '15

Full_Name: Ricard Valero Version: 2.4 OS: Debian/Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.35.55.43) Hi, Admins Guide 2.4 PDF lacks images, i know it's a minor issue but I like to have it on pdf, i'm new to LDAP and I would like to print it so i can write notes on it. Thanks

1 0

Re: (ITS#6077) Spurious uniqueness errors with filters in unique overlays
by quanah＠zimbra.com 13 Apr '15

13 Apr '15

I would suggest testing current RE24, somes fixes to slapo-unique went in last week. --Quanah --On Sunday, April 12, 2015 10:19 PM +0000 sbin(a)informatik.uni-leipzig.de wrote: > Should I be having this issue on OpenLDAP 2.4.40? I have the filter > > ldap:///?gidNumber?sub?(objectClass=posixGroup) > > and cannot use gidNumber in posixAccount's. This was working in 2.4.31 > if I recall correctly. > > #!RESULT ERROR > #!ERROR [LDAP: error code 19 - some attributes not unique] > dn: cn=User Name,ou=People,dc=... > changetype: modify > replace: gidNumber > gidNumber: 10000 > - > > > > > > -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6077) Spurious uniqueness errors with filters in unique overlays
by sbin＠informatik.uni-leipzig.de 12 Apr '15

12 Apr '15

Should I be having this issue on OpenLDAP 2.4.40? I have the filter ldap:///?gidNumber?sub?(objectClass=posixGroup) and cannot use gidNumber in posixAccount's. This was working in 2.4.31 if I recall correctly. #!RESULT ERROR #!ERROR [LDAP: error code 19 - some attributes not unique] dn: cn=User Name,ou=People,dc=... changetype: modify replace: gidNumber gidNumber: 10000 -

1 0

(ITS#8103) back-mdb segfault with aliases
by quanah＠openldap.org 12 Apr '15

12 Apr '15

Full_Name: Quanah Gibson-Mount Version: 2.4.39 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.25.188.166) When searching a DB that has extensive use of aliases, and using the -a always option to ldapsearch, slapd will eventually segv. This seems specific to the lmdb based backend. (gdb) thr apply all bt Thread 5 (Thread 0x7f9907687700 (LWP 906)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x00007fad0f360ec1 in ldap_pvt_thread_cond_wait (cond=0x1c26030, mutex=0x1c26008) at thr_posix.c:277 #2 0x00007fad0f35f858 in ldap_int_thread_pool_wrapper (xpool=0x1c26000) at tpool.c:683 #3 0x00007fad0d726e9a in start_thread (arg=0x7f9907687700) at pthread_create.c:308 #4 0x00007fad0d4538bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #5 0x0000000000000000 in ?? () Thread 4 (Thread 0x7f9908e8a700 (LWP 31908)): #0 0x00007fad0d453f53 in epoll_wait () at ../sysdeps/unix/syscall-template.S:82 #1 0x000000000043766f in slapd_daemon_task (ptr=0x19fe278) at daemon.c:2517 #2 0x00007fad0d726e9a in start_thread (arg=0x7f9908e8a700) at pthread_create.c:308 #3 0x00007fad0d4538bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #4 0x0000000000000000 in ?? () Thread 3 (Thread 0x7f9908689700 (LWP 32205)): #0 pthread_cond_wait@@GLIBC_2.3.2 () at ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 #1 0x00007fad0f360ec1 in ldap_pvt_thread_cond_wait (cond=0x1c26030, mutex=0x1c26008) at thr_posix.c:277 #2 0x00007fad0f35f858 in ldap_int_thread_pool_wrapper (xpool=0x1c26000) at tpool.c:683 #3 0x00007fad0d726e9a in start_thread (arg=0x7f9908689700) at pthread_create.c:308 #4 0x00007fad0d4538bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #5 0x0000000000000000 in ?? () Thread 2 (Thread 0x7f9907e88700 (LWP 32206)): #0 0x00007fad09d0ea4d in mdb_idscope (op=0x2207400, txn=0x3e85a00, base=1, ids=0x418e000, res=0x420e000) at dn2id.c:668 #1 0x00007fad09d01f50 in search_aliases (op=0x2207400, rs=0x7f9907e87a20, e_id=1, isc=0x7f9907e76470, mci=0x1f72680, stack=0x418e000) at search.c:177 #2 0x00007fad09d05c9f in search_candidates (op=0x2207400, rs=0x7f9907e87a20, e=0x3c60150, isc=0x7f9907e76470, mci=0x1f72680, ids=0x7f9907cf6470, stack=0x418e000) at search.c:1362 #3 0x00007fad09d03734 in mdb_search (op=0x2207400, rs=0x7f9907e87a20) at search.c:660 #4 0x00000000004d2932 in overlay_op_walk (op=0x2207400, rs=0x7f9907e87a20, which=op_search, oi=0x1f6e780, on=0x0) at backover.c:677 #5 0x00000000004d2b84 in over_op_func (op=0x2207400, rs=0x7f9907e87a20, which=op_search) at backover.c:730 #6 0x00000000004d2c93 in over_op_search (op=0x2207400, rs=0x7f9907e87a20) at backover.c:757 #7 0x000000000043f88d in fe_op_search (op=0x2207400, rs=0x7f9907e87a20) at search.c:402 #8 0x000000000043f0c0 in do_search (op=0x2207400, rs=0x7f9907e87a20) at search.c:247 #9 0x000000000043b8a7 in connection_operation (ctx=0x7f9907e87b60, arg_v=0x2207400) at connection.c:1132 #10 0x000000000043be39 in connection_read_thread (ctx=0x7f9907e87b60, argv=0xa) at connection.c:1268 #11 0x00007fad0f35f8ff in ldap_int_thread_pool_wrapper (xpool=0x1c26000) at tpool.c:696 #12 0x00007fad0d726e9a in start_thread (arg=0x7f9907e88700) at pthread_create.c:308 #13 0x00007fad0d4538bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 #14 0x0000000000000000 in ?? () Thread 1 (Thread 0x7fad0fa0f740 (LWP 31907)): #0 0x00007fad0d728148 in pthread_join (threadid=140295256188672, thread_return=0x0) at pthread_join.c:89 #1 0x00007fad0f360e02 in ldap_pvt_thread_join (thread=140295256188672, thread_return=0x0) at thr_posix.c:197 #2 0x00000000004388a9 in slapd_daemon () at daemon.c:2910 #3 0x0000000000414b7c in main (argc=9, argv=0x7ffffc5aae38) at main.c:1017 (gdb) thread 2 [Switching to thread 2 (Thread 0x7f9907e88700 (LWP 32206))] #0 0x00007fad09d0ea4d imdb_b_idscope (op=0x2207400, txn=0x3e85a00, base=1, ids=0x418e000, res=0x420e000) at dn2id.c:668 668 in dn2id.c (gdb) bt full #0 0x00007fad09d0ea4d in mdb_idscope (op=0x2207400, txn=0x3e85a00, base=1, ids=0x418e000, res=0x420e000) at dn2id.c:668 mdb = 0x2246000 dbi = 3 key = {mv_size = 8, mv_data = 0x7f9907cf61a8} data = {mv_size = 32, mv_data = 0x7f9a72303fb8} cursor = 0x1deca00 ida = 7168015 id = 1 cid = 7168015 ci0 = 0 idc = 0 ptr = 0x7f9a72303fd0 "\001" rc = 0 copy = 1 #1 0x00007fad09d01f50 in search_aliases (op=0x2207400, rs=0x7f9907e87a20, e_id=1, isc=0x7f9907e76470, mci=0x1f72680, stack=0x418e000) at search.c:177 aliases = 0x418e000 curscop = 0x420e000 visited = 0x428e000 newsubs = 0x430e000 oldsubs = 0x438e000 tmp = 0x440e000 cursora = 27246928 ida = 31360064 cursoro = 1 ido = 1 matctched = 0x3e85a00 a = 0x2207400 bv_alias = {bv_len = 5, bv_val = 0x7fad09d2cbe4 "alias"} aa_alias = {aa_desc = 0x1a1c540, aa_value = {bv_len = 5, bv_val = 0x7fad09d2cbe4 "alias"}} af = {f_choice = 163, f_un = {f_un_result = 131031616, f_un_desc = 0x7f9907cf6240, f_un_ava = 0x7f9907cf6240, f_un_ssa = 0x7f9907cf6240, f_un_mra = 0x7f9907cf6240, f_un_complex = 0x7f9907cf6240}, f_next = 0x0} #2 0x00007fad09d05c9f in search_candidates (op=0x2207400, rs=0x7f99077a7a20, e=0x3c60150, isc=0x7f9907e76470, mci=0x1f72680, ids=0x7f9907cf6470, stack=0x418e000) at search.c:1362 mdb = 0x2246000 rc = 32665 depth = 1 f = 0x3c60108 rf = {f_choice = 0, f_un = {f_un_result = 7, f_un_desc = 0x400000007, f_un_ava = 0x400000007, f_un_ssa = 0x400000007, f_un_mra = 0x400000007, f_un_complex = 0x400000007}, f_next = 0x0} xf = {f_choice = 63308112, f_un = {f_un_result = 35681280, f_un_desc = 0x2207400, f_un_ava = 0x2207400, f_un_ssa = 0x2207400, f_un_mra = 0x2207400, f_un_complex = 0x2207400}, f_next = 0x7f9907e86770} nf = {f_choice = 140295237755968, f_un = {f_un_result = 4627239, f_un_desc = 0x469b27, f_un_ava = 0x469b27, f_un_ssa = 0x469b27, f_un_mra = 0x469b27, f_un_complex = 0x469b27}, f_next = 0x7f9907cf63f0} sf = {f_choice = 140295237755968, f_un = {f_un_result = 132670896, f_un_desc = 0x7f9907e865b0, f_un_ava = 0x7f9907e865b0, f_un_ssa = 0x7f9907e865b0, f_un_mra = 0x7f9907e865b0, f_un_complex = 0x7f9907e865b0}, f_next = 0x0} aa_ref = {aa_desc = 0x0, aa_value = {bv_len = 0, bv_val = 0x0}} aa_subentry = {aa_desc = 0x0, aa_value = {bv_len = 0, bv_val = 0x0}} #3 0x00007fad09d03734 in mdb_search (op=0x2207400, rs=0x7f9907e87a20) at search.c:660 mdb = 0x2246000 id = 51 cursor = 3 nsubs = 10000018 ncand = 51 cscope = 140295239394864 lastid = 18446744073709551615 candidates = {0 <repeats 131072 times>} iscopes = {0 <repeats 65536 times>} scopes = 0x3e8e000 stack = 0x418e000 e = 0x0 base = 0x3c60150 matched = 0x0 attrs = 0x0 mask = 5119 stoptime = 1428813152 manageDSAit = 0 tentries = 0 isc = {mt = 0x3e85a00, mc = 0x1deae00, id = 0, scopes = 0x3e8e000, sctmp = 0x418e000, numrdns = 0, nscope = 0, oscope = 2, rdns = {{bv_len = 0, bv_val = 0x0} <repeats 2048 times>},rdrdns = {{bv_len = 0, bv_val = 0x0} <repeats 1718 times>, {bv_len = 140295239389896, bv_val = 0x2 <Address 0x2 out of bounds>}, { bv_len = 65559040, bv_val = 0x0}, {bv_len = 149475328, bv_val = 0x20e8290 "\004"}, {bv_len = 140295239389824, bv_val = 0x7f9908e8d000 "\002"}, {bv_len = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x7f9907e85250 "@T\350\a\231\177"}, {bv_len = 140381170805452, bv_val = 0x0}, {bv_len = 0, bv_val = 0x20e8290 "\004"}, {bv_len = 140295239389824, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7f9907e85140 "\b"}, {bv_len = 140295239390464, bv_val = 0x7f9907e85180 "\320Q\350\a\231\177"}, {bv_len = 140381170802682, bv_val = 0x0}, {bv_len = 140295239389616, bv_val = 0x16fdcf <Address 0x16fdcf out of bounds>}, {bv_len = 65559040, bv_val = 0x8 <Address 0x8 out of bounds>}, { bv_len = 140301427908608, bv_val = 0x7f990909efe8 "WW\027"}, {bv_len = 29398272, bv_val = 0x7f990909e000 "\023\002"}, {bv_len = 4294967296, bv_val = 0x7f9a78c5a000 "\317\375\026"}, {bv_len = 31370752, bv_val = 0x7f9907e851d0 "\300S\350\a\231\177"}, {bv_len = 140381170804162, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7f9907e85500 "\b"}, {bv_len = 31370752, bv_val = 0x7f9a78c5a000 "\317\375\026"}, {bv_len = 140295258370040, bv_val = 0x7e85210 <Address 0x7e85210 out of bounds>}, {bv_len = 0, bv_val = 0x7f9907e853c0 "@T\350\a\231\177"}, {bv_len = 140381170805452, bv_val = 0x7f9907e85250 "@T\350\a\231\177"}, {bv_len = 164732922, bv_val = 0x7f9907e85500 "\b"}, {bv_len = 31375252, bv_val = 0x14 <Address 0x14 out of bounds>}, {bv_len = 65559040, bv_val = 0x4 <Address 0x4 out of bounds>}, { bv_len = 140295256272896, bv_val = 0x7f9908e8df88 "0"}, {bv_len = 29398272, bv_val = 0x7f9908e8d000 "\002"}, {bv_len = 21474836482, bv_val = 0x4 <Address 0x4 out of bounds>}, {bv_len = 163208757248, bv_val = 0x7f9907e85440 "@\204\336\001"}, {bv_len = 140381170805319, bv_val = 0x0}, {bv_len = 8589934592, bv_val = 0x0}, {bv_len = 31370752, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 65559040, bv_val = 0x1 <Address 0x1 out of bounds>}, {bv_len = 65559224, bv_val = 0x20e8230 ""}, {bv_len = 65565417, bv_val = 0x100000001 <Address 0x100000001 out of bounds>}, {bv_len = 140295256199168, bv_val = 0x0}, {bv_l % = 0, bv_val = 0x0}, { bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7f9907e85380 " "}, {bv_len = 140295239390480, bv_val = 0x7f9907e85380 " "}, { bv_len = 63308528, bv_val = 0x7f9a78c5afcc "\200\006dc=spr"}, {bv_len = 140295106723843, bv_val = 0x7f9907e853c0 "@T\350\a\231\177"}, {bv_len = 140381170810321, bv_val = 0x7f9907e853c0 "@T\350\a\231\177"}, {bv_len = 140295239390256, bv_val = 0x1100000000 <Address 0x1100000000 out of bounds>}, {bv_len = 0, bv_val = 0x7f9907e85510 "\025"}, {bv_len = 31371144, bv_val = 0x20 <Address 0x20 out of bounds>}, {bv_len = 140301427912652, bv_val = 0x7f9a78c5afa0 "P"}, { bv_len = 140301427912624, bv_val = 0x7f9a78c5afc4 ""}, {bv_len = 31370752, bv_val = 0x301deaf88 <Address 0x301deaf88 out of bounds>}, {bv_len = 8589934592, bv_val = 0x7f9907e85440 "@\204\336\001"}, {bv_len = 140381170811635, bv_val = 0x0}, {bv_len = 140295239390372, bv_val = 0x200000000 <Address 0x200000000 out of bounds>}, { bv_len = 140295239390480, bv_val = 0x7f9907e85500 "\b"}, {bv_len = 18446744073709551595, bv_val = 0x7f9907e85450 "\220T\350\a\231\177"}, {bv_len = 140295256177840, bv_val = 0x7f9907e889c0 %C30300\231h\b\231\177"}, {bv_len = 4, bv_val = 0x7 <Address 0x7 out of bounds>}, {bv_len = 140381259065862, bv_val = 0x0}, {bv_len = 1, bv_val = 0x1de8440 ""}, {bv_len = 27255952, bv_val = 0x7f9907e85490 "\260T\350\a\231\177"}, {bv_len = 140381259067289, bv_val = 0x7f9907e854b0 "\220u\350\a\231\177"}, { bv_len = 0, bv_val = 0x4f7d80 ""}, {bv_len = 140295239398880, bv_val = 0x7 <Address 0x7 out of bounds>}, {bv_len = 140295239398880, bv_val = 0x7f9907e854b0 "\220u\350\a\231\177"}, {bv_len = 140381259067370, bv_val = 0x4f7d80 ""}, {bv_len = 140295239398880, bv_val = 0x7f9907e87590 ""}, { bv_len = 140381170752964, bv_val = 0x7f9907e875f0 "P|\241\001"}, {bv_len =4040295239398880, bv_val = 0x0}, {bv_len = 140295239398912, bv_val = 0x2207448 "\006"}, { bv_len = 0, bv_val = 0x3e85a00 ""}, {bv_len = 35681280, bv_val = 0x8 <Address 0x8 out of bounds>}, {bv_len = 140295239390520, bv_val = 0x15 <Address 0x15 out of bounds>}, { bv_len = 63308528, bv_val = 0x9 <Address 0x9 out of bounds>}, {bv_len = 63308509, bv_val = 0x1deae00 ""}, {bv_len = 0, bv_val = 0x0}, {bv_len = 63308539, bv_val = 0x2246000 ""}, {bv_len = 63308528, bv_val = 0x3ffff87b2 <Address 0x3ffff87b2 out of bounds>}, {bv_len = 0, bv_val = 0x0} <repeats 45 times>, {bv_len = 0, bv_val = 0x18 <Address 0x18 out of bounds>}, {bv_len = 140295239391424, bv_val = 0x7f9907e85870 ""}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0C C bv_val = 0x0}, {bv_len = 0, bv_val = 0x802 <Address 0x802 out of bounds>}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7f9907e858e0 "0i\350\a\231\177"}, { bv_len = 140381259073915, bv_val = 0x0}, {bv_len = 42949672961, bv_val = 0x0}, {bv_len = 8804682956800, bv_val = 0x7f9907e86930 "pi\350\a\231\177"}, { bv_len = 140381259071950, bv_val = 0x0}, {bv_len = 36961152, bv_val = 0x400000000 <Address 0x400000000 out of bounds>}, {bv_len = 36829584, bv_val = 0x0}, { bv_len = 4294967296, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0} <repeats 24 times>, {bv_len = 4820556, bv_val = 0x1d8e2a0 "\002"}, {bv_len = 140295239394208, bv_val = 0x0}, { bv_len = 140295239394208, bv_val = 0x1d8e2a0 "\002"}, {bv_len = 0, bv_val = 0x7f9907e85b20 "P[\350\a\231\177"}, {bv_len = 5191936, bv_val = 0x0}, {bv_len = 4820454, bv_val = 0x7f9907e863a0 "\002"}, {bv_len = 30991040, bv_val = 0x0}, {bv_len = 0,v_v_val = 0x7f9907e85b50 ""}, {bv_len = 4820737, bv_val = 0x0}, {bv_len = 140295239394208, bv_val = 0x0}, {bv_len = 4820556, bv_val = 0x1c1a600 "\v"}, {bv_len = 140295239394368, bv_val = 0x0}, {bv_len = 140295239394368, bv_val = 0x1c1a600 "\v"}, { bv_len = 63380800, bv_val = 0x7f9907e85bc0 "\360[\350\a\231\177"}, {bv_len = 5191936, bv_val = 0x0}, {bv_len = 4820454, bv_val = 0x7f9907e86440 "\v"}, {bv_len = 29468192, bv_val = 0x0}, {bv_len = 0, bv_val = 0x7f9907e85bf0 "\360h\350\a\231\177"}, {bv_len = 4820737, bv_val = 0x1ecfac0 "\024"}, {bv_len = 140295239394368, bv_val = 0x0}, { bv_len = 29468160, bv_val = 0x7f9907e868f0 ""}, {bv_len = 4808156, bv_val = 0x7f9907e85c40 "p\\\350\a\231\177"}, {bv_len = 140295239400000, bv_val = 0x7f9907e86928 "222}, { bv_len = 140295239395648, bv_val = 0x7f9907e864c0 "@\204\336\001"}, {bv_len = 32307936, bv_val = 0x0}, {bv_len = 31356864, bv_val = 0x7f9907e85c70 "pi\350\a\231\177"}, { bv_len = 4820737, bv_val = 0x0}, {bv_len = 140295239394496, bv_val = 0x0}, {bv_len = 32307904, bv_val = 0x7f9907e86970 ""}, {bv_len = 4808156, bv_val = 0x0}, { bv_len = 140295239395776, bv_val = 0x3c602b0 "\270\002\306\003"}, {bv_len = 63308448, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0} <repeats 25 times>, {bv_len = 0, bv_val = 0xffffffffffffffff <Address 0xffffffffffffffff out of bounds>}, {bv_len = 5, bv_val = 0x0}, {bv_len = 140295239392947, bv_val = 0x7f9907e8631b "52"}, { bv_len = 4294967295, bv_val = 0x7f9907e85eb2 <incomplete sequence \362>}, {bv_len = 18446744073709551504, bv_val = 0x7f9907e85eb0 "\n\211", <incomplete sequence \362>}, { bv_len = 140381228768393, bv_val = 0x0}, {bv_len = 140295239393076, bv_val = 0x7f9907e8631d ""}, {bv_len = 0, bv_val = 0xf2890a <Address 0xf2890a out of bounds>}, { bv_len = 0, bv_val = 0x0}, {bv_len = 140295239393120, bv_val = 0x7f9907e860e0 "\300b\350\a\231\177"}, {bv_len = 64, bv_val = 0x7f9907e86240 "@\200\336\001"}, {bv_len = 0, bv_val = 0x10 <Address 0x10 out of bounds>}, {bv_len = 140381228543396, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x34f2890a00000002 <Address 0x34f2890a00000002 out of bounds>}, {bv_len = 0, bv_val = 0x0}, {bv_len = 0, bv_val = 0x0}, {bv_len = 140381263811342, bv_val = 0x0}, { bv_len = 0, bv_val = 0xd794 <Address 0xd794 out of bounds>}, {bv_len = 0, bv_val = 0x0}, {bv_len = 140295239394864, bv_val = 0x7f9907e86620 ""}, {bv_len = 140295239395224, bv_val = 0x500ad7 "(%s%s=*)"}, {bv_len = 15, bv_val = 0x0}, {bv_len = 140381228009340, bv_val = 0x0}, {bv_len = 5245660, bv_val = 0x70 <Address 0x70 out of bounds>}, { bv_len = 3, bv_val = 0x0}...}} mci = 0x1f72680 mcd = 0x1deae00 wwctx = {txn = 0x0, mcd = 0x1ed06c0, key = 31360064, data = {mv_size = 0, mv_data = 0x0}, flag = 17} cb = {sc_next = 0x0, sc_response = 0, sc_cleanup = 0, sc_writewait = 0, sc_private = 0x0} opinfo = {moi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x2246000}, moi_txn = 0x3e85a00, moi_ref = 1, moi_flag = 1 '\001'} moi = 0x7f9907e86540 ltid = 0x3e85a00 #4 0x00000000004d2932 in overlay_op_walk (op=0x2207400, rs=0x7f9907e87a20, which=op_search, oi=0x1f6e780, on=0x0) at backover.c:677 func = 0x7fad09f33ed8 rc = 32768 #5 0x00000000004d2b84 in over_op_func (op=0x2207400, rs=0x7f9907e87a20, which=op_search) at backover.c:730 oi = 0x1f6e780 on = 0x201d680 be = 0x2020000 db = {bd_info = 0x7fad09f33e80, bd_self = 0x2020000, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001", '\000' <repeats 17 times>, "\001", be_flags = 2312, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, 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 = 0x1f96c40, be_nsuffix = 0x1f96c80, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x1f85950 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x1f85970 "%3=config"}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = -1, lms_t_hard = 0, lms_s_soft = -1, 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 = 0x1f9d7a0, 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 = 0x3957370, 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 = 0x7fad09f33be0, be_private = 0x2246000, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x2C2C sc_response = 0x4d16e7 <over_back_response>, sc_cleanup = 0, sc_writewait = 0, sc_private = 0x1f6e780} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #6 0x00000000004d2c93 in over_op_search (op=0x2207400, rs=0x7f9907e87a20) at backover.c:757 No locals. #7 0x000000000043f88d in fe_op_search (op=0x2207400, rs=0x7f9907e87a20) at search.c:402 bd = 0x75ee00 #8 0x000000000043f0c0 in do_search (op=0x2207400, rs=0x7f9907e87a20) at search.c:247 base = {bv_len = 6, bv_val = 0x231f997 "dc=spr"} siz = 0 off = 0 i = 0 #9 0x000000000043b8a7 in connection_operation (ctx=0x7f9907e87b60, arg_v=0x2207400) at connection.c:1132 rc = 80 cancel = 425556061 op = 0x2207400 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 = 0x233fb80 memctx = 0x1de8440 metxtx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #10 0x000000000043be39 in connection_read_thread (ctx=0x7f9907e87b60, argv=0xa) at connection.c:1268 rc = 0 cri = {op = 0x2207400, func = 0, arg = 0x0, ctx = 0x7f9907e87b60, nullop = 0} s = 10 #11 0x00007fad0f35f8ff in ldap_int_thread_pool_wrapper (xpool=0x1c26000) at tpool.c:696 pool = 0x1c26000 task = 0x395c500 work_list = 0x1c26098 ctx = {ltu_id = 140295239403264, ltu_key = {{ltk_key = 0x43b40d, ltk_data = 0x1c0b700, ltk_free = 0x43b25f <conn_counter_destroy>}, {ltk_key = 0x4b1433, ltk_data = 0x1de8440, ltk_free = 0x4b1258 <slap_sl_mem_destroy>D7D, {ltk_key = 0x456df1, ltk_data = 0x0, ltk_free = 0x456d44 <slap_op_q_destroy>}, {ltk_key = 0x1c09500, ltk_data = 0x3e85a00, ltk_free = 0x7fad09d103dc <mdb_reader_free>}, {ltk_key = 0x7fad09d0581e, ltk_data = 0x418e000, ltk_free = 0x7fad09d057fb <search_stack_free>}, {ltk_key = 0x7fad09d0236f, ltk_data = 0x0, ltk_free = 0x7fad09d02327 <scope_chunk_free>}, {ltk_key = 0x0, ltk_data = 0x3e60000, ltk_free = 0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 25 times>}} kctx = 0x0 i = 32 keyslot = 494 hash = 2690702830 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #12 0x00007fad0d726e9a in start_thread (arg=0x7f9907e88700) at pthread_create.c:308 __res = <optimized out> pd = 0x7f9907e88700 now = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {0, -7524299685094559341, 140295256177840, 140295239403968, 4, 7, 7540818657622552979, 7552056816962302355}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = 0 pagesize_m1 = <optimized out> sp = <optimized out> freesize = <optimized out> __PRETTY_FUNCTION__ = "start_thread" #13 0x00007fad0d4538bd in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 No locals. #14 0x0000000000000000 in ?? () No symbol table info available.

1 0

(ITS#8102) syncrepl_entry: be_modify failed (16)
by tpretz＠gmail.com 11 Apr '15

11 Apr '15

Now running RE24 head (commit 1101d4b7dbdb2453076c1075d1ae2375c36f06f9) Turned on a bit of logging (sync trace args) and grepped out some lines of interest. @(#) $OpenLDAP: slapd 2.4.X (Apr 10 2015 20:07:53) $ ... skipping ... syncrepl_message_to_entry: rid=100 DN: cn=3,ou=stest,dc=example,dc=com, UUID: 0f89951e-94fe-445b-91f8-9e8589c4d1e3 mdb_modify_internal: 0x00ebd167: cn=2,ou=stest,dc=example,dc=com mdb_modify_internal: replace AttrComment mdb_modify_internal: replace entryCSN mdb_modify_internal: replace modifiersName mdb_modify_internal: replace modifyTimestamp syncrepl_entry: rid=100 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=100 inserted UUID 0f89951e-94fe-445b-91f8-9e8589c4d1e3 syncrepl_entry: rid=100 be_search (0) syncrepl_entry: rid=100 cn=3,ou=stest,dc=example,dc=com mdb_modify: cn=3,ou=stest,dc=example,dc=com mdb_modify: updated id=00ebd167 dn="cn=2,ou=stest,dc=example,dc=com" syncrepl_entry: rid=101 be_modify cn=2,ou=stest,dc=example,dc=com (0) syncrepl_message_to_entry: rid=101 DN: cn=3,ou=stest,dc=example,dc=com, UUID: 0f89951e-94fe-445b-91f8-9e8589c4d1e3 mdb_modify_internal: 0x00ebd168: cn=3,ou=stest,dc=example,dc=com mdb_modify_internal: delete AttrComment mdb_modify_internal: replace entryCSN mdb_modify_internal: replace modifiersName mdb_modify_internal: replace modifyTimestamp syncrepl_entry: rid=101 LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD) syncrepl_entry: rid=101 inserted UUID 0f89951e-94fe-445b-91f8-9e8589c4d1e3 syncrepl_entry: rid=101 be_search (0) syncrepl_entry: rid=101 cn=3,ou=stest,dc=example,dc=com mdb_modify: cn=3,ou=stest,dc=example,dc=com mdb_modify: updated id=00ebd168 dn="cn=3,ou=stest,dc=example,dc=com" syncrepl_entry: rid=100 be_modify cn=3,ou=stest,dc=example,dc=com (0) syncrepl_message_to_entry: rid=100 DN: cn=4,ou=stest,dc=example,dc=com, UUID: 25f4703a-b73e-4d7c-81b8-9f139e267023 mdb_modify_internal: 0x00ebd168: cn=3,ou=stest,dc=example,dc=com mdb_modify_internal: delete AttrComment mdb_modify_internal: 16 modify/delete: AttrComment: no such attribute mdb_modify: modify failed (16) null_callback : error code 0x10 syncrepl_entry: rid=101 be_modify cn=3,ou=stest,dc=example,dc=com (16) syncrepl_entry: rid=101 be_modify failed (16) Thanks Tom

1 0

Re: (ITS#8101) facsimileTelephoneNumber
by hyc＠symas.com 10 Apr '15

10 Apr '15

bernhard.pfeiffer(a)brz.gv.at wrote: > Full_Name: Bernhard Pfeiffer > Version: 2.4.40 > OS: SUSE Linux 11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.158.227.32) > > > Hey! > > There is a problem in core-Schema with facsimileTelephoneNumber and jpegPhoto. > It is not possible to modify these attributes, for example: > > version: 1 > > dn: uid=testsimon,ou=people,ou=test,dc=gv,dc=at > changetype: modify > delete: facsimileTelephoneNumber > facsimileTelephoneNumber: +43 123 234 34234123 > > ldap_modify: Inappropriate matching (18) > additional info: modify/delete: facsimileTelephoneNumber: no equality > matching rule > > > It is only possible, to delete it completly or replace it. > > Is there any Bugfix in plan? This is not an OpenLDAP bug. The schema definitions for these attributes come from the LDAP RFCs (4519 in this case). You're welcome to submit a proposed revision to the IETF if you want the specs updated. In the meantime, your best approach is to define your own attributes that specify the matching rules you desire. Closing this ITS. -- -- 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#8102) syncrepl_entry: be_modify failed (16)
by quanah＠zimbra.com 10 Apr '15

10 Apr '15

--On Friday, April 10, 2015 5:12 PM +0000 tpretz(a)gmail.com wrote: > Full_Name: Tom Pressnell > Version: 2.4.40 > OS: debian wheezy > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (5.63.147.4) > > > Hi, > > In testing i have encountered the following when restoring replication > from multiple providers. > > slapd: slapd starting > slapd: null_callback : error code 0x10 > slapd: syncrepl_entry: rid=106 be_modify failed (16)AsAslapd: do_syncrepl: > rid=106 rc 16 retrying (9 retries left) > > Running 2.4.40 on debian wheezy amd64. > This occurs with both the mdb and hdb backends. > > While the consumer was offline i removed all values of an indexed > attribute from hundreds of entries, all providers are synced. > > Using standard syncrepl (not delta), issue occurs at process startup > where the consumer has been offline for a short while, i.e. replaying the > sessionlog not falling back to present. > > Having a read of syncrepl.c it would seem that syncrepl_diff_entry is > called for a entry received from a provider in a race with the same entry > from another provider in a different thread. > Both diff calls result in an attribute delete operation, when be_modify > is hit for the second time it fails with no such attribute as the first > thread has already removed it (uses DELETE, not SOFTDEL). Please test against current RE24, as there have been a number of fixes to syncrepl. Thanks! --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8102) syncrepl_entry: be_modify failed (16)
by tpretz＠gmail.com 10 Apr '15

10 Apr '15

Full_Name: Tom Pressnell Version: 2.4.40 OS: debian wheezy URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (5.63.147.4) Hi, In testing i have encountered the following when restoring replication from multiple providers. slapd: slapd starting slapd: null_callback : error code 0x10 slapd: syncrepl_entry: rid=106 be_modify failed (16)AsAslapd: do_syncrepl: rid=106 rc 16 retrying (9 retries left) Running 2.4.40 on debian wheezy amd64. This occurs with both the mdb and hdb backends. While the consumer was offline i removed all values of an indexed attribute from hundreds of entries, all providers are synced. Using standard syncrepl (not delta), issue occurs at process startup where the consumer has been offline for a short while, i.e. replaying the sessionlog not falling back to present. Having a read of syncrepl.c it would seem that syncrepl_diff_entry is called for a entry received from a provider in a race with the same entry from another provider in a different thread. Both diff calls result in an attribute delete operation, when be_modify is hit for the second time it fails with no such attribute as the first thread has already removed it (uses DELETE, not SOFTDEL). Thanks Tom

1 0

Re: (ITS#7145) cn=Connection 0
by michael＠stroeder.com 10 Apr '15

10 Apr '15

hguo(a)suse.com wrote: > Is your build identical to the 2.4.40 on OBS in terms of patches/source > code revision? No. It's RE24 with all changes to be released as 2.4.41. > What distribution did you use for testing? openSUSE Tumbleweed x86_64. Ciao, Michael.

1 0

Re: (ITS#7145) cn=Connection 0
by hguo＠suse.com 10 Apr '15

10 Apr '15

Is your build identical to the 2.4.40 on OBS in terms of patches/source code revision? What distribution did you use for testing? Kind regards, Howard On 10/04/15 15:23, Michael Ströder wrote: > Michael Ströder wrote: >> Yes, the duplicate occurence should be fixed. I have to check in my >> installation if it's still an issue. > > Using a local build from RE24 branch I cannot see the duplicate > occurence of > cn=Connection 0,cn=Connections,cn=Monitor anymore. > > Ciao, Michael. > >

1 0

Re: (ITS#7145) cn=Connection 0
by michael＠stroeder.com 10 Apr '15

10 Apr '15

Michael Ströder wrote: > Yes, the duplicate occurence should be fixed. I have to check in my > installation if it's still an issue. Using a local build from RE24 branch I cannot see the duplicate occurence of cn=Connection 0,cn=Connections,cn=Monitor anymore. Ciao, Michael.

1 0

Re: (ITS#7145) cn=Connection 0
by hguo＠suse.com 10 Apr '15

10 Apr '15

Last month when I tried OpenLDAP 2.4.40 using your SLES 12 package, I was still able to get two Connection0s to show up in one response. It'll be a great news if that's no longer the case with the next release. Kind regards, Howard On 10/04/15 15:08, Michael Ströder wrote: > hguo(a)suse.com wrote: >> According to the issue report, the connection 0's DN appears not only >> once, but twice, in some circumstances. Duplicated DN should not have >> appeared in server response. >> >> Apart from that, connection 0 does not serve any purpose for LDAP >> clients, therefore its connection details are not useful. > > Yes, the duplicate occurence should be fixed. I have to check in my > installation if it's still an issue. > > But IMO it's not the correct solution to completely mask out > Connection 0. > > Ciao, Michael. > >

1 0

Re: (ITS#7145) cn=Connection 0
by michael＠stroeder.com 10 Apr '15

10 Apr '15

This is a cryptographically signed message in MIME format. --------------ms040201060806000805040605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable hguo(a)suse.com wrote: > According to the issue report, the connection 0's DN appears not only > once, but twice, in some circumstances. Duplicated DN should not have > appeared in server response. > > Apart from that, connection 0 does not serve any purpose for LDAP > clients, therefore its connection details are not useful. Yes, the duplicate occurence should be fixed. I have to check in my=20 installation if it's still an issue. But IMO it's not the correct solution to completely mask out Connection 0= =2E Ciao, Michael. --------------ms040201060806000805040605 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBkUwggUtoAMCAQICAwtNUDANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTE0MDkyMzIw NDc1NVoXDTE1MDkyNDIyMDUxOFowXzEZMBcGA1UEDRMQNk0yWTdpOXpEdGU2alV3MDEdMBsG A1UEAwwUbWljaGFlbEBzdHJvZWRlci5jb20xIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ry b2VkZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAynIH09fU597v4fg4 uwqFJDPUxQHV9qxrfM/c3veStPyYl0JorqKHrD+hfCNZ+Toy65NN9f9vO26WnnLoDF+FE2Dk Qi61iTgK5jZTr5dJG1WQkk698UNWO87lUWBRYYiUM7wC3ek2E0rzR99qIxE4dG9wws19F3KK JvNN8tMTyoPw5Vkw4qx2SW54WEBMx7oCXBIZPPDD8ovled6vDVweVSaYXFUbkxbKJR87Msih 34Ba+cM5SAHQNQ11jaSJjFeqbQnXjf0nESnvo0XIckc9w240w3jcgu6b5SIQBI2vv5TaIv7v KqNk0o+cGc9NnCw5/xD/OAB9Aj/qDca6NheHCQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTj z1BhELZO3zEJfmZQ4I+c6NCXIjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAf BgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYL KwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0 byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20g Q0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns YXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2Nl cnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAfByd9CEZ5pYuRa3XuE5xeJoIpDol22 A1mIGuRqxaBFIummmDoYr/tVgFod/3evQJO+ad8T5wpooY422HkHN4a1UI7ujCKcU/PrQSxm v28AAsl4Fo/InY1nSFjMy8Ywj3EG+Edj1ZpCkzTRNGZjBa6Uj7UY7UW71kYcSdCBe8vc9Zi3 6OnHGkXROWIii3wBKLDEZqxknw0Cj9TTy5lyllYzyHku4aXLDPhiYrTzhWiwgYmweaLvW/yq YVsHRpW8udzqOr6xvUVcuRmfMTENM7RSlRZVw2+5+I+zn7jqOrrULO1FP7Lo5cPilsMpSMOw oJnPLQgNZvXOPFO6VaDCOboxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBAgMLTVAwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDQxMDEzMDg1MFowLwYJKoZIhvcNAQkEMSIE INjY2+k8RYDr+AWl9Tdry/StUnpv0l5mMlEZSSB1gSDBMGwGCSqGSIb3DQEJDzFfMF0wCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwgacGCyqGSIb3DQEJ EAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwtNUDANBgkq hkiG9w0BAQEFAASCAQCjGZUjWWmSZr90Qc5rvU4bxBdLLdl/R61n5bN2grUbuLaMnx4HHyVv LVPazxss32mJDpPv9Xr1ccusbTHOlLqSXb86g/nV15KcXNuXELqiRTpSXOlyIfU87jKAjdp5 oCZqdQqVZftPUXZyF+qT9OL2kVlXemA8JeBLBuPQXCpOtHyo3TPin+9sCpJJEGwCaJ6qwxaj ha0C1lKP3gWWr8dN4DQvq7jXatOueIkKxPcxjafbWhBxHeJs1ZrtDu62NqVuLyoSOkT4Jzpm /hXUFM4aD3fDNkLWCEqrqooaIDY3KqBEd7/J7vSoUAKwT/AUoo+4lqQzKyEGq3+TuVtLGnl+ AAAAAAAA --------------ms040201060806000805040605--

1 0

Re: (ITS#7145) cn=Connection 0
by hguo＠suse.com 10 Apr '15

10 Apr '15

According to the issue report, the connection 0's DN appears not only once, but twice, in some circumstances. Duplicated DN should not have appeared in server response. Apart from that, connection 0 does not serve any purpose for LDAP clients, therefore its connection details are not useful. What do you think? Kind regards, Howard On 10/04/15 14:29, Michael Ströder wrote: > hguo(a)suse.com wrote: >> The patch is a proposed resolution to the issue. >> >> To prevent monitor backend from returning invalid result about >> Connection 0, it will simply not report information about the >> connection 0. > > Indeed I do understand what your patch does. > > But what is the real problem with Connection 0 you're trying to solve? > Note that slapd internally access the database(s). So your monitoring > checks should simply ignore this Connection 0. > > Ciao, Michael. > .

1 0

Re: (ITS#7145) cn=Connection 0
by michael＠stroeder.com 10 Apr '15

10 Apr '15

hguo(a)suse.com wrote: > The patch is a proposed resolution to the issue. > > To prevent monitor backend from returning invalid result about > Connection 0, it will simply not report information about the connection 0. Indeed I do understand what your patch does. But what is the real problem with Connection 0 you're trying to solve? Note that slapd internally access the database(s). So your monitoring checks should simply ignore this Connection 0. Ciao, Michael.

1 0

Re: (ITS#7145) cn=Connection 0
by hguo＠suse.com 10 Apr '15

10 Apr '15

The patch is a proposed resolution to the issue. To prevent monitor backend from returning invalid result about Connection 0, it will simply not report information about the connection 0. Kind regards, Howard On 10/04/15 11:41, Michael Ströder wrote: > hguo(a)suse.com wrote: >> I created a patch against the latest source code and uploaded the patch >> "howard-guo-2015-04-10.patch" onto the FTP server. With the patch, >> monitor backend no longer returns connection ID 0 to the LDAP client. > > I'm curious: Which problem do you want to solve? > > Ciao, Michael. >

1 0

Re: (ITS#7145) cn=Connection 0
by michael＠stroeder.com 10 Apr '15

10 Apr '15

hguo(a)suse.com wrote: > I created a patch against the latest source code and uploaded the patch > "howard-guo-2015-04-10.patch" onto the FTP server. With the patch, > monitor backend no longer returns connection ID 0 to the LDAP client. I'm curious: Which problem do you want to solve? Ciao, Michael.

1 0

Re: (ITS#7145) cn=Connection 0
by hguo＠suse.com 10 Apr '15

10 Apr '15

Good day! The appearance of connections with ID 0 in the Monitor backend seems entirely cosmetic and does not affect the normal operation of OpenLDAP server. I created a patch against the latest source code and uploaded the patch "howard-guo-2015-04-10.patch" onto the FTP server. With the patch, monitor backend no longer returns connection ID 0 to the LDAP client. Please review - many thanks. Kind regards, Howard Guo SUSE LINUX Products GmbH

1 0

(ITS#8101) facsimileTelephoneNumber
by bernhard.pfeiffer＠brz.gv.at 10 Apr '15

10 Apr '15

Full_Name: Bernhard Pfeiffer Version: 2.4.40 OS: SUSE Linux 11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.158.227.32) Hey! There is a problem in core-Schema with facsimileTelephoneNumber and jpegPhoto. It is not possible to modify these attributes, for example: version: 1 dn: uid=testsimon,ou=people,ou=test,dc=gv,dc=at changetype: modify delete: facsimileTelephoneNumber facsimileTelephoneNumber: +43 123 234 34234123 ldap_modify: Inappropriate matching (18) additional info: modify/delete: facsimileTelephoneNumber: no equality matching rule It is only possible, to delete it completly or replace it. Is there any Bugfix in plan?

1 0

(ITS#8100) Empty accesslog causes issues with delta-syncrepl MMR configurations
by quanah＠openldap.org 09 Apr '15

09 Apr '15

Full_Name: Quanah Gibson-Mount Version: 2.4.39 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (50.25.188.166) When one has an MMR setup using delta-syncrepl, and the masters get into a situation where one is out of sync, or adding a new MMR node to an existing cluster, things will be broken until the new/reloaded node has a write op that goes to the accesslog DB. In an existing cluster, where a node is being reloaded, it causes all nodes to go into an endless looping fallback sync until that write occurs.

1 0

Re: (ITS#8099) Documentation bug with 'tls_cipher(_)suite' option
by quanah＠zimbra.com 08 Apr '15

08 Apr '15

--On Wednesday, April 08, 2015 11:52 AM +0000 matt(a)bodgit-n-scarper.com wrote: > Full_Name: Matt Dainty > Version: 2.4.40 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (173.38.209.6) > > > Documentation makes reference to `tls_ciphersuite=` option for > olcSyncrepl/syncrepl settings however I got an error when trying to use > it. Thanks for the report, this is now fixed in openldap.master/RE25/RE24. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8057) slapo-unique can be bypassed by anyone
by ondra＠mistotebe.net 08 Apr '15

08 Apr '15

A fix for that is at ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20150408-ITS-8057-uniqueness-… The above patch is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the above patches were developed by Ondrej Kuznik <ondra(a)mistotebe.net>. I have not assigned rights and/or interest in this work to any party. I, Ondrej Kuznik, hereby place the above modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice

1 0

(ITS#8099) Documentation bug with 'tls_cipher(_)suite' option
by matt＠bodgit-n-scarper.com 08 Apr '15

08 Apr '15

Full_Name: Matt Dainty Version: 2.4.40 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (173.38.209.6) Documentation makes reference to `tls_ciphersuite=` option for olcSyncrepl/syncrepl settings however I got an error when trying to use it. On a hunch, I tried using `tls_cipher_suite=` instead matching the style of the equivalent ldap.conf setting and this worked. Confirmed what the code was doing here: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/sl… slapd-config(5), slapd.conf(5) are affected as well as the admin guide, potentially slapd-meta(5) and slapd-ldap(5) too if those backends reuse the same config code.

1 0

Re: (ITS#8098) Memory leakage
by quanah＠zimbra.com 07 Apr '15

07 Apr '15

--On Tuesday, April 07, 2015 11:12 AM +0000 rolandsytt(a)yahoo.com wrote: > Full_Name: Roland S.tt > Version: 2.4.40 > OS: CentOS Linux release 7.0.1406 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.126.102.178) > > > Slapd memory usage increases endlessly. It's same in 2.4.39 (from CentOS 7 > repository). During some simple activity (e.g ldapsearch) memory usage > increases, but it's not decreases after the activity end. You're likely seeing the numerous issues known to occur when using glibc as the default allocator. OpenLDAP is routinely profiled for memory leaks, and there are none currently known to exist. It is always strongly advised to use a different memory allocator with OpenLDAP, such as tcmalloc. For example, I wrap slapd with: quanah@zre-ldap001:~/p4/zimbra/main/ThirdParty/openldap/patches$ more ../../../ZimbraServer/src/libexec/zmslapd #!/bin/bash # # ***** BEGIN LICENSE BLOCK ***** # Zimbra Collaboration Suite Server # Copyright (C) 2007, 2008, 2009, 2010, 2012, 2013, 2014 Zimbra, Inc. # # This program is free software: you can redistribute it and/or modify it under # the terms of the GNU General Public License as published by the Free Software Foundation, # version 2 of the License. # # This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; # without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # See the GNU General Public License for more details. # You should have received a copy of the GNU General Public License along with this program. # If not, see <http://www.gnu.org/licenses/>. # ***** END LICENSE BLOCK ***** # ulimit -n 32768 ulimit -c unlimited ulimit -v unlimited export LD_PRELOAD=/opt/zimbra/tcmalloc/lib/libtcmalloc_minimal.so exec /opt/zimbra/openldap/sbin/slapd "$@" As there is no actionable bug report here, this bug will be closed. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8098) Memory leakage
by rolandsytt＠yahoo.com 07 Apr '15

07 Apr '15

Full_Name: Roland S.tt Version: 2.4.40 OS: CentOS Linux release 7.0.1406 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.126.102.178) Slapd memory usage increases endlessly. It's same in 2.4.39 (from CentOS 7 repository). During some simple activity (e.g ldapsearch) memory usage increases, but it's not decreases after the activity end. Loaded modules:D0D olcModuleLoad: {0}dynlist.la olcModuleLoad: {1}ppolicy.la olcModuleLoad: {2}syncprov.la olcModuleLoad: {3}auditlog.la olcModuleLoad: {4}memberof.la olcDatabase: {1}bdb Number of entries in DB: ~2000 How to reproduce Install CentOS 7 openldap-servers package or build Openldap 2.4.40 RPM using openldap.spec from CentOS 7 openldap-servers source package. Then do numerous ldap searches from multiple hosts.

1 0

Re: (ITS#8057) slapo-unique can be bypassed by anyone
by quanah＠zimbra.com 07 Apr '15

07 Apr '15

--On Tuesday, April 07, 2015 4:01 AM +0000 quanah(a)zimbra.com wrote: > --On Saturday, February 14, 2015 6:16 PM +0000 ondra(a)mistotebe.net wrote: > >> Full_Name: Ondrej Kuznik >> Version: master >> OS: >> URL: >> ftp://ftp.openldap.org/pub/Ondrej-Kuznik-20150214-ITS-8057-uniqueness-ACL >> .patch Submission from: (NULL) (86.177.93.243) >> >> >> This is caused by my fix for #6641. Since anyone can specify the >> manageDSAit control on an operation it is trivial to bypass the >> uniqueness check as it stands. > > This "fix" causes OpenLDAP to crash during replication: > > <http://fpaste.org/207817/70741142/> Also crashes when using ldapmodify -M or ldapmodrdn -M --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8057) slapo-unique can be bypassed by anyone
by quanah＠zimbra.com 07 Apr '15

07 Apr '15

--On Saturday, February 14, 2015 6:16 PM +0000 ondra(a)mistotebe.net wrote: > Full_Name: Ondrej Kuznik > Version: master > OS: > URL: > ftp://ftp.openldap.org/pub/Ondrej-Kuznik-20150214-ITS-8057-uniqueness-ACL > .patch Submission from: (NULL) (86.177.93.243) > > > This is caused by my fix for #6641. Since anyone can specify the > manageDSAit control on an operation it is trivial to bypass the > uniqueness check as it stands. This "fix" causes OpenLDAP to crash during replication: <http://fpaste.org/207817/70741142/> --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8097) update nssov to nss-pam-ldapd 0.9.4
by ryan＠nardis.ca 05 Apr '15

05 Apr '15

Full_Name: Ryan Tandy Version: master, 2.4 OS: Debian URL: Submission from: (NULL) (24.68.37.4) updating the copied nss-pam-ldapd files: ftp://ftp.openldap.org/incoming/20150405_rtandy_nssov-update-nss-pam-ldapd-… updating nssov for those changes, see commit msg for details: ftp://ftp.openldap.org/incoming/20150405_rtandy_nssov-update-to-protocol-ve… while I'm in the code anyway, cleaning up a few compiler warnings (that were already there, I didn't introduce them :P). Cosmetic stuff: unused variables, return-type (void/non-void) mismatches, a couple of undeclared prototypes. ftp://ftp.openldap.org/incoming/20150405_rtandy_nssov-clean-up-some-compile… Please note, the protocol change breaks backwards compat with older versions of the client libraries (per nss-pam-ldapd/README). Tested on Linux. No idea about Solaris etc, sorry. The DN field was removed from the pam protocol, so uid lookup happens on every connection now. I couldn't think of a safe way to avoid that; suggestions welcome. -- (the following statements apply to patches 2 and 3 only; patch 1 is copied from work by Arthur de Jong, licensed LGPLv2.1) The attached patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the preceding patches were developed by Ryan Tandy <ryan(a)nardis.ca>. I have not assigned rights and/or interest in this work to any party. I, Ryan Tandy, hereby place the preceding modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#8087) Segmentation fault in MDB at idl.c:91 using searches
by hyc＠symas.com 04 Apr '15

04 Apr '15

francisco(a)garnelo.eu wrote: > Full_Name: Francisco Garnelo > Version: slapd 2.4.40 > OS: FreeBSD 10.1-STABLE > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.237.142.21) Thanks for the report. Pretty sure this has already been fixed in RE24 for 2.4.41. Can you please test with the 2.4 release engineering branch and confirm whether the problem is still present? > > > > Hi, when I try to access with a LDAP browser (Apache DS) and the browser begin > to enumerate the items in differents branches, the server crashes; this not > takes more than 30 seconds from last restart. > > I experimented a similar issue with SLES 12(if not it is the same) and openldap > 2.4.40 (from suse repositories) version, but in this system I could not take > evidences. > > The database has more than 3GB of size and MDB is configured to support 100GB as > the maximum size. > > The same databa w works fine ining BDB using an old openldap version. > > ############# > # Versions: # > ############# > > root@XXXX:/usr/local/etc/openldap # /usr/local/libexec/slapd -VVV > @(#) $OpenLDAP: slapd 2.4.40 (Mar 24 2015 17:18:46) $ > root@XXXX:/usr/rtrts/net/openldap24-server/work/openldap-2.4.40/servers/slapd > > Included static overlays: > dynlist > seqmod > syncprov > Included static backends: > config > ldif > relay > > root@xxxx:/usr/local/etc/openldap # uname -a > FreeBSD xxxx 10.1-STABLE FreeBSD 10.1-STABLE #0 r278906: Tue Feb 17 19:09:13 UTC > 2015 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > > > > ###################### > # cn=config export: # > ###################### > > version: 1 > > dn: cn=config > objectClass: olcGlobal > cn: config > olcArgsFile: /var/run/openldap/slapd.args > olcAttributeOptions: lang- > olcAuthzPolicy: none > olcConfigDir: slapd.d > olcConfigFile: slapd.conf > olcIdleTimeout: 0 > olcIndexIntLen: 8 > olcIndexSubstrAnyLen: 4 > olcIndexSubstrAnyStep: 2 > olcIndexSubstrIfMaxLen: 4 > olcIndexSubstrIfMinLen: 2 > olcListenerThreads: 1 > olcLocalSSF: 71 > olcLogLevel: 0 > olcPidFile: /var/run/openldap/slapd.pid > olcReadOnly: FALSE > olcReverseLookup: FALSE > olcSizeLimit: unlimited > olcThreads: 20 > olcTLSCACertificateFile: /usr/local/etc/openldap/certs/public/ca.crt > olcTLSCertificateFile: /usr/local/etc/openldap/certs/public/server.crt > olcTLSCertificateKeyFile: /usr/local/etc/openldap/certs/private/server.key > olcTLSCRLCheck: none > olcTLSProtocolMin: 0.0 > olcTLSVerifyClient: never > olcToolThreads: 2 > olcWriteTimeout: 0 > > dn: cn=module{0},cn=config > objectClass: olcModuleList > cn: module{0} > olcModuleLoad: {0}back_mdb database config > olcModulePath: /usr/local/libexec/openldap > > dn: cn=schema,cn=config > objectClass: olcSchemaConfig > cn: schema > > ### -- omitted content -- ### > > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > include /usr/local/etc/openldap/schema/inetorgperson.schema > include /r%r/local/etc/openldap/schema/rfc2307bis.schema > > ### -- omitted content -- ### > > > dn: olcDatabase={-1}frontend,cn=config > objectClass: olcFrontendConfig > objectClass: olcDatabaseConfig > olcDatabase: {-1}frontend > olcAccess: {0}to dn.base="" by * read > olcAccess: {1}to dn.base%%2"cn=subsemema" by * read > olcAccess: {2}to attrs=shadowLastChange by self write by * read > olcAccess: {3}to * by * read > olcAddContentAcl: FALSE > olcLastMod: TRUE > olcMaxDerefDepth: 0 > olcMonitoring: FALSE > olcReadOnly: FALSE > olcSchemaDN: cn=Subschema > olcSizeLimit: unlimited > olcSyncUseSubentry: FALSE > > dn: olcDatabase={0}config,cn=config > objectClass: olcDatabaseConfig > olcDatabase: {0}config > olcAccess: {0}to * by * none > olcAddContentAcl: TRUE > olcLastMod: TRUE > olcMaxDerefDepth: 15 > olcMonitoring: FALSE > olcReadOnly: FALSE > olcRootDN: cn=config > olcRootPW: XXXXX > olcSyncUseSubentry: FALSE > > dn: olcDatabase={1}mdb,cn=config > objectClass: olcMdbConfig > objectClass: olcDatabaseConfig > olcDatabase: {1}mdb > olcDbDirectory:2F2Fvar/db/openldap-data.mdb > olcDbIndex: objectClass eq > olcRootDN: cn=lalala,dc=yyyyyyy,dc=com > olcRootPW: XXXXXXX > olcSuffix: dc=yyyyyyy,dc=com > > > ######## > # GDB: # > ######## > > 551194b6 => mdb_dn2id("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,%3=com") > 551194b6 <= mdb_entry_decode > 551194b6 <= mdb_dn2id: got id=0x92b0 > 551194b6 => mdb_entry_decode: > 551194b6 => mdb_entry_decode: > 551194b6 <= mdb_entry_decode > 551194b6 => mdb_entry_decode: > 551194b6 => mdb_entry_decode: > 551194b6 <= mdb_entry_decode > 551194b6 <= mdb_entry_decode > 551194b6 => mdb_entry_decode: > 551194b6 => mdb_entry_decode: > 551194b6 <= mdb_entry_decode > 551194b6 <= mdb_entry_decode > 551194b6 mdb_dn2entry("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") > 551194b6 => mdb_entry_decode: > 551194b6 => mdb_dn2id("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") > 551194b6 <= mdb_entry_decode > 551194b6 <= mdb_entry_decode > 551194b6 => mdb_entry_decode: > 551194b6 => mdb_entry_decode: > 551194b6 <= mdb_entry_decode > 551194b6 <= mdb_dn2id: got id=0x92b0 > 551194b6 => mdb_entry_decode: > 551194b6 <= mdb_entry_decode > 551194b6 => mdb_entry_decode: > 551194b6 => mdb_entry_decode: > 551194b6 <= mdb_entry_decode > 551194b6 <= mdb_entry_decode > 551194b6 => mdb_entry_decode: > 551194b6 <=dbdb_entry_decode > 551194b6 => mdb_entry_decode: > 551194b6 => mdb_entry_decode: > 551194b6 <= mdb_entry_decode > 551194b6 <= mdb_entry_decode > 551194b6 => mdb_entry_decode: > 551194b6 <= mdb_entry_decode > 551194b6 => mdb_entry_decode: > 551194b6 => mdb_entry_decode: > 551194b6 <= mdb_entry_decode > 551194b6 <= mdb_entry_decode > 551194b6 mdb_dn2entry("lelreleID=luser123(a)odin.lala,ou=molon,dc=yyyyyyy,dc=com") > 551194b8 => mdb_dn2id("lelreleID=luser123(a)odin.lala,ou=molon,dc=yyyyyyy,dc=com") > 551194b8 <= mdb_dn2id: got id=0x931e > 551194b8 => mdb_entry_decode: > 551194b8 <= mdb_entry_decode > 551194b6 => mdb_entry_decode: > 551194b8 => mdb_entry_decode: > 551194b8 <= mdb_entry_decode > 551194b8 <= mdb_entry_decode > 551194b7 daemon: activity on 1 descriptor > 551194b8 daemon: activity on:519194b8 11r551194b8 > 551194b8 daemon: read activity on 11 > 551194b8 mdb_dn2entry("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") > 551194b8 => mdb_dn2id("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") > 551194b7 => mdb_entry_decode: > 551194b7 => mdb_entry_decode: > 551194b8 <= mdb_entry_decode > 551194b8 <= mdb_dn2id: got id=0x9321 > 551194b8 mdb_dn2entry("loloId=50,ou=fry,dc=yyyyyyy,dc=com") > 551194b8 => mdb_entry_decode: > 551194b8 => mdb_dn2id("loloId=50,ou=fry,dc=yyyyyyy,dc=com") > 551194b8 <= mdb_entry_decode > 551194b8 => mdb_entry_decode: > 551194b8 daemon: select: listen=6 active_threads=0 tvp=NULL > 551194b8 daemon: select: listen=7 active_threads=0 tvp=NULL > 551194b8 <= mdb_dn2id: got id=0xf > 551194b6 <= mdb_entry_decode > 551194b8 => mdb_entry_dece:3A > 551194b8 <= mdb_entry_decode > 551194b8 => mdb_entry_decode: > 551194b8 <= mdb_entry_decode > 551194b8 <= mdb_entry_decode > 551194b8 <= mdb_entry_decode > 551194b8 => mdb_entry_decode: > 551194b8 mdb_dn2entry("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") > 551194b8 => mdb_dn2id("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") > 551194b8 <= mdb_entry_decode > 551194b8 mdb_dn2entry("lelreleID=262280000000000(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") > 551194b8 => mdb_entry_decode: > 551194b8 <= mdb_entry_decode > 551194b8 => mdb_entry_decode: > 551194b8 => mdb_entry_decode: > 551194b8 <= mdb_entry_decode > 551194b8 => mdb_entry_decode: > 551194b8 <= mdb_dn2id: got id=0x9321 > 551194b8 <= mdb_entry_decode > 551194b8 => mdb_entry_decode: > 551194b8 <= mdb_entry_decode > 551194b8 => mdb_dn2id("lelreleID=262280000000000(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") > 551194b8 => mdb_entry_decode: > 551194b8 <= mdb_entry_decode > 551194b8 <= mdb_dn2id: got id=0x25 > 551194b8 => mdb_entry_decode: > 551194b8 <= mdb_entry_decode > 551194b8 => mdb_entry_decode: > 551194b8 mdb_dn2entry("loloId=50,ou=fry,dc=yyyyyyy,dc=com") > 551194b8 <= mdb_entry_decode > [New Thread 2103c12400 (LWP 100750/slapd)] > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 2103c12400 (LWP 100750/slapd)] > 0x00000008024a579f in mdb_idl_search (ids=0x210a980000, id=37) at idl.c:91 > 91 val = IDL_CMP( id, ids[cursor] ); > Current language: auto; currently minimal > > -------------- > > Thanks, Francisco Garnelo > > > -- -- 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#8086) slapd with mdb backend crashes in id2entry
by hyc＠symas.com 04 Apr '15

04 Apr '15

Nikos Voutsinas wrote: > I haven't compared the same build with and with out the fixes for > ITS#7961,#7987, however I can confirm that under the same environment, > RE24 (scheduled for 2.4.41) remains stable while 2.4.40 crashes from > time to time. Actually I would strongly suggest upgrading to 2.4.41 when > available. Thanks for the confirmation, we'll resolve this ITS. > > On Sun, Mar 22, 2015 at 9:36 PM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com>> wrote: > > Nikos Voutsinas wrote: > > I am in the process of doing so. Do you have in mind a specific > commit/fix in REL_EN that might have solved this; That would help me > reproduce the initial problem (in 2.4.40) and confirm the fix > (in REL_ENG). > > > Most likely 9a72292ac134f80c1befe8102dee11__60e57a92ec > > > For start I will try to upgrade to REL_ENG the same system from > which I > got the debug log, to see if that would help recover (although I > have no > great hopes). > > On Sun, Mar 22, 2015 at 12:39 AM, Howard Chu <hyc(a)symas.com > <mailto:hyc@symas.com> > <mailto:hyc@symas.com <mailto:hyc@symas.com>>> wrote: > > nvoutsin(a)gmail.com <mailto:nvoutsin@gmail.com> > <mailto:nvoutsin@gmail.com <mailto:nvoutsin@gmail.com>> wrote: > > Full_Name: Nikos Voutsinas > Version: 2.4.40 > OS: Debian > URL: > ftp://ftp.openldap.org/____incoming/NikosVoutsinas_20-03-____2015_mdb_asser… > <ftp://ftp.openldap.org/__incoming/NikosVoutsinas_20-03-__2015_mdb_assertion…> > > <ftp://ftp.openldap.org/__incoming/NikosVoutsinas_20-03-__2015_mdb_assertion… > <ftp://ftp.openldap.org/incoming/NikosVoutsinas_20-03-2015_mdb_assertion.id2…>> > Submission from: (NULL) (5.55.167.101) > > > slapd with an mdb backend, after some time of normal > operation, > may reach into a > situation where you can almost predictably crash it, with a > simple modify > operation. > > > Please test RE24 and see if you can still reproduce this issue. > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP > http://www.openldap.org/____project/ > <http://www.openldap.org/__project/> > <http://www.openldap.org/__project/ > <http://www.openldap.org/project/>> > > > > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/__project/ > <http://www.openldap.org/project/> > > -- -- 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#8086) slapd with mdb backend crashes in id2entry
by nvoutsin＠gmail.com 04 Apr '15

04 Apr '15

--001a113513b628687b0512e2d415 Content-Type: text/plain; charset=UTF-8 I haven't compared the same build with and with out the fixes for ITS#7961,#7987, however I can confirm that under the same environment, RE24 (scheduled for 2.4.41) remains stable while 2.4.40 crashes from time to time. Actually I would strongly suggest upgrading to 2.4.41 when available. On Sun, Mar 22, 2015 at 9:36 PM, Howard Chu <hyc(a)symas.com> wrote: > Nikos Voutsinas wrote: > >> I am in the process of doing so. Do you have in mind a specific >> commit/fix in REL_EN that might have solved this; That would help me >> reproduce the initial problem (in 2.4.40) and confirm the fix (in >> REL_ENG). >> > > Most likely 9a72292ac134f80c1befe8102dee1160e57a92ec > >> >> For start I will try to upgrade to REL_ENG the same system from which I >> got the debug log, to see if that would help recover (although I have no >> great hopes). >> >> On Sun, Mar 22, 2015 at 12:39 AM, Howard Chu <hyc(a)symas.com >> <mailto:hyc@symas.com>> wrote: >> >> nvoutsin(a)gmail.com <mailto:nvoutsin@gmail.com> wrote: >> >> Full_Name: Nikos Voutsinas >> Version: 2.4.40 >> OS: Debian >> URL: >> ftp://ftp.openldap.org/__incoming/NikosVoutsinas_20-03- >> __2015_mdb_assertion.id2entry >> <ftp://ftp.openldap.org/incoming/NikosVoutsinas_20-03- >> 2015_mdb_assertion.id2entry> >> Submission from: (NULL) (5.55.167.101) >> >> >> slapd with an mdb backend, after some time of normal operation, >> may reach into a >> situation where you can almost predictably crash it, with a >> simple modify >> operation. >> >> >> Please test RE24 and see if you can still reproduce this issue. >> >> -- >> -- Howard Chu >> CTO, Symas Corp. http://www.symas.com >> Director, Highland Sun http://highlandsun.com/hyc/ >> Chief Architect, OpenLDAP http://www.openldap.org/__project/ >> <http://www.openldap.org/project/> >> >> >> > > -- > -- Howard Chu > CTO, Symas Corp. http://www.symas.com > Director, Highland Sun http://highlandsun.com/hyc/ > Chief Architect, OpenLDAP http://www.openldap.org/project/ > --001a113513b628687b0512e2d415 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I haven't compared the same build with and with out th= e fixes for ITS#7961,#7987, however I can confirm that under the same envir= onment, RE24 (scheduled for 2.4.41) remains stable while 2.4.40 crashes fro= m time to time. Actually I would strongly suggest upgrading to 2.4.41 when = available. </div><div class=3D"gmail_extra"> <div class=3D"gmail_quot= e">On Sun, Mar 22, 2015 at 9:36 PM, Howard Chu <<a hre= f=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com</a>> w= rote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;borde= r-left:1px #ccc solid;padding-left:1ex">Nikos Voutsinas wr= ote: <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> I am in the process of doing so. Do you have in mind a specific commit/fix in REL_EN that might have solved this; That would help me reproduce the initial problem (in 2.4.40) and confirm the fix (in REL_ENG).= </blockquote> Most likely 9a72292ac134f80c1befe8102dee1160e57a92ec <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> For start I will try to upgrade to REL_ENG the same system from which I got the debug log, to see if that would help recover (although I have no<br= > great hopes). On Sun, Mar 22, 2015 at 12:39 AM, Howard Chu <<a href=3D"mailto:hyc@syma= s.com" target=3D"_blank">hyc(a)symas.com</a> <mailto:<a href=3D"mailto:hyc@symas.com" target=3D"_blank">hyc(a)symas.com= </a>>> wrote: =C2=A0 =C2=A0 <a href=3D"mailto:nvoutsin@gmail.com" target=3D"_blank">nvout= sin(a)gmail.com</a> <mailto:<a href=3D"mailto:nvoutsin@gmail.com" target= =3D"_blank">nvoutsin(a)gmail.com</a>> wrote: =C2=A0 =C2=A0 =C2=A0 =C2=A0 Full_Name: Nikos Voutsinas =C2=A0 =C2=A0 =C2=A0 =C2=A0 Version: 2.4.40 =C2=A0 =C2=A0 =C2=A0 =C2=A0 OS: Debian =C2=A0 =C2=A0 =C2=A0 =C2=A0 URL: =C2=A0 =C2=A0 =C2=A0 =C2=A0 <a href=3D"ftp://ftp.openldap.org/__incoming/Ni= kosVoutsinas_20-03-__2015_mdb_assertion.id2entry" target=3D"_blank">ftp://f= tp.openldap.org/__incoming/NikosVoutsinas_20-03-__2015_mdb_as= sertion.id2entry</a> =C2=A0 =C2=A0 =C2=A0 =C2=A0 <<a href=3D"ftp://ftp.openldap.org/incoming/= NikosVoutsinas_20-03-2015_mdb_assertion.id2entry" target=3D"_blank">ftp://f= tp.openldap.org/incoming/NikosVoutsinas_20-03-2015_mdb_assert= ion.id2entry</a>> =C2=A0 =C2=A0 =C2=A0 =C2=A0 Submission from: (NULL) (5.55.167.101) =C2=A0 =C2=A0 =C2=A0 =C2=A0 slapd with an mdb backend, after some time of n= ormal operation, =C2=A0 =C2=A0 =C2=A0 =C2=A0 may reach into a =C2=A0 =C2=A0 =C2=A0 =C2=A0 situation where you can almost predictably cras= h it, with a =C2=A0 =C2=A0 =C2=A0 =C2=A0 simple modify =C2=A0 =C2=A0 =C2=A0 =C2=A0 operation. =C2=A0 =C2=A0 Please test RE24 and see if you can still reproduce this issu= e. =C2=A0 =C2=A0 -- =C2=A0 =C2=A0 =C2=A0 =C2=A0-- Howard Chu =C2=A0 =C2=A0 =C2=A0 =C2=A0CTO, Symas Corp. <a href=3D"http://www.symas.com= " target=3D"_blank">http://www.symas.com</a> =C2=A0 =C2=A0 =C2=A0 =C2=A0Director, Highland Sun <a href=3D"http://highlan= dsun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a> =C2=A0 =C2=A0 =C2=A0 =C2=A0Chief Architect, OpenLDAP <a href=3D"http://www.= openldap.org/__project/" target=3D"_blank">http://www.openldap.org/__</u= >project/</a> =C2=A0 =C2=A0 <<a href=3D"http://www.openldap.org/project/" target=3D"_b= lank">http://www.openldap.org/project/</a>> </blockquote><div class=3D"HOEnZb"><div class=3D"h5"> -- =C2=A0 -- Howard Chu =C2=A0 CTO, Symas Corp.=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<a href=3D"= http://www.symas.com" target=3D"_blank">http://www.symas.com</a> =C2=A0 Director, Highland Sun=C2=A0 =C2=A0 =C2=A0<a href=3D"http://highland= sun.com/hyc/" target=3D"_blank">http://highlandsun.com/hyc/</a> =C2=A0 Chief Architect, OpenLDAP=C2=A0 <a href=3D"http://www.openldap.org/p= roject/" target=3D"_blank">http://www.openldap.org/project/</a> </div></div></blockquote></div> </div> --001a113513b628687b0512e2d415--

1 0

Re: (ITS#8081) syncprov crash in syncprov_op_mod
by quanah＠zimbra.com 03 Apr '15

03 Apr '15

--On Saturday, April 04, 2015 1:03 AM +0300 Leonid Yuriev <leo(a)yuriev.ru> wrote: > I had saw a queer in the CHANGES of 2.4 branch, and also comment of > aecec6a75. > > Exactly: Fixed slapo-syncprov deadlock when autogroup is in use > (ITS#8063,ITS#8081) > > But really, this (ITS#8081) is NOT related to autogroup (ITS#8063). > This bug was introduced by 7561998f7 (ITS#6335, Quanah Gibson-Mount > <quanah(a)openldap.org>, 2009-10-30). ITS#6335 was introduced in OpenLDAP 2.4.20. So wouldn't this then affect all releases since 2.4.20? Just so I can note that. ;) Also 6335 was not introduced by me. I simply sync'd it from master to RE24. ;) commit 739f8d075394ee3e85c3f2de7aa4031b36f54c8f Author: Rein Tollevik <rein(a)openldap.org> Date: Fri Oct 16 17:27:18 2009 +0000 ITS#6335 Don't reuse a modtarget someone is about to remove --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8081) syncprov crash in syncprov_op_mod
by leo＠yuriev.ru 03 Apr '15

03 Apr '15

I had saw a queer in the CHANGES of 2.4 branch, and also comment of aecec6a75. Exactly: Fixed slapo-syncprov deadlock when autogroup is in use (ITS#8063,ITS#8081) But really, this (ITS#8081) is NOT related to autogroup (ITS#8063). This bug was introduced by 7561998f7 (ITS#6335, Quanah Gibson-Mount <quanah(a)openldap.org>, 2009-10-30). Yes, after ITS#8063 this bug could be seen as SIGSEGV. But before ITS#8063 the syncprov could `re-order` notifications of changes that are visible by a remote syncrepl. Under a highload (our use case) this makes possible to 'lost' a some changes by replication, and then spread this error to all nodes of ldap-cluster (I spent a lot of time to dig this). So, this is a INDEPENDENT (critical) bug in syncprov (not in autogroup), which is also present in 2.4.40 release and so on.

1 0

Re: (ITS#8090) libldap bugfix: Spurious initial LDAP_CONNECT_ERROR with LDAP_OPT_CONNECT_ASYNC enabled
by hyc＠symas.com 01 Apr '15

01 Apr '15

olli.salli(a)vincit.fi wrote: > Full_Name: Olli Salli > Version: git master > OS: Windows 8.1, Linux 3.18.10 > URL: ftp://ftp.openldap.org/incoming/olli-salli-150325.patch > Submission from: (NULL) (83.102.45.242) Thanks for the report, fixed now in master. > > We are working on an application which needs to perform some simple LDAP search > queries every once in a while. The application is running as a daemon in an > embedded server environment and has no user interface, and is instead remotely > controlled and configured via a control TCP connection. This includes the > configuration specifying the LDAP server address and port, and whether the LDAP > queries should be attempted at all (if there is no server available). We are > currently developing on Windows 8.1 with Visual Studio 2013 but will also run in > Linux environments. > > To ensure the control TCP connection stays alive at all times (and the daemon > otherwise functional), and to avoid using threads, whahave used the openldap > asynchronous APIs, including the asynchronous connect option - if the configured > LDAP server is unreachable, the initial search query can block for a very long > time otherwise. It is here that we have hit a small issue. > > When using LDAP_OPT_CONNECT_ASYNC, if the LDAP server is unreachable, the > initial request (e.g. using ldap_search_ext) does not block, which is correct. > However, this first call returns LDAP_CONNECT_ERROR. If we disregard this, and > continue reissuing the ldap_search_ext request periodically, following calls > correctly return LDAP_X_CONNECTING. Then when the NETWORK_TIMEOUT has elapsed, > LDAP_CONNECT_ERROR is returned again, which is correct. > > LDAP_CONNECT_ERROR might result in the first ldap_search_ext call from > legitimate error conditions in connect() even in asynchronous mode, for example > out-of-resource conditions (EADDRNOTAVAIL), or all local network interfaces > being down (ENETUNREACH), etc. These should be handled as fatal errors, but > would be impossible to distinguish from the false initial LDAP_CONNECT_ERROR > resulting from using LDAP_OPT_CONNECT_ASYNC. > > The issue seems to be in ldap_send_initial_request > (http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/…). > > When async connect is enabled what happens during the first request is: > 1) sd is initialized to AC_SOCKET_INVALID > 2) ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) is called to determine whether > there is already a connection, and to fetch its socket descriptor to sd > 3) as there is no connection, it returns -1 and sd stays AC_SOCKET_INVALID > 4) a new connection is formed using ldap_open_defconn() > 5) ldap_int_check_async_open( ld, sd ) is called, but sd is still > AC_SOCKET_INVALID, and thus the poll fails > 6) LDAP_CONNECT_ERROR is returned > > On successive calls, what happens is > 1) ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) returns success and a valid > socket descriptor > 2) opening a new connection is skipped > 3) ldap_int_check_async_open( ld, sd ) is called this time with a valid socket > descriptor > 4) the poll works as intended > > A simple fix is to simply reissue ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) > after opening the connection. This fixes the first poll to return > LDAP_X_CONNECTING as intended. This is implemented in the patch at the URL. A > perhaps more semantically correct alternative could be to return the created > socket descriptor from ldap_open_defconn(). > > -- -- 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#8093) Error string for LDAP_X_CONNECTING is missing
by hyc＠symas.com 01 Apr '15

01 Apr '15

mikko.auvinen(a)vincit.fi wrote: > Full_Name: Mikko Auvinen > Version: git master > OS: Windows 8.1 > URL: ftp://ftp.openldap.org/incoming/mikko-auvinen-150326.patch > Submission from: (NULL) (83.102.45.242) > > > ldap_search_ext() returns LDAP_X_CONNECTING when async connect attempt is > ongoing. > > ldap_err2string() is missing an error string for LDAP_X_CONNECTING so it's > returning "Unknown API error". > > Here's a patch that fixes this. > > Thanks, committed to master. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8092) slapd crash with sasl auxprop and empty suffix
by hyc＠symas.com 01 Apr '15

01 Apr '15

ryan(a)nardis.ca wrote: > Full_Name: Ryan Tandy > Version: master, 2.4 > OS: Debian > URL: > Submission from: (NULL) (24.68.37.4) > > > Based on a Debian bug report: https://bugs.debian.org/781162 > > ./configure --enable-spasswd > > cat > slapd.conf << EOF > include /usr/local/etc/openldap/schema/core.schema > include /usr/local/etc/openldap/schema/cosine.schema > database mdb > directory . > suffix "" > EOF > > slapadd -f slapd.conf << EOF > dn: dc=com > objectClass: domain > > dn: dc=example,dc=com > objectClass: domain > > dn: uid=test,dc=example,dc=com > objectClass: account > objectClass: simpleSecurityObject > userPassword: {SASL}test(a)EXAMPLE.COM > > EOF > > ldapwhoami -x -D uid=test,dc=example,dc=com > Enter LDAP Password: > > Program received signal SIGSEGV, Segmentation fault. > [Switching to Thread 0x7fffeebab700 (LWP 28815)] > __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210 > 210 ../sysdeps/x86_64/multiarch/../strcmp.S: No such file or directory. > (gdb) bt > #0 __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210 > #1 0x0000000000441689 in select_backend (dn=0x7fffeebaa1a8, noSubs=1) at > backend.c:704 > #2 0x000000000049c7c2 in slap_auxprop_lookup (glob_context=0x0, > sparams=0x7fffe0001cd0, flags=0, > user=0x7fffe0001861 "test(a)EXAMPLE.COM", ulen=16) at sasl.c:370 > #3 0x00007ffff7bc463b in _sasl_auxprop_lookup (sparams=0x7fffe0001cd0, > flags=flags@entry=0, > user=0x7fffe0001861 "test(a)EXAMPLE.COM", ulen=16) at ../../lib/auxprop.c:959 > #4 0x00007ffff7bc5467 in _sasl_auxprop_lookup_user_props > (oparams=0x7fffe0001330, flags=3, conn=0x7fffe0000ac0) > at ../../lib/canonusr.c:220 > #5 _sasl_canon_user_lookup (conn=conn@entry=0x7fffe0000ac0, > user=user@entry=0x7fffe0001460 "test(a)EXAMPLE.COM", > ulen=ulen@entry=0, flags=flags@entry=3, > oparams=oparams@entry=0x7fffe0001330) at ../../lib/canonusr.c:281 > #6 0x00007ffff7bc5d39 in auxprop_verify_password (conn=0x7fffe0000ac0, > userstr=0x7fffe0001460 "test(a)EXAMPLE.COM", > passwd=0x7fffe0002696 "asdf", service=<optimized out>, user_realm=<optimized > out>) at ../../lib/checkpw.c:159 > #7 0x00007ffff7bcee78 in _sasl_checkpass (conn=conn@entry=0x7fffe0000ac0, > user=0x7fffe0001460 "test(a)EXAMPLE.COM", > userlen=userlen@entry=16, pass=pass@entry=0x7fffe0002696 "asdf", > passlen=passlen@entry=4) > at ../../lib/server.c:1922 > #8 0x00007ffff7bd1e50 in sasl_checkpass (conn=0x7fffe0000ac0, user=<optimized > out>, userlen=16, > pas3D0x0x7fffe0002696 "asdf", passlen=4) at ../../lib/server.c:1989 > #9 0x000000000049e4db in chk_sasl (sc=0x8cac98, passwd=0x7fffeebaa8a0, > cred=0x7fffe0002700, text=0x7fffeebaaae0) > at sasl.c:990 > #10 0x0000000000535278 in lutil_passwd (passwd=0x7fffe0003188, > cred=0x7fffe0002700, schemes=0x0, text=0x7fffeebaaae0) > at passwd.c:327 > #11 0x0000000000474aa6 in slap_passwd_check (op=0x7fffe00026b0, > e=0x7fffe0002f28, a=0x7fffe0002fa8, > cred=0x7fffe0002700, text=0x7fffeebaaae0) at passwd.c:529 > #12 0x00000000005088e7 in mdb_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at > bind.c:120 > #13 0x00000000004584f6 in fe_op_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at > bind.c:383 > #14 0x0000000000457bb4 in do_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at > bind.c:205 > #15 0x000000000042f68a in connection_operation (ctx=0x7fffeebaabf0, > arg_v=0x7fffe00026b0) at connection.c:1134 > #16 0x000000000042fc3a in connection_read_thread (ctx=0x7fffeebaabf0, argv=0xc) > at connection.c:1280 > #17 0x00000000005401bf in ldap_int_thread_pool_wrapper (xpool=0x8b83c0) at > tpool.c:958 > #18 0x00007ffff74750a4 in start_thread (arg=0x7fffeebab700) at > pthread_create.c:309 > #19 0x00007ffff71aa04d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 > > I don't know how auxprop is intended to be configured; I'm going to follow up on > that when I have time. This is just about a segv that happens when > pwcheck_method is auxprop (the default) and the suffix is the empty string. Fundamentally this is a configuration error; you should not use SPASSWD with slapd's auxprop. I.e., slapd's auxprop is only intended for use when slapd handles all SASL authentication itself. Using SPASSWD means you're forwarding all SASL authentication to whatever external SASL mechanisms you have configured. In this particular case, slapd has forwarded the authentication request out to libsasl as you requested, and libsasl is forwarding it back into slapd's auxprop but without providing the context that slapd expects. Fixed now in master. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8096) man not up to date
by quanah＠zimbra.com 01 Apr '15

01 Apr '15

--On Wednesday, April 01, 2015 6:13 PM +0000 tim.menage(a)gmail.com wrote: > Full_Name: Timothee > Version: @(#) $OpenLDAP: slapd (Ubuntu) (Mar 17 2014 21:20:08) > OS: Linux ldap 3.16.0-31-generic #41~14.04.1-Ubuntu SMP Wed Feb 11 > 19:30:13 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux URL: > ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (89.225.242.54) > > > Hey, > > If i've understand, slapd is reading config file from /etc/ldap/slapd.d/ > so I just don\t understand why when i do man slapd.conf (as you tell to do > everywhere), why the first lines are: > The file /etc/ldap/slapd.conf contains configuration information for the > slapd(8) daemon. Because both slapd-config(5) and slapd.conf(5) are supported. If you want the man page for slapd-config(5), read that one. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8096) man not up to date
by tim.menage＠gmail.com 01 Apr '15

01 Apr '15

Full_Name: Timothee Version: @(#) $OpenLDAP: slapd (Ubuntu) (Mar 17 2014 21:20:08) OS: Linux ldap 3.16.0-31-generic #41~14.04.1-Ubuntu SMP Wed Feb 11 19:30:13 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.225.242.54) Hey, If i've understand, slapd is reading config file from /etc/ldap/slapd.d/ so I just don\t understand why when i do man slapd.conf (as you tell to do everywhere), why the first lines are: The file /etc/ldap/slapd.conf contains configuration information for the slapd(8) daemon. Thanks

1 0

(ITS#8095) Patch
by rouzier＠gmail.com 31 Mar '15

31 Mar '15

Full_Name: James Rouzier Version: OS: URL: ftp://ftp.openldap.org/incoming/james-rouzier-150331.patch Submission from: (NULL) (192.222.129.11) I am working on a proof of concept of a simple key value store service using lmdb as the back end. I am using sendfile to avoid an extra copy. I accomplished this by creating function to extract get the mmap ptr from the env so I can calculate the offset of data. I figured that function might be useful to the bigger community. If it does not fit in the bigger vision of lmdb it is fine not to include it. I, James Rouzier, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

Re: (ITS#8094) OpenLdap2.4 rpm for RHEL5.11
by quanah＠zimbra.com 30 Mar '15

30 Mar '15

--On Monday, March 30, 2015 12:49 PM +0000 shashikanthbussa(a)gmail.com wrote: > Full_Name: shashikanth.bussa > Version: 2.4 > OS: RHEL5.11 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (115.160.252.10) > > > Hi, > > Please letme know the rpm repo file for Openldap2.4 on RHEL5.11 as i > have not found the openldap2.4 version for RHEl 5.11. The OpenLDAP foundation only releases source. If you want pre-compiled builds, you can look at the builds provided by Symas or the LTB project. As the ITS system is only for reporting bugs, this ITS will be closed. In the future, questions such as this should be directed to the openldap-technical list. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8094) OpenLdap2.4 rpm for RHEL5.11
by shashikanthbussa＠gmail.com 30 Mar '15

30 Mar '15

Full_Name: shashikanth.bussa Version: 2.4 OS: RHEL5.11 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (115.160.252.10) Hi, Please letme know the rpm repo file for Openldap2.4 on RHEL5.11 as i have not found the openldap2.4 version for RHEl 5.11. and When i tried to install from source tar ball. i am facing issue with the Barkley DB. hecking for Berkeley DB major version in db.h... 4 checking for Berkeley DB minor version in db.h... 3 checking if Berkeley DB version supported by BDB/HDB backends... no configure: error: BerkeleyDB version incompatible with BDB/HDB backends ... Please help on the above

1 0

(ITS#8093) Error string for LDAP_X_CONNECTING is missing
by mikko.auvinen＠vincit.fi 26 Mar '15

26 Mar '15

Full_Name: Mikko Auvinen Version: git master OS: Windows 8.1 URL: ftp://ftp.openldap.org/incoming/mikko-auvinen-150326.patch Submission from: (NULL) (83.102.45.242) ldap_search_ext() returns LDAP_X_CONNECTING when async connect attempt is ongoing. ldap_err2string() is missing an error string for LDAP_X_CONNECTING so it's returning "Unknown API error". Here's a patch that fixes this.

1 0

Re: (ITS#8091) Updateref for openldap 2.4.39 not work
by michael＠stroeder.com 26 Mar '15

26 Mar '15

This is a cryptographically signed message in MIME format. --------------ms090909080601010706070208 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: quoted-printable betchenhuang(a)163.com wrote: > Updateref for openldap 2.4.39 not work > i configured updateref option in slapd.conf for consumer slapd, later i= restart > slapd Successfully, but when i add new record to consumer, it failed. t= his new > recored not refer to master slapd. > in log ,i found the return code 10 which means: > ldap_add: Referral (10) > referrals: > ldaps://xxx:xxx/uid=3Dmeixuan,ou=3DPeoples,dc=3Dhadoop,dc=3Dcom It seems you did not load slapo-chain in your configuration which impleme= nts=20 the consumer-side referral chasing. Therefore the consumer sends the refe= rral=20 back to your LDAP client. Read about chaining here: http://www.openldap.org/doc/admin24/overlays.html#Chaining See another config example here: http://www.openldap.org/faq/data/cache/1434.html The ITS is only used for bug reports. Please post configuration questions to the openldap-technical mailing lis= t. Ciao, Michael. --------------ms090909080601010706070208 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC DIEwggY0MIIEHKADAgECAgEeMA0GCSqGSIb3DQEBBQUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0wNzEwMjQyMTAxNTVaFw0xNzEwMjQyMTAxNTVaMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UE ChMNU3RhcnRDb20gTHRkLjErMCkGA1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUg U2lnbmluZzE4MDYGA1UEAxMvU3RhcnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0 ZSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQDHCYPMzi3YGrEp pC4Tq5a+ijKDjKaIQZZVR63UbxIP6uq/I0fhCu+cQhoUfE6ERKKnu8zPf1Jwuk0tsvVCk6U9 b+0UjM0dLep3ZdE1gblK/1FwYT5Pipsu2yOMluLqwvsuz9/9f1+1PKHG/FaR/wpbfuIqu54q zHDYeqiUfsYzoVflR80DAC7hmJ+SmZnNTWyUGHJbBpA8Q89lGxahNvuryGaC/o2/ceD2uYDX 9U8Eg5DpIpGQdcbQeGarV04WgAUjjXX5r/2dabmtxWMZwhZna//jdiSyrrSMTGKkDiXm6/3/ 4ebfeZuCYKzN2P8O2F/Xe2AC/Y7zeEsnR7FOp+uXAgMBAAGjggGtMIIBqTAPBgNVHRMBAf8E BTADAQH/MA4GA1UdDwEB/wQEAwIBBjAdBgNVHQ4EFgQUU3Ltkpzg2ssBXHx+ljVO8tS4UYIw HwYDVR0jBBgwFoAUTgvvGqRAW6UXaYcwyjRoQ9BBrvIwZgYIKwYBBQUHAQEEWjBYMCcGCCsG AQUFBzABhhtodHRwOi8vb2NzcC5zdGFydHNzbC5jb20vY2EwLQYIKwYBBQUHMAKGIWh0dHA6 Ly93d3cuc3RhcnRzc2wuY29tL3Nmc2NhLmNydDBbBgNVHR8EVDBSMCegJaAjhiFodHRwOi8v d3d3LnN0YXJ0c3NsLmNvbS9zZnNjYS5jcmwwJ6AloCOGIWh0dHA6Ly9jcmwuc3RhcnRzc2wu Y29tL3Nmc2NhLmNybDCBgAYDVR0gBHkwdzB1BgsrBgEEAYG1NwECATBmMC4GCCsGAQUFBwIB FiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kucGRmMDQGCCsGAQUFBwIBFihodHRw Oi8vd3d3LnN0YXJ0c3NsLmNvbS9pbnRlcm1lZGlhdGUucGRmMA0GCSqGSIb3DQEBBQUAA4IC AQAKgwh9eKssBly4Y4xerhy5I3dNoXHYfYa8PlVLL/qtXnkFgdtY1o95CfegFJTwqBBmf8py TUnFsukDFUI22zF5bVHzuJ+GxhnSqN2sD1qetbYwBYK2iyYA5Pg7Er1A+hKMIzEzcduRkIMm CeUTyMyikfbUFvIBivtvkR8ZFAk22BZy+pJfAoedO61HTz4qSfQoCRcLN5A0t4DkuVhTMXIz uQ8CnykhExD6x4e6ebIbrjZLb7L+ocR0y4YjCl/Pd4MXU91y0vTipgr/O75CDUHDRHCCKBVm z/Rzkc/b970MEeHt5LC3NiWTgBSvrLEuVzBKM586YoRD9Dy3OHQgWI270g+5MYA8GfgI/EPT 5G7xPbCDz+zjdH89PeR3U4So4lSXur6H6vp+m9TQXPF3a0LwZrp8MQ+Z77U1uL7TelWO5lAp sbAonrqASfTpaprFVkL4nyGH+NHST2ZJPWIBk81i6Vw0ny0qZW2Niy/QvVNKbb43A43ny076 khXO7cNbBIRdJ/6qQNq9Bqb5C0Q5nEsFcj75oxQRqlKf6TcvGbjxkJh8BYtv9ePsXklAxtm8 J7GCUBthHSQgepbkOexhJ0wP8imUkyiPHQ0GvEnd83129fZjoEhdGwXV27ioRKbj/cIq7JRX un0NbeY+UdMYu9jGfIpDLtUUGSgsg2zMGs5R4jCCBkUwggUtoAMCAQICAwtNUDANBgkqhkiG 9w0BAQUFADCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNV BAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0 Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBMB4XDTE0MDkyMzIw NDc1NVoXDTE1MDkyNDIyMDUxOFowXzEZMBcGA1UEDRMQNk0yWTdpOXpEdGU2alV3MDEdMBsG A1UEAwwUbWljaGFlbEBzdHJvZWRlci5jb20xIzAhBgkqhkiG9w0BCQEWFG1pY2hhZWxAc3Ry b2VkZXIuY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAynIH09fU597v4fg4 uwqFJDPUxQHV9qxrfM/c3veStPyYl0JorqKHrD+hfCNZ+Toy65NN9f9vO26WnnLoDF+FE2Dk Qi61iTgK5jZTr5dJG1WQkk698UNWO87lUWBRYYiUM7wC3ek2E0rzR99qIxE4dG9wws19F3KK JvNN8tMTyoPw5Vkw4qx2SW54WEBMx7oCXBIZPPDD8ovled6vDVweVSaYXFUbkxbKJR87Msih 34Ba+cM5SAHQNQ11jaSJjFeqbQnXjf0nESnvo0XIckc9w240w3jcgu6b5SIQBI2vv5TaIv7v KqNk0o+cGc9NnCw5/xD/OAB9Aj/qDca6NheHCQIDAQABo4IC2jCCAtYwCQYDVR0TBAIwADAL BgNVHQ8EBAMCBLAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTj z1BhELZO3zEJfmZQ4I+c6NCXIjAfBgNVHSMEGDAWgBRTcu2SnODaywFcfH6WNU7y1LhRgjAf BgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTCCAUwGA1UdIASCAUMwggE/MIIBOwYL KwYBBAGBtTcBAgMwggEqMC4GCCsGAQUFBwIBFiJodHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9w b2xpY3kucGRmMIH3BggrBgEFBQcCAjCB6jAnFiBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1 dGhvcml0eTADAgEBGoG+VGhpcyBjZXJ0aWZpY2F0ZSB3YXMgaXNzdWVkIGFjY29yZGluZyB0 byB0aGUgQ2xhc3MgMSBWYWxpZGF0aW9uIHJlcXVpcmVtZW50cyBvZiB0aGUgU3RhcnRDb20g Q0EgcG9saWN5LCByZWxpYW5jZSBvbmx5IGZvciB0aGUgaW50ZW5kZWQgcHVycG9zZSBpbiBj b21wbGlhbmNlIG9mIHRoZSByZWx5aW5nIHBhcnR5IG9ibGlnYXRpb25zLjA2BgNVHR8ELzAt MCugKaAnhiVodHRwOi8vY3JsLnN0YXJ0c3NsLmNvbS9jcnR1MS1jcmwuY3JsMIGOBggrBgEF BQcBAQSBgTB/MDkGCCsGAQUFBzABhi1odHRwOi8vb2NzcC5zdGFydHNzbC5jb20vc3ViL2Ns YXNzMS9jbGllbnQvY2EwQgYIKwYBBQUHMAKGNmh0dHA6Ly9haWEuc3RhcnRzc2wuY29tL2Nl cnRzL3N1Yi5jbGFzczEuY2xpZW50LmNhLmNydDAjBgNVHRIEHDAahhhodHRwOi8vd3d3LnN0 YXJ0c3NsLmNvbS8wDQYJKoZIhvcNAQEFBQADggEBAAfByd9CEZ5pYuRa3XuE5xeJoIpDol22 A1mIGuRqxaBFIummmDoYr/tVgFod/3evQJO+ad8T5wpooY422HkHN4a1UI7ujCKcU/PrQSxm v28AAsl4Fo/InY1nSFjMy8Ywj3EG+Edj1ZpCkzTRNGZjBa6Uj7UY7UW71kYcSdCBe8vc9Zi3 6OnHGkXROWIii3wBKLDEZqxknw0Cj9TTy5lyllYzyHku4aXLDPhiYrTzhWiwgYmweaLvW/yq YVsHRpW8udzqOr6xvUVcuRmfMTENM7RSlRZVw2+5+I+zn7jqOrrULO1FP7Lo5cPilsMpSMOw oJnPLQgNZvXOPFO6VaDCOboxggPtMIID6QIBATCBlDCBjDELMAkGA1UEBhMCSUwxFjAUBgNV BAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNlY3VyZSBEaWdpdGFsIENlcnRpZmljYXRl IFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENsYXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlh dGUgQ2xpZW50IENBAgMLTVAwDQYJYIZIAWUDBAIBBQCgggIpMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTE1MDMyNjA3MDMwNFowLwYJKoZIhvcNAQkEMSIE INUwr+VrzD6DxfJr7U+Sku8f+I6JqX5ty0KBRXsQe1eUMGwGCSqGSIb3DQEJDzFfMF0wCwYJ YIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAKBggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYI KoZIhvcNAwICAUAwBwYFKw4DAgcwDQYIKoZIhvcNAwICASgwgaUGCSsGAQQBgjcQBDGBlzCB lDCBjDELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKzApBgNVBAsTIlNl Y3VyZSBEaWdpdGFsIENlcnRpZmljYXRlIFNpZ25pbmcxODA2BgNVBAMTL1N0YXJ0Q29tIENs YXNzIDEgUHJpbWFyeSBJbnRlcm1lZGlhdGUgQ2xpZW50IENBAgMLTVAwgacGCyqGSIb3DQEJ EAILMYGXoIGUMIGMMQswCQYDVQQGEwJJTDEWMBQGA1UEChMNU3RhcnRDb20gTHRkLjErMCkG A1UECxMiU2VjdXJlIERpZ2l0YWwgQ2VydGlmaWNhdGUgU2lnbmluZzE4MDYGA1UEAxMvU3Rh cnRDb20gQ2xhc3MgMSBQcmltYXJ5IEludGVybWVkaWF0ZSBDbGllbnQgQ0ECAwtNUDANBgkq hkiG9w0BAQEFAASCAQA77XDFu6SAsZn0FmyMD2rRN73NV6nvP7h6O9ppe+H2J0S4+hGmTotu VPLZ7Sc9V1Ybv1xqFXjhwjzuVkKFHn7h+iN+OF4ejzdOVuHI/YIZNepZiBMS0cQKuEachzBQ S42su/6Cs22EzIUB0QrvD0hSI4Ijwwa8bmUh24DP08hnlbZGf7pJoYUjdZv7vNPWpm15TMTD ZJKHJHyqA+0gYW4HKYRsncLL9x0ZN60EMI95J6n4S3NeQt5ccibsL+nhzVch20fZufWTufO9 CpNtlYUXs+6C/IJ3kkgLSnnzCHNmT9lOiE7/S3svyBhM/Lq6ATtG716LKJjcQ/LvQNF60oCB AAAAAAAA --------------ms090909080601010706070208--

1 0

(ITS#8092) slapd crash with sasl auxprop and empty suffix
by ryan＠nardis.ca 26 Mar '15

26 Mar '15

Full_Name: Ryan Tandy Version: master, 2.4 OS: Debian URL: Submission from: (NULL) (24.68.37.4) Based on a Debian bug report: https://bugs.debian.org/781162 ./configure --enable-spasswd cat > slapd.conf << EOF include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema database mdb directory . suffix "" EOF slapadd -f slapd.conf << EOF dn: dc=com objectClass: domain dn: dc=example,dc=com objectClass: domain dn: uid=test,dc=example,dc=com objectClass: account objectClass: simpleSecurityObject userPassword: {SASL}test(a)EXAMPLE.COM EOF ldapwhoami -x -D uid=test,dc=example,dc=com Enter LDAP Password: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffeebab700 (LWP 28815)] __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210 210 ../sysdeps/x86_64/multiarch/../strcmp.S: No such file or directory. (gdb) bt #0 __strcmp_ssse3 () at ../sysdeps/x86_64/multiarch/../strcmp.S:210 #1 0x0000000000441689 in select_backend (dn=0x7fffeebaa1a8, noSubs=1) at backend.c:704 #2 0x000000000049c7c2 in slap_auxprop_lookup (glob_context=0x0, sparams=0x7fffe0001cd0, flags=0, user=0x7fffe0001861 "test(a)EXAMPLE.COM", ulen=16) at sasl.c:370 #3 0x00007ffff7bc463b in _sasl_auxprop_lookup (sparams=0x7fffe0001cd0, flags=flags@entry=0, user=0x7fffe0001861 "test(a)EXAMPLE.COM", ulen=16) at ../../lib/auxprop.c:959 #4 0x00007ffff7bc5467 in _sasl_auxprop_lookup_user_props (oparams=0x7fffe0001330, flags=3, conn=0x7fffe0000ac0) at ../../lib/canonusr.c:220 #5 _sasl_canon_user_lookup (conn=conn@entry=0x7fffe0000ac0, user=user@entry=0x7fffe0001460 "test(a)EXAMPLE.COM", ulen=ulen@entry=0, flags=flags@entry=3, oparams=oparams@entry=0x7fffe0001330) at ../../lib/canonusr.c:281 #6 0x00007ffff7bc5d39 in auxprop_verify_password (conn=0x7fffe0000ac0, userstr=0x7fffe0001460 "test(a)EXAMPLE.COM", passwd=0x7fffe0002696 "asdf", service=<optimized out>, user_realm=<optimized out>) at ../../lib/checkpw.c:159 #7 0x00007ffff7bcee78 in _sasl_checkpass (conn=conn@entry=0x7fffe0000ac0, user=0x7fffe0001460 "test(a)EXAMPLE.COM", userlen=userlen@entry=16, pass=pass@entry=0x7fffe0002696 "asdf", passlen=passlen@entry=4) at ../../lib/server.c:1922 #8 0x00007ffff7bd1e50 in sasl_checkpass (conn=0x7fffe0000ac0, user=<optimized out>, userlen=16, pas3D0x0x7fffe0002696 "asdf", passlen=4) at ../../lib/server.c:1989 #9 0x000000000049e4db in chk_sasl (sc=0x8cac98, passwd=0x7fffeebaa8a0, cred=0x7fffe0002700, text=0x7fffeebaaae0) at sasl.c:990 #10 0x0000000000535278 in lutil_passwd (passwd=0x7fffe0003188, cred=0x7fffe0002700, schemes=0x0, text=0x7fffeebaaae0) at passwd.c:327 #11 0x0000000000474aa6 in slap_passwd_check (op=0x7fffe00026b0, e=0x7fffe0002f28, a=0x7fffe0002fa8, cred=0x7fffe0002700, text=0x7fffeebaaae0) at passwd.c:529 #12 0x00000000005088e7 in mdb_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at bind.c:120 #13 0x00000000004584f6 in fe_op_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at bind.c:383 #14 0x0000000000457bb4 in do_bind (op=0x7fffe00026b0, rs=0x7fffeebaaac0) at bind.c:205 #15 0x000000000042f68a in connection_operation (ctx=0x7fffeebaabf0, arg_v=0x7fffe00026b0) at connection.c:1134 #16 0x000000000042fc3a in connection_read_thread (ctx=0x7fffeebaabf0, argv=0xc) at connection.c:1280 #17 0x00000000005401bf in ldap_int_thread_pool_wrapper (xpool=0x8b83c0) at tpool.c:958 #18 0x00007ffff74750a4 in start_thread (arg=0x7fffeebab700) at pthread_create.c:309 #19 0x00007ffff71aa04d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:111 I don't know how auxprop is intended to be configured; I'm going to follow up on that when I have time. This is just about a segv that happens when pwcheck_method is auxprop (the default) and the suffix is the empty string.

1 0

(ITS#8091) Updateref for openldap 2.4.39 not work
by betchenhuang＠163.com 26 Mar '15

26 Mar '15

Full_Name: marix wong Version: 2.4.39 OS: redhat 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (119.145.14.210) Updateref for openldap 2.4.39 not work i configured updateref option in slapd.conf for consumer slapd, later i restart slapd Successfully, but when i add new record to consumer, it failed. this new recored not refer to master slapd. in log ,i found the return code 10 which means: ldap_add: Referral (10) referrals: ldaps://xxx:xxx/uid=meixuan,ou=Peoples,dc=hadoop,dc=com this is my configuration: syncrepl rid=124 provider=ldaps://167.52.0.35:21780 type=refreshAndPersist%0 interval=00:00:00:15 searchbase="dc=hadoop,dc=com" filter="(objectClass=*)" scope=sub attrs="*,+" tls_reqcert=allow tls_cacert=/opt/cert/cacert.pem schemachecking=off bindmethod=simple binddn="cn=root,dc=hadoop,dc=com" credentials=Ldap@123 retry="15 +" updateref ldaps://167.52.0.35:21780 so i want to know how to make this option work better?

1 0

(ITS#8090) libldap bugfix: Spurious initial LDAP_CONNECT_ERROR with LDAP_OPT_CONNECT_ASYNC enabled
by olli.salli＠vincit.fi 25 Mar '15

25 Mar '15

Full_Name: Olli Salli Version: git master OS: Windows 8.1, Linux 3.18.10 URL: ftp://ftp.openldap.org/incoming/olli-salli-150325.patch Submission from: (NULL) (83.102.45.242) We are working on an application which needs to perform some simple LDAP search queries every once in a while. The application is running as a daemon in an embedded server environment and has no user interface, and is instead remotely controlled and configured via a control TCP connection. This includes the configuration specifying the LDAP server address and port, and whether the LDAP queries should be attempted at all (if there is no server available). We are currently developing on Windows 8.1 with Visual Studio 2013 but will also run in Linux environments. To ensure the control TCP connection stays alive at all times (and the daemon otherwise functional), and to avoid using threads, whahave used the openldap asynchronous APIs, including the asynchronous connect option - if the configured LDAP server is unreachable, the initial search query can block for a very long time otherwise. It is here that we have hit a small issue. When using LDAP_OPT_CONNECT_ASYNC, if the LDAP server is unreachable, the initial request (e.g. using ldap_search_ext) does not block, which is correct. However, this first call returns LDAP_CONNECT_ERROR. If we disregard this, and continue reissuing the ldap_search_ext request periodically, following calls correctly return LDAP_X_CONNECTING. Then when the NETWORK_TIMEOUT has elapsed, LDAP_CONNECT_ERROR is returned again, which is correct. LDAP_CONNECT_ERROR might result in the first ldap_search_ext call from legitimate error conditions in connect() even in asynchronous mode, for example out-of-resource conditions (EADDRNOTAVAIL), or all local network interfaces being down (ENETUNREACH), etc. These should be handled as fatal errors, but would be impossible to distinguish from the false initial LDAP_CONNECT_ERROR resulting from using LDAP_OPT_CONNECT_ASYNC. The issue seems to be in ldap_send_initial_request (http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=libraries/…). When async connect is enabled what happens during the first request is: 1) sd is initialized to AC_SOCKET_INVALID 2) ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) is called to determine whether there is already a connection, and to fetch its socket descriptor to sd 3) as there is no connection, it returns -1 and sd stays AC_SOCKET_INVALID 4) a new connection is formed using ldap_open_defconn() 5) ldap_int_check_async_open( ld, sd ) is called, but sd is still AC_SOCKET_INVALID, and thus the poll fails 6) LDAP_CONNECT_ERROR is returned On successive calls, what happens is 1) ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) returns success and a valid socket descriptor 2) opening a new connection is skipped 3) ldap_int_check_async_open( ld, sd ) is called this time with a valid socket descriptor 4) the poll works as intended A simple fix is to simply reissue ber_sockbuf_ctrl( ... LBER_SB_OPT_GET_FD ... ) after opening the connection. This fixes the first poll to return LDAP_X_CONNECTING as intended. This is implemented in the patch at the URL. A perhaps more semantically correct alternative could be to return the created socket descriptor from ldap_open_defconn().

1 0

(ITS#8089) LMDB hangs on mdb_txn_renew0 if MDB_NOSYNC flag is used
by pk＠dbic.pro 24 Mar '15

24 Mar '15

Full_Name: Pavel Kraynyukhov Version: only LMDB from git and lmdb-0.9.14 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (37.99.47.171) Hello there, I have ran into an issue with LMDB, which I can reproduce at will, but it seems a specific one. The git commit is 3368d1f5e243225cba4d730fba19ff600798ebe3 And this commit and my issue seems to be related. 1. I use MDB_NOTLS flag on environment open. 2. if I use MDB_NOSYNC flag for LMDB environment, the writer thread is stuck after several transactions (writer thread backtrace): #0 0x00007fe5534a25dc in __lll_robust_lock_wait () from /lib64/libpthread.so.0 #1 0x00007fe553498ba1 in __pthread_mutex_lock_full () from /lib64/libpthread.so.0 #2 0x00007fe553ed895a in mdb_txn_renew0 (txn=txn@entry=0x661810) at mdb.c:2638 #3 0x00007fe553ed9558 in mdb_txn_begin (env=0x6606c0, parent=0x0, flags=<optimized out>, ret=0x7fe552bebd08) at mdb.c:2813 #4 0x000000000041cd0c in beginWOTxn (parent=0x0, this=0x6603a8) at ../ITCFramework/include/LMDBEnv.h:220 #5 itc::lmdb::WOTxn::WOTxn (this=0x7fe552bebdb0, ref=...) at ../ITCFramework/include/LMDBWOTxn.h:51 #6 0x0000000000420c5b in itc::lmdb::DBWriter::dbWrite (this=this@entry=0x661b08) at ../ITCFramework/include/LMDBWriter.h:185 #7 0x00000000004210ff in itc::lmdb::DBWriter::execute (this=0x661b08) at ../ITCFramework/include/LMDBWriter.h:98 #8 0x0000000000414eac in itc::sys::CancelableThread<itc::lmdb::DBWriter>::run (this=0x7ffff31f7cd0) at ../ITCLib/include/sys/CancelableThread.h:84 #9 0x0000000000439dc4 in itc::sys::invoke (context=0x7ffff31f7cd0) at src/Thread.cpp:56 #10 0x00007fe55349b4c6 in start_thread () from /lib64/libpthread.so.0 #11 0x00007fe5531e000d in clone () from /lib64/libc.so.6 Before you might ask: 1. There is only one writer thread. Only this thread begins writable transactions and only this thread commits them and of course only this thread calls mdb_put(). 2. There suppose to be a multiple reader threads. For the test I'm running one only. And there are no read operations or cursor usage during this test at the same time when the writer is working. 3. When I write hang, I mean only the application not the system. The test application consume no CPU after it hang. 4. If no MDB_NOSYNC flag is used, then there is no bug/deadlock. This however may be due to very slow file system operations of my PC. It is about 35 writable transactions per second and about 27-39% I/O wait on the CPU. P.S. tested against system provided lmdb version 0.9.14 and result is the same. So this maybe not related to latest commit in git.

1 0

(ITS#8088) slapd man pages get installed when --disable-slapd is specified
by quanah＠openldap.org 24 Mar '15

24 Mar '15

Full_Name: Quanah Gibson-Mount Version: RE24 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.64.214) When only building out the client libraries (--disable-slapd), make install goes ahead and installs the man pages related to slapd, which should be skipped in this case.

1 0

(ITS#8087) Segmentation fault in MDB at idl.c:91 using searches
by francisco＠garnelo.eu 24 Mar '15

24 Mar '15

Full_Name: Francisco Garnelo Version: slapd 2.4.40 OS: FreeBSD 10.1-STABLE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.21) Hi, when I try to access with a LDAP browser (Apache DS) and the browser begin to enumerate the items in differents branches, the server crashes; this not takes more than 30 seconds from last restart. I experimented a similar issue with SLES 12(if not it is the same) and openldap 2.4.40 (from suse repositories) version, but in this system I could not take evidences. The database has more than 3GB of size and MDB is configured to support 100GB as the maximum size. The same databa w works fine ining BDB using an old openldap version. ############# # Versions: # ############# root@XXXX:/usr/local/etc/openldap # /usr/local/libexec/slapd -VVV @(#) $OpenLDAP: slapd 2.4.40 (Mar 24 2015 17:18:46) $ root@XXXX:/usr/rtrts/net/openldap24-server/work/openldap-2.4.40/servers/slapd Included static overlays: dynlist seqmod syncprov Included static backends: config ldif relay root@xxxx:/usr/local/etc/openldap # uname -a FreeBSD xxxx 10.1-STABLE FreeBSD 10.1-STABLE #0 r278906: Tue Feb 17 19:09:13 UTC 2015 root@releng1.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 ###################### # cn=config export: # ###################### version: 1 dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/openldap/slapd.args olcAttributeOptions: lang- olcAuthzPolicy: none olcConfigDir: slapd.d olcConfigFile: slapd.conf olcIdleTimeout: 0 olcIndexIntLen: 8 olcIndexSubstrAnyLen: 4 olcIndexSubstrAnyStep: 2 olcIndexSubstrIfMaxLen: 4 olcIndexSubstrIfMinLen: 2 olcListenerThreads: 1 olcLocalSSF: 71 olcLogLevel: 0 olcPidFile: /var/run/openldap/slapd.pid olcReadOnly: FALSE olcReverseLookup: FALSE olcSizeLimit: unlimited olcThreads: 20 olcTLSCACertificateFile: /usr/local/etc/openldap/certs/public/ca.crt olcTLSCertificateFile: /usr/local/etc/openldap/certs/public/server.crt olcTLSCertificateKeyFile: /usr/local/etc/openldap/certs/private/server.key olcTLSCRLCheck: none olcTLSProtocolMin: 0.0 olcTLSVerifyClient: never olcToolThreads: 2 olcWriteTimeout: 0 dn: cn=module{0},cn=config objectClass: olcModuleList cn: module{0} olcModuleLoad: {0}back_mdb database config olcModulePath: /usr/local/libexec/openldap dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema ### -- omitted content -- ### include /usr/local/etc/openldap/schema/core.schema include /usr/local/etc/openldap/schema/cosine.schema include /usr/local/etc/openldap/schema/inetorgperson.schema include /r%r/local/etc/openldap/schema/rfc2307bis.schema ### -- omitted content -- ### dn: olcDatabase={-1}frontend,cn=config objectClass: olcFrontendConfig objectClass: olcDatabaseConfig olcDatabase: {-1}frontend olcAccess: {0}to dn.base="" by * read olcAccess: {1}to dn.base%%2"cn=subsemema" by * read olcAccess: {2}to attrs=shadowLastChange by self write by * read olcAccess: {3}to * by * read olcAddContentAcl: FALSE olcLastMod: TRUE olcMaxDerefDepth: 0 olcMonitoring: FALSE olcReadOnly: FALSE olcSchemaDN: cn=Subschema olcSizeLimit: unlimited olcSyncUseSubentry: FALSE dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcAccess: {0}to * by * none olcAddContentAcl: TRUE olcLastMod: TRUE olcMaxDerefDepth: 15 olcMonitoring: FALSE olcReadOnly: FALSE olcRootDN: cn=config olcRootPW: XXXXX olcSyncUseSubentry: FALSE dn: olcDatabase={1}mdb,cn=config objectClass: olcMdbConfig objectClass: olcDatabaseConfig olcDatabase: {1}mdb olcDbDirectory:2F2Fvar/db/openldap-data.mdb olcDbIndex: objectClass eq olcRootDN: cn=lalala,dc=yyyyyyy,dc=com olcRootPW: XXXXXXX olcSuffix: dc=yyyyyyy,dc=com ######## # GDB: # ######## 551194b6 => mdb_dn2id("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,%3=com") 551194b6 <= mdb_entry_decode 551194b6 <= mdb_dn2id: got id=0x92b0 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 mdb_dn2entry("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b6 => mdb_entry_decode: 551194b6 => mdb_dn2id("lelreleID=6666999999(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_dn2id: got id=0x92b0 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 <=dbdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b6 => mdb_entry_decode: 551194b6 <= mdb_entry_decode 551194b6 <= mdb_entry_decode 551194b6 mdb_dn2entry("lelreleID=luser123(a)odin.lala,ou=molon,dc=yyyyyyy,dc=com") 551194b8 => mdb_dn2id("lelreleID=luser123(a)odin.lala,ou=molon,dc=yyyyyyy,dc=com") 551194b8 <= mdb_dn2id: got id=0x931e 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b6 => mdb_entry_decode: 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 <= mdb_entry_decode 551194b7 daemon: activity on 1 descriptor 551194b8 daemon: activity on:519194b8 11r551194b8 551194b8 daemon: read activity on 11 551194b8 mdb_dn2entry("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b8 => mdb_dn2id("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b7 => mdb_entry_decode: 551194b7 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 <= mdb_dn2id: got id=0x9321 551194b8 mdb_dn2entry("loloId=50,ou=fry,dc=yyyyyyy,dc=com") 551194b8 => mdb_entry_decode: 551194b8 => mdb_dn2id("loloId=50,ou=fry,dc=yyyyyyy,dc=com") 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 daemon: select: listen=6 active_threads=0 tvp=NULL 551194b8 daemon: select: listen=7 active_threads=0 tvp=NULL 551194b8 <= mdb_dn2id: got id=0xf 551194b6 <= mdb_entry_decode 551194b8 => mdb_entry_dece:3A 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 <= mdb_entry_decode 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 mdb_dn2entry("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b8 => mdb_dn2id("lelreleID=6666999990(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b8 <= mdb_entry_decode 551194b8 mdb_dn2entry("lelreleID=262280000000000(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 <= mdb_dn2id: got id=0x9321 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 => mdb_dn2id("lelreleID=262280000000000(a)lol.com,ou=molon,dc=yyyyyyy,dc=com") 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 <= mdb_dn2id: got id=0x25 551194b8 => mdb_entry_decode: 551194b8 <= mdb_entry_decode 551194b8 => mdb_entry_decode: 551194b8 mdb_dn2entry("loloId=50,ou=fry,dc=yyyyyyy,dc=com") 551194b8 <= mdb_entry_decode [New Thread 2103c12400 (LWP 100750/slapd)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 2103c12400 (LWP 100750/slapd)] 0x00000008024a579f in mdb_idl_search (ids=0x210a980000, id=37) at idl.c:91 91 val = IDL_CMP( id, ids[cursor] ); Current language: auto; currently minimal -------------- Thanks, Francisco Garnelo

1 0

Re: (ITS#7008) paged results against ldap-proxy errors with 'cookie is invalid'
by whm＠stanford.edu 23 Mar '15

23 Mar '15

This one just bit us again. I know that the client should probably not be using pr at all, but the client is an Google supplied intergration application that we have little control over. Is this a problem that is going to be addressed as some point or will it be treated as a known limitation? Bill -- "We have meet the enemy and he is us." Pogo

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs