> Hi Dave,
Hi Ken! :)
> Yes, I was looking at that.
> The first thing that I ran into is trying to minimize database
> transactions during a pop access. The authentication part is
> easy, just read the user info from mysql.
>
> There are two optional transactions that do updates during
> an authentication
> 1) the roaming users --enable-roaming-users=y
> 2) authentication logging --enable-auth-log=y
>
Well, the solution I came up with is to set up 2 MySQL servers doing
two-replication, and load balance the hostname compiled in via a BIPIP. But
not everybody has that luxury :)
> It seems pretty wasteful to have the authentication
> mechanism open two database connections, one for
> the read only auth and one for the two possible updates.
> But I really can not see a way around it.
Yes, it is wasteful, until you need it it :) Why not make it a setup
option? You currently have an option for MySQL auth and an option for large
site. So why not just add an option like --enable-sql-redunancy=y? So, if
you want a RO and a Write connection, you can choose to have it.
>
> For the roaming users stuff to work, the IP addresses
> have to be centralized. Otherwise in a clustered setup
> once they pop, they may or may not be able to use smtp
> relaying. We have tried using a file based system with
> a NFS mount, but it runs into synchronization problems
> when multiple machines are updating the file at the same
> time, and locking doesn't help because NFS locks will
> fail.
>
> One thing we've been looking at is having "fall back"
> servers for both the read and update mysql connections.
> Meaning: if a connection to one fails, then it attempts
> a connection to the fallback machine.
>
> The other thing is the authentication needs to be compiled
> into the binaries. One other option is a patch from
> Ondrej that gets the mysql auth data from environment
> variables.
>
> Ken Jones
>
Dave
