- openldap-bugs - openldap.org

[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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs