openldap-bugs November 2009

openldap-bugs@openldap.org

40 participants
183 discussions

Re: (ITS#6383) Very Slow Query Response
by quanah＠zimbra.com 18 Nov '09

18 Nov '09

--On November 18, 2009 9:39:02 AM +0000 Bill MacAllister <whm(a)stanford.edu> wrote: >> For historical note this was caused by Cyrus-sasl being built >> incorrectly by the debian packagers when heimdal is used. >> > > I don't understand why you refer to this finding as historical. Not a historical finding. As a record for anyone who comes across this ITS and wants to know what was found. > If I > am reading this correctly you and Howard have found the underlying > cause. Now that the problem is understood can you suggest a way for > us to cause the problem in our test environments? At this point we > will really need to convince ourselves that the problem is indeed fixed > before we try to deploy 2.4 in our production environment again. To note, first off, this issue was not a bug in OpenLDAP, and the project went beyond its scope in tracking down why cyrus-sasl was behaving the way it was. Finding out test cases for you to explore is also beyond the scope of the OpenLDAP project when dealing with non-OpenLDAP issues. However, given what is known, i.e., that the NTLM code path was being called during SASL/GSSAPI binds, I would suggest you either set up a number of windows boxes that try and do SASL/GSSAPI auth with NTLM to a test server, or write a script that does that and run it from multiple systems. Some reference points: <http://www.netid.washington.edu/documentation/ldapAuth.aspx> It also seems it may be possible to use python-ldap to do this. I don't know if it is possible with Net::LDAP or Net::LDAPapi --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6384) ldap.conf - problem with comments
by h.b.furuseth＠usit.uio.no 18 Nov '09

18 Nov '09

masarati(a)aero.polimi.it writes: > Hash marks as line-long comment indicators is documented in slapd.conf(5). > It is also documented in recent 2.4 ldap.conf(5). It doesn't actually mention the word "comment" though. I'll tweak a bit so a search for that word will find it, and expand the examples a bit. -- Hallvard

1 0

Re: (ITS#6387) Valgrind reports issues in pcache
by masarati＠aero.polimi.it 18 Nov '09

18 Nov '09

masarati(a)aero.polimi.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD,re24,2.4.19 > OS: irrelevant? > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.175.154.146) > Submitted by: ando > > > See <http://www.openldap.org/lists/openldap-devel/200911/msg00015.html> The fix to ITS#6388 fixes the first valgrind warning of this ITS. p.

1 0

(ITS#6388) A timeout of { -1, 0 } allows to never time out
by masarati＠aero.polimi.it 18 Nov '09

18 Nov '09

Full_Name: Pierangelo Masarati Version: HEAD OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando Some code in back-ldap used a timeout of { -1, 0 } to disable any timeout set via ldap_set_option(). However, the code does not honor it (AFAIK). A fix that explicitly adds this feature is being committed (and documented in ldap_result(3)). p.

1 0

(ITS#6387) Valgrind reports issues in pcache
by masarati＠aero.polimi.it 18 Nov '09

18 Nov '09

Full_Name: Pierangelo Masarati Version: HEAD,re24,2.4.19 OS: irrelevant? URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando See <http://www.openldap.org/lists/openldap-devel/200911/msg00015.html> p.

1 0

(ITS#6386) Usage of ldap_init_fd
by vitaly.kroivets＠gmail.com 18 Nov '09

18 Nov '09

Full_Name: Vitaly Version: 2.4.16 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (192.115.180.11) I try to use function ldap_init_fd, but it fails . ldap_init_fd (sockfd , 1 ,host_uri , &server); ... rc = ldap_simple_bind_s(server, bind_dn, password); if (rc != 0) { fprintf(stderr, "ldap_simple_bind_s: %s", (*ldap_err2string)(rc)); return 1; } rc = ldap_search_s(server, ludp->lud_dn, ludp->lud_scope, ludp->lud_filter, ludp->lud_attrs, 0, &result); ... fails with segmentation fault: #0 find_connection (ld=0x8073ae8, srv=0x807cd50, any=1) at request.c:629 #1 0x080571ba in ldap_chase_referrals (ld=0x8073a08, lr=0x807cc98, errstrp=0x807ccbc, sref=-1, hadrefp=0xbffff84c) at request.c:1356 #2 0x0804c620 in try_read1msg (ld=0x8073a08, msgid=2, all=1, lc=0x8073ae8, result=0x8071ce0) at result.c:805 #3 0x0804bab0 in wait4msg (ld=0x8073a08, msgid=2, all=1, timeout=0x8073ae8, result=0x8071ce0) at result.c:390 #4 0x0804dc5e in ldap_search_s (ld=0x8073a08, base=0x8071d80 "cn=US", scope=0, filter=0x0, attrs=0x0, attrsonly=0, res=0x8071ce0) at search.c:428 #5 0x0804ab38 in main (argc=3, argv=0xbffff9d0) at /tmp/get.c:182 (gdb) p lc $1 = (struct ldap_conn *) 0x8073ae8 (gdb) p *lc $2 = {lconn_sb = 0x807bb30, lconn_refcnt = 3, lconn_created = 0, lconn_lastused = 1258722436, lconn_rebind_inprogress = 0, lconn_rebind_queue = 0x0, lconn_status = 3, lconn_server = 0x0, lconn_ber = 0x0, lconn_next = 0x0} (gdb) quit

1 0

Re: (ITS#6383) Very Slow Query Response
by whm＠stanford.edu 18 Nov '09

18 Nov '09

--On Tuesday, November 17, 2009 09:11:23 PM -0800 Quanah Gibson-Mount <quanah(a)zimbra.com> wrote: > > > On Nov 16, 2009, at 9:03 PM, Bill MacAllister <whm(a)stanford.edu> wrote: > >> >> >> --On Monday, November 16, 2009 07:37:49 PM -0800 Quanah Gibson-Mount >> <quanah(a)zimbra.com> wrote: >> >>> >>> >>> --On November 16, 2009 8:27:21 PM +0000 whm(a)stanford.edu wrote: >>> >>>> Full_Name: Bill MacAllister >>>> Version: 2.4.19+ >>>> OS: Debian 5 >>>> URL: ftp://ftp.openldap.org/incoming/ >>>> Submission from: (NULL) (171.64.19.165) >>>> >>>> >>>> On a system where slapd is the top CPU process and is consuming 4% >>>> of the >>>> CPU simple queries are taking ten of seconds to complete. Here is >>>> an >>>> example query: >>> >>> Last time we saw this it appeared that it might be related to DNS. >>> How long does a netstat -a take on the affected systems when the >>> LDAP queries are slow? >> >> I don't have that number. I have only see it once in the test >> environment I am not sure how long it will take me to get it. Since >> this plastered the production service today, I will have to reproduce >> it though before we attempt another production upgrade. >> >> Not clear to me why a DNS issue would appear only under load and not >> at other times. And it seems strange that it appears in >> lenny/openldap-2.4 and not in etch/openldap-2.3. >> >> Bill >> >> -- >> Bill MacAllister, System Software Programmer >> Unix Systems Group, Stanford University > > For historical note this was caused by Cyrus-sasl being built > incorrectly by the debian packagers when heimdal is used. > > --Quanah I don't understand why you refer to this finding as historical. If I am reading this correctly you and Howard have found the underlying cause. Now that the problem is understood can you suggest a way for us to cause the problem in our test environments? At this point we will really need to convince ourselves that the problem is indeed fixed before we try to deploy 2.4 in our production environment again. Bill -- Bill MacAllister, System Software Programmer Unix Systems Group, Stanford University

1 0

Re: (ITS#6368) Bug in deleting entry in MirrorMode
by pitpalme+openldap＠gmail.com 18 Nov '09

18 Nov '09

Hello, hyc(a)symas.com wrote: > Paste the debug log somewhere we can see it then. Might as well use = debug > level -1 while executing this sequence. And provide the debug output = from both > servers. I=92ve got 60MiB of log files (cumulated from both servers) from running = slapd with "-d Any=93.=20 Sadly this erroneous behavior did only happened after a couple of test = runs, so it=92s a lot of "everything works normal" in this files. The logs are available here: <url:http://pitpalme.is-a-geek.net/ldap/> They're both equal regarding contents, just compressed differently for = faster download if 'xz' as compression tool is available. The test DN that fails is "cn=3DMax = Mustermann,ou=3DbulkTestPerl,ou=3Dtest,o=3Desolution,dc=3Ddeutscherv,dc=3D= de". Thanks in advance and regards, Peter.=

1 0

(ITS#6385) Shutdown of broken syncrepl stanza cores
by masarati＠aero.polimi.it 18 Nov '09

18 Nov '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (131.175.154.146) Submitted by: ando The test for SLAP_SYNC_SUBENTRY() is done on a NULL BackendDB *. A fix is coming. p.

1 0

Re: (ITS#6383) Very Slow Query Response
by rra＠stanford.edu 17 Nov '09

17 Nov '09

quanah(a)zimbra.com writes: > For historical note this was caused by Cyrus-sasl being built > incorrectly by the debian packagers when heimdal is used. Well, rather, that's a theory which currently looks good. It definitely hasn't been proven yet. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
19
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2009