howdy all-
i got a private email from someone asking for more detail about setting up
clusters of qmail machines to work together. i want to respect this
person's privacy- he asked the question privately rather than through a
list. however, i think the answer should be shared with the world, so to
protect this person's identity i'm cutting out his name and such. enjoy.
On Mon, 27 Dec 1999, [someone] wrote:
> 1. When we host & DNS a domain, and we want to mail seomeone that has their
> own mailserver, we need a virtualusertable entry that says:
> @domain.com [EMAIL PROTECTED] ( we do point dns to send mx records to
> mail.domain.com.... How would qmail deliver and e-mail sent by someone within
> ? would we need a special config as above under sendmail ?
it sounds like you're trying to force all of the domain's mail to come
through your servers. the only reasons i can think of to do this would be:
- you have a kick-ass spam filtering system on your mailhub and want to
have your client use it (in which case i want a copy, that's the one thing
i could never get "maildrop" to do for me, a text-search on every message
to be received regardless of who it's for...) (hint, hint, if the maildrop
guy is on one of these lists, i don't remember your name right now...)
- your client doesn't want the entire world to connect to his mail server,
and has an IP access list which allows only your server(s) to connect.
this could be because they don't want to be an open relay but their
brain-dead mail server program can't be configured that way. (you also
need to set up a packet filter in your routers or terminal servers to make
this work for relay prevention...)
- you are providing ETRN service for a non-dedicated client
anyway, to set this up (so their mail is forced into your servers and your
server then hands it to them) ...
DNS contains records like this, as needed...
client.com IN MX 1 mailhub1.isp.com.
client.com IN MX 2 mailhub2.isp.com.
/var/qmail/control/rcpthosts (or morercpthosts.cdb) contains
client.com
/var/qmail/control/smtproutes contains (note that their mail server must
have a static ip in order for mail to be delivered to them)
client.com:12.34.56.78
if, on the other had, you want to offer the services of your mailhubs as
just a backup when the client's connection goes down, you set it up like
this (and the client would allow incoming connections from anywhere in the
world)
DNS contains:
client.com IN MX 1 mail.client.com.
client.com IN MX 2 mailhub1.isp.com.
client.com IN MX 3 mailhub2.isp.com.
/var/qmail/control/rcpthosts (or morercpthosts.cdb) contains
client.com
note that setting the MX records this way and having the client set up an
IP restriction list will still accomplish the goal of sending all of their
mail through your servers, but time would be wasted on every message while
the sending server tries first to contact your client's mail server
directly and times out before sending it to your (the ISP's) mail server.
it works but it's less than optimal (and to some that's just as bad as not
working at all.)
> 2. We also want to provide redundant mail service for our clients mail
> servers, and so we want to use etrn to accomplish this, but it seems like
> nobody is doing this under qmail...any ideas ?
long ago i found a patch for ETRN on the qmail.org
mega-page-of-doom(tm)... it works, although i added a few syslog() lines
to it myself so i could tell when it was working and not working. i also
added a line that checks to see if the first character of the domain name
being asked for is "@", and if so it skips the "@" before checking the
control/etrn file. this is because some versions of microsoft exchange
server add an "@" sign to the domain name- not standard ETRN but that's
microsoft for you...
however, i just went and looked at qmail.org again, and it's not there
anymore. (does anyone know why? was there a security hole that i didn't
hear about, do i need to call my old office and tell them about it?)
anyway, i don't have the patch anymore, but there are programs called
"turnmail" and "pullmail" (for unix and NT, respectively) that can be used
to simulate the results of ETRN functionality. i have no experience with
either of them.
i don't have the source file anymore (i don't work for the isp anymore)
but the changes were trivial.
> Also in your redundant solution for mailservers, I agree with the nfs issues
> you bring up, but how often were you ssh coping the files back & forth ? were
> you using rsyc with ssh protocol or is there an update parameter on scp ?
just to clarify, it's only the qmail control files that get copied, no
messages.
the copies were being done several times a day, basically every time a new
domain was added to the virtual mail server. we were using regular old
"scp" without worrying about any "update" parameters- if the master had
new config files, it was guaranteed that the slave needed them so we went
right ahead and overwrote what was on the slave machine. (and we weren't
overwriting the live qmail control directory, so there were no issues
there.)
we ran "scp" and "ssh" using the "-i" parameter and an ssh key pair which
was only used for updating qmail config files. details on how to set up
such a beast follow...
before starting this, you should be familiar with ssh and friends, as well
as file permissions, shell scripts, setuid wrappers, and most importantly
your own servers.
- on the master server, create a key pair using "ssh-keygen -f blah". DO
NOT ENTER A PASSPHRASE FOR THIS KEY PAIR. it will create two files. the
file "blah" is the SECRET half of the key, and "blah.pub" is the PUBLIC
half of the key. "mv" the secret half to somewhere safe, and set the
ownership and permissions so that it's safe (i.e. owned by root, chmod
0400, in a root-owned directory that's chmod 0700, etc.) I CANNOT STRESS
STRONGLY ENOUGH THE NEED FOR SECURITY OF THIS SECRET-KEY FILE! if someone
gets a copy of it, knows what it is and how to use it, they could totally
screw up the qmail control files on your slave machines. you may want to
rotate the key files once a week or once a month, and you definitely don't
want to use this key pair for anything else.
- on each slave server, create a new group-id (in /etc/group) called
"update" or something similar.
- on each slave server, create an account (userid "update" or something
like that) on each "slave" server. the user's group id in /etc/passwd
should be the same as the numeric id of the group you just created. the
password doesn't matter, you're about to throw it out anyway.
you then need to invalidate the password: in /etc/passwd or /etc/shadow,
manually replace the encrypted password with "ZZ@@@@@@@@@@@" or something
similar- it needs to contain at least one character other than letters,
digits, period, and forward slash, but not "*" or "!" since those are
magic characters for some authentication libraries.
- copy the public half of the key pair to the file ".ssh/authorized_keys"
in the user's home directory. make this file owned by the user and chmod
0400.
- write a shell script in the user's home directory to copy any qmail
config files you will be updating from the user's home directory to
/var/qmail/control. it would look something like this...
#!/bin/sh
PATH="/bin:/usr/bin:/usr/local/bin:/var/qmail/bin"
cd /home/update
cp morercpthosts virtualdomains smtproutes etrn /var/qmail/control/
chmod 755 /var/qmail/control
chmod 644 /var/qmail/control/*
qmail-newmrh
/etc/rc.d/init.d/qmail restart
the shell script itself should be owned by root and chmod 0700. the script
should either explicitly set its own path or manually specify full
pathnames for all programs (i.e. "/bin/cp" etc.) you should test the
script by running it as root.
- write a specific setuid-root wrapper (feel free to use the attached
"wrapper.c" as a guide, it compiles very small because it doesn't use any
libc functions, just syscalls) which will only run the shell script you
have just written. compile the program, give it a name (like "update"),
make the executable owned by root, set the group id to the group you
created above, and set the permissions to "chmod 4710". this will make it
setuid-root, with only members of the update group (i.e. only the update
user) able to actually run it.
- on the master machine, generate the new files as they should appear on
the slave server(s). copy the file(s) over with something like this:
scp -i /root/.ssh/update.identity configfile [EMAIL PROTECTED]:
note that you can have multiple filenames on the command line, as long
as the last thing is the "userid@machine:" with the colon.
then, you need to tell the slave to actually update the "live" config
files, like so:
ssh -i /root/.ssh/update.identity -l update slaveserver.isp.com ./update
> My suggestion was to use an ethernet based hard drive, which is remotely
> mounted not sure wich technology they use, but that way an actual system would
> not be responsible for the shared drive...
hrmmm... like a netapp. we tried one and ran into a few problems...
- they're hideously expensive, starting about $40K for a basic 18GB unit
- they depend on your ethernet. unless you're planning on installing a
100-Base-T private ethernet segment (with a second ethernet card in each
machine and a 100-Base-T switch, not hub) you're going to do a better job
of flooding your own network than any twisted hacker punk could do. these
suckers will use a LOT of bandwidth, because if you buy one and you're
smaller than someone like earthlink, you're going to want to use it for
more than just email. been there, done that, spent almost $6000 of the
company's money upgrading switches.
- did i mention they're horrendously expensive?
> Happy Y2K!
ugh... i'll be SO happy next week when this is all over...
take care all.
----------------------------------------------------------------
| John Simpson | http://www.depeche.mode.net/~jms1/ |
| Programmer At Large | <[EMAIL PROTECTED]> |
----------------------------------------------------------------
| It all seems so stupid, it makes me want to give up. |
| But why should I give up when it all seems so stupid? |
----------------------------------------------------------------
/* wrapper.c
[EMAIL PROTECTED] 1997-11-20
general-purpose setuid wrapper
header files etc. written for unix, compiles ok on solaris 2.6
set program base name in #define PROG
set parameters (if any) in ma[]
(make sure to adjust the size of ma[] to hold your parameters)
*/
#include <sys/types.h>
#include <unistd.h>
#define PROG "/usr/sbin/ndc"
int main ( int argc , char *argv[] )
{
char *ma[3] ;
if ( setuid ( 0 ) )
{
perror ( "setuid" ) ;
return 1 ;
}
if ( seteuid ( 0 ) )
{
perror ( "seteuid" ) ;
return 1 ;
}
ma[0] = PROG ;
ma[1] = "restart" ;
ma[2] = 0 ;
execv ( PROG , ma ) ;
perror ( "execv" ) ;
return 1 ;
}
