[Bug 9189] New: Add GSSAPI channel-bindings support
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9189
Bug ID: 9189
Summary: Add GSSAPI channel-bindings support
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: iboukris(a)gmail.com
Target Milestone: ---
Recently MS has announce they plan to enforce channel-bindings for LDAP over
TLS (ADV190023).
To support it on client side, we need to pass "tls-endpoint" bindings (RFC
5929) to the SASL plugin, and make use of that in GSSAPI.
See also:
https://github.com/cyrusimap/cyrus-sasl/pull/601
--
You are receiving this mail because:
You are on the CC list for the bug.
11 months, 2 weeks
[Bug 9186] New: RFE: More metrics in cn=monitor
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9186
Bug ID: 9186
Summary: RFE: More metrics in cn=monitor
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: michael(a)stroeder.com
Target Milestone: ---
Currently I'm grepping metrics from syslog with mtail:
https://gitlab.com/ae-dir/ansible-ae-dir-server/-/blob/master/templates/m...
With a new binary logging this is not possible anymore.
Thus it would be nice if cn=monitor provides more metrics.
1. Overall connection count per listener starting at 0 when started. This would
be a simple counter added to:
entries cn=Listener 0,cn=Listeners,cn=Monitor
2. Counter for the various "deferring" messages separated by the reason for
deferring.
3. Counters for all possible result codes. In my mtail program I also label it
with the result type.
--
You are receiving this mail because:
You are on the CC list for the bug.
1 year, 6 months
[Bug 9199] New: Disable IPv6 makes listener work on IP address but hostname or localhost
by openldap-its＠openldap.org
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 year, 11 months
[Bug 9192] New: slapo-rwm: assert triggered with invalid UUID filter
by openldap-its＠openldap.org
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 year, 11 months
[Bug 9197] New: slapd-ldap/slapo-chain hits error 80 after idletimeout
by openldap-its＠openldap.org
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 year, 11 months
[Bug 9194] New: slapd-ndb: Remove backend for the 2.5 release
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9194
Bug ID: 9194
Summary: slapd-ndb: Remove backend for the 2.5 release
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: ---
Remove the slapd-ndb backend for the 2.5 release, as it was never finished and
development on it has ceased.
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 3 months
[Bug 9191] New: libraries\liblutil\meter.c have a bad function lutil_meter_update, maybe divide 0
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9191
Bug ID: 9191
Summary: libraries\liblutil\meter.c have a bad function
lutil_meter_update, maybe divide 0
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: digpython(a)163.com
Target Milestone: ---
int
lutil_meter_update (
lutil_meter_t *meter,
size_t position,
int force)
{
static const double display_rate = 0.5;
double frac, cycle_length, speed, now;
time_t remaining_time, elapsed;
int rc;
assert( meter != NULL );
lutil_get_now( &now );
if ( !force && now - meter->last_update < display_rate ) return 0;
frac = ((double)position) / ((double) meter->goal_value);
elapsed = now - meter->start_time;
if (frac <= 0.0) return 0;
if (frac >= 1.0) {
rc = meter->display->display_update(
&meter->display_data,
1.0,
0,
(time_t) elapsed,
((double)position) / elapsed);
} else {
...
}
--
You are receiving this mail because:
You are on the CC list for the bug.
2 years, 3 months
[Bug 9185] New: glue entry
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9185
Bug ID: 9185
Summary: glue entry
Product: OpenLDAP
Version: 2.4.48
Hardware: All
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: client tools
Assignee: bugs(a)openldap.org
Reporter: gnoe(a)symas.com
Target Milestone: ---
--
You are receiving this mail because:
You are watching someone on the CC list of the bug.
2 years, 4 months