https://bugs.openldap.org/show_bug.cgi?id=10294
Issue ID: 10294
Summary: Overlay seems to load before schema in folder
configuration mode
Product: OpenLDAP
Version: 2.6.8
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: slapd
Assignee: bugs(a)openldap.org
Reporter: pduvax(a)gmail.com
Target Milestone: ---
In the folder configuration (vs slapd.conf file), the modules seem to be loaded
before schema folders files.
This makes troubles with memberOf attributeType which is created by the dynlist
overlay if missing (cf. the base function "dynlist_initialize" which starts by
doing this). As the schema files are not yet loaded, it creates systematically
the attributes which then prohibits the load of msuser.ldif schema without
raising the error "Duplicate attributeType".
I found a workaround by naming the entry of the dynlist overlay olcModuleList
cn=z-module{X} while z is alphanumerically after cn=schema. But as it is
hazardous, I think that the best way is to load modules after the schema by the
code.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10306
Issue ID: 10306
Summary: epoll, kqueue etc. are not used when cross compiling
Product: OpenLDAP
Version: 2.6.9
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: build
Assignee: bugs(a)openldap.org
Reporter: hi(a)alyssa.is
Target Milestone: ---
OpenLDAP's build system relies on running test programs to see whether epoll or
kqueue are available, after checking the headers are available. When cross
compiling, test programs can't be run, and even if they could, they wouldn't
produce useful results because they'd be testing the build machine. Running
test programs like this isn't even a great idea for native builds, because the
package is still quite likely to end up running on a different machine than it
was built for — think about distro packages.
This means that cross-compiled OpenLDAP ends up using select, even though it
could almost certainly use epoll or kqueue.
The best thing to do for this sort of thing is to check at runtime whether the
epoll/kqueue/whatever is available, and fall back if not, but this would
probably be hard to implement in OpenLDAP. Other, easier, things that could be
done to improve the situation would be:
• Assume that epoll/kqueue are available if the headers are. It's very
unlikely nowadays that a system with the headers won't actually have the API
available.
• If the AC_RUN_IFELSE checks are staying, make sure that they're all
overridabel with configure flags or at least AC_CACHE_CHECK.
There are also uses of AC_RUN_IFELSE for pthreads, which presumably have the
same problem.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10308
Issue ID: 10308
Summary: Implement cn=monitor for back-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: ---
Currently back-asyncmeta has no cn=monitor capabilities. It will be useful to
implement some, specifically to monitor targets and target connection states.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10304
Issue ID: 10304
Summary: Unable to remove item from directory as part of
transaction if it is the last item in that directory
Product: OpenLDAP
Version: 2.5.13
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: backends
Assignee: bugs(a)openldap.org
Reporter: sophie.elliott(a)arcticlake.com
Target Milestone: ---
I am running my ldap server on Debian 11.3, with the mdb backend, using the
backported openldap version 2.5.13. I am not 100% certain if this is an issue
with OpenLDAP or liblmdb, but I have been running tests in the repo and it
looks like the liblmdb tests work fine, so I think it's with OpenLDAP itself.
I have been performing a transaction, and deleting entries from a directory
during this transaction. This works fine if the item that I am deleting isn't
the last entry in its directory, but when it is I get a MDB_NOTFOUND error on
the commit transaction call and the delete doesn't go through. Here is an
excerpt of the logs when this happens:
```
67a64334.14e1fc32 0x766ad2a00700 => index_entry_del( 108,
"accessGroupID=f23de82f-3a1c-4f88-86bb-bb07f9a0992d,o=[COMPANY],ou=accessGroups,dc=local,dc=[COMPANY],dc=com"
)
67a64334.14e21912 0x766ad2a00700 mdb_idl_delete_keys: 6c [62d34624]
67a64334.14e22812 0x766ad2a00700 <= index_entry_del( 108,
"accessGroupID=f23de82f-3a1c-4f88-86bb-bb07f9a0992d,o=[COMPANY],ou=accessGroups,dc=local,dc=[COMPANY],dc=com"
) success
67a64334.14e23a91 0x766ad2a00700 mdb_delete: txn_commit failed: MDB_NOTFOUND:
No matching key/data pair found (-30798)
```
Please let me know if I should submit this issue elsewhere, or if this is
something that has already been fixed in a more recent version. I'm also happy
to provide more details if necessary. Thank you!
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10139
Ondřej Kuzník <ondra(a)mistotebe.net> changed:
What |Removed |Added
----------------------------------------------------------------------------
See Also| |https://bugs.openldap.org/s
| |how_bug.cgi?id=10307
--
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.
https://bugs.openldap.org/show_bug.cgi?id=10149
Issue ID: 10149
Summary: [PATCH] Allow certificates and keys to be read from
URIs.
Product: OpenLDAP
Version: unspecified
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: minfrin(a)sharp.fm
Target Milestone: ---
Add the LDAP_OPT_X_TLS_URIS and LDAP_OPT_X_TLS_CACERTURIS
options to allow certificates and keys to be set using OpenSSL
provider URIs.
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 Graham Leggett minfrin(a)sharp.fm. 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 Graham Leggett
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.