David Harris wrote:
> Any other advice on tinyldap or OpenLDAP?
> 
> Thanks!
> 
> David


tinyldap is very, very young, and very limited since Fefe needs
developers to extend it, and AFAIK has made very little progress on it
since 2002, if any. He uses it, and it fits his needs, but it's not very
useful to most anyone else. You must be able to update entries in an
LDAP database to make it useful in a typical ISP environment.

If you are a coder, and like very clean code and design, then go ahead
and help with tinyldap, email Fefe.

If you aren't and want the best stability with OpenLDAP, then I would
_strongly_ recommend the 1.3.x version (1.3.13, I believe) with the GDBM
backend. Note however, that you will be limited to the now archaic
version of the LDAP protocol - version 2. I've been running 1.3.13 for
several years now with only a few database corruptions and small
mishaps. For instance, right now the server isn't busy, and is answering
requests, but all of its threads seem to be looping and eating 75% of
the CPU time. This is how crappy the OpenLDAP code is!

30251 root      15   0  5196 5196   972 R       0 13.9  1.0 21157m slapd
30312 root      13   0  5196 5196   972 R       0 13.7  1.0 18553m slapd
30326 root      13   0  5196 5196   972 R       0 13.7  1.0 21056m slapd
30521 root      14   0  5196 5196   972 R       0 13.5  1.0 18979m slapd
30315 root      14   0  5196 5196   972 R       0 12.9  1.0 19045m slapd
30528 root      16   0  5196 5196   972 R       0 12.5  1.0 21041m slapd
30318 root      15   0  5196 5196   972 R       0 12.3  1.0 18820m slapd
30325 root      15   0  5196 5196   972 R       0 12.3  1.0 18687m slapd
30887 root      14   0  5196 5196   972 R       0 12.3  1.0 18542m slapd
30518 root      13   0  5196 5196   972 R       0 11.9  1.0 20796m slapd
30327 root      14   0  5196 5196   972 R       0 11.3  1.0 21057m slapd
30819 root      14   0  5196 5196   972 R       0 10.5  1.0 18597m slapd


If you still want to use 2.x.x version, then I strongly recommend NOT
using the Berkely DB backend. Use GDBM instead, you'll reduce the number
of future database corruptions dramatically. You will also avoid the
bulk of the bugs and Berkeley DB management overhead. If you've been
hanging around the OpenLDAP mailing lists, you'll see many responses
from OpenLDAP developers such as "This isn't our problem, this is
Berkeley DB problem, go fix it instead".

Reply via email to