What if ...
... the authentication were done by a seperate daemon entirely (like PAM's
functionality) which cached the responses from the real authentication
system? The generic authentication routine would be removed from
Courier-IMAP (slightly) and would be queried (by pipe / unix socket / etc.)
with the auth. information. It would then either check a cdb, or grab the
data from MySQL, or from LDAP, etc. It would cache a certain number of
requests, and could be optimised seperately. It could cache actual auth.
information, not SQL responses, etc.
----- Original Message -----
From: "Michael Boman" <[EMAIL PROTECTED]>
> Ninad Gupte wrote:
> >
> > Hello Guys,
> >
> > I have been following up on vpopmail and intend to start using it on our
> > production server now. However I would like to know whether there is any
> > advantage in using MySQL authentication over standard file based
> > authentication. I understand that as a sysadmin, I might have easier
> > control / access to user data, etc. But is this good enough on a system
> > handling say about 3000 users and hosting a few hundred domains?
> >
> > I had a past experience with an ISP who used MySQL for authentication
(I
> > dont know whether he was using vpopmail, or something else), and the
> > authentication would fail at times under heavy server load. I do not
want
> > such a scenario to be repeated.
>
> SQL databases has that problem, and there is not much you can do about
> it except using a caching daemon. I haven't seen anyone for qmail, but I
> know courier has a caching daemon for authication.
>
> To play it safe for now, use cdb auth.
>
> > I will wait for inputs from users who have already been running their
vpop
> > under MySQL before going ahead with the setup. Also are there any such
> > problems with filebased authentication under loads, that I probably did
not
> > realise?
> >
> > Thanks
> > Ninad
>
> Filebased auth. takes long time to update with many users (in the same
> domain) and with high server load.