- openldap-bugs - openldap.org

[Issue 9553] New: Segfault in mdb_txn_abort handler caused by uninitialized pointer in mdb_reader_flush
by openldap-its＠openldap.org 17 May '21

17 May '21

https://bugs.openldap.org/show_bug.cgi?id=9553 Issue ID: 9553 Summary: Segfault in mdb_txn_abort handler caused by uninitialized pointer in mdb_reader_flush Product: OpenLDAP Version: 2.4.58 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: jrddunbr(a)amazon.com Target Milestone: --- This is for OpenLDAP 2.4.58, git commit 350ede08564ab14a45884c6f7c32419d98a75468 best I can tell. I have located an issue in mdb_reader_flush where it appears that an uninitialized pointer causes segfaults when threading is disabled. In the following function: https://git.openldap.org/openldap/openldap/-/blob/350ede08564ab14a45884c6f7… ``` void mdb_reader_flush( MDB_env *env ) { void *data; void *ctx = ldap_pvt_thread_pool_context(); if ( !ldap_pvt_thread_pool_getkey( ctx, env, &data, NULL ) ) { ldap_pvt_thread_pool_setkey( ctx, env, NULL, 0, NULL, NULL ); mdb_reader_free( env, data ); } } ``` the `void *data;` gets random values and is not initialized to NULL; when there is no thread pool the functions after it return without doing anything, and that pointer is passed down into mdb_reader_free, which passes down to mdb_txn_abort, where it is (recursively) de-referenced until the pointer is NULL. This causes a segfault, as that condition is not reached before it tries reading invalid memory addresses. The fix appears to be to make the following modification: Change `void *data;` to `void *data = NULL;`. I don't actually know much about the internals of this application, so I wanted to make sure that this is the correct solution before making a pull request for it. Apologies if my C terminology is not up to snuff; this is not my forte. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 8820] ldap_get_attribute_ber() function needs to be documented
by openldap-its＠openldap.org 14 May '21

14 May '21

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

1 0

[Issue 8820] ldap_get_attribute_ber() function needs to be documented
by openldap-its＠openldap.org 14 May '21

14 May '21

https://bugs.openldap.org/show_bug.cgi?id=8820 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|OL_2_5_REQ | Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 363f1056 by Ondřej Kuzník at 2021-05-14T08:18:05+01:00 ITS#8820 Document ldap_get_attribute_ber() -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9540] New: userSMIMECertificate needs to be binary
by openldap-its＠openldap.org 12 May '21

12 May '21

https://bugs.openldap.org/show_bug.cgi?id=9540 Issue ID: 9540 Summary: userSMIMECertificate needs to be binary Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: openldap.ms(a)savignano.net Target Milestone: --- OpenLDAP uses inetOrgPerson.schema with the following note on userSMIMECertificate attribute: # userSMIMECertificate # [...] Values for # this attribute are to be stored and requested in binary form, as # 'userSMIMECertificate;binary'. [...] but a line is added saying specifically ## OpenLDAP note: ";binary" transfer should NOT be used as syntax is binary This seems to make no sense. According to RFC 2798 which define inetOrgPerson and the useSMIMECertificate (first comment is quoted from there), this attribute must be stored and requested as userSMIMECertificate;binary. OpenLDAP does not do so. I don't understand the explanation "as syntax is binary". This leads to problems with clients following RFC 2798 and requesting the attribute as userSMIMECertificate;binary because OpenLDAP does not send userSMIMECertificate instead, but sends nothing at all (as if attribute would not exist). I think this is a bug. OpenLDAP does not follow RFC 2798 and this causes compatibility problems. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 6467] syncrepl enhancements
by openldap-its＠openldap.org 12 May '21

12 May '21

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

1 0

[Issue 6467] syncrepl enhancements
by openldap-its＠openldap.org 11 May '21

11 May '21

https://bugs.openldap.org/show_bug.cgi?id=6467 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|IN_PROGRESS |RESOLVED --- Comment #8 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • efb84b3e by Ondřej Kuzník at 2021-05-11T18:19:22+00:00 ITS#6467 Handle syncrepl searches with base of "" -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8747] LDAP load balancer daemon (lloadd)
by openldap-its＠openldap.org 11 May '21

11 May '21

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

1 0

[Issue 8747] LDAP load balancer daemon (lloadd)
by openldap-its＠openldap.org 11 May '21

11 May '21

https://bugs.openldap.org/show_bug.cgi?id=8747 --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • 2c1bb42f by Ondřej Kuzník at 2021-05-10T18:49:13+00:00 ITS#8747 Do not observe an epoch while calling dispose_cb • 4f499755 by Ondřej Kuzník at 2021-05-10T18:49:13+00:00 ITS#8747 Avoid epoch recursion in connection_write_cb • a186fd70 by Ondřej Kuzník at 2021-05-10T18:49:13+00:00 ITS#8747 Do not continue reading if connection is dying • 3802fa92 by Ondřej Kuzník at 2021-05-10T18:49:13+00:00 ITS#8747 Fix lloadd builds --without-tls • 1cb65102 by Ondřej Kuzník at 2021-05-10T18:49:13+00:00 ITS#8747 Keep an explicit backend pointer • 8e4d7ffe by Ondřej Kuzník at 2021-05-10T18:49:13+00:00 ITS#8747 Remove c_private from LloadConnection • cba03e49 by Ondřej Kuzník at 2021-05-10T18:49:13+00:00 ITS#8747 Protect shutdown code while workers are still alive -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6467] syncrepl enhancements
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=6467 --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- https://git.openldap.org/openldap/openldap/-/merge_requests/328 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6467] syncrepl enhancements
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=6467 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.5.0 |2.5.5 Status|CONFIRMED |IN_PROGRESS -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6467] syncrepl enhancements
by openldap-its＠openldap.org 10 May '21

10 May '21

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

1 0

[Issue 9535] New: test078 fails on MacOS due to output formatting
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9535 Issue ID: 9535 Summary: test078 fails on MacOS due to output formatting Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- On MacOSX the output of the "wc" command is right-justified. This causes a mismatch against the reference data. God only knows why... -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9532] New: homedir overlay fails as a static module
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9532 Issue ID: 9532 Summary: homedir overlay fails as a static module 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 built as a static module, the homedir overlay is unusable, breaking test035: testrun/slapd.1.conf: line 8 (pidfile /home/build/git/ol25/ol25/tests/testrun/slapd.1.pid) testrun/slapd.1.conf: line 9 (argsfile /home/build/git/ol25/ol25/tests/testrun/slapd.1.args) testrun/slapd.1.conf: line 13 (database mdb) mdb_db_init: Initializing mdb database testrun/slapd.1.conf: line 14 (suffix "dc=example,dc=com") >>> dnPrettyNormal: <dc=example,dc=com> <<< dnPrettyNormal: <dc=example,dc=com>, <dc=example,dc=com> testrun/slapd.1.conf: line 15 (rootdn "cn=Manager,dc=example,dc=com") >>> dnPrettyNormal: <cn=Manager,dc=example,dc=com> <<< dnPrettyNormal: <cn=Manager,dc=example,dc=com>, <cn=manager,dc=example,dc=com> testrun/slapd.1.conf: line 16 (rootpw ***) testrun/slapd.1.conf: line 17 (directory /home/build/git/ol25/ol25/tests/testrun/db.1.a) testrun/slapd.1.conf: line 18 (index objectClass eq) index objectClass 0x0004 testrun/slapd.1.conf: line 19 (index cn,sn,uid pres,eq,sub) index cn 0x0716 index sn 0x0716 index uid 0x0716 testrun/slapd.1.conf: line 20 (maxsize 33554432) testrun/slapd.1.conf: line 22 (overlay homedir) overlay "homedir" not found testrun/slapd.1.conf: line 22: <overlay> handler exited with 1! slaptest: bad configuration file! -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9527] New: typo in nssov/README at line 68 "olDatabase" should be "olcDatabase"
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9527 Issue ID: 9527 Summary: typo in nssov/README at line 68 "olDatabase" should be "olcDatabase" Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: rdubner(a)symas.com Target Milestone: --- At line 68 in nssov/README, the word olDatabase should be olcDatabase If I could generate a merge request, I would point you to https://git.openldap.org/rdubner/openldap origin/nssov-README-patch But that seems overkill for adding a single character -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9525] New: Fix contrib modules to properly honor build flags
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9525 Issue ID: 9525 Summary: Fix contrib modules to properly honor build flags Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Currently the contrib makefiles use a variable "OPT", instead they should be fixed to correctly honor CFLAGS, CPPFLAGS, and LDFLAGS as appropriate -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9520] New: slapd should fail if linked with libsodium and rgon2.so is load with parameter with p>=1
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9520 Issue ID: 9520 Summary: slapd should fail if linked with libsodium and rgon2.so is load with parameter with p>=1 Product: OpenLDAP Version: 2.4.58 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- IMHO slapd should simply fail to start in case 1. it is linked against libsodium 2. and argon2.so is load with parameter with p>=1 Because this is a config error it should log a clear error message at config log level. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9519] New: Adopt the namedObject draft
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9519 Issue ID: 9519 Summary: Adopt the namedObject draft Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Lives here https://tools.ietf.org/html/draft-stroeder-namedobject -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9518] New: Configuration parameter to force TLSv1.2 (-no_tls1_3)
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9518 Issue ID: 9518 Summary: Configuration parameter to force TLSv1.2 (-no_tls1_3) Product: OpenLDAP Version: 2.4.50 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: tom.bosmans(a)be.ibm.com Target Milestone: --- Hi, I'm running into a problem during creation of an Ansible playbook that uses the community.general.ldap_entry module, which in turn depends on python-ldap , that uses the openldap libraries. My (openldap) server is configured for TLS 1.2, but does not support TLS 1.3. openssl version: OpenSSL 1.1.1k (have tried 1.1.1g as well). So the root cause is that openssl, if it's compiled with TLS v1.3 , will try TLS v1.3. If that doesn't work because the server does not support it, it just stops. This is madness. openssl s_client -connect isva.test:636 -showcerts -state CONNECTED(00000003) SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL3 alert read:fatal:handshake failure SSL_connect:error in error Now within openssl , there's a parameter that you can set to skip tls 1.3. Great. So this works. openssl s_client -connect isva.test:636 -showcerts -state -no_tls1_3 CONNECTED(00000003) SSL_connect:before SSL initialization SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS write client hello SSL_connect:SSLv3/TLS read server hello depth=0 CN = isva.test verify error:num=18:self signed certificate verify return:1 depth=0 CN = isva.test ... But with ldapsearch, there's no option to pass this . I've tried changing the cipher suite in .ldaprc, but to no avail. The TLSv1.3 ciphers are always used. [tbosmans@tbosmans-p73 ~]$ ldapsearch -x -H ldaps://isva.test -D "cn=bind,o=whatever" -w "pasword" -b "o=test" -v -d1 ldap_url_parse_ext(ldaps://isva.test) ldap_initialize( ldaps://isva.test:636/??base ) ldap_create ldap_url_parse_ext(ldaps://isva.test:636/??base) ldap_sasl_bind ldap_send_initial_request ldap_new_connection 1 1 0 ldap_int_open_connection ldap_connect_to_host: TCP isva.test:636 ldap_new_socket: 3 ldap_prepare_socket: 3 ldap_connect_to_host: Trying 192.168.42.135:636 ldap_pvt_connect: fd: 3 tm: -1 async: 0 attempting to connect: connect success TLS trace: SSL_connect:before SSL initialization TLS trace: SSL_connect:SSLv3/TLS write client hello TLS trace: SSL3 alert read:fatal:handshake failure TLS trace: SSL_connect:error in error TLS: can't connect: error:14094410:SSL routines:ssl3_read_bytes:sslv3 alert handshake failure. ldap_err2string ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1) [tbosmans@tbosmans-p73 ~]$ cat .ldaprc TLS_REQCERT never TLS_ECNAME ECDHE TLS_CIPHER_SUITE ECDHE-ECDSA-ARIA256-GCM-SHA384 So it would be great it there was an option equivalent to "-no_tls1_3" for the openldap client tools (or there may be a way to achieve this that I've missed so far). -- You are receiving this mail because: You are on the CC list for the issue.

1 10

[Issue 9517] New: Documenting how to pass Argon2 configuration parameters when loading the module
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9517 Issue ID: 9517 Summary: Documenting how to pass Argon2 configuration parameters when loading the module Product: OpenLDAP Version: 2.4.58 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: gilbert.kowarzyk(a)servicenow.com Target Milestone: --- It is possible to pass the configuration parameters for the argon2 module when loading the module in OpenLDAP, and they are properly employed when using ldappasswd. Nevertheless, it took me a considerable amount of time to find how to provide the config when loading the module. The way I was able to provide the argon2 configuration values was by adding the following to the slaps.ldif file: olcModuleload: argon2.so m=XXXX t=YYYY p=ZZZZZ (where XXXX, YYYY, and ZZZZ are the configuration values). The syntax was initially not clear to me, and required a lot of trial an error (I was not able to find documentation that clearly explained this syntax). Thanks in advance! -- You are receiving this mail because: You are on the CC list for the issue.

1 19

[Issue 9515] New: datamorph overlay fails to build
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9515 Issue ID: 9515 Summary: datamorph overlay fails to build Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- datamorph.c:1706:30: error: 'avl_dup_error' undeclared (first use in this function); did you mean 'ldap_avl_dup_error'? transformation_info_cmp, avl_dup_error ); ^~~~~~~~~~~~~ ldap_avl_dup_error datamorph.c:1706:30: note: each undeclared identifier is reported only once for each function it appears in datamorph.c: In function 'datamorph_add_mapping': datamorph.c:1771:33: error: 'avl_dup_error' undeclared (first use in this function); did you mean 'ldap_avl_dup_error'? transformation_mapping_cmp, avl_dup_error ); ^~~~~~~~~~~~~ ldap_avl_dup_error datamorph.c: In function 'datamorph_ldadd_info_cleanup': datamorph.c:1795:4: error: 'avl_dup_error' undeclared (first use in this function); did you mean 'ldap_avl_dup_error'? avl_dup_error ) ) { ^~~~~~~~~~~~~ ldap_avl_dup_error datamorph.c: In function 'datamorph_ldadd_mapping_cleanup': datamorph.c:1853:4: error: 'avl_dup_error' undeclared (first use in this function); did you mean 'ldap_avl_dup_error'? avl_dup_error ) ) { ^~~~~~~~~~~~~ ldap_avl_dup_error datamorph.c: In function 'datamorph_config_build_attr': datamorph.c:1965:10: warning: implicit declaration of function 'avl_apply'; did you mean 'acl_append'? [-Wimplicit-function-declaration] return avl_apply( info->ti_enum.to_db, datamorph_config_build_enum, ^~~~~~~~~ acl_append datamorph.c: In function 'datamorph_cfadd': datamorph.c:1988:30: error: 'avl_dup_error' undeclared (first use in this function); did you mean 'ldap_avl_dup_error'? transformation_info_cmp, avl_dup_error ); ^~~~~~~~~~~~~ ldap_avl_dup_error -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9511] New: make depend shouldn't error on slapi/plugin.c if no ltdl.h found
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9511 Issue ID: 9511 Summary: make depend shouldn't error on slapi/plugin.c if no ltdl.h found Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- make depend throws the following error if ltdl.h is not found: make[3]: Entering directory '/home/quanah/qtest/openldap/qbuild/servers/slapd/slapi' ../../../../build/mkdep -l -d "../../../../servers/slapd/slapi" -c "cc" -m "-M" -I../../../include -I.. -I. -I../../../../include -I../../../../servers/slapd/slapi/.. -I../../../../servers/slapd/slapi plugin.c slapi_pblock.c slapi_utils.c printmsg.c slapi_ops.c slapi_dn.c slapi_ext.c slapi_overlay.c ../../../../servers/slapd/slapi/plugin.c:33:10: fatal error: ltdl.h: No such file or directory #include <ltdl.h> ^~~~~~~~ I.e., it should probably just exit if HAVE_LTDL_H is not true or similar. At the least: diff --git a/servers/slapd/slapi/plugin.c b/servers/slapd/slapi/plugin.c index 7ebc23f3a..f816ea34e 100644 --- a/servers/slapd/slapi/plugin.c +++ b/servers/slapd/slapi/plugin.c @@ -30,7 +30,9 @@ /* * Note: if ltdl.h is not available, slapi should not be compiled */ +#ifdef HAVE_LTDL_H #include <ltdl.h> +#endif gets rid of the error during make depend -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9396] New: Docs might recommend applicationProcess for ppolicy entries
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9396 Issue ID: 9396 Summary: Docs might recommend applicationProcess for ppolicy entries Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: kop(a)karlpinc.com Target Milestone: --- Created attachment 779 --> https://bugs.openldap.org/attachment.cgi?id=779&action=edit Suggested doc patch Hello, The ppolicy section of the Admin Guide does not say why the "people" object class is present in the example policy entry. I suggest that the docs explain. Otherwise the reader is left wondering why the particular choice of structural object class was made. The less informed reader is left wondering why a second object class is required at all. I also suggest that instead of the "people" object class, that the applicationProcess object class be used in the example to provide the structural object class the entry requires. The slapo-ppolicy man page might also provide guidance. Attached is a suggested patch, provided so that you have something to work from. If you're not happy with the patch go ahead and discard it, I'm not advocating any particular wording. I, Karl O. Pinc, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -- You are receiving this mail because: You are on the CC list for the issue.

1 12

[Issue 9337] New: Slapd crash with lastbind overlay
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9337 Issue ID: 9337 Summary: Slapd crash with lastbind overlay Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: frederic.poisson(a)admin.gmessaging.net Target Milestone: --- Hello, I have an issue with a 2.4.50 OpenLDAP instance configured with replication (1 master and 1 replica), and when i activate the lastbind overlay. The replica server crash like this : slapd[8433]: segfault at 1d0 ip 000000000049f70b sp 00007f189f7fd1a0 error 4 in slapd[400000+1d8000] The database is this one with overlay loaded : dn: cn=module{0},cn=config olcModuleLoad: {0}sssvlv.la olcModuleLoad: {1}ppolicy.la olcModuleLoad: {2}syncprov.la olcModuleLoad: {3}lastbind.la olcModuleLoad: {4}pw-sha2.la dn: olcDatabase={3}mdb,cn=config objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcUpdateRef: ldap://master.server:389/ If i add this configuration it crash : dn: olcOverlay={2}lastbind objectClass: olcOverlayConfig objectClass: olcLastBindConfig olcOverlay: {2}lastbind olcLastBindPrecision: 60 olcLastBindForwardUpdates: TRUE Does the release 2.5.51 or 2.5.52 could solve this issue ? Regards, -- You are receiving this mail because: You are on the CC list for the issue.

1 11

[Issue 8770] dsaschema seg faults
by openldap-its＠openldap.org 10 May '21

10 May '21

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

1 0

[Issue 8736] Add test script for cn=config replication using delta-sync
by openldap-its＠openldap.org 10 May '21

10 May '21

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

1 0

[Issue 8707] slapd: Add systemd service notification support
by openldap-its＠openldap.org 10 May '21

10 May '21

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

1 0

[Issue 8586] load cert+chain from TLSCertificateFile
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=8586 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |FIXED Status|RESOLVED |VERIFIED -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7832] Proposing ppolicy extended module for OpenLDAP
by openldap-its＠openldap.org 10 May '21

10 May '21

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

1 0

[Issue 8721] Quarantine in meta backend
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=8721 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|IN_PROGRESS |RESOLVED --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 180092fe by Ondřej Kuzník at 2021-05-07T19:26:19+00:00 ITS#8721 Regression test • de0caafe by Ondřej Kuzník at 2021-05-07T19:26:19+00:00 ITS#8721 Do not update ri_last unless we're actually retrying -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9550] New: lloadd fails to compile without TLS
by openldap-its＠openldap.org 10 May '21

10 May '21

https://bugs.openldap.org/show_bug.cgi?id=9550 Issue ID: 9550 Summary: lloadd fails to compile without TLS Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: lloadd Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- ./configure --without-tls --enable-balancer && make ... Entering subdirectory lloadd make[2]: Entering directory '/home/ryan/tmp/openldap/servers/lloadd' ../../build/mkversion -v "2.X" -s -n Versionstr lloadd > version.c cc -g -O2 -I../../include -I. -I./../slapd -I../../include -c -o backend.o backend.c cc -g -O2 -I../../include -I. -I./../slapd -I../../include -c -o bind.o bind.c cc -g -O2 -I../../include -I. -I./../slapd -I../../include -c -o config.o config.c cc -g -O2 -I../../include -I. -I./../slapd -I../../include -c -o connection.o connection.c cc -g -O2 -I../../include -I. -I./../slapd -I../../include -c -o client.o client.c client.c: In function ‘client_tls_handshake_cb’: client.c:363:10: error: ‘LloadConnection’ has no member named ‘c_is_tls’ 363 | c->c_is_tls = LLOAD_TLS_ESTABLISHED; | ^~ client.c: In function ‘client_init’: client.c:418:10: error: ‘LloadConnection’ has no member named ‘c_is_tls’ 418 | c->c_is_tls = LLOAD_LDAPS; | ^~ make[2]: *** [<builtin>: client.o] Error 1 -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8747] LDAP load balancer daemon (lloadd)
by openldap-its＠openldap.org 08 May '21

08 May '21

https://bugs.openldap.org/show_bug.cgi?id=8747 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |ryan(a)openldap.org --- Comment #3 from Howard Chu <hyc(a)openldap.org> --- *** Issue 9550 has been marked as a duplicate of this issue. *** -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9500] New: back-mdb: index generation failiure
by openldap-its＠openldap.org 06 May '21

06 May '21

https://bugs.openldap.org/show_bug.cgi?id=9500 Issue ID: 9500 Summary: back-mdb: index generation failiure Product: OpenLDAP Version: 2.5 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Operating system CentOS Linux release 8.3.2011 OpenLDAP version 2.5.2 beta Error adding records. After app. 65539 records. Clientside error: index generation failed Server log: Mar 12 19:17:48 tx01 slapd[30394]: conn=1015 op=4 ADD dn="cn=foo,ou=Roles,ou=RBAC,dc=example,dc=com" Mar 12 19:17:48 tx01 slapd[30394]: slap_get_csn: conn=1015 op=4 generated new csn=20210312191748.484367Z#000000#001#000000 manage=1 Mar 12 19:17:48 tx01 slapd[30394]: slap_queue_csn: queueing 0x7d3d842146e0 20210312191748.484367Z#000000#001#000000 Mar 12 19:17:48 tx01 slapd[30394]: => mdb_idl_insert_keys: c_get hi failed: MDB_NOTFOUND: No matching key/data pair found (-30798) Mar 12 19:17:48 tx01 slapd[30394]: conn=1015 op=4 RESULT tag=105 err=80 qtime=0.000042 etime=0.001244 text=index generation failed Mar 12 19:17:48 tx01 slapd[30394]: slap_graduate_commit_csn: removing 0x7d3d842146e0 20210312191748.484367Z#000000#001#000000 -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9461] New: Deletion causes cursor to repeat
by openldap-its＠openldap.org 06 May '21

06 May '21

https://bugs.openldap.org/show_bug.cgi?id=9461 Issue ID: 9461 Summary: Deletion causes cursor to repeat Product: LMDB Version: 0.9.27 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: github(a)nicwatson.org Target Milestone: --- Created attachment 795 --> https://bugs.openldap.org/attachment.cgi?id=795&action=edit repro of cursor delete bug See attached source code for reproduction. The test behaves correctly in 0.9.26 and fails in 0.9.27 and 0.9.28. The failing sequence is: 1. In a dupsort DB, create two different keys and values. 2. Create a cursor, setting the position to the second key. 3. Delete the first key. 4. Have the cursor get the next key. mdb_get_key will return the second key instead of returning MDB_NOT_FOUND. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 8820] ldap_get_attribute_ber() function needs to be documented
by openldap-its＠openldap.org 06 May '21

06 May '21

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

1 0

[Issue 7335] Create process for updating man pages to handle both cn=config and slapd.conf configurations
by openldap-its＠openldap.org 06 May '21

06 May '21

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

1 0

[Issue 8721] Quarantine in meta backend
by openldap-its＠openldap.org 06 May '21

06 May '21

https://bugs.openldap.org/show_bug.cgi?id=8721 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Ever confirmed|0 |1 Assignee|smckinney(a)symas.com |ondra(a)mistotebe.net Status|UNCONFIRMED |IN_PROGRESS --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- https://git.openldap.org/openldap/openldap/-/merge_requests/327 -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9545] New: Compile warnings in OpenLDAP 2.4 branch
by openldap-its＠openldap.org 04 May '21

04 May '21

https://bugs.openldap.org/show_bug.cgi?id=9545 Issue ID: 9545 Summary: Compile warnings in OpenLDAP 2.4 branch Product: OpenLDAP Version: 2.4.58 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: simon.pichugin(a)gmail.com Target Milestone: --- There are a few compile warnings that are present in OPENLDAP_REL_ENG_2_4 libraries. I understand that 2.4 is not in an active development state anymore but I think it's important to keep it as clean as possible as the libraries are actively used by other projects. The warnings: tls2.c: In function ‘ldap_int_tls_connect’: tls2.c:378:9: warning: implicit declaration of function ‘ldap_pvt_tls_check_hostname’ [-Wimplicit-function-declaration] 378 | err = ldap_pvt_tls_check_hostname( ld, ssl, host ); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ thr_posix.c: In function ‘ldap_pvt_thread_set_concurrency’: thr_posix.c:93:9: warning: implicit declaration of function ‘pthread_setconcurrency’ [-Wimplicit-function-declaration] 93 | return pthread_setconcurrency( n ); | ^~~~~~~~~~~~~~~~~~~~~~ thr_posix.c: In function ‘ldap_pvt_thread_get_concurrency’: thr_posix.c:107:9: warning: implicit declaration of function ‘pthread_getconcurrency’; did you mean ‘ldap_pvt_thread_get_concurrency’? [-Wimplicit-function-declaration] 107 | return pthread_getconcurrency(); | ^~~~~~~~~~~~~~~~~~~~~~ | ldap_pvt_thread_get_concurrency charray.c: In function ‘ldap_charray2str’: charray.c:269:3: warning: ‘strncpy’ specified bound depends on the length of the source argument [-Wstringop-overflow=] 269 | strncpy( p, *v, len ); | ^~~~~~~~~~~~~~~~~~~~~ charray.c:268:9: note: length computed here 268 | len = strlen( *v ); | ^~~~~~~~~~~~ Additional information: The 'implicit declaration' warnings can be potentially harmful. If the compiler does not see the declaration of a function _before_ it is called, it assumes the following implicit declaration instead: int fnc_name(); ... which has severe consequences: 1. Only sizeof(int) bytes are read from the return value even if the function returns a different type. 2. Count and type of the arguments passed to the functions are not checked at all because the compiler has no means to know what the callee expects as parameters. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9543] New: Patch : Customize CN check on TLS
by openldap-its＠openldap.org 01 May '21

01 May '21

https://bugs.openldap.org/show_bug.cgi?id=9543 Issue ID: 9543 Summary: Patch : Customize CN check on TLS Product: OpenLDAP Version: unspecified Hardware: i386 OS: Other Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: julien.wadel(a)belledonne-communications.com Target Milestone: --- Created attachment 821 --> https://bugs.openldap.org/attachment.cgi?id=821&action=edit Patch on master Hi, I added a feature that allow to customize the domain name on TLS hostname verification. With it, we can use an IP that comes from our DNS resolver. It is mainly used when we want launch test units with a private server where the IP and domains are private. In our case, we use our own dns resolver (internal code) which give us an IP that is passed to LDAP. As we know the domain name but not LDAP, we pass it to it for checking (it's not an ignore option) Here is the commit from our repository (based from 2.4): https://gitlab.linphone.org/BC/public/external/openldap/-/commit/a4fef2181c… Here is the branch from the HEAD of your current master (one commit, parent 60b7dc731ce9f2424a4a56d78ae99270a3c6239c) https://gitlab.linphone.org/BC/public/external/openldap/-/tree/feature/host… Here is the branch from the HEAD of OPENLDAP_REL_ENG_2_4 (one commit, parent faf2c4e78641f69df3fdea5f97ddb058946f2051) https://gitlab.linphone.org/BC/public/external/openldap/-/tree/feature/host… I attached the diff on master Regards -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 8078] The configured TimeOut in back-meta overlay is not used during the connection phase
by openldap-its＠openldap.org 28 Apr '21

28 Apr '21

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

1 0

[Issue 8078] The configured TimeOut in back-meta overlay is not used during the connection phase
by openldap-its＠openldap.org 28 Apr '21

28 Apr '21

1 0

[Issue 8078] The configured TimeOut in back-meta overlay is not used during the connection phase
by openldap-its＠openldap.org 28 Apr '21

28 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=8078 --- Comment #2 from nivanova(a)symas.com <nivanova(a)symas.com> --- I don't think this is actually a bug. This is not what network_timeout is meant for. The timeout value for receiving a response is actually the per-operation timeouts, and these are, in fact, honored. ldap_result is called with a tv of LDAP_BACK_RESULT_UTIMEOUT to avoid multiple threads getting stuck waiting for the same connection to become available, but the call is repeated until the configured operation timeout is reached. This is how both back-ldap and back-meta operate, and it is by design. network-timeout is provided (by setting LDAP_OPT_NETWORK_TIMEOUT) to ldap_pvt_poll when a new connection is created or an ldap request is sent. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9533] New: OpenLdap hangs when creating many databases
by openldap-its＠openldap.org 28 Apr '21

28 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=9533 Issue ID: 9533 Summary: OpenLdap hangs when creating many databases Product: OpenLDAP Version: 2.4.57 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: akrush24(a)gmail.com Target Milestone: --- I initialize openldap cluster with config: ``` dn: cn=config objectClass: olcGlobal cn: config olcPidFile: /run/openldap/slapd.pid olcArgsFile: /run/openldap/slapd.args olcServerID: 1 ldaps://ldap.ldap01.xxx.ru:637 olcServerID: 2 ldaps://ldap.ldap02.xxx.ru:637 olcServerID: 3 ldaps://ldap.ldap03.xxx.ru:637 olcTLSCACertificateFile: /etc/openldap/ssl/ca.pem olcTLSCertificateKeyFile: /etc/openldap/ssl/private.key olcTLSCertificateFile: /etc/openldap/ssl/server.crt dn: cn=module,cn=config objectClass: olcModuleList cn: module olcModulepath: /usr/lib/openldap olcModuleload: back_mdb.so olcModuleload: syncprov.so dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///etc/openldap/schema/core.ldif include: file:///etc/openldap/schema/cosine.ldif include: file:///etc/openldap/schema/inetorgperson.ldif include: file:///etc/openldap/schema/nis.ldif dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage olcRootPW: Ohtheis7ur9Qua6e olcSyncRepl: rid=001 provider=ldaps://ldap.ldap01.xxx.ru:637 binddn=cn=config bindmethod=simple credentials=Ohtheis7ur9Qua6e searchbase=cn=config type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=ldaps://ldap.ldap02.xxx.ru:637 binddn=cn=config bindmethod=simple credentials=Ohtheis7ur9Qua6e searchbase=cn=config type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=003 provider=ldaps://ldap.ldap03.xxx.ru:637 binddn=cn=config bindmethod=simple credentials=Ohtheis7ur9Qua6e searchbase=cn=config type=refreshAndPersist retry="5 5 300 5" timeout=1 olcMirrorMode: TRUE dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov ``` Then I try to create many bases in a loop: My base template: ``` /etc/openldap/conf.d # cat > newdb.ldiff.template <<EOF! dn: olcDatabase={#DITID#}mdb,cn=config changetype: add objectClass: olcDatabaseConfig objectClass: olcMdbConfig olcDatabase: {#DITID#}mdb olcSuffix: dc=devmail,dc=srv,dc=local olcDbMaxSize: 1073741824 olcRootDN: cn=admin,dc=devmail,dc=srv,dc=local olcRootPW: 123 olcDbDirectory: /var/lib/openldap/openldap-data/ olcDbIndex: objectClass eq olcSyncRepl: rid=001 provider=ldaps://ldap.ldap01.xxx.local:637 binddn=cn=admin,dc=devmail,dc=srv,dc=local bindmethod=simple credentials=123 searchbase=dc=devmail,dc=srv,dc=local type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=002 provider=ldaps://ldap.ldap02.xxx.local:637 binddn=cn=admin,dc=devmail,dc=srv,dc=local bindmethod=simple credentials=123 searchbase=dc=devmail,dc=srv,dc=local type=refreshAndPersist retry="5 5 300 5" timeout=1 olcSyncRepl: rid=003 provider=ldaps://ldap.ldap03.xxx.local:637 binddn=cn=admin,dc=devmail,dc=srv,dc=local bindmethod=simple credentials=123 searchbase=dc=devmail,dc=srv,dc=local type=refreshAndPersist retry="5 5 300 5" timeout=1 olcMirrorMode: TRUE dn: olcOverlay=syncprov,olcDatabase={#DITID#}mdb,cn=config changetype: add objectClass: olcOverlayConfig objectClass: olcSyncProvConfig olcOverlay: syncprov EOF! ``` For example 100 dbs ``` for I in $(seq 1 100);do sed -e "s/devmail/devmail${I}/g" -e "s/#DITID#/${I}/g" ./newdb.ldiff.template > newdb${I}.ldiff ldapmodify -H ldapi://%2Fvar%2Frun%2Fopenldap%2Fldapi -Y EXTERNAL -f ./newdb${I}.ldiff done ``` As a result my cluster first slows down and then nodes hang up. Logs show nothing, no activity. Connect via ldapmodify or other cli utilities just hangs. In such a situation rebooting a single node of the cluster helps, until the cluster becomes unresponsive once again. Please tell me what could be the problem? Could my cluster configuration be incorrect? The problem manifests itself only in situation where I have many databases, e.g. more than 10. With one-two dbs all works as expected. I have also tried using different in-built database backends, to no avail. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9513] New: Enhanced debug output
by openldap-its＠openldap.org 23 Apr '21

23 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=9513 Issue ID: 9513 Summary: Enhanced debug output Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: enhancement Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- While debugging ITS#9479 I needed more information on which threads were doing what actions. Also, when looking for delays/hangs/race conditions, the 1-second granularity of the debug msg timestamp was inadequate. And also, some of the debug output for the Search operation was being done in separate Debug calls for a single line of output. This gets jumbled up pretty badly if other threads are printing output as well. New patch set will extend the debug timestamp to have fractional seconds too; it will use clock_gettime for nanosecond resolution if available, otherwise use gettimeofday for microsecond resolution. Also tweak the Search debug output to only use one Debug invocation per line of output. This is MR!279. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9470] New: Add homedir overlay to core
by openldap-its＠openldap.org 23 Apr '21

23 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=9470 Issue ID: 9470 Summary: Add homedir overlay to core 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: --- Symas will contribute its homedir overlay as a core overlay Home directory provisioning overlay The homedir overlay causes slapd to notice changes involving RFC-2307bis style user-objects and make appropriate changes to the local filesystem. This can be performed on both master and replica systems, so it is possible to perform remote home directory provisioning. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 8707] slapd: Add systemd service notification support
by openldap-its＠openldap.org 21 Apr '21

21 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=8707 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |FIXED --- Comment #31 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 629cafc9 by Ondřej Kuzník at 2021-04-20T22:54:19+00:00 ITS#8707 Add systemd service notification support • f3501534 by SATOH Fumiyasu at 2021-04-20T22:54:19+00:00 ITS#8707 - Add slapd.service and lloadd.service for systemd • 0786f6d5 by Quanah Gibson-Mount at 2021-04-20T22:54:19+00:00 ITS#8707 - Update CI/CD for systemd notification support • 72caa56a by Ondřej Kuzník at 2021-04-20T22:54:19+00:00 ITS#8707 systemd notifications from lloadd -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9528] New: liblmdb throws away environment CFLAGS
by openldap-its＠openldap.org 20 Apr '21

20 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=9528 Issue ID: 9528 Summary: liblmdb throws away environment CFLAGS Product: LMDB Version: 0.9.29 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- When building LMDB, specified hardening flags are thrown away due to the Makefile overriding CFLAGS: Makefile:CFLAGS = $(THREADS) $(OPT) $(W) $(XCFLAGS) -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 8721] Quarantine in meta backend
by openldap-its＠openldap.org 15 Apr '21

15 Apr '21

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

1 0

[Issue 8707] slapd: Add systemd service notification support
by openldap-its＠openldap.org 15 Apr '21

15 Apr '21

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

1 0

[Issue 8847] New LDAP URL syntax to support binding to specific IP address at client side
by openldap-its＠openldap.org 15 Apr '21

15 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=8847 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.5.3 |2.5.4 --- Comment #44 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 7df2a0f3 by Ondřej Kuzník at 2021-04-15T15:16:19+01:00 ITS#8847 Allocate a large enough buffer -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8707] slapd: Add systemd service notification support
by openldap-its＠openldap.org 14 Apr '21

14 Apr '21

https://bugs.openldap.org/show_bug.cgi?id=8707 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.6.0 |2.5.4 Assignee|bugs(a)openldap.org |ondra(a)mistotebe.net -- 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