Dan, Dan Melomedman <[EMAIL PROTECTED]> wrote: > 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.
As I stated in my first post, I don't need to be able to update entries one at a time -- I'll just rewrite the entire database every time I need it. Ugly, but less ugly than OpenLDAP I think. I e-mailed Felix and he seems to think that it will work. He says tinyldap supports the basic features that are needed by qmail-ldap. And because tinyldap uses a one-process per request architecture, it's not likely to crash, burn and stop handling requests. I've just asked him how likely something else might go wrong -- like a particular piece of data causing tinyldap to crash, and thus that record is not accessible. (Important note: The CVS version is what I would use. He has done some bugfixing and development since the latest tarball.) I'd appreciate any input or experience that anyone has. > 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! Yuck! > 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". I don't mind using GDBM or sticking with LDAP protocol v2. Why do you recommend staying with 1.3.x? Was something broken when the 2.x.x version was released? I believe you, but it makes me warry about OpenLDAP if they are going backwards on stability. Thanks, David
