[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.
6 days, 3 hours
[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.
6 days, 6 hours
[Bug 9218] New: Revist entry_release handling in slapo-pache, slapo-translucent
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9218
Bug ID: 9218
Summary: Revist entry_release handling in slapo-pache,
slapo-translucent
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
From a past discussion with hyc on 2.5 items:
[13:57] <hyc> there's a nagging problem though, pcache's entry_release function
needs to distinguish between its backend actually freeing the entry, or being a
no-op
[13:57] <hyc> so it can decide whether to return success or continue
[13:58] <hyc> the patch to translucent sidesteps the question, by avoiding
other overlays
[13:58] <hyc> but we need to revisit this in 2.5
--
You are receiving this mail because:
You are on the CC list for the bug.
1 week
[Bug 9217] New: Audit all schema definitions to have official non-experimental OIDs where possible
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9217
Bug ID: 9217
Summary: Audit all schema definitions to have official
non-experimental OIDs where possible
Product: OpenLDAP
Version: 2.5
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
From a past discussion with hyc on 2.5 requirements:
[09:27] <hyc> we also need to audit all of these schema defs
[09:27] <hyc> we're supposed to have official, non-experimental OIDs for
released schema
[09:28] <hyc> accesslog is still using 666, experimental arc
[09:29] <hyc> I think this means we should polish up the logschema draft,
Informational status, and publish it again as final
--
You are receiving this mail because:
You are on the CC list for the bug.
1 week
[Bug 9243] New: back-perl configure should test linking with libperl
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9243
Bug ID: 9243
Summary: back-perl configure should test linking with libperl
Product: OpenLDAP
Version: 2.4.49
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
./configure --enable-perl && make
[...]
checking for perl... /usr/bin/perl
[...]
libtool: link: cc -g -O2 -o slapd main.o globals.o bconfig.o config.o daemon.o
connection.o search.o filter.o add.o cr.o attr.o entry.o backend.o backends.o
result.o operation.o dn.o compare.o modify.o delete.o modrdn.o ch_malloc.o
value.o ava.o bind.o unbind.o abandon.o filterentry.o phonetic.o acl.o
str2filter.o aclparse.o init.o user.o lock.o controls.o extended.o passwd.o
schema.o schema_check.o schema_init.o schema_prep.o schemaparse.o ad.o at.o
mr.o syntax.o oc.o saslauthz.o oidm.o starttls.o index.o sets.o referral.o
root_dse.o sasl.o module.o mra.o mods.o sl_malloc.o zn_malloc.o limits.o
operational.o matchedValues.o cancel.o syncrepl.o backglue.o backover.o
ctxcsn.o ldapsync.o frontend.o slapadd.o slapcat.o slapcommon.o slapdn.o
slapindex.o slappasswd.o slaptest.o slapauth.o slapacl.o component.o aci.o
txn.o slapschema.o slapmodify.o version.o -Wl,-E -fstack-protector-strong
-pthread libbackends.a liboverlays.a ../../libraries/liblunicode/liblunicode.a
../../libraries/librewrite/librewrite.a ../../libraries/liblutil/liblutil.a
../../libraries/libldap_r/.libs/libldap_r.a
/home/ryan/tmp/openldap/libraries/liblber/.libs/liblber.a
../../libraries/liblber/.libs/liblber.a -L/usr/local/lib
-L/usr/lib/x86_64-linux-gnu/perl/5.28/CORE -lperl -ldl -lm -lpthread -lcrypt
-lresolv -pthread
/usr/bin/ld: cannot find -lperl
collect2: error: ld returned 1 exit status
It should probably test compiling and linking a program with the detected
CPPFLAGS and LDFLAGS.
--
You are receiving this mail because:
You are on the CC list for the bug.
1 week
[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 week, 3 days
[Bug 9246] New: Improve authzFrom/authzTo docs
by openldap-its＠openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9246
Bug ID: 9246
Summary: Improve authzFrom/authzTo docs
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 724
--> https://bugs.openldap.org/attachment.cgi?id=724&action=edit
Patch
The defaults for group/objectclass/attributetype were not documented.
Improve the section overall.
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 week, 3 days
[Bug 9238] New: access control documentation is confusing
by openldap-its＠openldap.org
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 week, 3 days
[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 week, 4 days