openldap-bugs

openldap-bugs@openldap.org

1 participants
20895 discussions

Re: (ITS#4728) accesslog dont write attributes removing
by hyc＠symas.com 31 Oct '06

31 Oct '06

surnu(a)alkohol.ee wrote: > Full_Name: Andres Kahk > Version: 2.3.28 > OS: Gentoo Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.80.105.102) > > > if i change attribute, everythings are fine i got: > reqMod: > autoReply:= FALSE > entryCSN:= 20061031104835Z#000000#00#000000 > modifiersName:= > modifyTimestamp:= 20061031104835Z > > but if i remove attribute from object then i got: > reqMod: > entryCSN:= 20061031104852Z#000000#00#000000 > modifiersName:= > modifyTimestamp:= 20061031104852Z > > There is no entry to remove. That means the entry is removed in write server, > but it still exists in read server > > If you got any info or patch to fix this and get syncrepl work correctly, please > send it :) It works fine here. Does test043 in the test suite succeed or fail for you? It succeeds here, and it also performs modifications that delete an attribute from an entry. You'll have to provide more information, e.g. your slapd configuration would be a good start. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4728) accesslog dont write attributes removing
by surnu＠alkohol.ee 31 Oct '06

31 Oct '06

Full_Name: Andres Kahk Version: 2.3.28 OS: Gentoo Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.80.105.102) if i change attribute, everythings are fine i got: reqMod: autoReply:= FALSE entryCSN:= 20061031104835Z#000000#00#000000 modifiersName:= modifyTimestamp:= 20061031104835Z but if i remove attribute from object then i got: reqMod: entryCSN:= 20061031104852Z#000000#00#000000 modifiersName:= modifyTimestamp:= 20061031104852Z There is no entry to remove. That means the entry is removed in write server, but it still exists in read server If you got any info or patch to fix this and get syncrepl work correctly, please send it :)

1 0

Re: (ITS#4727) back-perl builds with modular back_perl broken
by quanah＠OpenLDAP.org 30 Oct '06

30 Oct '06

This can be closed, the problem was tracked down to a broken build of libltdl in Debian Sarge 64-bit. sigh. --Quanah -- Quanah Gibson-Mount QA Engineer <http://www.openldap.org>

1 0

Re: (ITS#4725) back-perl not calling bind method
by quanah＠stanford.edu 30 Oct '06

30 Oct '06

--On Monday, October 30, 2006 11:09 AM +0000 mike(a)arishi.com wrote: > Full_Name: Mike Woods > Version: 2.3.28 > OS: FreeBSD 6.1 RELEASE 4 > URL: http://geofront.co.uk/GlueTest.pm > Submission from: (NULL) (207.138.125.56) > > > When using back-perl openldap fails to call the bind methog on > connection, i've tried this with the 2.2 branch and 2.3.28 to the same > effect. > > The failure to call bind essentialy renders back-perl useless. > > I've written and attached a basic "test" module so I can see what > openldap is doing. I am unable to reproduce this issue with 2.3.28. How are you testing this? For me: ldapsearch -LLL -x -h ldap-uat00 -b o=anyorg,c=us -D "uid=quanah,o=anyorg,c=us" -w test tribes:~> And the log clearly shows bind being called: Oct 30 18:38:13 ldap-uat00 slapd[24803]: conn=3 fd=8 ACCEPT from IP=171.64.19.55:41385 (IP=0.0.0.0:389) Oct 30 18:38:13 ldap-uat00 slapd[24803]: conn=3 op=0 BIND dn="uid=quanah,o=anyorg,c=us" method=128 Oct 30 18:38:13 ldap-uat00 Glue: Bind --Quanah -- Quanah Gibson-Mount Principal Software Developer ITS/Shared Application Services Stanford University GnuPG Public Key: http://www.stanford.edu/~quanah/pgp.html

1 0

(ITS#4727) back-perl builds with modular back_perl broken
by quanah＠OpenLDAP.org 30 Oct '06

30 Oct '06

Full_Name: Quanah Gibson-Mount Version: 2.3.28 OS: Linux 2.6 (64-bit) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.64.19.81) In working to test other bugs, I found that building slapd static allows you to use back-perl, but building slapd with modular back_perl it fails to resolve symbols. Investigation ongoing. This is with perl 5.8.8. --Quanah

1 0

(ITS#4726) ldap_pvt_tls_init not called when new CTX requested
by covener＠gmail.com 30 Oct '06

30 Oct '06

Full_Name: Eric Covener Version: 2.4.3 OS: ppc linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (129.33.49.251) I'm using 2.4.3 and trying to set SSL client certificates on a per-connection basis. A call to ldap_set_option(ld, LDAP_OPT_X_TLS_NEWCTX, &newctx) fails in my simple test application because ldap_pvt_tls_init hasn't had a chance to call SSLeay_add_ssl_algorithms() yet. I'm not familiar enough w/ openldap to track down how this path occurs, but it seems like the code in tls.c that handles the SSL_CTX_new() in the event of LDAP_OPT_X_TLS_NEWCTX should make sure the initializer has been run by calling ldap_pvt_tls_init() (My simple test app works when I add SSLeay_add_ssl_algorithms() before ldap_set_option). The failure without the call is TLS: could not allocate default ctx (336236705).

1 0

(ITS#4725) back-perl not calling bind method
by mike＠arishi.com 30 Oct '06

30 Oct '06

Full_Name: Mike Woods Version: 2.3.28 OS: FreeBSD 6.1 RELEASE 4 URL: http://geofront.co.uk/GlueTest.pm Submission from: (NULL) (207.138.125.56) When using back-perl openldap fails to call the bind methog on connection, i've tried this with the 2.2 branch and 2.3.28 to the same effect. The failure to call bind essentialy renders back-perl useless. I've written and attached a basic "test" module so I can see what openldap is doing.

1 0

Re: (ITS#4724) Case-insensitive search on unicode strings fail in 2.3.x
by hyc＠symas.com 29 Oct '06

29 Oct '06

katuev(a)dvbank.ru wrote: > Full_Name: Konstantin Katuev > Version: 2.3.28 > OS: Solaris > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (195.137.171.26) > > > When using unicode (russian) strings for DNs & attribute values, all sofwtare > that searches thru LDAP directory returns no results when case of letters does > not match. > If case of letters matches, everything is OK. On ASCII strings search works > fine. > Older versions (2.2.x) work good. > I've upload sample data > (ftp://ftp.openldap.org/incoming/case-unicode-test.ldiff) > and simple perl script (ftp://ftp.openldap.org/incoming/case-unicode-test.pl) > that can reproduce this behavior. Script will find 1 record when run against > 2.2.x server and nothing on 2.3.x. Thanks for the report. This is now fixed in CVS HEAD libraries/liblunicode/ucdata/ ucgendat.c 1.40 uctable.h 1.6 -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4724) Case-insensitive search on unicode strings fail in 2.3.x
by katuev＠dvbank.ru 29 Oct '06

29 Oct '06

Full_Name: Konstantin Katuev Version: 2.3.28 OS: Solaris URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (195.137.171.26) When using unicode (russian) strings for DNs & attribute values, all sofwtare that searches thru LDAP directory returns no results when case of letters does not match. If case of letters matches, everything is OK. On ASCII strings search works fine. Older versions (2.2.x) work good. I've upload sample data (ftp://ftp.openldap.org/incoming/case-unicode-test.ldiff) and simple perl script (ftp://ftp.openldap.org/incoming/case-unicode-test.pl) that can reproduce this behavior. Script will find 1 record when run against 2.2.x server and nothing on 2.3.x.

1 0

Re: (ITS#4723) SEGV in syncprov search
by richton＠nbcs.rutgers.edu 26 Oct '06

26 Oct '06

> I have no idea what t_delete is but it seems to be dying in your malloc > library. Assuming it's not out of memory, you'll probably need some kind of > malloc debugger (like efence) that can detect heap corruption. Hmm, yeah. Out of memory is unlikely; the core is only a couple hundred MB on a dedicated 2GB box. t_delete is in the depths of the Solaris malloc implementation. I'll ask Sun if they can make anything out of "malloc(35)" causing a SEGV; doesn't exactly sound like documented behavior. You're right that without a memory debugger it's tough to trust any of this. But it's also tough to run a memory debugger in production...they generally slow things down a bit more than I'd like.

1 0

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs