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.
https://bugs.openldap.org/show_bug.cgi?id=8752
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=9782
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
https://bugs.openldap.org/show_bug.cgi?id=9877
Issue ID: 9877
Summary: Session Tracking failing to log IP addresses
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
From slapd log in master with session tracking enabled:
62c45cfe.3b59f358 0x7fa3b0aa8700 conn=1002 fd=15 ACCEPT from IP=127.0.0.1:58790
(IP=127.0.0.1:9012)
62c45cff.017af6f5 0x7fa3b0aa8700 conn=1002 op=1 [IP=[
USERNAME=cn=manager,dc=example,dc=com] modifications:
62c45cff.017b2c53 0x7fa3b0aa8700 conn=1002 op=1 [IP=[
USERNAME=cn=manager,dc=example,dc=com] MOD dn="cn=replicator,dc=example,dc=com"
62c45cff.017bb35e 0x7fa3b0aa8700 conn=1002 op=1 [IP=[
USERNAME=cn=manager,dc=example,dc=com] MOD attr=pwdLastSuccess
Note the missing IP address. This works correctly in current 2.6.2
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9874
Issue ID: 9874
Summary: slapadd is returning garbage error data
Product: OpenLDAP
Version: 2.6.2
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
When slapadd encounters an error, instead of returning that error it is
returning garbage text.
Example:
slapadd: could not add entry dn="olcDatabase={1}mdb,cn=config" (line=1119): #]I
Note the: "#]I"
If run with -d -1, we see the actual error is:
mdb_db_init: Initializing mdb database
olcDbDirectory: value #0: invalid path: No such file or directory
slapadd: could not add entry dn="olcDatabase={1}mdb,cn=config" (line=1119):
olcDbDirectory: value #0: invalid path: No such file or directory
slapadd shutdown: initiated
--
You are receiving this mail because:
You are on the CC list for the issue.
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.
https://bugs.openldap.org/show_bug.cgi?id=9875
Issue ID: 9875
Summary: OpenLDAP 2.6 libldap_r.so is missing
Product: OpenLDAP
Version: 2.6.2
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: andysyam61(a)gmail.com
Target Milestone: ---
OpenLDAP 2.6 libldap_r.so is missing
https://github.com/python-ldap/python-ldap/issues/432
--
You are receiving this mail because:
You are on the CC list for the issue.
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.