- openldap-bugs - openldap.org

[Issue 9829] New: set timeouts in remoteauth overlay
by openldap-its＠openldap.org 14 Nov '23

14 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9829 Issue ID: 9829 Summary: set timeouts in remoteauth overlay Product: OpenLDAP Version: 2.5.11 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- Currently, it seems there is no way to configure timeouts in the remoteauth overlay. For example, if I define a remoteauth_mapping with a file containing a list of hostnames, the first one is checked first. After "remoteauth_retry_count" * "connect_timeout" seconds, (210s on my system), remoteauth test the second server in the list. In some circumstances, it could be nice to set the connect timeout lower (or higher). -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9677] New: Create "make install-strip” target
by openldap-its＠openldap.org 14 Nov '23

14 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9677 Issue ID: 9677 Summary: Create "make install-strip” target Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- All open source make-based projects shall follow the same naming and semantics of targets, described at https://www.gnu.org/prep/standards/html_node/Standard-Targets.html . In particular “make install-strip” shall strip the binaries during the installation, while “make install” shall not strip them. In openldap currently “make install” does strip, which surprised me. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 10128] New: Unavailability of OpenSSL 3.X compatible openldap lib libldap_r.so
by openldap-its＠openldap.org 14 Nov '23

14 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10128 Issue ID: 10128 Summary: Unavailability of OpenSSL 3.X compatible openldap lib libldap_r.so Product: OpenLDAP Version: 2.6.0 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: umakanta.senapati(a)netwitness.com Target Milestone: --- Hi Team, We are looking for openldap lib libldap_r.so compatible with openssl 3.x for el8 platform. From the release note i could check Open ldap has added openSSL 3.X support from version 2.5X onwards. But we couldn’t find any open ldap el8 rpm available with OpenSSL3.X support for 2.5.x or higher version. Please correct me if my understanding is wrong. Is there any plan to provide open ldap el8 rpm with libldap_r.so compatible with Openssl 3.X. Please help me if i can build the open ldap libldap_r.so with opensll 3.x lib or not? If yes please share the guide lines for the same. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10099] New: OpenLDAP version 2.5 & 2.6 causes IP connectivity to break and breaks basic commands like reboot
by openldap-its＠openldap.org 09 Nov '23

