Just out of curiosity, how many users does 20-25 
authentications per second equate to for you?

Thanks.


On Monday 25 November 2002 12:58, Brian Kolaci 
wrote:
> You can disable it at runtime also.
> Just specify it in the AUTHMODULES variable in
> the .../etc/*.config files (mine is at
> "authvchkpw authpam") rather than
> "authdaemond".  You don't have to go back and
> do a fresh compile.
>
> I was trying to use courier-imap 1.6.0, but I'm
> stuck at version 1.4.2.
>
> Under high loads, you *need* to have a pool of
> authentication servers.  I also use MySQL so
> the database authentication needs to take place
> for every request.  So some work needs to be
> done there, however I don't think its high on
> Sam's list.  I may have to tackle it in the not
> too distant future, but I don't think my work
> would get incorporated into his distribution...
>  Ken & Bill have been willing to take patches.
>
> Thanks,
>
> Brian
>
>   > Yeah. I ran into the same problem. They/we
>   > should really include that in documentation
>   > somewhere. In fact, I get that problem with
>   > sqwebmail even if
>
> I
>
>   > DO disable authdaemon.... I'm not sure it's
>   > the same kind of issue though.
>   >
>   > But back to the reason I posted in the
>   > first place:
>   >
>   > I've seen plenty of people complain on the
>   > sqwebmail list that authdaemon croaks after
>   > a short time under high load. Using only
>   > the authvchkpw module and disabling
>   > authdaemon at compile time always fixed the
>   > problem.
>   >
>   > What versions are you running?
>   >
>   > On Monday 25 November 2002 12:24, Brian 
Kolaci wrote:
>   > > authdaemond works for me, however IP
>   > > Alias doesn't work since the IP
>   > > information is passed via environment
>   > > variables.  The authdaemon protocol
>   > > doesn't take into account any of the
>   > > environment variables set by couriertcpd,
>   > > so your missing some of the critical
>   > > information.  I've mentioned this on the
>   > > courier list as well, however it didn't
>   > > appear anyone cared...
>   > >
>   > > If you disable authdaemond (and have it
>   > > fork/exec each login request), then it
>   > > works fine.  Its just not scalable (and
>   > > I'm getting into that problem now when I
>   > > hit about 20-25 authentications per
>   > > second).
>   > >
>   > > Thanks,
>   > >
>   > > Brian
>   > >
>   > >   > Are you using authdaemon? I believe
>   > >   > disabling auth daemon at compile time
>   > >   > fixes the problem too. compile with:
>   > >   >
>   > >   > --without-authdaemon \
>   > >   > --with-vchkpw
>   > >   >
>   > >   > when compiling courier-imap.
>   > >   >
>   > >   > I don't use authdaemon, and I don't
>   > >   > have any troubles. This is an
>   > >   > on-going list discussion.
>   > >   >
>   > >   > On Monday 25 November 2002 11:11, Dzuy 
Nguyen wrote:
>   > >   > > There is a bug in vchkpwd in
>   > >   > > vpopmail 5.2.1.  Version 5.3.x
>   > >   > > seems to fix it.
>   > >   > >
>   > >   > > [EMAIL PROTECTED] wrote:
>   > >   > > >I am using a
>   > >   > > > qmail/vpopmail/courier-imap mail
>   > >   > > > solution.  After re-installing
>   > >   > > > courier-imap, the first few
>   > >   > > > times, imap sessions to work
>   > >
>   > > and
>   > >
>   > >   > > >authenticate, but after awhile,
>   > >   > > > authentication fails and I get
>   > >   > > > nothing
>   > >
>   > > but
>   > >
>   > >   > > >LOGIN FAILED messages in my
>   > >   > > > maillog.  A reboot of the server
>   > >   > > > will fix it for a short time;
>   > >   > > > however, it keeps happening.  Has
>   > >   > > > anyone had this occur before or
>   > >   > > > have a possible solution?
>   > >   > > >
>   > >   > > >I am running these versions:
>   > >   > > >FreeBSD 4.5-RELEASE
>   > >   > > >Qmail - 1.03_1
>   > >   > > >vpopmail - 5.2
>   > >   > > >Courier-Imap - 1.5.3
>   > >   > > >
>   > >   > > >Any suggestions would be helpful.
>   > >   > > >
>   > >   > > >Thanks,
>   > >   > > >
>   > >   > > >Taylor Dondich
>   > >
>   > > Brian
>   > > Galaxy Networks, Inc.
>
> Brian
> Galaxy Networks, Inc.


Reply via email to