https://bugs.openldap.org/show_bug.cgi?id=9398
Issue ID: 9398
Summary: Stale accesslog cookie due to unclean shutdown
Product: OpenLDAP
Version: 2.4.56
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
If slapd terminates uncleanly, a checkpoint will be lost on the accesslog db.
Depending on the syncprov overlay checkpoint settings (usually no checkpointing
is enabled on the accesslog db) this can cause the system to refuse engage in
replication at startup.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9303
Issue ID: 9303
Summary: Add support for WolfSSL as an alternative to OpenSSL
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
For OpenLDAP 2.6, we should investigate adding support for WolfSSL as an
alternative to OpenSSL.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9284
Issue ID: 9284
Summary: Need man page for vc contrib overlay
Product: OpenLDAP
Version: 2.4.50
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
The verified credentials overlay in contrib is missing a man page describing
its purpose
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9272
Issue ID: 9272
Summary: Invalid search results for subordinate/glued database
Product: OpenLDAP
Version: 2.4.47
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: grapvar(a)gmail.com
Target Milestone: ---
Here is a trivial test case. Look at the following bunch of glued
dit's/databases, declared in this order:
| suffix ou=a,ou=1,ou=T # subordinate; contains only one (top-level) entry
| suffix ou=2,ou=T # subordinate; contains only one (top-level) entry
| suffix ou=b,ou=1,ou=T # subordinate; contains only one (top-level) entry
| suffix ou=T # master database, has two entries, top-level
| ` ou=1 # ... and this child entry
let's query the united database:
| $ ldapsearch -b ou=1,ou=T -s sub '' nx
| dn: ou=1,ou=T
| dn: ou=a,ou=1,ou=T
| dn: ou=b,ou=1,ou=T
Nice! But wait, what if ...
| $ ldapsearch -b ou=1,ou=T -s sub -E\!pr=2/noprompt '' nx
| dn: ou=1,ou=T
| dn: ou=a,ou=1,ou=T
|
| # pagedresults: cookie=//////////8=
... BANG! ...
| Server is unwilling to perform (53)
The problem is the glue_op_search(), which has issues
* different parts of code make different assumptions about data structures
* different parts of code track state inconsistently
* code that looks like a highly probably dead code
I mean that likely possible to build another bug-triggering test cases, and
glue_op_search() needs not just a fix of the bug above, but intense cleaning
and structuring.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9256
Bug ID: 9256
Summary: The ACLs required for SASL binding are not fully
documented
Product: OpenLDAP
Version: 2.5
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 727
--> https://bugs.openldap.org/attachment.cgi?id=727&action=edit
Patch massaging the SASL binding requirement docs
While some ACL requirements for SASL binding are documented, some are not.
E.g, that olcAuthzRegexp requires =x on objectClass when direct DN mapping is
not documented. Other requirements can be reasoned out based on the existing
documentation, but this can be very difficult when unfamiliar with all the
moving parts and the places they are documented. E.g. knowing that
(objectClass=*) is the default filter, and that there's _always_ _some_ filter,
and connecting this with ACLs required to do search-based SASL mapping.
The attached patch brings all the SASL binding requirements together in one
place in the docs and makes everything explicit. The word "SASL" is included,
for those searching for that keyword.
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.
https://bugs.openldap.org/show_bug.cgi?id=9244
Bug ID: 9244
Summary: API calls blocking after async connect
Product: OpenLDAP
Version: 2.4.49
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: ryan(a)openldap.org
Target Milestone: ---
Created attachment 721
--> https://bugs.openldap.org/attachment.cgi?id=721&action=edit
async connect test without TLS
My understanding of LDAP_OPT_CONNECT_ASYNC is that the attached program should
not block. If the connection does not establish fast enough, the bind call is
supposed to return LDAP_X_CONNECTING.
(At least that's how I understand it, based on the original behaviour (circa
2.4.23 up to 2.4.40) as well as the bind loop in back-meta. On the other hand,
the man page does "Subsequent calls to library routines will poll for
completion of the connect before performing further operations" which might be
interpreted as meaning they would block...)
In current releases it does block, as demonstrated by strace on Linux (latency
added using 'tc qdisc'):
[...]
connect(3, {sa_family=AF_INET, sin_port=htons(389),
sin_addr=inet_addr("192.168.1.204")}, 16) = -1 EINPROGRESS (Operation now in
progress)
write(3, "0\f\2\1\1`\7\2\1\3\4\0\200\0", 14) = -1 EAGAIN (Resource temporarily
unavailable)
poll([{fd=3, events=POLLOUT|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=3,
revents=POLLOUT}])
write(3, "0\f\2\1\1`\7\2\1\3\4\0\200\0", 14) = 14
poll([{fd=3, events=POLLIN|POLLPRI}], 1, -1) = 1 ([{fd=3, revents=POLLIN}])
read(3, "0\f\2\1\1a\7\n", 8) = 8
read(3, "\1\0\4\0\4\0", 6) = 6
write(2, "OK: ldap_simple_bind_returned 0 "..., 42OK: ldap_simple_bind_returned
0 (Success)
) = 42
[...]
As discussed in IRC, I believe I bisected this down to commit ae6347bac, from
bug 8022. The reasoning is sound, but ldap_int_open_connection does not
actually return -2, only -1 or 0.
The patch is simple enough, but I'm also looking at some later commits that
were probably done to work around this, and might not be needed now (bug 8957,
bug 8968, bug 8980). Also need to test all setups thoroughly (ldap, ldaps,
STARTTLS, not to mention back-meta/asyncmeta).
I also notice that LDAP_OPT_CONNECT_ASYNC is not effective unless
LDAP_OPT_NETWORK_TIMEOUT is also set. It might be intentional, but the man page
doesn't mention this specifically, and I don't see why it would be necessary...
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9220
Bug ID: 9220
Summary: Rewrite Bind and Exop result handling
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: ---
Bind and Exop result handling needs a rewrite so it is no longer a special case
for overlays.
--
You are receiving this mail because:
You are on the CC list for the bug.
https://bugs.openldap.org/show_bug.cgi?id=9343
Issue ID: 9343
Summary: Expand ppolicy policy configuration to allow URL
filter
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: ---
Currently, ppolicy only supports a single global default policy, and past that
any policies must be manually added to a given user entry if they are supposed
to have something other than the default policy.
Also, some sites want no default policy, and only a specific subset to have a
policy applied to them.
For both of these cases, it would be helpful if it were possible to configure a
policy to apply to a set of users via a URL similar to the way we handle
creating groups of users in dynlist
--
You are receiving this mail because:
You are on the CC list for the issue.
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/mta…
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.