openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#7996) Tighten race in ldap_int_initialize
by quanah＠symas.com 16 Jun '19

16 Jun '19

--On Sunday, June 16, 2019 4:06 PM +0200 Armin T=C3=BCting=20 <Armin.Tueting(a)tueting-online.com> wrote: > Hello Quanah, > > I'm following OPENLDAP_REL_ENG_2_4. The commit > 'cde56fad154fcd25e351c3cd84d8173d263b0a01' breaks starting slapd. It > won't start at all... > > I'm using a fairly up-to-date CentOS 7 version... > 3.10.0-957.21.2.el7.x86_64 #1 SMP Wed Jun 5 14:26:44 UTC 2019 x86_64 Hi, Thanks for the report. When reporting issues, please keep them on the=20 OpenLDAP bug tracking list, rather than directly emailing individuals. I'm unable to reproduce this with Ubuntu18 (all tests in the test suite=20 pass via make test, and I can start slapd just fine w/o debug mode). I'll=20 test on centos7 and see if I can reproduce. --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#9035) LDMB: 0.9.23: mdb_env_set_maxreaders() not honoured?
by steffen＠sdaoden.eu 14 Jun '19

14 Jun '19

Howard Chu wrote in <c68dedc0-e022-509b-da5a-e9300d71e39e(a)symas.com>: |steffen(a)sdaoden.eu wrote: |> Full_Name: Steffen Nurpmeso |> Version: 0.9.23 |> OS: Linux |> URL: https://ftp.sdaoden.eu/lmdb-bogo.tar.xz |> Submission from: (NULL) (109.40.130.211) |> |> |> A follow-up to private communication with Quanah Gibson-Mount. |> You can find more in the tarball linked below | |The maxreaders setting doesn't persist after all processes have closed \ |the environment. |Therefore it returns to its default value when the next process opens \ |the environment. | |The code works as designed. There is no bug here. Closing this ITS. Ok. But please let me wonder why it is part of a DB dump, then, if it has nothing to do with the persistent state of a DB, but rather with the coding environment that is recreated each time from scratch. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

1 0

Re: (ITS#9036) LDMB: 0.9.23: mdb_env_info() does not report latest mapsize() after transaction abort
by steffen＠sdaoden.eu 14 Jun '19

14 Jun '19

Howard Chu wrote in <b0311a63-3757-5b69-676a-bd8293e34c1e(a)symas.com>: |steffen(a)sdaoden.eu wrote: |> Full_Name: Steffen Nurpmeso |> Version: 0.9.23 |> OS: Linux |> URL: https://ftp.sdaoden.eu/lmdb-bogo.tar.xz |> Submission from: (NULL) (109.40.130.211) |> |> |> A follow-up to private communication with Quanah Gibson-Mount. |> You can find more in the tarball linked below |> |> |Your README states that the behavior in LMDB 0.9.23 is different than \ |in 0.9.22 but that |is incorrect. No changes to set_mapsize() behavior were made between \ |0.9.22 and 0.9.23. Yeah!! Mind you, i have even looked into the git history once AlpineLinux switched to 0.9.23 and i came to the very same conclusion! But one thing is plain: on AlpineLinux, with musl libc, from July 2018 to January 2019, i ran bogofilter with LMDB 0.9.22 exactly as it is still in bogofilter upstream and on the one branch in the ball i provided under the URL above. Doing monthly dump + rebuild of my spam database to vacuumize the thing. Without any problems. Then after my weekly system upgrade, which (also?) came with LMDB 0.9.23 i suddenly saw crashes, on a Saturday night! You can read the two mails [1,2] if you wanna. [1] https://www.bogofilter.org/pipermail/bogofilter-dev/2019q1/003515.html [2] https://www.bogofilter.org/pipermail/bogofilter-dev/2019q1/003516.html |Closing this ITS. Well ok, if it is so designed that set_mapsize() is not meant to survive a transaction abort, then it may be so. But then it should possibly be documented that after a transaction abort all environmental settings need to be reestablished, as they vanish after an abortion. I.e., that they only become persistent after a successful commit. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

1 0

Re: (ITS#9034) LDMB: 0.9.22/3: initial mdb_env_set_mapsize() is problematic
by steffen＠sdaoden.eu 14 Jun '19

14 Jun '19

Howard Chu wrote in <1c3b8393-3524-311e-0287-d87ef7e2de37(a)symas.com>: |steffen(a)sdaoden.eu wrote: |> Full_Name: Steffen Nurpmeso |> Version: 0.9.23 |> OS: Linux |> URL: https://ftp.sdaoden.eu/lmdb-bogo.tar.xz |> Submission from: (NULL) (109.40.130.211) |> |> |> A follow-up to private communication with Quanah Gibson-Mount. |> You can find more in the tarball linked below. | |The code works as designed. No changes to mapsize handling were made \ |between 0.9.22 and 0.9.23. |Closing this ITS. It did not work with 0.9.22 already. Sorry for the messy README, if you have not read it in its entirety, the long story possibly was too long. But if an initial set_mapsize() causes crashes further on, then this is a design i do not understand. I mean, i have found workarounds (leaving off code) which work stable since one year in two weeks from now, on musl as well as GNU C libraries, and Matthias Andree tested on FreeBSD and Solaris, if i recall correctly, and so it is ok for me. That is all i know. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)

1 0

Re: (ITS#8671) Declare ldap_init_fd() in ldap.h to help external consumers
by abokovoy＠redhat.com 14 Jun '19

14 Jun '19

On pe, 14 kesä 2019, Ondřej Kuzník wrote: >On Thu, Oct 19, 2017 at 03:39:24PM +0000, quanah(a)symas.com wrote: >> --On Thursday, October 19, 2017 10:20 AM +0300 Alexander Bokovoy >> <abokovoy(a)redhat.com> wrote: >>> Hi Quanah, >>> >>> On ti, 12 syys 2017, Quanah Gibson-Mount wrote: >>>> 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. >>> Attached is a re-based patch set since there were changes in git master >>> in last month or so that affected the same area. >>> >>> There are two patches: one for git master, one for 2.4 branch. Since >>> there is no functional change in the code, I'd like to see the 2.4 >>> version in an upcoming release as that would greatly help Samba. >>> >>> I'm also including an IPR notice below: >>> >>> Red Hat, Inc. 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. >> >> Thanks very much! I'll get this into my scratch repo for review. > >Hi Alexander, >as of commit 6a5e30674b63b17587738ba9a3d1ea3633c33fb1, OpenLDAP master >now ships and installs a new header <openldap.h> that should expose >ldap_init_fd(). Could you check this will work for Samba before we apply >this change in 2.4? Thanks. I've compiled openldap git master and installed it, I can see $prefix/include/openldap.h with ldap_init_fd() and man pages have proper references to openldap.h. Looks good to me. Once 2.4 becomes available, we can add support of this to Samba. -- / Alexander Bokovoy Sr. Principal Software Engineer Security / Identity Management Engineering Red Hat Limited, Finland

1 0

Re: (ITS#8671) Declare ldap_init_fd() in ldap.h to help external consumers
by ondra＠mistotebe.net 14 Jun '19

14 Jun '19

On Thu, Oct 19, 2017 at 03:39:24PM +0000, quanah(a)symas.com wrote: > --On Thursday, October 19, 2017 10:20 AM +0300 Alexander Bokovoy > <abokovoy(a)redhat.com> wrote: >> Hi Quanah, >> >> On ti, 12 syys 2017, Quanah Gibson-Mount wrote: >>> 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. >> Attached is a re-based patch set since there were changes in git master >> in last month or so that affected the same area. >> >> There are two patches: one for git master, one for 2.4 branch. Since >> there is no functional change in the code, I'd like to see the 2.4 >> version in an upcoming release as that would greatly help Samba. >> >> I'm also including an IPR notice below: >> >> Red Hat, Inc. 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. > > Thanks very much! I'll get this into my scratch repo for review. Hi Alexander, as of commit 6a5e30674b63b17587738ba9a3d1ea3633c33fb1, OpenLDAP master now ships and installs a new header <openldap.h> that should expose ldap_init_fd(). Could you check this will work for Samba before we apply this change in 2.4? Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#9020) Inconsistent cn=config objectClasses for overlays
by ondra＠mistotebe.net 14 Jun '19

14 Jun '19

On Thu, May 09, 2019 at 04:21:56PM +0000, quanah(a)openldap.org wrote: > The majority of supported overlays use an objectClass of the format: > > olcOVERLAYConfig > > However, there are two overlays that do *not* follow this format, which is > confusing. > > memberOf -> olcMemberOf > dynlist -> olcDynamicList > > For 2.5, I would suggest we change these to be consistent with all the other > overlays and document this change in the Admin Guide section on upgrade notes > etc. Maybe we could change the name in 2.4 with the proposed names as the primary keeping the old one as an alternative? Don't remember if slapcat would translate them accordingly. If it does, we could just drop the old name in 2.5 (and have everyone slapcat cn=config with OpenLDAP >= 2.4.48 or wherever this lands). Or just do the above in 2.5 only. -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8754) ldpasearch IPv5 only
by ondra＠mistotebe.net 14 Jun '19

14 Jun '19

On Wed, Oct 11, 2017 at 12:24:56PM +0000, dpa-openldap(a)aegee.org wrote: > After `./configure --disable-ipv6` I expect, that `ldapsearch` will not contact > severs over IPv6, which is achieved with the fix below. Hi, thank you for your work, the patch has been pushed to master (5e8aa3f6d111160cbb3ce3a49af7323258e702b5) and will also be part (c4f55cea87880ca8c14b559bd77bcea19ad615cd) of the upcoming 2.4.48 release. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8427) Incorrect value of tls_reqcert in syncrepl
by ondra＠mistotebe.net 14 Jun '19

14 Jun '19

On Fri, Dec 01, 2017 at 07:15:08PM +0000, mkp37215(a)gmail.com wrote: > I, Maciej Puzio, hereby place the above 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. Hi Maciej, thank you for your work, patches have been pushed to master and will also be part of the upcoming 2.4.48 release. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Re: (ITS#8674) Leak in ldap_create_assertion_control
by ondra＠mistotebe.net 14 Jun '19

14 Jun '19

On Thu, Sep 07, 2017 at 03:42:50PM +0000, come(a)opensides.be wrote: > 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. Hi Côme, thank you for your work, your patch has been pushed to master (2cac3ceb03530e3afe741d4a7d4d7e21059a6a97) and will also be part (8e6d1b8b81e94f89027a120ea862bd5938e953c6) of the upcoming 2.4.48 release. Thanks, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs