Discussion:
max open files
Klemens Kittan
2010-03-10 07:39:48 UTC
Permalink
Hello,

the problem is, that many clients generate more than 1024 concurrent
sockets to the LDAP service which block the remaining incoming sockets.

I already do all the possible changes to the server (ulimit, sysctl,
etc)
without a solution. All the incoming connections stop at the 1024
concurrent sockets.
The only solution is restarting slapd.

The version of openldap is 2.4.11.

In /var/log/syslog I found the following entry:

Mar 1 14:45:15 ldap1 slapd[25320]: warning: /etc/hosts.allow, line 19:
cannot open /etc/hosts.allow: Too many open files

cat /proc/sys/fs/file-max:
203609

cat /proc/<slapd pid>/limits:
Max open files 4096 4096 files

Regards,
Klemens
--
Klemens Kittan
Systemadministrator

Uni-Potsdam, Inst. f. Informatik
August-Bebel-Str. 89
14482 Potsdam

Tel. : +49-331-9773125
Fax. : +49-331-9773122
eMail : ***@cs.uni-potsdam.de

gpg --recv-keys --keyserver wwwkeys.de.pgp.net 6EA09333
Dieter Kluenter
2010-03-12 06:45:49 UTC
Permalink
Post by Klemens Kittan
Hello,
the problem is, that many clients generate more than 1024 concurrent
sockets to the LDAP service which block the remaining incoming sockets.
I already do all the possible changes to the server (ulimit, sysctl,
etc)
without a solution. All the incoming connections stop at the 1024
concurrent sockets.
The only solution is restarting slapd.
The version of openldap is 2.4.11.
cannot open /etc/hosts.allow: Too many open files
Do you really need tcp wrapper support?

-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:8EF7B6C6
53°37'09,95"N
10°08'02,42"E
o***@msu.edu
2010-03-12 16:17:23 UTC
Permalink
I had similar issue a while back with like the 2.2 or 2.3 series, and
part of the database was corrupt. The database couldn't respond to xyz
search and I assume would leave the sockets hanging thus use them all
up. I ended up rebuilding the database.
Post by Dieter Kluenter
Post by Klemens Kittan
Hello,
the problem is, that many clients generate more than 1024 concurrent
sockets to the LDAP service which block the remaining incoming sockets.
I already do all the possible changes to the server (ulimit, sysctl,
etc)
without a solution. All the incoming connections stop at the 1024
concurrent sockets.
The only solution is restarting slapd.
The version of openldap is 2.4.11.
cannot open /etc/hosts.allow: Too many open files
Do you really need tcp wrapper support?
-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:8EF7B6C6
53°37'09,95"N
10°08'02,42"E
Aaron Richton
2010-03-12 15:10:01 UTC
Permalink
Post by Klemens Kittan
cannot open /etc/hosts.allow: Too many open files
203609
Max open files 4096 4096 files
Sounds like you're mostly on the right track, but I didn't hear mention of
compiling with a suitable OPENLDAP_FD_SETSIZE. Are your CPPFLAGS set
accordingly?
Tony G.
2010-03-12 17:55:56 UTC
Permalink
Post by Aaron Richton
Post by Klemens Kittan
cannot open /etc/hosts.allow: Too many open files
203609
Max open files 4096 4096 files
Sounds like you're mostly on the right track, but I didn't hear mention of
compiling with a suitable OPENLDAP_FD_SETSIZE. Are your CPPFLAGS set
accordingly?
Klemens,

Few weeks ago I had a similar issue, I found this thread very useful:
http://www.sunmanagers.org/pipermail/summaries/2005-March/006226.html but
at the end the issue seemed to come from avahi daemon. I'm not familiar
with avahi but the config had:

[rlimits]
#rlimit-as=
rlimit-core=0
rlimit-data=4194304
rlimit-fsize=0
rlimit-nofile=30
rlimit-stack=4194304
rlimit-nproc=3

The machine restarted and started avahi(it was stopped before but not
disabled) and when ldap started to get some connections I received the same
output:
Feb 18 00:49:05 ldap01 slapd[3704]: warning: cannot open /etc/hosts.deny:
Too many open files

Hope that helps.
--
Tony
Klemens Kittan
2010-03-16 09:28:36 UTC
Permalink
On Fri, Mar 12, 2010 at 7:10 AM, Aaron Richton
cannot open /etc/hosts.allow: Too many open files
203609
Max open files 4096 4096 files
Sounds like you're mostly on the right track, but I didn't
hear mention of compiling with a suitable OPENLDAP_FD_SETSIZE.
Are your CPPFLAGS set accordingly?
Klemens,
http://www.sunmanagers.org/pipermail/summaries/2005-March/006226.html
but at the end the issue seemed to come from avahi daemon. I'm not
[rlimits]
#rlimit-as=
rlimit-core=0
rlimit-data=4194304
rlimit-fsize=0
rlimit-nofile=30
rlimit-stack=4194304
rlimit-nproc=3
The machine restarted and started avahi(it was stopped before but not
disabled) and when ldap started to get some connections I received the
Feb 18 00:49:05 ldap01 slapd[3704]: warning: cannot
open /etc/hosts.deny: Too many open files
I looked at that thread. They recommend exactly the things I tried
already, e.g. setting ulimit in the startup script. I checked that with
cat /proc/<slapd pid>/limits. Nevertheless the LDAP stopped responding
after 1024 open connections.
I didn't change "idletimeout" in slapd.conf for I found the follwing in
the LDAP documentation (and we use syncrepl):

"... Caution: This is a server wide value so that all bind connections
are affected by it. If this server is either a replication consumer
(using the syncrepl directive with a type value of refreshAndPersist) or
a provider (using the overlay syncprov directive with a one of more
consumers with a type of refreshAndPersist) then it is highly likely
that these links will remain idle for prolonged periods of time. Extreme
caution should be used when defining the idletimeout directive in either
of these conditions because the net effect may be to change such
replication connections into type refreshOnly which may not be a welcome
side effect..."

On my systems the avahi daemon is not installed.
--
Klemens Kittan
Systemadministrator

Uni-Potsdam, Inst. f. Informatik
August-Bebel-Str. 89
14482 Potsdam

Tel. : +49-331-9773125
Fax. : +49-331-9773122
eMail : ***@cs.uni-potsdam.de

gpg --recv-keys --keyserver wwwkeys.de.pgp.net 6EA09333
Klemens Kittan
2010-03-16 07:34:49 UTC
Permalink
Post by Aaron Richton
Post by Klemens Kittan
cannot open /etc/hosts.allow: Too many open files
203609
Max open files 4096 4096 files
Sounds like you're mostly on the right track, but I didn't hear mention of
compiling with a suitable OPENLDAP_FD_SETSIZE. Are your CPPFLAGS set
accordingly?
I use the OpenLDAP version from the distribution (Debian 5.0.4), so I
can more easily install updates. If there is no other solution, I will
try it.
--
Klemens Kittan
Systemadministrator

Uni-Potsdam, Inst. f. Informatik
August-Bebel-Str. 89
14482 Potsdam

Tel. : +49-331-9773125
Fax. : +49-331-9773122
eMail : ***@cs.uni-potsdam.de

gpg --recv-keys --keyserver wwwkeys.de.pgp.net 6EA09333
Quanah Gibson-Mount
2010-03-16 18:05:46 UTC
Permalink
--On Tuesday, March 16, 2010 8:34 AM +0100 Klemens Kittan
Post by Klemens Kittan
Post by Aaron Richton
Sounds like you're mostly on the right track, but I didn't hear mention
of compiling with a suitable OPENLDAP_FD_SETSIZE. Are your CPPFLAGS set
accordingly?
I use the OpenLDAP version from the distribution (Debian 5.0.4),
There's your first mistake.

<http://www.openldap.org/faq/data/cache/1456.html>

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Matheus Morais
2010-03-16 22:21:41 UTC
Permalink
Well, IMHO this is a really bad excuse and I was not expecting to hear that
in this list.

Klements,

You can get slapd source packages and change the flags as you want. Serious
distribution packages as Debian packages shouldn't be discouraged by
OpenLDAP dev team as I'm seeing here. Debian packages policy are very strong
and help a lot stable environments to be bug-free from recent less stable
versions. I use Debian as a protection from that too early versions who can
potentially threat my production environment and I was very successful with
Debian packages in this attempt.

You can also look for support on Debian IRC channels and lists.
--On Tuesday, March 16, 2010 8:34 AM +0100 Klemens Kittan <
Sounds like you're mostly on the right track, but I didn't hear mention
Post by Klemens Kittan
Post by Aaron Richton
of compiling with a suitable OPENLDAP_FD_SETSIZE. Are your CPPFLAGS set
accordingly?
I use the OpenLDAP version from the distribution (Debian 5.0.4),
There's your first mistake.
<http://www.openldap.org/faq/data/cache/1456.html>
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Quanah Gibson-Mount
2010-03-16 22:30:27 UTC
Permalink
--On Tuesday, March 16, 2010 7:21 PM -0300 Matheus Morais
Post by Matheus Morais
Well, IMHO this is a really bad excuse and I was not expecting to hear
that in this list. 
Klements,
You can get slapd source packages and change the flags as you want.
Serious distribution packages as Debian packages shouldn't
be discouraged by OpenLDAP dev team as I'm seeing here. Debian packages
policy are very strong and help a lot stable environments to be bug-free
from recent less stable versions. I use Debian as a protection from that
too early versions who can potentially threat my production environment
and I was very successful with Debian packages in this attempt.
You can also look for support on Debian IRC channels and lists.
Hi Matheus,

I'll note that article was written by one of the Debian openldap package
maintainers. And it is quite correct that anyone wanting to run a *stable*
OpenLDAP production environment should most definitely *not* use the ones
provided by most Linux OS providers, *particularly* Debian/Ubuntu. The
reasons why this is the case have been hashed over many, many times.
Particularly, the use of GnuTLS which is horribly broken being one of the
major reasons. The fact that they are not kept up to date with current
stable releases is another.

--Quanah

--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Alex McKenzie
2010-03-18 12:46:38 UTC
Permalink
I'll be honest: while LDAP does what I need it to, and is the only tool
I've found that works well for my purposes, this is why I'm constantly
looking for another option. Just about every request for help I see
come across this list gets an initial response of "Oh, well, you're one
or two minor versions out of date. You need to update to the newest
version before we can help you."

Software that unstable is not, in my view, really suited to a production
environment. If the OpenLDAP developers -- who, overall, do an
excellent job -- can't come up with a stable release every six months or
so, there's a problem. If there are so many major flaws that running a
month old version means it's unsupportable, that's an even bigger problem.

I've been following the list for around a year, and I understand the
difficulties involved in supporting old versions, but the simple fact
is, most of us don't have time to custom compile all our server
software. My Ubuntu-default installs of Apache, postfix, SSH, and just
about everything else work fine and can be supported by their
developers. It's only LDAP (and a few things in beta) that absolutely
have to run the newest version at all times. I chose to accept a
limited feature-set and bullied GnuTLS into working "well enough" for
our limited LDAP environment, but if I ever find an alternative, I'll be
moving away from LDAP to whatever that is.

And please -- nobody take this as an attack. I really do respect the
OpenLDAP development team, and the people on this list do their best to
help everyone, even those of us using old versions. I just question the
long-term viability of a system that needs to be recompiled as often as
OpenLDAP seems to.

- -Alex McKenzie
Post by Quanah Gibson-Mount
--On Tuesday, March 16, 2010 7:21 PM -0300 Matheus Morais
Post by Matheus Morais
Well, IMHO this is a really bad excuse and I was not expecting to hear
that in this list.
Klements,
You can get slapd source packages and change the flags as you want.
Serious distribution packages as Debian packages shouldn't
be discouraged by OpenLDAP dev team as I'm seeing here. Debian packages
policy are very strong and help a lot stable environments to be bug-free
from recent less stable versions. I use Debian as a protection from that
too early versions who can potentially threat my production environment
and I was very successful with Debian packages in this attempt.
You can also look for support on Debian IRC channels and lists.
Hi Matheus,
I'll note that article was written by one of the Debian openldap package
maintainers. And it is quite correct that anyone wanting to run a
*stable* OpenLDAP production environment should most definitely *not*
use the ones provided by most Linux OS providers, *particularly*
Debian/Ubuntu. The reasons why this is the case have been hashed over
many, many times. Particularly, the use of GnuTLS which is horribly
broken being one of the major reasons. The fact that they are not kept
up to date with current stable releases is another.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Dieter Kluenter
2010-03-18 15:59:12 UTC
Permalink
Post by Alex McKenzie
I'll be honest: while LDAP does what I need it to, and is the only tool
I've found that works well for my purposes, this is why I'm constantly
looking for another option. Just about every request for help I see
come across this list gets an initial response of "Oh, well, you're one
or two minor versions out of date. You need to update to the newest
version before we can help you."
Software that unstable is not, in my view, really suited to a production
environment. If the OpenLDAP developers -- who, overall, do an
excellent job -- can't come up with a stable release every six months or
so, there's a problem. If there are so many major flaws that running a
month old version means it's unsupportable, that's an even bigger problem.
I've been following the list for around a year, and I understand the
difficulties involved in supporting old versions, but the simple fact
is, most of us don't have time to custom compile all our server
software. My Ubuntu-default installs of Apache, postfix, SSH, and just
about everything else work fine and can be supported by their
developers. It's only LDAP (and a few things in beta) that absolutely
have to run the newest version at all times. I chose to accept a
limited feature-set and bullied GnuTLS into working "well enough" for
our limited LDAP environment, but if I ever find an alternative, I'll be
moving away from LDAP to whatever that is.
And please -- nobody take this as an attack. I really do respect the
OpenLDAP development team, and the people on this list do their best to
help everyone, even those of us using old versions. I just question the
long-term viability of a system that needs to be recompiled as often as
OpenLDAP seems to.
If you don't want to, or don't need to maintain an uptodate openldap
version, feel free to stick to your distribution, if you require
support, ask your distribution maintainer or an appropriate mailing
list of your distribution.

-Dieter
--
Dieter Klünter | Systemberatung
http://dkluenter.de
GPG Key ID:8EF7B6C6
53°37'09,95"N
10°08'02,42"E
Alex McKenzie
2010-03-18 14:36:09 UTC
Permalink
Right. But how much do I pay for Apache? How much do I pay for
postfix, sendmail, qmail, or exim? How about MySQL, or Postgresql? The
real issue, for me, is the version cycle. All of those packages have
minor updates fairly regularly, but none of them change major
functionality, and all of them provide packages to various linux
distributions, including Debian and Ubuntu. And most of them have
decent free support, at least via the sort of mailing list we're on now,
that includes those distribution packages. They may well tell you you
need to install the newest debian package, but they'll almost never tell
you that you have to recompile for basic functionality.

Again: this is a decision the development team made. It's not because
it's free, it's because they chose one particular mode of development.
I'm not saying it's wrong, necessarily, but it drives a lot of people --
like me -- to look for alternatives. Right now, the system pretty much
works, despite the fact that I'm using and older version
(2.4.7-6Ubuntu3). The problem, for me, is that if I write to this list
with a problem, I'll be told no one can help me unless I rebuild from
scratch. So far, it's been easier to work around problems or look for
help in the Ubuntu forums.

You're right that I don't need to keep rebuilding as new versions come
out, but that's only as long as I don't want to ask for help: if I need
to change how something works, or add functionality, even if it's
present in the version I have installed, I have to upgrade.


Anyway: this is really all pretty much irrelevant to the list as a
whole. I just wanted to make the point that this is an issue, and
perhaps something the devels should think about. If they decide to
continue on the way they have... well, that's their option. It's their
project, and they can do what they want with it. But they should at
least be aware that people are concerned about the current methods.

- -Alex
Hi Alex,
I think this falls into the "you get what you pay for..." camp.
On the support page, they list a number of companies that provide
technical support services for OpenLDAP. If the price for stability
is not worth engaging one of them, then you will need to keep your
software up to a revision level that the developers will support.
I am curious what constant issues/bugs are affecting you. Once we
have a working version, it keeps on working and there is no need
to constantly rebuild your software as new releases come out. The
other option that we use here is the 389 Directory server, which
might be an option for you to consider.
Regards,
Ken
I'll be honest: while LDAP does what I need it to, and is the only tool
I've found that works well for my purposes, this is why I'm constantly
looking for another option. Just about every request for help I see
come across this list gets an initial response of "Oh, well, you're one
or two minor versions out of date. You need to update to the newest
version before we can help you."
Software that unstable is not, in my view, really suited to a production
environment. If the OpenLDAP developers -- who, overall, do an
excellent job -- can't come up with a stable release every six months or
so, there's a problem. If there are so many major flaws that running a
month old version means it's unsupportable, that's an even bigger problem.
I've been following the list for around a year, and I understand the
difficulties involved in supporting old versions, but the simple fact
is, most of us don't have time to custom compile all our server
software. My Ubuntu-default installs of Apache, postfix, SSH, and just
about everything else work fine and can be supported by their
developers. It's only LDAP (and a few things in beta) that absolutely
have to run the newest version at all times. I chose to accept a
limited feature-set and bullied GnuTLS into working "well enough" for
our limited LDAP environment, but if I ever find an alternative, I'll be
moving away from LDAP to whatever that is.
And please -- nobody take this as an attack. I really do respect the
OpenLDAP development team, and the people on this list do their best to
help everyone, even those of us using old versions. I just question the
long-term viability of a system that needs to be recompiled as often as
OpenLDAP seems to.
-Alex McKenzie
Post by Quanah Gibson-Mount
--On Tuesday, March 16, 2010 7:21 PM -0300 Matheus Morais
Post by Matheus Morais
Well, IMHO this is a really bad excuse and I was not expecting to hear
that in this list.
Klements,
You can get slapd source packages and change the flags as you want.
Serious distribution packages as Debian packages shouldn't
be discouraged by OpenLDAP dev team as I'm seeing here. Debian packages
policy are very strong and help a lot stable environments to be bug-free
from recent less stable versions. I use Debian as a protection from that
too early versions who can potentially threat my production environment
and I was very successful with Debian packages in this attempt.
You can also look for support on Debian IRC channels and lists.
Hi Matheus,
I'll note that article was written by one of the Debian openldap package
maintainers. And it is quite correct that anyone wanting to run a
*stable* OpenLDAP production environment should most definitely *not*
use the ones provided by most Linux OS providers, *particularly*
Debian/Ubuntu. The reasons why this is the case have been hashed over
many, many times. Particularly, the use of GnuTLS which is horribly
broken being one of the major reasons. The fact that they are not kept
up to date with current stable releases is another.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Howard Chu
2010-03-18 19:10:32 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Right. But how much do I pay for Apache? How much do I pay for
postfix, sendmail, qmail, or exim? How about MySQL, or Postgresql? The
real issue, for me, is the version cycle. All of those packages have
minor updates fairly regularly, but none of them change major
functionality, and all of them provide packages to various linux
distributions, including Debian and Ubuntu. And most of them have
decent free support, at least via the sort of mailing list we're on now,
that includes those distribution packages. They may well tell you you
need to install the newest debian package, but they'll almost never tell
you that you have to recompile for basic functionality.
Most of those projects just release source code, like us. The packages you see
on various distros are built by the distro packagers, not by the upstream
projects.

We'd be happy to tell you to install the newest debian package, if it was ever
new enough. Because it usually isn't, you usually need to recompile. How is
this any different from any other software?

There haven't been any major changes to existing functionality in a couple of
years now. Remember, in the X.Y.Z version number, the Z is just a patchlevel.

If you say "I hit thus-and-such bug in version X.Y.Z" and we say "that's fixed
in X.Y.Z+10" and you don't want to sync up with that patch, that's your decision.
Again: this is a decision the development team made. It's not because
it's free, it's because they chose one particular mode of development.
"Release early, release often." That's the most viable way forward for an open
source project. I'd say our release frequency has been too slow, really.
I'm not saying it's wrong, necessarily, but it drives a lot of people --
like me -- to look for alternatives. Right now, the system pretty much
works, despite the fact that I'm using and older version
(2.4.7-6Ubuntu3). The problem, for me, is that if I write to this list
with a problem, I'll be told no one can help me unless I rebuild from
scratch.
So far, it's been easier to ... look for
help in the Ubuntu forums.
As it should be. If you're running a package from a distro vendor, then you
should be consuming their support resources, not ours. We don't know what all
the distro packagers do, what options they use, what libraries they include.
Some of them ship explicitly broken packages, despite our best efforts. (E.g.,
RedHat/CentOS, linking against Berkeley DB 4.3 when we know for a fact that
this combination crashes, and have explicitly prevented using BDB 4.3 in our
configure script.) If you have a problem with binaries from a distro packager,
that's their responsibility, and we can't help you work past their mistakes
unless you recompile the source and build it properly.
You're right that I don't need to keep rebuilding as new versions come
out, but that's only as long as I don't want to ask for help: if I need
to change how something works, or add functionality, even if it's
present in the version I have installed, I have to upgrade.
Anyway: this is really all pretty much irrelevant to the list as a
whole. I just wanted to make the point that this is an issue, and
perhaps something the devels should think about. If they decide to
continue on the way they have... well, that's their option. It's their
project, and they can do what they want with it. But they should at
least be aware that people are concerned about the current methods.
Your concerns are noted. But IMO they are misdirected. If your distro packager
can't keep you up to date then that's an issue for you and them to deal with.
- -Alex
Hi Alex,
I think this falls into the "you get what you pay for..." camp.
On the support page, they list a number of companies that provide
technical support services for OpenLDAP. If the price for stability
is not worth engaging one of them, then you will need to keep your
software up to a revision level that the developers will support.
I am curious what constant issues/bugs are affecting you. Once we
have a working version, it keeps on working and there is no need
to constantly rebuild your software as new releases come out. The
other option that we use here is the 389 Directory server, which
might be an option for you to consider.
Regards,
Ken
I'll be honest: while LDAP does what I need it to, and is the only tool
I've found that works well for my purposes, this is why I'm constantly
looking for another option. Just about every request for help I see
come across this list gets an initial response of "Oh, well, you're one
or two minor versions out of date. You need to update to the newest
version before we can help you."
Software that unstable is not, in my view, really suited to a production
environment. If the OpenLDAP developers -- who, overall, do an
excellent job -- can't come up with a stable release every six months or
so, there's a problem. If there are so many major flaws that running a
month old version means it's unsupportable, that's an even bigger problem.
I've been following the list for around a year, and I understand the
difficulties involved in supporting old versions, but the simple fact
is, most of us don't have time to custom compile all our server
software. My Ubuntu-default installs of Apache, postfix, SSH, and just
about everything else work fine and can be supported by their
developers. It's only LDAP (and a few things in beta) that absolutely
have to run the newest version at all times. I chose to accept a
limited feature-set and bullied GnuTLS into working "well enough" for
our limited LDAP environment, but if I ever find an alternative, I'll be
moving away from LDAP to whatever that is.
And please -- nobody take this as an attack. I really do respect the
OpenLDAP development team, and the people on this list do their best to
help everyone, even those of us using old versions. I just question the
long-term viability of a system that needs to be recompiled as often as
OpenLDAP seems to.
-Alex McKenzie
Post by Quanah Gibson-Mount
--On Tuesday, March 16, 2010 7:21 PM -0300 Matheus Morais
Post by Matheus Morais
Well, IMHO this is a really bad excuse and I was not expecting to hear
that in this list.
Klements,
You can get slapd source packages and change the flags as you want.
Serious distribution packages as Debian packages shouldn't
be discouraged by OpenLDAP dev team as I'm seeing here. Debian packages
policy are very strong and help a lot stable environments to be bug-free
from recent less stable versions. I use Debian as a protection from that
too early versions who can potentially threat my production environment
and I was very successful with Debian packages in this attempt.
You can also look for support on Debian IRC channels and lists.
Hi Matheus,
I'll note that article was written by one of the Debian openldap package
maintainers. And it is quite correct that anyone wanting to run a
*stable* OpenLDAP production environment should most definitely *not*
use the ones provided by most Linux OS providers, *particularly*
Debian/Ubuntu. The reasons why this is the case have been hashed over
many, many times. Particularly, the use of GnuTLS which is horribly
broken being one of the major reasons. The fact that they are not kept
up to date with current stable releases is another.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Покотиленко Костик
2010-03-19 08:47:22 UTC
Permalink
Post by Howard Chu
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Right. But how much do I pay for Apache? How much do I pay for
postfix, sendmail, qmail, or exim? How about MySQL, or Postgresql? The
real issue, for me, is the version cycle. All of those packages have
minor updates fairly regularly, but none of them change major
functionality, and all of them provide packages to various linux
distributions, including Debian and Ubuntu. And most of them have
decent free support, at least via the sort of mailing list we're on now,
that includes those distribution packages. They may well tell you you
need to install the newest debian package, but they'll almost never tell
you that you have to recompile for basic functionality.
Most of those projects just release source code, like us. The packages you see
on various distros are built by the distro packagers, not by the upstream
projects.
We'd be happy to tell you to install the newest debian package, if it was ever
new enough. Because it usually isn't, you usually need to recompile. How is
this any different from any other software?
There haven't been any major changes to existing functionality in a couple of
years now. Remember, in the X.Y.Z version number, the Z is just a patchlevel.
If you say "I hit thus-and-such bug in version X.Y.Z" and we say "that's fixed
in X.Y.Z+10" and you don't want to sync up with that patch, that's your decision.
This is probably an issue. If I'm correct Debian policy prevent version
upgrade, say, if Lenny have 2.4.11 version, they can't put 2.4.17 in it.
Instead, they can backport some patches from 2.4.17 back to 2.4.11 and
make it 2.4.11-1+lenny1. "they" mean maintainers. On Debian there are a
number of them, there is also a list which doesn't seem dead:

http://packages.debian.org/lenny/slapd
http://lists.alioth.debian.org/pipermail/pkg-openldap-devel/

So, maybe a correct solution for this situation is to figure out what
patch solves given issue and ask maintainers to backport it. Or maybe
just file a bug on Debian.
Post by Howard Chu
Again: this is a decision the development team made. It's not because
it's free, it's because they chose one particular mode of development.
"Release early, release often." That's the most viable way forward for an open
source project. I'd say our release frequency has been too slow, really.
I'm not saying it's wrong, necessarily, but it drives a lot of people --
like me -- to look for alternatives. Right now, the system pretty much
works, despite the fact that I'm using and older version
(2.4.7-6Ubuntu3). The problem, for me, is that if I write to this list
with a problem, I'll be told no one can help me unless I rebuild from
scratch.
So far, it's been easier to ... look for
help in the Ubuntu forums.
As it should be. If you're running a package from a distro vendor, then you
should be consuming their support resources, not ours. We don't know what all
the distro packagers do, what options they use, what libraries they include.
Some of them ship explicitly broken packages, despite our best efforts. (E.g.,
RedHat/CentOS, linking against Berkeley DB 4.3 when we know for a fact that
this combination crashes, and have explicitly prevented using BDB 4.3 in our
configure script.) If you have a problem with binaries from a distro packager,
that's their responsibility, and we can't help you work past their mistakes
unless you recompile the source and build it properly.
You're right that I don't need to keep rebuilding as new versions come
out, but that's only as long as I don't want to ask for help: if I need
to change how something works, or add functionality, even if it's
present in the version I have installed, I have to upgrade.
Anyway: this is really all pretty much irrelevant to the list as a
whole. I just wanted to make the point that this is an issue, and
perhaps something the devels should think about. If they decide to
continue on the way they have... well, that's their option. It's their
project, and they can do what they want with it. But they should at
least be aware that people are concerned about the current methods.
Your concerns are noted. But IMO they are misdirected. If your distro packager
can't keep you up to date then that's an issue for you and them to deal with.
- -Alex
Hi Alex,
I think this falls into the "you get what you pay for..." camp.
On the support page, they list a number of companies that provide
technical support services for OpenLDAP. If the price for stability
is not worth engaging one of them, then you will need to keep your
software up to a revision level that the developers will support.
I am curious what constant issues/bugs are affecting you. Once we
have a working version, it keeps on working and there is no need
to constantly rebuild your software as new releases come out. The
other option that we use here is the 389 Directory server, which
might be an option for you to consider.
Regards,
Ken
I'll be honest: while LDAP does what I need it to, and is the only tool
I've found that works well for my purposes, this is why I'm constantly
looking for another option. Just about every request for help I see
come across this list gets an initial response of "Oh, well, you're one
or two minor versions out of date. You need to update to the newest
version before we can help you."
Software that unstable is not, in my view, really suited to a production
environment. If the OpenLDAP developers -- who, overall, do an
excellent job -- can't come up with a stable release every six months or
so, there's a problem. If there are so many major flaws that running a
month old version means it's unsupportable, that's an even bigger problem.
I've been following the list for around a year, and I understand the
difficulties involved in supporting old versions, but the simple fact
is, most of us don't have time to custom compile all our server
software. My Ubuntu-default installs of Apache, postfix, SSH, and just
about everything else work fine and can be supported by their
developers. It's only LDAP (and a few things in beta) that absolutely
have to run the newest version at all times. I chose to accept a
limited feature-set and bullied GnuTLS into working "well enough" for
our limited LDAP environment, but if I ever find an alternative, I'll be
moving away from LDAP to whatever that is.
And please -- nobody take this as an attack. I really do respect the
OpenLDAP development team, and the people on this list do their best to
help everyone, even those of us using old versions. I just question the
long-term viability of a system that needs to be recompiled as often as
OpenLDAP seems to.
-Alex McKenzie
Post by Quanah Gibson-Mount
--On Tuesday, March 16, 2010 7:21 PM -0300 Matheus Morais
Post by Matheus Morais
Well, IMHO this is a really bad excuse and I was not expecting to hear
that in this list.
Klements,
You can get slapd source packages and change the flags as you want.
Serious distribution packages as Debian packages shouldn't
be discouraged by OpenLDAP dev team as I'm seeing here. Debian packages
policy are very strong and help a lot stable environments to be bug-free
from recent less stable versions. I use Debian as a protection from that
too early versions who can potentially threat my production environment
and I was very successful with Debian packages in this attempt.
You can also look for support on Debian IRC channels and lists.
Hi Matheus,
I'll note that article was written by one of the Debian openldap package
maintainers. And it is quite correct that anyone wanting to run a
*stable* OpenLDAP production environment should most definitely *not*
use the ones provided by most Linux OS providers, *particularly*
Debian/Ubuntu. The reasons why this is the case have been hashed over
many, many times. Particularly, the use of GnuTLS which is horribly
broken being one of the major reasons. The fact that they are not kept
up to date with current stable releases is another.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
--
Покотиленко Костик <***@meteor.dp.ua>
Buchan Milne
2010-03-19 09:31:14 UTC
Permalink
Post by Howard Chu
As it should be. If you're running a package from a distro vendor, then you
should be consuming their support resources, not ours. We don't know what
all the distro packagers do, what options they use, what libraries they
include. Some of them ship explicitly broken packages, despite our best
efforts. (E.g., RedHat/CentOS, linking against Berkeley DB 4.3 when we
know for a fact that this combination crashes, and have explicitly
prevented using BDB 4.3 in our configure script.)
Let's be careful about what we criticise some of the better open source
companies of doing. While the Red Hat packages have historically left a *lot*
to be desired (Red Hat 7.x/RHEL2.1 shipped OpenLDAP 2.0.x built against GNU
gdbm!, RHEL3 shipped 2.0.x when 2.1 had been stable for a substantial amount
of time), the RHEL4 packages of 2.2 built an internal copy of 4.2:

$ rpm -qlp /data/software/linux/redhat/rhel4es-64/RedHat/RPMS/openldap-
servers-2.2.13-12.el4.x86_64.rpm |grep "lib.*db"
/usr/lib64/libslapd_db-4.2.so
/usr/lib64/tls/libslapd_db-4.2.so

and RHEL5 shipped 2.3 (granted, RHEL5.2 and earlier had a very old version,
2.3.27 I think) built with an internal copy of 4.4 (while the "system" copy of
db was 4.3):

$ rpm -qlp /data/software/linux/redhat/rhel5.1-64/Server/openldap-
servers-2.3.27-8.x86_64.rpm |grep "lib.*db"
/usr/lib64/libslapd_db-4.4.so
/usr/lib64/tls/libslapd_db-4.4.so

While Fedora may have shipped OpenLDAP built against db4.3, I can find no
evidence of Red Hat having shipped that combination in any RHEL release.

As of 5.3, the OpenLDAP packages shipped by Red Hat are quite adequate (IMHO),
even if there are some peculiarities and areas for improvement. In
environments which don't justify 2.4, or where OpenLDAP isn't business-
critical (where I still have RHEL4 boxes running 2.3.43 because I can't
justify an OS upgrade yet), CentOS 5.3 with the supplied packages is quite
adequate.

Of course, people who desire packages for 2.4 can get them from others, and
people can argue the point that Red Hat should provide them. However Red Hat
aims to provide some kind of stability, including version stability. And, in
the same was as their OpenLDAP packages are still on 2.3, their samba packages
(at least on RHEL 5.4) are still on 3.0 (when there is even *more* motivation
to ship a newer version, due to compatibility with the new versions of the
desktop software with the biggest market share).

If you have a requirement for 2.4, faced with the choices, I would *not* go
with a distro that ships OpenLDAP built against gnutls, so my personal choices
would be Mandriva or CentOS with my 2.4 packages (but, I could be biased).

Regards,
Buchan
Emmanuel Lecharny
2010-03-18 17:56:33 UTC
Permalink
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Again: this is a decision the development team made. It's not because
it's free, it's because they chose one particular mode of development.
I'm not saying it's wrong, necessarily, but it drives a lot of people --
like me -- to look for alternatives. Right now, the system pretty much
works, despite the fact that I'm using and older version
(2.4.7-6Ubuntu3). The problem, for me, is that if I write to this list
with a problem, I'll be told no one can help me unless I rebuild from
scratch. So far, it's been easier to work around problems or look for
help in the Ubuntu forums.
I don't see whay you should blame the OpenLDAP developpers if
Ubuntu/RH/Suse/Whateverix don't provide updated packages...

Or may be they just need people to compile and test the latest packages
to add them in their distro.

You can volunteer, of course.
--
Regards,
Cordialement,
Emmanuel Lécharny
www.nextury.com
Dan Pritts
2010-03-18 18:57:19 UTC
Permalink
Post by Alex McKenzie
perhaps something the devels should think about. If they decide to
continue on the way they have... well, that's their option. It's their
project, and they can do what they want with it. But they should at
least be aware that people are concerned about the current methods.
I tend to agree with Alex, FWIW, but I too recognize that I get what
I pay for.

danno
--
Dan Pritts, Sr. Systems Engineer
Internet2
office: +1-734-352-4953 | mobile: +1-734-834-7224

Internet2 Spring Member Meeting
April 26-28, 2010 - Arlington, Virginia
http://events.internet2.edu/2010/spring-mm/
Russ Allbery
2010-03-18 23:38:32 UTC
Permalink
Post by Alex McKenzie
perhaps something the devels should think about. If they decide to
continue on the way they have... well, that's their option. It's their
project, and they can do what they want with it. But they should at
least be aware that people are concerned about the current methods.
I tend to agree with Alex, FWIW, but I too recognize that I get what I
pay for.
Out of fairness want to note that the most significant component of the
problems with the OpenLDAP packages for Debian (and Ubuntu, to a somewhat
lesser degree) is that the packaging team has basically no resources.
Only two of us have done much work over the past year or two, and then
only as we've found time, and neither of the two of us who are active have
any free time to spare to increase the amount of work that we're doing
significantly.

This is not something that either is the fault of the OpenLDAP project or
something that any of the OpenLDAP developers can address even if they
wanted to unless they wanted to become experts in Debian packaging.
Debian and Ubuntu need more people with a thorough understanding of Debian
packaging working on improving the packages.

At this point, nearly all complaints about the state of the Debian
packages are rightfully directed at the lack of resources on the Debian
side. There may be some issues that could be reasonably considered a
shared responsibility were the packages in much better shape, but at this
point they're swamped by the lack of volunteer resources to absorb new
upstream releases and do reasonable bug triage.

Unfortunately, we're currently in a state where the people involved in the
packaging don't have enough free time to teach even interested parties
about packaging so that they can come up to speed and help. We really
need volunteers who already know the packaging components and can start
working at that level without needing much additional resources or
training. Both Steve and I are already doing about a dozen other
high-profile things for Debian and are both involved in the packaging of
OpenLDAP primarily out of pure self-interest in not wanting to see the
packages go completely untended, not because we have any realistic ability
to maintain the packages as they properly should be maintained.

I do the Debian package maintenance for OpenAFS, which has a similar or
higher change rate as OpenLDAP and also doesn't do a lot of support for
old stable versions, but the end user experience is much, much better and
the same complaints are not present simply because on the packaging side
I'm able to apply more resources. I have the time to aggressively package
new versions, pull up upstream changes inbetween releases (admittedly,
made *far* easier than it would be for OpenLDAP by OpenAFS's use of Git),
and backport newer versions for users of Debian stable. When Debian users
of OpenAFS run into problems fixed in later versions, I can just tell them
to go to the version from backports.org to solve their problem. This
doesn't require any additional work from the OpenAFS upstream maintainers.

There's absolutely no reason why the same thing couldn't be true of the
OpenLDAP packages for Debian and Ubuntu, without any changes whatsoever to
how the OpenLDAP developers run their project. All it requires is
volunteers and time.
--
Russ Allbery (***@stanford.edu) <http://www.eyrie.org/~eagle/>
Michael Ströder
2010-03-19 09:14:48 UTC
Permalink
Post by Russ Allbery
Post by Alex McKenzie
perhaps something the devels should think about. If they decide to
continue on the way they have... well, that's their option. It's their
project, and they can do what they want with it. But they should at
least be aware that people are concerned about the current methods.
I tend to agree with Alex, FWIW, but I too recognize that I get what I
pay for.
Out of fairness want to note that the most significant component of the
problems with the OpenLDAP packages for Debian (and Ubuntu, to a somewhat
lesser degree) is that the packaging team has basically no resources.
In this case I'd prefer if a Linux distribution would not add a package at
all. At least not a package which was obviously an experimental pre-release at
that time. And not hacking the upstream software to work with components known
to be buggy. This would save us all a lot of time.

Ciao, Michael.
Покотиленко Костик
2010-03-19 10:01:59 UTC
Permalink
Post by Michael Ströder
Post by Russ Allbery
Post by Alex McKenzie
perhaps something the devels should think about. If they decide to
continue on the way they have... well, that's their option. It's their
project, and they can do what they want with it. But they should at
least be aware that people are concerned about the current methods.
I tend to agree with Alex, FWIW, but I too recognize that I get what I
pay for.
Out of fairness want to note that the most significant component of the
problems with the OpenLDAP packages for Debian (and Ubuntu, to a somewhat
lesser degree) is that the packaging team has basically no resources.
In this case I'd prefer if a Linux distribution would not add a package at
all. At least not a package which was obviously an experimental pre-release at
that time. And not hacking the upstream software to work with components known
to be buggy. This would save us all a lot of time.
Again, if not already done so, file a bug against distribution package
and read thier considerations.
--
Покотиленко Костик <***@meteor.dp.ua>
Russ Allbery
2010-03-19 16:58:18 UTC
Permalink
Post by Michael Ströder
Post by Russ Allbery
Out of fairness want to note that the most significant component of the
problems with the OpenLDAP packages for Debian (and Ubuntu, to a
somewhat lesser degree) is that the packaging team has basically no
resources.
In this case I'd prefer if a Linux distribution would not add a package
at all. At least not a package which was obviously an experimental
pre-release at that time. And not hacking the upstream software to work
with components known to be buggy. This would save us all a lot of time.
I understand this opinion, but don't share it. Sorry.
--
Russ Allbery (***@stanford.edu) <http://www.eyrie.org/~eagle/>
Matheus Morais
2010-03-19 04:06:26 UTC
Permalink
First of all let me reconsider my opinion after a carefully read on
Quanah arguments and references about OpenLDAP packages around some distros.
I had read the archives of this list, specifically about GnuTLS problems
with OpenLDAP on Debian and now I understand the point of view of OpenLDAP
developers. In fact, not only understands as I fully support it now. So
sorry if was missing the point at my first email.

I feel very sad to hear about the lack of resources on Debian and most sad
with myself to not be involved on it as much as I wish. I use Debian every
day on my work and I couldn't help the Debian community in the same way that
the community help me. I hope that I can change this some day and become
heavily involved to help in the packages maintenance.

Keep up with this great work in OpenLDAP development and support guys! :)
Post by Russ Allbery
Post by Alex McKenzie
perhaps something the devels should think about. If they decide to
continue on the way they have... well, that's their option. It's their
project, and they can do what they want with it. But they should at
least be aware that people are concerned about the current methods.
I tend to agree with Alex, FWIW, but I too recognize that I get what I
pay for.
Out of fairness want to note that the most significant component of the
problems with the OpenLDAP packages for Debian (and Ubuntu, to a somewhat
lesser degree) is that the packaging team has basically no resources.
Only two of us have done much work over the past year or two, and then
only as we've found time, and neither of the two of us who are active have
any free time to spare to increase the amount of work that we're doing
significantly.
This is not something that either is the fault of the OpenLDAP project or
something that any of the OpenLDAP developers can address even if they
wanted to unless they wanted to become experts in Debian packaging.
Debian and Ubuntu need more people with a thorough understanding of Debian
packaging working on improving the packages.
At this point, nearly all complaints about the state of the Debian
packages are rightfully directed at the lack of resources on the Debian
side. There may be some issues that could be reasonably considered a
shared responsibility were the packages in much better shape, but at this
point they're swamped by the lack of volunteer resources to absorb new
upstream releases and do reasonable bug triage.
Unfortunately, we're currently in a state where the people involved in the
packaging don't have enough free time to teach even interested parties
about packaging so that they can come up to speed and help. We really
need volunteers who already know the packaging components and can start
working at that level without needing much additional resources or
training. Both Steve and I are already doing about a dozen other
high-profile things for Debian and are both involved in the packaging of
OpenLDAP primarily out of pure self-interest in not wanting to see the
packages go completely untended, not because we have any realistic ability
to maintain the packages as they properly should be maintained.
I do the Debian package maintenance for OpenAFS, which has a similar or
higher change rate as OpenLDAP and also doesn't do a lot of support for
old stable versions, but the end user experience is much, much better and
the same complaints are not present simply because on the packaging side
I'm able to apply more resources. I have the time to aggressively package
new versions, pull up upstream changes inbetween releases (admittedly,
made *far* easier than it would be for OpenLDAP by OpenAFS's use of Git),
and backport newer versions for users of Debian stable. When Debian users
of OpenAFS run into problems fixed in later versions, I can just tell them
to go to the version from backports.org to solve their problem. This
doesn't require any additional work from the OpenAFS upstream maintainers.
There's absolutely no reason why the same thing couldn't be true of the
OpenLDAP packages for Debian and Ubuntu, without any changes whatsoever to
how the OpenLDAP developers run their project. All it requires is
volunteers and time.
--
Russ Allbery
2010-03-19 04:24:29 UTC
Permalink
Post by Matheus Morais
First of all let me reconsider my opinion after a carefully read on
Quanah arguments and references about OpenLDAP packages around some
distros. I had read the archives of this list, specifically about
GnuTLS problems with OpenLDAP on Debian and now I understand the point
of view of OpenLDAP developers. In fact, not only understands as I fully
support it now. So sorry if was missing the point at my first email.
I don't think anyone is happy about the multiple SSL library situation.
We (Debian) believe that not using OpenSSL is legally required by the
mixture of licenses in question and that we have no choice unless we were
to remove from the distribution all software covered by the GPL and using
the OpenLDAP libraries. Obviously, other people's legal advice differs,
but we can only go with the legal framework that we have available.

Due to its nature, Debian has to be somewhat more conservative on legal
questions since the project has no legal existence and hence no corporate
or other organizational liability shield. If we screw up on legal
questions, *individual people* potentially get sued. Although I note that
Ubuntu (which I'm not involved in), which does have an organizational
liability shield, is also taking the same stance.

It's one of those cases where the risk of an adverse event are very low,
but the negative consequences are potentially high.

I do think that the security concerns with GnuTLS tend to be somewhat
overstated on this list when summarized (and in a way that's not horribly
helpful in improving the overall quality of the package, not that it's the
obligation of anyone here to help with that). But, regardless, Debian, as
the distributor who wants to use GnuTLS against the explicit advice of the
OpenLDAP developers, should carry the burden of investigating, reducing to
reproducible test cases, and reporting problems that are best corrected in
the OpenLDAP side of the interface. That's not currently happening due to
the same lack of volunteer time discussed in my previous message, and
that's not the fault of the OpenLDAP maintainers.
--
Russ Allbery (***@stanford.edu) <http://www.eyrie.org/~eagle/>
Kurt Zeilenga
2010-03-19 16:51:29 UTC
Permalink
Post by Russ Allbery
we can only go with the legal framework that we have available.
Most certainly.

Often folks forget that there are both technical and non-technical reasons for taking courses of actions in software projects. A project need to do what it believes to be most appropriate.

As Howard notes, many software projects including the OpenLDAP Project ship only their source.

I note that here are both technical and non-technical reasons why a project might take such a course. For instance, lack of expertise in packaging for various platforms might be technical reason. Issues of legal liability might be a non-technical reason.

There are both technical and non-technical reasons behind the OpenLDAP Project practice to ship only source code to OpenLDAP Software.

Regards, Kurt
Покотиленко Костик
2010-03-19 08:52:29 UTC
Permalink
Post by Russ Allbery
Post by Alex McKenzie
perhaps something the devels should think about. If they decide to
continue on the way they have... well, that's their option. It's their
project, and they can do what they want with it. But they should at
least be aware that people are concerned about the current methods.
I tend to agree with Alex, FWIW, but I too recognize that I get what I
pay for.
Out of fairness want to note that the most significant component of the
problems with the OpenLDAP packages for Debian (and Ubuntu, to a somewhat
lesser degree) is that the packaging team has basically no resources.
Only two of us have done much work over the past year or two, and then
only as we've found time, and neither of the two of us who are active have
any free time to spare to increase the amount of work that we're doing
significantly.
This is not something that either is the fault of the OpenLDAP project or
something that any of the OpenLDAP developers can address even if they
wanted to unless they wanted to become experts in Debian packaging.
Debian and Ubuntu need more people with a thorough understanding of Debian
packaging working on improving the packages.
At this point, nearly all complaints about the state of the Debian
packages are rightfully directed at the lack of resources on the Debian
side. There may be some issues that could be reasonably considered a
shared responsibility were the packages in much better shape, but at this
point they're swamped by the lack of volunteer resources to absorb new
upstream releases and do reasonable bug triage.
Is this issue filed on Debian bugtracker?
Post by Russ Allbery
Unfortunately, we're currently in a state where the people involved in the
packaging don't have enough free time to teach even interested parties
about packaging so that they can come up to speed and help. We really
need volunteers who already know the packaging components and can start
working at that level without needing much additional resources or
training. Both Steve and I are already doing about a dozen other
high-profile things for Debian and are both involved in the packaging of
OpenLDAP primarily out of pure self-interest in not wanting to see the
packages go completely untended, not because we have any realistic ability
to maintain the packages as they properly should be maintained.
I do the Debian package maintenance for OpenAFS, which has a similar or
higher change rate as OpenLDAP and also doesn't do a lot of support for
old stable versions, but the end user experience is much, much better and
the same complaints are not present simply because on the packaging side
I'm able to apply more resources. I have the time to aggressively package
new versions, pull up upstream changes inbetween releases (admittedly,
made *far* easier than it would be for OpenLDAP by OpenAFS's use of Git),
and backport newer versions for users of Debian stable. When Debian users
of OpenAFS run into problems fixed in later versions, I can just tell them
to go to the version from backports.org to solve their problem. This
doesn't require any additional work from the OpenAFS upstream maintainers.
There's absolutely no reason why the same thing couldn't be true of the
OpenLDAP packages for Debian and Ubuntu, without any changes whatsoever to
how the OpenLDAP developers run their project. All it requires is
volunteers and time.
--
Покотиленко Костик <***@meteor.dp.ua>
Russ Allbery
2010-03-19 17:01:13 UTC
Permalink
Post by Покотиленко Костик
Post by Russ Allbery
At this point, nearly all complaints about the state of the Debian
packages are rightfully directed at the lack of resources on the Debian
side. There may be some issues that could be reasonably considered a
shared responsibility were the packages in much better shape, but at
this point they're swamped by the lack of volunteer resources to absorb
new upstream releases and do reasonable bug triage.
Is this issue filed on Debian bugtracker?
Yes. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512360

As you can see, the bug has gotten a fair number of replies, but
unfortunately so far they've not translated into more people with time to
do work.
--
Russ Allbery (***@stanford.edu) <http://www.eyrie.org/~eagle/>
Покотиленко Костик
2010-03-22 10:55:40 UTC
Permalink
Post by Russ Allbery
Post by Покотиленко Костик
Post by Russ Allbery
At this point, nearly all complaints about the state of the Debian
packages are rightfully directed at the lack of resources on the Debian
side. There may be some issues that could be reasonably considered a
shared responsibility were the packages in much better shape, but at
this point they're swamped by the lack of volunteer resources to absorb
new upstream releases and do reasonable bug triage.
Is this issue filed on Debian bugtracker?
Yes. http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=512360
As you can see, the bug has gotten a fair number of replies, but
unfortunately so far they've not translated into more people with time to
do work.
Well, I see. I'm going to migrate setup in my organization to LDAP soon.
So, I'm interested in the success of this, and by the way this is why
I've subscribed to the list.

I have some questions not answered before I can migrate, will start new
thread. Shortly, there is 200+ users with mix of UNIX, Samba, Postfix,
Cyrus, eJabberd accounts.

Maybe I can help in testing. Need some invertigation of questions/bugs.
--
Покотиленко Костик <***@meteor.dp.ua>
Dan Pritts
2010-03-19 14:44:53 UTC
Permalink
Post by Russ Allbery
Out of fairness want to note that the most significant component of the
problems with the OpenLDAP packages for Debian (and Ubuntu, to a somewhat
lesser degree) is that the packaging team has basically no resources.
Interesting about the Debian situation. Another reminder to me of why
I don't use Debian; the project's concerns about absolute "freedom"
don't mesh with my concerns about getting real work done.

That said, I've seen similar "don't use the distro's package" notes
about other distributions here, too.

I'm a redhat user. Of course, I should complain to redhat rather than
here, but I only pay them the .edu rate for software updates with no
support. I don't know the history of the particular (ancient at this
point) version of openldap that RHEL5 includes, or what redhat has done
behind the scenes to fix problems, but i have to say that in general
their policy of stability makes running servers a lot easier.

Of course, redhat has its own ldap server, which might explain why
they neglect their openldap packages.

Again though, I recognize that I get from openldap much more than I
have paid to the project. Thanks for all your hard work developing
the software. I suppose if it were super easy to make everything work,
they wouldn't need me here and I'd be flipping burgers. :)

thanks
danno
--
Dan Pritts, Sr. Systems Engineer
Internet2
office: +1-734-352-4953 | mobile: +1-734-834-7224

Internet2 Spring Member Meeting
April 26-28, 2010 - Arlington, Virginia
http://events.internet2.edu/2010/spring-mm/
Howard Chu
2010-03-20 00:37:02 UTC
Permalink
Post by Dan Pritts
Post by Russ Allbery
Out of fairness want to note that the most significant component of the
problems with the OpenLDAP packages for Debian (and Ubuntu, to a somewhat
lesser degree) is that the packaging team has basically no resources.
Interesting about the Debian situation. Another reminder to me of why
I don't use Debian; the project's concerns about absolute "freedom"
don't mesh with my concerns about getting real work done.
That said, I've seen similar "don't use the distro's package" notes
about other distributions here, too.
I'm a redhat user. Of course, I should complain to redhat rather than
here, but I only pay them the .edu rate for software updates with no
support. I don't know the history of the particular (ancient at this
point) version of openldap that RHEL5 includes, or what redhat has done
behind the scenes to fix problems, but i have to say that in general
their policy of stability makes running servers a lot easier.
Of course, redhat has its own ldap server, which might explain why
they neglect their openldap packages.
RedHat's neglect goes back long before they bought Netscape. Anyone holding up
their historical practice as a model of good open source behavior needs to
look again. At least the Debian people are keeping in regular contact on these
mailing lists now. When sticky questions come up, at least we have an
established channel of communication with them. I think some RedHat folks have
been doing better on the communication front recently, and I'm glad to see it.
But it's still pretty minimal in comparison to other teams.
Post by Dan Pritts
Again though, I recognize that I get from openldap much more than I
have paid to the project. Thanks for all your hard work developing
the software. I suppose if it were super easy to make everything work,
they wouldn't need me here and I'd be flipping burgers. :)
Ultimately I'd like the software to work so perfectly that we don't need to
provide support any more, and then I'll just spend my time playing fiddle.

For some level of users, we're already there - plenty of people use it without
needing any help.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Russ Allbery
2010-03-19 23:04:45 UTC
Permalink
Post by Russ Allbery
Out of fairness want to note that the most significant component of the
problems with the OpenLDAP packages for Debian (and Ubuntu, to a
somewhat lesser degree) is that the packaging team has basically no
resources.
Interesting about the Debian situation. Another reminder to me of why I
don't use Debian; the project's concerns about absolute "freedom" don't
mesh with my concerns about getting real work done.
Well, I certainly won't debate that here, but just to be clear, nothing
that I said has anything whatsoever to do with Debian's definition of
freedom or free software. Debian doesn't object to OpenSSL for any
grounds related to free software definitions or licensing. Everyone
agrees that the licenses of all software involved qualify as free
software.

Debian doesn't distribute GPL'd software linked (via OpenLDAP) to OpenSSL
because we believe doing so would be *illegal*. Not non-free, not falling
astray of some Debian licensing principle, but an actual legal violation
of the OpenSSL and GPL licenses for which we could be sued.

If you build the software yourself against OpenSSL but don't distribute
it, the relevant clause of the GPL doesn't apply and there is no issue.

As mentioned previously, I understand that other people's lawyers have
produced different answers.
--
Russ Allbery (***@stanford.edu) <http://www.eyrie.org/~eagle/>
Howard Chu
2010-03-20 05:54:22 UTC
Permalink
Post by Russ Allbery
Post by Russ Allbery
Out of fairness want to note that the most significant component of the
problems with the OpenLDAP packages for Debian (and Ubuntu, to a
somewhat lesser degree) is that the packaging team has basically no
resources.
Interesting about the Debian situation. Another reminder to me of why I
don't use Debian; the project's concerns about absolute "freedom" don't
mesh with my concerns about getting real work done.
Well, I certainly won't debate that here, but just to be clear, nothing
that I said has anything whatsoever to do with Debian's definition of
freedom or free software. Debian doesn't object to OpenSSL for any
grounds related to free software definitions or licensing. Everyone
agrees that the licenses of all software involved qualify as free
software.
Debian doesn't distribute GPL'd software linked (via OpenLDAP) to OpenSSL
because we believe doing so would be *illegal*. Not non-free, not falling
astray of some Debian licensing principle, but an actual legal violation
of the OpenSSL and GPL licenses for which we could be sued.
If you build the software yourself against OpenSSL but don't distribute
it, the relevant clause of the GPL doesn't apply and there is no issue.
Getting far into digression here, but this is another reason to switch to the
nssov / nss-pam-ldapd model. Remove libldap from PAM/NSS and a lot of these
linking issues disappear.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
Russ Allbery
2010-03-20 05:57:30 UTC
Permalink
Post by Howard Chu
Getting far into digression here, but this is another reason to switch
to the nssov / nss-pam-ldapd model. Remove libldap from PAM/NSS and a
lot of these linking issues disappear.
Yes, amen to that. I'm *really* happy with that work, both for that
reason and just for significant simplification of all sorts of linking
issues. I'm not sure if it's enough to resolve the problems that Debian
runs into due to the pile of GPL'd software that wants to link with the
LDAP libraries, but it certainly resolves the problem enough that it might
be on the table at some point, and even apart from that, it's simply a
much better model.

So thank you very much to everyone who's been involved.
--
Russ Allbery (***@stanford.edu) <http://www.eyrie.org/~eagle/>
Dan Pritts
2010-03-22 13:59:48 UTC
Permalink
Post by Russ Allbery
Debian doesn't distribute GPL'd software linked (via OpenLDAP) to OpenSSL
because we believe doing so would be *illegal*. Not non-free, not falling
yes, that became clear from your later reply, I had just assumed it was
due to some insufficiently-Free license that debian had rejected openssl.

sorry for spreading misinformation.

regards
danno
--
Dan Pritts, Sr. Systems Engineer
Internet2
office: +1-734-352-4953 | mobile: +1-734-834-7224

Internet2 Spring Member Meeting
April 26-28, 2010 - Arlington, Virginia
http://events.internet2.edu/2010/spring-mm/

Покотиленко Костик
2010-03-22 09:44:32 UTC
Permalink
Post by Dan Pritts
Post by Russ Allbery
Out of fairness want to note that the most significant component of the
problems with the OpenLDAP packages for Debian (and Ubuntu, to a somewhat
lesser degree) is that the packaging team has basically no resources.
Interesting about the Debian situation. Another reminder to me of why
I don't use Debian; the project's concerns about absolute "freedom"
don't mesh with my concerns about getting real work done.
The problem you are talking about is not Debian related, it's
distribution related. Tommorow the situation may change to the opposite.

When you are not satisfied with the version in stable - the are
backport. If there is no backport, there always is
testing/unstable/experimental to manually make backport from, later
always with most recent version in a resonable short delay.

Not sure about Redhat. I'm a Debian user.
Post by Dan Pritts
That said, I've seen similar "don't use the distro's package" notes
about other distributions here, too.
I'm a redhat user. Of course, I should complain to redhat rather than
here, but I only pay them the .edu rate for software updates with no
support. I don't know the history of the particular (ancient at this
point) version of openldap that RHEL5 includes, or what redhat has done
behind the scenes to fix problems, but i have to say that in general
their policy of stability makes running servers a lot easier.
Of course, redhat has its own ldap server, which might explain why
they neglect their openldap packages.
Again though, I recognize that I get from openldap much more than I
have paid to the project. Thanks for all your hard work developing
the software. I suppose if it were super easy to make everything work,
they wouldn't need me here and I'd be flipping burgers. :)
thanks
danno
--
Dan Pritts, Sr. Systems Engineer
Internet2
office: +1-734-352-4953 | mobile: +1-734-834-7224
Internet2 Spring Member Meeting
April 26-28, 2010 - Arlington, Virginia
http://events.internet2.edu/2010/spring-mm/
--
Покотиленко Костик <***@meteor.dp.ua>
Kenneth Marshall
2010-03-18 14:22:16 UTC
Permalink
Hi Alex,

I think this falls into the "you get what you pay for..." camp.
On the support page, they list a number of companies that provide
technical support services for OpenLDAP. If the price for stability
is not worth engaging one of them, then you will need to keep your
software up to a revision level that the developers will support.
I am curious what constant issues/bugs are affecting you. Once we
have a working version, it keeps on working and there is no need
to constantly rebuild your software as new releases come out. The
other option that we use here is the 389 Directory server, which
might be an option for you to consider.

Regards,
Ken
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'll be honest: while LDAP does what I need it to, and is the only tool
I've found that works well for my purposes, this is why I'm constantly
looking for another option. Just about every request for help I see
come across this list gets an initial response of "Oh, well, you're one
or two minor versions out of date. You need to update to the newest
version before we can help you."
Software that unstable is not, in my view, really suited to a production
environment. If the OpenLDAP developers -- who, overall, do an
excellent job -- can't come up with a stable release every six months or
so, there's a problem. If there are so many major flaws that running a
month old version means it's unsupportable, that's an even bigger problem.
I've been following the list for around a year, and I understand the
difficulties involved in supporting old versions, but the simple fact
is, most of us don't have time to custom compile all our server
software. My Ubuntu-default installs of Apache, postfix, SSH, and just
about everything else work fine and can be supported by their
developers. It's only LDAP (and a few things in beta) that absolutely
have to run the newest version at all times. I chose to accept a
limited feature-set and bullied GnuTLS into working "well enough" for
our limited LDAP environment, but if I ever find an alternative, I'll be
moving away from LDAP to whatever that is.
And please -- nobody take this as an attack. I really do respect the
OpenLDAP development team, and the people on this list do their best to
help everyone, even those of us using old versions. I just question the
long-term viability of a system that needs to be recompiled as often as
OpenLDAP seems to.
- -Alex McKenzie
Post by Quanah Gibson-Mount
--On Tuesday, March 16, 2010 7:21 PM -0300 Matheus Morais
Post by Matheus Morais
Well, IMHO this is a really bad excuse and I was not expecting to hear
that in this list.
Klements,
You can get slapd source packages and change the flags as you want.
Serious distribution packages as Debian packages shouldn't
be discouraged by OpenLDAP dev team as I'm seeing here. Debian packages
policy are very strong and help a lot stable environments to be bug-free
from recent less stable versions. I use Debian as a protection from that
too early versions who can potentially threat my production environment
and I was very successful with Debian packages in this attempt.
You can also look for support on Debian IRC channels and lists.
Hi Matheus,
I'll note that article was written by one of the Debian openldap package
maintainers. And it is quite correct that anyone wanting to run a
*stable* OpenLDAP production environment should most definitely *not*
use the ones provided by most Linux OS providers, *particularly*
Debian/Ubuntu. The reasons why this is the case have been hashed over
many, many times. Particularly, the use of GnuTLS which is horribly
broken being one of the major reasons. The fact that they are not kept
up to date with current stable releases is another.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iEYEARECAAYFAkuiIK4ACgkQWFYfIucpZ2O70QCfYpCKXvpBy3jYu9q55AW3ER/Z
OVsAnjWwqDeshYgYUiwCmdAZInwzhcLD
=ygBw
-----END PGP SIGNATURE-----
Quanah Gibson-Mount
2010-03-18 19:45:59 UTC
Permalink
--On Thursday, March 18, 2010 8:46 AM -0400 Alex McKenzie
Post by Alex McKenzie
I've been following the list for around a year, and I understand the
difficulties involved in supporting old versions, but the simple fact
is, most of us don't have time to custom compile all our server
software. My Ubuntu-default installs of Apache, postfix, SSH, and just
about everything else work fine and can be supported by their
developers. It's only LDAP (and a few things in beta) that absolutely
have to run the newest version at all times. I chose to accept a
limited feature-set and bullied GnuTLS into working "well enough" for
our limited LDAP environment, but if I ever find an alternative, I'll be
moving away from LDAP to whatever that is.
For a moment, consider our frustration. Debian/Ubuntu, because of their
issues with the OpenSSL license, build against GnuTLS. Which is a known
security risk
(<http://www.openldap.org/lists/openldap-devel/200802/msg00072.html>), and
also known to have tons of problems in working with OpenLDAP. RedHat built
their OpenLDAP against BDB 4.3 at one point, even though this was a known
bad version of BDB, and the configure script would deliberately quit if it
was encountered, so RH hacked configure instead of bothering to study why
this was a problem. Distributions also make specific decisions on how to
compile OpenLDAP (i.e., which options to use), that are not always best
suited to end users who want a production LDAP server.

While I agree most applications are easily and readily used with what is
compiled by OS distributors. But as is stated in the FAQ, and which is a
point people still continue to miss, is that the builds from OS distros are
geared toward providing the LDAP libraries for other clients (such as
postfix, etc). They are not geared towards running OpenLDAP as a
production service. Which is why we recommend over and over and over again
to avoid using them. If they happen to work for you great. If they don't,
then either support requests need to be taken to the distro provider, or a
build of the latest stable release needs to be used.

Consider your case, where you are using OpenLDAP 2.4.7, which was the first
public experimental release of 2.4. Read over the change log at the
hundreds, if not over a thousand at this point, bugs that were fixed since
then. As to your note about adding new features, all new branches, like
2.4 was at the time 2.4.7 was released, are open for new features until
development is stabilized and it is feature frozen. OpenLDAP 2.4 has been
feature frozen for a very long time now. This is not an unusual
development pattern.

So yes, if someone wants support for a problem they are experiencing, then
they need to show that the problem exists in the current stable release.
This also is not an uncommon practice. You may find it frustrating, but we
find it frustrating to be inundated with requests for help on issues that
were long ago fixed.

--Quanah


--

Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
Покотиленко Костик
2010-03-19 09:00:40 UTC
Permalink
Post by Quanah Gibson-Mount
--On Thursday, March 18, 2010 8:46 AM -0400 Alex McKenzie
Post by Alex McKenzie
I've been following the list for around a year, and I understand the
difficulties involved in supporting old versions, but the simple fact
is, most of us don't have time to custom compile all our server
software. My Ubuntu-default installs of Apache, postfix, SSH, and just
about everything else work fine and can be supported by their
developers. It's only LDAP (and a few things in beta) that absolutely
have to run the newest version at all times. I chose to accept a
limited feature-set and bullied GnuTLS into working "well enough" for
our limited LDAP environment, but if I ever find an alternative, I'll be
moving away from LDAP to whatever that is.
For a moment, consider our frustration. Debian/Ubuntu, because of their
issues with the OpenSSL license, build against GnuTLS. Which is a known
security risk
(<http://www.openldap.org/lists/openldap-devel/200802/msg00072.html>), and
also known to have tons of problems in working with OpenLDAP. RedHat built
their OpenLDAP against BDB 4.3 at one point, even though this was a known
bad version of BDB, and the configure script would deliberately quit if it
was encountered, so RH hacked configure instead of bothering to study why
this was a problem. Distributions also make specific decisions on how to
compile OpenLDAP (i.e., which options to use), that are not always best
suited to end users who want a production LDAP server.
While I agree most applications are easily and readily used with what is
compiled by OS distributors. But as is stated in the FAQ, and which is a
point people still continue to miss, is that the builds from OS distros are
geared toward providing the LDAP libraries for other clients (such as
postfix, etc). They are not geared towards running OpenLDAP as a
production service. Which is why we recommend over and over and over again
to avoid using them.
You would better recommend to file a bug so that maintainers would
finally consider recommendations of development team.

Also It's strange maintainers are not members of this list, isn't it? :)
Post by Quanah Gibson-Mount
If they happen to work for you great. If they don't,
then either support requests need to be taken to the distro provider, or a
build of the latest stable release needs to be used.
Consider your case, where you are using OpenLDAP 2.4.7, which was the first
public experimental release of 2.4. Read over the change log at the
hundreds, if not over a thousand at this point, bugs that were fixed since
then. As to your note about adding new features, all new branches, like
2.4 was at the time 2.4.7 was released, are open for new features until
development is stabilized and it is feature frozen. OpenLDAP 2.4 has been
feature frozen for a very long time now. This is not an unusual
development pattern.
So yes, if someone wants support for a problem they are experiencing, then
they need to show that the problem exists in the current stable release.
This also is not an uncommon practice. You may find it frustrating, but we
find it frustrating to be inundated with requests for help on issues that
were long ago fixed.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
--
Покотиленко Костик <***@meteor.dp.ua>
Buchan Milne
2010-03-19 09:45:07 UTC
Permalink
Post by Alex McKenzie
I'll be honest: while LDAP does what I need it to, and is the only tool
I've found that works well for my purposes, this is why I'm constantly
looking for another option. Just about every request for help I see
come across this list gets an initial response of "Oh, well, you're one
or two minor versions out of date. You need to update to the newest
version before we can help you."
Well, you haven't personally asked any questions on this list in the past 15
months (AFAICS), and I have personally attempted to provide alternative
answers to many questions which otherwise got the "upgrade before you bug us
further" response, besides spending time and effort on providing up-to-date
packages for two different distributions.
Post by Alex McKenzie
Software that unstable is not, in my view, really suited to a production
environment. If the OpenLDAP developers -- who, overall, do an
excellent job -- can't come up with a stable release every six months or
so, there's a problem.
Well, the 2.3.x series was very stable for me in production. 2.3.43 has been
running flawlessly for almost 2 years, and I switched to 2.3 at around 2.3.11
(and experienced one or two real bugs which were fixed during 2.3.x).

If you don't need the latest features from 2.4, it is also quite stable. The
multi-master code has taken a while to reach stability, but you should really
consider carefully if you *need* it. With OpenLDAP almost never failing,
environments that can't afford a few minutes of downtime a year for critical
kernel security updates should consider HA solutions instead of MMR.
Post by Alex McKenzie
If there are so many major flaws that running a
month old version means it's unsupportable, that's an even bigger problem.
I've been following the list for around a year, and I understand the
difficulties involved in supporting old versions, but the simple fact
is, most of us don't have time to custom compile all our server
software. My Ubuntu-default installs of Apache, postfix, SSH, and just
about everything else work fine and can be supported by their
developers. It's only LDAP (and a few things in beta) that absolutely
have to run the newest version at all times. I chose to accept a
limited feature-set and bullied GnuTLS into working "well enough" for
our limited LDAP environment, but if I ever find an alternative, I'll be
moving away from LDAP to whatever that is.
Maybe you should consider a different distribution, at least for your LDAP
servers, or consider spending your time improving the Debian/Ubuntu packages.
Post by Alex McKenzie
And please -- nobody take this as an attack. I really do respect the
OpenLDAP development team, and the people on this list do their best to
help everyone, even those of us using old versions. I just question the
long-term viability of a system that needs to be recompiled as often as
OpenLDAP seems to.
As I showed, depending on the features you need, this isn't a necessity. And,
even if it is a necessity, there's no reason you should need to do it
yourself. That's what distributions are for.

<punt>
All supported versions of Mandriva typically get the latest version of
OpenLDAP in their backports repo within 2 weeks of the upstream source
release. Rebuilds of those packages for Red Hat/CentOS 5 follow as and when I
have time to build and upload manually.
</punt>

Regards,
Buchan
Edgar Fuß
2010-03-21 10:23:33 UTC
Permalink
Post by Buchan Milne
Maybe you should consider a different distribution, at least for your LDAP
servers, or consider spending your time improving the Debian/Ubuntu packages.
May I throw in that pkgsrc works on Linux, too? Their stable branch (2009Q4) is at 2.4.19, while HEAD is at 2.4.21, so this will go into 2010Q1 shortly.
Buchan Milne
2010-03-19 10:14:44 UTC
Permalink
Post by Aaron Richton
Post by Klemens Kittan
cannot open /etc/hosts.allow: Too many open files
203609
Max open files 4096 4096 files
Sounds like you're mostly on the right track, but I didn't hear mention of
compiling with a suitable OPENLDAP_FD_SETSIZE. Are your CPPFLAGS set
accordingly?
I ran into this at some stage, and built some binaries (for RHEL3 I think)
with a higher OPENLDAP_FD_SETSIZE, however I am sure the discussion about this
concluded that on modern linux distros, this is no longer necessary, due to
the use of epoll. While it might still apply on other non-Linux-2.6 platforms
(doesn't Solaris have it's own API for similar purposes?), this should not be
a concern for anyone one a non-ancient Linux installation.

This bug report on Debian which relates to the same issue, seems to have come
to the same conclusion:

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=378261

On my laptop, running Mandriva 2010.0 x86_64 with the Mandriva OpenLDAP
package I ran the perl script in that bug report after increasing the file size
limit for OpenLDAP:

[***@tiger ~]# grep ^MAX /etc/sysconfig/ldap
MAXFILES=4096

which resulted in the correct limit being applied to the slapd pid:
[***@tiger ~]# grep files /proc/`pidof slapd`/limits
Max open files 4096 4096 files

and the limit for the shell from which I ran the script:

[***@tiger ~]# ulimit -n
4096

[***@tiger ~]# perl /home/bgmilne/bin/ldapportcheck.pl
[...]
4091
4092
Couldn't create socket 4093: Too many open files at
/home/bgmilne/bin/ldapportcheck.pl line 11.

slapd had been happy to have more than 4000 files open:

Mar 19 11:05:13 tiger slapd[22716]: conn=6086 fd=4083 ACCEPT from
IP=127.0.0.1:35432 (IP=0.0.0.0:389)


So, my conclusion is:
1)You're doing something wrong in your testing
2)For some reason Ubuntu is not biulding with epoll support
3)There is some obscure bug in OpenLDAP that results in file limit not being
adhered to even when built with epoll support

Regards,
Buchan
Loading...