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=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=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.
https://bugs.openldap.org/show_bug.cgi?id=9564
Issue ID: 9564
Summary: Race condition with freeing the spilled pages from
transaction
Product: LMDB
Version: 0.9.29
Hardware: Other
OS: Mac OS
Status: UNCONFIRMED
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: kriszyp(a)gmail.com
Target Milestone: ---
Created attachment 825
--> https://bugs.openldap.org/attachment.cgi?id=825&action=edit
Free the spilled pages and dirty overflows before unlocking the write mutex
The spilled pages (a transaction's mt_spill_pgs) is freed *after* a write
transaction's mutex is unlocked (in mdb.master3). This can result in a race
condition where a second transaction can start and subsequently assign a new
mt_spill_pgs list to the transaction structure that it reuses. If this occurs
after the first transaction unlocks the mutex, but before it performs the free
operation on mt_spill_pgs, then the first transaction will end up calling a
free on the same spilled page list as the second transaction, resulting in a
double free (and crash).
It would seem to be an extremely unlikely scenario to actually happen, since
the free call is literally the next operation after the mutex is unlocked, and
the second transaction would need to make it all the way to the point of saving
the freelist before a page spill list is likely to be allocated. Consequently,
this probably has rarely happened. However, one of our users (see
https://github.com/DoctorEvidence/lmdb-store/issues/48 for the discussion) has
noticed this occurring, and it seems that it may be particularly likely to
happen on MacOS on the new M1 silicon. Perhaps there is some peculiarity to how
the threads are more likely to yield execution after a mutex unlock, I am not
sure. I was able to reproduce the issue by intentionally manipulating the
timing (sleeping before the free) to verify that the race condition is
technically feasible, and apparently this can happen "in the wild" on MacOS, at
least with an M1.
It is also worth noting that this is due to (or a regression from) the fix for
ITS#9155
(https://github.com/LMDB/lmdb/commit/cb256f409bb53efeda4ac69ee8165a0b4fc1a277)
where the free call was moved outside the conditional (for having a parent)
that had previously never been executed after the mutex is unlocked, but now is
called after the unlock.
Anyway, the solution is relatively simple, the free call simply has to be moved
above the unlock. In my patch, I also moved the free call for mt_dirty_ovs. I
am not sure what OVERFLOW_NOTYET/mt_dirty_ovs is for, but presumably it should
be handled the same. This could alternately be solved by saving the reference
to these lists before unlocking, and freeing after unlocking, which would
slightly decrease the amount of processing within the mutex guarded code. Let
me know if you prefer a patch that does that.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10092
Issue ID: 10092
Summary: Local logging doesn't build on Windows
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
slapd/logging.c uses writev() to write a prefix and the log message together in
one call. This feature doesn't exist on Windows. The closest equivalent,
WriteFileGather, only works on page sized and aligned writes. On Windows the
only way to write as desired is to copy the message into a new buffer first.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10140
Issue ID: 10140
Summary: Add microsecond timestamp format for local file
logging
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: gnoe(a)symas.com
Target Milestone: ---
Add microsecond-level timestamps to local file logging.
Format is:
"YYYY-mm-ddTHH:MM:SS.ffffffZ"
The attached patch file is derived from OpenLDAP Software. All of the
modifications to OpenLDAP Software represented in the following patch(es) were
developed by Gregory Noe gnoe(a)symas.com. I have not assigned rights and/or
interest in this work to any party.
The attached modifications to OpenLDAP Software are subject to the following
notice:
Copyright 2023 Gregory Noe
Redistribution and use in source and binary forms, with or without
modification, are permitted only as authorized by the OpenLDAP Public License.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9849
Issue ID: 9849
Summary: Update website to support LTS and Feature releases
Product: website
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: website
Assignee: bugs(a)openldap.org
Reporter: mnormann(a)symas.com
Target Milestone: ---
Modify .wlmrc variable names and website content to handle both Feature Release
and Long Term Support release.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10020
Issue ID: 10020
Summary: dynlist's @groupOfUniqueNames is considered only for
the first configuration line
Product: OpenLDAP
Version: 2.5.13
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: msl(a)touk.pl
Target Milestone: ---
If we consider the following configuration of dynlist:
{0}toukPerson labeledURI uniqueMember+memberOf@groupOfUniqueNames
{1}groupOfURLs memberURL uniqueMember+dgMemberOf@groupOfUniqueNames
The {0} entry will correctly populate the memberOf relatively to static group
membership.
The {1} entry will produce dgMemberOf with dynamic group membership correctly
(based on memberURL query) but it will not populate static entries IF {0} entry
in configuration is present. IF I remove {0} from the dynlist configuration -
or - remove @groupOfUniqueNames part from this configuration line, then both
dynamic and static entries will be populated correctly for {1}.
So the effects are as follows on some user entry:
if both {0} and {1} are present - {1} produced only dynamic groups:
memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl
if both {0} and {1} are present and @groupOfUniqueNames is removed from {0} -
{1} produced static+dynamic groups:
dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl
If only {1} is present - {1} produced static+dynamic groups:
dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl
For completness - if only {0} is present:
memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
I would expect this behavior to be correct for the first case - {0} and {1}.
memberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
memberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=dyntouk,ou=dyntest,ou=group,dc=touk,dc=pl
dgMemberOf: cn=adm,ou=touk,ou=group,dc=touk,dc=pl
dgMemberOf: cn=touk,ou=touk,ou=group,dc=touk,dc=pl
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=9934
Issue ID: 9934
Summary: slapd-config(5) should document how to store
certificates for slapd usage
Product: OpenLDAP
Version: 2.5.13
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: ---
Commit 7b41feed83b expanded the ability of cn=config to save the certificates
used for TLS by slapd directly in the config database. However the
documentation for the new parameters was never added to the slapd-config(5) man
page.
olcTLSCACertificate $ olcTLSCertificate $ olcTLSCertificateKey
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10056
Issue ID: 10056
Summary: test069-delta-multiprovider-starttls failures on
static builds
Product: OpenLDAP
Version: 2.6.4
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: kaction(a)disroot.org
Target Milestone: ---
Hello.
I am getting following test error when trying to build `openldap` statically:
```
[nix-shell:/tmp/openldap-static/openldap-2.6.4/tests]$ ./run
test069-delta-multiprovider-starttls
Cleaning up test run directory leftover from previous run.
Running ./scripts/test069-delta-multiprovider-starttls for mdb...
running defines.sh
Initializing server configurations...
Starting server 1 on TCP/IP port 9011...
Using ldapsearch to check that server 1 is running...
Waiting 5 seconds for slapd to start...
Using ldapadd for context on server 1...
Starting server 2 on TCP/IP port 9012...
Using ldapsearch to check that server 2 is running...
Waiting 5 seconds for slapd to start...
Using ldapadd to populate server 1...
Waiting 7 seconds for syncrepl to receive changes...
Using ldapsearch to read all the entries from server 1...
Using ldapsearch to read all the entries from server 2...
Comparing retrieved entries from server 1 and server 2...
Using ldapadd to populate server 2...
Using ldapsearch to read all the entries from server 1...
Using ldapsearch to read all the entries from server 2...
Comparing retrieved entries from server 1 and server 2...
Breaking replication between server 1 and 2...
Using ldapmodify to force conflicts between server 1 and 2...
Restoring replication between server 1 and 2...
Waiting 7 seconds for syncrepl to receive changes...
Using ldapsearch to read all the entries from server 1...
Using ldapsearch to read all the entries from server 2...
Comparing retrieved entries from server 1 and server 2...
test failed - server 1 and server 2 databases differ (561)
```
I added line number (561) into error message to pinpoint it more precisely.
And here is difference between databases:
```
--- /tmp/openldap-static/openldap-2.6.4/tests/testrun/server1.flt
2023-05-23 22:53:51.000965129 -0400
+++ /tmp/openldap-static/openldap-2.6.4/tests/testrun/server2.flt
2023-05-23 22:53:51.005965136 -0400
@@ -289,13 +289,10 @@
userPassword:: amFq
dn: cn=James A Jones 2,ou=Alumni Association,ou=People,dc=example,dc=com
-carLicense: 123-XYZ
cn: James A Jones 2
cn: James Jones
cn: Jim Jones
-description: Amazing
description: Bizarre
-description: Mindboggling
description: Stupendous
employeeNumber: 64
employeeType: deadwood
@@ -307,7 +304,7 @@
pager: +1 313 555 3923
postalAddress: Alumni Association $ 111 Maple St $ Anytown, MI 48109
seeAlso: cn=All Staff,ou=Groups,dc=example,dc=com
-sn: Surname
+sn: Jones
telephoneNumber: +1 313 555 0895
title: Mad Cow Researcher, UM Alumni Association
uid: jaj
```
Suggestions on what more information I can provide are welcome. You can also
try to build `pkgsStatic.openldap` in this nixpkgs
[commit](f9e32f61282275eb5fa9064e08bbd0a92d1187de)
--
You are receiving this mail because:
You are on the CC list for the issue.