- openldap-bugs - openldap.org

[Issue 9659] New: slapd fails to compile with LDAP_PF_LOCAL_SENDMSG: redefinition of 'peerbv'
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9659 Issue ID: 9659 Summary: slapd fails to compile with LDAP_PF_LOCAL_SENDMSG: redefinition of 'peerbv' Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- Thanks for fixing issue 9658. The same test environment (Debian GNU/Hurd 11.0) now fails to compile slapd (RE25 and master): cc -g -O2 -I../../include -I. -I./slapi -I. -I../../include -c -o daemon.o daemon.c daemon.c: In function 'slap_listener': daemon.c:2113:16: error: redefinition of 'peerbv' 2113 | struct berval peerbv = BER_BVNULL; | ^~~~~~ daemon.c:2110:16: note: previous definition of 'peerbv' was here 2110 | struct berval peerbv = BER_BVC(peername); | ^~~~~~ <builtin>: recipe for target 'daemon.o' failed make[2]: *** [daemon.o] Error 1 The relevant code in daemon.c: char peername[LDAP_IPADDRLEN]; struct berval peerbv = BER_BVC(peername); #ifdef LDAP_PF_LOCAL_SENDMSG char peerbuf[8]; struct berval peerbv = BER_BVNULL; #endif When LDAP_PF_LOCAL_SENDMSG is defined, the variable 'peerbv' is declared twice. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9696] New: OpenSSL implementation of LDAP_OPT_X_TLS_PEERCERT leaks memory
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9696 Issue ID: 9696 Summary: OpenSSL implementation of LDAP_OPT_X_TLS_PEERCERT leaks memory Product: OpenLDAP Version: 2.4.57 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: cheimes(a)redhat.com Target Milestone: --- The OpenSSL implementation of ldap_get_option() LDAP_OPT_X_TLS_PEERCERT leaks memory. The internal function tlso_session_peercert() uses SSL_get_peer_certificate() to access the server certificate. SSL_get_peer_certificate() increases the reference counter of the peer cert by one. The code is missing a X509_free() call to decref the internal reference counter by one. I also recommend that you check the return value of SSL_get_peer_certificate() for NULL. There are cases when a TLS session does not have access to a peer certificate, e.g. session resumption. Valgrind log: ==586962== 16,044 (1,056 direct, 14,988 indirect) bytes in 3 blocks are definitely lost in loss record 6,355 of 6,374 ==586962== at 0x484086F: malloc (vg_replace_malloc.c:380) ==586962== by 0x16981A4D: CRYPTO_zalloc (mem.c:230) ==586962== by 0x168CC823: asn1_item_embed_new (tasn_new.c:122) ==586962== by 0x168CE12A: asn1_item_embed_d2i (tasn_dec.c:325) ==586962== by 0x168CE341: ASN1_item_ex_d2i (tasn_dec.c:124) ==586962== by 0x168CE3CE: ASN1_item_d2i (tasn_dec.c:114) ==586962== by 0x1744B7CC: tls_process_server_certificate (statem_clnt.c:1853) -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9668] New: undefined behavior for isdigit in tls2.c
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9668 Issue ID: 9668 Summary: undefined behavior for isdigit in tls2.c Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: roland.illig(a)gmx.de Target Milestone: --- tls2.c says: > isdigit( *c ) This invokes undefined behavior if someone manages to pass a non-ASCII character. Depending on the platform, the process may crash or wrongly classify the host name as either numeric or non-numeric. While here, I noticed that both sni and c have type 'char *', but they should rather be 'const char *'. Was there a specific reason to suggest to the reader the host name would be modifiable? -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9706] New: monitoringslapd.sdf: typo Backends
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9706 Issue ID: 9706 Summary: monitoringslapd.sdf: typo Backends Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- doc/guide/admin/monitoringslapd.sdf contains: H3: Backends The {{EX:cn=Backends,cn=Monitor}} object, itself, provides a list of available backends. The list of available backends all builtin backends, as well as backends loaded by modules. For example: … The second sentence has no verb. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9699] New: doc/admin25/loadbalancer.html: typo “between a a set of running slapd instances”
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9699 Issue ID: 9699 Summary: doc/admin25/loadbalancer.html: typo “between a a set of running slapd instances” Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- -- You are receiving this mail because: You are on the CC list for the issue.

1 2

