openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#6600) pcache overlay should ignore invalid attributes in search requests
by masarati＠aero.polimi.it 26 Jul '10

26 Jul '10

> Full_Name: Jonathan CLARKE > Version: RE24 > OS: > URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-pcache-100723.patch > Submission from: (NULL) (80.13.86.63) > > > While checking it's configuration, the pcache overlay verifies each > configured > attribute set (pcacheAttrset), to ensure that all attributes in the set > are > defined, via slap_str2ad. Given an attribute set with a non-existant > attribute, > an error is logged and slapd refuses to start (as expected): > > line 117 (pcacheAttrset 0 nonexistantAttr) > /etc/ldap/slapd.conf: line 117: attribute type undefined. > > However, when a search request comes in, the requested attributes list is > not > checked by the pcache overlay to ensure that attributes are properly > defined. In > effect, slapd just ignores the non-existant attributes, and returns other > attributes (or behaves as if 1.1 was requested if all requested attributes > are > invalid). > > This causes pcache's attribute set matching to fail for some requests, > since it > counts invalid attributes. If it were to ignore them, configured attribute > sets > might match, and successfully cache the search. The patch above implements > this > behaviour. Would you consider it for inclusion in OpenLDAP? > > I realize this may be considered "repairing bad requests", but sometimes > one > can't (easily) control what clients are requesting. Furthermore, it seems > to > make sense to have matching behavior all over (since slapd ignores invalid > requested attributes, pcache should too, IMHO). Yours looks like a good catch; however, your patch looks a bit like an overkill, since the an_desc field of the attribute list that is passed to get_attr_set() should already be set if the attribute was recognized by slapd, so you don't need to go through slap_bv2ad() once more. p.

1 0

(ITS#6602) ldap_chase_v3referrals() modifies ld_nextref_proc
by masarati＠aero.polimi.it 26 Jul '10

26 Jul '10

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.243) Submitted by: ando A fix is coming.

1 0

(ITS#6601) Document ldap_set_urllist_proc()
by masarati＠aero.polimi.it 26 Jul '10

26 Jul '10

Full_Name: Pierangelo Masarati Version: irrelevant OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.72.165.243) Submitted by: ando ldap_set_urllist_proc() is not documented; a patch for ldap_open.3 is coming. p.

1 0

Re: (ITS#6599) slapd not responding
by quanah＠zimbra.com 26 Jul '10

26 Jul '10

--On Friday, July 23, 2010 1:13 PM +0000 binoy(a)cordys.com wrote: > Full_Name: Binoy Joseph > Version: 2.4.21 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (210.210.79.19) Can you reproduce this with OpenLDAP 2.4.23? There was a change in locking behavior introduced in 2.4.21 that was backed out in 2.4.23. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6534) bad ifdef/elif clause in liblutil
by h.b.furuseth＠usit.uio.no 26 Jul '10

26 Jul '10

quanah(a)zimbra.com writes: >>> Line 131 is "#elif TIOCNOTTY". There's no 'long' there is TIOCNOTTY is >>> undefined, it'd just evaluate to #elif 0. So my guess is that TIOCNOTTY >>> somewhere is defined to expand to an expression involving a (long) cast. >> >> Apprently so. >> >> <http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg785259. >> html> > > Fixed by debian. Which is nice, but doesn't help with older debian versions. I don't see what's wrong with changing our #elif to #elif defined like you originally suggested, though I remember there was some confused #elif discussion earlier. -- Hallvard

1 0

(ITS#6600) pcache overlay should ignore invalid attributes in search requests
by jonathan＠phillipoux.net 23 Jul '10

23 Jul '10

Full_Name: Jonathan CLARKE Version: RE24 OS: URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-pcache-100723.patch Submission from: (NULL) (80.13.86.63) While checking it's configuration, the pcache overlay verifies each configured attribute set (pcacheAttrset), to ensure that all attributes in the set are defined, via slap_str2ad. Given an attribute set with a non-existant attribute, an error is logged and slapd refuses to start (as expected): line 117 (pcacheAttrset 0 nonexistantAttr) /etc/ldap/slapd.conf: line 117: attribute type undefined. However, when a search request comes in, the requested attributes list is not checked by the pcache overlay to ensure that attributes are properly defined. In effect, slapd just ignores the non-existant attributes, and returns other attributes (or behaves as if 1.1 was requested if all requested attributes are invalid). This causes pcache's attribute set matching to fail for some requests, since it counts invalid attributes. If it were to ignore them, configured attribute sets might match, and successfully cache the search. The patch above implements this behaviour. Would you consider it for inclusion in OpenLDAP? I realize this may be considered "repairing bad requests", but sometimes one can't (easily) control what clients are requesting. Furthermore, it seems to make sense to have matching behavior all over (since slapd ignores invalid requested attributes, pcache should too, IMHO).

1 0

(ITS#6599) slapd not responding
by binoy＠cordys.com 23 Jul '10

23 Jul '10

Full_Name: Binoy Joseph Version: 2.4.21 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (210.210.79.19) I run OpenLDAP 2.4.21 configured to bdb on Windows and Linux. We run some applications on top of our application framework which in turn is connected to OpenLDAP via JLDAP. We list children of 'cn=soap nodes' (search LDAP) very often as shown in the DIT below. I wrote a test case to create soapnode, soapproc, connectionpoint and then delete them one after the other, ie I create set1, delete set1, create set2, delete set2... Note that list children of 'cn=soap nodes' happen in parallel as mentioned above. Randomly but very consistently, suddenly we face an LDAP not responding issue. When I connect via an LDAP Explorer, I am able to see and expand most of the LDAP entries, except the 'cn=soap nodes' as shown in the DIT below, which says LDAP query did not return indefinitely. CPU: slapd shoots to 50% in Windows and 100% in Linux. Then I have to kill slapd and start again. This does not happen in OpenLDAP 2.4.16. After upgrading to 2.4.21 this started happening. When I switched to hdb, this does not occur in Linux, but continues to happen in Windows. This also looks very similar to http://www.openldap.org/its/index.cgi?findid=6322, Subject: slapd suddenly stops working, and starts using 100% CPU. o=org1 | +-cn=soap nodes | +-cn=soapnode1 | | | +cn=soapproc1 | | | +cn=connectionpoint1 | +-cn=soapnode2 . . Thanks and regards, Binoy Joseph

1 0

Re: (ITS#6489) Incomplete Master/Slave Replication
by frank.offermanns＠caseris.de 23 Jul '10

23 Jul '10

Hello Quanah, thanks for your info. I compiled OpenLDAP 2.4.23 and BDB 4.8.30, but unfortunately the problem still persists. I added 10000 Users added and: with RefreshAndPersist in 136 users at least one attribute was missing. with RefreshOnly in 34 users at least one attribute was missing. In my post in March I said, that with accesslog I do not have this problem. This is not completely true. Meanwhile (also with 2.4.21) I found out that with accesslog I also have this problem, but less frequentely. So with about 40000 users added I had only about 1 or 2 attributes missing. With the new version I added 10000, 20000 and 80000 users without a single problem. So I am not sure, if this problem still persist with accesslog, but with RefreshAndPersist and RefreshOnly there is definitely still a problem. Due to the fact that no one else complains about this, maybe this problem is Windows only? Or is there someone else who also has this problem? If you are interested I could provide you my windows test-application. With this the problem can be reproduced in a few minutes. Let me know if I should send you this program. Thanks a lot so far. Best regards, Frank Offermanns > > > Full_Name: Frank Offermanns > > Version: 2.4.21 > > OS: Windwos > > URL: ftp://ftp.openldap.org/incoming/ > > Submission from: (NULL) (217.6.189.242) > > > > > > I am running LDAP from Head with BDB 4.8.26 as backend on windows. I am > > testing master/slave replication while adding 10000 users with 10 filled > > attributes. I am not using a specific time synchronization. Standard > > windows time synchronization in domains is active. But as far as I > > understood, a microsecond time synchronisation is only needed for > > master-master, which I am not testing. > > BDB 4.8.26 is known problematic. Please use BDB 4.8.30, and OpenLDAP > 2.4.23, and report back if you still have issues. > > Thanks! > > --Quanah > > -- > > Quanah Gibson-Mount > Principal Software Engineer > Zimbra, Inc > -------------------- > Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6489) Incomplete Master/Slave Replication
by quanah＠zimbra.com 22 Jul '10

22 Jul '10

--On Tuesday, March 09, 2010 12:23 PM +0000 Frank.Offermanns(a)caseris.de wrote: > Full_Name: Frank Offermanns > Version: 2.4.21 > OS: Windwos > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (217.6.189.242) > > > I am running LDAP from Head with BDB 4.8.26 as backend on windows. I am > testing master/slave replication while adding 10000 users with 10 filled > attributes. I am not using a specific time synchronization. Standard > windows time synchronization in domains is active. But as far as I > understood, a microsecond time synchronisation is only needed for > master-master, which I am not testing. BDB 4.8.26 is known problematic. Please use BDB 4.8.30, and OpenLDAP 2.4.23, and report back if you still have issues. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6476) Failure to delete entry with multi-master replication
by quanah＠zimbra.com 22 Jul '10

22 Jul '10

--On Wednesday, February 17, 2010 1:05 PM +0000 worganc(a)avaya.com wrote: > Full_Name: Craig Worgan > Version: 2.4.21 > OS: RedHat Enterprise Linux 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (47.11.182.86) Hi Craig, Are you able to reproduce this with OpenLDAP 2.4.23? There have been some fixes around deletes since 2.4.21, and an issue that was introduced in 2.4.21 specific to cached objects as well. Thanks, Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

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