09 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10099 Issue ID: 10099 Summary: OpenLDAP version 2.5 & 2.6 causes IP connectivity to break and breaks basic commands like reboot Product: OpenLDAP Version: 2.5.16 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: amcwongahey(a)rbbn.com Target Milestone: --- Created attachment 980 --> https://bugs.openldap.org/attachment.cgi?id=980&action=edit The package Makefile I am upgrading openLDAP from version 2.4.59 to 2.5.16 and am running into show stopper issues. In my environment I am running CLIENT mode only (libldap). I have tried 2.5.16 with the following combinations: openSSL version 1.1.1s and 3.0.8 Kernel versions: 5.4.92, 4.19.192 and 2.6.32 Problems described below ONLY happens when connecting with a domain controller using LDAPS - does NOT happen with LDAP (non-secure). When I use ANY combination that includes kernel version 4 or 5 along with openLDAP 2.5.16 I get random lockups to the point where IP connectivity breaks into and out of the node. And also it is so completely hosed that even issuing a reboot command from the console completely hangs and does not restart the node. The problem happens roughly 50% of the time with openLDAP combined with version 5 kernel but happens noticeably less frequently with the version 4 kernel. As soon as I kill the process that invokes the connection with openLDAP the problem clears up. I invoke the connection with the following function call: nReturnCode = ldap_sasl_bind( m_pLD, m_ADBind.GetBindDN(), LDAP_SASL_SIMPLE, &stPassword, NULL, NULL, &nMsgID); I use simple auth simply because the entire connection is secured with TLS anyway and there is another functional reason which I cannot go into details on. OpenLDAP never returns from the ldap_sasl_bind function call. It hangs somewhere inside the library but that alone cannot account for the complete lockup where basic commands like reboot, etc do not work and where all IP connectivity breaks. It seems it has to be something with openLDAP and the Linux kernel combined that triggers this issue. I am hoping that someone who is much more familiar with the libldap part of the library will pick up on this and be able to determine how to fix this. As an FYI: I also tried the very first version of 2.5.1 (alpha release) and the latest 2.6 and the problem happens on those versions as well. To be clear the problem does NOT happen if I run openLDAP 2.5.16 with Linux kernel version 2.6.32. ADDITIONALLY ALL openSSL & kernel combinations works with openLDAP version 2.4.59! I am attaching the package Makefile to this report. Below is the ldap.conf contents: TLS_REQCERT never TLS_KEY /tmp/ssl/certs/server.pem TLS_CERT /tmp/ssl/certs/server.pem TLS_PROTOCOL_MIN 3.1 sasl_secprops maxssf=0 -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9009] 2.7: Switch to LMDB v1.0
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9009 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |db_reload -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9612] New: Change index_hash64 default to on
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9612 Issue ID: 9612 Summary: Change index_hash64 default to on Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Change the default value of index_hash64. By default this means slapd won't run on a 32-bit CPU (It will continue to work on 32-bit OSes running on 64-bit CPUs). If someone needs to run slapd on a 32-bit CPU they can turn this option off. In the documentation, mark the option as deprecated for eventual removal in a future release. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9580] New: Refresh vs. accesslog in delta-MPR
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9580 Issue ID: 9580 Summary: Refresh vs. accesslog in delta-MPR Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: replication Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- A server consuming a plain syncrepl session (might be a delta-MMR refresh) still has to log the entries into accesslog, however that accesslog stops being capable of serving as a delta-sync source: - operation entryCSNs will be out-of-order - the changes logged will not be the intended modifications (e.g. if we fell back after a conflict, the conflicting entry will be replaced with the other version, other examples available) We need to deal with that somehow, at the very least we need to make sure the consumer will not take them at face value. We could record this in the accesslog root entry if we can detect when this starts and match it up with the final cookie, syncprov would still need some tweaks to understand it. We could mark the entries received this way and make sure delta-consumers treat them as "poison", as if they were running a plain syncrepl session themselves (not update contextCSN until that's finished, mark its own accesslog entries this way, ...). Anything like that needs guarantees that it will clean itself up once all of the real plain sessions finish otherwise we've lost delta-sync altogether. A different approach might or might not be needed for live delta-persist sessions replicating from a refreshing provider, but at least that syncprov has a way of detecting this live if it chooses to. -- You are receiving this mail because: You are on the CC list for the issue.

1 13

[Issue 9341] New: Delta-sync MPR needs to be stable regardless of ordering
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9341 Issue ID: 9341 Summary: Delta-sync MPR needs to be stable regardless of ordering Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: replication Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- If two or more updates are spread across several providers before they have a chance to learn about the others, all replicas need to arrive at the same content regardless of the order in which they arrive. One example that is broken at the moment: - (csn a) server 1 accepts a modify - (csn b) server 2 accepts a delete on the same DN - (csn c) server 2 accepts an add on that DN again If a replica receives the actions in the order bca vs. abc, the content of the entry will be different even though the final CSN set is the same -> they will never converge. The ordering 'bac' also needs to result in eventual convergence, even if it means a refresh or replication from either provider stalling temporarily? Merge request with this test case (so far): https://git.openldap.org/openldap/openldap/-/merge_requests/145 -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 9577] New: slapd -V should be deprecated
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9577 Issue ID: 9577 Summary: slapd -V should be deprecated Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Sometimes a user's (present one included) ignorance gets them in trouble unnecessarily. The -V option is an example... Normally, when one wants to determine the version of a process, they use -V, or perhaps -v. With slapd, the daemon actually continues to run, which can have negative consequences. The doc clearly states that -VV is probably what the user wants, but is counter-intutive. Who RTFM's before checking the version? -V print version info (-VV exit afterwards, -VVV print info about static overlays and backends) I propose we eliminate the option to allow slapd to continue running after displaying the version. Perhaps we eliminate the -V option entirely, or just make it work the same as -VV. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9547] New: OpenLDAP does not send port as SPN when authenticating SASL GSSAPI
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9547 Issue ID: 9547 Summary: OpenLDAP does not send port as SPN when authenticating SASL GSSAPI Product: OpenLDAP Version: 2.4.44 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: robert.wilson1717(a)gmail.com Target Milestone: --- When trying to authenticate to an ADLDS server using kerberos and a MIT ccache, OpenLdap only passes the hostname to the SASL mechanism, causing a mismatch between the SPN in the client "ldap/adlds.my.domain" and the one registered in AD "ldap/adlds.my.domain:50000" Is there a way fo forcing OpenLDAP to pass the port as part of the SASL request? Or is there a part of the OpenLDAP -> Cyprus-SASL -> MIT KRB5 chain where this can be enabled? -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9506] New: dynlist: member expansion when member attribute not requested
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9506 Issue ID: 9506 Summary: dynlist: member expansion when member attribute not requested Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- When configured to do dynamic "member" expansion, i.e.: overlay dynlist dynlist-attrset groupOfURLs memberURL member Any query against an object that would trigger this expansion will incur a penalty while dynlist does the expansion work even if there was no request for the member attribute. Currently that can be worked around by specifying the manageDSAit control when doing a search on the object, but this may not be feasible for some client applications and additionally other directory servers do not do this expansion for their dynamic group implementations unless the underlying configured attribute is explicitly requested. We've already implemented this in dynlist for the memberOfAD case, we should do it here as well. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9269] New: "hidden" "subordinate" database is shown in a directory tree
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9269 Issue ID: 9269 Summary: "hidden" "subordinate" database is shown in a directory tree Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: grapvar(a)gmail.com Target Milestone: --- "hidden" configuration option is ignored by slapd (not honored by "glue" overlay?) if the database it tries to hide is also a "subordinate" database. Checked for openldap 2.4.47 and current git master (f3952d9). -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Bug 9244] New: API calls blocking after async connect
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9244 Bug ID: 9244 Summary: API calls blocking after async connect Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- Created attachment 721 --> https://bugs.openldap.org/attachment.cgi?id=721&action=edit async connect test without TLS My understanding of LDAP_OPT_CONNECT_ASYNC is that the attached program should not block. If the connection does not establish fast enough, the bind call is supposed to return LDAP_X_CONNECTING. (At least that's how I understand it, based on the original behaviour (circa 2.4.23 up to 2.4.40) as well as the bind loop in back-meta. On the other hand, the man page does "Subsequent calls to library routines will poll for completion of the connect before performing further operations" which might be interpreted as meaning they would block...) In current releases it does block, as demonstrated by strace on Linux (latency added using 'tc qdisc'): [...] connect(3, {sa_family=AF_INET, sin_port=htons(389), sin_addr=inet_addr("192.168.1.204")}, 16) = -1 EINPROGRESS (Operation now in progress) write(3, "0\f\2\1\1`\7\2\1\3\4\0\200\0", 14) = -1 EAGAIN (Resource temporarily unavailable) poll([{fd=3, events=POLLOUT|POLLERR|POLLHUP}], 1, -1) = 1 ([{fd=3, revents=POLLOUT}]) write(3, "0\f\2\1\1`\7\2\1\3\4\0\200\0", 14) = 14 poll([{fd=3, events=POLLIN|POLLPRI}], 1, -1) = 1 ([{fd=3, revents=POLLIN}]) read(3, "0\f\2\1\1a\7\n", 8) = 8 read(3, "\1\0\4\0\4\0", 6) = 6 write(2, "OK: ldap_simple_bind_returned 0 "..., 42OK: ldap_simple_bind_returned 0 (Success) ) = 42 [...] As discussed in IRC, I believe I bisected this down to commit ae6347bac, from bug 8022. The reasoning is sound, but ldap_int_open_connection does not actually return -2, only -1 or 0. The patch is simple enough, but I'm also looking at some later commits that were probably done to work around this, and might not be needed now (bug 8957, bug 8968, bug 8980). Also need to test all setups thoroughly (ldap, ldaps, STARTTLS, not to mention back-meta/asyncmeta). I also notice that LDAP_OPT_CONNECT_ASYNC is not effective unless LDAP_OPT_NETWORK_TIMEOUT is also set. It might be intentional, but the man page doesn't mention this specifically, and I don't see why it would be necessary... -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Issue 8957] Handling of TLS in async mode
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8957 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9244 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8968] Async connect mode does not work on Solaris
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8968 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9244 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8980] Async mode and TLS Non-Blocking Issue
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8980 Ondřej Kuzník <ondra(a)mistotebe.net> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=9244 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Bug 9229] New: Make liblutil usable by libldap
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9229 Bug ID: 9229 Summary: Make liblutil usable by libldap Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- liblutil is a static library (non-PIC) and so cannot be linked into shared objects, however we have several use cases for reusing its code in libldap. Some options: - moving more code from liblutil to libldap - just merge the whole thing? - are there components that link liblutil but _not_ libldap? - build liblutil as PIC (take a minor performance hit when linked into programs?) - build liblutil twice (liblutil.a and liblutil_pic.a) - symlink liblutil sources into libldap build dir, like libldap_r does with libldap - both of these last options require checking whether executables can call the PIC symbols safely (if some symbols are used by both library and program code) Nice-to-have for 2.5, I'd say more likely for 2.6 at this point. -- You are receiving this mail because: You are on the CC list for the bug.

1 10

[Issue 9009] 2.7: Switch to LMDB v1.0
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9009 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |9225 Referenced Issues: https://bugs.openldap.org/show_bug.cgi?id=9225 [Issue 9225] back-mdb: Add support for PREPARE/2-phase commit -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Bug 9221] New: Move all replication consumer code into its own overlay
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9221 Bug ID: 9221 Summary: Move all replication consumer code into its own overlay Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- (In relation to a discussion about slapo-chain) <hyc> anyway, the nicer ting to fix would be in 2.5, push all of the repl consumer code into its own overlay <hyc> in that case, updateref would be processed wherever the overlay was configured <hyc> so no longer tied to the frontend <hyc> it would also make it more feasible to have multiple different consumer configs in a single DB, each with their own provider URL (and thus their own updateref) <hyc> I would think we can get rid of the update ref directive entirely, just point all writes to that consumer's provider. -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 9218] New: Revist entry_release handling in slapo-pache, slapo-translucent
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9218 Bug ID: 9218 Summary: Revist entry_release handling in slapo-pache, slapo-translucent Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- From a past discussion with hyc on 2.5 items: [13:57] <hyc> there's a nagging problem though, pcache's entry_release function needs to distinguish between its backend actually freeing the entry, or being a no-op [13:57] <hyc> so it can decide whether to return success or continue [13:58] <hyc> the patch to translucent sidesteps the question, by avoiding other overlays [13:58] <hyc> but we need to revisit this in 2.5 -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Bug 9217] New: Audit all schema definitions to have official non-experimental OIDs where possible
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9217 Bug ID: 9217 Summary: Audit all schema definitions to have official non-experimental OIDs where possible 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: --- From a past discussion with hyc on 2.5 requirements: [09:27] <hyc> we also need to audit all of these schema defs [09:27] <hyc> we're supposed to have official, non-experimental OIDs for released schema [09:28] <hyc> accesslog is still using 666, experimental arc [09:29] <hyc> I think this means we should polish up the logschema draft, Informational status, and publish it again as final -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 9216] New: Port autoca to gnutls
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=9216 Bug ID: 9216 Summary: Port autoca to gnutls Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- For 2.5, support building and running the autoca overlay with GnuTLS. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Issue 10126] New: Openldap 2.5.16 Segmentation fault during start
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10126 Issue ID: 10126 Summary: Openldap 2.5.16 Segmentation fault during start Product: OpenLDAP Version: 2.5.16 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: bogdan.siara(a)gmail.com Target Milestone: --- Created attachment 987 --> https://bugs.openldap.org/attachment.cgi?id=987&action=edit gdb stacktrace Hi, I have openldap cluster with 2 nodes. Openldap is compiled in docker debian:bookworm-slim with options: ./configure --prefix=${LDAP_HOME}/openldap \ --enable-debug \ --enable-dynamic \ --enable-syslog \ --enable-ipv6 \ --enable-local \ --enable-slapd \ --enable-dynacl \ --enable-cleartext \ --enable-crypt \ --enable-spasswd \ --enable-modules \ --enable-slapi \ --enable-wrappers \ --enable-dnssrv=mod \ --enable-ldap=mod \ --enable-mdb=mod \ --enable-meta=mod \ --enable-asyncmeta=mod \ --enable-relay=mod \ --enable-overlays=mod \ --enable-argon2=yes \ --enable-balancer=mod \ --with-cyrus-sasl \ --with-threads \ --with-argon2=auto \ --without-systemd \ --with-tls=openssl make depend make make install cd contrib/slapd-modules/smbk5pwd sed -i "s|prefix=/usr/local|prefix=${LDAP_HOME}/openldap|g" Makefile sed -i "s|SSL_LIB = -lcrypto|SSL_LIB = -lnettle|g" Makefile sed -i "s|HEIMDAL_INC = -I/usr/heimdal/include|HEIMDAL_INC = \$(shell krb5-config.heimdal --cflags krb5 kadm-server)|g" Makefile sed -i "s|HEIMDAL_LIB = -L/usr/heimdal/lib -lkrb5 -lkadm5srv|HEIMDAL_LIB = \$(shell krb5-config.heimdal --libs krb5 kadm-server)|g" Makefile sed -i "s|LIBS = \$(LDAP_LIB) \$(HEIMDAL_LIB) \$(SSL_LIB)|LIBS = \$(HEIMDAL_LIB) \$(LDAP_LIB) \$(SSL_LIB)|g" Makefile make make install cd ../passwd/pbkdf2 sed -i "s|prefix=/usr/local|prefix=${LDAP_HOME}/openldap|g" Makefile sed -i "s|SSL_LIB = -lcrypto|SSL_LIB = -lnettle|g" Makefile make make install cd ../sha2 sed -i "s|prefix=/usr/local|prefix=${LDAP_HOME}/openldap|g" Makefile make make install cd ../../ppm sed -i "s|prefix=/usr/local|prefix=${LDAP_HOME}/openldap|g" Makefile make make install When I start openldap: slapd -h 'ldap://0.0.0.0:10389 ldaps://0.0.0.0:10536 ldapi://%2Fopt%2Fldap%2Fldapi' -F /opt/ldap//openldap/etc/openldap/slapd.d I get error: @(#) $OpenLDAP: slapd 2.5.16 (Nov 3 2023 07:51:03) $#012#011@f3068170494c:\/opt\/ldap\/openldap-2.5.16\/servers\/slapd /opt\/ldap\/openldap\/etc\/openldap\/slapd.d: line 1: rootdn is always granted unlimited privileges. Segmentation fault (core dumped) and in syslog: Nov 6 08:48:17 openldap-1 kernel: [44480681.935173] slapd[3775972]: segfault at 7f049da0375f ip 00007f049d75fc12 sp 00007fff24e77dd0 error 7 in libcrypto.so.3[7f049d60a000+279000] Nov 6 08:48:17 openldap-1 kernel: [44480681.935183] Code: 64 f9 ff ff eb a8 e8 ed 23 eb ff 66 66 2e 0f 1f 84 00 00 00 00 00 66 90 48 85 ff 0f 84 a7 00 00 00 53 b8 ff ff ff ff 48 89 fb <f0> 0f c1 47 30 83 e8 01 85 c0 74 12 7e 10 5b 31 c0 31 d2 31 f6 31 Next start with gdb: ldap@openldap-1:~$ gdb --args /opt/ldap/openldap/libexec/slapd -d 0 -h ldap://0.0.0.0:10389 -F /opt/ldap//openldap/etc/openldap/slapd.d GNU gdb (Debian 13.1-3) 13.1 Copyright (C) 2023 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". Type "show configuration" for configuration details. For bug reporting instructions, please see: <https://www.gnu.org/software/gdb/bugs/>. Find the GDB manual and other documentation resources online at: <http://www.gnu.org/software/gdb/documentation/>. For help, type "help". Type "apropos word" to search for commands related to "word"... Reading symbols from /opt/ldap/openldap/libexec/slapd... (No debugging symbols found in /opt/ldap/openldap/libexec/slapd) (gdb) run Starting program: /opt/ldap/openldap/libexec/slapd -d 0 -h ldap://0.0.0.0:10389 -F /opt/ldap//openldap/etc/openldap/slapd.d [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00007ffff79bfc12 in EVP_PKEY_free () from /lib/x86_64-linux-gnu/libcrypto.so.3 (gdb) bt full #0 0x00007ffff79bfc12 in EVP_PKEY_free () from /lib/x86_64-linux-gnu/libcrypto.so.3 No symbol table info available. #1 0x00007ffff79fa393 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3 No symbol table info available. #2 0x00007ffff79fa8cd in PEM_read_bio_Parameters_ex () from /lib/x86_64-linux-gnu/libcrypto.so.3 No symbol table info available. #3 0x00007ffff7fa1b38 in tlso_ctx_init (lo=0x5555556fd550, lt=0x7fffffffe280, is_server=1) at tls_o.c:546 dh = 0x7ffff7c6372f <SSL_CTX_new_ex+815> bio = 0x5555558afab0 ctx = 0x55555586b760 i = <optimized out> #4 0x00007ffff7f9de08 in ldap_int_tls_init_ctx (lo=0x5555556fd550, is_server=1) at tls2.c:264 rc = 0 ti = <optimized out> lts = {lt_certfile = 0x555555773350 "/opt/ldap/openldap/etc/openldap/certs/ldap.crt", lt_keyfile = 0x555555773390 "/opt/ldap/openldap/etc/openldap/certs/ldap.key", lt_dhfile = 0x555555773470 "/opt/ldap/openldap/etc/openldap/certs/dhparam", lt_cacertfile = 0x555555773310 "/opt/ldap/openldap/etc/openldap/certs/ca.crt", lt_cacertdir = 0x0, lt_ciphersuite = 0x5555557733d0 "TLS13-CHACHA20-POLY1305-SHA256:TLS13-AES-256-GCM-SHA384:TLS13-AES-128-GCM-SHA256:EECDH+CHACHA20:EECDH+AESGCM:EDH+AESGCM", lt_crlfile = 0x0, lt_randfile = 0x0, lt_ecname = 0x0, lt_protocol_min = 771, lt_protocol_max = 0, lt_cacert = {bv_len = 0, bv_val = 0x0}, lt_cert = {bv_len = 0, bv_val = 0x0}, lt_key = { bv_len = 0, bv_val = 0x0}} #5 0x00005555555759e7 in main () No symbol table info available. (gdb) thread apply all bt Thread 1 (Thread 0x7ffff75ce7c0 (LWP 64) "slapd"): #0 0x00007ffff79bfc12 in EVP_PKEY_free () from /lib/x86_64-linux-gnu/libcrypto.so.3 #1 0x00007ffff79fa393 in ?? () from /lib/x86_64-linux-gnu/libcrypto.so.3 #2 0x00007ffff79fa8cd in PEM_read_bio_Parameters_ex () from /lib/x86_64-linux-gnu/libcrypto.so.3 #3 0x00007ffff7fa1b38 in tlso_ctx_init (lo=0x5555556fd550, lt=0x7fffffffe280, is_server=1) at tls_o.c:546 #4 0x00007ffff7f9de08 in ldap_int_tls_init_ctx (lo=0x5555556fd550, is_server=1) at tls2.c:264 #5 0x00005555555759e7 in main () Next I rebuild openldap adding flags to configure step: ./configure CFLAGS=-g When I run slapd in new image: slapd -h 'ldap://0.0.0.0:10389 ldaps://0.0.0.0:10536 ldapi://%2Fopt%2Fldap%2Fldapi' -F /opt/ldap//openldap/etc/openldap/slapd.d all working well and I didn't get segementation fault. Can someone tell me what I'm doing wrong and how to investigate the problem? Regards BS -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 10127] New: Thread Safety in LMDB with MDB_NOTLS and Readonly Cursors
by openldap-its＠openldap.org 07 Nov '23

07 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=10127 Issue ID: 10127 Summary: Thread Safety in LMDB with MDB_NOTLS and Readonly Cursors Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: xiaoya2wei(a)gmail.com Target Milestone: --- Greetings LMDB Community, I am delving into the thread-safety aspects of LMDB, specifically regarding the use of readonly cursors across multiple threads. With the MDB_NOTLS flag enabled, which disables thread-local storage, my understanding is that readonly transactions may be shared between threads, provided there is proper synchronization to prevent concurrent access. Building upon this, I seek clarity on the following: Can multiple threads safely access a single readonly cursor derived from such a synchronized readonly transaction when MDB_NOTLS is enabled? Upon reviewing the LMDB source code, I noticed that cursors are tied to transactions (see mdb.c#L1335). This suggests that if threads can synchronously share a transaction, they might also share a cursor associated with it for data retrieval. I recognize my analysis might be superficial, and I'm open to corrections. Your insights on this matter would be greatly appreciated to enhance my understanding of LMDB's concurrency mechanisms. Thank you in advance for your assistance! -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8852] slapd memory use grows continuously with non-delta syncrepl and modifying groups
by openldap-its＠openldap.org 03 Nov '23

03 Nov '23

https://bugs.openldap.org/show_bug.cgi?id=8852 --- Comment #8 from Ondřej Kuzník <ondra(a)mistotebe.net> --- For comparison, using deltasync (and sortvals!) makes the consumer take a similar amount of CPU time (about +50-90 % on the provider's) to process the 10k value additions, just like Ryan noted earlier. On the other idea, no clue on whether we can somehow limit the amount of data queued up without severely impairing replication progress. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs