DAve wrote:
Sorry, had more thoughts...
Dave Richardson wrote:
Anyone aware of a particularly good discussion of building a farm of
vpopmail "compliant" front-end machines for user access to a central
file server via NFS on linux? I'm concerned that I haven't thought
through issues in how to properly account for webmail/IMAP, MySQL for
storing smtp-auth IPs for relay control, and a few other topics.
Googling hasn't yielded much but a few threads from the *BSD folks.
My tentative thinking is 2+ front end machines that draw from a
common/identical configuration that provide the client interfaces via:
- SMTPd, smtp-auth, pop3d, send, IMAPd, anti-virus, anti-spam, webmail
(apache + squirrelmail)
I would advise using the local supervise scripts. They should change so
little that running them from a mounted dir really isn't needed. In our
case we wanted them local. For example,
exec /usr/local/bin/softlimit -m 2000000 \
/usr/local/bin/tcpserver -v -P -R -h -l ecluster4.tls.net -x \
/var/qmail/control/tcp.smtp.cdb -c "$MAXSMTPD" \
-u "$QMAILDUID" -g "$NOFILESGID" 10.0.241.134 25 \
/usr/local/bin/fixcrio /var/qmail/bin/qmail-smtpd 2>&1
Putting the host name and the IP in the run file will make your headers
more informative. Most How-Tos don't show that. You could script a
solution I'm sure if you choose to share run files.
As far as smtp-auth IPs, we offer smtp to only the networks we own for
outbound mail, we make everyone else us smtp-auth. Our IPs don't change
often enough to warrant sharing tcp.cdb, though we configured it that
way from the beginning. Using smtp-auth instead of relay IP solutions
means we don't have to modify and rebuild cdb files all day.
Keep in mind that changing a shared file will make all servers see the
changes immediately, for better or for worse. It's a balancing act. Risk
vs Convenience.
- CHKUSER talking to the backend server
CHKUSER doesn't care, there is nothing special to do.
- Local /var/qmail/ (typical) install for queue, bin, supervise,
etc... possibly taken from the central, backend server via nightly
rsync where needed.
Run a local queue, trust me on this. /var/qmail/control is really all
you need to share, and actually you could get by without it. We found
data in there changes so little it really isn't an advantage having it
on NFS or scripting a solution via rsync.
DAve
- NFS client communication to the central backend server
We use a large MySQL/NFS machine for this here. We have each front-end
server (toaster/ecluster/whatever) connecting to a common MySQL DB. We
also use a self authored management program to modify vpopmail DB entries.
Currently we NFS mount a common directory on each front-end machine.
That directory contains the following; domains, qmail-control, webmail.
We then use symlinks to map the required directories on each front-end
server.
front-end (target) -> NFS (source)
-----------------------------------------------
/home/vpopmail/domains -> /shared/vdomains
/var/qmail/control -> /shared/qmail-control
/usr/local/www -> /shared/webmail
/var/tmp -> /shared/webmail-sessions
Make sure your NFS mount is up and operational before starting qmail.
A single, large server provides the "backend" services to these
machines for:
- MySQL server (for smtp-auth tracking, squirrelmail prefs/abook/sigs,
users, domains)
- NFS Service providing Client-mounted folder(s) for the domains' email.
Any special compile/configuration suggestions to support this that I
wouldn't normally use on a single-box solution? Should the client
machines be logging to their local drives, to an NFS mounted drive, or
log over the network (like syslog-ng, even possible with multilog???)
to any particular host?
We use local logging, I would advise against NFS logging, it was iffy
for us. Never had a need to investigate logging over the network. We
only have three front-end machines so it is easy enough to log into the
offending machines and tail/grep the logs. Headers will always tell you
which machine to investigate.
Any administrative issues that grow through this distributed model?
I'm thinking about whether vqadmin or qmailadmin will continue to
function correctly when run from any of the "farm" machines? Would I
just allow one "admin" machine for vqadmin/qmailadmin to prevent issues?
We use neither.
Any risks of data collision/overlap or other issues that might surface
with this multi-server model? Central MySQL should solve most of
this, right?
THANKS!!!!!
Three years up and running, 50,000 delivered messages a day. No problems
ever with lost mail or failures. Clients still scream "you lost my
message" and I prove them wrong each time, but they still try.
I hope that helps.
DAve
--
Three years now I've asked Google why they don't have a
logo change for Memorial Day. Why do they choose to do logos
for other non-international holidays, but nothing for
Veterans?
Maybe they forgot who made that choice possible.