[Issue 9693] New: Section 9.6 html formatting issue
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9693 Issue ID: 9693 Summary: Section 9.6 html formatting issue Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: mnormann(a)symas.com Target Milestone: --- Section 9.6 of documentation is missing a closing anchor tag and closing title tag (Glued/Subordinate database configurations) -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9689] New: Redundancy in the description of syncprov-nopresent
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9689 Issue ID: 9689 Summary: Redundancy in the description of syncprov-nopresent Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- https://www.openldap.org/devel/admin/replication.html#Set%20up%20the%20prov… says: “““ The nonpresent option **should only be configured if the overlay is being placed on top of a log database**, such as when used with delta-syncrepl. The nonpresent option is configured by the syncprov-nopresent <TRUE|FALSE> directive. This value **should only be set TRUE for a syncprov instance on top of a log database** (such as one managed by the accesslog overlay). The default is FALSE. ””” I think, the circumstances when the option shall be used, are repeated twice. One of the repetitions can be shortened. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9688] New: Is EQ index on entryCSN mandatory for replication?
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9688 Issue ID: 9688 Summary: Is EQ index on entryCSN mandatory for replication? Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- https://www.openldap.org/devel/admin/replication.html says about the EQ index on entryCSN: “On databases which support inequality indexing, setting an eq index on the entryCSN attribute and configuring contextCSN checkpoints will greatly speed up this scanning step.” → The index is recommended, but not mandatory, and not always possible. man 5 slapo-syncprov / https://www.openldap.org/software/man.cgi?query=slapo-syncprov&apropos=0&se… says “On databases that support inequality indexing, it is mandatory to set an eq index on the entryCSN attribute when using this overlay.” Between both documents there is a discrepancy, whether the EQ index is mandatory or not. -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9687] New: olcTLSECName is not required in order to use ECDHE-based cipher suites in OpenSSL
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9687 Issue ID: 9687 Summary: olcTLSECName is not required in order to use ECDHE-based cipher suites in OpenSSL Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- SLAPD-CONFIG(5) says that olcTLSECName is used to set the names of the Elliptic Curves. It does not say, that the option is required, nor does it say what happens, when the option is not set. https://www.openldap.org/doc/admin25/tls.html#TLS%20Configuration says for TLSECName: This is required in order to use ECDHE-based cipher suites in OpenSSL. I do not set TLSECName and call ./testssl.sh ldap.aegee.org:636 which prints: Hexcode Cipher Suite Name (OpenSSL) KeyExch. Encryption Bits Cipher Suite Name (IANA/RFC) ----------------------------------------------------------------------------------------------------------------------------- TLSv1 (server order) xc014 ECDHE-RSA-AES256-SHA ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA xc013 ECDHE-RSA-AES128-SHA ECDH 256 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLSv1.1 (server order) xc014 ECDHE-RSA-AES256-SHA ECDH 256 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA xc013 ECDHE-RSA-AES128-SHA ECDH 256 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLSv1.2 (server order) xc030 ECDHE-RSA-AES256-GCM-SHA384 ECDH 253 AESGCM 256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 xcca8 ECDHE-RSA-CHACHA20-POLY1305 ECDH 253 ChaCha20 256 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 xc02f ECDHE-RSA-AES128-GCM-SHA256 ECDH 253 AESGCM 128 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 xc028 ECDHE-RSA-AES256-SHA384 ECDH 253 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 xc027 ECDHE-RSA-AES128-SHA256 ECDH 253 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 xc014 ECDHE-RSA-AES256-SHA ECDH 253 AES 256 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA xc013 ECDHE-RSA-AES128-SHA ECDH 253 AES 128 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLSv1.3 (server order) x1302 TLS_AES_256_GCM_SHA384 ECDH 253 AESGCM 256 TLS_AES_256_GCM_SHA384 x1303 TLS_CHACHA20_POLY1305_SHA256 ECDH 253 ChaCha20 256 TLS_CHACHA20_POLY1305_SHA256 x1301 TLS_AES_128_GCM_SHA256 ECDH 253 AESGCM 128 TLS_AES_128_GCM_SHA256 Testing robust forward secrecy (FS) -- omitting Null Authentication/Encryption, 3DES, RC4 Elliptic curves offered: prime256v1 secp384r1 secp521r1 X25519 X448 This means, that when olcTLSECName is not set, OpenSSL defaults are used, and ECDHE-based cipher suites are still offered. testssl.sh can be obtianed from https://github.com/drwetter/testssl.sh . -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9674] New: Is olcMonitoring enabled by default for MDB?
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9674 Issue ID: 9674 Summary: Is olcMonitoring enabled by default for MDB? Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- The manual page doc/man/man5/slapd-config.5 misses a .TP before .B olcMonitoring. In turn at https://www.openldap.org/software/man.cgi?query=slapd-config&apropos=0&sekt… olcMonitoring appears in the description of olcMultiProvider . The same man page says, that only MBD supports the olcMonitoring mechanims and the default for olcMonitoring depends on the backend. The documentation for mdb does not say, if olcMonitoring is by default enabled or disabled -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9669] New: Incorrect Heimdal download site in OpenLDAP Administrator's Guide
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9669 Issue ID: 9669 Summary: Incorrect Heimdal download site in OpenLDAP Administrator's Guide Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: dewayne.geraghty(a)heuristicsystems.com.au Target Milestone: --- In section 4.2.3 page 18 of latest OpenLDAP 2.5 Admin Guide has Heimdal available from http://www.pdc.kth.se/heimdal/ which is a dead link. The more correct location is https://github.com/heimdal/heimdal (Thank-you for your great software!) -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9646] New: slapd-meta: deprecations in 2.4: “try-propagate is highly deprecated”
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9646 Issue ID: 9646 Summary: slapd-meta: deprecations in 2.4: “try-propagate is highly deprecated” Product: OpenLDAP Version: 2.5.4 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- The upgrade instructions from 2.4 at https://www.openldap.org/doc/admin25/appendix-upgrading.html says > B.4. ldap and meta backends > > Several deprecated configuration directives for slapd-ldap(5) and slapd-meta(5) have been removed. Configurations using those directive must be updated to use supported directives prior to upgrade. See the slapd-ldap(5) and slapd-meta(5) man pages from OpenLDAP 2.4 for a list of deprecated directives. The slapd-meta(5) for 2.4 says at https://www.openldap.org/software/man.cgi?query=slapd-meta&apropos=0&sektio… , when I search for “deprecated”: > tls {[try-]start|[try-]propagate} > The try- prefix instructs the proxy to continue operations if the StartTLS operation failed; its use is highly deprecated. ... > DEPRECATED STATEMENTS > The following statements have been deprecated and should no longer be used. > pseudorootdn <substitute DN in case of rootdn bind> > Use idassert-bind instead. > > pseudorootpw <substitute password in case of rootdn bind> > Use idassert-bind instead. I object the wording “highly deprecated”. It should be “highly discouraged”. With the current wording it is not very clear, whether the try- variants disappeared in 2.5 -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9656] New: slapd (2.5.7) crashes when ppm settings don't exist in the schema
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9656 Issue ID: 9656 Summary: slapd (2.5.7) crashes when ppm settings don't exist in the schema Product: OpenLDAP Version: unspecified Hardware: x86_64 OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: ktmdms(a)gmail.com Target Milestone: --- using ppolicy with ppm causes slapd to crash (2.5.7. I would have selected that as the version but it's not available to be selected) when pwdCheckModuleArg doesn't exist in the schema and/or the full path to ppm.so isn't defined in pwdCheckModule. at the time slapd would crash, pwdCheckModule was set to ppm.so not the full path of /usr/local/libexec/openldap/ppm.so and the pwdCheckModuleArg attribute didn't exist at all. whenever I would attempt to change my user password, slapd would crash. setting the full path and creating and setting the Arg attribute has stopped that behavior but I'm unsure if it was simply added the attribute or some combination of setting the full path, creating the attribute, and populating the attribute. fwiw, the attribute is set as: bWluUXVhbGl0eSA0Cm1heExlbmd0aCAwCmNoZWNrUkROIDEKZm9yYmlkZGVuQ2hhcnMgCmNsYXNz LXVwcGVyQ2FzZSBBQkNERUZHSElKS0xNTk9QUVJTVFVWV1hZWiAxIDEKY2xhc3MtbG93ZXJDYXNl IGFiY2RlZmdoaWprbG1ub3BxcnN0dXZ3eHl6IDEgMQpjbGFzcy1kaWdpdCAwMTIzNDU2Nzg5IDEg MQpjbGFzcy1zcGVjaWFsIDw+LD87LjovIcKnw7klKsK1XsKoJMKjwrImw6l+IiMneyhbLXzDqGBf XMOnXsOgQCldwrA9fSsgMSAxCgo= -- You are receiving this mail because: You are on the CC list for the issue.

