- openldap-bugs - openldap.org

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

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 07:04:48PM +0000, hyc(a)symas.com wrote: >My experience so far with Arch/Debian/Ubuntu/Centos mirrors this - >they're all different in FS layouts (/var/run vs /run, etc etc etc) and >the situation is no better than it was in SysV init In the case of the unit file proposed, the only system-specific path is the path to slapd itself, and the patch already handles substituting that at install time. (OT: /run as a directory and /var/run as a symlink to it for backwards compatibility is the cross-distro standard today as far as I'm aware, and has been for a few years now. RHEL/CentOS 5/6 are the outliers since they predate /run but are still supported.) >If no one has any other reasons to offer, I'm inclined to reject and >close this ITS. Even if you don't want to ship the unit file, please consider at least accepting the code change to enable the startup notification, which should be completely distro-independent, and no more system-specific than any of our other optional library dependencies.

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: > ryan(a)nardis.ca wrote: >> An explicit design goal of systemd is that unit files should be >> uniform enough that it's reasonable for upstream projects to >> ship them, >=20 > Yes, systemd has many admirable goals. And not enough competent developers to achieve any of them. > On the other hands Linux distributions differ a lot especially > regarding file system layout, not to speak of their systemd > back-port patches. My experience so far with Arch/Debian/Ubuntu/Centos mirrors this - they'r= e all=20 different in FS layouts (/var/run vs /run, etc etc etc) and the situation= is=20 no better than it was in SysV init. I see no reason for us to change our=20 policy regarding system-specific dependencies. re: providing an example in OpenLDAP documentation - this is an only slig= htly=20 less-bad suggestion. The onus is on systemd to provide adequate documenta= tion=20 on how to write unit files, and adequate examples of working files. Our o= nly=20 responsibility is to document the parameters for correctly running the co= de;=20 it's up to distro packagers to encapsulate a correct invocation into what= ever=20 their launch mechanism is. If no one has any other reasons to offer, I'm inclined to reject and clos= e=20 this ITS. >=20 > Ciao, Michael. >=20 > P.S.: > Right at this moment I'm trying to figure out the appropriate > Requires and After lines in systemd unit file template in =C3=83=E2=80=A0= -DIR's > ansible role. And the ansible role has only support for three (and > a half) different Linux distributions [1]. >=20 > [1] https://www.ae-dir.com/install.html#prereq >=20 >=20 >=20 >=20 --=20 -- 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#8671) Declare ldap_init_fd() in ldap.h to help external consumers
by quanah＠symas.com 12 Sep '17

12 Sep '17

Hi Alexander, Your submission appears to be missing an IPR statement as noted at <https://www.openldap.org/devel/contributing.html#notice>. This is required for your submission to be evaluated. Please add an IPR at your earliest convenience. Thanks! --Quanah --On Wednesday, June 07, 2017 11:44 AM +0000 abokovoy(a)redhat.com wrote: > > --ce5n3c4hsgyizewc > Content-Type: text/plain; charset=us-ascii; format=flowed > Content-Disposition: inline > > Patch attached. > > -- > / Alexander Bokovoy > > --ce5n3c4hsgyizewc > Content-Type: text/plain; charset=us-ascii > Content-Disposition: attachment; > filename="abokovoy-ldap_init_fd-move-ldap_init_fd-definition-to-ldap.h.pa > tch" Content-Transfer-Encoding: quoted-printable > > =46rom 2c1f3afd8098b2a345a900effa1a2e5c3f9e3b08 Mon Sep 17 00:00:00 2001 > =46rom: Alexander Bokovoy <abokovoy(a)redhat.com> > Date: Mon, 5 Jun 2017 14:43:58 +0300 > Subject: [PATCH] ldap_init_fd: move ldap_init_fd() definition to ldap.h > > While OpenLDAP team position is that all code in OpenLDAP source > distribution can be used by users, most distributions do not ship > ldap_pvt.h as part of openldap-devel (sub)package. > > Move ldap_init_fd() to ldap.h to facilitate external users who have a > need to integrate OpenLDAP with their own event loop processing. > --- > doc/man/man3/ldap_open.3 | 5 +---- > include/ldap.h | 8 ++++++++ > include/ldap_pvt.h | 2 -- > 3 files changed, 9 insertions(+), 6 deletions(-) > > diff --git a/doc/man/man3/ldap_open.3 b/doc/man/man3/ldap_open.3 > index 1d5e2b5..4f980f2 100644 > --- a/doc/man/man3/ldap_open.3 > +++ b/doc/man/man3/ldap_open.3 > @@ -3,7 +3,7 @@ > .\" Copyright 1998-2017 The OpenLDAP Foundation All Rights Reserved. > .\" Copying restrictions apply. See COPYRIGHT/LICENSE. > .SH NAME > -ldap_init, ldap_initialize, ldap_open \- Initialize the LDAP library and > o= pen a connection to an LDAP server > +ldap_init, ldap_initialize, ldap_open, ldap_init_fd \- Initialize the > LDAP= library and open a connection to an LDAP server > .SH LIBRARY > OpenLDAP LDAP (libldap, \-lldap) > .SH SYNOPSIS > @@ -45,9 +45,6 @@ LDAPURLDesc **url; > void *params; > .LP > .ft B > -#include <ldap_pvt.h> > -.LP > -.ft B > int ldap_init_fd(fd, proto, uri, ldp) > .ft > ber_socket_t fd; > diff --git a/include/ldap.h b/include/ldap.h > index 588e906..dd0c118 100644 > --- a/include/ldap.h > +++ b/include/ldap.h > @@ -1548,6 +1548,14 @@ LDAP_F( LDAP * ) > ldap_dup LDAP_P(( > LDAP *old )); > =20 > +/* open */ > +LDAP_F (int) > +ldap_init_fd LDAP_P(( > + ber_socket_t fd, > + int proto, > + LDAP_CONST char *url, > + LDAP **ldp )); > + > /* > * in tls.c > */ > diff --git a/include/ldap_pvt.h b/include/ldap_pvt.h > index f1d93ac..49f674c 100644 > --- a/include/ldap_pvt.h > +++ b/include/ldap_pvt.h > @@ -344,8 +344,6 @@ ldap_get_message_ber LDAP_P(( > /* open */ > LDAP_F (int) ldap_open_internal_connection LDAP_P(( > struct ldap **ldp, ber_socket_t *fdp )); > -LDAP_F (int) ldap_init_fd LDAP_P(( > - ber_socket_t fd, int proto, LDAP_CONST char *url, struct ldap **ldp )); > =20 > /* sasl.c */ > LDAP_F (int) ldap_pvt_sasl_generic_install LDAP_P(( Sockbuf *sb, > --=20 > 2.9.3 > > > --ce5n3c4hsgyizewc-- > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

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

12 Sep '17

ryan(a)nardis.ca wrote: > An explicit design goal of systemd is that unit files should be > uniform enough that it's reasonable for upstream projects to > ship them, Yes, systemd has many admirable goals. On the other hands Linux distributions differ a lot especially regarding file system layout, not to speak of their systemd back-port patches. Ciao, Michael. P.S.: Right at this moment I'm trying to figure out the appropriate Requires and After lines in systemd unit file template in Æ-DIR's ansible role. And the ansible role has only support for three (and a half) different Linux distributions [1]. [1] https://www.ae-dir.com/install.html#prereq

1 0

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

12 Sep '17

--On Tuesday, September 12, 2017 11:30 AM -0700 Ryan Tandy <ryan(a)nardis.ca> wrote: > "Part of this is that we want that unit files are supplied with upstream, > and not just added by the packager -- how it has usually been done in the > SysV world." > > Of course the unit file should only be installed if the configure switch > for systemd is enabled, and I believe the latest patch does this. I'll leave it to hyc to weigh in. It's not been the policy of the project so far to include such items. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

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 05:17:11PM +0000, quanah(a)symas.com wrote: >b) The OpenLDAP project has never provided init scripts of their >equivalents. I'm not sure it would be correct to include the systemd unit >file as a part of the project. An explicit design goal of systemd is that unit files should be uniform enough that it's reasonable for upstream projects to ship them, in contrast to init scripts where the conventions and helper scripts differ a lot from distro to distro. (This obviously does not preclude distro customization of the shipped unit file.) http://0pointer.de/blog/projects/on-etc-sysinit.html: "Part of this is that we want that unit files are supplied with upstream, and not just added by the packager -- how it has usually been done in the SysV world." Of course the unit file should only be installed if the configure switch for systemd is enabled, and I believe the latest patch does this.

1 0

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

12 Sep '17

quanah(a)symas.com wrote: > b) The OpenLDAP project has never provided init scripts of > their equivalents. I'm not sure it would be correct to include > the systemd unit file as a part of the project. I also suspect that many Linux distributions are picky regarding their own systemd flavors. My suggestion would be to provide an example systemd unit file as documentation. Ciao, Michael.

1 0

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

12 Sep '17

--On Sunday, August 13, 2017 12:55 PM +0000 fumiyas(a)osstech.co.jp wrote: A couple of things: a) There is no IPR statement provided, so this cannot be examined. b) The OpenLDAP project has never provided init scripts of their equivalents. I'm not sure it would be correct to include the systemd unit file as a part of the project. c) The referenced pull request has unrelated changes around the wired tiger backend mixed in. A clean git-format-patch addressing the above issues would be appreciated. Thanks! --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8404) Fix for an assertion failure when olcDbRewrite is modified on a meta or asyncmeta database
by nivanova＠symas.com 12 Sep '17

12 Sep '17

IPR for this ITS: 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

Re: (ITS#8404) Fix for an assertion failure when olcDbRewrite is modified on a meta or asyncmeta database
by nivanova＠symas.com 12 Sep '17

12 Sep '17

A new patch for this issue is uploaded at ftp://ftp.openldap.org/incoming/nadezhda-ivanova-170912.patch Since asyncmeta no longer uses the rewrite engine, that part of the fix has become irrelevant and is therefore not included. ----- Original Message ----- From: openldap-its(a)OpenLDAP.org To: nivanova(a)symas.com Sent: Thursday, April 14, 2016 4:28:20 PM Subject: Re: (ITS#8404) Fix for an assertion failure when olcDbRewrite is modified on a meta or asyncmeta database *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** Thanks for your report to the OpenLDAP Issue Tracking System. Your report has been assigned the tracking number ITS#8404. One of our support engineers will look at your report in due course. Note that this may take some time because our support engineers are volunteers. They only work on OpenLDAP when they have spare time. If you need to provide additional information in regards to your issue report, you may do so by replying to this message. Note that any mail sent to openldap-its(a)openldap.org with (ITS#8404) in the subject will automatically be attached to the issue report. mailto:openldap-its@openldap.org?subject=(ITS#8404) You may follow the progress of this report by loading the following URL in a web browser: http://www.OpenLDAP.org/its/index.cgi?findid=8404 Please remember to retain your issue tracking number (ITS#8404) on any further messages you send to us regarding this report. If you don't then you'll just waste our time and yours because we won't be able to properly track the report. Please note that the Issue Tracking System is not intended to be used to seek help in the proper use of OpenLDAP Software. Such requests will be closed. OpenLDAP Software is user supported. http://www.OpenLDAP.org/support/ -------------- Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved.

1 0

(ITS#8731) Variadic Debug() macro
by okuznik＠symas.com 12 Sep '17

12 Sep '17

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/incoming/debug_macro_refactor.tgz Submission from: (NULL) (82.10.24.68) The patch series in the linked archive changes the logging macros to be fully variadic: - 00-fixes.patch - fixes proposed in ITS#8730 - 01-logging.patch updates the macros themselves - 02-manual.patch updates some legal but unnecessary constructs - 03-variadic.patch (generated from 03-variadic.cocci against today's master 20e46d84948be3127f6145d4f65437091bb87580) replaces the current Debug(level, "fmt", 0, 0, 0) with Debug(level, "fmt"), etc. - 04-back-sql.patch updates parts of back-sql that coccinelle cannot currently process - 05-nssov.patch updates nssov where coccinelle cannot see past some of the macros - 06-shortcut.patch (generated from 06-shortcut.cocci) replaces the snprintf(buf);Debug("fmt", buf) workaround with Debug() - 07-snprintf-manual.patch updates what coccinelle cannot pick up without 08-merge.cocci - (nonexistent 08-merge.patch which would be generated by 08-merge.cocci if it could process servers/slapd/back-asyncmeta/search.c without timing out) Where a corresponding .cocci file is present, the patch has been generated with coccinelle[0] as of commit 42e4638bfacf13ab1a8acc35b40e216e34087578. To regenerate them (perhaps against a different OpenLDAP branch), the following command line can be used: spatch --timeout 300 --macro-file-builtins macros.h -dir --sp-file <cocci file> --dir . This will generate a patch on stdout, or, with "--in-place", will effect the changes directly on the source tree. The existence of 06-shortcut.cocci would not normally be necessary if the organisation of the file servers/slapd/back-meta/search.c did not cause coccinelle to take days to process it. This file is included for anyone trying to make sure the cleanup is complete even when some of the things that hold in OpenLDAP's master branch would not. Because of an oversight, this also means 08-merge.cocci does not perform all the clean up that 06-shortcut.cocci does and would need to be transplanted. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Ondřej Kuzník <okuznik(a)symas.com>. I have not assigned rights and/or interest in this work to any party. The attached semantic patches and modifications to OpenLDAP Software are subject to the following notice: Copyright 2017, Ondřej Kuzník <okuznik(a)symas.com>, 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#8730) Fixes to Debug() macro usage
by okuznik＠symas.com 12 Sep '17

12 Sep '17

Full_Name: Ondrej Kuznik Version: master OS: URL: ftp://ftp.openldap.org/incoming/debug_macro_refactor.tgz Submission from: (NULL) (82.10.24.68) There is some incorrect usage of the Debug macros that needs fixing before we can start making changes to the macros themselves. The patch 00-fixes.patch inside the linked archive (ftp://ftp.openldap.org/incoming/debug_macro_refactor.tgz) fixes these. The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Ondřej Kuzník <okuznik(a)symas.com>. I have not assigned rights and/or interest in this work to any party. The attached semantic patches and modifications to OpenLDAP Software are subject to the following notice: Copyright 2017, Ondřej Kuzník <okuznik(a)symas.com>, 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

Re: (ITS#6300) Add kqueue support to slapd
by quanah＠fast-mail.org 12 Sep '17

12 Sep '17

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

1 0

(ITS#8729) saslregex mapping failure
by mikedotjackson＠gmail.com 11 Sep '17

11 Sep '17

Full_Name: Mike Jackson Version: 2.4.45 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.157.185.162) On an server with KRB5_KTNAME and KRB5CCNAME in it's environment but without a functional /etc/krb5.conf file, olcAuthzRegexp mappings are completely ignored for EXTERNAL auth (in my tests, distinguished names for X.509 client authentication were not remapped until OL was able to kinit it's own kerberos ticket). This is a bit of a corner case, but a pretty annoying bug nonetheless when building up new servers and indicates a failure in logic somewhere or another. Chat logs follow: JoBbZ: podz: oh, you're saying that the regex fails if you use a *non* GSSAPI mechanism, and the krb5.conf can't talk to a KDC? [9:41pm] podz: yes [9:41pm] podz: and this is a dysfunction [9:41pm] JoBbZ: yes, that'd be a bug for sure [9:41pm] podz: it's really a dysfunction [9:42pm] JoBbZ: well, there should be zero reason for GSSAPI to even be initialized if using EXTERNAL [9:42pm] podz: precisely [9:42pm] tarpman: that's sounding more like a sasl bug so far... [9:42pm] podz: tarpman: like i said, i am not sure where the bug lies [9:43pm] podz: something is fishy, though [9:43pm] podz: now i am going to eat some cake and be back in 20-30 mins [9:44pm] JoBbZ: well, EXTERNAL is all openldap code, doesn't depend on cyrus-sasl [9:45pm] JoBbZ: so it could be a bug in OpenLDAP that it is calling cyrus-sasl at all in this case [9:45pm] podz: probably you are right

1 0

Re: (ITS#8474) Securely Erase BerElement Buffer After Use
by quanah＠symas.com 11 Sep '17

11 Sep '17

Hi Alan, Did you get a chance to finish the patch? Thanks, Quanah --On Tuesday, August 09, 2016 5:49 PM +0000 alcronin(a)cisco.com wrote: > SGksDQoNCkkgY2FuIHRha2UgYSBsb29rIGF0IHRoZSBzbGFwZCBzaWRlIGFuZCB0aG9zZSBvd > Ghl > ciByZXF1ZXN0cyBhbmQgaW1wbGVtZW50IHRoZSBmaXggdGhlcmUgYXMgd2VsbC4gSWYgdGhlc > mUg > YXJlIGFueSBvdGhlciBhcmVhcyBsZXQgbWUga25vdyBhbmQgSSBjYW4gYWRkcmVzcyB0aGVtI > HRv > LiBJIHdpbGwgdXBkYXRlIHRoZSBwYXRjaCB3aGVuIEkgaGF2ZSB0aG9zZSBjaGFuZ2VzIHJlY > WR5 > Lg0KDQpUaGUgY29tcGlsZXJzIHdpbGwgdHJlYXQgdGhhdCAobWVtc2V0IGJlaGF2aW91cikgY > XMg > YW4gb3B0aW1pemF0aW9uIGFuZCB3b3VsZCBiZSBoZXNpdGFudCB0byBjaGFuZ2UgaXQuIFRoa > XMg > aXMgbW9zdGx5IHNlZW4gaW4gR0NDIGFuZCBhbnkgdmFyaWFudHMuIFRoZXJlIGFyZSBvdGhlc > iBv > cHRpbWlzYXRpb25zIHN1Y2ggYXMgcmVtb3ZpbmcgdGhlIGNhbGwgdG8gdGhlIG1ldGhvZCBlb > nRp > cmVseSBpZiB0aGUgbmV4dCBvcGVyYXRpb24gaXMgYSBmcmVlIGFzIHRoaXMgd291bGQgYmUgc > 2Vl > biBieSB0aGUgY29tcGlsZXIgYXMgYSBuby1vcC4gUmVtb3Zpbmcgb3B0aW1pc2F0aW9ucyBpc > yBu > b3QgaWRlYWwgYXMgaXQgY2FuIGFmZmVjdCBtb3JlIHRoYW4ganVzdCB0aGUgc2VjdGlvbiBvZ > iB0 > aGUgY29kZSBhbmQgaXMgbm90IGEgY3Jvc3MgcGxhdGZvcm0gc29sdXRpb24uDQoNClRoYW5rc > ywN > CkFsYW4NCg0KT24gMDgvMDgvMjAxNiwgMjE6MzcsICJIb3dhcmQgQ2h1IiA8aHljQHN5bWFzL > mNv > bT4gd3JvdGU6DQoNCiAgICBBbGFuIENyb25pbiAoYWxjcm9uaW4pIHdyb3RlOg0KICAgID4gS > Gkg > SG93YXJkLA0KICAgID4NCiAgICA+IEkgY2FuIGNoYW5nZSB0aGUgY29kZSBzbyB0aGF0IGl0I > G92 > ZXJ3cml0ZXMgdGhlIG1lbW9yeSBmcm9tDQogICAgbGRhcF9mcmVlX3JlcXVlc3RfaW50KCkga > W5z > dGVhZC4gVGhpcyB3aWxsIGNvdmVyIHRoZSBleGVjdXRpb24gdXNpbmcgYSBiaW5kDQogICAgK > GJv > dGggc3luY2hyb25vdXMgYW5kIGFzeW5jaHJvbm91cykuIElzIHRoZXJlIGFueSBvdGhlciBwb > GFj > ZXMgd2hlcmUgdGhlDQogICAgcGFzc3dvcmQgd291bGQgYmUgaW4gdGhlIGJ1ZmZlciB0aGF0I > G5l > ZWRzIHRvIGJlIGNsZWFyZWQ/IFRoZSByZWFzb24gZm9yDQogICAgaW5zZXJ0aW5nIGl0IGlud > G8g > YmVyX2ZyZWVfYnVmKCkgd2FzIHRoYXQgaXQgd291bGQgY2xlYXIgYWxsIHBsYWNlcy4NCiAgI > CAN > CiAgICBJIHNlZSwgeW91J3JlIGxvb2tpbmcgYXQgdGhlIGNsaWVudCBzaWRlLiBXaGF0IGFib > 3V0 > IHRoZSBzbGFwZCBzaWRlPw0KICAgIA0KICAgIFRoZXJlIGFyZSAyIG1haW4gcGxhY2VzIHdoZ > XJl > IHBhc3N3b3JkcyBvY2N1ciAtIEJpbmQsIGFuZCBQYXNzd29yZE1vZGlmeSBleG9wLiANCiAgI > CBU > aGV5IG1pZ2h0IGFsc28gb2NjdXIgaW4gQWRkIGFuZCBNb2RpZnkgcmVxdWVzdHMuIEFkZCBpc > yBu > b3Qgc28gdW51c3VhbCwgDQogICAgTW9kaWZ5IHNob3VsZCBub3QgaGFwcGVuIHNpbmNlIGNsa > WVu > dHMgc2hvdWxkIHVzZSBQYXNzd29yZE1vZGlmeSBpbnN0ZWFkLg0KICAgIA0KICAgID4gU29tZ > SBj > b21waWxlcnMgd2lsbCBvcHRpbWl6ZSBjYWxscyB0byBtZW1zZXQoKSBzbyB0aGF0IG9ubHkgd > Ghl > IGZpcnN0DQogICAgY2hhcmFjdGVyIHdpbGwgYmUgY2hhbmdlZC4gTGVhdmluZyB0aGUgcmVzd > CBv > ZiB0aGUgc3RyaW5nIGludGFjdC4NCiAgICANCiAgICBUaGF0J3MgY2xlYXJseSBhIGNvbXBpb > GVy > IGJ1ZyB0aGVuLiBJZiB5b3UgaGF2ZSBleGFtcGxlcyBvZiBzdWNoIHNpdHVhdGlvbnMgDQogI > CAg > eW91IHNob3VsZCByZXBvcnQgdGhhdCB0byB0aGUgcmVzcGVjdGl2ZSBjb21waWxlciBtYWlud > GFp > bmVycy4NCiAgICANCiAgICA+IFRoaXMgaXMgd2h5DQogICAgdGhlIGl0ZXJhdGlvbiBpcyBpb > iBw > bGFjZS4NCiAgICA+DQogICAgPiBUaGFua3MgZm9yIGxvb2tpbmcgaW50byB0aGlzIHBhdGNoL > g0K > ICAgID4NCiAgICA+IEFsYW4NCiAgICA+DQogICAgPiBPbiAwNS8wOC8yMDE2LCAxOTo1MCwgI > khv > d2FyZCBDaHUiIDxoeWNAc3ltYXMuY29tPiB3cm90ZToNCiAgICA+DQogICAgPiAgICAgIGFsY > 3Jv > bmluQGNpc2NvLmNvbSB3cm90ZToNCiAgICA+ICAgICAgPiBGdWxsX05hbWU6IEFsYW4gQ3Jvb > mlu > DQogICAgPiAgICAgID4gVmVyc2lvbjogMi40LjQ0DQogICAgPiAgICAgID4gT1M6IFdpbmRvd > 3Mg > OC4xDQogICAgPiAgICAgID4gVVJMOiBodHRwczovL2RsLmRyb3Bib3h1c2VyY29udGVudC5jb > 20v > dS84MjM0MzQ3NS9TZWN1cmVseUVyYXNlQnVmZmVyLmRpZmYNCiAgICA+ICAgICAgPiBTdWJta > XNz > aW9uIGZyb206IChOVUxMKSAoMjAwMTo0MjA6NDA0MToyMDAzOmY5NDI6NTlhNTo1NDVmOmIzM > zQp > DQogICAgPiAgICAgID4NCiAgICA+ICAgICAgPg0KICAgID4gICAgICA+IFRoZSBmb2xsb3dpb > mcg > cGF0Y2ggaXMgYSBtb2RpZmljYXRpb24gdG8gdGhlIE9wZW5MREFQIEJlckVsZW1lbnQgYnVmZ > mVy > LiBUaGUNCiAgICA+ICAgICAgPiBidWZmZXIgY2FuIGJlIHVzZWQgdG8gY29udGFpbiB0aGUgT > ERB > UCByZXF1ZXN0IGluY2x1ZGluZyB0aGUgcGFzc3dvcmQgZm9yDQogICAgPiAgICAgID4gYXV0a > GVu > dGljYXRpb24uIFdoaWxlIHRoaXMgaXMgZnJlZSdkIHdoZW4gaXQgaXMgbm8gbG9uZ2VyIG5lZ > WRl > ZCwgdGhlIGNvbnRlbnRzDQogICAgPiAgICAgID4gb2YgdGhlIGJ1ZmZlciBpcyBub3Qgb3Zlc > ndy > aXR0ZW4gZnJvbSBtZW1vcnkuIFRoaXMgY2FuIGxlYWQgdG8gc29tZW9uZSByZWFkaW5nDQogI > CAg > PiAgICAgID4gdGhlIG1lbW9yeSBvZiB0aGUgcHJvY2VzcyBhbmQgZGV0ZXJtaW5pbmcgd2hhd > CB0 > aGUgcGFzc3dvcmQgaXMuIFRoZSBjaGFuZ2UNCiAgICA+ICAgICAgPiBpbmNsdWRlZCBpbiB0a > Glz > IHBhdGNoIHdpbGwgaXRlcmF0ZSBvdmVyIHRoZSBtZW1vcnkgYW5kIGNsZWFyIGl0LiBUaGlzI > Hdp > bGwNCiAgICA+ICAgICAgPiByZW1vdmUgYW55IHRyYWNlIG9mIHRoZSBwYXNzd29yZCBieSB0a > GUg > dGltZSBleGVjdXRpb24gaXMgaGFuZGVkIGJhY2sgdG8gdGhlDQogICAgPiAgICAgID4gY2Fsb > GVy > Lg0KICAgID4NCiAgICA+ICAgICAgV2h5IHdvdWxkIHlvdSBpbnNlcnQgYSBwZXJmb3JtYW5jZ > SBw > ZXNzaW1pemF0aW9uIGludG8gZXZlcnkgdXNlIG9mIHRoZSBMQkVSDQogICAgPiAgICAgIGxpY > nJh > cnksIHJhdGhlciB0aGFuIGp1c3QgZXJhc2luZyB0aGUgcGFzc3dvcmQgZnJvbSBhIEJpbmQgc > mVx > dWVzdD8NCiAgICA+DQogICAgPiAgICAgIFdoeSB3b3VsZCB5b3UgdXNlIGFuIGV4cGxpY2l0b > Hkg > Y29kZWQgbG9vcCBzZXR0aW5nIG9uZSBjaGFyYWN0ZXIgYXQgYSB0aW1lLA0KICAgID4gICAgI > CBp > bnN0ZWFkIG9mIHVzaW5nIGxpYmMncyBtZW1zZXQoKSB3aGljaCBoYXMgcHJvYmFibHkgYmVlb > iB3 > ZWxsIG9wdGltaXplZD8NCiAgICA+DQogICAgPiAgICAgID4gVGhlIGF0dGFjaGVkIHBhdGNoI > GZp > bGUgaXMgZGVyaXZlZCBmcm9tIE9wZW5MREFQIFNvZnR3YXJlLiBBbGwgb2YgdGhlDQogICAgP > iAg > ICAgID4gbW9kaWZpY2F0aW9ucyB0byBPcGVuTERBUCBTb2Z0d2FyZSByZXByZXNlbnRlZCBpb > iB0 > aGUgZm9sbG93aW5nIHBhdGNoKGVzKSB3ZXJlDQogICAgPiAgICAgID4gZGV2ZWxvcGVkIGJ5I > EFs > YW4gQ3JvbmluIGFsY3JvbmluQGNpc2NvLmNvbS4gSSBoYXZlIG5vdCBhc3NpZ25lZCByaWdod > HMg > YW5kL29yDQogICAgPiAgICAgID4gaW50ZXJlc3QgaW4gdGhpcyB3b3JrIHRvIGFueSBwYXJ0e > S4N > CiAgICA+ICAgICAgPiBUaGUgYXR0YWNoZWQgZmlsZSBpcyBkZXJpdmVkIGZyb20gT3BlbkxEQ > VAg > U29mdHdhcmUuIEFsbCBvZiB0aGUgbW9kaWZpY2F0aW9ucyB0bw0KICAgID4gICAgICA+IE9wZ > W5M > REFQIFNvZnR3YXJlIHJlcHJlc2VudGVkIGluIHRoZSBmb2xsb3dpbmcgcGF0Y2goZXMpIHdlc > mUg > ZGV2ZWxvcGVkIGJ5IENpc2NvDQogICAgPiAgICAgID4gU3lzdGVtcywgSW5jLi4gQ2lzY28gU > 3lz > dGVtcywgSW5jLiBoYXMgbm90IGFzc2lnbmVkIHJpZ2h0cyBhbmQvb3IgaW50ZXJlc3QgaW4NC > iAg > ICA+ICAgICAgPiB0aGlzIHdvcmsgdG8gYW55IHBhcnR5LiBJLCBBbGFuIENyb25pbiBhbSBhd > XRo > b3JpemVkIGJ5IENpc2NvIFN5c3RlbXMsIEluYy4sIG15DQogICAgPiAgICAgID4gZW1wbG95Z > XIs > IHRvIHJlbGVhc2UgdGhpcyB3b3JrIHVuZGVyIHRoZSBmb2xsb3dpbmcgdGVybXMuDQogICAgP > iAg > ICAgID4gQ2lzY28gU3lzdGVtcywgSW5jLiBoZXJlYnkgcGxhY2UgdGhlIGZvbGxvd2luZyBtb > 2Rp > ZmljYXRpb25zIHRvIE9wZW5MREFQDQogICAgPiAgICAgID4gU29mdHdhcmUgKGFuZCBvbmx5I > HRo > ZXNlIG1vZGlmaWNhdGlvbnMpIGludG8gdGhlIHB1YmxpYyBkb21haW4uIEhlbmNlLCB0aGVzZ > Q0K > ICAgID4gICAgICA+IG1vZGlmaWNhdGlvbnMgbWF5IGJlIGZyZWVseSB1c2VkIGFuZC9vciByZ > WRp > c3RyaWJ1dGVkIGZvciBhbnkgcHVycG9zZSB3aXRoIG9yDQogICAgPiAgICAgID4gd2l0aG91d > CBh > dHRyaWJ1dGlvbiBhbmQvb3Igb3RoZXIgbm90aWNlLg0KICAgID4gICAgICA+DQogICAgPiAgI > CAg > ID4NCiAgICA+DQogICAgPg0KICAgID4gICAgICAtLQ0KICAgID4gICAgICAgICAtLSBIb3dhc > mQg > Q2h1DQogICAgPiAgICAgICAgIENUTywgU3ltYXMgQ29ycC4gICAgICAgICAgIGh0dHA6Ly93d > 3cu > c3ltYXMuY29tDQogICAgPiAgICAgICAgIERpcmVjdG9yLCBIaWdobGFuZCBTdW4gICAgIGh0d > HA6 > Ly9oaWdobGFuZHN1bi5jb20vaHljLw0KICAgID4gICAgICAgICBDaGllZiBBcmNoaXRlY3QsI > E9w > ZW5MREFQICBodHRwOi8vd3d3Lm9wZW5sZGFwLm9yZy9wcm9qZWN0Lw0KICAgID4NCiAgICA+D > Qog > ICAgDQogICAgDQogICAgLS0gDQogICAgICAgLS0gSG93YXJkIENodQ0KICAgICAgIENUTywgU > 3lt > YXMgQ29ycC4gICAgICAgICAgIGh0dHA6Ly93d3cuc3ltYXMuY29tDQogICAgICAgRGlyZWN0b > 3Is > IEhpZ2hsYW5kIFN1biAgICAgaHR0cDovL2hpZ2hsYW5kc3VuLmNvbS9oeWMvDQogICAgICAgQ > 2hp > ZWYgQXJjaGl0ZWN0LCBPcGVuTERBUCAgaHR0cDovL3d3dy5vcGVubGRhcC5vcmcvcHJvamVjd > C8N CiAgICANCg0K > > > -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8396) syncprov hourly fails to answer syncrepl
by quanah＠symas.com 11 Sep '17

11 Sep '17

--On Monday, April 04, 2016 7:57 PM +0000 Frank.Swasey(a)uvm.edu wrote: > The bad log entries that coincide with check_syncrepl finding the replica > has fallen behind are like: > > Apr 4 13:18:27 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 > Apr 4 13:18:27 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 > Apr 4 14:18:53 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 > Apr 4 14:18:53 ldap7p slapd[27800]: syncprov_sendresp: cookie=rid=100 > > They appear once an hour. Hi Frank, This looks like ITS#8444, which now has a fix checked into OpenLDAP master. You probably want to apply it to your deployment. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

(ITS#8728) MDB_VL32 bug deleting overflow pages
by hyc＠openldap.org 09 Sep '17

09 Sep '17

Full_Name: Howard Chu Version: mdb.master OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.136.45.114) Submitted by: hyc The cursor's mc_ovpg pointer must be cleared after freeing a dirty overflow page, otherwise a use-after-free can occur later.

1 0

Re: (ITS#8722) MDB_LAST_DUP/FIRST_DUP return item beyond last item
by h.b.furuseth＠usit.uio.no 08 Sep '17

08 Sep '17

mdb_cursor_del()'s NUMKEYS() check in your fix (f34b61f9471d1c03fe0517b9d817c50c920e378a) looks like a general cursor tracking issue, so XCURSOR_REFRESH() should check it too. Unless we've got some ugliness where mp_lower is temporarily too small, but I haven't spotted anything like that. The mdb_cursor_del() is still wrong: The mn_flags check doesn't skip non-DUPDATA nodes. Using XCURSOR_REFRESH() fixes it. And it should use XCURSOR_INITED() like other XCURSOR_REFRESH() callers. Suggested fixes - branch "xcursor-its8722" @ symas.

1 0

Re: (ITS#8692) back-sock does not create LDAP_MOD_INCREMENT message
by quanah＠symas.com 08 Sep '17

08 Sep '17

--On Friday, September 08, 2017 7:27 PM +0000 michael(a)stroeder.com wrote: > Is there anything wrong with the patch herein? Hi Michael, I've added this to my openldap-scratch repo where I'm pulling in patches for review for inclusion into the overall project. I'll be sending out an email to -devel soon covering all the ITSes I have queued up needing review. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8692) back-sock does not create LDAP_MOD_INCREMENT message
by michael＠stroeder.com 08 Sep '17

08 Sep '17

Is there anything wrong with the patch herein?

1 0

(ITS#8727) Potential memory leaks in ldap_send_server_request()
by hyc＠openldap.org 08 Sep '17

08 Sep '17

Full_Name: Howard Chu Version: 2.4 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.136.45.114) Submitted by: hyc There are two error paths don't call ber_free() as all the other ones do. One is only in LDAP_CONNECTIONLESS code so quite rare. One occurs if ldap_int_flush_request() fails when flushing an earlier partial write. Also quite rare but has been seen occasionally.

1 0

Re: (ITS#7996) Global initialisation race in ldap_int_initialize
by quanah＠symas.com 08 Sep '17

08 Sep '17

--On Friday, September 08, 2017 1:02 PM +0000 a.cudbardb(a)freeradius.org wrote: >> Thanks for the report and sorry for the delay on getting to this = > issue. I would note that for the fix to be included in the OpenLDAP = > project, we need an IPR statement, as noted at = > <https://www.openldap.org/devel/contributing.html>. If you can provide = > that, and (if possible) submit the patch as git format-patch via the = > project FTP server (include the URL in your email), then I can pull it = > in. > > IPR statement is not a problem, but I don't have the original diff to = > work from. If you can send me a copy of the FTP submission I can = > reformat it and resubmit it. Hi Arran, The diff is in your github issues tracker. ;) <https://github.com/arr2036/ldapperf/issues/2#issuecomment-66242732> Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#7996) Global initialisation race in ldap_int_initialize
by a.cudbardb＠freeradius.org 08 Sep '17

08 Sep '17

--Apple-Mail=_95BF47BF-6363-41EE-A6CE-44E52E5DA9A1 Content-Type: multipart/mixed; boundary="Apple-Mail=_65FA453F-90D8-41E7-BEB1-EF56933D959A" --Apple-Mail=_65FA453F-90D8-41E7-BEB1-EF56933D959A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi Quanah, > Thanks for the report and sorry for the delay on getting to this = issue. I would note that for the fix to be included in the OpenLDAP = project, we need an IPR statement, as noted at = <https://www.openldap.org/devel/contributing.html>. If you can provide = that, and (if possible) submit the patch as git format-patch via the = project FTP server (include the URL in your email), then I can pull it = in. IPR statement is not a problem, but I don't have the original diff to = work from. If you can send me a copy of the FTP submission I can = reformat it and resubmit it. Many Thanks, -Arran Arran Cudbard-Bell <a.cudbardb(a)freeradius.org> FreeRADIUS Development Team FD31 3077 42EC 7FCD 32FE 5EE2 56CF 27F9 30A8 CAA2 --Apple-Mail=_65FA453F-90D8-41E7-BEB1-EF56933D959A Content-Disposition: attachment; filename=a_cudbardb_openldap_ipr_statement.txt.asc Content-Type: application/octet-stream; x-unix-mode=0644; name="a_cudbardb_openldap_ipr_statement.txt.asc" Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 The provided patch file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Arran Cudbard-Bell a.cudbardb(a)freeradius.org. I have not assigned rights and/or interest in this work to any party. I, Arran Cudbard-Bell, hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice. -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZsoaLAAoJEP+k1YKfttfKGV0P/3gpa+4LOb6ncwGwLgenRuqm Bq3ZgvozcMa2jmCk5atWmc3Jv8v5ysPc7VK9Lw4Zb4PZF2hsEqCCFIsU5Bt01poU qPu4yv8BndplIhR4vNEDX83z31RYqS4JlIVPdedFGEN3HuB5yTxp+bsUmMvIDpx6 ZFxgpfAIrNaPUBcfHaudBJ+1XiS4q64Sp1oHyGOmrbP+6IvrQirPj8zu3N6A9BGA UQGLlIFWmX1557EuYn6BkCCAtmKhe8b8lI9bIQaS4EBOGAeHKIhbCC4ptXAzMfrV 1sXXM6ziBSOWeyiZe0OkAdzoxIufpAPjO47coT71Ttw4rjlKDP2+VbSOamf4tLu8 njbt3HEtB0xscetKIPutcWAgnapFvNPB3sCHtHhd1yW2jAnA9AhASgjGyJSuK7sB tPocdgZJgksiqXgXe1ameazc9/jGpGd+1GGQo3kPMv6VQ5iUpInRqOWSarQAH3Rp E2IbaZAkzep9PD5mNslZHp//bXeAvfRugXjvuS1zjxwYeCaYEdvFX307BBtnaFKW 3i1qU8P4l9iyxxI9qxe+xcn121sA+fl5Ka0++1QWmg2QjeJvwynehN5qePwO+zFY WbOM1h8ztKWjFmdZ+6/4ZIjjIN22Bxt/c2235TPbAwTTsnwKG4UU5o/f+tL937b9 uhb+P27BWGmtr7fvPM+S =BAuq -----END PGP SIGNATURE----- --Apple-Mail=_65FA453F-90D8-41E7-BEB1-EF56933D959A-- --Apple-Mail=_95BF47BF-6363-41EE-A6CE-44E52E5DA9A1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJZsoa4AAoJEP+k1YKfttfKhuoQAIrSvVKQ31tqvi2NqH0Uc83b pArApt8XDS59yuYyMJUoA6US/LelLQeLiuWb2wnoRET4WRCSZttiKuHwXJ808m8E n5fC/FMAuXWzDnDKN4IXFTpsGk7T38vqkRuvEmSnx9p6mphaZtvcR52Sy2WqhK3H TgYdvp4SSPSS9IxZDKMrMORrrl3qj7BAjxEtEdG96Wir+kYFZPKyNmwyG0i9rf2n mB7ngTvWRcPSQ4SMJs5y7Cjbp8e9NiucQJlbbXxVTIcIBPBGfYEQs81w89UL7IY8 B8NagzvCRDCXGHCTSxuzjjNGOjPLMCpnfGYSGfoHWNcYsc0TCXz/mtnrw7fK9ZYR 8mGRRx3eZrQclqhQkaySdSp7hU4Cu51MzmWRbn853vDfsKwieGYeUJ1S4Ti1uviJ gJG9sHB3AwnkW/QRA6GOCuxNYw3mL6ai2uzVV9HD30wk1JOkEtVosC2ILj3hpDpo oG7GwSgwA2tWmv6bMn7oLZn/8nN6LCanOFUq/iXOnedXfvCcQNqpHls5hoAAnaU4 PR+KBdksxMsHG8qhRA9ZNW3OJvRV45/ms3sU+0ITU6VzkH0b54cd06IiORBZDw5h KgIYmPWMuctMiZcVet2US5QLWs809LfzAjyfKy1JAS1+x1ek5LtgBgDe/FgIAiNS Dw29LYUKqCOAr1NZdgNd =MuFe -----END PGP SIGNATURE----- --Apple-Mail=_95BF47BF-6363-41EE-A6CE-44E52E5DA9A1--

1 0

RE: (ITS#8436) slapadd hang in bdb_tool_entry_close / ldap_pvt_thread_cond_wait
by Mark.Bannister＠morganstanley.com 08 Sep '17

08 Sep '17

> Hi Mark, >=20 > I would note that no patch for this issue has ever been submitted to the = tracker, nor is there any IPR, etc. I did track > down your suggested fix via the mailing list thread. However, that is no= t sufficient for it to be included in the > OpenLDAP project. > > Please see <http://www.openldap.org/devel/contributing.html> for the corr= ect procedure for submitting your fix if you would like it to be included. >=20 > Thanks, > Quanah Hi Quanah, I was reporting a bug, not a patch. There were multiple ways of fixing it.= I provided one suggested fix here: http://www.openldap.org/lists/openldap-technical/201605/msg00103.html but quickly followed that up with another idea: http://www.openldap.org/lists/openldap-technical/201605/msg00104.html Of course moving to LMDB would be the best approach, but we're still not th= ere yet, it takes a long time to switch directory format when you're dealin= g with hundreds of OpenLDAP instances on Solaris 11 (esp. where Oracle have= only recently provided a way of upgrading from 2.4.30 to 2.4.44). Best regards, Mark. ---------------------------------------------------------------------------= ----- NOTICE: Morgan Stanley is not acting as a municipal advisor and the opinion= s or views contained herein are not intended to be, and do not constitute, = advice within the meaning of Section 975 of the Dodd-Frank Wall Street Refo= rm and Consumer Protection Act. If you have received this communication in = error, please destroy all electronic and paper copies and notify the sender= immediately. Mistransmission is not intended to waive confidentiality or p= rivilege. Morgan Stanley reserves the right, to the extent permitted under = applicable law, to monitor electronic communications. This message is subje= ct to terms available at the following link: http://www.morganstanley.com/d= isclaimers If you cannot access these links, please notify us by reply mes= sage and we will send the contents to you. By communicating with Morgan Sta= nley you consent to the foregoing and to the voice recording of conversatio= ns with personnel of Morgan Stanley.=

1 0

Re: (ITS#8508) PATCH - ucgendat.c properly add title-case characters without upper-case equivalents (e.g. greek letters with iota subscript)
by z.figura12＠gmail.com 08 Sep '17

08 Sep '17

Hello Quanah, I have resent the patch including an IPR: ftp://ftp.openldap.org/incoming/zebediah-figura-170907.patch Thank you for the attention.

1 0

Re: (ITS#8726) slapd -d pcache not available when pcache is a module
by adam＠brainfood.com 08 Sep '17

08 Sep '17

After further reading of the code, in ldap_log.h, I see LDAP_DEBUG options that are no longer supported(_CACHE and _INDEX). Based on that, I then specify -d 4096, and now I see the debug logs from pcache. This is because that's the first mask value discovered that is not used by the known log levels. However, that depends on the ordering of the modules, which seems fraught with error. On Thu, Sep 7, 2017 at 4:32 PM, <openldap-its(a)openldap.org> wrote: > > *** THIS IS AN AUTOMATICALLY GENERATED REPLY *** > > Thanks for your report to the OpenLDAP Issue Tracking System. Your > report has been assigned the tracking number ITS#8726. > > One of our support engineers will look at your report in due course. > Note that this may take some time because our support engineers > are volunteers. They only work on OpenLDAP when they have spare > time. > > If you need to provide additional information in regards to your > issue report, you may do so by replying to this message. Note that > any mail sent to openldap-its(a)openldap.org with (ITS#8726) > in the subject will automatically be attached to the issue report. > > mailto:openldap-its@openldap.org?subject=(ITS#8726) > > You may follow the progress of this report by loading the following > URL in a web browser: > http://www.OpenLDAP.org/its/index.cgi?findid=8726 > > Please remember to retain your issue tracking number (ITS#8726) > on any further messages you send to us regarding this report. If > you don't then you'll just waste our time and yours because we > won't be able to properly track the report. > > Please note that the Issue Tracking System is not intended to > be used to seek help in the proper use of OpenLDAP Software. > Such requests will be closed. > > OpenLDAP Software is user supported. > http://www.OpenLDAP.org/support/ > > -------------- > Copyright 1998-2007 The OpenLDAP Foundation, All Rights Reserved. >

1 0

(ITS#8726) slapd -d pcache not available when pcache is a module
by adam＠brainfood.com 07 Sep '17

07 Sep '17

Full_Name: Adam Heath Version: OS: debian stretch URL: Submission from: (NULL) (99.146.168.62) 1: In slapd/main.c, parse_debug_level adds 'pcache' to the global debug_unknowns. 2: main() then calls read_config() 3: eventually, overlay pcache is read from the config file 4: pcache calls slap_loglevel_get, to configure it's static int pcache_debug 5: pcache calls config_register_schema, so the pcache config options can be parsed 6: eventually, pcache:pc_cf_gen() is called, to handle the pcacheTemplate option 7: pc_cf_gen calls Debug(pcache_debug) 8: back in main(), immediately after read_config(), parse_debug_unknowns is called to add the enabled debug levels into the global slapd_debug bit mask. It'd be nice if I could see the pcache_debug calls when pcache is configured as a module, instead of having to statically compile it into slapd. If I use "-d -1", then I *do* see those pcache_debug calls, but then I also see *everything else*.

1 0

(ITS#8725) Additional support for asynchronous operation
by hyc＠openldap.org 07 Sep '17

07 Sep '17

Full_Name: Howard Chu Version: 2.5 OS: URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (83.136.45.114) Submitted by: hyc Some small frontend tweaks to better support back-asyncmeta

1 0

Re: (ITS#8427) Incorrect value of tls_reqcert in syncrepl
by quanah＠symas.com 07 Sep '17

07 Sep '17

--On Wednesday, October 05, 2016 7:25 PM +0000 mkp37215(a)gmail.com wrote: > Since more than four months have passed since last message here, I > would like to ask if any progress has been made in this matter? Has > anyone looked into my patch? Hi, I'm working on incorporating submissions in the ITS system. This report is missing an IPR which is required for it to be included in the project. Please see <http://www.openldap.org/devel/contributing.html> and update this ITS with your IPR when possible. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8578)
by quanah＠symas.com 07 Sep '17

07 Sep '17

--On Sunday, March 19, 2017 3:56 PM +0000 sca+openldap(a)andreasschulze.de wrote: > uploaded a new version: > ftp://ftp.openldap.org/incoming/andreas-schulze-its8578-20170319.patch Hi Andreas, For this to be included in the OpenLDAP project an IPR is necessary as documented at <http://www.openldap.org/devel/contributing.html>. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8508) PATCH - ucgendat.c properly add title-case characters without upper-case equivalents (e.g. greek letters with iota subscript)
by quanah＠symas.com 07 Sep '17

07 Sep '17

Hello Zebediah, Thanks for your submission. However your report is missing an IPR which is required for it to be included with OpenLDAP. Please see <http://www.openldap.org/devel/contributing.html> for futher information on how to provide the required IPR information. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8349) fix ppolicy issue
by quanah＠symas.com 07 Sep '17

07 Sep '17

--On Tuesday, January 12, 2016 7:28 AM +0000 hamano(a)osstech.co.jp wrote: > Full_Name: HAMANO Tsukasa > Version: 2.4.43 > OS: Linux > URL: > https://www.osstech.co.jp/download/hamano/openldap/ppolicy_fix_pwdInHisto > ry.patch Submission from: (NULL) (240b:10:2640:bf0:290:4cff:fe0d:f43e) > > > We fixed several issue around ppolicy. > > 1) reduce pwdInHistory > If set pwdInHistory to 5 then reduce pwdInHistory to 3, > We expect to check password with three history, but ppolicy check > password with all pwdHistory attribute. > > 2) reduce pwdInHistory to zero > If set pwdInHistory to 5 then reduce pwdInHistory to 0, > We expect that ppolicy password checking will be disbale. but the > pwdHistory attribute are remains, so password checking is still > enabled. > We need to remove pwdHistory attribute. Hi, I'm working on catching up on old ITS submissions. This submission is missing an IPR and cannot be included until it is provided. Please see <http://www.openldap.org/devel/contributing.html> for information on the IPR requirements. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8724) slapo-pcache truncates remote results
by adam＠brainfood.com 07 Sep '17

07 Sep '17

Cool. I've looked at pcache.c, and realized I'm a noob with this code. Basically, my thoughts, is that pcache should ignore the incoming search request, and recreate it's own with it's own options, always asking for paging. Then page through all the results from the backend, then store the full set in the backing store. While that is going on, the cache entry should be marked with a bit flag saying that it's in the process of being built, but otherwise can still store the entries fetched thus far. Meanwhile, the frontend request can begin to return results from this partially resolved backend entry stored in the cache, utilizing whatever pagination value(and or offset/limit) has been requested. Of course, that's just the high-level description, not even really pseudo-code ready. As an aside, and this s/b a separate bug, if an error occurs from the backend this does *not* get cached. Aka, during this investigation, my backend is returning 2000 entries, err=4. This takes 7s each time(I'm in Dallas, while the backend is in California, and I'm communicating over a tunnel). It's not cached, so the request is passed through each time. I've configured the templates correctly, and the debug shows that the request is CACHEABLE. On Wed, Sep 6, 2017 at 6:22 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > --On Wednesday, September 06, 2017 7:06 PM -0500 Adam Heath > <adam(a)brainfood.com> wrote: > > >> Well, then since you are confirming the bug, I would say this ticket >> should *not* be closed. > > > I already reopened it. ;) > >> I might just have to patch this to make it work. > > > Make sure you follow the contribution guidelines: > > <https://www.openldap.org/devel/contributing.html> > > Thanks, > > Quanah > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Re: (ITS#7996) Global initialisation race in ldap_int_initialize
by quanah＠symas.com 07 Sep '17

07 Sep '17

--On Tuesday, December 09, 2014 6:14 PM +0000 a.cudbardb(a)freeradius.org wrote: > Full_Name: Arran Cudbard-Bell > Version: 2.4.40 > OS: OSX 10.10.1 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.196.165.104) Hi Arran, Thanks for the report and sorry for the delay on getting to this issue. I would note that for the fix to be included in the OpenLDAP project, we need an IPR statement, as noted at <https://www.openldap.org/devel/contributing.html>. If you can provide that, and (if possible) submit the patch as git format-patch via the project FTP server (include the URL in your email), then I can pull it in. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8436) slapadd hang in bdb_tool_entry_close / ldap_pvt_thread_cond_wait
by quanah＠symas.com 07 Sep '17

07 Sep '17

Hi Mark, I would note that no patch for this issue has ever been submitted to the tracker, nor is there any IPR, etc. I did track down your suggested fix via the mailing list thread. However, that is not sufficient for it to be included in the OpenLDAP project. Please see <http://www.openldap.org/devel/contributing.html> for the correct procedure for submitting your fix if you would like it to be included. Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8674) Leak in ldap_create_assertion_control
by come＠opensides.be 07 Sep '17

07 Sep '17

--nextPart2367739.nNEjSNJblS Content-Type: multipart/mixed; boundary="nextPart4704199.6R7aSYJDEk" Content-Transfer-Encoding: quoted-printable This is a multi-part message in MIME format. --nextPart4704199.6R7aSYJDEk Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Hello, I encountered this bug as well while adding controls support into php-ldap (see https://github.com/php/php-src/pull/2640 - WIP) I used the work-around but it would still be better to fix this in openldap. Please consider merging the attached patch. --nextPart4704199.6R7aSYJDEk Content-Disposition: attachment; filename="0001-Fixing-8674-Leak-in-ldap_create_assertion_control.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="0001-Fixing-8674-Leak-in-ldap_create_assertion_control.patch" From=2059e15d7cd5217312fcc6e3343476416a39cdc739 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?C=C3=B4me=20Chilliet?= <come(a)opensides.be> Date: Thu, 7 Sep 2017 17:11:57 +0200 Subject: [PATCH] Fixing #8674 Leak in ldap_create_assertion_control ldap_create_assertion_control_value was returning ld->ld_errno upon success without reseting it to LDAP_SUCCESS first --- libraries/libldap/assertion.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libraries/libldap/assertion.c b/libraries/libldap/assertion.c index 8ccd5c188..e736d59eb 100644 --- a/libraries/libldap/assertion.c +++ b/libraries/libldap/assertion.c @@ -31,6 +31,8 @@ ldap_create_assertion_control_value( BerElement *ber = NULL; int err; + ld->ld_errno = LDAP_SUCCESS; + if ( assertion == NULL || assertion[ 0 ] == '\0' ) { ld->ld_errno = LDAP_PARAM_ERROR; return ld->ld_errno; -- 2.11.0 --nextPart4704199.6R7aSYJDEk-- This is a multi-part message in MIME format. --nextPart4704199.6R7aSYJDEk Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Hello, I encountered this bug as well while adding controls support into php-ldap (see https://github.com/php/php-src/pull/2640 - WIP) I used the work-around but it would still be better to fix this in openldap. Please consider merging the attached patch. --nextPart4704199.6R7aSYJDEk Content-Disposition: attachment; filename="0001-Fixing-8674-Leak-in-ldap_create_assertion_control.patch" Content-Transfer-Encoding: 7Bit Content-Type: text/x-patch; charset="UTF-8"; name="0001-Fixing-8674-Leak-in-ldap_create_assertion_control.patch" >From 59e15d7cd5217312fcc6e3343476416a39cdc739 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?C=C3=B4me=20Chilliet?= <come(a)opensides.be> Date: Thu, 7 Sep 2017 17:11:57 +0200 Subject: [PATCH] Fixing #8674 Leak in ldap_create_assertion_control ldap_create_assertion_control_value was returning ld->ld_errno upon success without reseting it to LDAP_SUCCESS first --- libraries/libldap/assertion.c | 2 ++ 1 file changed, 2 insertions(+) diff --git a/libraries/libldap/assertion.c b/libraries/libldap/assertion.c index 8ccd5c188..e736d59eb 100644 --- a/libraries/libldap/assertion.c +++ b/libraries/libldap/assertion.c @@ -31,6 +31,8 @@ ldap_create_assertion_control_value( BerElement *ber = NULL; int err; + ld->ld_errno = LDAP_SUCCESS; + if ( assertion == NULL || assertion[ 0 ] == '\0' ) { ld->ld_errno = LDAP_PARAM_ERROR; return ld->ld_errno; -- 2.11.0 --nextPart4704199.6R7aSYJDEk-- --nextPart2367739.nNEjSNJblS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEnJSNrcx2T3JL/3cLqGTYw87LDgAFAlmxaNcACgkQqGTYw87L DgAVJA/+IlrkY3qAMDWe3CqrX4XDwFcA2C3BNzLuPvsymVl2vWNjwn/t7HmpWR2v Hs+mLeTZwe/Z7+zej5H0FujRzHnzaEm3OsGf26mPZeeIRkC1PvE9CLUZzn4M9Mak fejbb2a4EcQnPy7aAD/3Ux2mjJgF2Bl3zc8K0rQO9VSxjpNErt8U2aKgKB+t1QFb /rV4+p/ovRbFydz+RweLBI4+5kuEkWxwfc1JesbjpFNZoEJFv8oCqaRZ3RdU4KQr 6v6+Ku5O9NWp325tXcZ7aW1DQ7BhoVnYAHMl0aLLWvNF95I2yAHaWJAJJ09DooBd 43kLxqcITLuuMg3fIzSeqQs8SEWl5/p3Km64iuAhg4px8+A9Zy//I3mwCI7Qhui8 ZNTrC3cDVBE0Jy5o5QNH1YYEVq65jVvpsm95RhS0PAtN7XsSjRDnvbdinyhdV2oD vtEHivK9B66KcKAxe+c9vluaQB3VImzX2Ji5ceLipGwesHOs6Qj8uaXcYZvopRPz ffbeFFYWDLWJvBZmG/9C1AvPGKEThli8gtsO1JGcFwnv0Wnf1ClBSy8W3qcUtugh pKtBvrUG1aUKogwNZOeg7hdv0nS5joNHRjQT7apD+z1zA0u/uZ8FHn1j/XkQxyXv ArP/jEWsxMRNIaxmZJsVViEFnQNsNoJq7+Z9LBee86cl+IpwNik= =Hdb1 -----END PGP SIGNATURE----- --nextPart2367739.nNEjSNJblS--

1 0

Re: (ITS#8724) slapo-pcache truncates remote results
by quanah＠symas.com 07 Sep '17

07 Sep '17

--On Wednesday, September 06, 2017 7:06 PM -0500 Adam Heath <adam(a)brainfood.com> wrote: > Well, then since you are confirming the bug, I would say this ticket > should *not* be closed. I already reopened it. ;) > I might just have to patch this to make it work. Make sure you follow the contribution guidelines: <https://www.openldap.org/devel/contributing.html> Thanks, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8724) slapo-pcache truncates remote results
by adam＠brainfood.com 07 Sep '17

07 Sep '17

I just cloned the source, and found where it removes the paging control. == /* NOTE: this is a quick workaround to let pcache minimally interact * with pagedResults. A more articulated solutions would be to * perform the remote query without control and cache all results, * performing the pagedResults search only within the client * and the proxy. This requires pcache to understand pagedResults. */ static int pcache_chk_controls( Operation *op, SlapReply *rs ) == Well, then since you are confirming the bug, I would say this ticket should *not* be closed. I might just have to patch this to make it work. The client software I'm actually working with is nextcloud, and it is *very* *very* *very* ldap chatty. And with 2900+ objectclass=group, and 3300 objectclass=person, it runs super dog slow. Their suggestion is to install a local ldap instance configured as a caching proxy, which has led us to here. I've already fixed several issues in nextcloud locally(the first one I ran into was $limit=400 hard-coded in the group search function). This kind of paged result handling needs to be dealt the same way an http proxy would deal with partial content caches. On Wed, Sep 6, 2017 at 4:22 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: > Hi Adam, > > I would note that pcache is not back-ldap, so their behavior is not the > same. > > slapo-pcache strips out the paged results control, and has since 2005 > (ec532ce88590c5454025cbc030d9df65d2df634f). So in the 12 years since then, > you're the first to have an issue with the behavior. If you'd like to see a > change in relation to this, patches welcome. > > --Quanah > > > -- > > Quanah Gibson-Mount > Product Architect > Symas Corporation > Packaged, certified, and supported LDAP solutions powered by OpenLDAP: > <http://www.symas.com> >

1 0

Re: (ITS#8724) slapo-pcache truncates remote results (fwd)
by quanah＠symas.com 06 Sep '17

06 Sep '17

Hi Adam, I would note that pcache is not back-ldap, so their behavior is not the same. slapo-pcache strips out the paged results control, and has since 2005 (ec532ce88590c5454025cbc030d9df65d2df634f). So in the 12 years since then, you're the first to have an issue with the behavior. If you'd like to see a change in relation to this, patches welcome. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com> -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: (ITS#8717) Connection delete callback registreed with LDAP_OPT_CONNECT_CB is not called on TLS failure
by hyc＠symas.com 06 Sep '17

06 Sep '17

ipuleston(a)SonicWALL.com wrote: > I have uploaded the patch to ftp.openldap.org/incoming as ian-puleston-1708= > 25.patch, and included it below. > > The code that it adds is pretty much copied from ldap_free_connection: Thanks for the report, added in master. -- -- 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#8719) slapd_crypt() become slow when many ldap cliant connections occur.
by hyc＠symas.com 06 Sep '17

06 Sep '17

yos-nishino(a)ys.jp.nec.com wrote: > Dear Howard-san, > >> That comment only applies when using LDAP_MEMORY_DEBUG and is irrelevant. > > I saw memory.c again.=20 > As you told, I confirmed the comment was available only when LDAP_MEMORY_DE= > BUG was used(from line 27 to line 119). > > I am sorry to bother you, and I am grateful for your help. > I am going to use "case2" patch, which I expect slapd_crypt() becomes much = > faster. Thanks for the patch, now in git master. -- -- 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#8724) slapo-pcache truncates remote results
by adam＠brainfood.com 06 Sep '17

06 Sep '17

I'll say it another way. ldapsearch is asking for 200 items at a time. But it gets 2000 from the local slapd, when pcache is enabled. What the local client is asking of slapd should be separate from how it talks to the back-ldap. If the back-ldap returns more results then the requested page size, then slapd should handle that. On Wed, Sep 6, 2017 at 12:59 PM, Adam Heath <adam(a)brainfood.com> wrote: > No, it's a pcache bug. > > 10.10.55.128(remote active directory) works > localhost(without pcache) works > localhost(with pcache) breaks. > > Paging of the results *does* work with AD. And works with back-ldap, > pointed at AD. It's only when pcache is added that the paging options > are ignored. > > On Wed, Sep 6, 2017 at 12:48 PM, Quanah Gibson-Mount <quanah(a)symas.com> wrote: >> --On Wednesday, September 06, 2017 6:15 PM +0000 adam(a)brainfood.com wrote: >> >>> Full_Name: Adam Heath >>> Version: 2.4.44 >>> OS: debian stretch >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (99.146.168.62) >>> >>> >>> I have configured slapd to proxy to a remote server. >>> >>> Using ldapsearch, I can talk directly to that remote server, and using the >>> pr=200/noprompt option, I get back 2900 results. >>> >>> Pointing ldapsearch at localhost, *without* pcache, I get the same set of >>> results(pages, and the final count is correct). >>> >>> When I enabled slapo-pcache, with *no* attribute sets, then the paging >>> options are removed, and I get only 2000 results(the max-size from the >>> remote server). >> >> >> Hi Adam, >> >> slapo-pcahce is acting in the correct fashion. It would appear that your >> remote system is Active Directory, which in typical Microsoft fashion, >> deliberately mis-implements paged results so that it incorrectly ignores the >> maxsize setting when paged results are in use (contrary to specifications). >> I would generally suggest talking to the AD administrator so that the bind >> identity of the pcache database is not subject to the maxsize limitation. >> >> This ITS will be closed. >> >> Regards, >> Quanah >> >> >> -- >> >> Quanah Gibson-Mount >> Product Architect >> Symas Corporation >> Packaged, certified, and supported LDAP solutions powered by OpenLDAP: >> <http://www.symas.com> >>

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs