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 > control/rcpthosts. > 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. > > Respectfully, > Tim Hasson -- Dave Weiner Partner Coyote Technical Services, LLC
