openldap-bugs July 2020

openldap-bugs@openldap.org

2 participants
123 discussions

[Issue 9295] New: ppolicy and replication: pwdLockedTime replication fails to replicate
by openldap-its＠openldap.org 03 Jun '21

03 Jun '21

https://bugs.openldap.org/show_bug.cgi?id=9295 Issue ID: 9295 Summary: ppolicy and replication: pwdLockedTime replication fails to replicate Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- If you have the following setup, a replica will hit an error during replication. a) ppolicy is configured on provider(s) and replicas. Replica has schemachecking=on in its syncrepl configuration b) account gets locked on the replica, so pwdAccountLockedTime is set on the replica but not on the provider(s) c) admin does a MOD/ADD op against a provider for the user entry to add a value to pwdAccountLockedTime dn: ... changetype: modify add: pwdAccountLockedTime pwdAccountLockedTime: ... d) provider accepts this modification. e) replica rejects this modification because the resulting change means that there would be two pwdAccountLockedTime values on the account in question Generally I believe that in this scenario, the MOD/ADD on the provider should be treated as a replace OP instead of an ADD op -- You are receiving this mail because: You are on the CC list for the issue.

1 18

[Issue 9288] New: slapd service stops suddenly but generates crash file
by openldap-its＠openldap.org 31 Mar '21

31 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9288 Issue ID: 9288 Summary: slapd service stops suddenly but generates crash file Product: OpenLDAP Version: 2.4.49 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: tekkitan(a)gmail.com Target Milestone: --- System: t3.small AWS instance 2VCPU 2GB RAM OS: Ubuntu 20.04 (was happening on 16.04 as well) Package Version: 2.4.49+dfsg-2ubuntu1.2 We've been having this weird problem with slapd between Ubuntu 16.04 and Ubuntu 20.04 where slapd will suddenly stop according to syslog but will also generate a crash file within apport. We thought it was due to some weird stuff we were doing in the 16.04 version (2.4.42+dfsg-2ubuntu3.8), but we deployed a new LDAP proxy in 20.04 (2.4.49+dfsg-2ubuntu1.2) which appears to have the same issue so I am reporting it and hoping for guidance as we use this proxy for our corporate VPN. Below is the backtrace which was the same from both proxy systems, but this one is from the 20.04 version as that is our current system in use: root@useldap02:~/_usr_sbin_slapd.0.crash# apport-retrace --stdout /var/crash/_usr_sbin_slapd.0.crash --- stack trace --- #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 set = {__val = {0, 140488162916432, 140488307736576, 140487911640016, 140487911640117, 140487911640016, 140487911640016, 140487911640147, 140487911640316, 140487911640016, 140487911640316, 0, 0, 0, 0, 0}} pid = <optimized out> tid = <optimized out> ret = <optimized out> #1 0x00007fc5f3043859 in __GI_abort () at abort.c:79 save_stage = 1 act = {__sigaction_handler = {sa_handler = 0x2, sa_sigaction = 0x2}, sa_mask = {__val = {131, 4, 99, 0, 0, 140488164070405, 0, 21474836480, 140488121483504, 0, 140488164102160, 0, 6703301646461552640, 140488164070405, 140488165695488, 140488164087176}}, sa_flags = -235332728, sa_restorer = 0xbf} sigs = {__val = {32, 0 <repeats 15 times>}} #2 0x00007fc5f3043729 in __assert_fail_base (fmt=0x7fc5f31d9588 "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", assertion=0x7fc5f1f91953 "!LDAP_BACK_CONN_TAINTED( lc )", file=0x7fc5f1f91b88 "../../../../../servers/slapd/back-ldap/bind.c", line=191, function=<optimized out>) at assert.c:92 str = 0x7fc5c410a280 "@Q\021\344\305\177" total = 4096 #3 0x00007fc5f3054f36 in __GI___assert_fail (assertion=0x7fc5f1f91953 "!LDAP_BACK_CONN_TAINTED( lc )", file=0x7fc5f1f91b88 "../../../../../servers/slapd/back-ldap/bind.c", line=191, function=0x7fc5f1f921a0 "ldap_back_conn_delete") at assert.c:101 No locals. #4 0x00007fc5f1f807c7 in ldap_back_conn_delete () from /usr/lib/ldap/back_ldap-2.4.so.2 No symbol table info available. #5 0x00007fc5f1f814a4 in ?? () from /usr/lib/ldap/back_ldap-2.4.so.2 No symbol table info available. #6 0x00007fc5f1f815ad in ldap_back_release_conn_lock () from /usr/lib/ldap/back_ldap-2.4.so.2 No symbol table info available. #7 0x00007fc5f1f833bc in ldap_back_retry () from /usr/lib/ldap/back_ldap-2.4.so.2 No symbol table info available. #8 0x00007fc5f1f7ec0b in ldap_back_search () from /usr/lib/ldap/back_ldap-2.4.so.2 No symbol table info available. #9 0x000055b87105cc88 in overlay_op_walk () No symbol table info available. #10 0x000055b87105cdb7 in ?? () No symbol table info available. #11 0x000055b870fef80d in fe_op_search () No symbol table info available. #12 0x000055b870fef034 in do_search () No symbol table info available. #13 0x000055b870fec6ed in ?? () No symbol table info available. #14 0x000055b870fed22c in ?? () No symbol table info available. #15 0x00007fc5f32e7a03 in ?? () from /lib/x86_64-linux-gnu/libldap_r-2.4.so.2 No symbol table info available. #16 0x00007fc5f3219609 in start_thread (arg=<optimized out>) at pthread_create.c:477 ret = <optimized out> pd = <optimized out> unwind_buf = {cancel_jmp_buf = {{jmp_buf = {140488121493248, -8220430158823943899, 140488129874654, 140488129874655, 140488129874784, 140488121490880, 8241811018110734629, 8241811687867814181}, mask_was_saved = 0}}, priv = {pad = {0x0, 0x0, 0x0, 0x0}, data = {prev = 0x0, cleanup = 0x0, canceltype = 0}}} not_first_call = 0 #17 0x00007fc5f3140103 in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:95 No locals. This is usually what we see within syslog when slapd stops: Jul 11 00:49:32 useldap02 slapd[5257]: conn=1035 op=239 SRCH base="ou=people,dc=company,dc=com" scope=2 deref=0 filter="(&(|(objectClass=person)(objectClass=organizationalPerson)(objectClass=inetOrgPerson)(?objectClass=fw1Person))(uid=exampleusername))" Jul 11 00:49:32 useldap02 slapd[5257]: conn=1035 op=239 SRCH attr=cn uid sn mail proxyAddresses userPrincipalName fullName displayName description objectclass fw1hour-range-from fw1hour-range-to fw1expiration-date fw1day fw1allowed-dst fw1allowed-src fw1auth-method userAccountControl fw1userPwdPolicy mobile fw1BadPwdCount fw1lastLoginFailure fw1pwdLastMod fw1auth-server fw1auth-server fw1groupTemplate fw1sr-auth-track fw1enc-methods fw1ISAKMP-EncMethod fw1ISAKMP-AuthMethods fw1ISAKMP-HashMethods fw1ISAKMP-Transform fw1ISAKMP-DataIntegrityMethod fw1ISAKMP-SharedSecret fw1ISAKMP-DataEncMethod givenName surname Jul 11 00:49:32 useldap02 slapd[5257]: conn=1035 op=240 SRCH base="ou=groups,dc=company,dc=com" scope=2 deref=0 filter="(&(|(objectClass=person)(objectClass=organizationalPerson)(objectClass=inetOrgPerson)(?objectClass=fw1Person))(uid=exampleusername))" Jul 11 00:49:32 useldap02 slapd[5257]: conn=1035 op=240 SRCH attr=cn uid sn mail proxyAddresses userPrincipalName fullName displayName description objectclass fw1hour-range-from fw1hour-range-to fw1expiration-date fw1day fw1allowed-dst fw1allowed-src fw1auth-method userAccountControl fw1userPwdPolicy mobile fw1BadPwdCount fw1lastLoginFailure fw1pwdLastMod fw1auth-server fw1auth-server fw1groupTemplate fw1sr-auth-track fw1enc-methods fw1ISAKMP-EncMethod fw1ISAKMP-AuthMethods fw1ISAKMP-HashMethods fw1ISAKMP-Transform fw1ISAKMP-DataIntegrityMethod fw1ISAKMP-SharedSecret fw1ISAKMP-DataEncMethod givenName surname Jul 11 00:49:34 useldap02 slapd[28099]: * Stopping OpenLDAP slapd Jul 11 00:49:34 useldap02 slapd[28099]: ...done. Jul 11 00:49:34 useldap02 systemd[1]: slapd.service: Succeeded. Note that a lot of these attributes being searched for (all the fw1* attributes) do not exist within our LDAP. Not sure if that would be the cause. Thank you for any help that can be provided. -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 9270] New: Admin guide: Add detailed information on indexing
by openldap-its＠openldap.org 31 Mar '21

31 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9270 Issue ID: 9270 Summary: Admin guide: Add detailed information on indexing Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- It would be useful to outline what the different types of indexing options do, and when they are useful, in the admin guide. For example: presence indexing is only useful if looking to find entries with a given attribute, when generally < 50% of the entries in the DB have an instance of that attribute. equality indexing would not be particularly useful on an attribute that exists in most every entry, and the attribute always has the same value etc. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Bug 9260] New: slapd-ldap(5) man page missing conn-pool-max option
by openldap-its＠openldap.org 31 Mar '21

31 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9260 Bug ID: 9260 Summary: slapd-ldap(5) man page missing conn-pool-max option Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The slapd-ldap(5) man page is missing any information on the conn-pool-max configuration option. Part of ITS#4791 -- You are receiving this mail because: You are on the CC list for the bug.

1 7

[Bug 9241] New: olcRefintNothing refuse to accept space in the target dn
by openldap-its＠openldap.org 31 Mar '21

31 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9241 Bug ID: 9241 Summary: olcRefintNothing refuse to accept space in the target dn Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: sebastien.chaumat(a)qspin.be Target Milestone: --- When configuring refint : dn: olcOverlay={2}refint,olcDatabase={1}mdb,cn=config objectClass: olcOverlayConfig objectClass: olcRefintConfig olcOverlay: {2}refint olcRefintAttribute: seeAlso olcRefintNothing: cn=admin,dc=test is accepted but olcRefintNothing: cn=admin space,dc=test is rejected when I ldapadd the configuration with the message : ldap_add: Constraint violation (19) additional info: <olcRefintNothing> extra cruft after <string> I tried various quoting : cn="admin space",dc=test cn=admin\20space "cn=admin space" -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 9199] New: Disable IPv6 makes listener work on IP address but hostname or localhost
by openldap-its＠openldap.org 02 Mar '21

02 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9199 Bug ID: 9199 Summary: Disable IPv6 makes listener work on IP address but hostname or localhost Product: OpenLDAP Version: 2.4.49 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: st-wong(a)cuhk.edu.hk Target Milestone: --- Hi, We're compiling 2.4.49 on CentOS8. Make test fails at "test000-rootdse" with error Can't contact LDAP server. Debug log shows error "Address already in use". We're quite sure the port (9011) is not in use. Starting slapd with test command verified the error: ../servers/slapd/slapd -f testrun/slapd.1.conf -h ldap://localhost:9011 Found that it's okay to start slapd if listener URL is using IP address instead. Checked ldap_url_parse* call may not work as expected with V6 disabled (configure option --disable-ipv6). Re-do configuration and make without "--disable-ipv6" works as expected. Would you help? Thanks. -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 9192] New: slapo-rwm: assert triggered with invalid UUID filter
by openldap-its＠openldap.org 02 Mar '21

02 Mar '21

https://bugs.openldap.org/show_bug.cgi?id=9192 Bug ID: 9192 Summary: slapo-rwm: assert triggered with invalid UUID filter Product: OpenLDAP Version: 2.4.48 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- slapo-rwm triggers an assert when a filter with an invalid UUID syntax is used. For example: /opt/symas/bin/ldapsearch -x -H ldaps://ldap0.example.com -D "cn=admin,dc=example,dc=com" -W -b dc=example,dc=com idmUUID=b58540b2-f16c-41c9-8147-83068004dd0a,ou=People,dc=example,dc=com Enter LDAP Password: # extended LDIF # # LDAPv3 # base <dc=example,dc=com> with scope subtree # filter: idmUUID=b58540b2-f16c-41c9-8147-83068004dd0a,ou=People,dc=example,dc=com # requesting: ALL # The above search will trigger an assert. Note that idmUUID is a custom attribute defined as: # idmUUID attributetype ( 1.3.6.1.4.1.29179.2.3.3 NAME 'idmUUID' DESC 'RFC4122 Univeral Unique Identifier for idM' EQUALITY uuidMatch SYNTAX 1.3.6.1.1.16.1 SINGLE-VALUE ) which is using the RFC4530 definition for UUID. On the slapd side, we see: #4 0x0000000000468650 in UUIDNormalize (usage=<optimized out>, syntax=<optimized out>, mr=<optimized out>, val=0x7f1c58003110, normalized=0x7f1c677fc5c0, ctx=<optimized out>) at /home/build/sold/openldap/servers/slapd/schema_init.c:3019 No locals. #5 0x00007f447599c55d in map_attr_value (dc=dc@entry=0x7f1c677fc730, adp=adp@entry=0x7f1c677fc658, mapped_attr=mapped_attr@entry=0x7f1c677fc660, value=0x7f1c58003110, mapped_value=mapped_value@entry=0x7f1c677fc670, memctx=0x7f1c58002810, remap=0) at /home/build/sold/openldap/servers/slapd/overlays/rwmmap.c:471 vtmp = {bv_len = 0, bv_val = 0x0} freeval = 0 ad = 0x1947630 mapping = 0x0 #6 0x00007f447599ccc6 in rwm_int_filter_map_rewrite (op=op@entry=0x7f1c580028f0, dc=dc@entry=0x7f1c677fc730, f=0x7f1c58003170, fstr=fstr@entry=0x7f1c677fc720) at /home/build/sold/openldap/servers/slapd/overlays/rwmmap.c:559 i = <optimized out> p = <optimized out> ad = 0x1947630 atmp = {bv_len = 7, bv_val = 0x1900bb0 "idmUUID"} vtmp = {bv_len = 139759712219536, bv_val = 0x7f1c58003240 "c"} tmp = <optimized out> ber_bvfalse = {bv_len = 18, bv_val = 0x7f447599f816 "(!(objectClass=*))"} ber_bvtf_false = {bv_len = 3, bv_val = 0x7f447599f829 "(|)"} ber_bvtrue = {bv_len = 15, bv_val = 0x7f447599f802 "(objectClass=*)"} ber_bvtf_true = {bv_len = 3, bv_val = 0x7f447599f812 "(&)"} ber_bverror = {bv_len = 9, bv_val = 0x7f447599f7f8 "(?=error)"} ber_bvunknown = {bv_len = 11, bv_val = 0x7f447599f7ec "(?=unknown)"} ber_bvnone = {bv_len = 8, bv_val = 0x7f447599f82d "(?=none)"} len = <optimized out> __PRETTY_FUNCTION__ = "rwm_int_filter_map_rewrite" #7 0x00007f447599d7a8 in rwm_filter_map_rewrite (op=op@entry=0x7f1c580028f0, dc=dc@entry=0x7f1c677fc730, f=<optimized out>, fstr=fstr@entry=0x7f1c677fc720) at /home/build/sold/openldap/servers/slapd/overlays/rwmmap.c:824 rc = <optimized out> fdc = <optimized out> ftmp = {bv_len = 26355712, bv_val = 0x7f4475224500 "\002"} #8 0x00007f4475999c5b in rwm_op_search (op=0x7f1c580028f0, rs=0x7f1c677fda60) at /home/build/sold/openldap/servers/slapd/overlays/rwm.c:976 on = 0x1922620 rwmap = 0x1922800 rc = 0 dc = {rwmap = 0x1922800, conn = 0x7f4475224500, ctx = 0x7f447599f090 "searchFilterAttrDN", rs = 0x7f1c677fda60} fstr = {bv_len = 0, bv_val = 0x0} f = 0x0 an = 0x0 text = 0x0 roc = 0x7f1c58003218 #9 0x000000000049776a in overlay_op_walk (op=op@entry=0x7f1c580028f0, rs=rs@entry=0x7f1c677fda60, which=which@entry=op_search, oi=oi@entry=0x1924430, on=0x1922620) at /home/build/sold/openldap/servers/slapd/backover.c:671 func = 0x1922678 rc = 32768 #10 0x00000000004978be in over_op_func (op=0x7f1c580028f0, rs=0x7f1c677fda60, which=op_search) at /home/build/sold/openldap/servers/slapd/backover.c:747 oi = 0x1924430 on = <optimized out> be = 0x728420 <slap_frontendDB> db = {bd_info = 0x1922620, bd_self = 0x728420 <slap_frontendDB>, be_ctrls = "\000", '\001' <repeats 17 times>, '\000' <repeats 14 times>, be_flags = 768, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0x18cb690, be_nsuffix = 0x18cb6e0, be_schemadn = {bv_len = 12, bv_val = 0x1955c20 "cn=Subschema"}, be_schemandn = {bv_len = 12, bv_val = 0x1955370 "cn=subschema"}, be_rootdn = { bv_len = 0, bv_val = 0x0}, be_rootndn = {bv_len = 0, bv_val = 0x0}, be_rootpw = {bv_len = 0, bv_val = 0x0}, be_max_deref_depth = 0, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 50, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x1925890, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0x0, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __elision = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x7200e8 <cf_ocs+392>, be_private = 0x0, be_next = {stqe_next = 0x18cbcc0}} sc = <optimized out> cb = 0x7f1c580031e8 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #11 0x0000000000431006 in do_search (op=0x7f1c580028f0, rs=0x7f1c677fda60) at /home/build/sold/openldap/servers/slapd/search.c:247 base = {bv_len = 14, bv_val = 0x7f1c580025c7 "dc=example,dc=com"} siz = 0 off = 0 i = <optimized out> #12 0x000000000042ede5 in connection_operation (ctx=ctx@entry=0x7f1c677fdbd0, arg_v=arg_v@entry=0x7f1c580028f0) at /home/build/sold/openldap/servers/slapd/connection.c:1167 rc = 80 cancel = <optimized out> op = 0x7f1c580028f0 rs = {sr_type = REP_RESULT, sr_tag = 0, sr_msgid = 0, sr_err = 0, sr_matched = 0x0, sr_text = 0x0, sr_ref = 0x0, sr_ctrls = 0x0, sr_un = {sru_search = {r_entry = 0x0, r_attr_flags = 0, r_operational_attrs = 0x0, r_attrs = 0x0, r_nentries = 0, r_v2ref = 0x0}, sru_sasl = {r_sasldata = 0x0}, sru_extended = {r_rspoid = 0x0, r_rspdata = 0x0}}, sr_flags = 0} tag = 99 opidx = SLAP_OP_SEARCH conn = 0x7f4475224500 memctx = 0x7f1c58002810 memctx_null = 0x0 memsiz = 1048576 __PRETTY_FUNCTION__ = "connection_operation" #13 0x000000000042f0ea in connection_read_thread (ctx=0x7f1c677fdbd0, argv=0x16) at /home/build/sold/openldap/servers/slapd/connection.c:1314 rc = <optimized out> cri = {op = 0x7f1c580028f0, func = 0x0, arg = 0x0, ctx = <optimized out>, nullop = <optimized out>} s = <optimized out> #14 0x00007f447a585353 in ldap_int_thread_pool_wrapper (xpool=0x18b1340) at /home/build/sold/openldap/libraries/libldap_r/tpool.c:963 pq = 0x18b1340 pool = 0x18b1250 task = 0x7f1c68000da0 work_list = <optimized out> ctx = {ltu_pq = 0x18b1340, ltu_id = 139759972247296, ltu_key = {{ltk_key = 0x42cbf0 <conn_counter_init>, ltk_data = 0x7f1c58002700, ltk_free = 0x42ccb0 <conn_counter_destroy>}, { ltk_key = 0x47fef0 <slap_sl_mem_init>, ltk_data = 0x7f1c58002810, ltk_free = 0x47fdb0 <slap_sl_mem_destroy>}, {ltk_key = 0x1ae4a40, ltk_data = 0x7f1c58102f30, ltk_free = 0x7f44763ff550 <mdb_reader_free>}, {ltk_key = 0x4416f0 <slap_op_free>, ltk_data = 0x0, ltk_free = 0x441650 <slap_op_q_destroy>}, {ltk_key = 0x0, ltk_data = 0x7f1c58000a80, ltk_free = 0x0}, {ltk_key = 0x0, ltk_data = 0x0, ltk_free = 0x0} <repeats 27 times>}} kctx = <optimized out> keyslot = <optimized out> hash = <optimized out> pool_lock = 0 freeme = 0 __PRETTY_FUNCTION__ = "ldap_int_thread_pool_wrapper" #15 0x00007f4478d42ea5 in start_thread () from /lib64/libpthread.so.0 No symbol table info available. #16 0x00007f4478a6b8cd in clone () from /lib64/libc.so.6 No symbol table info available. (gdb) -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 9197] New: slapd-ldap/slapo-chain hits error 80 after idletimeout
by openldap-its＠openldap.org 26 Feb '21

26 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9197 Bug ID: 9197 Summary: slapd-ldap/slapo-chain hits error 80 after idletimeout Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- From a customer: In order to communicate via the LB managed writable ldap, we have to ensure that an idle connection is periodically refreshed. If we do not, the LB will silently drop the connection after 5 minutes. Therefore to combat that I set an olcIdleTimeout on the writable server so that the chain cached connections will be removed before the LB timeout hits. However the slapo-ldap client goes into CLOSE_WAIT state, which causes subsequent ldapmodify updates being brokered by the read only instance to fail with err=80. There appear to be a few bugs filed on this in the past against slapd-ldap, but it's not clear if we may be hitting the same issue, or if this is a new one. I've also connected the read only instances directly to the writable ldap instances and the CLOSE_WAIT issue persists, so I don't believe the CLOSE_WAIT issue is caused by the LB These were the other threads I found as I started looking for this problem, these are using the ldap-proxy though I think: https://www.openldap.org/lists/openldap-technical/201301/msg00323.html http://www.openldap.org/lists/openldap-software/201004/msg00060.html https://www.openldap.org/lists/openldap-bugs/200412/msg00029.html The LB we have seems to be set to forget connections that last over 5 min per the setting, so the 240:10:30 seemed like it should have worked and I just thought it wasn't working because in the man page the text "Only some systems support the customization of these values" is present. however after setting keepalive to 60:10:30 did I maintain a stable connection, so there may be other network settings at play I'm not aware of. -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Issue 9292] New: Man page for LDAP_OPT_TIMEOUT/LDAP_OPT_NETWORK_TIMEOUT unclear on use of free
by openldap-its＠openldap.org 26 Feb '21

26 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9292 Issue ID: 9292 Summary: Man page for LDAP_OPT_TIMEOUT/LDAP_OPT_NETWORK_TIMEOUT unclear on use of free Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: sshanks(a)kx.com Target Milestone: --- Ref: https://git.openldap.org/openldap/openldap/-/blob/master/doc/man/man3/ldap_… https://www.openldap.org/software/man.cgi?query=ldap_get_option&sektion=3&a… See details of LDAP_OPT_TIMEOUT and LDAP_OPT_NETWORK_TIMEOUT. Both state "the caller has to free *outvalue" This can be interpreted as the called must call free on outvalue. This can cause a random crash when 'free' used (build on Linux ran ok, Windows crashed immediately) Would be better is it stated that the caller must use 'ldap_memfree', in the same way as other options state use must use 'ldap_memfree'. FYI: within the code, get_option for these params calls ldap_int_timeval_dup which calls LDAP_MALLOC -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Bug 9238] New: access control documentation is confusing
by openldap-its＠openldap.org 26 Feb '21

26 Feb '21

https://bugs.openldap.org/show_bug.cgi?id=9238 Bug ID: 9238 Summary: access control documentation is confusing Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: kop(a)karlpinc.com Target Milestone: --- Created attachment 716 --> https://bugs.openldap.org/attachment.cgi?id=716&action=edit git format-patch output slapd.access says "Access control checking stops at the first match of the <what> and <who> clause, unless otherwise dictated by the <control> clause." But this, by itself, is wrong. You have to read the next sentence, which says there's an implicit "by * none stop", meaning that the default is to stop when only <what> matches. Patch attached. I, Karl O. Pinc, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- You are receiving this mail because: You are on the CC list for the bug.

1 16

← Newer
1
2
3
4
5
6
7
...
13
Older →

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs July 2020