[Issue 9358] New: back-mdb may return accesslog entries out of order
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9358
Issue ID: 9358
Summary: back-mdb may return accesslog entries out of order
Product: OpenLDAP
Version: 2.4.53
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
back-mdb will usually return search entries in entryID order, but may do a dn
traversal instead if the count of children is smaller than the count of search
filter candidates. The RDNs are sorted in length order, not lexical order. For
accesslog, all RDNs are of equal length but if they have trailing zeroes, the
generalizedTime normalizer truncates them. Changing their lengths causes
accesslog's timestamp-based RDNs to sort in the wrong order.
The least intrusive fix is to override the syntax/normalizer for reqStart and
reqEnd attributes to not truncate trailing zeroes.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 1 month
[Issue 9516] New: Argon2 configuration parameters with slappasswd
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9516
Issue ID: 9516
Summary: Argon2 configuration parameters with slappasswd
Product: OpenLDAP
Version: 2.4.58
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: gilbert.kowarzyk(a)servicenow.com
Target Milestone: ---
It is currently possible to generate an Argon2 hash using slappasswd as
follows:
slappasswd -h {ARGON2} -o module-load=pw-argon2
However, I believe that it is currently not possible to provide Argon2
configuration values for parameters "m", "t", and "p" when using slappasswd.
If it is currently possible to provide these config parameters when using
slappasswd, please add documentation for how to do so.
Thanks in advance!
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 1 month
[Issue 9596] New: Python test suite
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9596
Issue ID: 9596
Summary: Python test suite
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
The bash test suite is extremely limited, hard to write for and slow. We can't
lose it as it is also portable, but something should be introduced for
developers/CI on more modern systems and increase coverage.
A Python 3 seed for one is in development in MR!347.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 1 month
[Issue 9726] New: Admin guide and man pages need better documentation on disabling syslog
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9726
Issue ID: 9726
Summary: Admin guide and man pages need better documentation on
disabling syslog
Product: OpenLDAP
Version: 2.6.0
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
2.6.0 added the new feature allowing using a logfile for all debug/loglevel
messages and bypassing syslog entirely. However, there is no documentation on
the new settings or examples of how to do this in the admin guide, and the man
page sections on the new parameters for the logfile side do not note at
when/how they enable bypassing syslog.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 2 months
[Issue 9782] New: regression test its8752 failure
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9782
Issue ID: 9782
Summary: regression test its8752 failure
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If a contextCSN update (new cookie) goes from server A through server B to
server C, server C will use that CSN to update entryCSN as well (which neither
A nor B did). This fails the initial replication check.
The issue has likely existed since deltasync was made possible, a version of
this is confirmed at least in 2.4.60 onwards to current master. In principle,
it is related to concerns raised in ITS#9580.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 2 months
[Issue 9534] New: Persistent test043 failures
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9534
Issue ID: 9534
Summary: Persistent test043 failures
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: ---
In testing current RE25 as of 4/23/2021
(73b2769d05529a7d474661023f2c4f3a931417b2)
test043 is sporadically failing. Examining the testrun log, it appears
replication never even initiated.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 2 months
[Issue 9642] New: Adding a task to runqueue doesn't wake the main thread
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9642
Issue ID: 9642
Summary: Adding a task to runqueue doesn't wake the main thread
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
If a connection adds a new syncrepl stanza, that is not started until the main
thread comes around to doing it. However if that thread is currently stuck in
SLAP_EVENT_WAIT() and nothing else happens (like an unbind over the connection
that modified the config), the task is never started. This can take a long
time.
No idea yet how to wake it up with/from ldap_pvt_runqueue_insert() given that
sits within libldap and not really something that should be calling
slap_wake_listener().
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 3 months
[Issue 9468] New: slapd-ldap does anonymous bind even if rebind-as-user is set
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9468
Issue ID: 9468
Summary: slapd-ldap does anonymous bind even if rebind-as-user
is set
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: tero.saarni(a)est.tech
Target Milestone: ---
When back-ldap retries bind operation after connection retry, it will do it as
anonymous even if rebind-as-user is set to yes.
Expected behavior is that (re)bind is done with user's credentials from the
initial bind operation.
I observed following (Warning: I might have understood details of the code
incorrectly):
When rebind-as-user is set and bind operation from client is processed, proxy
will copy the credentials to ldapconn_t representing the remote LDAP
connection. When remote LDAP connection is closed (e.g. by the proxy itself due
to timeout), the bind credentials information is lost when freeing the old
ldapconn_t. At this point, client still holds the connection to proxy and is
unaware of the remote connection being lost. Proxy then re-establishes the
connection and "synthetically" generates new bind itself, but since it does not
have the credentials stored in memory anymore, it sends anonymous bind on
behalf of the client.
As a side effect, slapd currently crashes if remote server does not allow
anonymous bind and responds with InvalidCredentials instead. The crash is due
to assert(), which is handled in separate issue
https://bugs.openldap.org/show_bug.cgi?id=9288
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 3 months
[Issue 9580] New: Refresh vs. accesslog in delta-MPR
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9580
Issue ID: 9580
Summary: Refresh vs. accesslog in delta-MPR
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: replication
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
A server consuming a plain syncrepl session (might be a delta-MMR refresh)
still has to log the entries into accesslog, however that accesslog stops being
capable of serving as a delta-sync source:
- operation entryCSNs will be out-of-order
- the changes logged will not be the intended modifications (e.g. if we fell
back after a conflict, the conflicting entry will be replaced with the other
version, other examples available)
We need to deal with that somehow, at the very least we need to make sure the
consumer will not take them at face value. We could record this in the
accesslog root entry if we can detect when this starts and match it up with the
final cookie, syncprov would still need some tweaks to understand it.
We could mark the entries received this way and make sure delta-consumers treat
them as "poison", as if they were running a plain syncrepl session themselves
(not update contextCSN until that's finished, mark its own accesslog entries
this way, ...). Anything like that needs guarantees that it will clean itself
up once all of the real plain sessions finish otherwise we've lost delta-sync
altogether.
A different approach might or might not be needed for live delta-persist
sessions replicating from a refreshing provider, but at least that syncprov has
a way of detecting this live if it chooses to.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 3 months
[Issue 9385] New: Opening an env with MDB_NOSUBDIR with no existing file returns error
by openldap-its@openldap.org
https://bugs.openldap.org/show_bug.cgi?id=9385
Issue ID: 9385
Summary: Opening an env with MDB_NOSUBDIR with no existing file
returns error
Product: LMDB
Version: unspecified
Hardware: All
OS: Mac OS
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: kriszyp(a)gmail.com
Target Milestone: ---
Created attachment 776
--> https://bugs.openldap.org/attachment.cgi?id=776&action=edit
A fix to tolerate stat call on non-existing file
Calling mdb_env_open with a file path to a file that doesn't exist yet, with
MDB_NOSUBDIR on a non-Windows OS will return an error indicating that the file
doesn't exist. This is supposed to create a new file, and works properly on the
mdb.master branch, and still functions properly on Windows. The error is due to
the stat() call in mdb_env_open prior to the file existing.
I attached a patch that tolerates the absence of the file before checking if
the file is on a block device. I am not sure if this is the appropriate fix, or
if would be better to move this check later in mdb_env_open after the file is
created, or alternately, determining the parent directory and calling stat on
that.
--
You are receiving this mail because:
You are on the CC list for the issue.
1 year, 4 months