openldap-bugs April 2019

openldap-bugs@openldap.org

16 participants
64 discussions

Re: (ITS#8996) Please supply a pkg-config file for libldap
by hugh.mcmaster＠outlook.com 05 Apr '19

05 Apr '19

In reference to #8996, I have prepared a patchset that adds support for generating pkg-config files at configure-time. There are three patches, one each for libldap, libldap_r and liblber. The attached patch files are derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Hugh McMaster <hugh.mcmaster at outlook.com>. I have not assigned rights and/or interest in this work to any party. I, Hugh McMaster, 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. ftp://ftp.openldap.org/incoming/hugh-mcmaster-190405.patch ftp://ftp.openldap.org/incoming/hugh-mcmaster-190405-02.patch ftp://ftp.openldap.org/incoming/hugh-mcmaster-190405-03.patch Please review the above patches and let me know if you require any changes. Thank you Hugh

1 0

Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by hyc＠symas.com 04 Apr '19

04 Apr '19

henrik.bohnenkamp(a)ionos.com wrote: > On Fri, Jan 25, 2019 at 06:31:41AM -0800, Quanah Gibson-Mount wrote: >> --On Friday, January 25, 2019 1:51 PM +0000 hbohnenkamp(a)united-internet.de >> wrote: >> Hi, thanks for the report and investigation. I've briefly reviewed your patches. Please squash your #3 into #2, there's no reason to preserve that. We don't use "inline" in this code. If the compiler is smart enough it will inline automatically anyway. Please drop that from your patch. No need to keep the old mdb_idscope invocation commented out in patch #2. Just delete it, we have the git history. In patch #1 delete.c your patch line #145 is incorrect. You should be using is_entry_alias(e) instead of (op->ora_e.) The entry in question is not part of the op request, only its DN is in the Delete request. Not sure why you dropped nsubs from the diskNode definition. Are you sure you haven't broken the nsubs processing in this patch? > > Hi, > > I have now done quite a lot of testing in the way described in my > email from January (Followup 3). I used version 2.4.47, not the HEAD > of the openldap git master branch. > > I have found one bug, the one mentioned already in the same email. I > have added a fix for that bug to the patch directory in > https://github.com/hbo/openldap-mdb-deref-problem > > I have come across the regression with the back-hdb backend again, > which I also described in my previous email already. I am now > convinced that this regression is really a problem with the back-hdb > implementation, and I can show it without using my patched > implementation of back-mdb. The demonstration requires a bit more work > to be really presentable and should in any case go into a different > bug report. > > Apart from these two issues I have not seen any regressions, and I am > now quite confident that my patch would work reliable in the > environment of my company... no guarantees for anything else :-) > > I have seen that Quanah has suggested to look at ITS#8875 for the > 2.4.48 release. Whether there will be a fix in 2.4.48 and whether it > will be based on my patch is of course up to the lead developers (the > change in the DB schema is certainly a strong point against), but this > patch can perhaps serve as something to test the actual fix against. > > Best regards > Henrik > > > -- > Henrik Bohnenkamp > > > > -- -- 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

(ITS#9003) Update slapd-ldap(5) idassert-authzfrom for policy difference
by quanah＠openldap.org 04 Apr '19

04 Apr '19

Full_Name: Quanah Gibson-Mount Version: 2.4.47 OS: N/A URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (47.208.144.40) The slapd-ldap(5) man page has the following statement: idassert-authzFrom <authz-regexp> if defined, selects what local identities are authorized to exploit the identity assertion feature. The string <authz- regexp> follows the rules defined for the authzFrom attribute. See slapd.conf(5), section related to authz-policy, for details on the syntax of this field. However, it deviates from the rules laid out in the authz-policy section in that the special case of "*" has a different meaning for slapd-ldap/slapd-meta. In their case, this *allows* anonymous, while in the authz-policy case, anonymous is denied. This exception to the normal behavior needs to be noted.

1 0

Re: (ITS#8875) [Patch] Performance problems in back-mdb with large DITs and many aliases
by henrik.bohnenkamp＠ionos.com 02 Apr '19

02 Apr '19

On Fri, Jan 25, 2019 at 06:31:41AM -0800, Quanah Gibson-Mount wrote: > --On Friday, January 25, 2019 1:51 PM +0000 hbohnenkamp(a)united-internet.de > wrote: > Hi, I have now done quite a lot of testing in the way described in my email from January (Followup 3). I used version 2.4.47, not the HEAD of the openldap git master branch. I have found one bug, the one mentioned already in the same email. I have added a fix for that bug to the patch directory in https://github.com/hbo/openldap-mdb-deref-problem I have come across the regression with the back-hdb backend again, which I also described in my previous email already. I am now convinced that this regression is really a problem with the back-hdb implementation, and I can show it without using my patched implementation of back-mdb. The demonstration requires a bit more work to be really presentable and should in any case go into a different bug report. Apart from these two issues I have not seen any regressions, and I am now quite confident that my patch would work reliable in the environment of my company... no guarantees for anything else :-) I have seen that Quanah has suggested to look at ITS#8875 for the 2.4.48 release. Whether there will be a fix in 2.4.48 and whether it will be based on my patch is of course up to the lead developers (the change in the DB schema is certainly a strong point against), but this patch can perhaps serve as something to test the actual fix against. Best regards Henrik -- Henrik Bohnenkamp

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs April 2019