On Sunday 21 September 2003 08:35 pm, Tim Hasson wrote:
> I recall a old problem from the days of vpopmail 4.9.x which was a bug in
> vadddomain not sending a HUP signal to qmail-send to tell it to reread
> The problem manifested itself when a new domain is added, then you try to
> send a message to a mailbox at that domain, qmail typically refused the
> delivery saying something like:
> "Although I am listed as best preference MX for this domain, it's not
> listed in my rcpthosts", or similar.
> Suppose you did ./vadddomain on one of the cluster servers running
> qmail/vpop. Sure if you use NFS, the changes will show from any of the
> servers running the NFS client. However, only the server which you ran
> vadddomain on will have it's qmail-send restarted and it will be the only
> one that will receive mail for that domain. The others will not untill
> qmail-send is restarted, or the server is rebooted.
What I did (back in the 4.5 tree, I believe), was to write a little shell
script that would do a svc -h /service/qmail. Then, using daemontools and
tcpserver, I setup it up to listen on a unused port and to only accept
connections from my "master" server. The script would return either a "OK"
or "FAIL", and all I had to do from the master server was telnet on that port
to each of the other servers in the cluster.
You could also setup a ssh key for root on the master box, and setup the other
boxes in the cluster to allow root to log in using a key and no password, and
just write a little wrapper script around vadddomain that calls vadddomain,
the ssh's to each of the other boxes in the cluster and does the svc -h
/service/qmail. Just make sure you set it up on each of the boxes that root
can only ssh in from the master server. However, that's more of a hole than
the daemontools/tcpserver solution.
> Tim Hasson
Coyote Technical Services, LLC