openldap-bugs May 2009

openldap-bugs@openldap.org

42 participants
159 discussions

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

← Newer
1
...
6
7
8
9
10
11
12
...
16
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs May 2009