- openldap-bugs - openldap.org

(ITS#6126) test054-syncreplication-parallel-load failed: producer and consumer databases differ
by michael＠stroeder.com 14 May '09

14 May '09

Full_Name: Michael Ströder Version: RE24 OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.105.68) >>>>> Starting test054-syncreplication-parallel-load ... running defines.sh Starting producer slapd on TCP/IP port 9011... Using ldapsearch to check that producer slapd is running... Using ldapadd to create the context prefix entry in the producer... Starting consumer slapd on TCP/IP port 9014... Using ldapsearch to check that consumer slapd is running... Using ldapadd to populate the producer directory... Waiting 7 seconds for syncrepl to receive changes... Stopping the provider, sleeping 10 seconds and restarting it... Using ldapsearch to check that producer slapd is running... Waiting 10 seconds to let the system catch up Using ldapmodify to modify producer directory... Using ldappasswd to change some passwords... Waiting 7 seconds for syncrepl to receive changes... Stopping consumer to test recovery... Modifying more entries on the producer... Restarting consumer... Waiting 7 seconds for syncrepl to receive changes... Try updating the consumer slapd... Trying to change some passwords on the consumer... Waiting 7 seconds for syncrepl to receive changes... Using ldapsearch to read all the entries from the producer... Using ldapsearch to read all the entries from the consumer... Filtering producer results... Filtering consumer results... Comparing retrieved entries from producer and consumer... test failed - producer and consumer databases differ >>>>> ./scripts/test054-syncreplication-parallel-load failed (exit 1) make[2]: *** [hdb-yes] Error 1 make[2]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make[1]: *** [test] Error 2 make[1]: Leaving directory `/usr/src/michael/openldap/OPENLDAP_REL_ENG_2_4/openldap/tests' make: *** [test] Error 2

1 0

(ITS#6125) back-sql support via Windows API ODBC
by slapd＠hannebauer.name 14 May '09

14 May '09

Full_Name: Christoph Hannebauer Version: 2.4.16 OS: Windows/cygwin URL: www.hannebauer.name/openldap-sql/configure.in.patch Submission from: (NULL) (77.189.227.183) I wasn't able to build slapd with back-sql in cygwin, because libodbc32 is not detected by configure. The console prints the error configure: error: could not locate suitable ODBC library and config.log contains: configure:31357: mgcc -o conftest.exe -g -O2 -I/usr/local/mingw/include -L/usr/local/mingw/lib conftest.c -lodbc32 >&5 /cygdrive/c/Users/CHANNE~1/AppData/Local/Temp/ccy74wDp.o: In function `main': /cygdrive/d/TestProgs/openldap-2.4.16/conftest.c:81: undefined reference to `_SQLDriverConnect' This means there is a library libodbc32, but it doesn't define SQLDriverConnect as a _cdecl function. When the current configure script searches for an ODBC library, it only checks whether one of the libraries iodbc, odbc, or odbc32 has SQLDriverConnect defined as _cdecl, which is not the case if odbc32 provides its functions as _stdcall. All Windows API functions are mangled as _stdcall functions, so I assume this error occurs on most MSYS and cygwin systems. With the attached patch, configure uses windows.h and sqlext.h to compile SQLDriverConnect and then tries to link it with -lodbc32 if no other ODBC library can be linked. This way, SQLDriverConnect is compiled the way sqlext.h defines it, which is _stdcall in case of cygwin. I have tested the patch in my environment: slapd with back-sql builds successfully. Glueck & Kanja Consulting AG (www.glueckkanja.com) hereby places 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

(ITS#6118) Misleading LDAP URL example in man-page slapo-constraint.5
by michael＠stroeder.com 14 May '09

14 May '09

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.105.68) HI! I'd consider this example in the man-page of slapo-constraint to be problematic because the constrained attribute type is the same like the attribute type used for the valid values. constraint_attribute title uri ldap:///dc=catalog,dc=example,dc=com?title?sub?(objectClass=titleCatalog) Off course this would work if dc=catalog,dc=example,dc=com would be in a separate database but this is rather unlikely in common setups. So I'd recommend to make this clear. Ciao, Michael.

1 0

Re: (ITS#6117) Segfault in hdb_index_mask
by hyc＠symas.com 14 May '09

14 May '09

Luca Scamoni wrote: > Howard Chu ha scritto: >> >> In frame 1 print *ap >> > p *ap > $1 = {a_desc = 0x0, a_vals = 0x0, a_nvals = 0x0, a_numvals = 0, a_flags > = 0, a_next = 0x54149adc} Your frame 1 is pretty much impossible - you have oldattrs == newattrs, but in frame 2 the attr list was replaced by a duplicate (using attrs_dup, modify.c:94). Perhaps you've got a compiler bug. -- -- 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#6117) Segfault in hdb_index_mask
by luca.scamoni＠sys-net.it 14 May '09

14 May '09

Howard Chu ha scritto: > > In frame 1 print *ap > p *ap $1 = {a_desc = 0x0, a_vals = 0x0, a_nvals = 0x0, a_numvals = 0, a_flags = 0, a_next = 0x54149adc} Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. Gruppo Partners Associates via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

Re: (ITS#6117) Segfault in hdb_index_mask
by hyc＠symas.com 14 May '09

14 May '09

luca(a)OpenLDAP.org wrote: > Full_Name: Luca Scamoni > Version: 2.4.16 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (82.63.140.131) > > > Master segfaulted in hdb_index_mask. For some reason desc is NULL. > Backtrace: In frame 1 print *ap > #0 0x00de2d92 in hdb_index_mask (be=0x236ec90, desc=0x0, atname=0x236e958) at > index.c:47 > at = (AttributeType *) 0x99f5f48 > ai = (AttrInfo *) 0x0 > #1 0x00dd8ca5 in bdb_modify_idxflags (op=0x9c16a28, desc=0x9af4078, > got_delete=1, newattrs=0x5414fdac, oldattrs=0x5414fdac) at modify.c:54 > ap = (Attribute *) 0x5414fdac > ix2 = {bv_len = 0, bv_val = 0x2370104 ""} > ix_at = {bv_len = 25, bv_val = 0x99f5998 "certificateRevocationList"} > ai = (AttrInfo *) 0x9ab07c0 -- -- 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#6117) Segfault in hdb_index_mask
by luca.scamoni＠sys-net.it 14 May '09

14 May '09

Last lines in log file May 14 07:50:25 quercia01 slapd[29850]: conn=57 op=68 MOD dn="cn=CRL7,ou=Regione Lombardia Certification Authority Cittadini,o=Regione Lombardia,c=IT,dc=a,dc =prod,dc=actalis" May 14 07:50:25 quercia01 slapd[29850]: conn=57 op=68 MOD attr=certificateRevocationList;binary May 14 07:50:25 quercia01 slapd[29850]: slap_queue_csn: queing 0x236e980 20090514055025.683019Z#000000#000#000000 Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. Gruppo Partners Associates via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

(ITS#6117) Segfault in hdb_index_mask
by luca＠OpenLDAP.org 14 May '09

14 May '09

Full_Name: Luca Scamoni Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Master segfaulted in hdb_index_mask. For some reason desc is NULL. Backtrace: #0 0x00de2d92 in hdb_index_mask (be=0x236ec90, desc=0x0, atname=0x236e958) at index.c:47 at = (AttributeType *) 0x99f5f48 ai = (AttrInfo *) 0x0 #1 0x00dd8ca5 in bdb_modify_idxflags (op=0x9c16a28, desc=0x9af4078, got_delete=1, newattrs=0x5414fdac, oldattrs=0x5414fdac) at modify.c:54 ap = (Attribute *) 0x5414fdac ix2 = {bv_len = 0, bv_val = 0x2370104 ""} ix_at = {bv_len = 25, bv_val = 0x99f5998 "certificateRevocationList"} ai = (AttrInfo *) 0x9ab07c0 #2 0x00dd98dc in hdb_modify_internal (op=0x9c16a28, tid=0x9ec6628, modlist=0xa3189f0, e=0x236eaa0, text=0x2370104, textbuf=0x236eb00 "ôÏ#", textlen=256) at modify.c:245 rc = 0 err = 0 mod = (Modification *) 0xa3189f0 ml = (Modifications *) 0xa3189f0 save_attrs = (Attribute *) 0x5414fdac ap = (Attribute *) 0x0 glue_attr_delete = 0 got_delete = 1 __PRETTY_FUNCTION__ = "hdb_modify_internal" #3 0x00ddab1a in hdb_modify (op=0x9c16a28, rs=0x23700f0) at modify.c:590 bdb = (struct bdb_info *) 0x9aaf888 e = (Entry *) 0x545d316c ei = (EntryInfo *) 0x9eb8828 manageDSAit = 0 textbuf = "ôÏ#\000@è#\000ðÿÿÿ(ë6\002á\226\027\000@è#\000\020\000\000\000\024Íy\000ð\0007\002\220ì6\002Hë6\002\026wy\000\020\000\000\000@è#\000ðÿÿÿ`\2352\n`\2352\n\024Íy\000hë6\002|wy\000\020\000\000\000\000\000\000\000\220ì6\002\000\000\000\000$\000\000\000@ç\026\b\006\000\000\000üþ\024Tl1]T\000\000\000\000xÓ5\n\000\000\000\000DjÁ\txÓ5\n\001\000\000\000\001\000\000\000D\2352\n\000\000\000\000\230\n«\t\230\t«\t\224y'\000\220ì6\002(ì6\002\232#'\000(jÁ\tÔt¿S\001\000\000\000Ñä\021\bL\000\000\000\000\200\000\000"... textlen = 256 ltid = (DB_TXN *) 0xa430420 lt2 = (DB_TXN *) 0x9ec6628 opinfo = {boi_oe = {oe_next = {sle_next = 0x0}, oe_key = 0x9aaf888}, boi_txn = 0xa430420, boi_locks = 0x0, boi_err = 0, boi_acl_cache = 0 '\0', boi_flag = 0 '\0'} dummy = {e_id = 0, e_name = {bv_len = 130, bv_val = 0x0}, e_nname = {bv_len = 130, bv_val = 0x0}, e_attrs = 0x5414fdac, e_ocflags = 65792, e_bv = { bv_len = 0, bv_val = 0x0}, e_private = 0x0} lock = {off = 148504, ndx = 108, gen = 438195, mode = DB_LOCK_READ} num_retries = 0 preread_ctrl = (LDAPControl **) 0x0 postread_ctrl = (LDAPControl **) 0x0 ctrls = {0x0, 0xffffff40, 0x763c2298, 0x1, 0x0, 0x1} num_ctrls = 0 rc = 37153432 #4 0x080fffe2 in overlay_op_walk (op=0x9c16a28, rs=0x23700f0, which=op_modify, oi=0x9ab0898, on=0x0) at ../../../servers/slapd/backover.c:669 func = (BI_op_bind **) 0xf5fb8c rc = 32768 #5 0x081001a7 in over_op_func (op=0x9c16a28, rs=0x23700f0, which=op_modify) at ../../../servers/slapd/backover.c:721 oi = (slap_overinfo *) 0x9ab0898 on = (slap_overinst *) 0x9ab0998 be = (BackendDB *) 0x9aaf788 db = {bd_info = 0xf5fb60, bd_self = 0x9aaf788, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\001", '\0' <repeats 15 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 = 0x9aaf5b8, be_nsuffix = 0x9ab0680, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 34, bv_val = 0x9ab0718 "cn=Manager,dc=a,dc=prod,dc=actalis"}, be_rootndn = {bv_len = 34, bv_val = 0x9ab0758 "cn=manager,dc=a,dc=prod,dc=actalis"}, be_rootpw = {bv_len = 6, bv_val = 0x9ab0548 "secret"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9af2488, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0xf5f940, be_private = 0x9aaf888, be_next = {stqe_next = 0x9ab0b98}} cb = {sc_next = 0x0, sc_response = 0x80ff283 <over_back_response>, sc_cleanup = 0, sc_private = 0x9ab0898} rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #6 0x0810027d in over_op_modify (op=0x9c16a28, rs=0x23700f0) at ../../../servers/slapd/backover.c:755 No locals. #7 0x08098538 in fe_op_modify (op=0x9c16a28, rs=0x23700f0) at ../../../servers/slapd/modify.c:301 update = 0 repl_user = 0 op_be = (BackendDB *) 0x9aaf788 bd = (BackendDB *) 0x8176380 textbuf = "ôÏ#\000@è#\000\230\030Ç\t(î6\002:v\027\000@è#\000\230\030Ç\tôÏ#\000šî6\002\230\030Ç\t\004ï6\002\004\236\035\000\230\030Ç\t\230\030Ç\t[\000\000\000\000@\000\000 Ó#\000\000\000\000\000\a\000\000\000\006vy\000xî6\002ÿÿÿÿÿÿÿÿ\v\000\000\000\025\000\000\000\230\030Ç\t\000\000\000\000!±\vJ", '\0' <repeats 16 times>, "µ0h%\000\000\000\000Èî6\002\027ä\t\bøÅ\233\t\220\233\000\n\031\000\000\000\2250h%\000\000\000\000\000\000\000\000\001\000\000\000ý\026<\000\004s¿S\220iÁ\táä\a\000\b@`%\a\000\000\000@ç\026\b\030ï6\002\\\214"... textlen = 256 #8 0x08097f67 in do_modify (op=0x9c16a28, rs=0x23700f0) at ../../../servers/slapd/modify.c:175 dn = {bv_len = 111, bv_val = 0x25683012 "cn=CRL7,ou=Regione Lombardia Certification Authority Cittadini,o=Regione Lombardia,c=IT,dc=a,dc=prod,dc=actalis"} textbuf = "8îTG\000\000\000\002\000\000\000\000³æ:\001ÿ\017\000\000@ç\026\b@è#\000\000\000\000\000\000\000\000\000\016\000\000\000@è#\000\000\000\000\000\000\000\000\000Tè#\000\200\000\000\000\000\000\000\000\031\000\000\000Xè#\000\006\000\000\0000\000\000\000ôÏ#\000 Ê#\000\000\000\000\000øÿ6\002ôÏ#\000\001\000\000\000@è#\000\030\0007\002V\224\027\000@è#\000,\000\000\000ÿÿÿÿðÀ\001\000\024Íy\000(\0007\002Ë\231y\000\030óÊ\tS£Ã\t\b\000\000\000Ìwy\000ÿÿÿÿ\024Íy\000\000\000\000\000\001\000\000\000\020\0027\002\000kÁ\t\230\0007\002fg\016\b\020\0027\002Õf\016\b"... textlen = 256 tmp = (Modifications *) 0x0 #9 0x08079867 in connection_operation (ctx=0x2370210, arg_v=0x9c16a28) at ../../../servers/slapd/connection.c:1115 rc = 80 op = (Operation *) 0x9c16a28 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_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}, sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} tag = 102 opidx = SLAP_OP_MODIFY conn = (Connection *) 0xb7f7a274 memctx = (void *) 0x9c16990 memctx_null = (void *) 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #10 0x08079d99 in connection_read_thread (ctx=0x2370210, argv=0x27) at ../../../servers/slapd/connection.c:1241 rc = 0 cri = {op = 0x9c16a28, func = 0, arg = 0x0, ctx = 0x2370210, nullop = 0} s = 39 #11 0x003ad389 in ldap_int_thread_pool_wrapper (xpool=0x99dfab0) at ../../../libraries/libldap_r/tpool.c:663 pool = (struct ldap_int_thread_pool_s *) 0x99dfab0 task = (ldap_int_thread_task_t *) 0x52502480 work_list = (ldap_int_tpool_plist_t *) 0x99dfb30 ctx = {ltu_id = 37161888, ltu_key = {{ltk_key = 0x80793bb, ltk_data = 0x9c168a0, ltk_free = 0x80791ab <conn_counter_destroy>}, { ltk_key = 0x80e66d5, ltk_data = 0x9c16990, ltk_free = 0x80e64e8 <slap_sl_mem_destroy>}, {ltk_key = 0x8092ceb, ltk_data = 0x0, ltk_free = 0x8092c48 <slap_op_q_destroy>}, {ltk_key = 0x9af2498, ltk_data = 0x9c12970, ltk_free = 0xdf2796 <bdb_reader_free>}, {ltk_key = 0x9af5a80, ltk_data = 0x9c31dd0, ltk_free = 0xdf2796 <bdb_reader_free>}, {ltk_key = 0xde0b96, ltk_data = 0x44e44008, ltk_free = 0xde0b6b <search_stack_free>}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 580 hash = 5761604 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #12 0x008ad3cc in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #13 0x001ddc3e in clone () from /lib/tls/libc.so.6 No symbol table info available. any further info available upon request

1 0

Re: (ITS#6116) BDB 4.8 support
by hyc＠symas.com 13 May '09

13 May '09

quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.16 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.131.62.113) > > > Oracle has kindly provided Howard and I access to the early BDB 4.8 code. > Filing this ITS so that we can track modifications to support new features in > BDB 4.8, such as the bulk add/delete capabilities. > After a quick read-thru of the Changes in 4.8, I'm a bit skeptical that we'll be able to use the bulk add/delete feature. It simply allows multiple key/value pairs to be written in one request and in general, since we only operate on individual entries, we seldom operate on more than one k/v pair at a time. The main exception is when generating a substring index. But in that case, we generate pairs in arbitrary (hashed) order, and BDB expects them in sorted order. We could try modifying slapadd to accumulate multiple entries in memory and then add them all at once, but that would only help the adds to the id2entry DB. For the dn2id and all the other index DBs, we again cannot guarantee that inserts will occur in any particular order. As such it seems like we'll be creating quite a bit of complexity, batching up id2entry writes but not batching up the other writes. On a separate front, we should probably look into adding support for partitioned databases. I think that has the potential to be pretty useful, although we'll have to continue to train admins to stop RAIDing all of their disks in order to see any benefit from this. It looks like most of the other changes in 4.8 are internal/transparent, so no action is required of us to take advantage. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6116) BDB 4.8 support
by quanah＠OpenLDAP.org 13 May '09

13 May '09

Full_Name: Quanah Gibson-Mount Version: 2.4.16 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.131.62.113) Oracle has kindly provided Howard and I access to the early BDB 4.8 code. Filing this ITS so that we can track modifications to support new features in BDB 4.8, such as the bulk add/delete capabilities.

1 0

Re: (ITS#6112) LDAP Configuration
by quanah＠zimbra.com 13 May '09

13 May '09

--On May 13, 2009 9:41:04 AM +0000 vinodkharatmol(a)gmail.com wrote: > Full_Name: Vinod Kharatmol > Version: 2.3.27-5 > OS: Linux RHEL 4 Update 2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (203.199.133.19) > > > Hello, > > I have Installed RHEL 5 on VMware separately as Server and Client. > The LDAP Sever and Client Successfully configured. > I am able to start LDAP Server successfully using command: # service ldap > start. > I have created a ldapuser on Server. > But when I am trying to login as a ldapuser on client using # su ldapuser > then we are facing error as, su:ldapuser does not exist. > > I am totally stuck here. Nothing in this report shows any bug in the OpenLDAP software. If you are having problems with the ldap package provided by RHEL, I suggest you contact RedHat support. If you have general usage questions about OpenLDAP, you should address those to the appropriate list (most likely openldap-software(a)openldap.org). This ITS will be closed. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6115) gdi32.lib required by OpenSSL+Windows
by slapd＠hannebauer.name 13 May '09

13 May '09

Full_Name: Christoph Hannebauer Version: 2.4.16 OS: Windows/cygwin URL: http://www.hannebauer.name/openldap-openssl/configure.in.patch Submission from: (NULL) (139.18.40.169) I tried to use OpenSSL 0.9.8k for TLS in my cygwin (target MinGW) OpenLDAP build. The configure script does not detect OpenSSL (however, it doesn't break, instead it finishes without TLS support), because the static library cannot be linked. The config.log file contains error messages like /usr/local/mingw/lib/libcrypto.a(rand_win.o):rand_win.c:(.text+0xa0c): undefined reference to `_CreateDCA@16' The missing functions are part of the library gdi32.lib. The OpenSSL readme file INSTALL.W32 says, that Windows program using OpenSSL should link gdi32.lib (and user32.lib, ..., but on my machine, gdi32.lib seems to be sufficient). Therefore I have created the attached patch file to configure.in (1.697), which adds gdi32.lib to LIBS, if it is required for OpenSSL. I have tested the patched configure file on my machine, the build works without problems. Glück & Kanja Consulting AG (www.glueckkanja.com) hereby places 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#6111) Assert in connection_state_closing
by luca.scamoni＠sys-net.it 13 May '09

13 May '09

Luca Scamoni ha scritto: > I have two more cores at the same point. > Different entries but same assert hit > info available from these cores also > And just around the time it died logs are full of: May 12 15:40:01 quercia01 slapd[10124]: cmp -1, too old May 12 15:40:01 quercia01 slapd[10124]: log csn 20090512050127.389811Z#000000#000#000000 May 12 15:40:01 quercia01 slapd[10124]: cmp -1, too old May 12 15:40:01 quercia01 slapd[10124]: log csn 20090512050127.613282Z#000000#000#000000 May 12 15:40:01 quercia01 slapd[10124]: cmp -1, too old May 12 15:40:01 quercia01 slapd[10124]: log csn 20090512050130.927811Z#000000#000#000000 May 12 15:40:01 quercia01 slapd[10124]: cmp -1, too old May 12 15:40:01 quercia01 slapd[10124]: log csn 20090512050131.178084Z#000000#000#000000 May 12 15:40:01 quercia01 slapd[10124]: cmp -1, too old May 12 15:40:01 quercia01 slapd[10124]: log csn 20090512053954.526945Z#000000#000#000000 May 12 15:40:01 quercia01 slapd[10124]: cmp -1, too old May 12 15:40:01 quercia01 slapd[10124]: log csn 20090512060051.745213Z#000000#000#000000 May 12 15:40:01 quercia01 slapd[10124]: cmp -1, too old May 12 15:40:01 quercia01 slapd[10124]: log csn 20090512060104.372615Z#000000#000#000000 May 12 15:40:01 quercia01 slapd[10124]: cmp -1, too old May 12 15:40:01 quercia01 slapd[10124]: log csn 20090512060123.047312Z#000000#000#000000 and May 12 20:15:37 quercia01 slapd[10355]: srs csn 20090512130647.129160Z#000000#000#000000 May 12 20:15:37 quercia01 slapd[10355]: log csn 20090512134228.001585Z#000000#000#000000 May 12 20:15:37 quercia01 slapd[10355]: log csn 20090512134918.492711Z#000000#000#000000 May 12 20:15:37 quercia01 slapd[10355]: log csn 20090512135120.067222Z#000000#000#000000 May 12 20:15:37 quercia01 slapd[10355]: log csn 20090512135443.385871Z#000000#000#000000 May 12 20:15:37 quercia01 slapd[10355]: log csn 20090512140043.322924Z#000000#000#000000 May 12 20:15:37 quercia01 slapd[10355]: log csn 20090512140055.931196Z#000000#000#000000 May 12 20:15:37 quercia01 slapd[10355]: log csn 20090512140111.553421Z#000000#000#000000 May 12 20:15:37 quercia01 slapd[10355]: log csn 20090512140139.198221Z#000000#000#000000 May 12 20:15:37 quercia01 slapd[10355]: log csn 20090512140151.790035Z#000000#000#000000 May 12 20:15:37 quercia01 slapd[10355]: log csn 20090512140225.400627Z#000000#000#000000 May 12 20:15:37 quercia01 slapd[10355]: log csn 20090512140240.985607Z#000000#000#000000 May 12 20:15:37 quercia01 slapd[10355]: log csn 20090512140314.649432Z#000000#000#000000 May 12 20:15:37 quercia01 slapd[10355]: log csn 20090512140327.203755Z#000000#000#000000 May 12 20:15:37 quercia01 slapd[10355]: log csn 20090512140345.926040Z#000000#000#000000 May 12 20:15:37 quercia01 slapd[10355]: log csn 20090512140410.553120Z#000000#000#000000 May 12 20:15:37 quercia01 slapd[10355]: log csn 20090512140423.120156Z#000000#000#000000 May 12 20:15:37 quercia01 slapd[10355]: log csn 20090512140502.743306Z#000000#000#000000 May 12 20:15:37 quercia01 slapd[10355]: log csn 20090512140533.526334Z#000000#000#000000 Don't know if they're normal or not Ing. Luca Scamoni Responsabile Ricerca e Sviluppo SysNet s.r.l. Gruppo Partners Associates via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ----------------------------------- Office: +39 0382 573859 (137) Fax: +39 0382 476497 Email: luca.scamoni(a)sys-net.it -----------------------------------

1 0

(ITS#6112) LDAP Configuration
by vinodkharatmol＠gmail.com 13 May '09

13 May '09

Full_Name: Vinod Kharatmol Version: 2.3.27-5 OS: Linux RHEL 4 Update 2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (203.199.133.19) Hello, I have Installed RHEL 5 on VMware separately as Server and Client. The LDAP Sever and Client Successfully configured. I am able to start LDAP Server successfully using command: # service ldap start. I have created a ldapuser on Server. But when I am trying to login as a ldapuser on client using # su ldapuser then we are facing error as, su:ldapuser does not exist. I am totally stuck here. Please help me out. Thanks & Regards, Vinod

1 0

Re: (ITS#6111) Assert in connection_state_closing
by lscamoni＠alice.it 13 May '09

13 May '09

I have two more cores at the same point. Different entries but same assert hit info available from these cores also

1 0

(ITS#6111) Assert in connection_state_closing
by luca.scamoni＠sys-net.it 13 May '09

13 May '09

Full_Name: Luca Scamoni Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (82.63.140.131) Met a new assert, this time in connection_state_closing. OpenLDAP 2.4.16 + patches (aligned to RELENG). Master/Slave configuration with syncrepl in refreshAndPersist. Any further info available. (gdb) bt full #0 0x006487a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2 No symbol table info available. #1 0x002ea7a5 in raise () from /lib/tls/libc.so.6 No symbol table info available. #2 0x002ec209 in abort () from /lib/tls/libc.so.6 No symbol table info available. #3 0x002e3d91 in __assert_fail () from /lib/tls/libc.so.6 No symbol table info available. #4 0x0807864f in connection_state_closing (c=0xb7ef3b04) at ../../../servers/slapd/connection.c:704 state = -1209058380 __PRETTY_FUNCTION__ = "connection_state_closing" #5 0x0808d721 in send_ldap_ber (op=0x36faf30, ber=0x36faae0) at ../../../servers/slapd/result.c:148 conn = (Connection *) 0xb7ef3b04 bytes = 891791 ret = 0 closing = 0 #6 0x0809150d in slap_send_search_entry (op=0x36faf30, rs=0x36facb0) at ../../../servers/slapd/result.c:1247 berbuf = { buffer = "\002\000\001\000\000\000\000\000ÿÿÿÿ\000\000\000\000\000\000\000\000üÀ¯Q\213\\œQ\222]œQ\000\000\000\000\000\000\000\000\bw\201\f\004~8\000hÒä\thÒä\tr\000\000\000\000@\000\000 ³>\000[Y0\000L°¯Q\003\b\024\bX«o\003\200°¯Qø«o\003\v\000\000\000\025\000\000\000hÒä\t\000\000\000\000H|\tJhÒä\tr\000\000\000àx8\000D«o\003\000\000\000\000\000\000\000\000àvNu\bw\201\f ¬o\003\000\000\000\000\001\000\000\000\200°¯QøvNu0\217ô\000\000\000\000\000Aw\016\bX?\003\000\003\002\000\000\033Ò{\002\001\000\000\000\005\000\000\0000\217ô\000"..., ialign = 65538, lalign = 65538, falign = 9.18382988e-41, dalign = 3.2380074297143616e-319, palign = 0x10002 <Address 0x10002 out of bounds>} ber = (BerElement *) 0x36faae0 a = (Attribute *) 0x0 i = 1 j = 3 rc = 891791 bytes = 8080 userattrs = 1 acl_state = {as_vi_acl = 0x0, as_vd_acl = 0x0, as_vd_ad = 0x9a65858, as_recorded = ACL_STATE_RECORDED, as_vd_acl_count = 0, as_result = 1, as_fe_done = 0} attrsonly = 0 ad_entry = (AttributeDescription *) 0x9a68f58 e_flags = (char **) 0x0 #7 0x00406da2 in syncprov_sendresp (op=0x36faf30, opc=0x36fad90, so=0x476b9080, e=0x36fadd4, mode=2) at ../../../../servers/slapd/overlays/syncprov.c:834 on = (slap_overinst *) 0x9b3c998 rs = {sr_type = REP_SEARCH, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x36faca8, sr_un = { sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x22}, sru_search = {r_entry = 0x0, r_attr_flags = 34, r_operational_attrs = 0x54370acc, r_attrs = 0x43366f30, r_nentries = 0, r_v2ref = 0x0}}, sr_flags = 0} ctrls = {0x51afb08c, 0x0} cookie = {bv_len = 52, bv_val = 0x51afb04c "rid=002,csn=20090512134019.302018Z#000000#000#000000"} csns = {{bv_len = 40, bv_val = 0x450749fb "20090512134019.302018Z#000000#000#000000"}, {bv_len = 0, bv_val = 0x0}} e_uuid = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x36fac40, e_ocflags = 0, e_bv = { bv_len = 0, bv_val = 0x0}, e_private = 0x0} a_uuid = {a_desc = 0x9a65d50, a_vals = 0x0, a_nvals = 0x36fadac, a_numvals = 0, a_flags = 0, a_next = 0x0} __PRETTY_FUNCTION__ = "syncprov_sendresp" #8 0x00407160 in syncprov_qplay (op=0x36faf30, so=0x476b9080) at ../../../../servers/slapd/overlays/syncprov.c:913 on = (slap_overinst *) 0x9b3c998 sr = (syncres *) 0x45074928 e = (Entry *) 0x54546b2c opc = {son = 0x9b3c998, smatches = 0x36fb008, smt = 0x36fadf8, sdn = {bv_len = 76, bv_val = 0x45074950 "ou=Actalis CA per Firma Digitale Qualificata,o=CNIPA,dc=a,dc=prod,dc=actalis"}, sndn = {bv_len = 76, bv_val = 0x4507499d "ou=actalis ca per firma digitale qualificata,o=cnipa,dc=a,dc=prod,dc=actalis"}, suuid = {bv_len = 16, bv_val = 0x450749ea "\215è#\001µÀ\021Ú\200\006\207öæyñœ020090512134019.302018Z#000000#000#000000"}, sctxcsn = {bv_len = 40, bv_val = 0x450749fb "20090512134019.302018Z#000000#000#000000"}, osid = 0, rsid = 0, sreference = 0} rc = 0 #9 0x00407372 in syncprov_qtask (ctx=0x36fb210, arg=0x476b9080) at ../../../../servers/slapd/overlays/syncprov.c:971 so = (syncops *) 0x476b9080 opbuf = {ob_op = {o_hdr = 0x36fb008, o_tag = 99, o_time = 1242135600, o_tincr = 0, o_bd = 0x36fae20, o_req_dn = {bv_len = 23, bv_val = 0x43366f93 "dc=a,dc=prod,dc=actalis"}, o_req_ndn = {bv_len = 23, bv_val = 0x43366fab "dc=a,dc=prod,dc=actalis"}, o_request = {oq_add = { rs_modlist = 0x2, rs_e = 0x0}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 0, bv_val = 0xffffffff <Address 0xffffffff out of bounds>}, rb_edn = { bv_len = 4294967295, bv_val = 0x0}, rb_ssf = 0, rb_mech = {bv_len = 1127640880, bv_val = 0x47abcff8 "\207"}}, oq_compare = {rs_ava = 0x2}, oq_modify = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 0 '\0'}, rs_increment = -1}, oq_modrdn = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = 0 '\0'}, rs_deleteoldrdn = -1, rs_newrdn = {bv_len = 4294967295, bv_val = 0x0}, rs_nnewrdn = {bv_len = 0, bv_val = 0x43366f30 "\001"}, rs_newSup = 0x47abcff8, rs_nnewSup = 0xf}, oq_search = {rs_scope = 2, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x43366f30, rs_filter = 0x47abcff8, rs_filterstr = {bv_len = 15, bv_val = 0x43366fc3 "(objectClass=*)"}}, oq_abandon = {rs_msgid = 2}, oq_cancel = {rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x0}, rs_flags = -1, rs_reqdata = 0xffffffff}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0x0}, rs_flags = -1, rs_reqdata = 0xffffffff}, rs_old = {bv_len = 0, bv_val = 0x0}, rs_new = {bv_len = 1127640880, bv_val = 0x47abcff8 "\207"}, rs_mods = 0xf, rs_modtail = 0x43366fc3}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 1 '\001', o_is_auth_check = 0 '\0', o_dont_replicate = 0 '\0', o_acl_priv = ACL_NONE, o_nocaching = 0 '\0', o_delete_glue_parent = 0 '\0', o_no_schema_check = 0 '\0', o_no_subordinate_glue = 0 '\0', o_ctrlflag = '\0' <repeats 14 times>, "\003", '\0' <repeats 16 times>, o_controls = 0x36fb130, o_authz = { sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 34, bv_val = 0x43366f70 "cn=manager,dc=a,dc=prod,dc=actalis"}, sai_ndn = { bv_len = 34, bv_val = 0x43366f70 "cn=manager,dc=a,dc=prod,dc=actalis"}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x0, o_res_ber = 0x0, o_callback = 0x0, o_ctrls = 0x0, o_csn = {bv_len = 0, bv_val = 0x0}, o_private = 0x0, o_extra = {slh_first = 0x0}, o_next = {stqe_next = 0x0}}, ob_hdr = {oh_opid = 1, oh_connid = 18793, oh_conn = 0xb7ef3b04, oh_msgid = 2, oh_protocol = 3, oh_tid = 53455776, oh_threadctx = 0x36fb210, oh_tmpmemctx = 0xc817708, oh_tmpmfuncs = 0x8172f00, oh_counters = 0x9bc2c28, oh_log_prefix = "conn=18793 op=1", '\0' <repeats 240 times>}, ob_controls = {0x0 <repeats 32 times>}} op = (Operation *) 0x36faf30 be = {bd_info = 0x9b3c898, bd_self = 0x9b3b788, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\000\001", '\0' <repeats 15 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 = 0x9b3b5b8, be_nsuffix = 0x9b3c680, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 34, bv_val = 0x9b3c718 "cn=Manager,dc=a,dc=prod,dc=actalis"}, be_rootndn = {bv_len = 34, bv_val = 0x9b3c758 "cn=manager,dc=a,dc=prod,dc=actalis"}, be_rootpw = {bv_len = 6, bv_val = 0x9b3c548 "secret"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x0, be_dfltaccess = ACL_READ, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x9b7e488, be_pcl_mutex = {__m_reserved = 0, __m_count = 0, __m_owner = 0x0, __m_kind = 0, __m_lock = {__status = 0, __spinlock = 0}}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0xf5f940, be_private = 0x9b3b888, be_next = {stqe_next = 0x9b3cb98}} rc = 135718720 #10 0x0017c389 in ldap_int_thread_pool_wrapper (xpool=0x9a6bab0) at ../../../libraries/libldap_r/tpool.c:663 pool = (struct ldap_int_thread_pool_s *) 0x9a6bab0 task = (ldap_int_thread_task_t *) 0x9b890c0 work_list = (ldap_int_tpool_plist_t *) 0x9a6bb30 ctx = {ltu_id = 57654176, ltu_key = {{ltk_key = 0x80793bb, ltk_data = 0xca920d8, ltk_free = 0x80791ab <conn_counter_destroy>}, { ltk_key = 0x80e66d5, ltk_data = 0xc817708, ltk_free = 0x80e64e8 <slap_sl_mem_destroy>}, {ltk_key = 0x8092ceb, ltk_data = 0xcad6508, ltk_free = 0x8092c48 <slap_op_q_destroy>}, {ltk_key = 0x9b856d0, ltk_data = 0xca96970, ltk_free = 0xdf2796 <bdb_reader_free>}, {ltk_key = 0x9b7e498, ltk_data = 0xc8ebe68, ltk_free = 0xdf2796 <bdb_reader_free>}, {ltk_key = 0xde0b96, ltk_data = 0x4e175008, ltk_free = 0xde0b6b <search_stack_free>}, { ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0} <repeats 26 times>}} kctx = (ldap_int_thread_userctx_t *) 0x0 i = 32 keyslot = 429 hash = 5950893 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #11 0x008ad3cc in start_thread () from /lib/tls/libpthread.so.0 No symbol table info available. #12 0x0038bc3e in clone () from /lib/tls/libc.so.6 No symbol table info available.

1 0

Re: (ITS#6106) Unable to start LDAP Service in Windows
by hyc＠symas.com 12 May '09

12 May '09

Jemmy.Sentonius(a)infor.com wrote: > Full_Name: Jemmy Sentonius > Version: 2.2.29 > OS: Windows 2003 Server > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (211.24.230.162) > > > > 1) Start the LDAP Service in Windows (logon as Domain Administrator) > 2) System will prompt error: > Windows could not start the InforSecurity LDAP on local computer. For more > information, review the system event log. If this is non-Microsoft Service, > contact the service vendor, and refer to service-specific error code 16. > > 3) Go to Windows Event Viewer, System Log > Notice that there's an error log with description: > The InforSecurity LDAP Service terminated with service-specific error 16 > (0x10) The OpenLDAP Project dropped support for OpenLDAP 2.2 in 2005. This ITS will be closed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6110) GSSAPI signing/encryption for unsuspectingly applications
by mikbec＠web.de 12 May '09

12 May '09

Full_Name: Mike Becher Version: 2.4.16 or HEAD OS: Linux URL: ftp://ftp.openldap.org/incoming/mike-becher-090512.libraries-libldap.patch Submission from: (NULL) (84.150.169.165) patch file name: mike-becher-090512.libraries-libldap-gssapi.1.patch patch subject: GSSAPI signing/encryption for unsuspectingly applications ftp://ftp.openldap.org/incoming/mike-becher-090512.libraries-libldap.patch This patch (see above) introduces a function hook and an additional ldap.conf or ldaprc option GSSAPI_TRY_GSSAPI_BIND_S_IN_SASL_INTERACTIVE_BIND_S which enables unsuspectingly applications to make use of GSSAPI based authentification, signing, and/or encryption. This is very useful if you are connected to MS Active Directory with LDAP server signing is required (means is switched on) and your software (like for example pam_ldap or nss_ldap) doesn't know about that requirement. Additionally if a user does not want use this feature s/he can it switch off on demand. Excerpt from manual page enhancement: On technical view this (hook and option) enables call of ldap_gssapi_bind_s() at the beginning of ldap_sasl_interactive_bind_s(). If ldap_gssapi_bind_s() returns with LDAP_SUCCESS the SASL code of ldap_sasl_interactive_bind_s() will be skipped. In other case ldap_sasl_interactive_bind_s() will be executed. If this option is switch on and an application makes use of ldap_sasl_interactive_bind_s() but doesn't know anything about ldap_gssapi_bind_s() it is able to use GSSAPI signing and encryption. NOTE(s): This patch makes patches of * ITS#6091: missing implementation of "switch off" functionality of GSSAPI OPTIONS * ITS#6092: correct string problem in guess_service_principal() * ITS#6093: correct hostname resolving problem in guess_service_principal() obsolete. Thanks to Hallvard B Furuseth for its comments to ITS#6092 which results in a rewrite of that code snipset.

1 0

(ITS#6109) readonly mode allows ldappaswd
by lacoste＠miage.univ-paris12.fr 12 May '09

12 May '09

Full_Name: Thierry Lacoste Version: 2.4.16 OS: FreeBSD 6.4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (86.203.226.27) A server in readonly mode allows password changes via ldappasswd.

1 0

Re: (ITS#6104) race condition with cancel operation
by hyc＠symas.com 11 May '09

11 May '09

Hallvard B Furuseth wrote: > hyc(a)symas.com writes: >>> slapd/cancel.c sets o_abandon before o_cancel. Thus it's possible for >>> the canceled operation to obey o_abandon before o_cancel gets set. >> >> Cancel is just best-effort, why not just set o_cancel before o_abandon? > > Memory coherence. Without mutex protection, the cancelled thread might > still see the o_abandon change before the o_cancel change. And thus not > send a response, nor update info for the Cancel operation to react to. > I'd prefer to condense it all into a bitfield. We already ensure that the c_mutex is held when setting these flags. It would be a lot of overhead to grab the mutex just to read the flag, and would require additional analysis to make sure the new locking behavior doesn't introduce new deadlocks. -- -- 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#6104) race condition with cancel operation
by h.b.furuseth＠usit.uio.no 11 May '09

11 May '09

hyc(a)symas.com writes: >> slapd/cancel.c sets o_abandon before o_cancel. Thus it's possible for >> the canceled operation to obey o_abandon before o_cancel gets set. > > Cancel is just best-effort, why not just set o_cancel before o_abandon? Memory coherence. Without mutex protection, the cancelled thread might still see the o_abandon change before the o_cancel change. And thus not send a response, nor update info for the Cancel operation to react to. -- Hallvard

1 0

(ITS#6108) unique overlay and rootdn
by mfn＠fs-etit.de 11 May '09

11 May '09

Full_Name: Christopher Dyck Version: 2.4.11 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (130.83.183.3) I found a strange behavior in the unique overlay. unique overlay only works, when a rootdn is specified in the slapd.conf, because the unique_search function uses the rootdn for searching. (took me hours to determine why my configuration didn't do it's job) Isn't it more reasonable to use the dn with which the add or modify is performed? Or mention this circumstance at least in the manpage?!

1 0

Re: (ITS#6107) Manual pages do not mention -e option
by masarati＠aero.polimi.it 11 May '09

11 May '09

rein(a)OpenLDAP.org wrote: > Full_Name: Rein Tollevik > Version: 2.4.16 > OS: Irrelevant > URL: > Submission from: (NULL) (81.93.160.250) > Submitted by: rein > > > The manual pages for (at least) ldapmodify, ldapmodrdn and ldapdelete do not > mention the "-e control" option, nor is the private "-E" documented for > ldapmodify. > > A lot of the options accepted by the ldap* tools are common to them all. Should > they be documented in a separate man page referred to by the tools manuals, or > at least included from a common source? I favor documenting everything in each man page, to limit the amount of redirection (when reading man pages, one wants to quickly find an answer to a specific problem, not learn everything about LDAP :). Documentation should be concise enough to minimally impact the amount one needs to read to learn how to *use* those controls. To learn about the purpose and the details of those controls, references should be used. My 2c. p.

1 0

(ITS#6107) Manual pages do not mention -e option
by rein＠OpenLDAP.org 11 May '09

11 May '09

Full_Name: Rein Tollevik Version: 2.4.16 OS: Irrelevant URL: Submission from: (NULL) (81.93.160.250) Submitted by: rein The manual pages for (at least) ldapmodify, ldapmodrdn and ldapdelete do not mention the "-e control" option, nor is the private "-E" documented for ldapmodify. A lot of the options accepted by the ldap* tools are common to them all. Should they be documented in a separate man page referred to by the tools manuals, or at least included from a common source? -- Rein Tollevik Basefarm AS

1 0

Re: (ITS#6059) Abandon syncprov race condition?
by rein＠OpenLDAP.org 11 May '09

11 May '09

hyc(a)symas.com wrote: > rein(a)OpenLDAP.org wrote: >> I've had two cases where a delete operation was performed on the master without >> being replicated to its consumers, which so far appear to be cases of possible >> connection lost (abandon) race conditions. The log (level: stats) shows the >> "DEL" message of the entry, immediately followed by a "closed (connection lost)" >> message on the connection. Note: No "RESULT" message was logged. >> >> I haven't looked very much into this, but my theory so far is that syncprov >> skipped replicating of the delete op after noticing the abandon resulting from >> loosing the connection, even though the delete had already taken place in the >> local database. That it happened after a delete op might very well have been a >> coincident, this possible race could exist after any modify op for all I know. > >> Do we need some sort of o_committed flag that can be used to prevent o_abandon >> from being set or acted upon? Or handle o_abandon more like o_cancel, i.e with >> multiple values, including "too late"? > > No. What good can that do, since the connection has already been lost? > > It doesn't matter if syncprov fails to send an update to a consumer - the > consumer's cookie state will let it pick up where it left off when it reconnects. It isn't the connection to the syncprov consumer that was lost, it is the connection to the client that made the change. The abandon may cause syncprov to abandon the modify op (in syncprov_op_abandon), and it will definitely cause the entire response callback to be skipped. Which is where syncprov sends updates to its consumers. The change will take place in the local database, but not be replicated, nor will auditlog log it. Accesslog does though, probably since the cleanup callback it enables in accesslog_op_mod explicitly calls its response callback. The syncprov clients will receive updates to the csn when new modifications takes place, i.e the clients must be restarted with the "-c" option to resync their databases. Rein

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs