Re: [vchkpw] synchronize control files
Hi, Quoting Dave Weiner <[EMAIL PROTECTED]>: > 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 > > > My setup is a little different. I have a private apache process listening on the master server's real ip (I also have virtual ip managed by LVS for the virtual services) on a high port and runs as a normal user and his private group. Something similar to user nobody group nobody, but seperate. This user is not allowed to do, own, read, write anything else. I am developing a web based interface on it using php/mysql and some perl scripts, and some input validation etc (still in early beta) The normal user that the apache process runs as has a exchange ssh keys setup in his ~/.ssh with each of the servers in the cluster, including localhost, so that he can execute commands like: "ssh [EMAIL PROTECTED] ~vpopmail/bin/vadddomain test.com secretpass" _only_ after I validate the client supplied input through the web interface. Execution of such commands are mostly limited to the admin user only. The interface also has multi-tiered authentication system, based on MySQL, with user ACL's and limits per level or per user. Multi-tiered auth basically allows for three types of logins; admin, reseller, client. Each of admin, reseller, and client, can have a different level. For example, an admin of level 100 has full privilges such as config services, monitor cluster, add/remove domains, clients, or resellers. An admin of level 20 is like a helpdesk account who can add/edit domains, but cannot delete domains, or edit domains that have been edited by another admin and locked from changes. Also, accounts can be restricted by IP address. Usually, the admin account should be allowed to connect to the interface from only a specified IP address. My worst fear is of a exploit like the recent SSL v2 vulnerability where an unautheticated user, or an anonymous user, could just simply exploit the apache process, and use it as a step stone. So this is not the most secure either. Ideas?? The interface wraps up tinydns, qmail, vpopmail w/ mysql, courier-imap, apache vhosting (w/ extensions such as php, frontpage etc.), pureftpd w/ mysql, maildrop and spamassassin w/mysql prefs for spam filtering. I am still debating over my final decisions in quota handling. I believe the best option would be operating system enforced quotas (by the nfs file server for example), so I could have a client's account map to a user in the system with no shell, and make his vpop domain and apache vhost directory owned by his account. This is best for security (of apache), and for quota enforcement. (The apache files still have to be owned by group nobody so apache can read them. Trying also to force uploaded files with permissions 750 to protect against other mailicious clients cgi scripts trying to read other users php scripts) Sorry for the overwhelming details and for getting off topic, but such a project has always been my dream, and it just doesn't ex
Re: [vchkpw] synchronize control files
At 07:20 PM 9/21/2003, X-Istence wrote: I have always joyfully added files to my rcpthosts and it has never failed to pick em up on the next incoming SMTP connection. Its always worked just fine, so i dont know. qmail-send and qmail-smtpd are two different programs, with two different behaviors. just read the man pages, it's explained there. Paul Theodoropoulos http://www.anastrophe.com
Re: [vchkpw] synchronize control files
Tim Hasson wrote:
Quoting X-Istence <[EMAIL PROTECTED]>:
As i have tinkered with the source code myself, i dont see why qmail
would have to be restarted. In the qmail source file, it re-reads the
rcpthosts file on every run of it ( qmail-smtpd ), so "hot" adding
shouldnt be a problem at all.
X-Istence
Don't tinker, READ!
daemon1# pwd
/downloads/mail/vpopmail-5.2.1
daemon1# grep qmail-send vpopmail.c
signal_process("qmail-send", SIGHUP);
/* send a HUP signal to qmail-send process to reread control files */
signal_process("qmail-send", SIGHUP);
signal_process("qmail-send", SIGHUP);
daemon1#
Things like that has mislead me in the past, so I am quite anal when it comes
to expressing opinions.
At times when I mention something I am not 100% sure of, I say "Please correct
me if I am wrong", or "I could be wrong".
Also, if I don't have the big-qmail-vpop-picture, I would never make a
conclusion like "[something] shouldn't be a problem, at all".
Respectfully,
Tim Hasson
I have always joyfully added files to my rcpthosts and it has never
failed to pick em up on the next incoming SMTP connection. Its always
worked just fine, so i dont know.
X-Istence
Re: [vchkpw] synchronize control files
Quoting X-Istence <[EMAIL PROTECTED]>:
> As i have tinkered with the source code myself, i dont see why qmail
> would have to be restarted. In the qmail source file, it re-reads the
> rcpthosts file on every run of it ( qmail-smtpd ), so "hot" adding
> shouldnt be a problem at all.
>
> X-Istence
>
>
Don't tinker, READ!
daemon1# pwd
/downloads/mail/vpopmail-5.2.1
daemon1# grep qmail-send vpopmail.c
signal_process("qmail-send", SIGHUP);
/* send a HUP signal to qmail-send process to reread control files */
signal_process("qmail-send", SIGHUP);
signal_process("qmail-send", SIGHUP);
daemon1#
Things like that has mislead me in the past, so I am quite anal when it comes
to expressing opinions.
At times when I mention something I am not 100% sure of, I say "Please correct
me if I am wrong", or "I could be wrong".
Also, if I don't have the big-qmail-vpop-picture, I would never make a
conclusion like "[something] shouldn't be a problem, at all".
Respectfully,
Tim Hasson
Re: [vchkpw] synchronize control files
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
Re: [vchkpw] synchronize control files
Tim Hasson wrote: Hi, Respectfully, Tim Hasson As i have tinkered with the source code myself, i dont see why qmail would have to be restarted. In the qmail source file, it re-reads the rcpthosts file on every run of it ( qmail-smtpd ), so "hot" adding shouldnt be a problem at all. X-Istence
Re: [vchkpw] synchronize control files
Hi, Sorry for CC'ing those who replied on this thread, but I just wanted to note something important, for all who replied on that thread. And since it's been three days since the original post, I wanted to make sure everyone get this. So regarding the sync of control files in a cluster environment, some said they use nfs to share those directories, other recommended using rsync etc. All this is fine except for one thing. qmail-send needs to be restarted (on every server in the cluster running qmail/vpop) to start accepting mail for the newly added domain (to reread control/rcpthosts at least). So I think you cannot just sync those files and expect everything to work as expected. 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. Respectfully, Tim Hasson
Re: [vchkpw] synchronize control files
Hi Jeff, --- Jeff Oliver <[EMAIL PROTECTED]> wrote: > Basically we have n+1 qmail+vpopmail+mysql, each > sharing an NFS datastore for the vpopmail directory. > (and only for that directory) We have a similar setup. What we are doing is sharing the following directories off the NFS server (which also holds our MySQL database): NFS Server-> NFS clients /maildirs -> /home/vpopmail/domains /var/qmail/control -> /var/qmail/control /var/qmail/users -> /var/qmail/users so naturally, all the mail servers are getting the above three directories shared out to them, and any changes on one get automatically reflected in the others. I then have the admin web interface (or shell in, if that's how I wish to do it) into the NFS server, and make the changes on there, which immediately get reflected ont he other servers :-) I hope this helps. Alan Murrell <[EMAIL PROTECTED]> __ Post your free ad now! http://personals.yahoo.ca
Re: [vchkpw] synchronize control files
On Thu, 2003-09-18 at 12:18, Jeff Oliver wrote: > Basically we have n+1 qmail+vpopmail+mysql, each sharing an NFS > datastore for the vpopmail directory. (and only for that directory) ok, cluster. > > > As of now we are using a kludgey way of adding new domains to all > boxes – simply adding the domain once to each box. I think it’s pure > luck that all machines are putting the new domains into the same > directories and getting the same values in assign, morercpthosts etc. > up to now. This can’t be the right way as adding the domain a second > time gives an error about the domain existing, however we do get the > desired benefit of having the domain added to qmails control files and > the box will answer for that domain. rsync is your friend. > > > Is there a documented, proven proper method for adding domains to > multiple machines in this configuration? Should I be sharing the > qmail control files as well/instead? The problem with that is that > some control files are unique to that machine? Creative use of > symlinks? What about the lock files and cdb? rsync is your friend. > > > Any help or suggestions or pointers to the proper docs on cluster > synchronization (which I can’t seem to find but probably haven’t > looked hard enough ;) ) are appreciated. set up an rsync server for the qmail control files and a cronjob that runs every however long that rsyncs the qmail control files. Then, all you have to do is update the 'master' :) -- Jeremy Kitchen Systems Administrator . Inter7 Internet Technologies, Inc. www.inter7.com 866.528.3530 toll free 847.492.0470 int'l 847.492.0632 fax GNUPG key ID: 93BDD6CE
RE: [vchkpw] synchronize control files
The only thing we have come up with is a scripted method (we remotely call the vpopmail binaries anyways). Bascially we do the following... Add the domain... Check that [EMAIL PROTECTED] is a valid mailbox, if it is, then we scp the various files (morercpthosts, rcpthosts, assign, virtualdomains). After they are copied over we MD5 them to make sure they are identical, then run the various apps to update them (qmail-newu, qmail-newmrh). I am positive this isn't the best solution, but the only one we have come up with to date. Tom Walsh
