https://bugs.openldap.org/show_bug.cgi?id=10097
Issue ID: 10097
Summary: slapi didn't build on Windows
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: Windows
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: hyc(a)openldap.org
Target Milestone: ---
Apparently no one has ever tried to use SLAPI on Windows, since it has been
broken ever since the initial commit in 2002.
Fixed now in master, in
3489931553a684ab388b29dde0b8b2cf6cf63e79 and
a7bd0416c80bcb954001c1b39512fb97f6c4b4ac
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10093
Issue ID: 10093
Summary: Unclear licenses in certain places
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: thegeorg(a)yandex-team.com
Target Milestone: ---
We use scancode-toolkit in order to perform automatic license analysis.
At the time, this toolkit reports certain places with unclear license status.
In particular, libraries/libldap/modrdn.c (lines 19 to 24) bear the following
notice:
```
/* Copyright 1999, Juan C. Gomez, All rights reserved.
* This software is not subject to any license of Silicon Graphics
* Inc. or Purdue University.
*
* Redistribution and use in source and binary forms are permitted
* without restriction or fee of any kind as long as this notice
* is preserved.
*/
```
While copyright notice is completely fine, the second part can not be
recognised as any SPDX acknowledged license.
Is it possible to unify the text across other parts of OpenLDAP?
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10058
Issue ID: 10058
Summary: destroying robust mutexes leads to use of an
uninitialized mutex
Product: LMDB
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: jiri.novosad(a)gmail.com
Target Milestone: ---
Created attachment 966
--> https://bugs.openldap.org/attachment.cgi?id=966&action=edit
an example program to reproduce the bug
This is a regression introduced in
https://bugs.openldap.org/show_bug.cgi?id=9278 .
The issue is that mdb_env_setup_locks initializes the mutex only when it gets
an exclusive fcntl file lock. But there is this possible order of operations:
1. Process A opens the DB, gets an exclusive file lock, initializes the mutex,
downgrades the file lock to shared and does its thing
2. Process A closes the env: it gets an exclusive lock and destroys the mutex
3. Process B opens the DB and blocks in mdb_env_excl_lock trying to get the
shared lock
4. Process A finishes closing the env, closes the file descriptor and loses the
file lock
5. Process B gets the shared lock, does not initialize the mutex in
mdb_env_setup_locks (because it does not have the exclusive lock)
6. Process B tries to lock the mutex, but it is not initialized,
pthread_mutex_lock returns EINVAL
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=6166
OndÅ™ej KuznÃk <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=10080
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7226
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net
Target Milestone|--- |2.7.0
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7226
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|olcAuditlogFile At dos not |olcAuditlogFile should be
|accept multiple values |single valued, but accepts
| |multiple values (additional
| |values ignored)
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7226
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|VERIFIED |CONFIRMED
Resolution|FEEDBACK |---
--- Comment #17 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
Root problem of this being treated as single value, but accepting multiple
values (additional values are ignored) has never been addressed, which was the
original bug report here. The matching rule issue was already fixed.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10086
Issue ID: 10086
Summary: test059 does not set up valid cn=config replication
Product: OpenLDAP
Version: 2.6.4
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: test suite
Assignee: bugs(a)openldap.org
Reporter: quanah(a)openldap.org
Target Milestone: ---
For cn=config replication to be valid, the entryUUIDs must match throughout the
config database. However, this is not the case when test059 executes. The
entryUUID for 'dn: cn=config' differs between the two.
Example:
quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID:
cfcon.d/cn\=config.ldif
entryUUID: aea058c4-bf6e-103d-9e18-4582986e9372
quanah@apito1:~/git/quanah/openldap-scratch/tests/testrun$ grep entryUUID:
db.1.a/cn\=config\,cn\=consumer.ldif
entryUUID: ae9bd858-bf6e-103d-871e-5daccf782d22
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10090
Issue ID: 10090
Summary: regex that contains a quoted literal space or escaped
space results in a parse error
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: gburd(a)symas.com
Target Milestone: ---
Searching ACLs using regex expressions should allow for white space.
olcAccess: to dn.subtree="dc=example,dc=com" by dn.regex="ou=Before\
After,o=example[.]com,c=US$" read by * break
or
olcAccess: to dn.subtree="dc=example,dc=com" by dn.regex="ou=Before[
]After,o=example[.]com,c=US$" read by * break
or any regex that contains a literal space results in a parse error.
It seems like the string is broken on literal spaces irrespective of quoting.
Debug output from slapd:
64cd845c.253aa590 0x7fe6f4fc9640 slapd: line 0: regular expression "ou=Before\"
bad because of Trailing backslash
This should also include other methods for expressing white space such as
`:space:` or `\w` pattern matches.
olcAccess: to dn.subtree="dc=example,dc=com" by
dn.regex="ou=Before[[:space:]]After,o=example[.]com,c=US$" read by * break
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10073
Issue ID: 10073
Summary: database monitor | slapd fails to start when "database
ldap" without suffix exists
Product: OpenLDAP
Version: 2.5.14
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: cyusedfzfb(a)gmail.com
Target Milestone: ---
As requested on the mailinglist, I am filing an issue for this behaviour:
Today setup the cn=Monitor backend, and after doing so, openldap failed to
start with:
backend_startup_one (type=monitor, suffix="cn=Monitor"): bi_db_open failed!
(-1)
The reason turned out to be: we had configured one of our databases ("database
ldap") without a suffix.
After I added a suffix, openldap started, and cn=Monitor worked as expected.
It would be nice if this error message could become a little bit more specific.
:-)
Also: we've had the "database ldap" without a suffix in production working for
many years. Perhaps cn=Monitor should be able to deal with that config as
well..?
--
You are receiving this mail because:
You are on the CC list for the issue.