openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(ITS#6397) accesslog + syncprov crash
by h.b.furuseth＠usit.uio.no 23 Nov '09

23 Nov '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: Linux URL: ftp://ftp.openldap.org/incoming/Hallvard-Furuseth-091123.tgz Submission from: (NULL) (129.240.6.233) Submitted by: hallvard slapd dumps core in test043-delta-syncrepl with this patch to excite accesslog. While I didn't expect good behavior with that change, I didn't expect a coredump either. --- tests/data/slapd-deltasync-master.conf~ 2009-04-06 17:26:37 +0200 +++ tests/data/slapd-deltasync-master.conf 2009-11-23 15:09:56 +0100 @@ -40,4 +40,5 @@ directory @TESTDIR@/db.1.b rootdn "cn=Manager,dc=example,dc=com" +index reqStart eq #bdb#index objectClass eq #bdb#index entryUUID,entryCSN eq @@ -78,4 +79,5 @@ logops writes logsuccess true +logpurge 00:00:05 00:00:03 #monitor#database monitor Happens ca every 2nd test043 run with RE24 --enable-accesslog. Output with backtrace and testrun/ attached.

1 0

(ITS#6396) slow reads on slaves after many changes in master
by rolnas＠gmail.com 23 Nov '09

23 Nov '09

Full_Name: Rolandas Naujikas Version: 2.4.19 OS: FreeBSD 7.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (217.147.36.211) We have a setup of 3 slapd: 2 of them running in mirror mode and last one as a read-only slave. All entries could fit in the cache (my goal is good read performance). Usually when master receive only small changes (modify + several adds) - read performance is OK. When I do ~5% content change (doing a lot of deletes and adds in short period), then read performance drops sharply - on master not so much (2x), on slaves 10-20x. In the same time CPU load on slaves when doing read is becoming high (almost 100%), on master - normal. It rests in such situation until I restart slave instances, after that all such performance problems disappears. By comparison version 2.4.16 didn't show such behavior and for some time (until 2.4.19 was not declared stable) we used this older version.

1 0

Re: (ITS#6390) test020 seg faults
by rhafer＠suse.de 23 Nov '09

23 Nov '09

Am Freitag 20 November 2009 19:45:53 schrieb quanah(a)zimbra.com: > --On Friday, November 20, 2009 3:53 PM +0000 quanah(a)zimbra.com wrote: > > --On Friday, November 20, 2009 12:35 PM +0000 rhafer(a)suse.de wrote: > >> Hm, I get the following warning during the make run: > >> > >> =2E./../../servers/slapd/syncrepl.c:2861 is: > >> comma =3D ber_bvrchr( &ptr, ',' ); > >> with ber_bvrchr being a macro around memrchr(). So it seems that > >> memrchr() = is=20 > >> undefined in syncrepl.c. > > > > Please don't add secondary issues to an ITS. File a new one. > > Unless you're saying that is the issue, which isn't clear to me in what you > wrote. :P I thought sending my mails against this ITS would be sufficient to show that I am talking about this issue :). I'll try to make that a bit more obvious next time. -- regards, Ralf

1 0

(ITS#6395) Web site release readme needs BDB version compatibility update
by battery＠writeme.com 23 Nov '09

23 Nov '09

Full_Name: Matt Kassawara Version: 2.4.18 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (24.56.179.224) The release readme posted on the OpenLDAP web site doesn't explicitly indicate compatibility with BDB 4.8. http://www.openldap.org/software/release/readme.html

1 0

Re: (ITS#6300) Add kqueue support to slapd
by hyc＠symas.com 23 Nov '09

23 Nov '09

bduncan(a)apple.com wrote: > On Sep 22, 2009, at 1:02 PM, Quanah Gibson-Mount wrote: > >> --On Tuesday, September 22, 2009 7:23 PM +0000 bduncan(a)apple.com >> wrote: >> >>> Subject should have been: "PATCH - Added kqueue support to slapd" to >>> make clear this ITS tracks a patch that has been submitted. >> >> What OS(es) has this kqueue support been tested with? For example, >> the last time I looked at kqueue on OSX 10.5, it was very marginal, >> and missing most of the important pieces, which meant it wouldn't >> work for OpenLDAP or Postfix, etc. > > It was tested on OS X 10.6. Should work on all BSDs; nothing OSX- > specific about the kqueue usage in the patch. As far as kqueue > support in OS X 10.5, from what I see, most everything is there. > Certainly all of the kqueue features in this patch are supported in OS > X 10.5. To expand on this: there are a lot of comments around the web that kqueue was fairly broken at least up to 10.5. E.g. this: http://lists.schmorp.de/pipermail/libev/2008q4/000523.html Since we also use a pipe for the wake_sds[] in our event loop, if kqueue only supports sockets, then it cannot be used reliably in slapd. -- -- 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#6392) olcAuthIDRewrite handler exited with 1
by masarati＠aero.polimi.it 22 Nov '09

22 Nov '09

> Yeah, I noticed that hyc had patched it differently. There is > definitely a steep learning curve when it comes to helping out with > anything. > I see hyc's patch committed in the latest RE24. I have tested it with > HEAD and the error message seems to be gone. > I can't seem to get olcAuthIDRewrite to work -- but that's probably not > an ITS problem. =) Probably, yes. authzid-rewrite is used much like authz-regexp, only with a slightly different syntax. Actually, when rewriting is available, authz-regexp is handled by authzid-rewrite, using a subset of its syntax (and thus of its semantics). So its use applies when authz-regexp is appropriate. See slapd.conf(5) for usage of authz-regexp. p.

1 0

Re: (ITS#6391) missing check for broken filters
by h.b.furuseth＠usit.uio.no 22 Nov '09

22 Nov '09

masarati(a)aero.polimi.it writes: > Are you going to fix this? Probably not. -- Hallvard

1 0

Re: (ITS#6391) missing check for broken filters
by masarati＠aero.polimi.it 22 Nov '09

22 Nov '09

> syncrepl.c and overlays/pcache.c call str2filter() and str2filter_x() > without checking for success. > > (so does retcode, but that overlay is only for testing anyway.) Are you going to fix this? I can take care of it later, in case. p.

1 0

Re: (ITS#6394) syncrepl accepts rid>999 then assumes rid<=999
by hyc＠symas.com 22 Nov '09

22 Nov '09

h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth > Version: HEAD, RE24 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > syncrepl accepts rid values in range [0, SLAP_SYNC_SID_MAX(4095)], but > proceeds to assume the rid is in range [0, SLAP_SYNC_RID_MAX (999)]. > This can produce buffer overruns for such rids. > > slapd.conf(5) says max rid = 4095, since ITS#5108. > > Possible fixes: either to revert to a limit of 999, or expand to 4 > digits to support the documented behavior, or to make them hex to keep > the documented limit but still max 3 digits. I've opted to revert to 999. The previous behavior was completely broken anyway; aside from the syncrepl config parser all of the rest of the infrastructure was still treating rids as 3 decimal digits: the config unparser, slapd-config(5), slap_compose_sync_cookie, slap_parse_sync_cookie, etc. etc... All of these would have had to change to hex to make the 4095 limit work, and they weren't. Also, for backward compatibility with 2.3, they can't. -- -- 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#6394) syncrepl accepts rid>999 then assumes rid<=999
by h.b.furuseth＠usit.uio.no 21 Nov '09

21 Nov '09

Full_Name: Hallvard B Furuseth Version: HEAD, RE24 OS: URL: Submission from: (NULL) (129.240.6.233) Submitted by: hallvard syncrepl accepts rid values in range [0, SLAP_SYNC_SID_MAX(4095)], but proceeds to assume the rid is in range [0, SLAP_SYNC_RID_MAX (999)]. This can produce buffer overruns for such rids. slapd.conf(5) says max rid = 4095, since ITS#5108. Possible fixes: either to revert to a limit of 999, or expand to 4 digits to support the documented behavior, or to make them hex to keep the documented limit but still max 3 digits.

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