https://bugs.openldap.org/show_bug.cgi?id=7080
--- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
RE26 (2.6.10):
• 8d19c205
by Ondřej Kuzník at 2025-02-19T18:06:29+00:00
ITS#7080 Do not munge path twice
• f328965d
by Ondřej Kuzník at 2025-02-19T18:06:33+00:00
ITS#7080 Implement pre/postread for modrdn
• c667f2ea
by Ondřej Kuzník at 2025-02-19T18:15:58+00:00
ITS#7080 Do not reuse back-ldif's stack for controls
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10229
Issue ID: 10229
Summary: ldap_result, when invoked with MSG_RECEIVED and a
timeout value set to 0 (polling), does not return all
available messages until it is called again
Product: OpenLDAP
Version: 2.6.8
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: libraries
Assignee: bugs(a)openldap.org
Reporter: nivanova(a)symas.com
Target Milestone: ---
The issue is noticeable when ldap_result is used by the proxy back-ends. It has
not affected back-meta behavior, because when a first call is unsuccessful, it
retries with a small timeout. back-asyncmeta will also usually call it twice on
the same connection from different threads, although this is not a desired
behavior.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10288
Issue ID: 10288
Summary: autoca Attribute olcAutoCAserverClass
Product: OpenLDAP
Version: 2.6.9
Hardware: All
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: stefan(a)kania-online.de
Target Milestone: ---
I try to add the autoca overlay with the following ldif:
--------------
dn: olcOverlay=autoca,olcDatabase={2}mdb,cn=config
objectClass: olcAutoCAConfig
objectClass: olcOverlayConfig
olcOverlay: autoca
olcAutoCADays: 3652
olcAutoCAKeybits: 4096
olcAutoCAserverClass: ipHost
olcAutoCAserverDays: 1826
olcAutoCAserverKeybits: 4096
olcAutoCAuserClass: person
olcAutoCAuserDays: 365
olcAutoCAuserKeybits: 4096
--------------
ldapadd gives me:
adding new entry "olcOverlay=autoca,olcDatabase={2}mdb,cn=config"
ldap_add: Other (e.g., implementation specific) error (80)
additional info: <olcAutoCAserverClass> handler exited with 1
If I remove the attribute from my ldif, it works.
What is wrong with the olcAutoCAserverClass attribute in my ldif? I try to look
it up in the admin handbook but I could not find anything. I looked in the
source code and found:
------------
{ "serverClass", "objectclass", 2, 2, 0,
ARG_STRING|ARG_MAGIC|ACA_SRVCLASS, autoca_cf,
"( OLcfgOvAt:22.2 NAME 'olcAutoCAserverClass' "
"DESC 'ObjectClass of server entries' "
"EQUALITY caseIgnoreMatch "
"SYNTAX OMsDirectoryString SINGLE-VALUE )", NULL, NULL },
------------
For me it looks the same as the attribute olcAutoCAuserclass.
-------------
{ "userClass", "objectclass", 2, 2, 0,
ARG_STRING|ARG_MAGIC|ACA_USRCLASS, autoca_cf,
"( OLcfgOvAt:22.1 NAME 'olcAutoCAuserClass' "
"DESC 'ObjectClass of user entries' "
"EQUALITY caseIgnoreMatch "
"SYNTAX OMsDirectoryString SINGLE-VALUE )", NULL, NULL },
-------------
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10226
Issue ID: 10226
Summary: [PATCH] ldap.conf: some remarks and editorial fixes
for this man page
Product: OpenLDAP
Version: unspecified
Hardware: x86_64
OS: Linux
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: documentation
Assignee: bugs(a)openldap.org
Reporter: bjarniig(a)vortex.is
Target Milestone: ---
Created attachment 1020
--> https://bugs.openldap.org/attachment.cgi?id=1020&action=edit
Remarks and editotiral fixes for the manual ldap.conf.5
Version 2.6.8 is not named on the webpage when entering an issue.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7249
Quanah Gibson-Mount <quanah(a)openldap.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|IN_PROGRESS |RESOLVED
Resolution|--- |TEST
--- Comment #22 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
head:
• 993f488e
by Ondřej Kuzník at 2025-02-19T17:29:04+00:00
ITS#7249 Let backend_attribute know who's calling it
• f2cba910
by Ondřej Kuzník at 2025-02-19T17:29:04+00:00
ITS#7249 Disallow memberof-addcheck when memberof is global
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10296
Issue ID: 10296
Summary: Force a Mac OS full flush
Product: LMDB
Version: unspecified
Hardware: All
OS: Mac OS
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: liblmdb
Assignee: bugs(a)openldap.org
Reporter: renault.cle(a)gmail.com
Target Milestone: ---
Created attachment 1045
--> https://bugs.openldap.org/attachment.cgi?id=1045&action=edit
Use a F_FULLFSYNC fcntl when committing on Mac OS
Hello Howard and Happy New Year,
As discussed in this issue [1], the LMDB durability is incorrect when
committing. I propose the following patch that uses fcntl with the F_FULLFSYNC
flag. The fcntl documentation is on this page [2].
Note that I kept the calls to msync/fsync for simplicity and because they don't
cost much but feel free to skip them on Mac OS.
Have a nice day,
kero
[1]: https://github.com/cberner/redb/pull/928#issuecomment-2567032808
[2]:
https://developer.apple.com/library/archive/documentation/System/Conceptual…
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=10160
Issue ID: 10160
Summary: Add negset and negurl for slapo-constraint
Product: OpenLDAP
Version: 2.6.6
Hardware: All
OS: All
Status: UNCONFIRMED
Keywords: needs_review
Severity: normal
Priority: ---
Component: overlays
Assignee: bugs(a)openldap.org
Reporter: manu(a)netbsd.org
Target Milestone: ---
Created attachment 1003
--> https://bugs.openldap.org/attachment.cgi?id=1003&action=edit
Add negset and negurl for slapo-constraint
Add negset and negurl constraints for slapo-constraint. THe two new types are
logical not of set and url. They will fire a constraint violation if the set or
LDAP URL query is non empty.
--
You are receiving this mail because:
You are on the CC list for the issue.
https://bugs.openldap.org/show_bug.cgi?id=7080
--- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> ---
• 86d23423
by Ondřej Kuzník at 2024-12-16T17:01:26+00:00
ITS#7080 Do not munge path twice
• e5826622
by Ondřej Kuzník at 2024-12-16T17:01:26+00:00
ITS#7080 Implement pre/postread for modrdn
• 70d8e22d
by Ondřej Kuzník at 2024-12-16T17:01:26+00:00
ITS#7080 Do not reuse back-ldif's stack for controls
--
You are receiving this mail because:
You are on the CC list for the issue.
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.