Joshua Megerman <qmail@honorablemenschen.com> wrote:
> >
> > > but I would think for that application NFS would be adequate.
> >
> > Agreed.
> >
> Actually, it isn't. I worked on a cluster of about 10 front-end
> qmail/vpopmail servers serving ~6000 users and handling ~200K messages/day.
> At the height of the busy times, with literally 100+ pop/imap
> connections/second, the tcp.smtp cdb couldn't get rebuilt fast enough to
> avoid collisions. Since vpopmail keeps a dynamic list of IP addresses in (in
> our case) a MySQL DB, and has to combine it with the static list from the FS,
> it was rebuilding the tcp.smtp.cdb file 100 times/second, which is NOT where
> CDB excels.
No, of course not. For fast-changing data like that, skip CDB entirely. Keep
track with individual (probably 0-length) files that you look up either by
hashing, or by simply converting an address A.B.C.D to path .../A/B/C/D.
> The solution for us was to use the tcpserver MySQL patch which
> checks checks the MySQL table in a read-only manner, and let vpopmail handle
> the updates. Which, incidentally, is what the original patch author wrote it
> for...
It's still ugly to put a relational database into this path. All that's
needed is a tiny shim after the checkpassword program that creates the state
file as described above; it'll only be run on successful authentication. Then
you have a similar tiny shim before qmail-smtpd that checks for the existence
of the file and conditionally sets RELAYCLIENT before execing qmail-smtpd
(optionally checking the timestamp on the file is recent enough), and an
external process removing stale state files.
Charles
--
--------------------------------------------------------------------------
Charles Cazabon <qmail@discworld.dyndns.org>
Read http://pyropus.ca/personal/writings/12-steps-to-qmail-list-bliss.html
My services include qmail consulting. See http://pyropus.ca/ for details.
--------------------------------------------------------------------------
|