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 exist. I hope we can go GPL with this soon, after we work out all the security issues. Any ideas/suggestions/comments are good :) Respectfully, Tim Hasson
