October 2020 - openldap-bugs

[Bug 9186] New: RFE: More metrics in cn=monitor

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9186 Bug ID: 9186 Summary: RFE: More metrics in cn=monitor Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- Currently I'm grepping metrics from syslog with mtail: https://gitlab.com/ae-dir/ansible-ae-dir-server/-/blob/master/templates/m... With a new binary logging this is not possible anymore. Thus it would be nice if cn=monitor provides more metrics. 1. Overall connection count per listener starting at 0 when started. This would be a simple counter added to: entries cn=Listener 0,cn=Listeners,cn=Monitor 2. Counter for the various "deferring" messages separated by the reason for deferring. 3. Counters for all possible result codes. In my mtail program I also label it with the result type. -- You are receiving this mail because: You are on the CC list for the bug.

2 years, 2 months

1
8
0 / 0

[Bug 9216] New: Port autoca to gnutls

by openldap-its＠openldap.org

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

2 years, 2 months

1
6
0 / 0

[Issue 9303] New: Add support for WolfSSL as an alternative to OpenSSL

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9303 Issue ID: 9303 Summary: Add support for WolfSSL as an alternative to OpenSSL Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For OpenLDAP 2.6, we should investigate adding support for WolfSSL as an alternative to OpenSSL. -- You are receiving this mail because: You are on the CC list for the issue.

2 years, 2 months

1
2
0 / 0

[Issue 9305] New: ldap_connect_to_host: Return code from getaddrinfo() discarded, troubleshooting difficult

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9305 Issue ID: 9305 Summary: ldap_connect_to_host: Return code from getaddrinfo() discarded, troubleshooting difficult Product: OpenLDAP Version: 2.4.46 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: minfrin(a)sharp.fm Target Milestone: --- When the ldap_connect_to_host() function sees a failure from getaddrinfo(), the meaningless return code -1 is returned. This makes troubleshooting difficult on a webserver, where the low level printf debugging is not practical. (gdb) step ldap_connect_to_host (ld=ld@entry=0x7fffc4002e10, sb=0x7fffc400b240, proto=1, srv=srv@entry=0x7fffc400b2f0, async=async@entry=0) at os-ip.c:543 543 { (gdb) next 546 ber_socket_t s = AC_SOCKET_INVALID; (gdb) 562 if ( srv->lud_host == NULL || *srv->lud_host == 0 ) { (gdb) 568 port = srv->lud_port; (gdb) 570 if( !port ) { (gdb) 578 switch(proto) { (gdb) 580 osip_debug( ld, (gdb) warning: Source file is more recent than executable. 71 return __builtin___memset_chk (__dest, __ch, __len, __bos0 (__dest)); (gdb) 598 hints.ai_flags = AI_ADDRCONFIG; (gdb) 601 hints.ai_socktype = socktype; (gdb) 602 snprintf(serv, sizeof serv, "%d", port ); (gdb) 605 LDAP_MUTEX_LOCK(&ldap_int_resolv_mutex); (gdb) 607 err = getaddrinfo( host, serv, &hints, &res ); (gdb) 609 LDAP_MUTEX_UNLOCK(&ldap_int_resolv_mutex); (gdb) 611 if ( err != 0 ) { (gdb) 612 osip_debug(ld, "ldap_connect_to_host: getaddrinfo failed: %s\n", (gdb) print host $3 = <optimized out> (gdb) print serv $4 = "636\000\000\000" (gdb) next 614 return -1; (gdb) The ldap_connect_to_host() function needs to return proper error codes. -- You are receiving this mail because: You are on the CC list for the issue.

2 years, 2 months

1
3
0 / 0

[Issue 9367] New: back-mdb: encryption support

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9367 Issue ID: 9367 Summary: back-mdb: encryption support Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Need to add encryption support to the back-mdb backend, depends on issue#9364 -- You are receiving this mail because: You are on the CC list for the issue.

2 years, 3 months

1
2
0 / 0

[Issue 9341] New: Delta-sync MPR needs to be stable regardless of ordering

by openldap-its＠openldap.org

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

2 years, 3 months

1
9
0 / 0

[Bug 9243] New: back-perl configure should test linking with libperl

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9243 Bug ID: 9243 Summary: back-perl configure should test linking with libperl Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- ./configure --enable-perl && make [...] checking for perl... /usr/bin/perl [...] libtool: link: cc -g -O2 -o slapd main.o globals.o bconfig.o config.o daemon.o connection.o search.o filter.o add.o cr.o attr.o entry.o backend.o backends.o result.o operation.o dn.o compare.o modify.o delete.o modrdn.o ch_malloc.o value.o ava.o bind.o unbind.o abandon.o filterentry.o phonetic.o acl.o str2filter.o aclparse.o init.o user.o lock.o controls.o extended.o passwd.o schema.o schema_check.o schema_init.o schema_prep.o schemaparse.o ad.o at.o mr.o syntax.o oc.o saslauthz.o oidm.o starttls.o index.o sets.o referral.o root_dse.o sasl.o module.o mra.o mods.o sl_malloc.o zn_malloc.o limits.o operational.o matchedValues.o cancel.o syncrepl.o backglue.o backover.o ctxcsn.o ldapsync.o frontend.o slapadd.o slapcat.o slapcommon.o slapdn.o slapindex.o slappasswd.o slaptest.o slapauth.o slapacl.o component.o aci.o txn.o slapschema.o slapmodify.o version.o -Wl,-E -fstack-protector-strong -pthread libbackends.a liboverlays.a ../../libraries/liblunicode/liblunicode.a ../../libraries/librewrite/librewrite.a ../../libraries/liblutil/liblutil.a ../../libraries/libldap_r/.libs/libldap_r.a /home/ryan/tmp/openldap/libraries/liblber/.libs/liblber.a ../../libraries/liblber/.libs/liblber.a -L/usr/local/lib -L/usr/lib/x86_64-linux-gnu/perl/5.28/CORE -lperl -ldl -lm -lpthread -lcrypt -lresolv -pthread /usr/bin/ld: cannot find -lperl collect2: error: ld returned 1 exit status It should probably test compiling and linking a program with the detected CPPFLAGS and LDFLAGS. -- You are receiving this mail because: You are on the CC list for the bug.

2 years, 3 months

1
7
0 / 0

[Bug 9224] New: Add support for PREPARE/2-phase commit

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9224 Bug ID: 9224 Summary: Add support for PREPARE/2-phase commit Product: LMDB Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: liblmdb Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- In LMDB, add support for PREPARE/2-phase commits -- You are receiving this mail because: You are on the CC list for the bug.

2 years, 3 months

1
2
0 / 0

[Bug 9225] New: back-mdb: Add support for PREPARE/2-phase commit

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9225 Bug ID: 9225 Summary: back-mdb: Add support for PREPARE/2-phase commit Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Add support for PREPARE/2-phase commit in back-mdb -- You are receiving this mail because: You are on the CC list for the bug.

2 years, 3 months

1
6
0 / 0

[Issue 9363] New: removing olcReadOnly on a DB does not set it to FALSE

by openldap-its＠openldap.org

https://bugs.openldap.org/show_bug.cgi?id=9363 Issue ID: 9363 Summary: removing olcReadOnly on a DB does not set it to FALSE Product: OpenLDAP Version: 2.4.53 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: maxime.besson(a)worteks.com Target Milestone: --- Created attachment 771 --> https://bugs.openldap.org/attachment.cgi?id=771&action=edit ldif config that reproduces the issue I am running the following test: * add olcReadOnly: TRUE on a MDB database in cn=config * Try to write to the MDB database => fails with "unwilling to perform" as expected * remove the olcReadOnly attribute from the MDB database * Try to write to the MDB database => still fails with the same error * Restart slapd * Try to write to the MDB database => OK However the following test works as expected: * add olcReadOnly: TRUE on a MDB database in cn=config * Try to write to the MDB database => fails with "unwilling to perform" as expected * modify olcReadOnly to FALSE on the MDB database * Try to write to the MDB database => OK It seems a little counter intuitive to me that removing a setting does not reset it to its default value. The fact that a slapd restart make writing possible again in the first test described above makes it seem to the casual user that olcReadOnly cannot be undone without a restart at all. Tested in 2.4.53 and 2.4.44, config attached but it probably works with any config (hdb, etc) -- You are receiving this mail because: You are on the CC list for the issue.

2 years, 3 months

2
9
0 / 0

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs October 2020