- openldap-bugs - openldap.org

[Issue 4685] Updated changelog overlay by Neil Dunbar
by openldap-its＠openldap.org 28 Aug '20

28 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=4685 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #9 from Quanah Gibson-Mount <quanah(a)openldap.org> --- The auditlog overlay generates something quite similar, and there's little value in supporting this at this point. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 4656] Enhancement: again on Netscape style changelog
by openldap-its＠openldap.org 28 Aug '20

28 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=4656 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 4656] Enhancement: again on Netscape style changelog
by openldap-its＠openldap.org 28 Aug '20

28 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=4656 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #17 from Quanah Gibson-Mount <quanah(a)openldap.org> --- The auditlog overlay generates something quite similar, and there's little value in supporting this at this point. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9054] Add support for multiple EECDH curves
by openldap-its＠openldap.org 28 Aug '20

28 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9054 --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- trunk: Commits: • d5ed7c50 by Howard Chu at 2020-08-28T11:09:25+01:00 ITS#9054, #9318 document new TLS options in slapd RE24: Commits: • cfc231a5 by Howard Chu at 2020-08-28T15:27:59+00:00 ITS#9054, #9318 document new TLS options in slapd -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9135] mdb index corruption during legitimate delete
by openldap-its＠openldap.org 28 Aug '20

28 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9135 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|2.5.0 |2.4.52 Resolution|TEST |FIXED --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • ce6d302c by Howard Chu at 2020-08-28T01:30:53+00:00 ITS#9135 fix index error on collapsed range -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9054] Add support for multiple EECDH curves
by openldap-its＠openldap.org 27 Aug '20

27 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9054 --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: Commits: • 53676779 by Howard Chu at 2020-08-27T11:22:58+01:00 ITS#9054 fix typo RE24: Commits: • d2139d5c by Howard Chu at 2020-08-27T15:05:46+00:00 ITS#9054 fix typo -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8725] Additional support for asynchronous operation
by openldap-its＠openldap.org 26 Aug '20

26 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=8725 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|UNCONFIRMED |RESOLVED Keywords|OL_2_5_REQ | --- Comment #6 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Sigh, wrong commit in the message, but: Commits: • 8d312196 by Quanah Gibson-Mount at 2020-08-26T21:55:39+00:00 More for ITS#8845, skip cleanup on async op with extended operations -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8725] Additional support for asynchronous operation
by openldap-its＠openldap.org 26 Aug '20

26 Aug '20

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

1 0

[Issue 8725] Additional support for asynchronous operation
by openldap-its＠openldap.org 26 Aug '20

26 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=8725 --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Note: Adjust debug statement there for head/RE25. ;) -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8725] Additional support for asynchronous operation
by openldap-its＠openldap.org 26 Aug '20

