Przemyslaw Wegrzyn wrote:
> Which version of OpenLDAP you were using ?
1.2.11, since 2.x wasn't considered stable by Kurt Zeilenga at the time.
2.0.11 is now considered stable.
> I wonder if there are still leakage issues with current version.
They are most likely fixed with 2.0.11, it would seem. It hasn't been
out long enough to tell for sure. I'm not switching back just to test it
;-)
> Hmm, replicating whole database once can be accepted in this project.
> But, how about, for example, user changing his/her password ?
> Will this data be automaticaly propagated without problems ?
Like I said, my experience with slurpd (OpenLDAP's replication daemon)
was less than desirable. Slurpd was the source of most of the crashes I
experienced, one about every 1-2 weeks. Combine that with the bug that
was in the January release of qmail-ldap that treated ldap timeouts as
non-existant deliveries and I was bouncing mail and pissing people off
with "my email system".
> Why ? is NSS so slow ? It's just libc pluggable module executing in
> address space of a porcess requesting the info.
> Well, the only source of significant overhead I see is spawning
> qmail-getpw (fork/exec costs)
It adds another transaction layer to the process of verifying the
account. Qmail-ldap doesn't have to contact anything but the LDAP server
directly.
> > In-cluster deliveries work via qmqp. Qmqp is not smtp. It is something
> > like 30 times faster than smtp. "Clustering" is a bit of a misnomer for
> > qmail-ldap. It does mail routing based on mailhost attributes in ldap,
> > and it does it quite well.
>
> But it assigns particular accounts to particular servers, that's what I'm
> trying to avoid.
That's the only way it works; unless you recode it, that is. Qmail-ldap
does not contain intelligent load balancing. It is a mail routing server
that can read account info from LDAP.
--
Mike
