- openldap-bugs - openldap.org

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

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs