openldap-bugs August 2020

openldap-bugs@openldap.org

2 participants
185 discussions

[Bug 9207] New: Remove Moznss compatibility layer
by openldap-its＠openldap.org 15 Oct '20

15 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9207 Bug ID: 9207 Summary: Remove Moznss compatibility layer Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- For the 2.5 release, remove the MozNSS compatibility layer. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 9201] New: LDAP_THREAD_DEBUG doesn't compile
by openldap-its＠openldap.org 15 Oct '20

15 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9201 Bug ID: 9201 Summary: LDAP_THREAD_DEBUG doesn't compile Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- on master @ 4ac88b219d: ./configure CPPFLAGS="-DLDAP_THREAD_DEBUG" && make make[2]: Entering directory '/home/ryan/tmp/openldap/libraries/libldap_r' /bin/sh ../../libtool --mode=compile cc -g -O2 -I../../include -I../../include -DLDAP_R_COMPILE -I./../libldap -DLDAP_THREAD_DEBUG -DLDAP_LIBRARY -c threads.c cc -g -O2 -I../../include -I../../include -DLDAP_R_COMPILE -I./../libldap -DLDAP_THREAD_DEBUG -DLDAP_LIBRARY -c threads.c -fPIC -DPIC -o .libs/threads.o In file included from ldap_thr_debug.h:129, from threads.c:73: ../../include/ldap_pvt_thread.h:114:1: error: conflicting types for 'ldap_pvt_thread_mutex_recursive_init' ldap_pvt_thread_mutex_recursive_init LDAP_P(( ldap_pvt_thread_mutex_t *mutex )); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In file included from ldap_thr_debug.h:129, from threads.c:26: ../../include/ldap_pvt_thread.h:114:1: note: previous declaration of 'ldap_pvt_thread_mutex_recursive_init' was here ldap_pvt_thread_mutex_recursive_init LDAP_P(( ldap_pvt_thread_mutex_t *mutex )); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ make[2]: *** [Makefile:420: threads.lo] Error 1 -- You are receiving this mail because: You are on the CC list for the bug.

1 13

[Bug 9194] New: slapd-ndb: Remove backend for the 2.5 release
by openldap-its＠openldap.org 15 Oct '20

15 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9194 Bug ID: 9194 Summary: slapd-ndb: Remove backend for the 2.5 release Product: OpenLDAP Version: 2.5 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: backends Assignee: bugs(a)openldap.org Reporter: quanah(a)openldap.org Target Milestone: --- Remove the slapd-ndb backend for the 2.5 release, as it was never finished and development on it has ceased. -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 9191] New: libraries\liblutil\meter.c have a bad function lutil_meter_update, maybe divide 0
by openldap-its＠openldap.org 15 Oct '20

15 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9191 Bug ID: 9191 Summary: libraries\liblutil\meter.c have a bad function lutil_meter_update, maybe divide 0 Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: client tools Assignee: bugs(a)openldap.org Reporter: digpython(a)163.com Target Milestone: --- int lutil_meter_update ( lutil_meter_t *meter, size_t position, int force) { static const double display_rate = 0.5; double frac, cycle_length, speed, now; time_t remaining_time, elapsed; int rc; assert( meter != NULL ); lutil_get_now( &now ); if ( !force && now - meter->last_update < display_rate ) return 0; frac = ((double)position) / ((double) meter->goal_value); elapsed = now - meter->start_time; if (frac <= 0.0) return 0; if (frac >= 1.0) { rc = meter->display->display_update( &meter->display_data, 1.0, 0, (time_t) elapsed, ((double)position) / elapsed); } else { ... } -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 9184] New: slapd -V flag not documented
by openldap-its＠openldap.org 15 Oct '20

15 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9184 Bug ID: 9184 Summary: slapd -V flag not documented Product: OpenLDAP Version: 2.4.49 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: documentation Assignee: bugs(a)openldap.org Reporter: ryan(a)openldap.org Target Milestone: --- The slapd(8) man page does not document the -V (version info) flag. https://openldap.org/software/man.cgi?query=slapd&apropos=0&sektion=0&manpa… https://openldap.org/software/man.cgi?query=slapd&apropos=0&sektion=0&manpa… -- You are receiving this mail because: You are watching someone on the CC list of the bug.

1 5

[Issue 9277] New: restart 3+ providers at once burns CPU forever
by openldap-its＠openldap.org 15 Oct '20

15 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9277 Issue ID: 9277 Summary: restart 3+ providers at once burns CPU forever Product: OpenLDAP Version: 2.4.50 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: slapd Assignee: bugs(a)openldap.org Reporter: michael(a)stroeder.com Target Milestone: --- I have tiny VMs configured as Æ-DIR servers, 5 providers (multi-provider replication) and 5 read-only consumers each syncing with all providers. Restarting all consumers at once simply works, no matter how many of the providers are up. Restarting only two providers at once also works. But when restarting more than two providers at once all of thems seem to hang eating up CPU. It could be the same issue like ITS#8650 / ITS#9210 but those only mention GNUTLS being affected. But all my Æ-DIR test servers run slapd built against OpenSSL (openSUSE, Debian buster, CentOS7). -- You are receiving this mail because: You are on the CC list for the issue.

1 7

[Issue 9330] New: Need to fully serialize delta-syncrepl
by openldap-its＠openldap.org 13 Oct '20

13 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9330 Issue ID: 9330 Summary: Need to fully serialize delta-syncrepl 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: --- While using delta-syncrepl was supposed to fully serialize updates due to the use of the accesslog DB, in extremely high write driven environments it became clear this wasn't entirely the case. This would cause systems to constantly go into mini REFRESH states as changes came in out of order. -- You are receiving this mail because: You are on the CC list for the issue.

1 6

[Issue 9331] New: New Mirror in NL
by openldap-its＠openldap.org 13 Oct '20

13 Oct '20

https://bugs.openldap.org/show_bug.cgi?id=9331 Issue ID: 9331 Summary: New Mirror in NL Product: website Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: website Assignee: bugs(a)openldap.org Reporter: info(a)lyrahosting.com Target Milestone: --- Hi, With much pleasure, Lyra Hosting has created a new Mirror for OpenLDAP. Mirror is located in Netherland access methods: http and https Your mirror's available bandwidth: 200mbps An administrative contact email: admin(a)lyrahosting.com http://mirror.lyrahosting.com/OpenLDAP/ https://mirror.lyrahosting.com/OpenLDAP/ Kindly regards Dennis -- You are receiving this mail because: You are on the CC list for the issue.

1 5

[Issue 9317] New: LDAPS connection fails to multi-IP DNS using DIGEST-MD5 mechanism
by openldap-its＠openldap.org 18 Sep '20

18 Sep '20

https://bugs.openldap.org/show_bug.cgi?id=9317 Issue ID: 9317 Summary: LDAPS connection fails to multi-IP DNS using DIGEST-MD5 mechanism Product: OpenLDAP Version: 2.4.46 Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: paul.raines(a)gmail.com Target Milestone: --- Our MS AD ldap servers are in DNS using alias ldap.example.org at multiple IP addresses like so: # host ldap.example.org ldap.example.org has address 172.18.1.10 ldap.example.org has address 172.21.1.10 ldap.example.org has address 172.24.1.10 ldap.example.org has address 172.30.1.10 For CentOS 6 this was not a problem. But with CentOS 7 (2.4.44) and CentOS 8 (2.4.46) the following fails # ldapwhoami -d -1 -H ldaps://ldap.example.org -Y DIGEST-MD5 -U username -W with the error: ldap_sasl_interactive_bind_s: Invalid credentials (49) additional info: 80090303: LdapErr: DSID-0C090574, comment: The digest-uri does not match any LDAP SPN's registered for this server., data 0, v3839 ldap_free_connection 1 1 ldap_send_unbind If one reverse DNS IP lookups one of the IPs and uses the unique name (e.g. ldap01.example.org) instead it works fine I think openldap should work in this case with DNS aliases. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

[Issue 9315] New: FR: Support SPIFFE Certificate Provisioner
by openldap-its＠openldap.org 18 Sep '20

18 Sep '20

https://bugs.openldap.org/show_bug.cgi?id=9315 Issue ID: 9315 Summary: FR: Support SPIFFE Certificate Provisioner Product: OpenLDAP Version: unspecified Hardware: All OS: All Status: UNCONFIRMED Severity: normal Priority: --- Component: libraries Assignee: bugs(a)openldap.org Reporter: dar(a)xoe.solutions Target Milestone: --- Created attachment 754 --> https://bugs.openldap.org/attachment.cgi?id=754&action=edit A SPIFFE samle certificate SPIFFE is a protocol for attesting workload identities. It implements a pull based workflow where clients request ad-hoc certificates about their identity from a unix domain socket. While there is a helper that can wrap clients it is uncertain how certificate rolls, which happen by default every few minutes, shall be signalled to the ldap client: https://github.com/spiffe/spiffe-helper I assume there is no signal which induces graceful reloading of the certificates. Therefore, it might be considerable adding direct spiffe support to the ldap client. See example: https://github.com/spiffe/c-spiffe/blob/master/c-spiffe.cc Please find attached a spiffe sample cert, for mere information. Note it does convey identity (exclusively) through SAN, which currently seems not be supported in OpenLDAP. I'm going to open another issue for that. -- You are receiving this mail because: You are on the CC list for the issue.

1 3

← Newer
1
...
4
5
6
7
8
9
10
...
19
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs August 2020