1 23

[Issue 9644] New: provide a man page for ppm
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9644 Issue ID: 9644 Summary: provide a man page for ppm Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: contrib Assignee: bugs(a)openldap.org Reporter: david.coutadeur(a)gmail.com Target Milestone: --- Provide a man page for ppm proposed PR is coming -- You are receiving this mail because: You are on the CC list for the issue.

1 8

[Issue 9648] New: 'MAXPATHLEN' undeclared on some systems
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9648 Issue ID: 9648 Summary: 'MAXPATHLEN' undeclared on some systems Product: OpenLDAP Version: 2.5.4 Hardware: All OS: Linux Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: git(a)freundtech.com Target Milestone: --- Created attachment 834 --> https://bugs.openldap.org/attachment.cgi?id=834&action=edit Docker reproduction I'm trying to compile OpenLDAP 2.5.7 on Alpine Linux, but have verified that the problem exists since 2.5.4. Version 2.4.59 compiles correctly with everything else equal. Compilation fails with In file included from ldap-int.h:119, from request.c:53: request.c: In function 'ldap_dump_connection': ../../include/ldap_pvt.h:181:25: error: 'MAXPATHLEN' undeclared (first use in this function) 181 | #define LDAP_IPADDRLEN (MAXPATHLEN + sizeof("PATH=")) | ^~~~~~~~~~ request.c:859:17: note: in expansion of macro 'LDAP_IPADDRLEN' 859 | char from[LDAP_IPADDRLEN]; | ^~~~~~~~~~~~~~ ../../include/ldap_pvt.h:181:25: note: each undeclared identifier is reported only once for each function it appears in 181 | #define LDAP_IPADDRLEN (MAXPATHLEN + sizeof("PATH=")) | ^~~~~~~~~~ request.c:859:17: note: in expansion of macro 'LDAP_IPADDRLEN' 859 | char from[LDAP_IPADDRLEN]; | ^~~~~~~~~~~~~~ make[2]: Leaving directory '/tmp/openldap/libraries/libldap' Thanks to JoBbZ on IRC I found out that including <ac/param.h> in ldap_pvt.h seems to fix the issue. My best guess as to why this fails on Alpine Linux and not on other distributions is that Alpine uses musl instead of glibc as it's libc implementation. I have attacked an (unfinished) dockerfile for reproduction of the issue. -- You are receiving this mail because: You are on the CC list for the issue.

1 17

[Issue 9712] New: back-mdb multival delete isn't deleting
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9712 Issue ID: 9712 Summary: back-mdb multival delete isn't deleting Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hyc(a)openldap.org Target Milestone: --- When deleting an entry that has multival-related attributes, those attribute values weren't getting deleted. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9631] New: slapd-wt tests often fail/timeout
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9631 Issue ID: 9631 Summary: slapd-wt tests often fail/timeout Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ondra(a)mistotebe.net Target Milestone: --- Since merging wt into master, tests started to fail ~80-90% of the time, partly due to bugs in wt (https://git.openldap.org/openldap/openldap/-/jobs/8458) or timeouts in CI. I am about to remove the backend from make test for now (keeping it in alltests), opening this issue to discuss further. -- You are receiving this mail because: You are on the CC list for the issue.

1 9

[Issue 9463] New: back-wt: cumulative fix
by openldap-its＠openldap.org 11 Oct '21

11 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9463 Issue ID: 9463 Summary: back-wt: cumulative fix Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: hamano(a)osstech.co.jp Target Milestone: --- Hi, This is cumulative fix for back-wt. I'm sorry to making 2.5 patch has been delayed due to we're still using 2.4. -- You are receiving this mail because: You are on the CC list for the issue.

1 8

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

07 Oct '21

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

1 0

[Issue 6097] MMR problems with deletes
by openldap-its＠openldap.org 07 Oct '21

07 Oct '21

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

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 05 Oct '21

05 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #22 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE26: • ce073522 by Ondřej Kuzník at 2021-10-05T01:42:43+00:00 ITS#6949 Fix and emit error messages • 15ac53a7 by Ondřej Kuzník at 2021-10-05T01:42:48+00:00 ITS#6949 Remove dead code from lloadd • 466e0321 by Ondřej Kuzník at 2021-10-05T01:42:52+00:00 ITS#6949 Port rest of the features to lloadd -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 05 Oct '21

05 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=6949 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |TEST --- Comment #21 from Quanah Gibson-Mount <quanah(a)openldap.org> --- • a3dea08c by Ondřej Kuzník at 2021-10-04T14:46:22+01:00 ITS#6949 Fix and emit error messages • 8894f00f by Ondřej Kuzník at 2021-10-04T14:46:26+01:00 ITS#6949 Remove dead code from lloadd • 3c07544b by Ondřej Kuzník at 2021-10-04T14:46:26+01:00 ITS#6949 Port rest of the features to lloadd -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 04 Oct '21

04 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #20 from Ondřej Kuzník <ondra(a)mistotebe.net> --- I would also note that there's a fair amount of fprintf( stderr, ... ) peppered around the code, that might also need cleaning up at some point. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9692] New: Insertion rate in large groups slows unexpectedly
by openldap-its＠openldap.org 04 Oct '21

04 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9692 Issue ID: 9692 Summary: Insertion rate in large groups slows unexpectedly Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: smckinney(a)symas.com Target Milestone: --- Created attachment 843 --> https://bugs.openldap.org/attachment.cgi?id=843&action=edit slapd.conf Observed during jmeter tests[1] that perform ldapmod operations, adding members into a group. The insertion speed decreases unexpectedly, as the size of the group increases. A test run starts 10 jmeter threads, each doing 1000 mods = 100,000 members added altogether to a group. At the beginning of the test, throughput is approximately 200/s. At the end, the mod rate slows down to < 10/s. Multival and sortval are enabled (slapd.conf attached): sortvals member multival member 500,3 *** Server info Ubuntu20 2 CPU Cores 4GB RAM symas-openldap-server 2.5.7-1focal1 *** To verify multival is enabled: ``` data/dc=example,dc=com# mdb_stat -s id2v . Status of id2v Tree depth: 1 Branch pages: 0 Leaf pages: 1 Overflow pages: 0 Entries: 746316 ``` [1][ldap-load-gen](https://gitlab.symas.net/symas-public/ldap-load-gen) -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9639] New: slapd -r : what must be present in the chroot environment
by openldap-its＠openldap.org 01 Oct '21

01 Oct '21

https://bugs.openldap.org/show_bug.cgi?id=9639 Issue ID: 9639 Summary: slapd -r : what must be present in the chroot environment Product: OpenLDAP Version: 2.4.59 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- `man slapd` - https://www.openldap.org/software/man.cgi?query=slapd&apropos=0&sektion=0&m… - says that the -r option calls chroot. Please clarify, what must be present in the chroot environment: /proc, /tmp, /dev/shm , libc -- You are receiving this mail because: You are on the CC list for the issue.

1 14

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 30 Sep '21

30 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #19 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: • 66c62841 by Howard Chu at 2021-09-30T04:23:29+01:00 ITS#6949 fixup loglevel delete, consolidate redundant code RE26: • e2739d9f by Howard Chu at 2021-09-30T15:32:11+00:00 ITS#6949 fixup loglevel delete, consolidate redundant code -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9156] latest ppolicy draft support
by openldap-its＠openldap.org 30 Sep '21

30 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9156 --- Comment #15 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: commit 4cd096defffc278f13edf9a194f4bc62095a947e Author: Ondřej Kuzník <ondra(a)mistotebe.net> Date: Mon Jun 7 15:52:25 2021 +0100 ITS#9156 Do not spam the logs on account of lastbind Re25: • 667ea288 by Ondřej Kuzník at 2021-09-30T16:02:34+00:00 ITS#9156 Do not spam the logs on account of lastbind -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9710] New: integrated lastbind debug statement at ANY level
by openldap-its＠openldap.org 30 Sep '21

30 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9710 Issue ID: 9710 Summary: integrated lastbind debug statement at ANY level Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For some reason, a debug statement for the newly integrated lastbind code is logging at ANY level, which seems incorrect: Debug( LDAP_DEBUG_ANY, "fe_op_lastbind: " "old pwdLastSuccess value=%s %lds ago\n", a->a_nvals[0].bv_val, bindtime == (time_t)-1 ? -1 : op->o_time - bindtime ); This results in log lines with every bind like: Sep 30 01:41:42 ub18 slapd[5980]: fe_op_lastbind: old pwdLastSuccess value=20210930014121Z 21s ago I think a different loglevel should be in use here. -- You are receiving this mail because: You are on the CC list for the issue.

1 4

[Issue 9156] latest ppolicy draft support
by openldap-its＠openldap.org 30 Sep '21

30 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9156 --- Comment #14 from Quanah Gibson-Mount <quanah(a)openldap.org> --- *** Issue 9710 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 6949] OpenLDAP Logging
by openldap-its＠openldap.org 29 Sep '21

29 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #18 from Quanah Gibson-Mount <quanah(a)openldap.org> --- head: Commits: • 10fb8c0a by Howard Chu at 2021-09-29T14:39:28+01:00 ITS#6949 fix logfile_only regression in prev commit RE26: Commits: • 74d1475a by Howard Chu at 2021-09-29T21:29:15+00:00 ITS#6949 fix logfile_only regression in prev commit -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9708] New: null (empty) attribute values of type Directory String pass the dry-run validation
by openldap-its＠openldap.org 29 Sep '21

29 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9708 Issue ID: 9708 Summary: null (empty) attribute values of type Directory String pass the dry-run validation Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: mheyman(a)symas.com Target Milestone: --- On behalf of Aaron Bliss at Paychex ---- I'm pretty confident that I've identified a bug when running slapadd with the dry-run switch. As a step of migrating a given replica set from oDSEE to OpenLDAP, we of course make use of the dry-run switch after sanitizing a given oDSEE export. However on a few migrations I've noticed that null (empty) attribute values of type Directory String (which are illegal per the RFC) pass the dry-run validation. This becomes really problematic because a subsequent slapadd in which the quick switch is passed will load the invalid data into the database. I understand that loading a given ldif using the quick switch performs fewer consistency checks on the input data however with our largest dataset's, it's not viable for us to migrate a given replica set from oDSEE to OpenLDAP without using the quick switch (it would require an outage that's far longer than we can allow for on the customer side of things). It makes total sense for sure that OpenLDAP will not allow for null values for this attribute type in keeping with the standard but unfortunately oDSEE allows for it as such we have to account for it. Would it be possible to catch the null attribute value scenario when performing a dry run and if so is there any way this could be prioritized (doing so would be of tremendous help to us)? If not then I'll have to write my own validation (not at all ideal) to check for this scenario but for sure would be better if slapadd can catch this condition. Thanks much as always. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 27 Sep '21

27 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #17 from Quanah Gibson-Mount <quanah(a)openldap.org> --- RE26: • c23c6563 by Howard Chu at 2021-09-27T19:20:18+00:00 ITS#6949 honor specified loglevel, not just debuglevel -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 27 Sep '21

27 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|hyc(a)openldap.org |ondra(a)mistotebe.net --- Comment #16 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Assigning to Ondrej for the load balancer portion -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 27 Sep '21

27 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #15 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Commits: • 77adb192 by Howard Chu at 2021-09-27T16:54:24+00:00 ITS#6949 honor specified loglevel, not just debuglevel But skip calls to syslog() if logfile_only is set. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9709] New: Invalid link for Symas website
by openldap-its＠openldap.org 27 Sep '21

27 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9709 Issue ID: 9709 Summary: Invalid link for Symas website Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- The Symas website link in the powered by portion is invalid. -- You are receiving this mail because: You are on the CC list for the issue.

1 1

[Issue 9705] New: synprov put add info into wrong cookie while performing test059-consumer-config
by openldap-its＠openldap.org 27 Sep '21

27 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9705 Issue ID: 9705 Summary: synprov put add info into wrong cookie while performing test059-consumer-config Product: OpenLDAP Version: 2.4.59 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: overlays Assignee: bugs(a)openldap.org Reporter: gil77for(a)gmail.com Target Milestone: --- There is an issue with syncrepl and syncprov working together in parallel. The issue can be seen in provider LDAP server logs of test059-consumer-config. For linux this problem does not cause the test to malfunction, but it may cause replication to malfunction on other systems (or possibly on linux in a different situation from the test). In case of OpenVMS we have this issue. The problem is detected under the following circumstances, followed by a step-by-step description of the actions in test 059 that lead to malfunction: 1. Adding replication configuration for the dn: olcDatabase={1}ldif,cn=config dn: olcDatabase={1}ldif,cn=config changetype: modify add: olcSyncrepl olcSyncrepl: {0}rid=001 provider=ldap://localhost:9001/ binddn="cn=config" bindmethod=simple credentials=******** searchbase="cn=schema,cn=config" type=refreshAndPersist retry="3 5 300 5" timeout=3 suffixmassage="cn=schema,cn=config,cn=consumer" this registers a syncInfo structure with the parameter rid=001 inside the syncrepl engine. the corresponding syncCookie and cookieState are also created inside this structure 2. adding includes by ldapadd to the configuration, this causes {1}ldif,cn=config to be filled on the provider and register this adding in rid=001 syncInfo cookies with sid=001: include: file:///LDAP$SCHEMA:core.ldif include: file:///LDAP$SCHEMA:cosine.ldif include: file:///LDAP$SCHEMA:inetorgperson.ldif include: file:///LDAP$SCHEMA:openldap.ldif include: file:///LDAP$SCHEMA:nis.ldif 3. Adding replication configuration for the dn: olcDatabase={1}mdb,cn=config,cn=consumer: dn: olcDatabase={1}mdb,cn=config,cn=consumer objectClass: olcDatabaseConfig objectClass: olcmdbConfig olcDatabase: {1}mdb olcSuffix: dc=example,dc=com olcDbDirectory: [.testdir.db_2_a] olcRootDN: cn=Manager,dc=example,dc=com olcRootPW: secret olcSyncRepl: rid=002 provider=ldap://localhost:9001/ binddn="cn=Manager,dc=example,dc=com" bindmethod=simple credentials=secret searchbase="dc=example,dc=com" type=refreshAndPersist retry="3 5 300 5" timeout=3 olcUpdateRef: ldap://localhost:9001/ this registers new syncInfo structure with the parameter rid=002 inside the syncrepl engine. Should also be added info into cookies of this structure but this is the issue. The info about {1}mdb,cn=config,cn=consumer is added to the cookie of structure with rid=001 (!!!). Thus the cookie about {1}ldif is overrides by this new cookie data. It can be seen in provider server logs (was run on linux): …… 61275c7d ldif_back_add: "olcDatabase={1}mdb,cn=config,cn=consumer" 61275c7d oc_check_required entry (olcDatabase={1}mdb,cn=config,cn=consumer), objectClass "olcMdbConfig" …… 61275c7d slap_get_csn: conn=1007 op=3 generated new csn=20210826091853.649104Z#000000#001#000000 manage=1 61275c7d slap_queue_csn: queueing 0x7fcdf4106bc0 20210826091853.649104Z#000000#001#000000 61275c7d ldif_write_entry: wrote entry "olcDatabase={1}mdb,cn=config,cn=consumer" 61275c7d ldif_back_add: err: 0 text: 61275c7d send_ldap_result: conn=1007 op=3 p=3 61275c7d send_ldap_result: err=0 matched="" text="" 61275c7d conn=1007 op=3 syncprov_matchops: recording uuid for dn=olcDatabase={1}mdb,cn=config,cn=consumer on opc=0x7fcdf4001608 …… 61275c7d slap_graduate_commit_csn: removing 0x7fcdf4106bc0 20210826091853.649104Z#000000#001#000000 61275c7d conn=1004 op=1 syncprov_sendresp: cookie=rid=001,sid=001,csn=20210826091853.649104Z#000000#001#000000 61275c7d conn=1004 op=1 syncprov_sendresp: sending LDAP_SYNC_ADD, dn=olcDatabase={1}mdb,cn=config,cn=consumer …… rid=002 should be there! When running on linux, this does not cause a problem for the test, because syncprov task works later than the ldif database replication on consumer by syncrepl task. And the overlapped cookie entry does not matter anymore. In our case (OpenVMS) the order of asynchronous tasks (syncrepl and syncprov) is different and overwriting the cookie leads to loss of ldif database replication and failure of the test. The consumer does not receive scheme data. The differences in the order of tasks are caused by the features of pthreads library implementation for the VMS. But it should not matter for LDAP operation. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9703] New: init_config_ocs: register_oc failed
by openldap-its＠openldap.org 23 Sep '21

23 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9703 Issue ID: 9703 Summary: init_config_ocs: register_oc failed Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: goudal(a)enseirb.fr Target Milestone: --- Hello, I just compiled openldap2.5.7 from source with the following command : ./configure '--enable-overlays' '--enable-crypt' '--with-tls' '--enable-backends' '--with-cyrus-sasl' '--disable-ndb' '--enable-modules' Distribution is Ubuntu20.04 When I start slapd it exits with the error init_config_ocs: register_oc failed With -d -1 flag I got the the following : 6149e48c.212556fe 0x7f20fc933740 wt_back_initialize: initialize WiredTiger backend 6149e48c.21544f14 0x7f20fc933740 wt_back_initialize: WiredTiger 2.9.3: (June 26, 2017) 6149e48c.21558481 0x7f20fc933740 register_oc: objectclass "( OLcfgDbOc:9.1 NAME 'olcWtConfig' DESC 'Wt backend configuration' SUP olcDatabaseConfig MUST olcDbDirectory MAY ( olcWtConfig $ olcDbIndex ) )": Inconsistent duplicate \ objectClass, 1.3.6.1.4.1.4203.1.12.2.4.2.9.1 -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9690] New: 2.5.7: test suite is failing
by openldap-its＠openldap.org 23 Sep '21

23 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9690 Issue ID: 9690 Summary: 2.5.7: test suite is failing Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: kloczko.tomasz(a)gmail.com Target Milestone: --- Created attachment 842 --> https://bugs.openldap.org/attachment.cgi?id=842&action=edit Test suite log Source code configured with below options: %configure \ --disable-debug \ --disable-ndb \ --disable-slp \ --disable-sql \ --disable-wt \ --disable-static \ --enable-backends=mod \ --enable-bdb=yes \ --enable-cleartext \ --enable-crypt \ --enable-dynacl \ --enable-dynamic \ --enable-hdb \ --enable-lmpasswd \ --enable-mdb=yes \ --enable-modules \ --enable-monitor \ --enable-overlays=mod \ --enable-rewrite \ --enable-rlookups \ --enable-slapi \ --enable-spasswd \ --libexecdir=%{_libdir} \ --with-cyrus-sasl \ --with-gnu-ld \ --without-fetch \ --with-pic \ --with-threads \ %{nil} Test suite log is in attachment Please let me know if you need more details or want me to perform some diasgnostics. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 6097] MMR problems with deletes
by openldap-its＠openldap.org 23 Sep '21

23 Sep '21

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

1 0

[Issue 6097] MMR problems with deletes
by openldap-its＠openldap.org 23 Sep '21

23 Sep '21

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

1 0

[Issue 9704] New: Failing Configuration of OpenLDAP
by openldap-its＠openldap.org 22 Sep '21

22 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9704 Issue ID: 9704 Summary: Failing Configuration of OpenLDAP Product: OpenLDAP Version: 2.5.7 Hardware: x86_64 OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: build Assignee: bugs(a)openldap.org Reporter: narendra.challa(a)cscs.ch Target Milestone: --- Created attachment 845 --> https://bugs.openldap.org/attachment.cgi?id=845&action=edit Error Hi There, I am new to OpenLDAP and followed the steps mentioned in this quick start guide as it is https://www.openldap.org/doc/admin25/quickstart.html but failing the configuration of OpenLDAP. I followed the below steps on CentOS 8 with 2.5.7 and successfully installed but while configuring facing issues, please correct me if I am doing this in the wrong way. 1. Created a Linux user dedicated to OpenLDAP with the name "nchalla" which has sudo permissions. 2. Login with Root user and created a folder /u01 3. change permissions on /u01 (for time being granted 777 ( 4. change ownership of /u01 to "nchalla" 5. downloaded the tarball and extracted the OpenLDAP 2.5.7 7. downloaded the required developer libraries 8. Logged in as nchalla and navigated to the OpenLDAP 2.5.7 extracted folder and start compiling and installing with the below commands ./configure --prefix=/u01/ldap make depend make make test (all tests were passed) make install 9. Started the configuration following the below steps a. created a folder /u01/ldap/etc/slapd.d b. updated the slapd.ldif with our domain name c. navigate to /u01/ldap and executed the command below, sbin/slapadd -n 0 -F /u01/ldap/etc/slapd.d -l /u01/ldap/etc/openldap/slapd.ldif which is throwing error messages -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9701] New: OpenLDAP replica skips few items while synchronization
by openldap-its＠openldap.org 21 Sep '21

21 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9701 Issue ID: 9701 Summary: OpenLDAP replica skips few items while synchronization Product: OpenLDAP Version: 2.4.44 Hardware: x86_64 OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: mgkrishnan(a)gmail.com Target Milestone: --- I have an OpenLdap cluster with 6 nodes, when an item is added/deleted in the master, the synchronization kicks in and the changes are replicated to other slave nodes in the cluster, but sometimes one of the slave cluster nodes (the same node all the time) misses the updates and hence there is a difference between this slave node and the rest of the slave nodes and the master, so sometimes when the request goes to the unsynchronized slave it yields invalid results. In the problematic slave's ldap logs, there is no error information during this operation to the master which explains the miss, so cant figure out what has caused this problem, bringing down that slave and re-add does not help either. What could be the root cause of this issue ? -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 20 Sep '21

20 Sep '21

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

1 0

[Issue 9698] New: per database olcSecurity: tls=0 does not override olcSecurity: tls=1 from the frontend
by openldap-its＠openldap.org 20 Sep '21

20 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9698 Issue ID: 9698 Summary: per database olcSecurity: tls=0 does not override olcSecurity: tls=1 from the frontend Product: OpenLDAP Version: 2.5.7 Hardware: All OS: Linux Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- I have these databases: cn=config frontend,cn=config mdb/suffix o=A,cn=config mdb/suffix o=B,cn=confix slapd listens on port 389. I want to make sure, that • all requests to suffix o=A are served after STARTTLS, as these come from the wild internet. • all requests to suffix o=B do not have to utilize STARTTLS (ldaps), as these are local to the machine, and • if a request to the root DSE is made, without using STARTTLS, the client shall gets “ldap_bind: Confidentiality required (13) additional info: TLS confidentiality required”. To enforce STARTTLS for suffix o=A I put there `olcSecurity: tls=1`. If I set dn: olcDatabase=frontend,cn=config olcAccess: to dn="" by tls_ssf=256 * read and the rootDSE is requested without STARTTLS, the result is just empty, rather than “ldap_bind: Confidentiality required (13) additional info: TLS confidentiality required”. To get the “confidentiality required” for the root DSE I have to put dn: olcDatabase=frontend,cn=config olcSecurity: tls=1 or dn: cn=config olcSecurity: tls=1 It was unclear to me which one shall I use, but both serve the same purpose. Now, I want to enable no-STARTTLS to suffix o=B. I put there “olcSecurity: tls=0”. Irrespective, if only cn=config, or only olcDatabase=frontend,cn=config contain “olcSecurity: tls=1” the “olcSecurity: tls=0” in suffix o=B is not enacted. -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 17 Sep '21

17 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #13 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Generally, it looks like this feature was implemented using slapd options and ignoring the slapd configured loglevel. This is problematic in that it: a) Breaks the longstanding expectation of being able to control logging via the loglevel/olcLogLevel settings in slapd.conf/cn=config b) Requires a restart to change the logging level c) Is going to be a multi-step issue on systemd based systems, as the debug level would need to be modified in the systemd overrides configuration file. I.e., one cannot simply do even a slapd restart to change the loglevel with this implementation. Generally expectation: a) loglevel continues to control logging b) it is possible to change the loglevel on the fly without restarting slapd c) It is not necessary to fiddle with the -d option to slapd to get logging. Setting -s 0 seems fine. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 17 Sep '21

17 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 Quanah Gibson-Mount <quanah(a)openldap.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|TEST |--- Status|RESOLVED |CONFIRMED --- Comment #12 from Quanah Gibson-Mount <quanah(a)openldap.org> --- Unable to get this to work in master. Set up a generic slapd with cn=config Did an ldapmodify to set the logging options: ldapmodify -x -H ldapi:/// -D cn=config -w secret dn: cn=config changetype: modify add: olcLogFile olcLogFile: /var/symas/slapd.log - add: olcLogFileOnly olcLogFileOnly: TRUE - add: olcLogFileRotate olcLogFileRotate: 12 10 1 modifying entry "cn=config" Logfile is created, but nothing is logged to it. Restarted slapd, still nothing logged to it. Explicitly set the loglevel to stats sync Still nothing logged to it. -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9697] New: healthcare software development
by openldap-its＠openldap.org 17 Sep '21

17 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9697 Issue ID: 9697 Summary: healthcare software development Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: ritesh.patil732(a)gmail.com Target Milestone: --- https://mobisoftinfotech.com/industry/healthcare-software-development -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 6949] OpenLDAP Logging
by openldap-its＠openldap.org 16 Sep '21

16 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=6949 --- Comment #11 from Quanah Gibson-Mount <quanah(a)openldap.org> --- For reference, with the test008 config, timings for progs/slapd-tester -H ldap://:9011 -D cn=manager,dc=example,dc=com -w secret -d testdata -P progs -l 1000 -s0 -dnone 18.92 seconds -s0 -d256 23.37 seconds -s0 -d256 + rotate 27.00 seconds -s256 -dnone 45.33 seconds Logfile params were logfile testrun/logfile logfile-rotate 12 10 1 logfile-only true -- You are receiving this mail because: You are on the CC list for the issue.

1 0

[Issue 9464] New: Test suite file conf.sh tries to sed unused items
by openldap-its＠openldap.org 15 Sep '21

15 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9464 Issue ID: 9464 Summary: Test suite file conf.sh tries to sed unused items 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: --- The conf.sh script tries to sed values that are not meant for replacement but instead are environment variables handled by run.in and defines.sh. This should be deleted from conf.sh -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9694] New: Can Delta-sync’s changelog be based on a sessionlog?
by openldap-its＠openldap.org 15 Sep '21

15 Sep '21

https://bugs.openldap.org/show_bug.cgi?id=9694 Issue ID: 9694 Summary: Can Delta-sync’s changelog be based on a sessionlog? Product: OpenLDAP Version: 2.5.7 Hardware: All OS: All Status: UNCONFIRMED Keywords: needs_review Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: dpa-openldap(a)aegee.org Target Milestone: --- In the replication terminology, the terms sessionlog and accesslog are used. sessionlog is created by the syncprov-overlay/syncprov-sessionlog directive; accesslog is created in first place by the accesslog overlay. Delta-syncrepl introduces an additional term: changelog. The example at https://www.openldap.org/devel/admin/replication.html#Delta-syncrepl%20Prov… uses accesslog for the changelog. The documentation is unclear, whether the changelog must be backed on accesslog-database, or it can be backed also on a sessionlog. (⇔Is delta-sync happy just with a sessionlog?) The documentation in slapo-syncprov(5) for syncprov-nopresent says “This value should only be set TRUE for a syncprov instance on top of a log database (such as one managed by the accesslog overlay).” Is sessionlog a log database? -- You are receiving this mail because: You are on the CC list for the issue.

1 4

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs