著者: Eli 日付: To: 'Erik Zweers', exim-users CC: 題目: RE: [exim] Sharing autoreply once data without using NFS
Erik wrote: > I'm now stuck with how to prevent duplicate vacation
> messages from going out from each individual mail
> server as they see the source address for the first time.
Are the systems on a shared network? If so, are they running SSH and can
they allow each other to SSH in to one another (as in, is that a possibility
for your setup)?
You could use a "condition" in your autoreply transport to ${run ...} a
script that would check a database that it would manage itself (as to what
type of db, I'm not sure if there's one kind that would be better than
another) and then via SSH, push the updated database to the other servers.
You'd have a heck of a time dealing with file locks though.
A better idea is a daemon on each system open to updating a database that
exim can query, and also lets Exim somehow populate it. Each Exim system
would ${run ...} a command to fetch/push data to & from the daemon, which
would maintain an open link to a database file. The client portion on each
system would not only update localhost, but push the update to each remote
system as well, thus maintaining the same data over all systems. Pretty
elaborate, but if you want all systems to maintain data this is about the
only way you can do it without worrying about synchronizing delays between
systems.
I would personally say just use MySQL - that's pretty high on the dependancy
list I would assume though. However it's not entirely unreasonable. Exim
allows for multiple MySQL server definitions that it will use (if first
down, uses second, etc...). You can easily set up MySQL replication among
servers as well. If you really wanted to, set up MySQL on each Exim server,
designate an order of precedence between them all with one being a master
and have it replicate to all children. Updates go to the master server if
it's up which is replicated quickly to the children... You hopefully get the
idea. This is just the type of set-up I will be using eventually, and it's
a set up I currently have for some PowerDNS servers which (although not in
production) seem to work quite well.