Comments on: Odd Directory Server problem

By: OpenDS - YALDAPS and a look at the current playing field at VMUNIX Blues

OpenDS - YALDAPS and a look at the current playing field at VMUNIX Blues — Thu, 03 Aug 2006 01:42:40 +0000

[...] If I had to summarize the differences between Netscape DS and OpenLDAP, it would be this: One is well documented, and one isn’t. In case you didn’t guess, the Netscape LDAP server is the one that’s leaps and bounds better in this regard and now that Fedora DS is out there for free, it’s the one I recommend any sysadmins starting with LDAP take a look at first. Even if you don’t deploy Fedora DS, or Red hat DS, or Sun DS (on 64-bit Solaris — stay far, far away from Sun DS on Linux or 32-bit Solaris) you need to start with the Netscape docs. Because only they actually have chapters about general concepts, systems architecture, and deployment scenarios. The OpenLDAP docs will tell you how to use OpenLDAP, but they won’t tell you how to build directory services. Which means you’ll probably give up and walk away from OpenLDAP before you make it do anything useful for you. [...]

By: mark

mark — Thu, 04 Aug 2005 21:56:27 +0000

Thanks for the clarification, David. I should have said “use OpenLDAP on a non-Solaris box” as a possible solution. FreeBSD and Linux, for example, don’t have the stdio limitation so you wouldn’t bump into the problem.

We chose to stick with Sun Directory Server on Solaris 10 (i386) and just got people to re-enter their passwords. But if I were starting from scratch again I’d probably just go OpenLDAP on Linux.

By: David Baldwin

David Baldwin — Wed, 03 Aug 2005 23:27:48 +0000

OpenLDAP uses crypt() in the same circumstances and with the same limitations on my Solaris 9 box.

from man -s 3c crypt:
The crypt() function calls crypt_gensalt(3C) to generate the
salt. If the first character of salt is “$”, crypt() uses
crypt.conf(4) to determine which shared module to load for
the encryption algorithm. If the first character of salt is
not “$”, the algorithm described on crypt_unix(5) is used.

And it can’t open /etc/security/crypt.conf if it doesn’t have a free file descriptor available

By: mark

mark — Fri, 15 Jul 2005 18:01:39 +0000

Steve: Don’t use {crypt} style password entries in your directory, basically. If you load the passwords in as {SSHA} hashes in your directory, ns-slapd doesn’t have to call out to the UNIX crypt() routines in libc, so you don’t hit the stdio file descriptor limit.

If you only have UNIX crypts from, say, /etc/passwd, you have to get users to re-enter their passwords. We made a simple script to do this. Painful, yes. But that’s the only solution if you want to stick with Directory Server on a 32-bit system.

The other solution would be to use OpenLDAP. Or get a 64-bit Solaris box…

By: Steve Lee

Steve Lee — Fri, 15 Jul 2005 17:31:22 +0000

I am currently running into the same problem you have. What was your final solutions to this.

By: Jim Litchfield

Jim Litchfield — Mon, 20 Jun 2005 14:37:36 +0000

The key is whether the LDAP server is a 32-bit app. It probably is and there is a limitation
of 256 FDs that can be open in the stdio library for 32-bit apps. Given the error message,
this is most likely the cause. You could harass the support people to ask the LDAP server
people to make sure that they don’t have any fds in the range of 0-255 that don’t use
stdio. Although that would make life easier, the real cure is to make the LDAP server 64-bit.

There were several efforts to “enhance” the 32-bit library to support more than 256
fds but these all foundered on various obscure edge cases that meant one would have to
recompile all apps and libraries that used 32-bit to be totally safe. The sticking point?
Mainly fileno() which for a very long time was a macro referencing an unsigned byte field.

By: Jason

Jason — Fri, 17 Jun 2005 04:31:33 +0000

Reading the tunables guide, I came across this:

Compared to rlim_fd_max. If rlim_fd_cur is greater than rlim_fd_max, rlim_fd_cur is reset to rlim_fd_max.

You might need to also increase rlim_fd_max. Having said that, rlim_fd_max section mentions this:

A 32-bit program using standard I/O is limited to 256 file descriptors. A 64-bit program using standard I/O can use up to 2 billion descriptors. Specifically, standard I/O refers to the stdio(3C) functions in libc(3LIB).

Not sure if this is the crux of the problem but it might be since this program is running on a 32 bit system.

By: mark

mark — Wed, 15 Jun 2005 18:40:57 +0000

I turned nscd off after I was seeing some weirdness with it blocking some user accounts in LDAP. Weird stuff where if you do a “getent passwd username” with nscd off the record shows up just fine. Turn nscd on and you get nothing back. You’re correct of course that with it on I see a lot less nss traffic to the LDAP server. But I still see the problem.

By: nathan hruby

nathan hruby — Wed, 15 Jun 2005 14:10:11 +0000

Is nscd running on the linux hosts? Probably it isn’t and the LDAP conenctions are for nss_ldap doing various nss lookups over and over again (assuming of course, you have nss_ldap turned on, which I’m blindly, and possibly wrongly, assuming you do since you have pam_ldap on..)