26 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=8725 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |--- Status|RESOLVED |UNCONFIRMED Ever confirmed|1 |0 --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- This seems to be missing the following necessary change: diff --git a/servers/slapd/extended.c b/servers/slapd/extended.c index 2b55438..59624f7 100644 --- a/servers/slapd/extended.c +++ b/servers/slapd/extended.c @@ -176,6 +176,12 @@ do_extended( op->o_bd = frontendDB; rs->sr_err = frontendDB->be_extended( op, rs ); + if ( rs->sr_err == SLAPD_ASYNCOP ){ + /* skip cleanup */ + Debug( LDAP_DEBUG_TRACE, "do_extended: skipping cleanup for ASYNCOP\n", 0, 0, 0 ); + return rs->sr_err; + } + /* clean up in case some overlay set them? */ if ( !BER_BVISNULL( &op->o_req_ndn ) ) { if ( !BER_BVISNULL( &op->o_req_dn ) -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9314] New: Add slap_client_keepalive to proto-slap.h
by openldap-its＠openldap.org 26 Aug '20

26 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9314 Issue ID: 9314 Summary: Add slap_client_keepalive to proto-slap.h 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: --- When building OpenLDAP, there are implicit declaration warnings that would be resolved by adding the missing function definition of slap_client_keepalive to proto-slap.h (if appropriate). From back-ldap: bind.c:714:2: warning: implicit declaration of function 'slap_client_keepalive'; did you mean 'slap_client_connect'? [-Wimplicit-function-declaration] slap_client_keepalive(ld, &li->li_tls.sb_keepalive); -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 7239] slapo-accesslog: not all write operations logged with 'logops all'
by openldap-its＠openldap.org 25 Aug '20

25 Aug '20

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

1 0

[Issue 9316] New: performance issue when writing a high number of large objects
by openldap-its＠openldap.org 25 Aug '20

25 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9316 Issue ID: 9316 Summary: performance issue when writing a high number of large objects Product: LMDB Version: 0.9.24 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: JGabler(a)univa.com Target Milestone: --- Created attachment 755 --> https://bugs.openldap.org/attachment.cgi?id=755&action=edit lmdb performance test reproducing the issue When writing a high number of big objects we see an extreme variation in performance from very fast to extremely slow. In the test scenario we write 10 chunks of 10.000 "jobs" (some 10kB) and their corresponding "job script" (some 40kB), 200.000 objects in total. Then delete all objects. We do 10 iterations of this scenario. When running this scenario as part of Univa Grid Engine with LMDB as database backend we get the following performance values (rows are the iteration, columns the chunk of jobs): Iteration 0 1 2 3 4 5 6 7 8 9 0 21.525 21.250 21.574 21.722 22.693 21.992 22.438 22.650 21.972 22.017 1 22.262 21.656 22.339 22.914 21.549 24.906 23.862 1531.189 1695.041 1491.255 2 36.071 21.619 22.074 22.927 23.455 27.239 22.640 22.802 633.956 1882.008 3 52.163 21.651 21.571 22.686 22.727 22.024 40.980 22.156 22.429 595.362 4 64.977 21.511 22.519 22.148 22.354 23.292 57.740 20.835 37.680 250.594 5 54.724 21.074 21.200 23.744 22.109 21.351 62.225 21.447 91.292 375.260 6 49.065 21.573 22.309 26.084 21.226 21.248 68.580 22.531 59.338 249.936 7 44.666 21.830 21.009 28.760 21.533 21.611 72.291 23.144 86.281 118.326 8 35.486 21.720 21.840 24.729 22.045 20.877 76.473 21.193 120.387 136.836 9 41.159 23.365 21.721 23.024 21.835 20.972 77.409 21.784 193.885 306.158 So usually writing of 10.000 "jobs"+"job_script" takes some 22 seconds but after some time performance massively breaks in. With other database backends we do not see this behaviour, see the following performance data of the same test done with PostgreSQL backend which is slower (as expected going over the network) but provides constant throughput: Iteration 0 1 2 3 4 5 6 7 8 9 0 36.937 37.110 36.952 37.279 37.580 37.364 37.950 37.390 37.682 37.439 1 37.464 38.110 37.679 38.366 37.576 37.624 37.476 37.412 37.265 37.727 2 36.394 37.635 37.347 37.603 37.402 37.515 37.802 37.898 37.355 37.939 3 37.213 37.539 36.771 37.706 37.055 37.780 37.283 37.488 36.955 37.460 4 36.554 37.557 37.368 37.960 37.070 37.892 37.459 37.857 37.228 37.833 5 37.047 38.164 37.167 37.885 37.268 37.676 37.355 37.572 37.347 37.569 6 37.118 37.735 36.857 37.602 36.717 37.716 37.444 37.685 37.085 38.151 7 36.787 37.647 36.844 37.601 36.934 37.440 37.632 37.291 37.174 37.926 8 36.884 37.560 37.117 37.239 37.034 37.748 37.289 37.635 36.822 37.693 9 37.178 37.496 36.849 37.799 37.289 37.644 37.461 37.622 37.022 37.670 We can reproduce the issue with a small C program (see attachment) which does essentially the same database operations as our database layer in Univa Grid Engine but depends only on liblmdb. It simulates the scenario described above and gives us the following performance data showing the extreme performance variation: Iteration 0 1 2 3 4 5 6 7 8 9 0 0.686 0.625 0.660 0.637 0.631 0.741 0.757 0.658 0.651 0.614 1 0.705 0.838 0.690 0.772 0.663 3.248 0.605 542.762 1114.374 898.477 2 13.336 1.299 0.659 0.637 0.626 0.712 11.172 0.663 29.833 1161.884 3 26.774 0.647 0.607 0.586 0.583 0.639 24.893 0.629 3.837 423.248 4 32.802 0.629 0.616 0.560 0.550 0.605 31.133 0.625 6.606 195.150 5 34.819 0.623 0.628 0.582 0.564 0.609 32.275 0.607 7.599 134.106 6 26.319 0.622 0.582 0.548 0.551 0.590 28.536 0.611 36.429 160.781 7 21.878 0.814 0.668 0.736 0.614 0.543 24.355 0.626 36.583 148.337 8 4.129 0.654 5.674 0.596 0.566 0.554 7.158 0.633 0.599 48.799 9 30.278 0.608 0.608 0.560 0.549 0.587 29.253 0.606 9.593 128.339 It can be compiled on Linux 64bit with gcc -I <path to lmdb>/include -L <path to lmdb>/lib -o test_lmdb_perf test_lmdb_perf.c -llmdb To run the given scenario call it with the following parameters: ./test_lmdb_perf <path to database directory> 10 10 10000 We built and ran it on - CentOS Linux release 7.7.1908 (Core) - Linux biber 3.10.0-1062.9.1.el7.x86_64 #1 SMP Fri Dec 6 15:49:49 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux - it was built with gcc (GCC) 7.2.1 20170829 (Red Hat 7.2.1-1) from devtoolset-7 -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 9054] Add support for multiple EECDH curves
by openldap-its＠openldap.org 24 Aug '20

24 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9054 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |FIXED --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE24: • aacec4c8 by Howard Chu at 2020-08-21T22:21:43+00:00 ITS#9054 Add support for multiple EECDH curves Requires OpenSSL 1.0.2 or newer • a9f42b12 by Howard Chu at 2020-08-21T23:02:11+00:00 ITS#9054, #9318 add new TLS options to slapd bindconf For use with back-ldap/back-meta/syncrepl/etc -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9326] New: Expose LDAP_OPT_X_TLS_NEWCTX on process signal
by openldap-its＠openldap.org 22 Aug '20

22 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9326 Issue ID: 9326 Summary: Expose LDAP_OPT_X_TLS_NEWCTX on process signal Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dar(a)xoe.solutions Target Milestone: --- After a process manager taking note of a certificate roll over, it will be convenient for such process manager to instruct the slapd daemon to set LDAP_OPT_X_TLS_NEWCTX for both client(s) and server(s) tls context through an IPC signal. Thereby servers would gain graceful support with minimal downtime for certificate rolling. Alternatively, dn=config _can_ be put in a shape so as to receive a dummy operation that induces a config reload. While this is possible, it is inconvenient for several reasons: 1. It requires a _dummy_ op, and thereby has the notion of a workaround 2. It triggers a reload of the entire config, instead of only renewing the tls context (educated guess on my side) 3. It requires the process manager to somehow gain directly or indirectly knowledge of the ldap protocol. This increases deployment complexity. 4. It requires special handling of authC and authZ for such process manager and thereby significantly increases deployment complexity - especially authZ in the context of immutable / gitops-controlled configs. 5. Those dummy operations have to be crafted against olcGlobal for the server and any database's olcSyncRepl configuration. Therefore a helper must also read given values and dummy-replace them back in. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 8427] Incorrect value of tls_reqcert in syncrepl
by openldap-its＠openldap.org 22 Aug '20

22 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=8427 --- Comment #28 from Howard Chu <hyc(a)openldap.org> --- Current code in master with this fix has also broken back-ldap when TLS was not requested - it is issuing a Start TLS request anyway, because bindconf_tls_set always initializes the sb_tls_ctx and when back-ldap ldap_back_prepare_conn sees a non-NULL sb_tls_ctx it tries to use it. The connection request then fails because the start_tls request fails. I'm currently seeing these errors in the slapd.1.log from test048. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9054] Add support for multiple EECDH curves
by openldap-its＠openldap.org 21 Aug '20

21 Aug '20

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

1 0

[Issue 9054] Add support for multiple EECDH curves
by openldap-its＠openldap.org 21 Aug '20

21 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9054 --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- additional in master for slapd: Commits: • 650b1404 by Howard Chu at 2020-08-21T20:06:56+01:00 ITS#9054, #9318 add new TLS options to slapd bindconf -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9054] Add support for multiple EECDH curves
by openldap-its＠openldap.org 21 Aug '20

21 Aug '20

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

1 0

[Issue 9054] Add support for multiple EECDH curves
by openldap-its＠openldap.org 21 Aug '20

21 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9054 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|OL_2_5_REQ | Target Milestone|2.5.0 |2.4.52 --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- OL head: Commits: • 2386a116 by Howard Chu at 2020-08-21T07:58:07+01:00 ITS#9054 Add support for multiple EECDH curves Requires OpenSSL 1.0.2 or newer -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9321] New: ldapsearch nettimeout doesn't work with startTls when the server address is not reachable
by openldap-its＠openldap.org 21 Aug '20

21 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9321 Issue ID: 9321 Summary: ldapsearch nettimeout doesn't work with startTls when the server address is not reachable Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: allen.zhang(a)audiocodes.com Target Milestone: --- We found that ldapsearch doesn't return with failure according to the nettimeout when the server address is not valid. it fails only after TCP timeout (about 120 seconds in my environment). we dug into in to the source code and found that : in common.c, we set the nettimeout after ldap_start_tls_s is called. We tried to call "ldap_set_option( ld, LDAP_OPT_NETWORK_TIMEOUT, (void *) &nettimeout )" before ldap_start_tls_s and it works well! -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9266] Replace custom hostname and IP address verification with OpenSSL API
by openldap-its＠openldap.org 20 Aug '20

20 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9266 --- Comment #5 from Quanah Gibson-Mount <quanah(a)openldap.org> --- See also https://lists.openldap.org/hyperkitty/list/openldap-announce@openldap.org/t… -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9266] Replace custom hostname and IP address verification with OpenSSL API
by openldap-its＠openldap.org 20 Aug '20

20 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9266 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dar(a)xoe.solutions --- Comment #4 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** Issue 9318 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 9309] New: slapd exits on failed assertion in ppolicy.c: 912 ctrls_cleanup
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9309 Issue ID: 9309 Summary: slapd exits on failed assertion in ppolicy.c: 912 ctrls_cleanup Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: jakealexis(a)gmail.com Target Milestone: --- Created attachment 753 --> https://bugs.openldap.org/attachment.cgi?id=753&action=edit slapd debug -1 output When trying to authenticate against slapd, it exits with an assertion failure: `slapd: ppolicy.c:912: ctrls_cleanup: Assertion `rs->sr_ctrls != NULL' failed.` I have searched quite extensively, and have found multiple previous bug reports with similar symptoms, often to do with the ppolicy overlay. Most of these have been marked as closed and fixed, but I'm using the latest version and still getting the same problem. I have found one RedHat bug with similar symptoms that described it as a config error, but with no details of what the config error is - and the assert statement doesn't help me narrow it down. I have tested this on 2.4.46 and 2.4.50, same behaviour. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9308] New: slapo-allow contrib module increments uninitialized variable
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9308 Issue ID: 9308 Summary: slapo-allow contrib module increments uninitialized variable Product: OpenLDAP Version: 2.4.51 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Line 335 declares "i" with no default value line 345 increments it Need to fix the for loop at 339 to ensure it is initialized before incrementation -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9304] New: Archived-At: -> 404
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9304 Issue ID: 9304 Summary: Archived-At: -> 404 Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- I appreciate this mailing list message header: Archived-At: <https://openldap.org/hyperkitty/list/openldap-technical@openldap.org/messag…> But unfortunately the link returns 404. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9294] New: ppolicy and replication: Multiple values for pwdLockedTime in violation of schema
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9294 Issue ID: 9294 Summary: ppolicy and replication: Multiple values for pwdLockedTime in violation of schema Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- If you have the following setup, a replica can end up with user entries in a non-schema compliant state: a) ppolicy is configured on provider(s) and replicas. Replica has schemachecking=off in its syncrepl configuration b) account gets locked on the replica, so pwdAccountLockedTime is set on the replica but not on the provider(s) c) admin does a MOD/ADD op against a provider for the user entry to add a value to pwdAccountLockedTime dn: ... changetype: modify add: pwdAccountLockedTime pwdAccountLockedTime: ... d) provider accepts this modification. e) replica accepts this modification f) account entry on replica now has two values for pwdAccountLockedTime in violation of it being a single valued attribute: "( 1.3.6.1.4.1.42.2.27.8.1.17 " "NAME ( 'pwdAccountLockedTime' ) " "DESC 'The time an user account was locked' " "EQUALITY generalizedTimeMatch " "ORDERING generalizedTimeOrderingMatch " "SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 " "SINGLE-VALUE " -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9289] New: Broken link to dmoz.org
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9289 Issue ID: 9289 Summary: Broken link to dmoz.org Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: cleydyr(a)gmail.com Target Milestone: --- At https://www.openldap.org/doc/admin24/intro.html, there's the following paragraph: --- A web directory, such as provided by the Open Directory Project <http://dmoz.org>, is a good example of a directory service. These services catalog web pages and are specifically designed to support browsing and searching. --- However, the Dmoz site is not at http://dmoz.org anymore. The user is redirected to an error page of a AWS S3 service if they try to access the link. Currently Dmoz has an archived version at https://dmoz-odp.org/ -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9287] New: ldap_create cause 10s delay in some scenario
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9287 Issue ID: 9287 Summary: ldap_create cause 10s delay in some scenario Product: OpenLDAP Version: 2.4.44 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: happy.mu(a)nokia-sbell.com Target Milestone: --- hi LDAP guys there has some issue in our product when we integrate ipv6. scenario: ipv4 internal + ipv6 external after ldap search finish, we need build ldap message by ldap_create function. some times the ldap_create message will cause 10s delay. for example: the ldap search has 4 ocs, and only the first oc's ldap_create will cause 10s delay, the fellowing ocs is within 0.0001s. we just think it may because the mutext is global and locked by other thread. could you help on this ? LOGs: there has 10s delay, and only execute ldap_create between them. 2020/07/08-16:32:11.942114-[INFO] 13 (DBL) [DBL_LlbSearchResponse:76]LLB replied successfully with [4] entries 2020/07/08-16:32:11.942181- [INFO] 13 (DBL) [DBL_LlbSearchResponse:125]Entry Buffer[0] : l_entryBerBufferPtr="0x64820136xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" 2020/07/08-16:32:21.957488 [INFO] 13 (DBL) [DBL_LlbSearchResponse:138]Successfully created LDAP dummy handle -- You are receiving this mail because: You are on the CC list for the issue.

1 16

[Issue 9285] New: Expose ppolicy control in the rootDSE
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9285 Issue ID: 9285 Summary: Expose ppolicy control in the rootDSE Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Currently the rootDSE does not expose the ppolicy control when ppolicy is instantiated. Generally the project has had a policy of not exposing controls for items that are not on a released RFC/standard. However, at this point, ppolicy is widely used, been around for years, and (eventually) the draft should get finalized. It would be useful to expose the control at this point. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9279] New: Support for Netscape password expiry controls
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9279 Issue ID: 9279 Summary: Support for Netscape password expiry controls Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Add support for legacy clients expecting the LDAP server to attach these controls on relevant bind responses: - Password Expired Control (2.16.840.1.113730.3.4.4) - Password Expiration Warning Control (2.16.840.1.113730.3.4.5) Decisions as configured by regular password policy. -- You are receiving this mail because: You are on the CC list for the issue.

1 24

[Issue 9275] New: Replace all references to master/slave with appropriate terminology
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9275 Issue ID: 9275 Summary: Replace all references to master/slave with appropriate terminology Product: OpenLDAP Version: 2.4.51 Hardware: All OS: All Status: UNCONFIRMED Severity: blocker Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- We need to replace all references to master/slave in the documentation, code comments etc. provider, consumer multimaster -> multiprovider -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9271] New: ldap_parse_intermediate undocumented
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9271 Issue ID: 9271 Summary: ldap_parse_intermediate undocumented 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: --- ldap_parse_intermediate is missing from manpages, should probably be included in ldap_parse_result.3. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9263] New: test064 fails on FreeBSD
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9263 Issue ID: 9263 Summary: test064 fails on FreeBSD Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- test064 fails when executed on FreeBSD because it tries to use /bin/bash. On FrreeBSD, this is /usr/local/bin/bash -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Bug 9262] New: Segmentation Fault on ldap_chain_op during Network Issues
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9262 Bug ID: 9262 Summary: Segmentation Fault on ldap_chain_op during Network Issues Product: OpenLDAP Version: 2.4.49 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: jeremy.diaz(a)rexconsulting.net Target Milestone: --- Created attachment 733 --> https://bugs.openldap.org/attachment.cgi?id=733&action=edit Full backtrace This is a follow up to the following OpenLDAP mailing list post: https://www.openldap.org/lists/openldap-technical/202001/msg00045.html The issue is as follows: Slapd crashes with a segmentation fault periodically and seems to occur most often during periods of high load. The issue seems to be related to the chain overlay. Some background info: This environment was originally made up of 3 producers and 6 consumers all on OpenLdap 2.4.48. Initially the issue did not appear to be caused directly by high load. We noticed that there was an uptick in saslauthd errors around the time when a crash occurred: Dec 11 07:23:20 {REDACTED} saslauthd[2720]: user ldap_search_st() failed: Timed out Dec 11 07:23:30 {REDACTED} saslauthd[2718]: user ldap_search_st() failed: Timed out Dec 11 07:23:40 {REDACTED} saslauthd[2718]: user ldap_search_st() failed: Timed out Dec 11 07:23:56 {REDACTED} saslauthd[2717]: user ldap_search_st() failed: Timed out Dec 11 07:23:57 {REDACTED} saslauthd[2720]: user ldap_search_st() failed: Timed out Dec 11 07:23:57 {REDACTED} saslauthd[2719]: user ldap_search_st() failed: Timed out Dec 11 07:24:05 {REDACTED} saslauthd[2718]: user ldap_search_st() failed: Timed out Dec 11 07:24:06 {REDACTED} saslauthd[2717]: user ldap_search_st() failed: Timed out Dec 11 07:24:54 {REDACTED} saslauthd[2719]: : write failure Dec 11 07:24:54 {REDACTED} saslauthd[2717]: : write failure Dec 11 07:24:54 {REDACTED} saslauthd[2719]: : write: Broken pipe Dec 11 07:24:54 {REDACTED} saslauthd[2717]: : write: Broken pipe Dec 11 07:24:54 {REDACTED} saslauthd[2718]: : write failure Dec 11 07:24:54 {REDACTED} saslauthd[2720]: : write failure Dec 11 07:24:54 {REDACTED} saslauthd[2718]: : write: Broken pipe Dec 11 07:24:54 {REDACTED} saslauthd[2720]: : write: Broken pipe Dec 11 07:25:04 {REDACTED} saslauthd[2721]: : write failure Dec 11 07:25:04 {REDACTED} saslauthd[2721]: : write: Broken pipe This seemed to indicate an issue with either AD, saslauthd or the ldap meta instance. Slapd with log level -1 did not return any obvious error messages. One consumer server was particularly problematic since it was in a data center that had a slower network connection. This server was also dealing with a subset of traffic corresponding to another one of our applications so overall there was more traffic going into this server than some the other servers. After some network improvements the segfault occurences dropped to about 1 every couple of days mostly confined to the problematic server. The environment was eventually updated to 2.4.49 but there was no obvious reduction in the number of segfaults. A while after an incident occurred that caused an increase in the latency of the network connections causing most of the slapd instances to crash constantly every few minutes. The crashing stopped only after the network latency was reduced. Ultimately what seemed to significantly reduce the number of segfaults was adding another 3 consumers to further reduce the load on each server. The following backtrace we captured seems to indicate that there is an issue with the chain overlay: #0 ldap_chain_op (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20, op_f=0x4a845e <ldap_back_search>, ref=ref@entry=0x0, depth=depth@entry=0) at chain.c:422 #1 0x00000000004e61da in ldap_chain_response (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at chain.c:1090 #2 0x000000000049d323 in over_back_response (op=0x7ffbe41f0870, rs=0x7ffbf09bbb20) at backover.c:237 #3 0x0000000000447c1a in slap_response_play (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20) at result.c:508 #4 0x00000000004480f5 in send_ldap_response (op=op@entry=0x7ffbe41f0870, rs=rs@entry=0x7ffbf09bbb20) at result.c:583 The issue ultimately seems to stem from slapd being really sensitive to network latency. The chain overlay appears to be attempting to dereference a value that never gets set due to a timeout mechanism being exceeded because of high load and/or high network latency as chain.c:422 seems to suggest: for ( ; !BER_BVISNULL( ref ); ref++ ) { Attached is the updated full backtrace of all the threads and below is the relevant portions of our olc configuration regarding the chain overlay: dn: olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcChainConfig olcOverlay: {1}chain olcChainCacheURI: FALSE olcChainMaxReferralDepth: 1 olcChainReturnError: TRUE dn: olcDatabase={0}ldap,olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {0}ldap olcDbStartTLS: ldaps starttls=no olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: TRUE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 dn: olcDatabase={1}ldap,olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {1}ldap olcDbURI: “{REDACTED URI 1}“ olcDbStartTLS: ldaps starttls=no tls_cacert=“/{REDACTED}/openldap/tls/ cacerts.cer" tls_reqcert=demand tls_crlcheck=none olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm ethod=simple timeout=0 network-timeout=0 binddn={REDACTED} credentials={REDACTED} keepalive=0:0:0 olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: TRUE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 dn: olcDatabase={2}ldap,olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {2}ldap olcDbURI: “{REDACTED URI 2}“ olcDbStartTLS: ldaps starttls=no tls_cacert=“/{REDACTED}/openldap/tls/ cacerts.cer" tls_reqcert=demand tls_crlcheck=none olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm ethod=simple timeout=0 network-timeout=0 binddn={REDACTED} credentials={REDACTED} keepalive=0:0:0 olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: TRUE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 dn: olcDatabase={3}ldap,olcOverlay={1}chain,olcDatabase={-1}frontend,cn=config objectClass: olcLDAPConfig objectClass: olcChainDatabase olcDatabase: {3}ldap olcDbURI: “{REDACTED URI 3}“ olcDbStartTLS: ldaps starttls=no tls_cacert=“/{REDACTED}/openldap/tls/ cacerts.cer" tls_reqcert=demand tls_crlcheck=none olcDbIDAssertBind: mode=self flags=prescriptive,proxy-authz-non-critical bindm ethod=simple timeout=0 network-timeout=0 binddn={REDACTED} credentials={REDACTED} keepalive=0:0:0 olcDbRebindAsUser: FALSE olcDbChaseReferrals: TRUE olcDbTFSupport: no olcDbProxyWhoAmI: TRUE olcDbProtocolVersion: 3 olcDbSingleConn: FALSE olcDbCancel: abandon olcDbUseTemporaryConn: FALSE olcDbConnectionPoolMax: 16 olcDbSessionTrackingRequest: FALSE olcDbNoRefs: FALSE olcDbNoUndefFilter: FALSE olcDbOnErr: continue olcDbKeepalive: 0:0:0 -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 9248] New: argon2 Makefile detects prefix incorrectly
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9248 Bug ID: 9248 Summary: argon2 Makefile detects prefix incorrectly Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- argon2 tries to auto-detect the prefix from the core Makefile, but gets it slightly wrong. $ make DESTDIR=/home/ryan/tmp/sysroot install mkdir -p /home/ryan/tmp/sysroot`grep -e "^prefix =" ../../../../Makefile | cut -d= -f2`/libexec/openldap mkdir: cannot create directory ‘/usr/libexec’: Permission denied make: *** [Makefile:63: install-lib] Error 1 $ grep -e "^prefix =" ../../../../Makefile | cut -d= -f2 /usr $ grep -e "^prefix =" ../../../../Makefile prefix = /usr The problem is the space after the equals sign. I'd probably just remove this auto-detection and default it to prefix=/usr/local, like every other contrib Makefile does, for the sake of simplicity. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 9227] New: Fix syncrepl exattrs to not delete local attrs
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9227 Bug ID: 9227 Summary: Fix syncrepl exattrs to not delete local attrs Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- An issue with syncrepl using exattrs is that the local replica may delete attrs that are being managed by locally deployed overlays such as memberOf (See bug#7400 for example). This behavior needs to be fixed so that the locally managed attributes are not deleted when included in an exattrs statement. -- You are receiving this mail because: You are on the CC list for the bug.

1 8

[Issue 9083] Broken link in the list of commercial support partners
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9083 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 7573] back-perl not working with cn=config
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=7573 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 7501] added TCP keepalive support to back_ldap
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=7501 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 9121] dynlist enhancements
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9121 --- Comment #7 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 12e11c9b by Howard Chu at 2020-08-18T23:49:26+00:00 ITS#9121 slapo-dynlist, -memberof: define memberOf if needed Ignore if it's defined already. Make it no-user-mod. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 8702] SLAPD_MAX_DAEMON_THREADS is too small
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=8702 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Status|UNCONFIRMED |RESOLVED See Also| |https://bugs.openldap.org/s | |how_bug.cgi?id=7926 Keywords|OL_2_5_REQ | --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Fixed as a part of ITS#7926 Commits: • 2f94318f by Howard Chu at 2020-08-18T22:00:58+01:00 ITS#7926 support multiple config cleanup functions per op Prep for main changes • 9d2f1530 by Howard Chu at 2020-08-18T22:37:50+01:00 ITS#7926 dynamic changes to olcListenerThreads Reallocates sockets from old to new listener threads -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 7926] modifying olcListenerThreads crashes slapd
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

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

1 0

[Issue 7926] modifying olcListenerThreads crashes slapd
by openldap-its＠openldap.org 19 Aug '20

19 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=7926 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |TEST Keywords|OL_2_5_REQ | Status|CONFIRMED |RESOLVED --- Comment #3 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 2f94318f by Howard Chu at 2020-08-18T22:00:58+01:00 ITS#7926 support multiple config cleanup functions per op Prep for main changes • 9d2f1530 by Howard Chu at 2020-08-18T22:37:50+01:00 ITS#7926 dynamic changes to olcListenerThreads Reallocates sockets from old to new listener threads -- You are receiving this mail because: You are on the CC list for the issue.

1 0

How to Add Tag in Website
by Anuj jindal 18 Aug '20

18 Aug '20

In our last blog we discussed the UGC NET JRF Eligibility Criteria (UGC NET JRF Admit Card, Eligibility Criteria & Exam Result). Hence the checklist for you to know your eligibility, let’s discuss the checklist of the UGC NET JRF exam that checks your efficiency. <a href="https://www.anujjindal.in/ugc-net-apply-online-syllabus-selection-criteria/">UGC NET JRF Selection Criteria</a>

1 0

[Issue 9135] mdb index corruption during legitimate delete
by openldap-its＠openldap.org 13 Aug '20

13 Aug '20

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

1 0

[Issue 9135] mdb index corruption during legitimate delete
by openldap-its＠openldap.org 13 Aug '20

13 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9135 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |TEST --- Comment #2 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • b0d73083 by Howard Chu at 2020-08-13T18:18:45+01:00 ITS#9135 fix index error on collapsed range -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9135] mdb index corruption during legitimate delete
by openldap-its＠openldap.org 13 Aug '20

13 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9135 Howard Chu <hyc(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Howard Chu <hyc(a)openldap.org> --- (In reply to Konstantin Andreev from comment #0) > Full_Name: Konstantin Andreev > Version: 2.4.48, git/master/44a7b46/20191203 > OS: Solaris 11.3 x64 > URL: > Submission from: (NULL) (79.135.238.172) > > > Here is a test case. > > 1) choose an attribute that has an equality index in your dit; > > 2) for this attribute choose a value that does not (and did not) exist in > the dit yet; > > Let assume you chose [o=1] attr/val pair. > > 3) add MDB_IDL_DB_MAX+1 ( = 0x10000 = 65536 ) entries having [o=1] > attr/val > pair. > > 4) delete last MDB_IDL_DB_MAX-1 of them in the order inverted as > compared to > the order of addition > > Now you have two entries having [o=1] attr/val pair. Let assume they are > > | $ ldapsearch -s sub -b 'ou=T' '(o=1)' o > | dn: cn=1,ou=T > | o: 1 > | > | dn: cn=2,ou=T > | o: 1 > > 5) delete one of the remaining entries, e.g. cn=2,ou=T > > Repeat the search: > > | $ ldapsearch -s sub -b 'ou=T' '(o=1)' o > | $ > > Nope, the remaining entry has been lost from the index forever. But it is > still > in the dit: > > | $ ldapsearch -s one -b 'ou=T' '(objectclass=*)' o > | dn: cn=1,ou=T > | o: 1 > | > | dn: ou=A,ou=T > | ... > > You need to slapindex to restore `o' index to a valid state, but you may not > know you need to repair the index. > > The probability of this scenario is negligible, because indexed entries never > form continuous block of ids of many-thousand length, but the code for this > scenario exists and has a bug. Thanks for the report. Fixed now in master. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9312] New: Getting connection_read(23): no connection!
by openldap-its＠openldap.org 11 Aug '20

11 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9312 Issue ID: 9312 Summary: Getting connection_read(23): no connection! Product: OpenLDAP Version: 2.4.44 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: shaheena.kazi(a)gmail.com Target Milestone: --- Hi, I have a connection_read(23): no connection! message in my syslog. This does not affect the functionality of anything on system but is simply present in the logs. Also, it comes randomly. No wrong password error or no such issues. I have referred the ID's - 8781 and 6548. But it does not help. Secondly, I have updated the consolidated patch for the openldap version from the openldap/patches website. that too does not help. We want to know why this messages come in the logs ? Regarding, This commonly occurs when a client ends the connection without properly ending an unbind request first. The solution would be to fix the client involved. -- What does the client server need to do here ? I mean what is to be handled correctly ? Is there any configuration miss ? Awaiting your response. - Shaheena K -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9313] New: TLS 1.3 Support on 2.4.44
by openldap-its＠openldap.org 11 Aug '20

11 Aug '20

https://bugs.openldap.org/show_bug.cgi?id=9313 Issue ID: 9313 Summary: TLS 1.3 Support on 2.4.44 Product: OpenLDAP Version: 2.4.44 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: shaheena.kazi(a)gmail.com Target Milestone: --- Hello, I wanted to know if TLSv1.3 is supported on openldap 2.4.44 If no, then what about on openldap 2.4.47 ? Awaiting your response. Regards, Shaheena K -- You are receiving this mail because: You are on the CC list for the issue.

1 3

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs