- openldap-bugs - openldap.org

Re: (ITS#8533) Support OpenSSL-1.1.0c
by sca＠andreasschulze.de 26 Nov '16

26 Nov '16

Howard Chu: > Patches should be relative to git master. There is no 2.4.45. right, I wrongly named the git master 2.4.45 - my fault but in fact it's git master... > Don't use pkg-config. Not all systems support it. I know only linux, sorry. Again: your right, support for openssl-1.1 don't require pkg-config. But I personally need pkg-config because my openssl library is named libssl-dv / libcrypto-dv to coexist with the distribution versions. Viktor Dukhovni told me to build openssl-1.1 that way and beside the requirement for pkg-config I'm personally fine with that advise :-) should I prepare the new patch to fit your needs? otherwise I would be fine if you modify the contribution to your needs. Anyway: after I wrote the patch for git-master it was very easy to create a patch to compile also 2.4.44 with openssl-1.1 I could publish that also next week. Do you think that makes sense? Thanks, Andreas

1 0

Re: (ITS#8533) Support OpenSSL-1.1.0c
by hyc＠symas.com 26 Nov '16

26 Nov '16

sca+openldap(a)andreasschulze.de wrote: > Full_Name: Andreas Schulze > Version: 2.4.45~git Patches should be relative to git master. There is no 2.4.45. > OS: linux > URL: ftp://ftp.openldap.org/incoming/andreas-schulze-161125.patch > Submission from: (NULL) (2001:a60:f0b4:e502::152) > > > while http://www.openldap.org/its/index.cgi/Development?id=8353 > end with "work with openssl-1.1" I checked out openldap from git in november > 2016 > and found it does not compile. So I write the patch. > > it solve the following challenges: > - SSL_library_init no longer exist, use OPENSSL_init_ssl to detect openssl > - configure use pkg-config to find the names of libssl and libcrypto Don't use pkg-config. Not all systems support it. > - codechanges in libraries/libldap/tls_o.c to handle the API changes introduced > by openssl-1.1.0 > > > > -- -- 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#8533) Support OpenSSL-1.1.0c
by sca+openldap＠andreasschulze.de 25 Nov '16

25 Nov '16

Full_Name: Andreas Schulze Version: 2.4.45~git OS: linux URL: ftp://ftp.openldap.org/incoming/andreas-schulze-161125.patch Submission from: (NULL) (2001:a60:f0b4:e502::152) while http://www.openldap.org/its/index.cgi/Development?id=8353 end with "work with openssl-1.1" I checked out openldap from git in november 2016 and found it does not compile. So I write the patch. it solve the following challenges: - SSL_library_init no longer exist, use OPENSSL_init_ssl to detect openssl - configure use pkg-config to find the names of libssl and libcrypto - codechanges in libraries/libldap/tls_o.c to handle the API changes introduced by openssl-1.1.0

1 0

Re: (ITS#8531) Segfault in servers/slapd/back-sql/search.c
by quanah＠symas.com 21 Nov '16

21 Nov '16

--On Thursday, November 17, 2016 3:47 PM +0000 winkelmann(a)hornetsecurity.com wrote: > Full_Name: Guido Winkelmann > Version: 2.4.44 > OS: Gentoo Linux > URL: > Submission from: (NULL) (80.146.184.86) > > > Hi, > > I have been trying to set up OpenLDAP to serve some data from a MySQL > database using back_sql. I have gotten to the point where it should show > the base object of its tree, but when I try to query it using Hello Guido, As noted in the slapd-sql(5) man page the backend is entirely experimental and one uses it at their own risk. There is not, to my knowledge, any current maintainer for the backend at this time. Patches welcome. If you do decide to pursue a patch, please be sure and read over: <http://www.openldap.org/devel/contributing.html> Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8532) Blank subject name results in failed SSLHandshake
by quanah＠symas.com 21 Nov '16

21 Nov '16

--On Monday, November 21, 2016 8:50 PM +0000 graham.wells(a)gmail.com wrote: > Full_Name: Graham Wells > Version: 2.4.28 > OS: macOS 10.12.1 > URL: > Submission from: (NULL) (50.207.27.182) Hi Graham, Thanks for the report. However, Apple builds of OpenLDAP have hacked in support for a custom TLS library called Secure Transport. Use of this TLS library is not supported by the OpenLDAP project, thus we cannot address this problem. You will need to contact Apple for help with this problem. Hope that helps. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8532) Blank subject name results in failed SSLHandshake
by graham.wells＠gmail.com 21 Nov '16

21 Nov '16

Full_Name: Graham Wells Version: 2.4.28 OS: macOS 10.12.1 URL: Submission from: (NULL) (50.207.27.182) SSLHandshake fails for ldapsearch when the subject is blank, even if the certificate is valid and certificate chain trusted (should only require a valid SAN and for SAN to be marked as critical): Command: /usr/bin/ldapsearch -b "CN=userid,ou=foo,ou=bar,dc=domain,dc=com" -D "CN=bind-dn,ou=foo,ou=bar,dc=domain,dc=com" -H ldaps://server-ldap.com:636 -W -d-1 ldap_url_parse_ext(ldaps://server-ldap.com:636) ldap_create ldap_url_parse_ext(ldaps://server-ldap.com:636/??base) Enter LDAP Password:AlAldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP server-ldap.com:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 10.2.2.2:636 ldap_pvt_connect: fd: 3 tm: -1 async:%D tlsst_thr_init() tlsst_init() tlsst_ctx_new() = 0x7fa10de02f90 tlsst_ctx_init(0x7fa10de02f90) tlsst_ciphers_get((null), TLS_CIPHER_SUITE) tlsst_trusted_certs_get(CA 002|CA 001|CA 003|ROOT CA 001|Other Root CA, TLS_TRUSTED_CERTS) tlssttetem_get(CA 002, TLS_TRUSTED_CERTS) tlsst_item_get(CA 001, TLS_TRUSTED_CERTS) tlsst_item_get(CA 003, TLS_TRUSTED_CERTS) tlsst_item_get(ROOT CA 001, TLS_TRUSTED_CERTS) tlsst_item_get(Other Root CA, TLS_TRUSTED_CERTS) tlsst_session_new(0x7fa10de02f90) tlsst_ciphers_set(42, TLS_CIPHER_SUITE) TLS: 42 ciphers wanted: ...(omitted) TLS: 72 ciphers supported: ...(omitted) TLS: 16 ciphers enabled ...(omitted) tlsst_ctx_ref(0x7fa10de02f90) tlsst_session_new(0x7fa10de02f90) = 0x7fa10dd08280 tlsst_sb_setup(0x7fa10dd08280) tlsst_ctx_ref(0x7fa10de02f90) tlsst_session_connect(0x7fa10dd08280) tlsst_session_handshake() tlsst_socket_write(0x7fa10dd0ef68, 123) tls_write: want=123, written=123 0000: 16 03 01 00 76 01 00 00 72 03 03 58 33 55 fe 4e ....v...r..X3U.N 0010: 8e 16 0d df 99 3a e6 68 36 a1 ff 90 71 1f 78 bb .....:.h6...q.x. 0020: 70 bf 2a 02 05 44 c9 94 07 33 2f 00 00 22 00 ff p.*..D...3/..".. 0030: 00 9d 00 9f 00 3d 00 6b 00 35 00 39 00 9c 00 9e .....=.k.5.9.... 0040: 00 3c 00 67 00 2f 00 33 00 0a 00 16 00 05 00 04 .<.g./.3........ 0050: 01 00 00 27 00 0d 00 12 00 10 04 01 02 01 05 01 ...'............ 0060: 06 01 04 03 02 03 05 03 06 03 00 05 00 05 01 00 ................ 0070: 00 00 00 00 12 00 00 00 17 00 00 ........... tlsst_socket_read(0x7fa10e81d800, 5) tls_read: want=5, got=5 0000: 16 03 03 11 38 ....8 tlsst_socket_read(0x7fa10e81d805, 4408) tls_read: want=0808, got=2891 ...(sanitized) tlsst_socket_read - received (2891) bytes of (4408) requested bytes - (1517) encrypted bytes remaining tlsst_socket_flags sess(0x7fa10dd08280) tlsst_socket_flags ->(2) tlsst_socket_read(0x7fa10e81e350, 1517) tls_read: want=1517, got=1517 ...(sanitized) TLS: during handshake: peer cert is valid, or was ignored if verification disabled (-9841) TLS: during handshake: Peer certificate is not trusted: kSecTrustResultRecoverableTrustFailure tlsst_session_upflags(0x7fa10dd08280) tlsst_session_errmsg(0x7fa10dd08280) TLS: can't connect: SSLHandshake() failed: misc. bad certificate (-9825). tlsst_sb_remove(0x7fa10dd08280) tlsst_session_free(0x7fa10dd08280) tlsst_ctx_free(0x7fa10de02f90) ldap_err2string ldap_sasl_bind(SIMPLE): Can7t7t contact LDAP server (-1) ldap_pvt_clear_search_results_callback: ld 0x7fa10dd00ab0 ldap_pvt_close_select_pipe: sip = 0x7fa10e803800 tlsst_ctx_free(0x7fa10de02f90) tlsst_ctx_free(0x7fa10de02f90) tlsst_destroy() Certificate is otherwise valid: Certificate: Data: Version: 3 (0x2) Serial Number: (redacted) Signature Algorithm: sha256WithRSAEncryption Issuer: DC=foo, DC=bar, CN=CA 003 Validity Not Before: Oct 25 23:33:16 2016 GMT Not After : Oct 25 23:33:16 2017 GMT Subject: Subject Public Key Info: Public Key Algorithm: rsaEncryption RSA Public Key: (2048 bit) Modulus (2048 bit): (redacted) Exponent: 65537 (0x10001) X509v3 extensions: 1.3.6.1.4.1.311.21.7: 0-.%+.....7....`...W......./....W...b......d... X509v3 Extended Key Usage: 1.3.6.1.5.2.3.5, Microsoft Smartcardlogin, TLS Web Server Authentication, TLS Web Client Authentication X509v3 Key Usage: critical Digital Signature, Key Encipherment 1.3.6.1.4.1.311.21.10: 010...+......0.. +.....7...0 ..+.......0 ..+....... X509v3 Subject Key Identifier: E2:D2:D9:24:6D:A6:5A:2D:59:03:08:38:03:AE:E8:F4:2A:EA:EB:9F X509v3 Authority Key Identifier: keyid:16:70:AA:1C:31:53:76:FB:26:B5:B8:EA:FC:76:08:E6:3F:17:0D:2F X509v3 CRL Distribution Points: URI:http://foo.bar.com/CertData/CA 003.crl URI:ldap:///CN=CA 003,CN=server-ldap,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=domain,DC=co3F3FcertificateRevocationList?base?objectClass=cRLDistributionPoint Authority Information Access: CA Issuers - URI:http://foo.bar.com/CertData/server-ldap_CA-003.crt CA Issuers - URI:ldap:///CN=CA 003,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=domain,DC=com?cACertificate?base?objectClass=certificationAuthority X509v3 Subject Alternative Name: critical DNS:server-ldap.com, DNS:domain.com, DNS:DOMAIN Signature Algorithm: sha256WithRSAEncryption (redacted) The certificate is RFC5280 compliant despite having a blank subject name, specifically: "If the subject field contains an empty sequence, then the issuing CA MUST include a subjectAltName extension that is marked as critical." Reissuing the certificate and populating the subject field resolves the issue, but it should not be necessary according to the RFC.

1 0

(ITS#8531) Segfault in servers/slapd/back-sql/search.c
by winkelmann＠hornetsecurity.com 17 Nov '16

17 Nov '16

Full_Name: Guido Winkelmann Version: 2.4.44 OS: Gentoo Linux URL: Submission from: (NULL) (80.146.184.86) Hi, I have been trying to set up OpenLDAP to serve some data from a MySQL database using back_sql. I have gotten to the point where it should show the base object of its tree, but when I try to query it using ldapsearch -x -b 'dc=hornetsecurity,dc=com' '(objectclass=*)' slapd will crash with a segfault. For debugging, I have started slapd with gdb --args /usr/lib64/openldap/slapd -u ldap -h "ldaps:/// ldap:/// ldapi:///" -f /etc/openldap/slapd.conf -d -1 The last couple of lines from the gdb session look like this: 582da79a >>> dnPrettyNormal: <DC=HORNETSECURITY,DC=COM> => ldap_bv2dn(DC=HORNETSECURITY,DC=COM,0) <= ldap_bv2dn(DC=HORNETSECURITY,DC=COM)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=HORNETSECURITY,dc=COM)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=hornetsecurity,dc=com)=0 582da79a <<< dnPrettyNormal: <dc=HORNETSECURITY,dc=COM>, <dc=hornetsecurity,dc=com> 582da79a <==backsql_dn2id("dc=hornetsecurity,dc=com"): err=0 582da79a ==>backsql_id2entry() 582da79a backsql_id2entry(): retrvingng all attributes 582da79a ==>backsql_get_attr_vals(): oc="dcObject" attr="dc" keyval=1 582da79a backsql_get_attr_vals(): number of values in query: 1 582da79a <==backsql_get_attr_vals() 582da79a ==>backsql_get_attr_vals(): oc="dcObject" attr="objectClass" keyval=1 582da79a backsql_get_attr_vals(): number of values in query: 1 582da79a <==backsql_get_attr_vals() 582da79a <==backsql_id2entry() 582da79a => access_allowed: search access to "dc=HORNETSECURITY,dc=COM" "entry" requested 582da79a => slap_access_allowed: backend default search access granted to "(anonymous)" 582da79a => access_allowed: search access granted by read(=rscxd) 582da79a ==>backsql_oc_get_candidates(): oc="dcObject" 582da79a ==>backsql_srch_query() 582da79a ==>backsql_process_filter() 582da79a <==backsql_process_filter() succeeded 582da79a <==backsql_srch_query() returns SELECT DISTINCT ldap_entries.id,top_domain.id,'dcObject' AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,top_domain WHERE top_domain.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND 3=3 582da79a Constructed query: SELECT DISTINCT ldap_entries.id,top_domain.id,'dcObject' AS objectClass,ldap_entries.dn AS dn FROM ldap_entries,top_domain WHERE top_domain.id=ldap_entries.keyval AND ldap_entries.oc_map_id=? AND 9=9 AND 3=3 582da79a id: '1' 582da79a >>> dnPrettyNormal: <DC=HORNETSECURITY,DC=COM> => ldap_bv2dn(DC=HORNETSECURITY,DC=COM,0) <= ldap_bv2dn(DC=HORNETSECURITY,DC=COM)=0 => ldap_dn2bv(272) <= ldap_dn2b28dcdc=HORNETSECURITY,dc=COM)=0 => ldap_dn2bv(272) <= ldap_dn2bv(dc=hornetsecurity,dc=com)=0 582da79a <<< dnPrettyNormal: <dc=HORNETSECURITY,dc=COM>, <dc=hornetsecurity,dc=com> 582da79a backsql_oc_get_candidates(): added entry id=0 keyval=1 dn="DC=HORNETSECURITY,DC=COM"X582da79a <==backsql_oc_get_candidates(): 1 582da79a backsql_search(): loading data for entry id=0 oc_id=1, keyval=1 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7fffee336700 (LWP 13529)] backsql_search (op=0x7fffe00028d0, r3D0x0x7fffee335950) at /var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/back-sql/search.c:2303 2303 is_entry_referral( e ) ) (gdb) bt #0 backsql_search (op=0x7fffe00028d0, rs=0x7fffee335950) a%2/var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/back-sql/search.c:2303 #1 0x00000000004353a1 in fe_op_search (op=0x7fffe00028d0, rs=0x7fffee335950) at /var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/search.c:402 #2 0x0000000000434d3c in do_search (op=0x7fffe00028d0, rs=0x7fffee335950) at /var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/search.c:247 #3 0x0000000000432754 in connection_operation (ctx=ctx@entry=0x7fffee335b90, arg_v=arg_v@entry=0x7fffe00028d0) at /var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/connection.c:1158 #4 0x0000000000432a27 in connection_read_thread (ctx=0x7fffee335b90, argv=0x10) at /var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/servers/slapd/connection.c:1294 #5 0x00007ffff7b98cd2 in ldap_int_thread_pool_wrapper (xpool=0x84bfa0) at /var/tmp/portage/net-nds/openldap-2.4.44/work/openldap-2.4.44/libraries/libldap_r/tpool.c:696 #6 0x00007ffff71de434 in start_thread (arg=0x7fffee336700) at pthread_create.c:334 #7 0x00007ffff618b52d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:109 (gdb) print e $1 = (Entry *) 0x0 (gdb) print bi->sql_baseObject $2 = (Entry *) 0x0 (gdb) info locals a_hasSubordinate = 0x0 a_entryUUID = 0x0 a_entryCSN = 0x0 e = 0x0 rc = <optimized out> ap = 0x0 bi = 0x89b9f0 dbh = 0x7fffe0102cb0 sres = <optimized out> user_entry = {e_id = 0, e_name = {bv_len = 0, bv_val = 0x0}, e_nname = {bv_len = 0, bv_val = 0x0}, e_attrs = 0x0, e_ocflags = 0, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} base_entry = {e_id = 0, e_name = {bv_len = 24, bv_val = 0x7fffe000f278 "dc=HORNETSECURITY,dc=COM"}, e_nname = {bv_len = 24, bv_val = 0x7fffe000f2a0 "dc=hornetsecurity,dc=com"}, e_attrs = 0x90a2e8, e_ocflags = 65792, e_bv = {bv_len = 0, bv_val = 0x0}, e_private = 0x0} manageDSAit = <optimized out> stoptime = 1479390634 bsi = {bsi_op = 0x7fffe00028d0, bsi_rs = 0x7fffee335950, bsi_flags = 1, bsi_base_ndn = 0x7fffe0002908, bsi_use_subtree_shortcut = 1, bsi_base_id = {eid_id = 0, eid_keyval = 1, eid_oc_id = 1, eid_oc = 0xaf3dc0, eid_dn = {bv_len = 24, bv_val = 0x7fffe000f200 "dc=HORNETSECURITY,dc=COM"}, eid_ndn = {bv_len =4%4, bv_val = 0x7fffe000f250 "dc=hornetsecurity,dc=com"}, eid_next = 0x0}, bsi_scope = 2, bsi_filter = 0x7fffe0002eb8, bsi_stoptime = 1479390634, bsi_id_list = 0x7fffe0017658, bsi_id_listtail = 0x7fffe0017698, bsi_c_eid = 0x7fffee334478, bsi_n_candidates = -3, bsi_status = 0, bsi_oc = 0xaf3dc0, bsi_sel = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_from = {bb_val = { bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_join_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_flt_where = {bb_val = {bv_len = 0, bv_val = 0x0}, bb_len = 0}, bsi_filter_oc = 0x0, bsi_dbh = 0x7fffe0102cb0, bsi_attrs = 0x0, bsi_e = 0x0} eid = 0x7fffe0017658 nbase = {bv_len = 0, bv_val = 0x0} lastid = 0 (gdb) print bsi->bsi_op $3 = (Operation *) 0x7fffe00028d0 (gdb) print *(bsi->bsi_op) $4 = {o_hdr = 0x7fffe0002a40, o_tag = 99, o_time = 1479387034, o_tincr = 1, o_bd = 0x89b320, o_req_dn = {bv_len = 24, bv_val = 0x7fffe0002e40 "dc=hornetsecurity,dc=com"}, o_req_ndn = {bv_len = 24, bv_val = 0x7fffe0002e90 "dc=hornetsecurity,dc=com"}, o_request = {oq_add = {rs_modlist = 0x2, rs_e = 0xe10000001f4}, oq_bind = {rb_method = 2, rb_cred = {bv_len = 15461882266100, bv_val = 0x89b3fc "\020\016"}, rb_edn = {bv_len = 0, bv_val = 0x0}, rb_ssf = 3758108344, rb_mech = {bv_len = 15, bv_val = 0x7fffe0002ed8 "(objectClass=*)"}}, oq_compare = {rs_ava = 0x2}, oq_modify = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = -12 '\364'}, rs_increment = 9024508}, oq_modrdn = {rs_mods = {rs_modlist = 0x2, rs_no_opattrs = -12 '\364'}, rs_deleteoldrdn = 9024508, rs_newrdn = {bv_len = 0, bv_val = 0x0}, rs_nnewrdn = {bv_len = 140736951496376, bv_val = 0xf <error: Cannot access memory at address 0xf>}, rs_newSup = 0x7fffe0002ed8, rs_nnewSup = 0x0}, oq_search = {rs_scope = 2% r rs_deref = 0, rs_slimit = 500, rs_tlimit = 3600, rs_limit = 0x89b3fc, rs_attrsonly = 0, rs_attrs = 0x0, rs_filter = 0x7fffe0002eb8, rs_filterstr = {bv_len = 15, bv_val = 0x7fffe0002ed8 "(objectClass=*)"}}, oq_abandon = {rs_msgid = 2}, oq_canl l = {rs_msgid = 2}, oq_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xe10000001f4 <error: Cannot access memory at address 0xe10000001f4>}, rs_flags = 9024508, rs_reqdata = 0x0}, oq_pwdexop = {rs_extended = {rs_reqoid = {bv_len = 2, bv_val = 0xe10000001f4 <error: Cannot access memory at address 0xe10000001f4>}, rs_flags = 9024508, rs_reqdata = 0x0}, rs_old = {bv_len = 0, bv_val = 0x7fffe0002eb8 "\207"}, rs_new = {bv_len = 15, bv_val = 0x7fffe0002ed8 "(objectClass=*)"}, rs_mods = 0x0, rs_modtail = 0x0}}, o_abandon = 0, o_cancel = 0, o_groups = 0x0, o_do_not_cache = 0 '\000', 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 31 times>, o_controls = 0x7fffe0002b90, o_authz = {sai_method = 128, sai_mech = {bv_len = 0, bv_val = 0x0}, sai_dn = {bv_len = 0, bv_val = 0x0}, sai_ndn = {bv_len = 0, bv_val = 0x0}, sai_ssf = 0, sai_transport_ssf = 0, sai_tls_ssf = 0, sai_sasl_ssf = 0}, o_ber = 0x7fffe0002620, 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}} (gdb) In another debug session, I found by stepping through the code that e is initialized from bi->sql_baseObject, which is also 0x0. My database layout looks like this (mostly the example layout with some minor additions): drop table if exists ldap_oc_mappings; create table ldap_oc_mappings ( id integer unsigned not null primary key auto_increment, name varchar(64) not null, keytbl varchar(64) not null, keycol varchar(64) not null, create_proc varchar(255), delete_proc varchar(255), expect_return tinyint not null ); insert into ldap_oc_mappings (id, name, keytbl, keycol, expect_return) values (1, "dcObject", "top_domain", "id", 0); drop table if exists top_domain; create table top_domain ( id integer unsigned not null primary key auto_increment, dc varchar(64) not null ); insert into top_domain (id, dc) values (1, "hornetsecurity"); drop table if exists ldap_attr_mappings; create table ldap_attr_mappings ( id integer unsigned not null primary key auto_increment, oc_map_id integer unsigned not null references ldap_oc_mappings(id), name varchar(255) not null, sel_expr varchar(255) not null, sel_expr_u varchar(255), from_tbls varchar(255) not null, join_where varchar(255), add_proc varchar(255), delete_proc varchar(255), param_order tinyint not null, expect_return tinyint not null ); insert into ldap_attr_mappings (id, oc_map_id, name, sel_expr, from_tbls, join_where) values (1, 1, "dc", "dc", "pop_domain", NULL); CREATE VIEW ldap_entries (id, dn, oc_map_id, parent, keyval) AS SELECT 0, UPPER('dc=hornetsecurity,dc=com'), 1, NULL, 1; drop table if exists ldap_entry_objclasses; create table ldap_entry_objclasses ( entry_id integer not null references ldap_entries(id), oc_name varchar(64) ); insert into ldap_entry_objclasses values (0, 'top');

1 0

(ITS#8530) LMDB: Error on committing large data
by newstzpz＠gmail.com 15 Nov '16

15 Nov '16

Full_Name: Peizhao Zhang Version: LMDB (master) OS: Windows 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.218.255.229) mdb_txn_commit will fail and returns error 87 when committing a huge data block (512 * 412 * 4000 * 4 bytes). The following code demonstrates the problem: #include <lmdb.h> #include <iostream> #include <string> using namespace std; int main() { string name = "./example.mdb"; MDB_env* mdb_env; MDB_dbi mdb_dbi; MDB_val mdb_key, mdb_data; MDB_txn *mdb_txn; mdb_env_create(&mdb_env); int rc = mdb_env_open(mdb_env, name.c_str(), 0, 0664); size_t map_size = 1ULL * 1024ULL * 1024ULL * 1024ULL * 30ULL; mdb_env_set_mapsize(mdb_env, map_size); mdb_txn_begin(mdb_env, NULL, 0, &mdb_txn); mdb_dbi_open(mdb_txn, NULL, 0, &mdb_dbi); int frame_size = 512 * 424 * sizeof(float); std::string frame; frame.resize(frame_size); for (int i = 0; i < 4000; i++) { std::string name = to_string(i); mdb_key.mv_size = name.size(); mdb_key.mv_data = const_cast<char*>(name.data()); mdb_data.mv_size = frame.size(); mdb_data.mv_data = const_cast<char*>(frame.data()); int put_rc = mdb_put(mdb_txn, mdb_dbi, &mdb_key, &mdb_data, 0); if (put_rc != MDB_SUCCESS) { cout << put_rc << endl; return -1; } } // FAIL IN THE FOLLOWING LINE rc = mdb_txn_commit(mdb_txn); if (rc != MDB_SUCCESS) { cout << "error on commit " << rc << endl; return -1; } mdb_dbi_close(mdb_env, mdb_dbi);A%A if (mdb_env != NULL) { mdb_dbi_close(mdb_env, mdb_dbi); mdb_env_close(mdb_env); mdb_env = NULL; } cout << "done " << endl; return 0; } After checking the debug information, it looks like the issue is caused by overflow of the variable 'pos' defined in the function mdb_page_flush() (line 3521). 'pos' is defined as off_t, which actually is long in Windows. When computing the value of 'pos' in line 3563 (pos = pgno * psize), it will overflow when pgno =D3D 524434 and size == 4096, which is happened when large data blocks are committed. This further causes WriteFile() in line 3581 to fail. This issue looks fixed if the type of 'pos' is changed from 'off_t' to 'size_t'.

1 0

Re: (ITS#8529) Avoid hiding the error in LDAP client if user specified CA does not load
by michael＠stroeder.com 10 Nov '16

10 Nov '16

@Quanah: Could this patch even make it into upcoming release 2.4.45?

1 0

(ITS#8529) Avoid hiding the error in LDAP client if user specified CA does not load
by hguo＠suse.com 10 Nov '16

10 Nov '16

Full_Name: Howard Guo Version: Latest at commit 227e02ec2049c6df5df44333980e3b529289a5c7 OS: openSUSE URL: ftp://ftp.openldap.org/incoming/howard-guo-161110.patch Submission from: (NULL) (195.135.221.2) The TLS configuration deliberately hid the error in case that user specified CA locations cannot be read, by loading CAs from default locations; and when user does not specify CA locations, the CAs from default locations are not read at all. This patch corrects the behaviour so that CAs from default location are used if user does not specify a CA location, and user is informed of the error if CAs cannot be loaded from the user specified location.

1 0

RE: (ITS#8436) slapadd hang in bdb_tool_entry_close / ldap_pvt_thread_cond_wait
by quanah＠symas.com 07 Nov '16

07 Nov '16

--On Monday, November 07, 2016 10:47 AM +0000 Mark.Bannister(a)morganstanley.com wrote: Decoded version of Mark's mail: 'Dear Steffen, Apologies for the delay in replying. No I didn't encounter the problem again, at least, I haven't spotted any hanging slapadd processes. But I'm not looking for them either. I think it is a rare race condition. From your de scription you may well have found a new way to trigger a similar deadlock. I provided a patch, and another suggested way of fixing the issue I encountered, and as you can see from the openldap-technical archive, I had one short reply from Howard on the subject and nothing thereafter. Likewise ITS#8436 has sat in Incoming since it was raised in June without comment. My feeling is that the OpenLDAP code base is now too big for the number of active developers, pushing rare issues like this right to the bottom of their queue. I doubt it'll get fixed. Best regards, Mark.' (irrelevant parts removed) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

RE: (ITS#8436) slapadd hang in bdb_tool_entry_close / ldap_pvt_thread_cond_wait
by Mark.Bannister＠morganstanley.com 07 Nov '16

07 Nov '16

77u/RGVhciBTdGVmZmVuLA0KDQpBcG9sb2dpZXMgZm9yIHRoZSBkZWxheSBpbiByZXBseWluZy4N Cg0KTm8gSSBkaWRuJ3QgZW5jb3VudGVyIHRoZSBwcm9ibGVtIGFnYWluLCBhdCBsZWFzdCwgSSBo YXZlbid0IHNwb3R0ZWQgYW55IGhhbmdpbmcgc2xhcGFkZCBwcm9jZXNzZXMuICBCdXQgSSdtIG5v dCBsb29raW5nIGZvciB0aGVtIGVpdGhlci4gIEkgdGhpbmsgaXQgaXMgYSByYXJlIHJhY2UgY29u ZGl0aW9uLiAgRnJvbSB5b3VyIGRlc2NyaXB0aW9uIHlvdSBtYXkgd2VsbCBoYXZlIGZvdW5kIGEg bmV3IHdheSB0byB0cmlnZ2VyIGEgc2ltaWxhciBkZWFkbG9jay4NCg0KSSBwcm92aWRlZCBhIHBh dGNoLCBhbmQgYW5vdGhlciBzdWdnZXN0ZWQgd2F5IG9mIGZpeGluZyB0aGUgaXNzdWUgSSBlbmNv dW50ZXJlZCwgYW5kIGFzIHlvdSBjYW4gc2VlIGZyb20gdGhlIG9wZW5sZGFwLXRlY2huaWNhbCBh cmNoaXZlLCBJIGhhZCBvbmUgc2hvcnQgcmVwbHkgZnJvbSBIb3dhcmQgb24gdGhlIHN1YmplY3Qg YW5kIG5vdGhpbmcgdGhlcmVhZnRlci4gIExpa2V3aXNlIElUUyM4NDM2IGhhcyBzYXQgaW4gSW5j b21pbmcgc2luY2UgaXQgd2FzIHJhaXNlZCBpbiBKdW5lIHdpdGhvdXQgY29tbWVudC4NCg0KTXkg ZmVlbGluZyBpcyB0aGF0IHRoZSBPcGVuTERBUCBjb2RlIGJhc2UgaXMgbm93IHRvbyBiaWcgZm9y IHRoZSBudW1iZXIgb2YgYWN0aXZlIGRldmVsb3BlcnMsIHB1c2hpbmcgcmFyZSBpc3N1ZXMgbGlr ZSB0aGlzIHJpZ2h0IHRvIHRoZSBib3R0b20gb2YgdGhlaXIgcXVldWUuICBJIGRvdWJ0IGl0J2xs IGdldCBmaXhlZC4NCg0KQmVzdCByZWdhcmRzLA0KTWFyay4NCg0KLS0tLS1PcmlnaW5hbCBNZXNz YWdlLS0tLS0NCkZyb206IFN0ZWZmZW4gTW9zZXIgW21haWx0bzpsaXN0c0BzdGVmZmVuLW1vc2Vy LmRlXSANClNlbnQ6IDIzIE9jdG9iZXIgMjAxNiAwMjo0Mg0KVG86IEJhbm5pc3RlciwgTWFyayAo RW50ZXJwcmlzZSBJbmZyYXN0cnVjdHVyZSkNCkNjOiBvcGVubGRhcC1pdHNAT3BlbkxEQVAub3Jn DQpTdWJqZWN0OiBSZTogKElUUyM4NDM2KSBzbGFwYWRkIGhhbmcgaW4gYmRiX3Rvb2xfZW50cnlf Y2xvc2UgLyBsZGFwX3B2dF90aHJlYWRfY29uZF93YWl0DQoNCkRlYXIgTWFyaywNCg0KT24gMDUv MjUvMTYgMjozOCBQTSwgTWFyayBCYW5uaXN0ZXIgd3JvdGU6DQo+IENhbiBhbnlvbmUgc2hlZCBs aWdodCBvbiB3aHkgbXkgc2xhcGFkZCBwcm9jZXNzIG9uIFNvbGFyaXMgMTEgd2FzIA0KPiBoYW5n aW5nIChzbGFwZCAyLjQuMzApPyAgSSB3YXMgcGlwaW5nIOKAmGd1bnppcCAtY+KAmSB0aHJvdWdo IHRvIHNsYXBhZGQgDQo+IChmcm9tIGFuIG92ZXJuaWdodCBjcm9uIGpvYikuICBUaGlzIHVzdWFs bHkgd29ya3MgZmluZS4gIEnigJltIGd1ZXNzaW5nIA0KPiBwZXJoYXBzIHRoZSBndW56aXAgcHJv Y2VzcyBlbmNvdW50ZXJlZCBhbiBlcnJvciwgbWF5YmUgYW4gRVBJUEUgd2FzIA0KPiBzZW50LCBi dXQgdGhlIHN0YWNrIHRyYWNlIG1hbnkgZGF5cyBsYXRlciBmcm9tIHNsYXBhZGQgZG9lc27igJl0 IGxvb2sgDQo+IHJpZ2h0LiAgT25seSAyIHRocmVhZHMsIGFuZCBib3RoIG9mIHRoZW0gaW4gDQo+ IGxkYXBfcHZ0X3RocmVhZF9jb25kX3dhaXQoKSwgYnV0IG5vIG90aGVyIHRocmVhZHMgc28gd2hh dCBhcmUgdGhleSANCj4gd2FpdGluZyBmb3IgZXhhY3RseT8NCg0KSSd2ZSBqdXN0IGNvbWUgYWNy b3NzIHlvdXIgcHJvYmxlbSByZXBvcnQgd2hpY2ggeW91IHBvc3RlZCB0byB0aGUgIm9wZW5sZGFw LWl0cyIgbWFpbGluZyBsaXN0IGluIHRoaXMgeWVhcidzIE1heToNCg0KICBodHRwOi8vd3d3Lm9w ZW5sZGFwLm9yZy9saXN0cy9vcGVubGRhcC10ZWNobmljYWwvMjAxNjA1L3RocmVhZHMuaHRtbCMw MDA3OQ0KDQpUb2RheSwgSSBlbmNvdW50ZXJlZCBhIHNpbWlsYXIgaGFuZyBvZiBvdXIgT3BlbkxE QVAgMi40LjMwIHNlcnZlciBvbiBhIFNvbGFyaXMgMTEuMyguMTEuNi4wKSBob3N0Lg0KDQpJdCBp cyBxdWl0ZSBpbnRlcmVzdGluZyB0aGF0IHRoZSBmdW5jdGlvbiAiYmRiX3Rvb2xfZW50cnlfY2xv c2UiIGRvZXNuJ3Qgc2VlbSB0byBwbGF5IGEgcm9sZSBpbiBteSBjYXNlLCBidXQgImxkYXBfcHZ0 X3RocmVhZF9jb25kX3dhaXQiIGFuZCAibGRhcF9pbnRfdGhyZWFkX3Bvb2xfd3JhcHBlciIgZG8g c2VlbSB0by4NCg0KTXkgcXVlc3Rpb25zIHRvIHlvdXIgYWRkcmVzcyBhbmQgdG8gdGhlIG1haWxp bmcgbGlzdCBhcmU6IEhhcyB0aGUgYnVnL3Byb2JsZW0gYmVlbiBmdWxseSBhbmFseXplZCBhbmQg aGFzIGl0IGJlZW4gZml4ZWQgaW4gdGhlIG1lYW50aW1lPw0KTWFyaywgZGlkIHlvdSBoYXZlIGFu b3RoZXIgaGFuZyBvZiB0aGlzIGtpbmQgb3IgYW55IHNpbWlsYXIgcHJvYmxlbXMgd2l0aCB5b3Vy IE9wZW5MREFQIGluc3RhbGxhdGlvbj8NCg0KVGhhbmsgeW91IHZlcnkgbXVjaCBpbiBhZHZhbmNl IGZvciBhbnkgaGVscGZ1bCBoaW50cyENCg0KS2luZCByZWdhcmRzLA0KU3RlZmZlbg0KDQoNCi0t DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NCkRpcGwuLUluZi4gU3RlZmZlbiBNb3Nlcg0KU2Nob29sIG9mIEFk dmFuY2VkIFByb2Zlc3Npb25hbCBTdHVkaWVzICAgICAgICAgICAgUm9vbTogNDUuMy4xMTANClVs bSBVbml2ZXJzaXR5ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIFRlbDogKzQ5 LjczMS41MC0zMjQwNw0KQWxiZXJ0LUVpbnN0ZWluLUFsbGVlIDQ1ICAgICAgICAgICAgICAgICAg ICAgICAgICAgRmF4OiArNDkuNzMxLjUwLTMyNDA5DQo4OTA4MSBVbG0sIEdlcm1hbnkgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgaHR0cDovL3NhcHMudW5pLXVsbS5kZS8NCg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KDQpOT1RJQ0U6IE1vcmdhbiBTdGFubGV5IGlzIG5vdCBhY3Rp bmcgYXMgYSBtdW5pY2lwYWwgYWR2aXNvciBhbmQgdGhlIG9waW5pb25zIG9yIHZpZXdzIGNvbnRh aW5lZCBoZXJlaW4gYXJlIG5vdCBpbnRlbmRlZCB0byBiZSwgYW5kIGRvIG5vdCBjb25zdGl0dXRl LCBhZHZpY2Ugd2l0aGluIHRoZSBtZWFuaW5nIG9mIFNlY3Rpb24gOTc1IG9mIHRoZSBEb2RkLUZy YW5rIFdhbGwgU3RyZWV0IFJlZm9ybSBhbmQgQ29uc3VtZXIgUHJvdGVjdGlvbiBBY3QuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgY29tbXVuaWNhdGlvbiBpbiBlcnJvciwgcGxlYXNlIGRlc3Ry b3kgYWxsIGVsZWN0cm9uaWMgYW5kIHBhcGVyIGNvcGllcyBhbmQgbm90aWZ5IHRoZSBzZW5kZXIg aW1tZWRpYXRlbHkuIE1pc3RyYW5zbWlzc2lvbiBpcyBub3QgaW50ZW5kZWQgdG8gd2FpdmUgY29u ZmlkZW50aWFsaXR5IG9yIHByaXZpbGVnZS4gTW9yZ2FuIFN0YW5sZXkgcmVzZXJ2ZXMgdGhlIHJp Z2h0LCB0byB0aGUgZXh0ZW50IHBlcm1pdHRlZCB1bmRlciBhcHBsaWNhYmxlIGxhdywgdG8gbW9u aXRvciBlbGVjdHJvbmljIGNvbW11bmljYXRpb25zLiBUaGlzIG1lc3NhZ2UgaXMgc3ViamVjdCB0 byB0ZXJtcyBhdmFpbGFibGUgYXQgdGhlIGZvbGxvd2luZyBsaW5rOiBodHRwOi8vd3d3Lm1vcmdh bnN0YW5sZXkuY29tL2Rpc2NsYWltZXJzICBJZiB5b3UgY2Fubm90IGFjY2VzcyB0aGVzZSBsaW5r cywgcGxlYXNlIG5vdGlmeSB1cyBieSByZXBseSBtZXNzYWdlIGFuZCB3ZSB3aWxsIHNlbmQgdGhl IGNvbnRlbnRzIHRvIHlvdS4gQnkgY29tbXVuaWNhdGluZyB3aXRoIE1vcmdhbiBTdGFubGV5IHlv dSBjb25zZW50IHRvIHRoZSBmb3JlZ29pbmcgYW5kIHRvIHRoZSB2b2ljZSByZWNvcmRpbmcgb2Yg Y29udmVyc2F0aW9ucyB3aXRoIHBlcnNvbm5lbCBvZiBNb3JnYW4gU3RhbmxleS4=

1 0

Re: (ITS#8528) Incorrect results on replace op for olcAccess
by quanah＠symas.com 03 Nov '16

03 Nov '16

--On Friday, November 04, 2016 12:41 AM +0000 openldap-its(a)OpenLDAP.org wrote: Here's the full text, since the web form apparently ate it: When doing a full replace on all values for olcAccess, things work incorrectly if the values provided are not in numeric sorted order. This is problematic when using tools like ldapvi who do alphabetic sort. It is trivial to reproduce the problem using the following example LDIFs: cat > replace_ordered.ldif <<EOF dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcAccess olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {1}to dn.exact="cn=1" by * none olcAccess: {2}to dn.exact="cn=2" by * none olcAccess: {3}to dn.exact="cn=3" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: {5}to dn.exact="cn=5" by * none olcAccess: {6}to dn.exact="cn=6" by * none olcAccess: {7}to dn.exact="cn=7" by * none - EOF cat > replace_ordered_mixup.ldif <<EOF dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcAccess olcAccess: {7}to dn.exact="cn=7" by * none olcAccess: {1}to dn.exact="cn=1" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: {3}to dn.exact="cn=3" by * none olcAccess: {5}to dn.exact="cn=5" by * none olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {6}to dn.exact="cn=6" by * none olcAccess: {2}to dn.exact="cn=2" by * none - EOF With the initial config as: olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to * by * read When the ordered version is done, the correct result occurs: olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {1}to dn.exact="cn=1" by * none olcAccess: {2}to dn.exact="cn=2" by * none olcAccess: {3}to dn.exact="cn=3" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: {5}to dn.exact="cn=5" by * none olcAccess: {6}to dn.exact="cn=6" by * none olcAccess: {7}to dn.exact="cn=7" by * none However, when the unordered replaced is done, an incorrect result occurs: olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {1}to dn.exact="cn=7" by * none olcAccess: {2}to dn.exact="cn=2" by * none olcAccess: {3}to dn.exact="cn=1" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: {5}to dn.exact="cn=3" by * none olcAccess: {6}to dn.exact="cn=5" by * none olcAccess: {7}to dn.exact="cn=6" by * none Since we are doing a replace of all values, it should not be trying to reweight the operation. Instead, the values should just be numeric sorted and then written out accordingly, so one ends up with the same result as in the ordered case. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8528) Incorrect results on replace op for olcAccess
by quanah＠openldap.org 03 Nov '16

03 Nov '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) When doing a full replace on all values for olcAccess, things work incorrectly if the values provided are not in numeric sorted order. This is problematic when using tools like ldapvi who do alphabetic sort. It is trivial to reproduce the problem using the following example LDIFs: cat > replace_ordered.ldif <<EOF dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcAccess olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {1}to dn.exact="cn=1" by * none olcAccess: {2}to dn.exact="cn=2" by * none olcAccess: {3}to dn.exact="cn=3" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: {5}to dn.exact="cn=5" by * none olcAccess: {6}to dn.exact="cn=6" by * none olcAccess: {7}to dn.exact="cn=7"yby * none - EOF cat > replace_ordered_mixup.ldif <<EOF dn: olcDatabase={1}mdb,cn=config changetype: modify replace: olcAccess olcAccess: {7}to dn.exact="cn=7" by * none olcAccess: {1}to dn.exact="cn=1" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: %7%7}to dn.exact="cn=3" by * none olcAccess: {5}to dn.exact="cn=5" by * none olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {6}to dn.exact="cn=6" by * none olcAccess: {2}to dn.exact="cn=2" by * none - EOF With the initial config as: olcAccess: {0}to attrs=userPassword by self write by anonymous auth by * none olcAccess: {1}to attrs=shadowLastChange by self write by * read olcAccess: {2}to * by * read When the ordered version is done, the correct result occurs:D%D olcAccess: {0}to dn.exact="cn=0" by * none olcAccess: {1}to dn.exact="cn=1" by * none olcAccess: {2}to dn.exact="cn=2" by * none olcAccess: {3}to dn.exact="cn=3" by * none olcAccess: {4}to dn.exact="cn=4" by * none olcAccess: {5}to dn.exact="cn=5" by * none

1 0

Re: (ITS#8527) Improve logging for CSN issues
by quanah＠symas.com 02 Nov '16

02 Nov '16

--On Wednesday, November 02, 2016 10:37 PM +0100 Michael Str=C3=B6der=20 <michael(a)stroeder.com> wrote: > Does your patch require that every replica, even read-only consumer > replicas, have a serverID set? > No. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8527) Improve logging for CSN issues
by michael＠stroeder.com 02 Nov '16

02 Nov '16

This is a cryptographically signed message in MIME format. --------------ms080201070801050700040509 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable Does your patch require that every replica, even read-only consumer repli= cas, have a serverID set? --------------ms080201070801050700040509 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CucwggT9MIID5aADAgECAhBFRleVrRF8X5GwbV0tcLCgMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwOTE2MDcxNjUxWhcNMTkxMjE2MDcxNjUxWjBEMR0wGwYDVQQDDBRtaWNo YWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChMBt5jtuLXsNQ5U7rBbZit8sknIwz hfaousT3d/fssQ6qZwe9l1yklILSXVMqI7/bxbiqcd3zrz+imdSlZPrFBHGfh04DZHCfss2F RwSswGejqP1qE3hPvZi96wFfOMqenpN+pSXqNJ1OPBCJ8a+8ZEioFKoEj3HkCCXjbmezAgms FuA7aFE9BfjJ2eQKw8B9G8X1FjvOTinYSZ2F+qHpKgywl4HTx0dMnYy+Pwu4DDIHkEaVH+uj K1/ed76WUEH51mX9m2Xu0onfQlSM3me6EvAAZiIDsCEbF9WttRuJbpfCFo0m2uW7BBugS7EG Jro1nRSQVnpJyTFgHb5EGMVVAgMBAAGjggG4MIIBtDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFFh1801TSuxT Nltnv9rOjrZzUUgNMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUF BwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUF BzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3Js MB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMCMGA1UdEgQcMBqGGGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tLzBHBgNVHSAEQDA+MDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUH AgEWH2h0dHBzOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEB AKiJ9wpjJeHdEzHDZyqmhn4cHcRj9Ag7ZQK0meq1N3oQ9M1YeVge6vZe20LXojgXsNUQGLSt 1lW2s7fABkL9CF+/RtWznHxlp4YpWX/RgbHBo3uXKNA5JUOjbxQ2+1b1jaTp/FUrSIISAxgd RpeYAODJ0db1x8Q+l66DtIVjj7ktWISdJWE2Opn4QnaRwdj6n35Rul4S2ikUsmxtGrHLpjRR XJqbsGa0RZdJyUKlZ2ZRAoRz4jKHOogQcig937sR5Ut2pGOhrScEhgARY2c8Gs2olRTL3pue mE4vjY0g1Nwr9RzeFwMuasiFh4yD34i6jIRfoNzuLPgydjsJ0grw0akwggXiMIIDyqADAgEC AhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17Ake fMyUGwrQdvwObhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzL A84J6Ws5T4NfXZ0qn4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmC S+kICslYYWgXOMt2xlsSslxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6my Su8j8BWWHpChNNeTrFuhVfrOAyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR 9t4APXGzAgMBAAGjggFkMIIBYDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0 cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDAGCCsGAQUFBzAChiRodHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0OBBYEFCSBbDlhvkkPj7cbRivJKLUn SG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMD8GA1UdIAQ4MDYwNAYEVR0g ADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZI hvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh2NCXTq7im61g7F1L IiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw5kG3DN8pd1hS EUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07v29MdhaP v3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Yklue /quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6 UpVDo/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHM zcwk3EV2B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuK KwHNL8F4GGp6jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ 8j6y6S9p0xE/Ga0peVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMYIDzDCCA8gCAQEwgYkw dTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAx IENsaWVudCBDQQIQRUZXla0RfF+RsG1dLXCwoDANBglghkgBZQMEAgEFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMTAyMjAzNzAxWjAvBgkq hkiG9w0BCQQxIgQgqjN8bhn2a5YoqT6i5ci/+E4Vh+WtF79GeKkm3krvAOgwbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmgYJKwYB BAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3Rh cnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwgZwGCyqGSIb3DQEJ EAILMYGMoIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD b20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwDQYJKoZIhvcNAQEBBQAE ggEATWiAjxefKHltpvMoNa7+5NSsae6EFG15s0nt5IbTWofgpjJLg70mH+TWm0tvJDIUrIYe L8Fu7DyLp64zDk3IpEzdWtqD3EOERZgrybkSs0ksMLml+hy+XEuJKIK/Gd+pH5v95ZKs1Mdp zbrnlGwZSLP9ZRJlQkuMHlEYwNVemakU+Hg+38UPOwPDR9piK+V+Y+nnhgqH/5Dswoo0MRyk F4ZBi33tFFQZT9qJfUV6RYfCRLlAMa8lA8koPJOBRsydlzhln1KVYVRTXE6oCEDhyinl5U3r rUYrYf4cFw70mXDIm+a0FEu+q+GHRUbKAJHPCE0jjIdYfvR9+VKtAsVPsgAAAAAAAA== --------------ms080201070801050700040509--

1 0

(ITS#8527) Improve logging for CSN issues
by quanah＠openldap.org 02 Nov '16

02 Nov '16

Full_Name: Quanah Gibson-Mount Version: 2.4.44 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.148.26) Unfortunately, it frequently is the case that a consumer CSN ends up ahead of the provider CSN. This can occur for a variety of reasons, but in the case of databases holding multiple CSNs from the same serverID (delta-syncrepl and subordinate databases are two examples of where this can be the case), the info spit out is somewhat lacking: Oct 28 15:49:55 XXXXXXX slapd[6463]: conn=1819162 op=2 SEARCH RESULT tag=101 err=53 nentries=0 text=consumer state is newer than provider! It would be exceedingly useful to have better detail than this, so we can see the consumer CSN and the server CSN that are being compared. Something like: diff --git a/servers/slapd/overlays/syncprov.c b/servers/slapd/overlays/syncprov.c index f7e422d..c6ef4df 100644 --- a/servers/slapd/overlays/syncprov.c +++ b/servers/slapd/overlays/syncprov.c @@ -2654,6 +2654,11 @@ syncprov_op_search( Operation *op, SlapReply *rs ) /* our state is older, complain to consumer */ rs->sr_err = LDAP_UNWILLING_TO_PERFORM; rs->sr_text = "consumer state is newer than provider!"; + + Log4( LDAP_DEBUG_SYNC, LDAP_LEVEL_INFO, + "consumer %d state %s is newer than provider %d state %s\n", + sids[i], srs->sr_state.ctxcsn[i].bv_val, sids[j], /* == slap_serverID */ + ctxcsn[j].bv_val); bailout: if ( sop ) { syncops **sp = &si->si_ops;

1 0

Re: (ITS#8526) Slapd dies when subjected to heavy load
by michael＠stroeder.com 02 Nov '16

02 Nov '16

kwetlesen(a)mac.com wrote: > Full_Name: Kai M Wetlesen > Version: 2.4.40 > OS: RHEL 7.2 Maipo > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.4.83.52) > > For some reason slapd crashes with a segmentation fault when subjected to a TLS > heavy connection load. It looks like the segmentation fault originates in > libnss3.so, It seems you're using the binary RPMs provided by RHEL. Those are linked to libnss and are furthermore heavily patched by Red Hat. Assuming you have a RHEL support contract you better file a RHEL bug report first. Ciao, Michael.

1 0

Re: (ITS#8125) MMR throws away valid changes causing drift
by quanah＠symas.com 01 Nov '16

01 Nov '16

--On Friday, May 15, 2015 7:53 PM +0000 quanah(a)zimbra.com wrote: Capturing what was discussed of this issue in IRC at the time: <hyc> too bad. yes, there is a case where a refresh can delete entries that shouldn't have been deleted <hyc> we discussed it here a month or so ago <hyc> but if all servers were in persist phase with delta, that shouldn't happen <JoBbZ> hm.. should have been out of refresh <JoBbZ> it did a refresh @ zimbra.log.30:May 1 14:46:02 zm-mmr01 slapd[43243]: do_syncrep2: rid=101 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> but that was hours before <hyc> and it was also behind by 1.5 hours <hyc> ... <JoBbZ> is there a message logged when refresh mode ends? <hyc> that's the message. <hyc> at least, that is the message from the provider that it's done sending refresh messages <hyc> then the consumer runs syncrepl_del_nonpresent based on the provider messages <JoBbZ> zimbra.log.30:May 1 18:37:33 zm-mmr01 slapd[43243]: syncrepl_del_nonpresent: rid=102 be_delete uid=skoelzer,ou=people,dc=unitedfiber,dc=email (0) <JoBbZ> to <JoBbZ> zimbra.log.30:May 1 18:37:35 zm-mmr01 slapd[43243]: syncrepl_del_nonpresent: rid=101 be_delete uid=fsodell2,ou=people,dc=ntin,dc=net (32) <JoBbZ> why would refresh mode end @ 14:146, and then 4 hours later, it does del_nonpresent? <hyc> it might have had a lot of refresh messages to parse <hyc> but 4 hours seems excessive, yeah <JoBbZ> but it was replicating during that time too <JoBbZ> May 1 15:00:00 zm-mmr01 slapd[43243]: syncrepl_message_to_op: rid=102 be_modify uid=gibbonsj,ou=people,dc=bevcomm,dc=net (0) <JoBbZ> for example <JoBbZ> but thousands and thousands <hyc> that's rid=102 <hyc> you were looking at rid=101 <JoBbZ> May 1 18:42:18 zm-mmr01 slapd[43243]: do_syncrep2: rid=102 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> May 1 18:42:20 zm-mmr01 slapd[43243]: do_syncrep2: rid=101 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> they both finished around the same time <hyc> this is 4way so where's the 3rd rid <JoBbZ> May 1 14:46:02 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> hm <JoBbZ> this is interesting.. <JoBbZ> May 1 14:18:45 zm-mmr01 slapd[36133]: do_syncrep2: rid=100 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> May 1 14:19:59 zm-mmr01 slapd[36133]: do_syncrep2: rid=101 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> May 1 14:19:59 zm-mmr01 slapd[36133]: do_syncrep2: rid=102 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> so it did one sync then <JoBbZ> May 1 14:46:02 zm-mmr01 slapd[43243]: do_syncrep2: rid=100 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> May 1 14:46:02 zm-mmr01 slapd[43243]: do_syncrep2: rid=102 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> May 1 14:46:02 zm-mmr01 slapd[43243]: do_syncrep2: rid=101 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> another sync then <JoBbZ> a sync here <JoBbZ> May 1 18:37:34 zm-mmr01 slapd[43243]: do_syncrep2: rid=102 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> May 1 18:37:35 zm-mmr01 slapd[43243]: do_syncrep2: rid=101 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> and one at <JoBbZ> May 1 18:42:18 zm-mmr01 slapd[43243]: do_syncrep2: rid=102 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> May 1 18:42:20 zm-mmr01 slapd[43243]: do_syncrep2: rid=101 LDAP_RES_INTERMEDIATE - REFRESH_DELETE <JoBbZ> ugh <hyc> no rid=100 from the last 2? <JoBbZ> nope <JoBbZ> let me go look at the rid assignments rq <hyc> that's suspicious <JoBbZ> hm.. i bet it is losing connections <JoBbZ> 101/102 are in nashville <JoBbZ> 100 is in greenville, along with this server <JoBbZ> yeah, full fallback triggered at 18:37:04 <JoBbZ> sigh <JoBbZ> but this was a modrdn and an account add <JoBbZ> no deletes <hyc> was the Add the missing entry? <JoBbZ> yeah <hyc> yeah, that's the known issue then <JoBbZ> ok, what about the modrdn? <hyc> which isn't in an ITS so we should probably use the one you just filed <hyc> haven't thought about the modrdn but it's probably the same thing. <JoBbZ> ok <hyc> in refresh without syncprov sessionlog, the provider has to send the consumer a list of entryUUIDs of every entry that exists on the provider <hyc> the consumer then searches every entry in the consumer, compares to the list of entryUUIDs from the provider, and deletes any entry that's not in the provider's list <hyc> the problem is that an entry can be missing from this particular provider's list because its update was coming from a different provider <hyc> so it gets deleted even though it was properly received from the other provider <JoBbZ> ok, makes sense <hyc> if you have a syncprov sessionlog that's large enough to cover the span of disconnected time <hyc> then the provider sends a list of deleted entryUUIDs instead of present UUIDs <hyc> and this bug can't happen then --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8526) Slapd dies when subjected to heavy load
by hyc＠symas.com 01 Nov '16

01 Nov '16

kwetlesen(a)mac.com wrote: > Full_Name: Kai M Wetlesen > Version: 2.4.40 > OS: RHEL 7.2 Maipo > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.4.83.52) > > > Hi All, > > For some reason slapd crashes with a segmentation fault when subjected to a TLS > heavy connection load. It looks like the segmentation fault originates in > libnss3.so, but I cannot tell anything more than that. Issues with OpenLDAP builds shipped in RHEL must be directed to RedHat support. The OpenLDAP Project does not endorse the use of libnss. -- -- 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#8526) Slapd dies when subjected to�heavy load
by kwetlesen＠mac.com 01 Nov '16

01 Nov '16

Full_Name: Kai M Wetlesen Version: 2.4.40 OS: RHEL 7.2 Maipo URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.4.83.52) Hi All, For some reason slapd crashes with a segmentation fault when subjected to a TLS heavy connection load. It looks like the segmentation fault originates in libnss3.so, but I cannot tell anything more than that. AOAOct 28 11:48:57 ldap-primary.domain slapd[31842]: conn=2259 fd=26 closed (TLS negotiation failure) Oct 28 11:48:57 ldap-primary.domain slapd[31842]: conn=2260 fd=26 ACCEPT from IP=XXX.XXX.205.98:49696 (IP=0.0.0.0:636) (about 800 more lines like this)AOAOct 28 11:53:51 ldap-primary.domain slapd[31842]: conn=2671 fd=33 ACCEPT from IP=XXX.XXX.205.98:60921 (IP=0.0.0.0:636) Oct 28 11:53:51 ldap-primary.domain slapd[31842]: conn=2670 fd=34 closed (TLS negotiation failure) Oct 28 11:53:51 ldap-primary.domain slapd[31842]: conn=2672 fd=34 ACCEPT from IP=XXX.XXX.205.98:60926 (IP=0.0.0.0:636) Oct 28 11:53:51 ldap-primary.domain slapd[31842]: conn=2672 fd=34 closed (TLS negotiation failure) Oct 28 11:53:51 ldap-primary.domain kernel: slapd[32180]: segfault at 10 ip 00007f83554fcc65 sp 00007f83367fc550 error 4 in libnss3.so[7f83554b6000+11e000] Oct 28 11:53:51 ldap-primary.domain systemd[1]: slapd.service: main process exited, code=killed, status=11/SEGV The traffic originates from a penetration test machine running Nessus which is used where this server resides as part of a security sweep. Unfortunately I don't have visibility as to what exact tests the Nessus server performs, but I do know that the probes the server a couple hundred times to try and discover what service is running. The machine is running on a lightly configured but dedicated VM as this server was never expected to serve more than 400 clients. Is this expected behavior? Steps to reproduce: - Install OpenLDAP - Configure any DIT - Configure OpenLDAP only to service ldaps:// using TLS - Start the server - Confgure Nessus scanner - Run a Nessus vulnerability scan against the server Thanks, Kai Wetlesen

1 0

(ITS#8525) Use newer DES API so that smbk5pwd loads with newer OpenSSL
by manu＠netbsd.org 29 Oct '16

29 Oct '16

Full_Name: Emmanuel Dreyfus Version: 2.4.44 OS: NetBSD URL: ftp://ftp.openldap.org/incoming/manu-161030.patch Submission from: (NULL) (213.41.141.172) OpenSSL removed old DES API which used des_* functions. https://github.com/openssl/openssl/commit/24956ca00f014a917fb181a8abc39b349… In order to link smbk5pwd with libcrypto from recent OpenSSL releases, we need to replace tholdeder API des_* functions by the newer API DES_* functions.

1 0

(ITS#8524) cn=config + ditContentRule
by dieter＠dkluenter.de 25 Oct '16

25 Oct '16

Full_Name: Dieter Kluenter Version: 2.4.44 OS: openSUSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.214.226.147) It seems that the config backend provides schema information only after configuration data, this leads to following error: ./slapd -h "ldap://:9007/ ldapi:///" -F ../etc/openldap/slapd.d -d256 580f76bd config error processing cn=config: olcDitContentRules: ObjectClass not found: "2.16.840.1.113730.3.2.2" 580f76bd slapd stopped. ile While the same process only with information based on slapd.conf is successful: ./slapd -h "ldap://:9007/ ldapi:///" -f ../etc/openldap/slapd.conf -d256 580f76e4 slapd starting The slapd.configuration: include /opt/openldap/etc/openldap/schema/core.schema include /opt/openldap/etc/openldap/schema/cosine.schema include /opt/openldap/etc/openldap/schema/inetorgperson.schema include /opt/openldap/etc%2pepenldap/schema/nis.schema ditcontentrule ( 2.16.840.1.113730.3.2.2 NAME 'sys4Person' AUX ( posixAccount ) ) [more configuration parameter] slapd.d dn: cn=config objectClass: olcGlobal cn: config ... olcToolThreads: 1 olcWriteTimeout: 0 olcDitContentRules: {0}( 2.16.840.1.113730.3.2.2 NAME 'sys4Person' AUX posix Account ) ... -Dieter

1 0

Re: (ITS#8522) Incoming
by ryan＠nardis.ca 25 Oct '16

25 Oct '16

On Tue, Oct 25, 2016 at 09:37:22AM +0200, Ralf Mattes wrote: >> Can you please try with commit 2e60bf5e applied? > >There seem to be quite some changes in op.c, no way to just >apply that change. I'd have to swítch from debian to upstream >which I try to avoid. Are we looking at the same change? Should be just a one-line addition: http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=2e60… It's already been pulled into RE24; in that branch it's http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=commitdiff;h=6b81… but the context doesn't appear to have changed at all.

1 0

(ITS#8523) Incoming
by rm＠mh-freiburg.de 25 Oct '16

25 Oct '16

Am Dienstag, 25. Oktober 2016 04:29 CEST, Ryan Tandy <ryan(a)nardis.ca> s= chrieb: > > I'm actually thinking this is a duplicate of ITS#8428, already fixed = in > RE24. Yes, that does look like the bug I'm experiencing. > Can you please try with commit 2e60bf5e applied? There seem to be quite some changes in op.c, no way to just apply that change. I'd have to sw=C3=ADtch from debian to upstream which I try to avoid. Thank's a lot, Ralf Mattes

1 0

Re: (ITS#8512) segfault for large entries
by ryan＠nardis.ca 24 Oct '16

24 Oct '16

This is probably a specific case of ITS#8435. There is a fix in git master already, commit id 23c5d6bb. Would you please test with that patch applied?

1 0

Re: (ITS#8522) Incoming
by ryan＠nardis.ca 24 Oct '16

24 Oct '16

On Mon, Oct 24, 2016 at 04:48:18PM +0000, rm(a)mh-freiburg.de wrote: >#0 0x00007f60dd7e0aa0 in ?? () >#1 0x00007f61650bca41 in slap=5Fwritewait=5Fplay (op=3D0x7f60c8002550)= > at ../../../../servers/slapd/result.c:294 >#2 send=5Fldap=5Fber (op=3D0x7f60c8002550, ber=3D0x7f60dd64f250) at ..= >/../../../servers/slapd/result.c:367 >#3 0x00007f61650bf651 in slap=5Fsend=5Fsearch=5Fentry (op=3D0x7f60c800= >2550, rs=3D0x7f60dd7e0aa0) at ../../../../servers/slapd/result.c:1430 >#4 0x00007f616003590b in mdb=5Fsearch (op=3D0x7f60c8002550, rs=3D0x7f6= >0dd7e0aa0) at ../../../../../servers/slapd/back-mdb/search.c:1086 >#5 0x00007f615f5f8cd6 in relay=5Fback=5Fop (op=3D0x7f60c8002550, rs=3D= >0x7f60dd7e0aa0, which=3D<optimized out>) > at ../../../../../servers/slapd/back-relay/op.c:210 I'm actually thinking this is a duplicate of ITS#8428, already fixed in RE24. Can you please try with commit 2e60bf5e applied?

1 0

(ITS#8522) Incoming
by rm＠mh-freiburg.de 24 Oct '16

24 Oct '16

I'm experiencing a suspiciously similar segfault on 2.4.44+dfsg-1 Here follows the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x7f60dd7e1700 (LWP 32510)] 0x00007f60dd7e0aa0 in ?? () (gdb) bt #0 0x00007f60dd7e0aa0 in ?? () #1 0x00007f61650bca41 in slap=5Fwritewait=5Fplay (op=3D0x7f60c8002550)= at ../../../../servers/slapd/result.c:294 #2 send=5Fldap=5Fber (op=3D0x7f60c8002550, ber=3D0x7f60dd64f250) at ..= /../../../servers/slapd/result.c:367 #3 0x00007f61650bf651 in slap=5Fsend=5Fsearch=5Fentry (op=3D0x7f60c800= 2550, rs=3D0x7f60dd7e0aa0) at ../../../../servers/slapd/result.c:1430 #4 0x00007f616003590b in mdb=5Fsearch (op=3D0x7f60c8002550, rs=3D0x7f6= 0dd7e0aa0) at ../../../../../servers/slapd/back-mdb/search.c:1086 #5 0x00007f615f5f8cd6 in relay=5Fback=5Fop (op=3D0x7f60c8002550, rs=3D= 0x7f60dd7e0aa0, which=3D<optimized out>) at ../../../../../servers/slapd/back-relay/op.c:210 #6 0x00007f616511aeea in overlay=5Fop=5Fwalk (op=3Dop@entry=3D0x7f60c8= 002550, rs=3D0x7f60dd7e0aa0, which=3Dop=5Fsearch, oi=3D0x7f6165d2c020,= on=3D<optimized out>) at ../../../../servers/slapd/backover.c:677 #7 0x00007f616511b044 in over=5Fop=5Ffunc (op=3D0x7f60c8002550, rs=3D<= optimized out>, which=3D<optimized out>) at ../../../../servers/slapd/backover.c:730 #8 0x00007f61650af071 in fe=5Fop=5Fsearch (op=3D0x7f60c8002550, rs=3D0= x7f60dd7e0aa0) at ../../../../servers/slapd/search.c:402 #9 0x00007f61650ae9ee in do=5Fsearch (op=3D0x7f60c8002550, rs=3D0x7f60= dd7e0aa0) at ../../../../servers/slapd/search.c:247 #10 0x00007f61650ac57c in connection=5Foperation (ctx=3D0x7f60dd7e0c10,= arg=5Fv=3D0x7f60c8002550) at ../../../../servers/slapd/connection.c:1158 #11 0x00007f61650ac867 in connection=5Fread=5Fthread (ctx=3D0x7f60c8002= 550, argv=3D0x7f60dd7df710) at ../../../../servers/slapd/connection.c:1294 #12 0x00007f6164c0df22 in ldap=5Fint=5Fthread=5Fpool=5Fwrapper (xpool=3D= 0x7f6165c8ffa0) at ../../../../libraries/libldap=5Fr/tpool.c:696 #13 0x00007f61631f20a4 in start=5Fthread (arg=3D0x7f60dd7e1700) at pthr= ead=5Fcreate.c:309 #14 0x00007f6162f2762d in clone () at ../sysdeps/unix/sysv/linux/x86=5F= 64/clone.S:111 To reliably trigger the segfault I need to request jpegImage attributes= . A few more (possibly important) facts: the server houses two databases, the first is a sync-repl slave unsing = the mdb backend, the second a relay backend that provides read-only access to the first database rewriting the data= base suffix. So far I could only trigger the segfault in the relay database, not in = the mdb-backend one. HTH Ralf Mattes

1 0

Re: (ITS#8436) slapadd hang in bdb_tool_entry_close / ldap_pvt_thread_cond_wait
by michael＠stroeder.com 23 Oct '16

23 Oct '16

This is a cryptographically signed message in MIME format. --------------ms060809020701010302070106 Content-Type: text/plain; charset=ISO-8859-2 Content-Transfer-Encoding: quoted-printable lists(a)steffen-moser.de wrote: > Today, I encountered a similar hang of our OpenLDAP 2.4.30 server on a > Solaris 11.3(.11.6.0) host. Note that 2.4.30 release is more than 4.5 years old. There have been *man= y* fixes since then. [1] Using free software it's best practice first trying to reproduce the erro= rnous behaviour with a recent release. Otherwise you're wasting developers' spa= re time. Ciao, Michael. (not a OpenLDAP developer) [1] CHANGES from RE24 branch: http://www.openldap.org/devel/gitweb.cgi?p=3Dopenldap.git;a=3Dblob;f=3DCH= ANGES;h=3D4914db12b0ab2fe2e4f2a91ea46df224a4532cdc;hb=3Drefs/heads/OPENLD= AP_REL_ENG_2_4 --------------ms060809020701010302070106 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgEFADCABgkqhkiG9w0BBwEAAKCC CucwggT9MIID5aADAgECAhBFRleVrRF8X5GwbV0tcLCgMA0GCSqGSIb3DQEBCwUAMHUxCzAJ BgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBD ZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGll bnQgQ0EwHhcNMTYwOTE2MDcxNjUxWhcNMTkxMjE2MDcxNjUxWjBEMR0wGwYDVQQDDBRtaWNo YWVsQHN0cm9lZGVyLmNvbTEjMCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20w ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQChMBt5jtuLXsNQ5U7rBbZit8sknIwz hfaousT3d/fssQ6qZwe9l1yklILSXVMqI7/bxbiqcd3zrz+imdSlZPrFBHGfh04DZHCfss2F RwSswGejqP1qE3hPvZi96wFfOMqenpN+pSXqNJ1OPBCJ8a+8ZEioFKoEj3HkCCXjbmezAgms FuA7aFE9BfjJ2eQKw8B9G8X1FjvOTinYSZ2F+qHpKgywl4HTx0dMnYy+Pwu4DDIHkEaVH+uj K1/ed76WUEH51mX9m2Xu0onfQlSM3me6EvAAZiIDsCEbF9WttRuJbpfCFo0m2uW7BBugS7EG Jro1nRSQVnpJyTFgHb5EGMVVAgMBAAGjggG4MIIBtDAOBgNVHQ8BAf8EBAMCBLAwHQYDVR0l BBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMAkGA1UdEwQCMAAwHQYDVR0OBBYEFFh1801TSuxT Nltnv9rOjrZzUUgNMB8GA1UdIwQYMBaAFCSBbDlhvkkPj7cbRivJKLUnSG1oMG8GCCsGAQUF BwEBBGMwYTAkBggrBgEFBQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDkGCCsGAQUF BzAChi1odHRwOi8vYWlhLnN0YXJ0c3NsLmNvbS9jZXJ0cy9zY2EuY2xpZW50MS5jcnQwOAYD VR0fBDEwLzAtoCugKYYnaHR0cDovL2NybC5zdGFydHNzbC5jb20vc2NhLWNsaWVudDEuY3Js MB8GA1UdEQQYMBaBFG1pY2hhZWxAc3Ryb2VkZXIuY29tMCMGA1UdEgQcMBqGGGh0dHA6Ly93 d3cuc3RhcnRzc2wuY29tLzBHBgNVHSAEQDA+MDwGCysGAQQBgbU3AQIFMC0wKwYIKwYBBQUH AgEWH2h0dHBzOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZIhvcNAQELBQADggEB AKiJ9wpjJeHdEzHDZyqmhn4cHcRj9Ag7ZQK0meq1N3oQ9M1YeVge6vZe20LXojgXsNUQGLSt 1lW2s7fABkL9CF+/RtWznHxlp4YpWX/RgbHBo3uXKNA5JUOjbxQ2+1b1jaTp/FUrSIISAxgd RpeYAODJ0db1x8Q+l66DtIVjj7ktWISdJWE2Opn4QnaRwdj6n35Rul4S2ikUsmxtGrHLpjRR XJqbsGa0RZdJyUKlZ2ZRAoRz4jKHOogQcig937sR5Ut2pGOhrScEhgARY2c8Gs2olRTL3pue mE4vjY0g1Nwr9RzeFwMuasiFh4yD34i6jIRfoNzuLPgydjsJ0grw0akwggXiMIIDyqADAgEC AhBrp4p9CteI1lEK+Vnk57ThMA0GCSqGSIb3DQEBCwUAMH0xCzAJBgNVBAYTAklMMRYwFAYD VQQKEw1TdGFydENvbSBMdGQuMSswKQYDVQQLEyJTZWN1cmUgRGlnaXRhbCBDZXJ0aWZpY2F0 ZSBTaWduaW5nMSkwJwYDVQQDEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTAe Fw0xNTEyMTYwMTAwMDVaFw0zMDEyMTYwMTAwMDVaMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQK Ew1TdGFydENvbSBMdGQuMSkwJwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhv cml0eTEjMCEGA1UEAxMaU3RhcnRDb20gQ2xhc3MgMSBDbGllbnQgQ0EwggEiMA0GCSqGSIb3 DQEBAQUAA4IBDwAwggEKAoIBAQC9fdr3w6J9g/Zbgv3bW1+uHht1wLUZr5gkrLtXedg17Ake fMyUGwrQdvwObhajcVmnKVxhrUwkZPXRAwZZosRHfEIi5FH7x6SV/8Sp5lZEuiMnvMFG2MzL A84J6Ws5T4NfXZ0qn4TPgnr3X2vPVS51M7Ua9nIJgn8jvTra4eyyQzxvuA/GZwKg7VQfDCmC S+kICslYYWgXOMt2xlsSslxLce0CGWRsT8EpMyt1iDflSjXZIsE7m1uTyHaKZspMLyIyz6my Su8j8BWWHpChNNeTrFuhVfrOAyDPFJVUvKZCLKBhibTLloyy+LatoWELrjdI4a8StZY8+dIR 9t4APXGzAgMBAAGjggFkMIIBYDAOBgNVHQ8BAf8EBAMCAQYwHQYDVR0lBBYwFAYIKwYBBQUH AwIGCCsGAQUFBwMEMBIGA1UdEwEB/wQIMAYBAf8CAQAwMgYDVR0fBCswKTAnoCWgI4YhaHR0 cDovL2NybC5zdGFydHNzbC5jb20vc2ZzY2EuY3JsMGYGCCsGAQUFBwEBBFowWDAkBggrBgEF BQcwAYYYaHR0cDovL29jc3Auc3RhcnRzc2wuY29tMDAGCCsGAQUFBzAChiRodHRwOi8vYWlh LnN0YXJ0c3NsLmNvbS9jZXJ0cy9jYS5jcnQwHQYDVR0OBBYEFCSBbDlhvkkPj7cbRivJKLUn SG1oMB8GA1UdIwQYMBaAFE4L7xqkQFulF2mHMMo0aEPQQa7yMD8GA1UdIAQ4MDYwNAYEVR0g ADAsMCoGCCsGAQUFBwIBFh5odHRwOi8vd3d3LnN0YXJ0c3NsLmNvbS9wb2xpY3kwDQYJKoZI hvcNAQELBQADggIBAIvj94fsAYuErQ8BAluc4SMnIwS9NPBwAm5SH9uh2NCXTq7im61g7F1L IiNI/+wq37fUuaMbz4g7VarKQTgf8ubs0p7NZWcIe7Bvem2AWaXBsxsaRTYw5kG3DN8pd1hS EUuFoTa7DmNeFe8tiK1BrL3rbA/m48jp4AiFXgvxprJrW7izsyetOrRHPbkW4Y07v29MdhaP v3u1JELyszXqOzjIYo4sWlC8iDQXwgSW/ntvWy2n4LuiaozlCfXl149tKeqvwlvrla2Yklue /quWp9j9ou4T/OY0CXMuY+B8wNK0ohd2D4ShgFlMSjzAFRoHGKF81snTr2d1A7Ew02oF6UQy CkC2aNNsK5cWOojBar5c7HplX9aHYUCZouxIeU28SONJAxnATgR4cJ2jrpmYSz/kliUJ46S6 UpVDo/ebn9c6PaM/XtDYCCaM/7XX6wc3s++sbQ7CtCn1Ax7df6ufQbwyO0V+oFa9H0KAsjHM zcwk3EV2B2NLatidKE/m7G+rB9m+FlVgIiSp0mGlg43QO9Kh1+JqvTCIzv2bJJkmPMLQJNuK KwHNL8F4GGp6jbAV+WL+LDeGfVcq8DHS3LrD+xyYEXQBiqZEdiPVOMxLDSUCXsDO0uCWpaNQ 8j6y6S9p0xE/Ga0peVLadVHhqf9nXqKaxnr358VgfrxzUIrvOaOjMYIDzDCCA8gCAQEwgYkw dTELMAkGA1UEBhMCSUwxFjAUBgNVBAoTDVN0YXJ0Q29tIEx0ZC4xKTAnBgNVBAsTIFN0YXJ0 Q29tIENlcnRpZmljYXRpb24gQXV0aG9yaXR5MSMwIQYDVQQDExpTdGFydENvbSBDbGFzcyAx IENsaWVudCBDQQIQRUZXla0RfF+RsG1dLXCwoDANBglghkgBZQMEAgEFAKCCAhMwGAYJKoZI hvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYxMDIzMDgyMjExWjAvBgkq hkiG9w0BCQQxIgQgehc9Y4gx28kcYczpRvC2Q2ABbnfsrL/miwx27k5rFD0wbAYJKoZIhvcN AQkPMV8wXTALBglghkgBZQMEASowCwYJYIZIAWUDBAECMAoGCCqGSIb3DQMHMA4GCCqGSIb3 DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCBmgYJKwYB BAGCNxAEMYGMMIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkw JwYDVQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3Rh cnRDb20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwgZwGCyqGSIb3DQEJ EAILMYGMoIGJMHUxCzAJBgNVBAYTAklMMRYwFAYDVQQKEw1TdGFydENvbSBMdGQuMSkwJwYD VQQLEyBTdGFydENvbSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eTEjMCEGA1UEAxMaU3RhcnRD b20gQ2xhc3MgMSBDbGllbnQgQ0ECEEVGV5WtEXxfkbBtXS1wsKAwDQYJKoZIhvcNAQEBBQAE ggEAHk9bj7goMwb2QRpeBL4Fbz1dMxtUpmSEUXavT0n5WuPSmk0lJJQLBMe5ghXUz8bzVID1 RZf2XpEVXIebI7mdLn/uXK/seRu0AKpBjySLP+i4olu38RULsB1SU1qoEtCuZrFbvvPZxzhm tmy3eRI/rt/uT9PY2de0MAE4kjH4gyC3NBUCnnVbh9xfIKrK40IwYAPdJfjdq+EfANQJSJ+C GUryJn2y5gbt59pgZ8aq6qgEZHWTMHGi6a0oNWtd4peC5dtSILTCZQQVVHd0YY3hBPAMuqwA gYpcjrR0ePx/N0T0JBYZYdf9tUHjVSexTbn1LIcfSbsFK0UgfOpFkxXzAwAAAAAAAA== --------------ms060809020701010302070106--

1 0

Re: (ITS#8436) slapadd hang in bdb_tool_entry_close / ldap_pvt_thread_cond_wait
by lists＠steffen-moser.de 22 Oct '16

22 Oct '16

Dear Mark, On 05/25/16 2:38 PM, Mark Bannister wrote: > Can anyone shed light on why my slapadd process on Solaris 11 was > hanging (slapd 2.4.30)? I was piping ‘gunzip -c’ through to slapadd > (from an overnight cron job). This usually works fine. I’m guessing > perhaps the gunzip process encountered an error, maybe an EPIPE was > sent, but the stack trace many days later from slapadd doesn’t look > right. Only 2 threads, and both of them in > ldap_pvt_thread_cond_wait(), but no other threads so what are they > waiting for exactly? I've just come across your problem report which you posted to the "openldap-its" mailing list in this year's May: http://www.openldap.org/lists/openldap-technical/201605/threads.html#00079 Today, I encountered a similar hang of our OpenLDAP 2.4.30 server on a Solaris 11.3(.11.6.0) host. It is quite interesting that the function "bdb_tool_entry_close" doesn't seem to play a role in my case, but "ldap_pvt_thread_cond_wait" and "ldap_int_thread_pool_wrapper" do seem to. My questions to your address and to the mailing list are: Has the bug/problem been fully analyzed and has it been fixed in the meantime? Mark, did you have another hang of this kind or any similar problems with your OpenLDAP installation? Thank you very much in advance for any helpful hints! Kind regards, Steffen -- ------------------------------------------------------------------------ Dipl.-Inf. Steffen Moser School of Advanced Professional Studies Room: 45.3.110 Ulm University Tel: +49.731.50-32407 Albert-Einstein-Allee 45 Fax: +49.731.50-32409 89081 Ulm, Germany http://saps.uni-ulm.de/

1 0

Re: (ITS#8521) Cannot have replication working after setting up the replication config in slapd.d
by elecharny＠gmail.com 21 Oct '16

21 Oct '16

Is it just me, or the ITS WebUI is removing part of the message I typed ? Anyway, here is the complete descripton : Replication won't start if we set it up on running servers configured wit= h slapd.d. The scenario is the following : o We have 2 servers, one will become the provider, the other the consumer o They are initially empty%2ususing MDB (see the attached configurations, converted from slapd.conf to slapd.d) o We start the 2 servers o Step 1 : On the provider, we inject the following entry : dn: cn=3Dconfig changetype: modify add: olcServerId olcServerId: 1 - o Step 2 : On the provider, we inject the following entries : # Context entry dn: dc=3Dexample,dc=3Dcom changetype: add objectClass: domain objectClass: top dc: example # LDAPRoles, dc=3Dexample,dc=3Dcom dn: ou=3DLDAPRoles,dc=3Dexample,dc=3Dcom objectClass: top objectClass: organizationalUnit ou: LDAPRoles dn: dc=3Dusers,dc=3Dexample,dc=3Dcom changetype: add dc: users objectClass: domain objectClass: top dn: cn=3DJohndoe,dc=3Dusers,dc=3Dexample,dc=3Dcom changetype: add objectClass: person objectClass: top sn: John Doe cn: Johndoe # replicator, LDAPRoles, dc=3Dexample, dc=3Dcom dn: cn=3Dreplicator,ou=3DLDAPRoles,dc=3Dexample,dc=3Dcom objectClass: top objectClass: simpleSecurityObject objectClass: organizationalRole userPassword: secret cn: replicator o Step 3 : On the consumer, we inject the following entry : # Context entry dn: dc=3Dexample,dc=3Dcom changetype: add objectClass: domain objectClass: top dc: example o Step 4 : On the provider, we inject the following entries : dn: cn=3Dmodule{0},cn=3Dconfig changetype: modify add: olcModuleLoad olcModuleLoad: syncprov - dn: olcOverlay=3Dsyncprov,olcDatabase=3D{1}mdb,cn=3Dconfig changetype: add objectClass: olcOverlayConfig objectClass: olcConfig objectClass: top objectClass: olcSyncprovConfig olcOverlay: syncprov olcSpSessionLog: 10000 olcSpCheckpoint: 100 10 dn: olcDatabase=3D{1}mdb,cn=3Dconfig changetype: modify add: olcLimits olcLimits: dn.exact=3D"cn=3Dreplicator,ou=3DLDAPRoles,dc=3Dexample,dc=3Dc= om" time.soft=3Dunlimited time.h ard=3Dunlimited size.soft=3Dunlimited size.hard=3Dunlimited - dn: olcDatabase=3D{1}mdb,cn=3Dconfig changetype: modify replace: olcAccess olcAccess: {0}to dn.subtree=3D"dc=3Dexample,dc=3Dcom" by self write by = dn.exact=3D"cn=3D replicator,ou=3DLDAPRoles,dc=3Dexample,dc=3Dcom" read by anonymous auth = by * read - o Step 5 : On the consumer, we inject the following entry : dn: olcDatabase=3D{1}mdb,cn=3Dconfig changetype: modify add: olcSyncrepl olcSyncrepl: rid=3D1 provider=3Dldap://10.61.155.18 bindmethod=3Dsimple b= i nddn=3D"cn=3Dreplicator,ou=3DLDAPRoles,dc=3Dexample,dc=3Dcom" credential= s=3Dsecret type=3DrefreshAndPersis t searchbase=3D"dc=3Dexample,dc=3Dcom" filter=3D"(objectclass=3D*)" scop= e=3Dsub schemacheck ing=3Don retry=3D"5 10 60 +" sizeLimit=3Dunlimited timelimit=3Dunlimited - At this point, one would expect the replication to kick on, and having th= e entries flowing from the producer to the consumer, but nothing happens. Ignoring the first step (ServerID setting), and applying the other steps,= just work fine. It seems that setting the ServerID blocks everything (FT= R, it does not help either to setup the consumer's ServerID). This is problematic in a scenario where we would try to make 2 servers be= ing replicated in a MMR typology with MirrorMode set, as the ServerID wi= l be mandatory. Here is the provider configuratio (this is in slapd.conf format for conve= nience, it is being converted to slapd.d before the server is started) : #########################################################################= ######## ## Provider configuration #########################################################################= ######### # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # # Schema files. Note that not all of these schemas co-exist peacefully. # Use only those you need and leave the rest commented out. include "/opt/symas/etc/openldap/schema/core.schema" include "/opt/symas/etc/openldap/schema/cosine.schema" include "/opt/symas/etc/openldap/schema/inetorgperson.schema" include "/opt/symas/etc/openldap/schema/misc.schema" # TLSCipherSuite <cipher-suite-spec> # Permits configuring what ciphers will be accepted and the # preference order. <cipher-suite-spec> should be a cipher # specification for the TLS library in use (OpenSSL, GnuTLS, or # Mozilla NSS). TLSCipherSuite HIGH:MEDIUM # Files in which to store the process id and startup arguments. # These files are needed by the init scripts, so only change # these if you are prepared to edit those scripts as well. pidfile "/var/symas/run/slapd.pid" argsfile "/var/symas/run/slapd.args" # Choose the directory for loadable modules. modulepath "/opt/symas/lib64/openldap" # Uncomment the moduleloads as needed to enable additional # functionalityi when configured. NOTE: We package many=20 # more modules options than those found below.=20 moduleload back_mdb.la moduleload back_monitor.la # Sample access control policy: # Allow read access of root DSE # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: access to dn=3D"" by * read access to * by self write by users read by anonymous auth #----------------------------------------------------------------------- # LOGGING loglevel stats sync ####################################################################### # config database ####################################################################### database config rootdn "cn=3DDirectory Manager,cn=3Dconfig" rootpw secret access to * by * none ####################################################################### # Sample LMDB database definitions ####################################################################### database mdb suffix "dc=3Dexample,dc=3Dcom" rootdn "cn=3DDirectory Manager,dc=3Dexample,dc=3Dcom" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details describing # the creation of encrypted passwords. rootpw secret # Indices to maintain # index default sets the basic type of indexing to perform if there isn't= any indexing specified for a given attribute index default eq index objectClass index cn # The database directory MUST exist prior to running slapd AND=20 # should only be accessible by the slapd/tools. Mode 700 recommended. # One directory will be needed for each backend, so you should # create a subdirectory beneath /var/symas/openldap-data for each # new backend. This is also where the DB_CONFIG file needs to be # placed. directory "/var/symas/openldap-data/example" # Here we specify the maximum on-disk size of the database. It is=20 # Recommended to set this near the expected free-space availability # for the machine. This paramiter is not pre-allocated and simply=20 # represents the upward limit to which the database will be allowed # to grow. Note: Specified in *bytes*. Here, we set it to 1gb. maxsize 10485760 ####################################################################### # Monitor database ####################################################################### database monitor access to dn.subtree=3D"cn=3Dmonitor" by * read And here is the consumer configuration : #########################################################################= ######## ## Consumer configuration #########################################################################= ######### # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # # Schema files. Note that not all of these schemas co-exist peacefully. # Use only those you need and leave the rest commented out. include "/opt/symas/etc/openldap/schema/core.schema" include "/opt/symas/etc/openldap/schema/cosine.schema" include "/opt/symas/etc/openldap/schema/inetorgperson.schema" include "/opt/symas/etc/openldap/schema/misc.schema" # # TLSCipherSuite <cipher-suite-spec> # Permits configuring what ciphers will be accepted and the # preference order. <cipher-suite-spec> should be a cipher # specification for the TLS library in use (OpenSSL, GnuTLS, or # Mozilla NSS). TLSCipherSuite HIGH:MEDIUM # Files in which to store the process id and startup arguments. # These files are needed by the init scripts, so only change # these if you are prepared to edit those scripts as well. pidfile "/var/symas/run/slapd.pid" argsfile "/var/symas/run/slapd.args" # Choose the directory for loadable modules. modulepath "/opt/symas/lib64/openldap" # Uncomment the moduleloads as needed to enable additional # functionalityi when configured. NOTE: We package many # more modules options than those found below. moduleload back_mdb.la moduleload back_monitor.la # Sample access control policy: # Allow read access of root DSE # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: access to dn=3D"" by * read access to * by self write by users read by anonymous auth #----------------------------------------------------------------------- # LOGGING loglevel stats sync ####################################################################### # config database ####################################################################### database config rootdn "cn=3DDirectory Manager,cn=3Dconfig" rootpw secret access to * by * none ####################################################################### # Sample LMDB database definitions ####################################################################### database mdb suffix "dc=3Dexample,dc=3Dcom" rootdn "cn=3DDirectory Manager,dc=3Dexample,dc=3Dcom" # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details describing # the creation of encrypted passwords. rootpw secret # Indices to maintain # index default sets the basic type of indexing to perform if there isn't= any indexing specified for a given attribute index default eq index objectClass index cn # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd/tools. Mode 700 recommended. # One directory will be needed for each backend, so you should # create a subdirectory beneath /var/symas/openldap-data for each # new backend. This is also where the DB_CONFIG file needs to be # placed. directory "/var/symas/openldap-data/example" # Here we specify the maximum on-disk size of the database. It is # Recommended to set this near the expected free-space availability # for the machine. This paramiter is not pre-allocated and simply # represents the upward limit to which the database will be allowed # to grow. Note: Specified in *bytes*. Here, we set it to 1gb. maxsize 10485760 ####################################################################### # Monitor database ####################################################################### database monitor access to dn.subtree=3D"cn=3Dmonitor" by * read Le 21/10/16 =C3=A0 23:45, openldap-its(a)OpenLDAP.org a =C3=A9crit : > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#8521. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#8521) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=3D(ITS#8521) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=3D8521 > > Please remember to retain your issue tracking number (ITS#8521) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. > --=20 Emmanuel Lecharny Symas.com directory.apache.org

1 0

(ITS#8521) Cannot have replication working after setting up the replication config in slapd.d
by elecharny＠apache.org 21 Oct '16

21 Oct '16

Full_Name: Emmanuel L.charny Version: 2.4.45 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (90.92.161.247) Replication won't start if we set it up on running servers configured with slapd.d. The scenario is the following : o We have 2 servers, one will become the provider, the other the consumer o They are initially empty%2ususing MDB (see the attached configurations, converted from slapd.conf to slapd.d) o We start the 2 servers o Step 1 : On the provider, we inject the following entry : dn: cn=config changetype: modify add: olcServerId olcServerId: 1 -

1 0

Re: (ITS#8504) LDMB: Return EPIPE from mdb_env_copyfd2 instead abort on SIGPIPE
by lmb＠cloudflare.com 20 Oct '16

20 Oct '16

--001a114741aec1bad3053f481b06 Content-Type: text/plain; charset=UTF-8 On 20 October 2016 at 09:35, Hallvard Breien Furuseth < h.b.furuseth(a)usit.uio.no> wrote: > > Hmm. Nevermind, it's probably better to leave that to the user. > It gets ugly for a library to meddle with the current thread's > signals. I.e. it must check if SIGPIPE was already pending > before the call, and don't collect it on EPIPE in that case. > Yeah, I agree. Your changes LGTM. Interesting point re atomic int write, I wasn't entirely sure how mc_error could be accesses, so I decided to play it safe. -- Lorenz Bauer | Systems Engineer 25 Lavington St., London SE1 0NZ www.cloudflare.com --001a114741aec1bad3053f481b06 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">= On 20 October 2016 at 09:35, Hallvard Breien Furuseth <span dir=3D"ltr">&lt= ;<a href=3D"mailto:h.b.furuseth@usit.uio.no" target=3D"_blank">h.b.furuseth= @usit.uio.no</a>></span> wrote:<blockquote class=3D"gmail_quote" style= =3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Hmm.=C2=A0 Nevermind, it's probably better to leave that to the user.<b= r> It gets ugly for a library to meddle with the current thread's<br> signals.=C2=A0 I.e. it must check if SIGPIPE was already pending<br> before the call, and don't collect it on EPIPE in that case.<span class= =3D"HOEnZb"><font color=3D"#888888"><br></font></span></blockquote></div><d= iv><br></div><div>Yeah, I agree. Your changes LGTM.</div><div><br></div><di= v>Interesting point re atomic int write, I wasn't entirely sure how mc_= error could be accesses, so I decided to play it safe.</div><div><br></div>= -- <br><div class=3D"gmail_signature" data-smartmail=3D"gmail_signature">Lo= renz Bauer =C2=A0| =C2=A0Systems Engineer<br>25 Lavington St., London SE1 0= NZ<br><br><a href=3D"http://www.cloudflare.com" target=3D"_blank">www.cloud= flare.com</a></div> </div></div> --001a114741aec1bad3053f481b06--

1 0

Re: (ITS#8504) LDMB: Return EPIPE from mdb_env_copyfd2 instead abort on SIGPIPE
by h.b.furuseth＠usit.uio.no 20 Oct '16

20 Oct '16

I wrote: > And.. duh, we've forgotten mdb_copy without MDB_CP_COMPACT. > I'll do it later if nobody beats me to it. Hmm. Nevermind, it's probably better to leave that to the user. It gets ugly for a library to meddle with the current thread's signals. I.e. it must check if SIGPIPE was already pending before the call, and don't collect it on EPIPE in that case. -- Hallvard

1 0

Re: (ITS#8504) LDMB: Return EPIPE from mdb_env_copyfd2 instead abort on SIGPIPE
by h.b.furuseth＠usit.uio.no 20 Oct '16

20 Oct '16

On 27/09/16 22:14, lmb(a)cloudflare.com wrote: >On 26 September 2016 at 20:48, Hallvard Breien Furuseth <h.b.furuseth(a)usit.uio.no> wrote: >> I think we can skip sigwait() too since the thread will exit when done. >> (...) > > That's what my initial patch did. At least on OS X this leads to the > process receiving SIGPIPE and dying. OK. I've put a fixed version including that comment in branch "mdb/its8504-sigpipe" @ <git://git.uio.no/u/hbf/openldap.git>. We can squash the commits later: Never clear mc_error, we'd lose failure in the other thread. It's not mutex-protected, which is OK: If both threads set it, we'll get one of the errors. LMDB already expects atomic int. And.. duh, we've forgotten mdb_copy without MDB_CP_COMPACT. I'll do it later if nobody beats me to it. Test: Comment out SIGPIPE in mdb_copy.c, then run bash$ (sleep 1; ./mdb_copy testdb; echo exit $? >&2) | true exit 141 Exit values >= 128 are aborts from signals.

1 0

Re: (ITS#8520) Maximum number os entries
by quanah＠symas.com 18 Oct '16

18 Oct '16

--On Tuesday, October 18, 2016 6:41 PM +0000 teresarosado.net(a)gmail.com wrote: > Full_Name: Teresa Rosado > Version: 2015-11-15 > OS: Win Xp > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.65.44.71) Hello, The ITS system is for reporting software bugs. Questions about the software and how it functions should be directed to the openldap technical list. Please see: <http://www.openldap.org/lists/mm/listinfo/openldap-technical> This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8520) Maximum number os entries
by teresarosado.net＠gmail.com 18 Oct '16

18 Oct '16

Full_Name: Teresa Rosado Version: 2015-11-15 OS: Win Xp URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.65.44.71) Dear Sirs, What is the maximum number of entries your OpenLDAP server can have on DB? What is the maximum number of entries your OpenLDAP server can return on ldapsearch command? BR Teresa

1 0

Re: (ITS#8406) LMDB: Assertion 'mc->mc_flags & C_INITIALIZED' with MDB_NEXT after mdb_cursor_del
by h.b.furuseth＠usit.uio.no 17 Oct '16

17 Oct '16

[Copied from IRC chat] The fix is wrong - this commit broke cursor tracking: 37081325f7356587c5e6 "ITS#8406 fix xcursors after cursor_del" Demo: mtest_rand -v -f700 -i3 -p0x1000 -r1276664687.3 It sets C_DEL on the wrong xcursor, one which is at a different key than the deleted key. Like this: put key1, data1 put[cursor] key2, data2 del key1, data1 Now [cursor].mx_cursor has C_DEL. This also breaks - probably the same bug: mtest_rand -v -c7 -f326 -p0x800 -r2712746413 -- Hallvard

1 0

Re: (ITS#8519) Mahesh
by quanah＠symas.com 17 Oct '16

17 Oct '16

--On Monday, October 17, 2016 2:17 PM +0000 maheshwar.reddy(a)secure-24.com wrote: > Full_Name: Maheshwar Reddy > Version: 2.4.4 > OS: CentOS 6.5 > URL: ftp://ftp.openldap.org/incoming/Mahesh The ITS system is for reporting bugs. Usage/help requests should be directed to the openldap-techincal(a)openldap.org mailing list. Please see <http://www.openldap.org/lists/> for more information. This ITS will be closed. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8519) Mahesh
by maheshwar.reddy＠secure-24.com 17 Oct '16

17 Oct '16

Full_Name: Maheshwar Reddy Version: 2.4.4 OS: CentOS 6.5 URL: ftp://ftp.openldap.org/incoming/Mahesh Submission from: (NULL) (175.101.6.130) Dear Openldap Support, First of all thank for the open community, We have been using openldap since last 5 years. Right now we are trying to decommission older version of openldap and trying to build newversion. Prior to that we are testing the openldap functionality and we observed some issue while configuring. We have a Linux team, and they all are need ldap write access. I've created a group and provided a ldap write access to that group. But the people who belongs to that group they were unable to write the ldiff files. Attached information, kindly take look into it. you help would highly appreciated. # ldap_writers, access_control, redhot, redhot.com dn: cn=ldap_writers,ou=access_control,o=redhot,dc=redhot,dc=com cn: ldap_writers objectClass: organizationalRole description: Grants full LDAP write access roleOccupant: uid=maheshwar.reddy,ou=users,o=redhot,dc=redhot,dc=com [root@sal-lnx01 ~]# cat grantaccess.ldif dn: olcDatabase={2}bdb,cn=nonfig changetype: modify add: olcAccess olcAccess: to * by group/organizationalRole/roleOccupant="cn=ldap_writers,ou=access_control,o=redhot,dc=redhot,dc=com" write [root@sal-lnx01 ~]# ldapadd -Y EXTERNAL -H ldapi:/// -f grantaccess.ldif SASL/EXTERNAL authentication started SASL username: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth SASL SSF: 0 modifying entry "olcDatabase={2}bdb,cn=config" [root@sal-lnx01 ~]# slapcat -n0 | tail -n10 olcAccess: {1}to dn.base="" by * read olcAccess: {2}to * by dn="cn=Manager,dc=redhot,dc=com" write by * read olcAccess: {3}to * by group/organizationalRole/roleOccupant="cn=ldap_writers ,ou=access_control,o=redhot,dc=redhot,dc=com" write olcSuffix: dc=redhot,dc=com olcRootDN: cn=Manager,dc=redhot,dc=com entryCSN: 20161017124350.966527Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth modifyTimestamp: 20161017124350Z [root@sal-lnx01 ~]# ldapadd -x -W -D uid=maheshwar.reddy,ou=users,o=redhot,dc=redhot,dc=com -f test.ldif Enter LDAP Password: adding new entry "uid=srikanth.reddy,ou=users,o=redhot,dc=redhot,dc=com" ldap_add: Insufficient access (50) additional info: no write access to parent [root@sal-lnx01 ~]# cat test.ldif # srikanth.reddy, users, redhot.com dn: uid=srikanth.reddy,ou=users,o=redhot,dc=redhot,dc=com cn: Maheshwar objectClass: organizationalPerson objectClass: person objectClass: inetOrgPerson objectClass: posixAccount objectClass: top givenName: Maheshwar Reddy homeDirectory:2F2Fhome/srikanth.reddy loginShell: /bin/bash mail: srikanth.reddy(a)redhot.com sn: Reddy uid: srikanth.reddy uidNumber: 10001 gidNumber: 1000 userPassword: {SSHA}UQU2j5vBuGqjfTE3x+UlA2Ez1ENHAZ/Q

1 0

Re: (ITS#8505) LMDB vs. fork()
by lmb＠cloudflare.com 13 Oct '16

13 Oct '16

--001a1143758a2a3d2c053ec0c5a5 Content-Type: text/plain; charset=UTF-8 I obviously agree that fixing the problems you mention is worthwhile, it just so far doesn't really get me what I need: safe fork() + exec(). Well, or mdb_env_open() could take an > MDB_CLOEXEC flag which says to set FD_CLOEXEC on that FD too. > If I could get that I'd move off my soapbox immediately. I can contribute a patch if that sounds reasonable? -- Lorenz Bauer | Systems Engineer 25 Lavington St., London SE1 0NZ www.cloudflare.com --001a1143758a2a3d2c053ec0c5a5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><div>I obviously agree that fixing the problems you mentio= n is worthwhile, it just so far doesn't really get me what I need: safe= fork() + exec().<br></div><br><div class=3D"gmail_extra"><div class=3D"gma= il_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8= ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Well, or mdb_en= v_open() could take an<br> MDB_CLOEXEC flag which says to set FD_CLOEXEC on that FD too.<br></blockquo= te><div><br></div><div>If I could get that I'd move off my soapbox imme= diately. I can contribute a patch if that sounds reasonable?</div></div><di= v><br></div>-- <br><div class=3D"gmail_signature">Lorenz Bauer =C2=A0| =C2= =A0Systems Engineer<br>25 Lavington St., London SE1 0NZ<br><br><a href=3D"h= ttp://www.cloudflare.com" target=3D"_blank">www.cloudflare.com</a></div> </div></div> --001a1143758a2a3d2c053ec0c5a5--

1 0

Re: (ITS#8507) adding the syncprov overlay does not load the associated schema elements
by hyc＠symas.com 12 Oct '16

12 Oct '16

ryan(a)nardis.ca wrote: > On Thu, Sep 29, 2016 at 06:03:38PM +0000, elecharny(a)apache.org wrote: >> $ grep -ri "olcSpNoPresent" slapd.d >> $ ... You are never supposed to access the files within the slapd.d directory. > Actually slapd replaces the entire cn=schema entry at runtime. As far as > I can tell, the the cn=schema.ldif file on disk is never used. So it > would certainly be dangerous to rely on its contents for anything. Correct. -- -- 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#8507) adding the syncprov overlay does not load the associated schema elements
by elecharny＠gmail.com 12 Oct '16

12 Oct '16

Le 12/10/16 à 02:40, Ryan Tandy a écrit : > On Thu, Sep 29, 2016 at 06:03:38PM +0000, elecharny(a)apache.org wrote: >> $ grep -ri "olcSpNoPresent" slapd.d >> $ ... >> >> You can stop and restart the server, the attribute is still not present. > > It's system schema and not user schema, so I kind of expect this. The > behaviour is the same when cn=config is initialized using slapadd -n0. > > 'ldapsearch -s base cn=schema,cn=config' does show these attributes. > >> Going back to the slapd.conf file, add the module : >> >> ... >> # Uncomment the mululeloads as needed to enable additional >> # functionalityi when configured. NOTE: We package many >> # more modules options than those found below. >> moduleload back_mdb.la >> moduleload back_monitor.la >> moduleload syncprov.la # Added module >> ... >> >> and regenerate the slapd.d content : >> >> $ /etc/init.d/solserver stop >> $ rm -rf /opt/symas/etc/openldap/slapd.d/* >> $ /opt/symas/bin/slaptest -f /opt/symas/etc/openldap/slapd.conf -F >> /opt/symas/etc/openldap/slapd.d >> $ grep -ri "olcSpNoPresent" /opt/symas/etc/openldap/slapd.d >> slapd.d/cn=config/cn=schema.ldif:olcAttributeTypes: ( OLcfgOvAt:1.3 NAME >> 'olcSpNoPresent' DESC 'Omit Present >> slapd.d/cn=config/cn=schema.ldif: $ olcSpSessionlog $ olcSpNoPresent $ >> olcSpReloadHint ) ) >> $... >> >> This is problematic... > > If there is a bug, I'd say it's the fact that the converter does write > out these attributes. > > Actually slapd replaces the entire cn=schema entry at runtime. As far > as I can tell, the the cn=schema.ldif file on disk is never used. So > it would certainly be dangerous to rely on its contents for anything. I must say that I can't reproduce this behavious with the latest release, so I guess it was fixed since the test I did.

1 0

Re: (ITS#7384) Assert Crash in ppolicy_ctrls_cleanup
by ryan＠nardis.ca 11 Oct '16

11 Oct '16

Just noting that one way to reproduce this assert reliably is to bind to an existing entry, through the relay, with an incorrect password. The important part of the config is: database mdb suffix dc=example,dc=com [...] overlay ppolicy database relay suffix o=example overlay rwm rwm-suffixmassage o=example dc=example,dc=com overlay ppolicy Then, binding through the relay: $ ldapwhoami -x -D uid=test,o=example -w zzz -e ppolicy slapd: ppolicy.c:912: ctrls_cleanup: Assertion `rs->sr_ctrls != ((void *)0)' failed. Same as when someone accidentally attaches two ppolicy instances to a single database. Not totally sure, but I suspect it's wrong here too: I don't see what the ppolicy attached to the relay is supposed to add in this case. I guess in theory they could have different configuration? wrt. e.g. ppolicy_use_lockout, or even pwdLockout/pwdMustChange via a different ppolicy_default... Wondering if it would make sense for add_passcontrol to look for a ppolicy control already existing on the op, and try to fail gracefully if so, instead of hitting this on the way out. Binding to the same entry with the correct password... $ ldapwhoami -x -D uid=test,o=example -w test -e ppolicy currently hits the same segfault reported in ITS#7966.

1 0

Re: (ITS#8507) adding the syncprov overlay does not load the associated schema elements
by ryan＠nardis.ca 11 Oct '16

11 Oct '16

On Thu, Sep 29, 2016 at 06:03:38PM +0000, elecharny(a)apache.org wrote: >$ grep -ri "olcSpNoPresent" slapd.d >$ ... > >You can stop and restart the server, the attribute is still not present. It's system schema and not user schema, so I kind of expect this. The behaviour is the same when cn=config is initialized using slapadd -n0. 'ldapsearch -s base cn=schema,cn=config' does show these attributes. >Going back to the slapd.conf file, add the module : > >... ># Uncomment the mululeloads as needed to enable additional ># functionalityi when configured. NOTE: We package many ># more modules options than those found below. >moduleload back_mdb.la >moduleload back_monitor.la >moduleload syncprov.la # Added module >... > >and regenerate the slapd.d content : > >$ /etc/init.d/solserver stop >$ rm -rf /opt/symas/etc/openldap/slapd.d/* >$ /opt/symas/bin/slaptest -f /opt/symas/etc/openldap/slapd.conf -F >/opt/symas/etc/openldap/slapd.d >$ grep -ri "olcSpNoPresent" /opt/symas/etc/openldap/slapd.d >slapd.d/cn=config/cn=schema.ldif:olcAttributeTypes: ( OLcfgOvAt:1.3 NAME >'olcSpNoPresent' DESC 'Omit Present >slapd.d/cn=config/cn=schema.ldif: $ olcSpSessionlog $ olcSpNoPresent $ >olcSpReloadHint ) ) >$... > >This is problematic... If there is a bug, I'd say it's the fact that the converter does write out these attributes. Actually slapd replaces the entire cn=schema entry at runtime. As far as I can tell, the the cn=schema.ldif file on disk is never used. So it would certainly be dangerous to rely on its contents for anything.

1 0

Re: (ITS#8510) OpenLDAP Crash when using ppolicy
by ryan＠nardis.ca 11 Oct '16

11 Oct '16

Hi, On Mon, Oct 03, 2016 at 08:00:55AM +0000, poil(a)quake.fr wrote: >I have an openldap with a master-master replication >* Config directory is a HDB database >* Main directory (people/group/policy) is a MDB database > >When using ># ldapwhoami -x -H ldap://localhost -D uid=poil,ou=opople,dc=my,dc=test -W -e >ppolicy >LDAP crash > >When using ># ldapwhoami -x -H ldap://localhost -D uid=poil,ou=people,dc=my,dc=test -W >It's working There isn't enough information here to reproduce the issue. Please provide complete steps to reproduce starting from a clean installation, including the entire configuration and some example data that demonstrates the problem.

1 0

Re: (ITS#8516) TAG decoding incorrect when longer than 1 byte
by elecharny＠gmail.com 11 Oct '16

11 Oct '16

Le 11/10/16 à 19:56, Hallvard Breien Furuseth a écrit : > On 11. okt. 2016 18:10, elecharny(a)apache.org wrote: >> IMO, the code that deal with tags in the lber decode.c >> ber_tag_and_rest() method >> is incorrectly decoding tags that are longer than 1 byte. (...) > > It's far too late to change the ASN.1 <-> integer mapping. liblber is > widely used outside OpenLDAP, we don't know if we'd break something. I think I overlooked the origial code. See later... > > As lber.h explains: > * ber_tag_t represents the identifier octets at the beginning of BER > * elements. OpenLDAP treats them as mere big-endian unsigned integers. Indeed. That means the method just grabs bytes without taking care of the 'continuation' bits (ie the 7th bit if there are more bytes after), and returns a long. > > I wish it had at least used little-endian so we could check the class > and P/C bits with a simple '&' operation. Oh well. Well, the way this function works make it hard to do so, I agree. OTOH, it means this ITS can be closed, because it's based on a wrong understanding on what this method does. It's not bugy, it's just doing somethig different than what I was expecting. Thanks !

1 0

Re: (ITS#8516) TAG decoding incorrect when longer than 1 byte
by h.b.furuseth＠usit.uio.no 11 Oct '16

11 Oct '16

On 11. okt. 2016 18:10, elecharny(a)apache.org wrote: > IMO, the code that deal with tags in the lber decode.c ber_tag_and_rest() method > is incorrectly decoding tags that are longer than 1 byte. (...) It's far too late to change the ASN.1 <-> integer mapping. liblber is widely used outside OpenLDAP, we don't know if we'd break something. As lber.h explains: * ber_tag_t represents the identifier octets at the beginning of BER * elements. OpenLDAP treats them as mere big-endian unsigned integers. I wish it had at least used little-endian so we could check the class and P/C bits with a simple '&' operation. Oh well. -- Hallvard

1 0

(ITS#8516) TAG decoding incorrect when longer than 1 byte
by elecharny＠apache.org 11 Oct '16

11 Oct '16

Full_Name: Emmanuel Lecjarny Version: 2.4.44 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (90.92.161.247) IMO, the code that deal with tags in the lber decode.c ber_tag_and_rest() method is incorrectly decoding tags that are longer than 1 byte. Not that it is a huge problem for OpenLDAP, because we always use 1 byte long tags, but from the ASN.1 BER decoding POV, that wilbrbreak when having a 2 bytes long tag : 116 do { 117 if ( rest <= 0 ) { 118 break; 119 } 120 tag <<= 8; 121 tag |= *ptr++ & 0xffU; 122 rest--; 123 124 if ( ! (tag & LBER_MORE_TAG_MASK) ) { 125 goto done; 126 } 127 } while ( tag <= (ber_tag_t)-1 / 256 ); should read 114 tag = (ber_tag_t) 0x00U; 115 116 do { 117 if ( rest <= 0 ) { 118 break; 119 } 120 tag <<= 7; 121 tag |= *ptr++ & 0x7fU; 122 rest--; 123 124 if ( ! (tag & LBER_MORE_TAG_MASK) ) { 125 goto done; 126 } 127 } while ( tag <= (ber_tag_t)-1 / 256 ); The reason being that BER encoding for Tags when longer than 1 byte looks like : [class|P/C|11111] - [1|uuu uuuu] - [1|uuu uuuu] - [1|uuu uuuu] - ... - [0|uuu uuuu] byte 1 byte 2 byte 3 byte 4 byte N and the 'uuu uuuu' parts are only 7 bits long.

1 0

Re: (ITS#8515) => mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize limit reached (-30792)
by michael＠stroeder.com 10 Oct '16

10 Oct '16

sebastiaan.van.zanten(a)ing.nl wrote: > Version: 2.4.4 ^^^^^ Sure? > However we installed it as an MDB database > and now we receive the following error: > > => mdb_idl_insert_keys: c_put id failed: MDB_MAP_FULL: Environment mapsize > limit reached (-30792) > > Apparently the settings were default and it exceeded the size of 10mb. We have > plenty of diskspace on the machine. However we are unsure how to update this. > Can you advise us how we do this? In general usage questions should not be added as ticket. Please use the openldap-technical mailing list instead. In your case you can increase the DB size with the slapd.conf directive "maxsize" (or the equivalent attribute when using cn=config) and restart slapd. Ciao, Michael.

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs