openldap-bugs

openldap-bugs@openldap.org

1 participants
20962 discussions

Re: (ITS#5280) JLDAP waits for response for request which hasn't been sent because of connection shutdown
by Rastogi Arpit 06 Feb '08

06 Feb '08

hi Marcin, Me back from my vacation. How is the issue going on? Is there any progress made . Now I will be able to help you with the issue. This time it will be very helpful if you can tell me how you are using the sdk (the scenario) and code snippet of the code (if possible) and the purpose of using it . regards, Arpit

1 0

Re: (ITS#5280) JLDAP waits for response for request which hasn't been sent because of connection shutdown
by rarpit＠novell.com 06 Feb '08

06 Feb '08

--=__Part82A462B4.1__= Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable hi Marcin, Me back from my vacation. How is the issue going on? Is there any = progress made . Now I will be able to help you with the issue.=20 This time it will be very helpful if you can tell me how you are using the = sdk (the scenario) and code snippet of the code (if possible) and the = purpose of using it . =20 regards, Arpit=20 =20 --=__Part82A462B4.1__= Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Content-Description: HTML <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-15= "> <META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR></HEAD> <BODY style=3D"MARGIN: 4px 4px 1px; FONT: 10pt Segoe UI"> <DIV>hi Marcin,</DIV> <DIV>    Me back from my vacation. How is the issue going = on? Is there any progress made . Now I will be able to help you with the = issue. <BR>This time it will be very helpful if you can tell me how you = are using the sdk (the scenario) and code snippet of the code (if = possible) and the purpose of using it .<BR> <BR>regards,<BR>Arpit = <BR> </DIV></BODY></HTML> --=__Part82A462B4.1__=--

1 0

(ITS#5356) Catching index ownership errors
by rra＠stanford.edu 06 Feb '08

06 Feb '08

Full_Name: Russ Allbery Version: 2.4.7 OS: Debian GNU/Linux URL: Submission from: (NULL) (171.66.157.16) One of the most common problems we see in Debian with people new to OpenLDAP is that they run slapindex as root when they're running their directory server as a non-root user and hence break the file ownership and the database. Would it be possible to add a check in slapindex where, if slapindex is running as root and the database files are owned by a different user, it would either refuse to run (possibly overideable by a flag) or at least print a warning saying that ownership may have to be fixed later? One possible problem, I know, is that the names of the database files are a matter for the database backend and slapindex really shouldn't know what they are. But maybe the check could somehow be added to back-bdb and back-hdb and exposed for slapindex to use?

1 0

(ITS#5355) back-meta calls back-ldap directly
by rra＠stanford.edu 06 Feb '08

06 Feb '08

Full_Name: Russ Allbery Version: 2.4.7 OS: Debian GNU/Linux URL: Submission from: (NULL) (171.66.157.16) back-meta currently makes direct calls to back-ldap. The specific way in which this caused problems is that Debian uses a patched libltdl (to deal with other problems unrelated to OpenLDAP) across the whole distribution which does not open modules with the RTDL_GLOBAL flag and hence doesn't populate all functions into the global namespace. However, my understanding is that regardless of the merits of that particular decision, the current linkage between back-meta and back-ldap is against OpenLDAP's module policy and it's something that you would want to correct.

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by rra＠stanford.edu 06 Feb '08

06 Feb '08

rra(a)stanford.edu writes: > Steve had an ugly hack to work around this by linking the meta backend > against the bdb backend. Doing that isn't the ugly part -- that's > actually formally correct and really is what libtool should be doing in > the first place. The ugly part is that libtool *really* doesn't like > linking against something that doesn't start with lib*. Sorry, I didn't double-check the original report and got this confused. I believe it's back-ldap that back-meta has a dependency on, not back-bdb. -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by orenl＠cs.columbia.edu 06 Feb '08

06 Feb '08

Russ Allbery wrote: > Oren Laadan <orenl(a)cs.columbia.edu> writes: >> Russ Allbery wrote: >>> orenl(a)cs.columbia.edu writes: > >>>> Our configuration uses both BDB and META back-ends; as it turns out >>>> the standard debian package of LDAP fails to run with the META >>>> back-end configured (see also complaints here: >>>> http://www.openldap.org/lists/openldap-bugs/200705/msg00011.html and >>>> here: http://arkiv.netbsd.se/?ml=OpenLDAP-bugs&a=2007-02&t=3076794). > >>> Yeah, we're still trying to figure out the best way to fix that. >>> libtool has some serious problems with how it handles namespaces when >>> dynamically loading modules, and fixing one set of problems creates a >>> separate set of problems. (This particular problem is Debian-specific >>> and not a problem with the upstream OpenLDAP.) >> :( >> >> Well, the good news is that it isn't a show-stopper, and the simple >> workaround is to compile the code from scratch. > > Specifically, the workaround is to compile the code with the upstream > libtool instead of with Debian's libtool, since upstream libtool imports > all module symbols into the global namespace. Debian's libtool has been > modified to not do this because it causes all sorts of other problems in > the general case, but not doing this breaks the meta backend because it > wants to reference symbols from the bdb backend. > > Steve had an ugly hack to work around this by linking the meta backend > against the bdb backend. Doing that isn't the ugly part -- that's > actually formally correct and really is what libtool should be doing in > the first place. The ugly part is that libtool *really* doesn't like > linking against something that doesn't start with lib*. > >> What's really bothering me, is that the system repeatedly and frequently >> hangs with my configuration ... (my users aren't happy with me >> recently). Do you have any idea how to investigate that ? > > Not beyond the standard advice to investigate what the server is doing > during a hang using gdb attach or strace. done that. couldn't find anything interesting: some threads where waiting in some posix-threads related place (most of them were in thread-join if I recall correctly). as I'm not familiar with ldap implementation, was hard to just dive in without prior knowledge. note that the problems happens becomes more acute when I set the "idle_timeout" to 30 seconds; the system is much more tolerant when it isn't set. > > We have yet to have a chance to do intensive testing of 2.4.7. (Debian > testing really is a testing distribution that doesn't have production > stability.) > I observed the exact same behavior on 2.3.9 (latest stable) that I compiled from scratch; this is actually the reason why I moved to 2.4.7 (hoped it would be better). Is there someone who can work with me on getting to the root cause and hopefully getting it fixed ? Oren.

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by rra＠stanford.edu 06 Feb '08

06 Feb '08

Oren Laadan <orenl(a)cs.columbia.edu> writes: > Russ Allbery wrote: >> orenl(a)cs.columbia.edu writes: >>> Our configuration uses both BDB and META back-ends; as it turns out >>> the standard debian package of LDAP fails to run with the META >>> back-end configured (see also complaints here: >>> http://www.openldap.org/lists/openldap-bugs/200705/msg00011.html and >>> here: http://arkiv.netbsd.se/?ml=OpenLDAP-bugs&a=2007-02&t=3076794). >> Yeah, we're still trying to figure out the best way to fix that. >> libtool has some serious problems with how it handles namespaces when >> dynamically loading modules, and fixing one set of problems creates a >> separate set of problems. (This particular problem is Debian-specific >> and not a problem with the upstream OpenLDAP.) > > :( > > Well, the good news is that it isn't a show-stopper, and the simple > workaround is to compile the code from scratch. Specifically, the workaround is to compile the code with the upstream libtool instead of with Debian's libtool, since upstream libtool imports all module symbols into the global namespace. Debian's libtool has been modified to not do this because it causes all sorts of other problems in the general case, but not doing this breaks the meta backend because it wants to reference symbols from the bdb backend. Steve had an ugly hack to work around this by linking the meta backend against the bdb backend. Doing that isn't the ugly part -- that's actually formally correct and really is what libtool should be doing in the first place. The ugly part is that libtool *really* doesn't like linking against something that doesn't start with lib*. > What's really bothering me, is that the system repeatedly and frequently > hangs with my configuration ... (my users aren't happy with me > recently). Do you have any idea how to investigate that ? Not beyond the standard advice to investigate what the server is doing during a hang using gdb attach or strace. We have yet to have a chance to do intensive testing of 2.4.7. (Debian testing really is a testing distribution that doesn't have production stability.) -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by orenl＠cs.columbia.edu 06 Feb '08

06 Feb '08

Russ Allbery wrote: > orenl(a)cs.columbia.edu writes: > >> Our configuration uses both BDB and META back-ends; as it turns out the >> standard debian package of LDAP fails to run with the META back-end >> configured (see also complaints here: >> http://www.openldap.org/lists/openldap-bugs/200705/msg00011.html and >> here: http://arkiv.netbsd.se/?ml=OpenLDAP-bugs&a=2007-02&t=3076794). > > Yeah, we're still trying to figure out the best way to fix that. libtool > has some serious problems with how it handles namespaces when dynamically > loading modules, and fixing one set of problems creates a separate set of > problems. (This particular problem is Debian-specific and not a problem > with the upstream OpenLDAP.) :( Well, the good news is that it isn't a show-stopper, and the simple workaround is to compile the code from scratch. What's really bothering me, is that the system repeatedly and frequently hangs with my configuration ... (my users aren't happy with me recently). Do you have any idea how to investigate that ? Thanks, Oren.

1 0

Re: (ITS#5354) slapd repeatedly hangs and stops reponding
by rra＠stanford.edu 06 Feb '08

06 Feb '08

orenl(a)cs.columbia.edu writes: > Our configuration uses both BDB and META back-ends; as it turns out the > standard debian package of LDAP fails to run with the META back-end > configured (see also complaints here: > http://www.openldap.org/lists/openldap-bugs/200705/msg00011.html and > here: http://arkiv.netbsd.se/?ml=OpenLDAP-bugs&a=2007-02&t=3076794). Yeah, we're still trying to figure out the best way to fix that. libtool has some serious problems with how it handles namespaces when dynamically loading modules, and fixing one set of problems creates a separate set of problems. (This particular problem is Debian-specific and not a problem with the upstream OpenLDAP.) -- Russ Allbery (rra(a)stanford.edu) <http://www.eyrie.org/~eagle/>

1 0

(ITS#5354) slapd repeatedly hangs and stops reponding
by orenl＠cs.columbia.edu 06 Feb '08

06 Feb '08

Full_Name: Oren Laadan Version: 2.4.7 OS: debian/sid URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.59.18.70) Description: The slapd server hangs frequently, and completely stops responding to any request. This results in the entire machine (as well as all clients) becoming unresponsive. Under certain configurations it can happen as frequently as every few minutes. As a temporary measure, we have a script that restarts the server every 10 minutes, just in case. Operating System: Debian Sid Linux ____ 2.6.22-3-amd64 #1 SMP Mon Nov 12 10:28:43 UTC 2007 x86_64 GNU/Linux LDAP version: Our configuration uses both BDB and META back-ends; as it turns out the standard debian package of LDAP fails to run with the META back-end configured (see also complaints here: http://www.openldap.org/lists/openldap-bugs/200705/msg00011.html and here: http://arkiv.netbsd.se/?ml=OpenLDAP-bugs&a=2007-02&t=3076794). So I downloaded the 2.4.7 and compiled with the following options: ./configure \ --enable-dynamic \ --prefix=/opt/ldap-2.4.7 \ --sysconfdir=/etc \ --localstatedir=/var/lib \ --disable-ipv6 \ --enable-spasswd \ --enable-bdb --enable-hdb --enable-ldap --enable-meta --enable-relay \ --enable-overlays \ --with-threads \ --with-tls Setup: Our server is used by clients in abc.main.example.com domain, who are also part of main.example.com domain. In the latter there is already an ldap server ldap.main.example.com; Our server builds on that server extending it by adding some records (e.g. groups that are private to abc.main.example.com). To implement this, I first built a BDB backend that holds the local data that is added to the big database, serving the domain abc.main.example.com. Then I setup a META backend that redirects queries to both the parent server and to the local server; sending to local server also uses "suffixmassage" to convert from the original domain (main.example.com) to the domain (abc.main.example.com). Note that the clients are configured for the regular, original domain, that is main.example.com. Therefore the new domain is only for internal use within the LDAP server. See the configuration file for details. Problem: Originally the config file didn't have the two lines setting "thread" and "idle_timeout"; To reproduce the problem, we would run on one of the clients a script that opens 300 ssh connections outside to some destinations. The ldap server would freeze. Looking for a solution, some posts in google suggested playing with these two parameters. So I added them. And - voila - now it not only happens under those circumstances, but in fact it happens randomly and frequently, maybe every 15 minutes or so, sometimes more sometimes less. It's quite reproducible, and I'm willing to work with whoever to try to solve this. Right now our setup is hardly usable :( Logs and other material are avilable on request. Config file: ---------------------------------------------------------------------------- include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/autofs.schema include /etc/ldap/schema/dnszone.schema include /etc/ldap/schema/dhcp.schema # Where the pid file is put. The init.d script # will not stop the server if you change this. pidfile /var/run/slapd/slapd.pid # List of arguments that were passed to the server argsfile /var/run/slapd/slapd.args # Read slapd.conf(5) for possible values #loglevel 256 loglevel 64 # TRY TO SOLVE ISSUES ? threads 32 idletimeout 30 # Where the dynamically loaded modules are stored # [orenl] we use statically build backends/overlays modulepath /opt/ldap/lib moduleload back_ldap moduleload back_meta moduleload back_bdb # The maximum number of entries that is returned for a search operation sizelimit 10000 # The tool-threads parameter sets the actual amount of cpu's that is used # for indexing. tool-threads 1 ####################################################################### # Specific Backend Directives for bdb: backend bdb TLSCipherSuite HIGH:MEDIUM:LOW TLSCACertificateFile /etc/ldap/ssl/SOME_IP.crt TLSCertificateFile /etc/ldap/ssl/SOME_IP.crt TLSCertificateKeyFile /etc/ldap/ssl/SOME_IP.pem TLSVerifyClient try ####################################################################### # Specific Backend Directives for meta: backend meta TLSCipherSuite HIGH:MEDIUM:LOW TLSCACertificateFile /etc/ldap/ssl/SOME_IP.crt TLSCACertificateFile /etc/ssl/certs/OTHER_IP.crt TLSCertificateFile /etc/ldap/ssl/SOME_IP.crt TLSCertificateKeyFile /etc/ldap/ssl/SOME_IP.pem TLSVerifyClient allow ####################################################################### # Specific Directives for database #1, of type bdb: database bdb # The base of your directory in database #1 suffix "dc=abc,dc=main,dc=example,dc=com" readonly on # rootdn directive for specifying a superuser on the database. This is needed # for syncrepl. #rootdn "cn=admin,dc=main,dc=example,dc=com" #rootpw "change" # Where the database file are physically stored for database #1 directory "/var/lib/ldap" # For the Debian package we use 2MB as default but be sure to update this # value if you have plenty of RAM dbconfig set_cachesize 0 2097152 0 # Sven Hartge reported that he had to set this value incredibly high # to get slapd running at all. See http://bugs.debian.org/303057 # for more information. # Number of objects that can be locked at the same time. dbconfig set_lk_max_objects 1500 # Number of locks (both requested and granted) dbconfig set_lk_max_locks 1500 # Number of lockers dbconfig set_lk_max_lockers 1500 # Indexing options for database #1 index objectClass eq # Save the time that the entry gets modified, for database #1 lastmod on # Everyone can read everything. #access to * by * read ####################################################################### # Specific Directives for database #2, of type 'ldap': database meta lastmod off #rebind-as-user yes # The base of your directory in database #3 suffix "dc=main,dc=example,dc=com" uri "ldaps://OTHER_IP/dc=main,dc=example,dc=com" uri "ldaps:///dc=main,dc=example,dc=com" suffixmassage "dc=main,dc=example,dc=com" "dc=abc,dc=main,dc=eaxmple,dc=com" ----------------------------------------------------------------------------

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