openldap-bugs

openldap-bugs@openldap.org

1 participants
20961 discussions

(ITS#5236) core.ldif differs from core.schema
by hyc＠symas.com 13 Dec '07

13 Dec '07

Michael Ströder wrote: > HI! > > following up on this because some older schema files reference > 'countryName' (and worked with RE23). > > Howard Chu wrote: >> I'm puzzled why RFC4519 drops the 'countryName' alias for this type >> from the RFC2256 definition. > > Me too... > > How to deal with that (except changing the schema files of other vendors)? After chatting with Kurt, we confirmed that there was no reason to drop the alias from our schema files, so I've restored it. (Implementations are allowed to recognize multiple names for the same attribute. Since slapd still only generates the canonical name in its output, we are still conformant.) -- -- 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 hyc＠symas.com 13 Dec '07

13 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? I've just built Samba4 from svn and tried to run this test, but it fails much earlier on my AMD64 system. It looks like your ldbsearch client is generating an invalid request, perhaps it's not 64-bit aware. In st/dc/private/ldap/logs I see: >>> slap_listener(ldapi://%2Fhome%2Fsoftware%2FSAMBA_4_0%2Fsource%2Fst%2Fdc%2Fprivate%2Fldap%2Fldapi) daemon: activity on 1 descriptor daemon: activity on: daemon: epoll: listen=7 active_threads=0 tvp=NULL daemon: listen=7, new connection on 20 daemon: activity on 1 descriptor daemon: activity on: 20r daemon: read active on 20 daemon: added 20r (active) listener=(nil) daemon: epoll: listen=7 active_threads=0 tvp=NULL connection_get(20) connection_get(20): got connid=0 connection_read(20): checking for input on id=0 ber_get_next ldap_read: want=8, got=8 0000: 80 04 00 0a 01 00 0a 01 ........ ber_get_next on fd 20 failed errno=34 (Numerical result out of range) connection_read(20): input error=-2 id=0, closing. All LDAP requests should begin with 0x30, the BER Sequence tag. -- -- 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#5275) Poor LDAP performance when we reach 1000 connections
by hyc＠symas.com 13 Dec '07

13 Dec '07

The ITS is for tracking actual bugs. There is no evidence of anything other than a misconfiguration issue here. Use the OpenLDAP-software mailing list for questions about how to use the software. This ITS will be closed. 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. > > > . > -- -- 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

(ITS#5276) include handler broken
by quanah＠zimbra.com 13 Dec '07

13 Dec '07

Full_Name: Quanah Gibson-Mount Version: 2.3.39 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (66.92.25.194) In discussions with a fellow on IRC, it looks like the include handler has some serious problems. For example with this slapd.conf, we get: #ucdata-path "/opt/zimbra/openldap/ucdata" include "/opt/zimbra/openldap/etc/openldap/schema/core.schema" include "/opt/zimbra/openldap/etc/openldap/schema/cosine.schema" include "/opt/zimbra/openldap/etc/openldap/schema/inetorgperson.schema" include "/opt/zimbra/openldap/etc/openldap/schema/amavisd.schema" include "/opt/zimbra/openldap/etc/openldap/schema/zimbra.schema" include "/opt/zimbra/lib/conf/zimbra-ext.schema" threads 8 pidfile "/opt/zimbra/openldap/var/run/slapd.pid" argsfile "/opt/zimbra/openldap/var/run/slapd.args" TLSCertificateFile /opt/zimbra/conf/slapd.crt TLSCertificateKeyFile /opt/zimbra/conf/slapd.key TLSVerifyClient never loglevel 32768 # Load dynamic backend modules: modulepath /opt/zimbra/openldap/libexec/openldap moduleload back_bdb.la moduleload back_monitor.la moduleload syncprov.la moduleload accesslog.la <acl lines snipped> database config rootpw {SSHA}+wKEnqbcbxssdGDKx1LeNsoL90Ha2Lzx database monitor rootdn "cn=config" access to dn.children="cn=monitor" by dn.children="cn=admins,cn=zimbra" read include /opt/zimbra/conf/bdb-conf include /opt/zimbra/conf/syncrepl-conf bdb-conf is: database bdb suffix "" rootdn "cn=config" cachesize 10000 idlcachesize 10000 checkpoint 64 5 directory "/opt/zimbra/openldap-data" index objectClass eq sizelimit unlimited timelimit unlimited And we can see it is clearly processed, so why is the syncrepl line getting tagged to the monitor backend? line 47 (index entryCSN eq) index entryCSN 0x0004 line 48 (sizelimit unlimited) line 49 (timelimit unlimited) line 154 (include /opt/zimbra/conf/syncrepl-conf) reading config file /opt/zimbra/conf/syncrepl-conf line 13 (syncrepl ***) /opt/zimbra/conf/syncrepl-conf: line 13: database monitor does not support operations required for syncrepl /opt/zimbra/conf/slapd.conf: line 154: <include> handler exited with 1! Another example of this problem can be seen at: http://pastebin.com/d16e9b905

1 0

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

13 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 13 Dec '07

13 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 12 Dec '07

12 Dec '07

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

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