openldap-bugs September 2017

openldap-bugs@openldap.org

35 participants
128 discussions

(ITS#8735) Significant delay setting LDAP_OPT_X_TLS_REQUIRE_CERT with invalid DNS
by sean.haugh＠vertivco.com 14 Sep '17

14 Sep '17

Full_Name: Sean Haugh Version: 2.4.45 OS: Linux URL: Submission from: (NULL) (143.166.81.254) I'm seeing a significant delay (32s) when setting `LDAP_OPT_X_TLS_REQUIRE_CERT` with unreachable DNS servers in resolv.conf. We initially discovered the issue in 2.4.42 although I've confirmed it is present in 2.4.45. AFAIK it is not present in 2.4.23.

1 0

Re: (ITS#8208) ppolicy supportedControl not visible in root DSE
by come＠opensides.be 14 Sep '17

14 Sep '17

Hello, I=E2=80=99m not sure I understand the outcome of the discussion here, why i= s 1.3.6.1.4.1.42.2.27.8.5.1 absent from the supportedControl returned by th= e rootDSE? (1.3.6.1.4.1.42.2.27.8.5.1 being LDAP_CONTROL_PASSWORDPOLICYREQUEST) This prevents client to know that the server supports ppolicy. C=C3=B4me

1 0

Re: (ITS#6300) Add kqueue support to slapd
by quanah＠symas.com 13 Sep '17

13 Sep '17

Hi Bryan, I managed to track down a copy of your patch, and uploaded it to the OpenLDAP FTP server as bryan-duncan-its6300.patch. I will see about getting this updated for current OpenLDAP, for possible inclusion in OpenLDAP 2.5. Regards, Quanah --On Monday, September 11, 2017 11:45 PM +0000 quanah(a)fast-mail.org wrote: > Hi Bryan, > > Unfortunately this patch is no longer available with Apple's switch to > iCloud. Would you be able to upload it to the OpenLDAP FTP server? > > Thanks, > Quanah > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8734) Fixes for multiple back-asyncmeta issues
by nivanova＠symas.com 13 Sep '17

13 Sep '17

Full_Name: Nadezhda Ivanova Version: 2.5 OS: URL: ftp://ftp.openldap.org/incoming/nadezhda-ivanova-170913.patch Submission from: (NULL) (87.227.214.182) This patch contains the fixes for all issues discovered and fixed since the initial submission of back-asyncmeta. These include memory leaks, stability issues, segfaults and functional bugs. IPR: The attached files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch were developed by Symas Corporation. Symas Corporation has not assigned rights and/or interest in this work to any party. I, Nadezhda Ivanova, am authorized by Symas Corporation, my employer, to release this work under the following terms. The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2017 Symas Corporation Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

(ITS#8733) liblber value extraction enhancements
by ondra＠openldap.org 13 Sep '17

13 Sep '17

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170913-ber_skip_raw-ber_dec… Submission from: (NULL) (82.10.24.68) When extracting parts of a BerElement, one might want to pull out a valid ber-encoded buffer. Also, there is no way to ber-decode an integer from a berval. These patches provide and expose that functionality. The attached patches have been authored by Hallvard with a few fixes by me, I have kept his name as the author.

1 0

(ITS#8732) LDAP_CIRCLEQ improvements
by ondra＠openldap.org 13 Sep '17

13 Sep '17

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/incoming/Ondrej-Kuznik-20170913-LDAP_CIRCLEQ.patch Submission from: (NULL) (82.10.24.68) The CIRCLEQ macros are incomplete and not very useful on their own, but when providing a few more that allow rotating it, they are. Patch to that effect is attached. They could probably be made a bit more efficient as well, though.

1 0

Re: (ITS#8707) slapd: Add systemd service notification support
by hyc＠symas.com 12 Sep '17

12 Sep '17

Ryan Tandy wrote: > On Tue, Sep 12, 2017 at 08:24:15PM +0000, hyc(a)symas.com wrote: >> I don't have documentation for sd_notify() on my machine > > https://www.freedesktop.org/software/systemd/man/sd_notify.html > >> - what does it return if systemd isn't running at the moment? What does it >> return if the current program wasn't started by systemd (and thus, the >> notification is irrelevant)? > > 0 in both of these cases (assuming there is not an unrelated NOTIFY_SOCKET env > var). However, it also says: > >> In order to support both service managers that implement this scheme and >> those which do not, it is generally recommended to ignore the return value >> of this call." > > and the current patch doesn't follow that recommendation, since it does check > the return value. I don't feel strongly either way about that. OK. You realize how egregiously gross this kind of API design is? "Oh, yeah, we return a value, but properly written programs should ignore it." Everything about this makes me nauseous. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8707) slapd: Add systemd service notification support
by ryan＠nardis.ca 12 Sep '17

12 Sep '17

On Tue, Sep 12, 2017 at 08:24:15PM +0000, hyc(a)symas.com wrote: >I don't have documentation for sd_notify() on my machine https://www.freedesktop.org/software/systemd/man/sd_notify.html >- what does it return if systemd isn't running at the moment? What does >it return if the current program wasn't started by systemd (and thus, >the notification is irrelevant)? 0 in both of these cases (assuming there is not an unrelated NOTIFY_SOCKET env var). However, it also says: >In order to support both service managers that implement this scheme >and those which do not, it is generally recommended to ignore the >return value of this call." and the current patch doesn't follow that recommendation, since it does check the return value. I don't feel strongly either way about that. >It strikes me that this code should only be invoked if slapd was actually >started by systemd. As I understand it, sd_notify() should be a no-op (no error) if NOTIFY_SOCKET is not set. I don't think we should check NOTIFY_SOCKET ourselves; it's to some extent an implementation detail.

1 0

Re: (ITS#8707) slapd: Add systemd service notification support
by hyc＠symas.com 12 Sep '17

12 Sep '17

michael(a)stroeder.com wrote: > Howard Chu wrote: >> If no one has any other reasons to offer, I'm inclined to reject >> and close this ITS. > > Note that the systemd unit file was only a little detail in this > ITS. The most important part is the C code change. OK. Looking at the patch: +dnl +dnl Check for systemd +dnl +WITH_SYSTEMD=no +ol_link_systemd=no +if test $ol_with_systemd != no ; then + AC_CHECK_HEADERS(systemd/sd-daemon.h) + + if test $ac_cv_header_systemd_sd_daemon_h = yes; then + AC_CHECK_LIB(systemd, sd_notify, + [ol_link_systemd="-lsystemd"]) + fi + + if test $ol_link_systemd = no ; then + if test $ol_with_systemd != auto ; then + AC_MSG_ERROR([Could not locate systemd]) + else + AC_MSG_WARN([Could not locate systemd]) + AC_MSG_WARN([systemd service notification not supported!]) + fi + else + AC_DEFINE(HAVE_SYSTEMD,1,[define if you have systemd]) + SYSTEMD_LIBS="$ol_link_systemd" + WITH_SYSTEMD=yes + fi +fi + There should not be any warning if with-systemd is defaulted to auto and it's not found. It should be silently ignored. This isn't like SASL, which is an explicit part of the LDAP spec and therefore has a warning in its absence. +#ifdef HAVE_SYSTEMD + rc = sd_notifyf( 1, + "READY=1\n" + "STATUS=slapd: ready to serve connections...\n" + "MAINPID=%lu", + (unsigned long) getpid() ); + if ( rc < 0 ) + Debug( LDAP_DEBUG_ANY, + "systemd sd_notify failed (%d)\n", rc, 0, 0 ); +#endif /* HAVE_SYSTEMD */ + I don't have documentation for sd_notify() on my machine - what does it return if systemd isn't running at the moment? What does it return if the current program wasn't started by systemd (and thus, the notification is irrelevant)? It strikes me that this code should only be invoked if slapd was actually started by systemd. In particular, I don't want to see a lot of "sd_notify failed" messages in our logs, for manually started slapd processes. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#8707) slapd: Add systemd service notification support
by michael＠stroeder.com 12 Sep '17

12 Sep '17

Howard Chu wrote: > If no one has any other reasons to offer, I'm inclined to reject > and close this ITS. Note that the systemd unit file was only a little detail in this ITS. The most important part is the C code change. Ciao, Michael.

1 0

← Newer
1
2
3
4
5
6
7
8
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs September 2017