- openldap-bugs - openldap.org

ITS#7548 Split man pages
by hyc＠symas.com 21 May '15

21 May '15

This patch cannot be accepted because it uses Makefile directives ".if " etc. that are not portable across different versions of Make. -- -- 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#8151) test062 sporadically seg faults
by hyc＠symas.com 21 May '15

21 May '15

michael(a)stroeder.com wrote: > Full_Name: > Version: git master 66ab6bafa8e290d842f68e683e3cd3ee63f513be > OS: openSUSE Linux x86_64 > URL: > Submission from: (NULL) (84.178.24.246) > > > test062 in git master sometimes seg faults with hdb and mdb. config delete support is still WIP. Tests in master are known to fail from time to time, do not file ITSs for these. -- -- 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#8152) mt_flags & MDB_TXN_ERROR is never reset when MDB_MAP_FULL occurs
by dw＠botanicus.net 21 May '15

21 May '15

--047d7bd6b9e4604df2051695f2ab Content-Type: text/plain; charset=UTF-8 Confirmed fixed in mdb.RE/0.9 @ github.com --047d7bd6b9e4604df2051695f2ab Content-Type: text/html; charset=UTF-8 <div dir="ltr">Confirmed fixed in mdb.RE/0.9 @ <a href="http://github.com">github.com</a><br></div> --047d7bd6b9e4604df2051695f2ab--

1 0

(ITS#8152) mt_flags & MDB_TXN_ERROR is never reset when MDB_MAP_FULL occurs
by dw＠botanicus.net 21 May '15

21 May '15

Full_Name: David Wilson Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (81.157.85.186) Since the me_txn0 heap allocation is cached across write transactions, when any write transaction fails with MDB_MAP_FULL and causes MDB_TXN_ERROR to be set in me_txn0->mt_flags, it becomes impossible to try another write transaction without reopening the environment, since that bit is never unset anywhere. A simple way to trigger this is attempting to put any value larger than the map size, at which point the environment will always return MDB_BAD_TXN for subsequent write transactions. While MAP_FULL and insufficient validation of input by the application are pretty show-stopper issues already, I doubt wedging the environment state is the most robust response LMDB could muster in this case. It seems MDB_TXN_ERROR wants to be unset in either mdb_txn_abort() or mdb_txn_reset0(). Taking into account the possibility of a parent write transaction also existing, I'm not sure where and how exactly the bit should be unset.

1 0

(ITS#8151) test062 sporadically seg faults
by michael＠stroeder.com 21 May '15

21 May '15

Full_Name: Version: git master 66ab6bafa8e290d842f68e683e3cd3ee63f513be OS: openSUSE Linux x86_64 URL: Submission from: (NULL) (84.178.24.246) test062 in git master sometimes seg faults with hdb and mdb. Core was generated by `/usr/src/michael/openldap-git/master/openldap/servers/slapd/.libs/lt-slapd -s0'. Program terminated with signal SIGSEGV, Segmentation fault. #0 0x00007fc961c38c3d in syncprov_free_syncop (so=0x7fc954103950, unlink=1) at syncprov.c:811 811 for ( sop = &so->s_si->si_ops; *sop; sop = &(*sop)->s_next ) { Missing separate debuginfos, use: zypper install cyrus-sasl-crammd5-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-digestmd5-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-gs2-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-gssapi-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-ntlm-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-otp-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-plain-debuginfo-2.1.26-11.1.x86_64 cyrus-sasl-scram-debuginfo-2.1.26-11.1.x86_64 glibc-debuginfo-2.21-5.2.x86_64 krb5-debuginfo-1.13.1-1.2.x86_64 libcom_err2-debuginfo-1.42.12-2.2.x86_64 libdb-4_8-debuginfo-4.8.30-30.2.x86_64 libkeyutils1-debuginfo-1.5.9-47.2.x86_64 libltdl7-debuginfo-2.4.6-2.1.x86_64 libopenssl1_0_0-debuginfo-1.0.1k-3.1.x86_64 libpcre1-debuginfo-8.37-1.1.x86_64 libsasl2-3-debuginfo-2.1.26-11.1.x86_64 libselinux1-debuginfo-2.3-4.3.x86_64 libz1-debuginfo-1.2.8-7.2.x86_64 unixODBC-debuginfo-2.3.2-5.2.x86_64 (gdb) bt full #0 0x00007fc961c38c3d in syncprov_free_syncop (so=0x7fc954103950, unlink=1) at syncprov.c:811 sop = 0x6a626f006769666e sr = 0x62644960 srnext = 0x7fc954003270 ga = 0x7fc954103330 gnext = 0x100000 #1 0x00007fc961c396a0 in syncprov_qtask (ctx=0x7fc962644bf0, arg=0x7fc954103950) at syncprov.c:1005 so = 0x7fc954103950 opbuf = {ob_op = {o_hdr = 0x7fc962644960, o_tag = 99, o_time = 1432200195, o_tin % = 0, o_bd = 0x7fc962644660, o_req_dn = {bv_len = 9, bv_val = 0x7fc95410a9e2 "cn=config"}, o_req_ndn = {bv_len = 9, bv_val = 0x7fc95410a9ec "cn=config"}, o_request = {oq_add = {rs_modlist = 0x2, rs_e = 0xffffffffffffffff}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 18446744073709551615, bv_val = 0x0}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 1410349536, rb_mech = {bv_len = 15, bv_val = 0x7fc95410a9f6 "(objectClass=*)"}}, oq_compar= D {rs_ava = 0x2}, oq_modify = {rs_mods = { rs_modlist = 0x2, rs_no_opattrs = -1 '\377'}, rs_increment = 0}, oq_modrdn = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = -1 '\377'}, rs_deleteoldrdn = 0, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 140502675503584, bv_val = 0xf <error: Cannot access memory at address 0xf>}, rs_newSup = 0x7fc95410a9f6, rs_nnewSup = 0x0}, oq_search = {rs_scope = 2, rs_deref = 0, rs_slimit = -1, rs_tlimit = -1, rs_limit = 0x0, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x7fc9541039e0, rs_filterstr = {bv_len = 15, bv_val = 0x7fc95410a9f6 "(objectClass=*)"}}, oq_abandon = {rs_msgid = 2}, oq_cancel = {rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff>}, rs_flags = 0, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = { rs_reqoid = {bv_len = 2, bv_val = 0xffffffffffffffff <error: Cannot access memory at address 0xffffffffffffffff>}, rs_flags = 0, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x7fc9541039e0 "\207"}, rs_new = {bv_len = 15, bv_val = 0x7fc95410a9f6 "(objectClass=*)"}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 1 '\001', o_is_auth_check = 0 '\000', o_dont_replicate = 0 '\000', o_acl_priv = ACL_NONE, o_nocaching = 0 '\000', o_delete_glue_parent = 0 '\000', o_no_schema_check = 0 '\000', o_no_subordinate_glue = 0 '\000', o_ctrlflag = '\000' <repeats 20 times>, "\001\000\000\000\000\000\000\000\000\000\000", o_controls = 0x7fc962644aa8, o_authz = {sai_method = 128, sai_mech = { bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 9, bv_val = 0x7fc95410a9d8 "cn=config"}, sai_ndn = {bv_len = 9, bv_val = 0x7fc95410a9d8 "cn=config"}, 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 = 1003, oh_conn = 0x1bb5730, oh_msgid = 2, oh_protocol = 3, oh_tid = 140502915897088, oh_threadctx = 0x7fc962644bf0, oh_tmpmemctx = 0x7fc954002350, oh_tmpmfuncs = 0x765980 <slap_sl_mfuncs>, oh_counters = 0x7fc954002240, oh_log_prefix = "conn=1003 op=1", '\000' <repeats 241 times>}, ob_controls = { 0x0 <repeats 32 times>}} op = 0x7fc9626447f0 be = {bd_info = 0x760de0 <slap_binfo>, bd_self = 0x1b72470, be_ctrls = '\000' <repeats 15 times>, "\001", '\000' <repeats 16 times>, "\001", be_flags = 131328, 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 = 0x1b72670, be_nsuffix = 0x1b726c0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 9, bv_val = 0x1b72610 "cn=config"}, be_rootndn = {bv_len = 9, bv_val = 0x1b72630 "cn=config"}, be_rootpw = {bv_len = 8, bv_val = 0x1b72930 "D/nFIIJ7"}, 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 = 0x1c6e000, be_dfltaccess = ACL_NONE, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x1b58ff0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x0, be_private = 0x766680 <cfBackInfo>, be_next = {stqe_next = 0x0}} rc = 0 #2 0x00007fc967987ec3 in ldap_int_thread_pool_wrapper (xpool=0x1b4e640) at tpool.c:958 pq = 0x1b4e640 pool = 0x1b4e550 task = 0x7fc954112e30 work_list = 0x1b4e6b0 ctx = {ltu_pq = 0x1b4e640, ltu_id = 140502915897088, ltu_key = {{ltk_key = 0x43f901 <conn_counter_init>, ltk_data = 0x7fc954002240, ltk_free = 0x43f753 <conn_counter_destroy>}, {ltk_key = 0x4b3ff5 <slap_sl_mem_init>, ltk_data = 0x7fc954002350, ltk_free = 0x4b3e1a <slap_sl_mem_destroy>}, {ltk_key = 0x45a859 <slap_op_free>, ltk_data = 0x7fc954002eb0, ltk_free = 0x45a7ac <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x7fc95410bff0, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 28 times>}} kctx = 0x0 i = 32 keyslot = 837 hash = 1269620549 pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #3 0x00007fc965e5f484 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #4 0x00007fc965b9da4d in clone () from /lib64/libc.so.6 No symbol table info available.

1 0

Re: (ITS#8142) back-ldap transparent reconnecting is not so transparent
by hyc＠symas.com 21 May '15

21 May '15

hyc(a)symas.com wrote: > ebackes(a)symas.com wrote: >> Full_Name: Emily Backes >> Version: 2.4 >> OS: >> URL: >> Submission from: (NULL) (50.113.67.84) >> >> >> Currently, back-ldap stores credentials in the outbound connection >> structure. When that disappears, e.g. from idle-timeout, conn-ttl, >> network lossage, AD trouble, etc., the connection becomes unbound and >> AD returns err=1 (Operations error), which isn't enougfofor back-ldap >> to treat it as LDAP_UNAVAILABLE. >> >> Howard reports this is working-as-designed, even if the design is bad. >> Several ITS filings are still open about this problem; 5110, 6571, and >> 7464 are all related. #5110 looks unrelated actually. >> At a minimum, we should drop the client connection if we can't keep >> the session stable. > > This is not as simple as it sounds. In particular, back-ldap may be part of a > larger glued tree of backends. A failure to search in the back-ldap context > should not prevent the rest of the glued tree from being searched, and it > should not drop the client connection. > 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#8129) ignored config variable autocommit for back-sql
by hyc＠symas.com 21 May '15

21 May '15

daniel.chobe(a)dimensiondata.com wrote: > Full_Name: Daniel Chobe > Version: 2.4.40 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.111.74.244) > > > This bug is related to ITS#6613. In this bug a new configvariable named > autocommit was introduced. But the flagmask in config.c was wrong, so setting > this config variable has no influence to the behavior of the slapd. > > The Patch is very simply replace SQL_AUTOCOMMIT with BSQL_AUTOCOMMIT. Thanks for the report, fixed in git master. > > > diff -rupN 1/servers/slapd/back-sql/config.c 2/servers/slapd/back-sql/config.c > --- 1/servers/slapd/back-sql/config.c 2013-11-15 04:31:27.000000000 +0100 > +++ 2/servers/slapd/back-sql/config.c 2015-05-05 14:51:43.161310554 +0200 > @@ -210,7 +210,7 @@ static ConfigTable sqlcfg[] = { > "DESC 'Quoting char of the aliasing keyword' " > "SYNTAX OMsDirectoryString SINGLE-VALUE )", NULL, NULL }, > { "autocommit", "yes|no", 2, 2, 0, > - ARG_ON_OFF|ARG_MAGIC|SQL_TOCOCOMMIT, (void *)sql_cf_gen, > + ARG_ON_OFF|ARG_MAGIC|BSQL_AUTOCOMMIT, (void *)sql_cf_gen, > "( OLcfgDbAt:6.45 NAME 'olcSqlAutocommit' " > "SYNTAX OMsBoolean SINGLE-VALUE )", NULL, NULL }, > { NULL, NULL, 0, 0, 0, ARG_IGNORED, > > -- -- 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#8150) slapcat cn=config produces LDIF that will not re-load
by hyc＠symas.com 21 May '15

21 May '15

Ryan Tandy wrote: > Does the following patch make sense? > > ftp://ftp.openldap.org/incoming/20150520_rtandy_ITS-8150-let-check_name_ind… Looks fine to me. Pushing 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#8150) slapcat cn=config produces LDIF that will not re-load
by ryan＠nardis.ca 21 May '15

21 May '15

Does the following patch make sense? ftp://ftp.openldap.org/incoming/20150520_rtandy_ITS-8150-let-check_name_ind…

1 0

Re: (ITS#8150) slapcat cn=config produces LDIF that will not re-load
by andrew.findlay＠skills-1st.co.uk 20 May '15

20 May '15

On Wed, May 20, 2015 at 11:57:13AM -0700, Ryan Tandy wrote: > It does if you use an initial LDIF like the one from ITS#7016: > > $ mkdir cf.d > $ slapadd -Fcf.d -n0 > dn: cn=config > objectClass: olcGlobal > > dn: olcDatabase=frontend,cn=config > objectClass: olcDatabaseConfig > objectClass: olcFrontendConfig Good point: that suggests an incomplete fix for ITS#7106 rather than a problem in slapcat. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#8150) slapcat cn=config produces LDIF that will not re-load
by ryan＠nardis.ca 20 May '15

20 May '15

On Wed, May 20, 2015 at 06:40:36PM +0000, hyc(a)symas.com wrote: >Unable to reproduce. It does if you use an initial LDIF like the one from ITS#7016: $ mkdir cf.d $ slapadd -Fcf.d -n0 dn: cn=config objectClass: olcGlobal dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig ^D $ slapcat -Fcf.d -n0 -l cf.ldif $ rm -r cf.d/* $ slapadd -Fcf.d -n0 -l cf.ldif slapadd: dn="olcDatabase={-1}frontend,cn=config" (line=591): (64) value of single-valued naming attribute 'olcDatabase' conflicts with value present in entry _#################### 100.00% eta none elapsed none fast! Closing DB... (I ran into this myself a while back but forgot to report it.)

1 0

Re: (ITS#8150) slapcat cn=config produces LDIF that will not re-load
by hyc＠symas.com 20 May '15

20 May '15

andrew.findlay(a)skills-1st.co.uk wrote: > Full_Name: Andrew Findlay > Version: 2.4.40 > OS: CentOS 7 > URL: > Submission from: (NULL) (2001:8b0:8d0:f7e1:a136:6cef:11df:9726) > > > When using cn=config it is sometimes necessary to extract the whole config to an > LDIF file, edit it and re-load into an empty directory. Therefore I would expect > the null-edit case to work for any system: > > slapcat -F .../config -n 0 -o ldif-wrap=no % e extracted.ldif > rm -rf .../config > mkdir .../config > slapadd -F .../config -n 0 -l extracted.ldif > > What I actually get is an error message: > slapadd: dn="olcDatabase={-1}frontend,cn=config" (line=250): (64) value of > single-valued naming attribute 'olcDatabase' conflicts with value present in > entry Unable to reproduce. violino:~/OD/o24/tests> mkdir testrun/slapd.d violino:~/OD/o24/tests> ../servers/slapd/slapd -Tc -f testrun/slapd.1.conf -F testrun/slapd.d -n0 > cf1.ldif violino:~/OD/o24/tests> ls testrun/slapd.d cn=config cn=config.ldif violino:~/OD/o24/tests> rm -rf testrun/slapd.d/* violino:~/OD/o24/tests> ../servers/slapd/slapd -Ta -F testrun/slapd.d -n0 -l cf1.ldif _#################### 100.00% eta none elapsed none fast! Closing DB... -- -- 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#8150) slapcat cn=config produces LDIF that will not re-load
by andrew.findlay＠skills-1st.co.uk 20 May '15

20 May '15

Full_Name: Andrew Findlay Version: 2.4.40 OS: CentOS 7 URL: Submission from: (NULL) (2001:8b0:8d0:f7e1:a136:6cef:11df:9726) When using cn=config it is sometimes necessary to extract the whole config to an LDIF file, edit it and re-load into an empty directory. Therefore I would expect the null-edit case to work for any system: slapcat -F .../config -n 0 -o ldif-wrap=no % e extracted.ldif rm -rf .../config mkdir .../config slapadd -F .../config -n 0 -l extracted.ldif What I actually get is an error message: slapadd: dn="olcDatabase={-1}frontend,cn=config" (line=250): (64) value of single-valued naming attribute 'olcDatabase' conflicts with value present in entry The problem is the frontend database entry: dn: olcDatabase={-1}frontend,cn=config objectClass: olcDatabaseConfig objectClass: olcFrontendConfig olcDatabase: frontend olcAccess: {0}to * by * read structuralObjectClass: olcDatabaseConfig entryUUID: 35adc8f6-9363-1034-85ee-896d5ca46112 creatorsName: cn=config createTimestamp: 20150520174137Z entryCSN: 20150520174137.558106Z#000000#000#000000 modifiersName: cn=config modifyTimestamp: 20150520174137Z %SpSpecifically, the '{-1}' in the dn should either be omitted or should also be present on the olcDatabase attribute in the entry itself. The problem is in the behaviour of slapcat, but may be related to the fix for ITS#7016 Andrew

1 0

(ITS#8149) nssov loginStatus doesn't play well with replication
by ryan＠openldap.org 20 May '15

20 May '15

Full_Name: Ryan Tandy Version: RE24 OS: Debian URL: Submission from: (NULL) (142.31.146.2) Submitted by: ryan jindraj in #openldap reported that in a master/slave setup, nssov on the slave updates loginStatus in the local db, not on the master. nssov should update loginStatus in a way that can be forwarded properly (possibly controlled by a conf option, similar to ppolicy_forward_updates). The loginStatus updates also don't behave intuitively under MMR. The mod is done without opattrs, so is not immediately replicated, but it does get replicated if the entry's CSN gets updated for any other reason. loginStatus is not an operational attribute, nor is user-modification of it prohibited. (Maybe it should be?)

1 0

Re: (ITS#8148) exattrs=memberOf in consumer causes removal of memberOf attributes
by alexoz66＠gmail.com 20 May '15

20 May '15

On 05/19/2015 11:55 PM, Howard Chu wrote: > alexoz66(a)gmail.com wrote: >> Full_Name: John Alex. >> Version: 2.4.40 >> OS: FreeBSD 9.3 >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (176.58.252.240) >> >> >> I have a consumer configured with slapo-memberof and exattrs=memberof in order >> to keep track of group memberships locally as suggested in the manpages. This >> works ok when adding/deleting users to groups, but when a user entry containing >> "memberOf" values is modified, those values are deleted in the consumer. >> According to ITS#7400, exattrs=memberOf is necessary to avoid getting this >> attribute from the provider. > > I see nothing in ITS#7400 that even mentions exattrs. In fact there's nothing conclusive > in ITS#7400 at all, it only says the issue should be taken up on the -devel mailing list > and needs new design work. By reading ITS#7400, I got the impression that the provider (wrongly) sends "memberOf" when the consumer requests "+", so I figured I had to either block this attribute by acl at the provider or by using exattrs on the consumer. Has this been fixed? >> However, it was suggested to me to remove >> "memberOf" from exattrs, which I did and now everything seems to work fine. >> >> In any case, even if exattrs=memberof is not needed anymore, it should not have >> any effect to the local slapo-memberof operations. > > Sorry, that doesn't follow. Adding settings will invariably change some server behavior. > Adding a setting that you didn't need generally turns a working config into a broken config. Redundant yes, but broken? Although I don't have the slightest clue about the inner workings of syncrepl and slapo-memberof, I don't see why one should affect the other. >> See also: http://www.openldap.org/lists/openldap-technical/201505/msg00124.html > >

1 0

Re: (ITS#8133) segfault at startup with memberof+dds
by ryan＠nardis.ca 20 May '15

20 May '15

The patch below fixes the crash, however I'd appreciate a review before committing in case I misunderstood why that code might be needed. The first periodic expiry runs immediately after startup completes, and AFAICT does everything this one would have; so the window for returning stale data should be short. Thanks. ftp://ftp.openldap.org/incoming/20150519_rtandy_ITS-8133-avoid-mods-during-…

1 0

Re: (ITS#8148) exattrs=memberOf in consumer causes removal of memberOf attributes
by hyc＠symas.com 19 May '15

19 May '15

alexoz66(a)gmail.com wrote: > Full_Name: John Alex. > Version: 2.4.40 > OS: FreeBSD 9.3 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (176.58.252.240) > > > I have a consumer configured with slapo-memberof and exattrs=memberof in order > to keep track of group memberships locally as suggested in the manpages. This > works ok when adding/deleting users to groups, but when a user entry containing > "memberOf" values is modified, those values are deleted in the consumer. > According to ITS#7400, exattrs=memberOf is necessary to avoid getting this > attribute from the provider. I see nothing in ITS#7400 that even mentions exattrs. In fact there's nothing conclusive in ITS#7400 at all, it only says the issue should be taken up on the -devel mailing list and needs new design work. > However, it was suggested to me to remove > "memberOf" from exattrs, which I did and now everything seems to work fine. > > In any case, even if exattrs=memberof is not needed anymore, it should not have > any effect to the local slapo-memberof operations. Sorry, that doesn't follow. Adding settings will invariably change some server behavior. Adding a setting that you didn't need generally turns a working config into a broken config. > See also: http://www.openldap.org/lists/openldap-technical/201505/msg00124.html -- -- 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#8148) exattrs=memberOf in consumer causes removal of memberOf attributes
by alexoz66＠gmail.com 19 May '15

19 May '15

Full_Name: John Alex. Version: 2.4.40 OS: FreeBSD 9.3 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (176.58.252.240) I have a consumer configured with slapo-memberof and exattrs=memberof in order to keep track of group memberships locally as suggested in the manpages. This works ok when adding/deleting users to groups, but when a user entry containing "memberOf" values is modified, those values are deleted in the consumer. According to ITS#7400, exattrs=memberOf is necessary to avoid getting this attribute from the provider. However, it was suggested to me to remove "memberOf" from exattrs, which I did and now everything seems to work fine. In any case, even if exattrs=memberof is not needed anymore, it should not have any effect to the local slapo-memberof operations. See also: http://www.openldap.org/lists/openldap-technical/201505/msg00124.html

1 0

Re: (ITS#8142) back-ldap transparent reconnecting is not so transparent
by hyc＠symas.com 19 May '15

19 May '15

ebackes(a)symas.com wrote: > Full_Name: Emily Backes > Version: 2.4 > OS: > URL: > Submission from: (NULL) (50.113.67.84) > > > Currently, back-ldap stores credentials in the outbound connection > structure. When that disappears, e.g. from idle-timeout, conn-ttl, > network lossage, AD trouble, etc., the connection becomes unbound and > AD returns err=1 (Operations error), which isn't enougfofor back-ldap > to treat it as LDAP_UNAVAILABLE. > > Howard reports this is working-as-designed, even if the design is bad. > Several ITS filings are still open about this problem; 5110, 6571, and > 7464 are all related. > > At a minimum, we should drop the client connection if we can't keep > the session stable. This is not as simple as it sounds. In particular, back-ldap may be part of a larger glued tree of backends. A failure to search in the back-ldap context should not prevent the rest of the glued tree from being searched, and it should not drop the client connection. -- -- 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#8147) syncrepl fails when encountering bad data, master leaks memory
by Mark.Bannister＠morganstanley.com 19 May '15

19 May '15

> > I did see that a number of memory leaks have been fixed since 2.4.30, b= ut I > > didn't see anything that looked like this profile. Sorry I don't have = a newer > > version of OpenLDAP to hand to re-test. > > Closing this ITS. You can followup again if you see the same problem in t= he=20 > current 2.4.41 release candidate. 2.4.30 is over 3 years old, no one is g= oing=20 > to investigate this. I wasn't asking anyone to look into 2.4.30. Given how easy this is to test= , Howard, and in the interests of code hygiene, wouldn't it be better for you to spen= d 10 minutes attempting to reproduce the problem on the latest RC? It'll take me much l= onger to download and compile the new RC than it would do for you to import a bad en= try and set-up basic syncrepl. If, by doing so, you can identify and fix another m= emory leak then that's a really good thing. If you can't reproduce it in 2.4.41 after= 10 minutes, then I understand if you close the issue. Best regards, Mark. ---------------------------------------------------------------------------= ----- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinion= s or views contained herein are not intended to be, and do not constitute, = advice within the meaning of Section 975 of the Dodd-Frank Wall Street Refo= rm and Consumer Protection Act. If you have received this communication in = error, please destroy all electronic and paper copies; do not disclose, use= or act upon the information; and notify the sender immediately. Mistransmi= ssion is not intended to waive confidentiality or privilege. Morgan Stanley= reserves the right, to the extent permitted under applicable law, to monit= or electronic communications. This message is subject to terms available at= the following link: http://www.morganstanley.com/disclaimers. If you canno= t access these links, please notify us by reply message and we will send th= e contents to you. By messaging with Morgan Stanley you consent to the fore= going.=

1 0

Re: (ITS#8147) syncrepl fails when encountering bad data, master leaks memory
by hyc＠symas.com 19 May '15

19 May '15

mark.bannister(a)morganstanley.com wrote: > Full_Name: Mark Bannister > Version: 2.4.30 > OS: Oracle Solaris 11.2 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (205.228.82.171) > > > I have a master server and a replica configured with syncrepl in > refreshAndPersist mode. Im using bdb (not mdb), simple auth (not SASL), > standard syncrepl (not delta-syncrepl). > > I noticed that the directory has about 5 erroneous entries in 300,000 where > there is a multi-valued attribute containing two identical values. These > entries were added by slapadd -q. Here is an example: > > dn: cn=test,ou=rpc,dc=mycompany,dc=com > objectClass: oncRpc > cn: test > cn: test > oncRpcNumber: 12345678 The docs already tell you to only use slapadd with known-good data. > I did see that a number of memory leaks have been fixed since 2.4.30, but I > didn't see anything that looked like this profile. Sorry I don't have a newer > version of OpenLDAP to hand to re-test. Closing this ITS. You can followup again if you see the same problem in the current 2.4.41 release candidate. 2.4.30 is over 3 years old, no one is going to investigate this. -- -- 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#8147) syncrepl fails when encountering bad data, master leaks memory
by mark.bannister＠morganstanley.com 19 May '15

19 May '15

Full_Name: Mark Bannister Version: 2.4.30 OS: Oracle Solaris 11.2 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (205.228.82.171) I have a master server and a replica configured with syncrepl in refreshAndPersist mode. Im using bdb (not mdb), simple auth (not SASL), standard syncrepl (not delta-syncrepl). I noticed that the directory has about 5 erroneous entries in 300,000 where there is a multi-valued attribute containing two identical values. These entries were added by slapadd -q. Here is an example: dn: cn=test,ou=rpc,dc=mycompany,dc=com objectClass: oncRpc cn: test cn: test oncRpcNumber: 12345678 When the replica attempts to copy this data using syncrepl from the master server, it fails. All entries up to that point are synchronised fine, but any entries from that point onwards are missing. I didn't see any log entries telling me about this failure, although I admit I didn't look very hard or tweak the log levels. This then causes a memory leak in the master server: $ while :; do ps -p 9025 -o pid,ppid,pmem,rss,vsz,args | tail +2; sleep 60; done 9025 1 5.2 434204 463892 /usr/lib/slapd -f /etc/openldap/slapd.conf -u openldap -g openldap -h ldap:/// 9025 1 5.3 443216 472900 /usr/lib/slapd -f /etc/openldap/slapd.conf -u openldap -g openldap -h ldap:/// 9025 1 5.4 444384 474076 /usr/lib/sla - -f /etc/openldap/slapd.conf -u openldap -g openldap -h ldap:/// 9025 1 5.5 454680 484364 /usr/lib/slapd -f /etc/openldap/slapd.conf -u openldap -g openldap -h ldap:/// 9025 1 5.5 458288 487972 /usr/lib/slapd -f /etc/openldap/slapd.conf -u openldap -g openldap -h ldap:/// 9025 1 5.6 464996 494684 /usr/lib/slapd -f /etc/openldap/slapd.conf -u openldap -g openldap -h ldap:/// 9025 1 5.7 472952 502636 /usr/lib/slapd -f /etc/openldap/slapd.conf -u openldap -g openldap -h ldap:/// ... until memory is exhausted, and I get: ch_malloc of 606572 bytes failed ... followed by a 3GB core dump file. When the server restarts, the cycle starts over again, ad infinitum until the filesystem is full of core dump files. When I remove the 5 duplicate attribute values and restart the master and replica servers, the entire directory is then successfully replicated and the memory footprint of the slapd process remains stable. I am therefore assuming that the duplicate attribute values were causing syncrepl not to complete and a memory leak in the master server. I did see that a number of memory leaks have been fixed since 2.4.30, but I didn't see anything that looked like this profile. Sorry I don't have a newer version of OpenLDAP to hand to re-test.

1 0

Re: (ITS#8117) Bugs related to key-size in lmdb and backend
by h.b.furuseth＠usit.uio.no 18 May '15

18 May '15

On 04/05/15 02:13, h.b.furuseth(a)usit.uio.no wrote: > (...) If I understand correctly this time, the doc should > simply say that the two types size_t and unsigned int are supported. > The "typically" is plain misleading. > > That is, if mdb_node_search() shows the intent when it picks either > int-sized or size_t-sized for IS_BRANCH. OTOH, another bug: > > default_cmp pick cmp_int for INTEGERDUP|DUPFIXED and some other > replaces md_dcmp = cmp_int with cmp_long, which makes no sense unless > cmp_int is just a placeholder. Yet at least mdb_dcmp() calls that > placeholder directly without checking the data size. If that's the intent, branch "mdb/keysize" @ my UiO repo fixes it. Should it do the following too? > And if it's > just a placeholder, how about instead setting dcmp to something which > just abort()s, to make sure the bug of not replacing it is caught? Hallvard

1 0

Re: (ITS#8146) Slapd with mdb consumes 100% CPU if deref aliases is requested
by andrew.findlay＠skills-1st.co.uk 18 May '15

18 May '15

On Mon, May 18, 2015 at 04:58:29PM +0000, Howard Chu wrote: > > (On my laptop, "all possible" is 2^64 - 1 so yes, this will spin for .. a while.) 584942 years at 1M tests/sec - I am not waiting around for the timeout :-) (or the electricity bill: over £10M at todays prices) > Fixed now in git master. Thanks Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#8146) Slapd with mdb consumes 100% CPU if deref aliases is requested
by hyc＠symas.com 18 May '15

18 May '15

hyc(a)symas.com wrote: > Andrew Findlay wrote: >> On Mon, May 18, 2015 at 04:48:13PM +0100, Howard Chu wrote: >> >>> ITS#8103 fix crash with more than 65535 aliases in a scope >> >> Ah - my test case does not have any aliases at all so it may be an >> unrelated issue. > > I see, your issue is caused by the fact you haven't indexed the objectClass > attribute. When back-mdb does a search to find all the alias objects in the > DB, instead of returning zero, it returns unknown which causes it to loop > through all possible entryIDs looking for alias entries. > > (On my laptop, "all possible" is 2^64 - 1 so yes, this will spin for .. a while.) > Fixed now in git 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#8146) Slapd with mdb consumes 100% CPU if deref aliases is requested
by hyc＠symas.com 18 May '15

18 May '15

Andrew Findlay wrote: > On Mon, May 18, 2015 at 04:48:13PM +0100, Howard Chu wrote: > >> ITS#8103 fix crash with more than 65535 aliases in a scope > > Ah - my test case does not have any aliases at all so it may be an > unrelated issue. I see, your issue is caused by the fact you haven't indexed the objectClass attribute. When back-mdb does a search to find all the alias objects in the DB, instead of returning zero, it returns unknown which causes it to loop through all possible entryIDs looking for alias entries. (On my laptop, "all possible" is 2^64 - 1 so yes, this will spin for .. a while.) -- -- 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#8146) Slapd with mdb consumes 100% CPU if deref aliases is requested
by andrew.findlay＠skills-1st.co.uk 18 May '15

18 May '15

On Mon, May 18, 2015 at 04:48:13PM +0100, Howard Chu wrote: > ITS#8103 fix crash with more than 65535 aliases in a scope Ah - my test case does not have any aliases at all so it may be an unrelated issue. Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#8146) Slapd with mdb consumes 100% CPU if deref aliases is requested
by hyc＠symas.com 18 May '15

18 May '15

Andrew Findlay wrote: > On Mon, May 18, 2015 at 12:39:17PM +0100, Howard Chu wrote: > >> Already fixed in RE24. > > Not in the version that I pulled 10 minutes ago... > > openldap-OPENLDAP_REL_ENG_2_4-e445af3 Hmm. violino:~/OD/gr24/servers/slapd> git log -1 back-mdb commit e1fdac9db59e4677b9a2403a072558bd89e44321 Author: Howard Chu <hyc(a)openldap.org> Date: Mon Apr 13 13:11:29 2015 -0700 ITS#8103 fix crash with more than 65535 aliases in a scope I'll look at your test case shortly, thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8146) Slapd with mdb consumes 100% CPU if deref aliases is requested
by andrew.findlay＠skills-1st.co.uk 18 May '15

18 May '15

On Mon, May 18, 2015 at 12:39:17PM +0100, Howard Chu wrote: > Already fixed in RE24. Not in the version that I pulled 10 minutes ago... openldap-OPENLDAP_REL_ENG_2_4-e445af3 Andrew -- ----------------------------------------------------------------------- | From Andrew Findlay, Skills 1st Ltd | | Consultant in large-scale systems, networks, and directory services | | http://www.skills-1st.co.uk/ +44 1628 782565 | -----------------------------------------------------------------------

1 0

Re: (ITS#8146) Slapd with mdb consumes 100% CPU if deref aliases is requested
by hyc＠symas.com 18 May '15

18 May '15

andrew.findlay(a)skills-1st.co.uk wrote: > Full_Name: Andrew Findlay > Version: 2.4.40 > OS: Linux: OpenSuSE 13.2 > URL: ftp://ftp.openldap.org/incoming/openldap-mdb-spin-bug.tgz > Submission from: (NULL) (2001:8b0:8d0:f7e1:61a6:169e:b4ba:9954) > > > Some client programs (such as Apache Directory Studio) request alias > dereferencing by default. This puts slapd with mdb into a spin where it consumes > 100% of a CPU. Other threads continue to work and new connections are accepted. > Timeouts do not terminate the spin. Disconnecting the client does not terminate > the spin. Already fixed in RE24. > To reproduce: start slapd and issue a search of the form: > > ldapsearch -a search -x -b dc=example,dc=org objectclass=person > > I have placed a tarball on the FTP server containing: > > slapd.conf > sample data in LDIF > gdb output showing thread trace after breaking in > script of client commands > > The build options were: > > CFLAGS=-g > export CFLAGS > > ./configure --prefix=/meme/andrew/test/openldap-2.4.40 \ > --enable-spasswd \ > --enable-crypt \ > --enable-slapi \ > --enable-overlays \ > --enable-hdb=no \ > --enable-bdb=no \ > --enable-ldap \ > --enable-rewrite \ > --enable-meta \ > --enable-null \ > --enable-monitor \ > --enable-relay \ > --enable-sock \ > --with-cyrus-sasl \ > --with-tls > > > For those that need it, the workaround with Apache Directory Studio is to > disable alias dereferencing in the Browser Options tab for the connection. > > Andrew > > -- -- 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#8146) Slapd with mdb consumes 100% CPU if deref aliases is requested
by andrew.findlay＠skills-1st.co.uk 18 May '15

18 May '15

Full_Name: Andrew Findlay Version: 2.4.40 OS: Linux: OpenSuSE 13.2 URL: ftp://ftp.openldap.org/incoming/openldap-mdb-spin-bug.tgz Submission from: (NULL) (2001:8b0:8d0:f7e1:61a6:169e:b4ba:9954) Some client programs (such as Apache Directory Studio) request alias dereferencing by default. This puts slapd with mdb into a spin where it consumes 100% of a CPU. Other threads continue to work and new connections are accepted. Timeouts do not terminate the spin. Disconnecting the client does not terminate the spin. To reproduce: start slapd and issue a search of the form: ldapsearch -a search -x -b dc=example,dc=org objectclass=person I have placed a tarball on the FTP server containing: slapd.conf sample data in LDIF gdb output showing thread trace after breaking in script of client commands The build options were: CFLAGS=-g export CFLAGS ./configure --prefix=/meme/andrew/test/openldap-2.4.40 \ --enable-spasswd \ --enable-crypt \ --enable-slapi \ --enable-overlays \ --enable-hdb=no \ --enable-bdb=no \ --enable-ldap \ --enable-rewrite \ --enable-meta \ --enable-null \ --enable-monitor \ --enable-relay \ --enable-sock \ --with-cyrus-sasl \ --with-tls For those that need it, the workaround with Apache Directory Studio is to disable alias dereferencing in the Browser Options tab for the connection. Andrew

1 0

Re: (ITS#8145) The olcThreadQueues config element is not documented
by elecharny＠gmail.com 16 May '15

16 May '15

Le 15/05/15 19:14, Howard Chu a écrit : > Emmanuel Lécharny wrote: >> Le 15/05/15 13:40, Howard Chu a écrit : >>> elecharny(a)apache.org wrote: >>>> Full_Name: Emmanuel L.charny >>>> Version: 2.4.40 >>>> OS: >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (83.202.0.248) >>>> >>>> >>>> The olcThreadQueues AttributeType is part of the olcGlobal >>>> OvjectClass since >>>> 2.4.36, where it's has been added. >>>> A man slapd-config provides no information on this parameter. >>> >>> You're mistaken. The olcThreadQueues feature has not been included in >>> any official 2.4 release, it is a 2.5 feature. >>> >> Sadly, I can't comment on an ITS. So here it is : >> >> "It may not be official, but it's present in the code base since 2.4.36, >> it's also present as a MAY attribute in the olcGlobal ObjectClass. > > No. You misunderstand - it is *NOT* present in the 2.4 source tree. It > has *never* been present in the 2.4 source tree. > It's present in HEAD, which I suppose is now the 2.5 branch : http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=blob;f=servers/sl… The web browser is kind of confusing... And, no, it's not present in tag 2.4.40. The ITS can be closed, sorry for the noise.

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by quanah＠zimbra.com 15 May '15

15 May '15

--On Friday, May 15, 2015 7:45 PM +0000 quanah(a)zimbra.com wrote: > --On Friday, May 15, 2015 8:39 PM +0100 Howard Chu <hyc(a)symas.com> wrote: > >> quanah(a)zimbra.com wrote: >>> This is caused by modify ops: >>> >>> [zimbra@ldap02-dc01 xx]$ grep $20$ /var/log/zimbra.log >>> May 15 08:35:46 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: >>> rid=201 be_modify uid=xxx,ou=people,dc=xxx,dc=com (20) >> >> Multiple TYPE_OR_VALUE_EXISTS errors indicate you're sending a lot of >> mods that were already performed. Sounds more like a serverID or URL >> misconfig here if there are actually only 2 servers talking. > > ServerID's are unique (2 & 3). There is no URL portion to the config, as > we're not replicating cn=config. In 6 days, the servers have gotten > totally out of sync with one another, and REFRESH mode isn't fixing it > either. Note that the drift is occurring on an attribute that is multi-valued: zimbraPasswordLockoutFailureTime The values stored in the attribute are only granular down to the second, so it's not uncommon for multiple writes of the same value (add/mod/delete) to occur for this attribute. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by quanah＠zimbra.com 15 May '15

15 May '15

--On Friday, May 15, 2015 8:39 PM +0100 Howard Chu <hyc(a)symas.com> wrote: > quanah(a)zimbra.com wrote: >> This is caused by modify ops: >> >> [zimbra@ldap02-dc01 xx]$ grep $20$ /var/log/zimbra.log >> May 15 08:35:46 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 >> be_modify uid=xxx,ou=people,dc=xxx,dc=com (20) > > Multiple TYPE_OR_VALUE_EXISTS errors indicate you're sending a lot of > mods that were already performed. Sounds more like a serverID or URL > misconfig here if there are actually only 2 servers talking. ServerID's are unique (2 & 3). There is no URL portion to the config, as we're not replicating cn=config. In 6 days, the servers have gotten totally out of sync with one another, and REFRESH mode isn't fixing it either. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by hyc＠symas.com 15 May '15

15 May '15

quanah(a)zimbra.com wrote: > This is caused by modify ops: > > [zimbra@ldap02-dc01 xx]$ grep $20$ /var/log/zimbra.log > May 15 08:35:46 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 > be_modify uid=xxx,ou=people,dc=xxx,dc=com (20) Multiple TYPE_OR_VALUE_EXISTS errors indicate you're sending a lot of mods that were already performed. Sounds more like a serverID or URL misconfig here if there are actually only 2 servers talking. > May 15 08:47:44 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 > be_modify uid=xxx,ou=people,dc=yyy,dc=co,dc=za (20) > May 15 08:56:03 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 > be_modify uid=xxx,ou=people,dc=zzz,dc=co,dc=za (20) > May 15 09:31:12 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 > be_modify uid=xxx,ou=people,dc=www,dc=co,dc=za (20) > May 15 10:46:58 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 > be_modify uid=xxx,ou=people,dc=ppp,dc=co,dc=za (20) > May 15 13:44:11 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 > be_modify uid=xxx,ou=people,dc=rrr,dc=co,dc=za (20) > May 15 14:54:49 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 > be_modify uid=xxx,ou=people,dc=zzz,dc=com (20) > May 15 17:23:11 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 > be_modify uid=xxx,ou=people,dc=zzz,dc=com (20) > > So overall, there seems to be significant problems with RE24 in relation to > replication at this time. > > Clocks are tightly in sync. > > --Quanah > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration > > > > -- -- 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#8125) MMR throws away valid changes causing drift
by quanah＠zimbra.com 15 May '15

15 May '15

--On Friday, May 15, 2015 7:25 PM +0000 quanah(a)zimbra.com wrote: > Clocks are tightly in sync. Seeing tons of "greater than snapshot errors". 108 so far today on one host, 144 on the other. Example of one: May 15 17:33:19 ldap01-dc01 slapd[31479]: Entry uid=xxxx,ou=people,dc=yyyy,dc=co,dc=za CSN 20150515153317.592677Z#000000#002#000000 greater than snapshot 20150515153317.320608Z#000000#002#000000 --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by quanah＠zimbra.com 15 May '15

15 May '15

--On Monday, May 11, 2015 7:32 PM +0000 quanah(a)zimbra.com wrote: > --On Friday, May 08, 2015 7:56 PM +0000 quanah(a)zimbra.com wrote: > >> >> >> --On May 4, 2015 at 8:00:45 PM +0000 openldap-its(a)OpenLDAP.org wrote: >> >> >> In addition to the missing entries, multiple differences exist for >> existing entries as well. At this point, it seems that replication with >> 2.4.41 is entirely unsafe. > > The existing entry drift seems to be related to the locked up replication > that occured because of a bug in openssl. So the real issue is just the > entries that weren't created, which is a current known limitation of > syncrepl refresh that needs fixing. Unfortunately, I'm now seeing this at a second customer site with 2-node MMR, where it is running current RE24 (2.4.41). In this case: ldap01 and ldap02 were stopped openldap was upgraded from 2.4.39 to 2.4.41 ldap01's db was slapcat'd ldap02's db was erased ldap02's db was recreated from ldap01's slapcat Now they are having drift, and constant refresh troubles: [zimbra@ldap01-dc01 ~]$ grep REFRESH /var/log/zimbra.log May 15 08:56:02 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515065528.000299Z,cn=accesslog), switching to REFRESH May 15 08:58:07 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 LDAP_RES_INTERMEDIATE - REFRESH_DELETE May 15 09:57:18 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515075718.000081Z,cn=accesslog), switching to REFRESH May 15 10:46:57 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515084653.000032Z,cn=accesslog), switching to REFRESH May 15 12:43:18 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515104318.000049Z,cn=accesslog), switching to REFRESH May 15 16:32:19 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515143211.000250Z,cn=accesslog), switching to REFRESH May 15 16:36:41 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515143556.000046Z,cn=accesslog), switching to REFRESH May 15 17:23:10 ldap01-dc01 slapd[31479]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515152310.000002Z,cn=accesslog), switching to REFRESH [zimbra@ldap02-dc01 xx]$ grep FRESH /var/log/zimbra.log May 15 08:35:46 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515063539.000009Z,cn=accesslog), switching to REFRESH May 15 08:47:44 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515064733.000043Z,cn=accesslog), switching to REFRESH May 15 08:56:03 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515065528.000234Z,cn=accesslog), switching to REFRESH May 15 08:57:24 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 LDAP_RES_INTERMEDIATE - REFRESH_DELETE May 15 09:31:12 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515073112.000086Z,cn=accesslog), switching to REFRESH May 15 10:46:58 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515084653.000003Z,cn=accesslog), switching to REFRESH May 15 13:44:11 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515114405.000313Z,cn=accesslog), switching to REFRESH May 15 14:54:49 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515125448.000002Z,cn=accesslog), switching to REFRESH May 15 17:23:11 ldap02-dc01 slapd[18167]: do_syncrep2: rid=201 delta-sync lost sync on (reqStart=20150515152311.000035Z,cn=accesslog), switching to REFRESH This is caused by modify ops: [zimbra@ldap02-dc01 xx]$ grep $20$ /var/log/zimbra.log May 15 08:35:46 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 be_modify uid=xxx,ou=people,dc=xxx,dc=com (20) May 15 08:47:44 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 be_modify uid=xxx,ou=people,dc=yyy,dc=co,dc=za (20) May 15 08:56:03 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 be_modify uid=xxx,ou=people,dc=zzz,dc=co,dc=za (20) May 15 09:31:12 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 be_modify uid=xxx,ou=people,dc=www,dc=co,dc=za (20) May 15 10:46:58 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 be_modify uid=xxx,ou=people,dc=ppp,dc=co,dc=za (20) May 15 13:44:11 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 be_modify uid=xxx,ou=people,dc=rrr,dc=co,dc=za (20) May 15 14:54:49 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 be_modify uid=xxx,ou=people,dc=zzz,dc=com (20) May 15 17:23:11 ldap02-dc01 slapd[18167]: syncrepl_message_to_op: rid=201 be_modify uid=xxx,ou=people,dc=zzz,dc=com (20) So overall, there seems to be significant problems with RE24 in relation to replication at this time. Clocks are tightly in sync. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8145) The olcThreadQueues config element is not documented
by quanah＠zimbra.com 15 May '15

15 May '15

--On Friday, May 15, 2015 12:50 PM +0000 elecharny(a)gmail.com wrote: > You migth object that the reference is what's in the man page, but then, > how possibly can we detect missing parts in the documentation?" You're either using a Symas or Zimbra openldap build to test against, both of which backport 2.5 features not generally available in stock OpenLDAP 2.4. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8145) The olcThreadQueues config element is not documented
by hyc＠symas.com 15 May '15

15 May '15

Emmanuel Lécharny wrote: > Le 15/05/15 13:40, Howard Chu a écrit : >> elecharny(a)apache.org wrote: >>> Full_Name: Emmanuel L.charny >>> Version: 2.4.40 >>> OS: >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (83.202.0.248) >>> >>> >>> The olcThreadQueues AttributeType is part of the olcGlobal >>> OvjectClass since >>> 2.4.36, where it's has been added. >>> A man slapd-config provides no information on this parameter. >> >> You're mistaken. The olcThreadQueues feature has not been included in >> any official 2.4 release, it is a 2.5 feature. >> > Sadly, I can't comment on an ITS. So here it is : > > "It may not be official, but it's present in the code base since 2.4.36, > it's also present as a MAY attribute in the olcGlobal ObjectClass. No. You misunderstand - it is *NOT* present in the 2.4 source tree. It has *never* been present in the 2.4 source tree. -- -- 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#8145) The olcThreadQueues config element is not documented
by elecharny＠gmail.com 15 May '15

15 May '15

Le 15/05/15 13:40, Howard Chu a écrit : > elecharny(a)apache.org wrote: >> Full_Name: Emmanuel L.charny >> Version: 2.4.40 >> OS: >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (83.202.0.248) >> >> >> The olcThreadQueues AttributeType is part of the olcGlobal >> OvjectClass since >> 2.4.36, where it's has been added. >> A man slapd-config provides no information on this parameter. > > You're mistaken. The olcThreadQueues feature has not been included in > any official 2.4 release, it is a 2.5 feature. > Sadly, I can't comment on an ITS. So here it is : "It may not be official, but it's present in the code base since 2.4.36, it's also present as a MAY attribute in the olcGlobal ObjectClass. There is no way for me to know that it's a 2.5 feature, if it's in 2.4 branch, and if it's not documented as so. This is not really convenient, as I'm basing the OpenLDAP configuration editor on the content of the existing ObjectClasses. You migth object that the reference is what's in the man page, but then, how possibly can we detect missing parts in the documentation?"

1 0

Re: (ITS#8145) The olcThreadQueues config element is not documented
by hyc＠symas.com 15 May '15

15 May '15

elecharny(a)apache.org wrote: > Full_Name: Emmanuel L.charny > Version: 2.4.40 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (83.202.0.248) > > > The olcThreadQueues AttributeType is part of the olcGlobal OvjectClass since > 2.4.36, where it's has been added. > A man slapd-config provides no information on this parameter. You're mistaken. The olcThreadQueues feature has not been included in any official 2.4 release, it is a 2.5 feature. -- -- 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#8145) The olcThreadQueues config element is not documented
by elecharny＠apache.org 15 May '15

15 May '15

Full_Name: Emmanuel L.charny Version: 2.4.40 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.202.0.248) The olcThreadQueues AttributeType is part of the olcGlobal OvjectClass since 2.4.36, where it's has been added. A man slapd-config provides no information on this parameter.

1 0

Re: (ITS#8140) ssf is hard coded to log as zero, even if it is non-zero
by quanah＠zimbra.com 15 May '15

15 May '15

--On Tuesday, May 12, 2015 7:58 PM +0000 quanah(a)zimbra.com wrote: > --On Tuesday, May 12, 2015 1:18 PM +0000 hyc(a)symas.com wrote: > >> Works as designed. The Bind op itself didn't provide any security, so it >> contributed 0 to the session's ssf. The preceding StartTLS request >> actually established a security layer, and it correctly logs the ssf >> from that. > > I think overall the design is problematic. "ssf" is generally supposed to > indicate the overall security of the connection, regardless of the step. > Perhaps for 2.5 and later, we could modify the logging line to be > something more like: > > May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND > dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE bind_ssf=0 ssf=256 > > > So that the overall SSF of the connection is reflected, and we're > indicating that specifically the BIND op added nothing to SSF. > > This would be useful for ldapi:/// connections as well, as there are zero > ssf indicators logged at all outside of the bind op: > > May 12 02:30:19 ldap01 slapd[33839]: conn=169357 fd=85 ACCEPT from > PATH=/opt/zimbra/data/ldap/state/run/ldapi > (PATH=/opt/zimbra/data/ldap/state/run/ldapi) > May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND > dn="uid=zimbra,cn=admins,cn=zimbra" method=128 > May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND > dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 > May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 RESULT tag=97 err=0 > text= > > > Even though I have: > > olcLocalSSF: 128 > > in my config DB > > I.e., I think it would be better to show: > > May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND > dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE bind_ssf=0 ssf=128 > > in this case. Per Howard: we should update the SASL Bind log to use bind_ssf= as well --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7806) memory leak in contrib/ldapc++/LDAPAsynConnection.cpp
by quanah＠zimbra.com 15 May '15

15 May '15

--On Wednesday, February 26, 2014 6:15 PM +0000 kevpatt(a)khptech.com wrote: > Full_Name: Kevin H. Patterson > Version: git master HEAD > OS: macosx 10.9.1 > URL: > http://campus.hartland.edu/temp/0001-fixed-memory-leak-in-LDAPAsynConnect > ion.cpp.patch Submission from: (NULL) (65.207.4.130) > > > In libldapcpp, there is a memory leak in the LDAPAsynConnection class. > ldap_initialize() allocates memory which is never freed. This memory (ld > structure) should be freed by a call to ldap_unbind() in the class > destructor and other places where the ld structure is replaced with a new > one. > > I have included a patch against git master HEAD below. According to a ldap c++ user, this patch causes code to segv. Please see <https://www.openldap.org/its/private.cgi/?findid=8143> --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#8144) SegV in ~LDAPCtrl()
by jianying.luo＠alcatel-lucent.com 15 May '15

15 May '15

Full_Name: Jianying Luo Version: 2.4.40 OS: RHEL 2.6.32-504.12.2.el6.x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (135.245.8.2) Hi, >From the 2.4.40 changelog, I saw "Fixed ldapc++ memory leak in Async connection (ITS#7806)". The code change is at openldap-2.4.40/contrib/ldapc++/src/LDAPAsynConnection.cpp -Del- 46 LPAsysynConnection::~LDAPAsynConnection(){} +Add+ 46 LDAPAsynConnection::~LDAPAsynConnection(){ +Add+ 47 unbind(); +Add+ 48 delete m_constr; +Add+ 49 } But this caused a segV #0 0x00c40a79 in __gnu_cxx::__exchange_and_add(int volatile*, int) () from /usr/lib/libstdc++.so.6 Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.149.el6_6.5.i686 libgcc-4.4.7-11.el6.i686 libstdc++-4.4.7-11.el6.i686 (gdb) bt #0 0x00c40a79 in __gnu_cxx::__exchange_and_add(int volatile*, int) (9 9 from /usr/lib/libstdc++.so.6 #1 0x005e05c1 in ::~LDAPCtrl() () from /opt/LU3P/lib/libldapcpp.so.0 #2 0x005e0c7f in LDAPControlSet::~LDAPControlSet() () from /opt/LU3P/lib/libldapcpp.so.0 #3 0x005e02a3 in LDAPConstraints::~LDAPConstraints() () from /opt/LU3P/lib/libldapcpp.so.0 #4 0x005da82f in LDAPAsynConnection::~LDAPAsynConnection() () from /opt/LU3P/lib/libldapcpp.so.0 #5 0x005dfa98 in LDAPConnection::~LDAPConnection() () from /opt/LU3P/lib/libldapcpp.so.0 #6 0x005dfac2 in LDAPConnection::~LDAPConnection() () from /opt/LU3P/lib/libldapcpp.so.0 #7 0x0805e189 in CpmLDAPOper::~CpmLDAPOper (this=0x82fc630, __in_chrg=<value optimized out>) at ../../../../../../glob/src/cpm_daemon/CpmLDAPOper.cpp:54 #8 0x0806486a in CpmMonMain::ReadFeatureOption (this=0x82fa228, force=1 '\001') at ../../../../../../glob/src/cpm_daemon/CpmMonMain.cpp:332 #9 0x08065c8c in CpmMonMain::CheckState (this=0x82fa228) at ../../../../../../glob/src/cpm_daemon/CpmMonMain.cpp:473 #10 0x08065ec0 in CpmMonMain::LoopWork (this=0x82fa228) at ../../../../../../glob/src/cpm_daemon/CpmMonMain.cpp:256 #11 0x0805348a in CpmMainBase::Run (this=0x82fa228, argc=1, argv=0xffcbe944) at ../../../../../../glob/src/cpm_daemon/CpmMainBase.cpp:156 #12 0x0806435d in main (argc=1, argv=0xffcbe944) at ../..F.F../../../../glob/src/cpm_daemon/CpmMonMain.cpp:517 (gdb) q Thanks, Jianying

1 0

(ITS#8143) SegV in ~LDAPCtrl()
by jianying.luo＠alcatel-lucent.com 14 May '15

14 May '15

Full_Name: Jianying Luo Version: 2.4.40 OS: RHEL 2.6.32-504.12.2.el6.x86_64 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (135.245.8.3) Hi, >From the 2.4.40 changelog, I saw "Fixed ldapc++ memory leak in Async connection (ITS#7806)". The code change is at openldap-2.4.40/contrib/ldapc++/src/LDAPAsynConnection.cpp -Del- 46 LPAsysynConnection::~LDAPAsynConnection(){} +Add+ 46 LDAPAsynConnection::~LDAPAsynConnection(){ +Add+ 47 unbind(); +Add+ 48 delete m_constr; +Add+ 49 } But this caused a segV #0 0x00c40a79 in __gnu_cxx::__exchange_and_add(int volatile*, int) () from /usr/lib/libstdc++.so.6 Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.149.el6_6.5.i686 libgcc-4.4.7-11.el6.i686 libstdc++-4.4.7-11.el6.i686 (gdb) bt #0 0x00c40a79 in __gnu_cxx::__exchange_and_add(int volatile*, int) (9 9 from /usr/lib/libstdc++.so.6 #1 0x005e05c1 in ::~LDAPCtrl() () from /opt/LU3P/lib/libldapcpp.so.0 #2 0x005e0c7f in LDAPControlSet::~LDAPControlSet() () from /opt/LU3P/lib/libldapcpp.so.0 #3 0x005e02a3 in LDAPConstraints::~LDAPConstraints() () from /opt/LU3P/lib/libldapcpp.so.0 #4 0x005da82f in LDAPAsynConnection::~LDAPAsynConnection() () from /opt/LU3P/lib/libldapcpp.so.0 #5 0x005dfa98 in LDAPConnection::~LDAPConnection() () from /opt/LU3P/lib/libldapcpp.so.0 #6 0x005dfac2 in LDAPConnection::~LDAPConnection() () from /opt/LU3P/lib/libldapcpp.so.0 #7 0x0805e189 in CpmLDAPOper::~CpmLDAPOper (this=0x82fc630, __in_chrg=<value optimized out>) at ../../../../../../glob/src/cpm_daemon/CpmLDAPOper.cpp:54 #8 0x0806486a in CpmMonMain::ReadFeatureOption (this=0x82fa228, force=1 '\001') at ../../../../../../glob/src/cpm_daemon/CpmMonMain.cpp:332 #9 0x08065c8c in CpmMonMain::CheckState (this=0x82fa228) at ../../../../../../glob/src/cpm_daemon/CpmMonMain.cpp:473 #10 0x08065ec0 in CpmMonMain::LoopWork (this=0x82fa228) at ../../../../../../glob/src/cpm_daemon/CpmMonMain.cpp:256 #11 0x0805348a in CpmMainBase::Run (this=0x82fa228, argc=1, argv=0xffcbe944) at ../../../../../../glob/src/cpm_daemon/CpmMainBase.cpp:156 #12 0x0806435d in main (argc=1, argv=0xffcbe944) at ../..F.F../../../../glob/src/cpm_daemon/CpmMonMain.cpp:517 (gdb) q Thanks, Jianying

1 0

(ITS#8142) back-ldap transparent reconnecting is not so transparent
by ebackes＠symas.com 13 May '15

13 May '15

Full_Name: Emily Backes Version: 2.4 OS: URL: Submission from: (NULL) (50.113.67.84) Currently, back-ldap stores credentials in the outbound connection structure. When that disappears, e.g. from idle-timeout, conn-ttl, network lossage, AD trouble, etc., the connection becomes unbound and AD returns err=1 (Operations error), which isn't enougfofor back-ldap to treat it as LDAP_UNAVAILABLE. Howard reports this is working-as-designed, even if the design is bad. Several ITS filings are still open about this problem; 5110, 6571, and 7464 are all related. At a minimum, we should drop the client connection if we can't keep the session stable. If we keep it open, we need to ensure we can precisely duplicate the client session-state, including credentials. (this would be very useful).

1 0

Re: (ITS#8140) ssf is hard coded to log as zero, even if it is non-zero
by quanah＠zimbra.com 12 May '15

12 May '15

--On Tuesday, May 12, 2015 1:18 PM +0000 hyc(a)symas.com wrote: > Works as designed. The Bind op itself didn't provide any security, so it > contributed 0 to the session's ssf. The preceding StartTLS request > actually established a security layer, and it correctly logs the ssf > from that. I think overall the design is problematic. "ssf" is generally supposed to indicate the overall security of the connection, regardless of the step. Perhaps for 2.5 and later, we could modify the logging line to be something more like: May 11 02:28:06 ldap01 slapd[33839]: conn=153266 op=1 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE bind_ssf=0 ssf=256 So that the overall SSF of the connection is reflected, and we're indicating that specifically the BIND op added nothing to SSF. This would be useful for ldapi:/// connections as well, as there are zero ssf indicators logged at all outside of the bind op: May 12 02:30:19 ldap01 slapd[33839]: conn=169357 fd=85 ACCEPT from PATH=/opt/zimbra/data/ldap/state/run/ldapi (PATH=/opt/zimbra/data/ldap/state/run/ldapi) May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" method=128 May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE ssf=0 May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 RESULT tag=97 err=0 text= Even though I have: olcLocalSSF: 128 in my config DB I.e., I think it would be better to show: May 12 02:30:19 ldap01 slapd[33839]: conn=169357 op=0 BIND dn="uid=zimbra,cn=admins,cn=zimbra" mech=SIMPLE bind_ssf=0 ssf=128 in this case. --Quanah -- Quanah Gibson-Mount Platform Architect Zimbra, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#8141) Weird info returned by mdb_stat
by hyc＠symas.com 12 May '15

12 May '15

elecharny(a)apache.org wrote: > Full_Name: Emmanuel Lecharny > Version: 2.4.38 > OS: > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (92.163.84.201) > > > When running mdb_stat on some existing database, we get some results like : > > Status of className > Tree depth: 1 > Branch pages: 0 > Leaf pages: 1 > Overflow pages: 0 > Entries: 72899 > > I wonder how possibly we could have 72 899 entries stored into one single 4kb > page. You're looking at an index DB which uses sorted duplicates. The space used by the duplicates is in a subtree and the stats for that subtree aren't available. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#8141) Weird info returned by mdb_stat
by elecharny＠apache.org 12 May '15

12 May '15

Full_Name: Emmanuel Lecharny Version: 2.4.38 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (92.163.84.201) When running mdb_stat on some existing database, we get some results like : Status of className Tree depth: 1 Branch pages: 0 Leaf pages: 1 Overflow pages: 0 Entries: 72899 I wonder how possibly we could have 72 899 entries stored into one single 4kb page.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs