openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#5275) Poor LDAP performance when we reach 1000 connections
by quanah＠zimbra.com 12 Dec '07

12 Dec '07

So fix your file descriptors. --Quanah --On December 12, 2007 11:02:51 PM +0000 hodson.chris(a)orbital.com wrote: > Full_Name: Chris Hodson > Version: 2.3.32 > OS: Red Hat EL 4 Rel 4 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (198.207.0.5) > > > We're using a Red Hat EL 4 release 4 box to run openLDAP version 2.3.32. > Every night we find ourselves reaching 1000+ (netstat | grep ldap | wc > -l) connections to our LDAP server and have found the only resolution to > restart the LDAP service daily. When we get to 1000+ connections > performance takes a huge hit and no one is able to login to any box > utilizing LDAP. This server consists of 2 dual core Opeterons with 8 GBs > of memory, so its not a hardware performance issue. > We're able to duplicate this issue on a RHEL 4 release 5 box also when we > reach 1000+ connections using the same config files. Is there a setting > that needs adjusting so connections timeout or some other config file > misconfiguration? > > > Any help would be much appreciated. > Thank you. > > -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5275) Poor LDAP performance when we reach 1000 connections
by hodson.chris＠orbital.com 12 Dec '07

12 Dec '07

Full_Name: Chris Hodson Version: 2.3.32 OS: Red Hat EL 4 Rel 4 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (198.207.0.5) We're using a Red Hat EL 4 release 4 box to run openLDAP version 2.3.32. Every night we find ourselves reaching 1000+ (netstat | grep ldap | wc -l) connections to our LDAP server and have found the only resolution to restart the LDAP service daily. When we get to 1000+ connections performance takes a huge hit and no one is able to login to any box utilizing LDAP. This server consists of 2 dual core Opeterons with 8 GBs of memory, so its not a hardware performance issue. We're able to duplicate this issue on a RHEL 4 release 5 box also when we reach 1000+ connections using the same config files. Is there a setting that needs adjusting so connections timeout or some other config file misconfiguration? Any help would be much appreciated. Thank you.

1 0

(ITS#5274) add search to online docs
by craig5＠pobox.com 12 Dec '07

12 Dec '07

Full_Name: Craig Sebenik Version: 2.3.35 OS: CentOS 4.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.220.152.66) It would be helpful if the admin documentation on the OpenLDAP web pages had some way to search. http://www.openldap.org/doc/admin24/ IMO, it would be fantastic if there was a simple search box on each page and an "advanced search page" with more options. However, a simple search box on just the main page would be a great start.

1 0

(ITS#5273) ldap.conf and TLS as a default
by cardoe＠gentoo.org 12 Dec '07

12 Dec '07

Full_Name: Douglas Klima Version: 2.3. OS: Linux URL: Submission from: (NULL) (216.155.111.10) I was looking for a way to make TLS the default in /etc/openldap/ldap.conf however it currently seems impossible. You can specify LDAP over clear text and LDAP over SSL but you can't specify LDAP over TLS (I'm talking about "start_tls"). It seems like ldaps:// is deprecated in favor of ldap:// + TLS, which is why I'm trying to configure this. Currently my /etc/openldap/ldap.conf looks like: BASE dc=example,dc=com URI ldap://srv1.example.com ldap://srv2.example.com TLS_REQCERT demand TLS_CACERTDIR /etc/ssl/certs If I do the following: $ ldapsearch ldap_bind: Confidentiality required (13) additional info: TLS confidentiality required If I change URI to have "ldaps://srv1.example.com:389", then $ ldapsearch just hangs until it times out. Clearly it's not using start_tls. Now if I change URI back to it's original setting and do: $ ldapsearch -Z .... # search result search: 3 result: 0 Success # numResponses: 54 # numEntries: 53 I get a successful lookup. I'm basically looking for a way to pass "-Z" in /etc/openldap/ldap.conf and in .ldaprc Initially I tried to send this to the OpenLDAP ML but was told by MacJobBz to submit this to ITS.

1 0

Re: (ITS#5261) Samba4 can 'hang' OpenLDAP slapd
by hyc＠symas.com 11 Dec '07

11 Dec '07

Andrew Bartlett wrote: > On Tue, 2007-12-11 at 14:22 -0800, Howard Chu wrote: >> Andrew Bartlett wrote: >>> I wonder if there is a known issue with db 4.6 and OpenLDAP, as Fedora's >>> OpenLDAP seems to include it's own libslapd_db-4.4.so (it has a >>> slapd_db_stat to match, for 4.4). >> I think they packaged that to avoid using BDB 4.3 which was known to be >> broken. I've been using OpenLDAP with BDB 4.6.1 thru 4.6.3, and 4.6.18 thru >> 4.6.21 without any trouble. > > Where there any further clues on my deadlock in the db_stat output? Yes, it showed a transaction waiting for a write lock on an object that was held by a non-transactional reader. Normally that sort of thing should never deadlock. I would have to dig with gdb to identify which threads owned the locks in question. I guess I may have to build your source to try to duplicate the problem, unless you're up for walking thru a debug session thru IM/etc. -- -- Howard Chu Chief Architect, 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#5261) Samba4 can 'hang' OpenLDAP slapd
by abartlet＠samba.org 11 Dec '07

11 Dec '07

--=-5OIFeVOYW+hUABHuhQBa Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Tue, 2007-12-11 at 14:22 -0800, Howard Chu wrote: > Andrew Bartlett wrote: > > I wonder if there is a known issue with db 4.6 and OpenLDAP, as Fedora'= s > > OpenLDAP seems to include it's own libslapd_db-4.4.so (it has a > > slapd_db_stat to match, for 4.4). >=20 > I think they packaged that to avoid using BDB 4.3 which was known to be=20 > broken. I've been using OpenLDAP with BDB 4.6.1 thru 4.6.3, and 4.6.18 th= ru=20 > 4.6.21 without any trouble. Where there any further clues on my deadlock in the db_stat output? Andrew Bartlett --=20 Andrew Bartlett http://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org Samba Developer, Red Hat Inc. --=-5OIFeVOYW+hUABHuhQBa Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQBHXw8iz4A8Wyi0NrsRAsqOAJ44WnvMZZCXxu3KWaXpG80h98a9RQCfby5v h3+M0ny5D6JqcytP+00anRs= =huku -----END PGP SIGNATURE----- --=-5OIFeVOYW+hUABHuhQBa--

1 0

Re: (ITS#5261) Samba4 can 'hang' OpenLDAP slapd
by hyc＠symas.com 11 Dec '07

11 Dec '07

Andrew Bartlett wrote: > I wonder if there is a known issue with db 4.6 and OpenLDAP, as Fedora's > OpenLDAP seems to include it's own libslapd_db-4.4.so (it has a > slapd_db_stat to match, for 4.4). I think they packaged that to avoid using BDB 4.3 which was known to be broken. I've been using OpenLDAP with BDB 4.6.1 thru 4.6.3, and 4.6.18 thru 4.6.21 without any trouble. -- -- Howard Chu Chief Architect, 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#5265) back-ldif flunks test004-modify
by h.b.furuseth＠usit.uio.no 11 Dec '07

11 Dec '07

Pierangelo Masarati writes: >> test017-syncreplication-refresh > > works for me (in HEAD) For me too. Likely you fixed it with ldapdelete. However now HEAD run -b ldif test011-glue-slapadd fails with differently sorted entries: cn=Manager,dc=example,dc=com is out of place. >> test025-limits [didn't bump into server-side unchecked limit] > > no notion of "unckecked" (should walk the tree to find out how many > entries are there...) Or backends could count down from sizelimit.unchecked while examining and returning entries/referrals. Then fail with adminLimitExceeded if they reach zero. Is it OK to return entries followed by adminLimitExceeded? I don't see any protest in the LDAP RFCs, but I remember vaguely that the code may be mimicing X.500 errors which should not be combined with result entries. (I'll need to reread X.500 soon, it's been too long...) -- Regards, Hallvard

1 0

Re: (ITS#5265) back-ldif flunks test004-modify
by ando＠sys-net.it 11 Dec '07

11 Dec '07

h.b.furuseth(a)usit.uio.no wrote: test004 & test008: fixed (incorrect handling of file deletion) > While I'm checking this - other tests that fail with back-ldif: > test027-emptydn [cannot slapadd to a database with suffix ""] fixed > Unsupported operations, I guess: > test016-subref todo > test017-syncreplication-refresh works for me (in HEAD) > test025-limits [didn't bump into server-side unchecked limit] no notion of "unckecked" (should walk the tree to find out how many entries are there...) > test037-manage manage not supported > OK failure - compare fails because of entry order from ldapsearch: > test012-glue-populate todo > test026-dn fixed (search results not sorted by DN, thus insertion order not preserved by fs) > test004, test008 and test017 succeed in 2.3.38. Maybe the fix to > ITS#4627 (back-ldif issues) was bad? > Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5272) facsimileNumber matching rules status
by ando＠sys-net.it 11 Dec '07

11 Dec '07

anders(a)anduras.de wrote: > I'm filing this new bug report, because I cannot add the question to the real > issue with number 2571 (it's always "Rejected; blocked by automated review > system"). Just send a message to openldap-its(a)openldap.org with ITS#2571 in the subject. > > So, take a look at: > http://www.openldap.org/its/index.cgi/Contrib?id=2571 > > My questions are: > > - What is the current status of this issue / patch? > (I want to see it supported as soon as possible.) Just edit the schema files, adding the desired matching rules. > - What does "Await IETF action" mean?? Presumably, there's an action open with IETF about modifying that schema item. As soon as it's officially modified, OpenLDAP will modify the schema files accordingly. In the meanwhile, all we can do is release schema files that comply with the current standard. This ITS will be closed. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

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