https://bugs.openldap.org/show_bug.cgi?id=10383
Issue ID: 10383
Summary: slapd-meta ignores olcDbIDAssertBind if olcDbURI
defined after it
Product: OpenLDAP
Version: 2.6.9
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: david.frickert(a)protonmail.com
Target Milestone: ---
Hi,
We are using slapd-meta to connect an OpenLDAP server to another external LDAP
server and it works well on first configuration.
However, if we want to update any info, e.g. the external LDAP URI, we must
replace the olcDbURI attribute. This means that the ordering of the attributes
change and this attribute is now defined after olcDbIDAssertBind.
Didn't think this would be important, but after this change the "meta"
connection stops working and upon enabling debugging i can see that the
external LDAP server is responding with:
"ldap_bind: Inappropriate authentication (48)
additional info: Anonymous Simple Bind Disabled"
This seems to imply that the olcDbIDAssertBind attribute is being ignored,
likely due to being defined before olcDbURI (my assumption).
Is this intended? If so, what can we do to mitigate this problem?
Do we need to perform a replace on all attributes of the object to ensure
correct ordering, or is there any way to perform an in-place attribute
modification without making it shift its position in the object?
Example:
First configuration (OK):
# {0}uri, {2}meta, config
dn: olcMetaSub={0}uri,olcDatabase={2}meta,cn=config
objectClass: olcMetaTargetConfig
olcMetaSub: {0}uri
--> olcDbURI: ldap://REDACTED/ou=users,REDACTED
olcDbIDAssertBind: bindmethod=simple starttls=yes tls_reqcert=demand
binddn="REDACTED" credentials="REDACTED"
olcDbRewrite: {0}suffixmassage REDACTED REDACTED
olcDbKeepalive: 0:0:0
olcDbBindTimeout: 100000
olcDbCancel: abandon
After URI update (NOK):
# {0}uri, {2}meta, config
dn: olcMetaSub={0}uri,olcDatabase={2}meta,cn=config
objectClass: olcMetaTargetConfig
olcMetaSub: {0}uri
olcDbIDAssertBind: bindmethod=simple starttls=yes tls_reqcert=demand
binddn="REDACTED" credentials="REDACTED"
olcDbRewrite: {0}suffixmassage REDACTED REDACTED
olcDbKeepalive: 0:0:0
olcDbBindTimeout: 100000
olcDbCancel: abandon
--> olcDbURI: ldap://REDACTED/ou=users,REDACTED
The olcDbURI attribute is shifted to the bottom after a modify operation, and
seems to cause these issues.
Best Regards,
David
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10286
Issue ID: 10286
Summary: ldap_pvt_gettime may result in "not new enough csn"
problems in multi-thread case.
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: 971748261(a)qq.com
Target Milestone: ---
Created attachment 1041
--> https://bugs.openldap.org/attachment.cgi?id=1041&action=edit
the log of adding two entry which shows the time sequence.
I used openldap as krb5's database, and openldap was deploymented in
mirrormode.
I tried to add kerberos principals via kadmin.local -q "addprinc -randkey
principal.
slapd log showed that the entry of kadmin/admin was added earlier than the
entry of ossuser. But the csn of kadmin/admin was greater than ossuser.
In this case, when the two entry began to sync to the other slapd server,
ossuser was ignored because of "csn not new enough"
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10293
Issue ID: 10293
Summary: Log operations generated by syncrepl at STATS level
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
Similarly to how incoming operations are logged, operations created by syncrepl
should be logged as well.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10398
Issue ID: 10398
Summary: memberof and refint clash on subtree renames
Product: OpenLDAP
Version: 2.6.10
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
If a group and its members are under a subtree that got renamed, refint will
trigger, and try to update all the relevant DNs. When it processes the group
entry, it will issue Modifies to update the DNs of the group's members. The
memberof overlay will see these modifies and start trying to update the
corresponding memberof values but will only succeed halfway.
It will try to delete the old memberof value from the old member DN's entry,
which fails because the subtree has renamed all the entries. Then it will try
to add the new memberof value to the new member DN's entry, which succeeds.
Then eventually refint will try to process the member's. It will try to delete
the old memberof value from the new entry, and add the new memberof value to
the entry. This modify request fails because the new value is already present.
The entry is left with a memberof value that points to the obsolete group DN.
The solution is for refint to set the manageDsaIt control on its repair ops,
and for memberof to ignore Modify requests with this control set.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10329
Issue ID: 10329
Summary: Additional issues with pcache, and a test
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: aweits(a)rit.edu
Target Milestone: ---
Created attachment 1062
--> https://bugs.openldap.org/attachment.cgi?id=1062&action=edit
test & patches
Hello again!
Further testing revealed some more issues in pcache [re: ITS#10270]. I've
attached an update to test020-proxycache as well. These are based off the
current git HEAD.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10026
Issue ID: 10026
Summary: Refresh handling can skip entries (si_dirty not
managed properly)
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: ondra(a)mistotebe.net
Target Milestone: ---
Take MPR plain syncrepl with 3+ providers.
When a provider's own syncrepl session transitions to persist and a it starts a
new parallel session towards another host, that session always has to start as
a refresh. If that refresh serves entries to us, our handling of si_dirty is
not consistent:
- if the existing persist session serves some of these entries to us, we can
"forget" to pass the others to a newly connected consumer
- same if the refresh is abandoned and we start refreshing from a different
provider that might be behind what we were being served (again our consumers
could suffer)
- if we restart, si_dirty is forgotten and our consumers suffer even worse
We might need to be told (at the beginning of the refresh?) what the end state
we're going for is, so we can keep si_dirty on until then. And somehow persist
that knowledge in the DB...
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9717
Issue ID: 9717
Summary: The RADIUSOV overlay can be incorporated into OpenLDAP
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: contrib
Assignee: bugs(a)openldap.org
Reporter: rdubner(a)symas.com
Target Milestone: ---
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10363
Issue ID: 10363
Summary: Implement a target connection time-to-live in
asyncmeta
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
Implement a feature that limits the maximum time before a target connection is
reset, even if it is not idle - conn-ttl. To avoid too many target connections
timing out at once, a minimum reset interval per target should also be
configurable. So, a configuration of:
conn-ttl 5s 5s
would mean connections have a 5 seconds time-to-live, but a connection should
be reset no more frequently that once every 5 seconds per target.
This feature was requested by a customer.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9731
Issue ID: 9731
Summary: startup messages still go to syslog when logfile-only
is on
Product: OpenLDAP
Version: 2.6.0
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 setting logfile-only on, slapd still logs its startup message to syslog:
Oct 29 21:07:47 u18test slapd[18534]: @(#) $OpenLDAP: slapd 2.6.0 (Oct 29 2021
05:12:17) $#012#011openldap
This is useful information to have consolidated into the specified logfile.
Note that:
617c62a3.16f03fdb 0x7f9325ed67c0 slapd starting
does make it to the logfile. However, it would be useful to have the build
date and version in the specified logfile.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10380
Issue ID: 10380
Summary: file logger doesn't emit slapd startup/version info
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: ---
When using syslog, a startup message is emitted which is useful in many
different contexts:
- signals a slapd restart to the admin
- shows the actual version used
- if a crash happened just before, there is no "stopped" message, this is a
hint to anyone looking that something was not right and the slapd is not the
same process
- people writing log processing scripts (incident response) know when it's
necessary to reset their state, again as it's a new process
Because of the above, it feels like a regression to me.
I guess we can just emit this info on logfile config handlers? This means
startups and logfile switches are still handled as they used to in syslog and
log rotation doesn't emit anything (making it easy and safe to just concatenate
files).
Yes, slapd logs its PID in most formats so restarts can be detected that way,
but that's considerably harder to search for.
--
You are receiving this mail because:
You are on the CC list for the issue.