Differences between revisions 1 and 4 (spanning 3 versions)
Revision 1 as of 2008-06-19 03:12:36
Size: 3036
Editor: ?smarenka
Comment:
Revision 4 as of 2008-06-19 14:14:56
Size: 5220
Editor: ?smarenka
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
The buildd account needs to be able to send and receive email. This page has some configuration ideas if the stock email solution does not work for your situation. The ["M68k/Buildd"] account needs to be able to send and receive email. This page has some configuration ideas if the stock email solution does not work for your situation.
Line 4: Line 4:
  * [#procmail procmail]   * [#procmail buildd procmail] recipe
Line 19: Line 19:
Replace $server with the name of the mail server (I usually use the common name). Replace $client with the name of the mail client (this is like a user account). Replace $password with some password (i.e., makepasswd). Replace $server with the hostname of the mail server (server=$(hostname)). $client needs to be distinguishable from $server, so I use the client hostname plus "in" (e.g., client=$(hostname)in). Replace $password with some password (i.e., makepasswd).
Line 84: Line 84:
{{{ working through here }}} Note that you have to run through the above configuration twice (each host is both client and server) if you're going to pass mail both directions on demand (i.e., immediately when available).
Line 86: Line 86:
On the client you should su uucp and ssh to $server to make sure the key
works. You'll get a uucp prompt.
To make sure everything is now working.
Line 91: Line 90:
You'll want a cronjob that calls "/usr/lib/uucp/uucico -C -S$server"
periodically.
You should get a uucp Login prompt, which you can then Control-C out of.
Line 94: Line 92:
You can also setup your mta to make that call whenever mail is pending
if you'd prefer. Something about
        uux -r -n -z -a$sender - $nexthop!rmail ($recipient)
I believe.
If you're using postfix.
== Sending ==
Line 100: Line 94:
 /etc/postfix/transport
        $server uucp:$server
You may want a cronjob that calls "/usr/lib/uucp/uucico -C -S$server" periodically. I use this method of machines that are only occasionally connected to the internet.
Line 103: Line 96:
And I think that's about it. I'm happy to help debug if needed. You can also setup your mta to make that call whenever mail is pending. uux is your friend here. If you're using postfix you do that with the following. Note that the only change between the following and the Debian default is removing '-r' from the uux command. If you want to transfer mail outside of mta control (say, under cron or whatever), leave the {{{uux -r}}}.

{{{
/etc/postfix/master.cf:
uucp unix - n n - - pipe
  flags=Fqhu user=uucp argv=uux -n -z -a$sender - $nexthop!rmail ($recipient)
}}}

I also use postfix transport_maps.
{{{
/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport
}}}

The following asterisk may be replaced with just a servername if you only want to route some mail over uucp.
{{{
/etc/postfix/transport:
* uucp:$server
}}}
Do not forget to {{{postmap /etc/postfix/transport}}} after you are done.

[[Anchor(procmail)]]
= Buildd Procmail Recipe =

The buildd account really only care about certain formatted messages. Everything else is spam to it. Since many of my buildds are hidden behind a mail gateway, I map an account on the mail server and use a procmail recipe to filter out invalid mail before it ever goes to the buildd. Substitute $BUILDDMAIL with the real delivery address for the buildd account.

{{{
.procmailrc:# Set to yes when debugging
#VERBOSE=yes

# Remove ## when debugging; set to no if you want minimal logging
## LOGABSTRACT=all

# Directory for storing procmail-related files
PMDIR=$HOME/.procmail.d

# Put ## before LOGFILE if you want no logging (not recommended)
LOGFILE=$PMDIR/log

MAILDIR=$HOME/Mail

SPAMBOX="spambox/"

DEFAULT=$SPAMBOX

# excerpted from buildd-mail
:0
* ^Subject: Re: Log for .* build of |\
  ^Subject: Re: Should I build |\
  ^Subject: Processing of |\
  ^Subject: .*changes INSTALL|\
  ^Subject: .*changes ACCEPTED|\
  ^Subject: new version of
! $BUILDDMAIL

# maybe you want a copy of all spam sent to the admin
#:0 c
#! $BUILDDADMINEMAIL
}}}

If you are using a log file like the above, you may wish to periodically roll it with
{{{savelog -p $HOME/.procmail.d/log >/dev/null}}} or logrotate.

The ["M68k/Buildd"] account needs to be able to send and receive email. This page has some configuration ideas if the stock email solution does not work for your situation.

  • [#uucp uucp over ssh] notes
  • [#procmail buildd procmail] recipe

?Anchor(uucp)

uucp over ssh

Sometimes the solution to a problem such as routing email is to go old school. You can deliver email using uucp over ssh. Hopefully someone will document something a little newer, but for now, this works.

Install uucp on both the client and server apt-get install uucp. You can setup both the client and the server to transfer mail on demand or by polling. This faq is going to cover push/push (both machines act as clients and servers). This works pretty well for buildds because they usually already have a working ssh client and server.

Client

You will need to generate a password-less ssh key for uucp.

sudo -u uucp ssh-keygen

Replace $server with the hostname of the mail server (server=$(hostname)). $client needs to be distinguishable from $server, so I use the client hostname plus "in" (e.g., client=$(hostname)in). Replace $password with some password (i.e., makepasswd).

Think of this as what username ($client) and $password to use when contacting $server.

/etc/uucp/call:
$server $client $password

Tell uucp to use ssh.

/etc/uucp/port:
port sshport
type pipe
command /usr/bin/ssh -x -o batchmode=yes $server

/etc/uucp/sys:
system $server
call-login *
call-password *
time any
address $server
port sshport
protocol t
remote-send /var/spool/uucppublic
remote-receive /var/spool/uucppublic

Optionally map the common name you are using for the server to the fully qualified domain name.

/var/spool/uucp/.ssh/config:
Host $server
    Hostname $server.example.com

Server

$server, $client, and $password should match as appropriate from the client.

/etc/uucp/passwd:
$client $password

Allow the client to use the system.

/etc/uucp/sys:
system $client
time any
port tcp
protocol t
remote-send /var/spool/uucppublic
remote-receive /var/spool/uucppublic
commands        rmail rnews rbsmtp rsmtp cbsmtp rcsmtp rgsmtp

You will need /var/spool/uucp/.ssh/id_rsa.pub from the client.

/var/spool/uucp/.ssh/authorized_keys:
command="/usr/lib/uucp/uucico -l" ssh-rsa uucp_public_key uucp@client

Preparation and Testing

Note that you have to run through the above configuration twice (each host is both client and server) if you're going to pass mail both directions on demand (i.e., immediately when available).

To make sure everything is now working.

sudo -u uucp ssh $server

You should get a uucp Login prompt, which you can then Control-C out of.

Sending

You may want a cronjob that calls "/usr/lib/uucp/uucico -C -S$server" periodically. I use this method of machines that are only occasionally connected to the internet.

You can also setup your mta to make that call whenever mail is pending. uux is your friend here. If you're using postfix you do that with the following. Note that the only change between the following and the Debian default is removing '-r' from the uux command. If you want to transfer mail outside of mta control (say, under cron or whatever), leave the uux -r.

/etc/postfix/master.cf:
uucp      unix  -       n       n       -       -       pipe
  flags=Fqhu user=uucp argv=uux -n -z -a$sender - $nexthop!rmail ($recipient)

I also use postfix transport_maps.

/etc/postfix/main.cf:
transport_maps = hash:/etc/postfix/transport

The following asterisk may be replaced with just a servername if you only want to route some mail over uucp.

/etc/postfix/transport:
* uucp:$server

Do not forget to postmap /etc/postfix/transport after you are done.

?Anchor(procmail)

Buildd Procmail Recipe

The buildd account really only care about certain formatted messages. Everything else is spam to it. Since many of my buildds are hidden behind a mail gateway, I map an account on the mail server and use a procmail recipe to filter out invalid mail before it ever goes to the buildd. Substitute $BUILDDMAIL with the real delivery address for the buildd account.

.procmailrc:# Set to yes when debugging
#VERBOSE=yes

# Remove ## when debugging; set to no if you want minimal logging
## LOGABSTRACT=all

# Directory for storing procmail-related files
PMDIR=$HOME/.procmail.d

# Put ## before LOGFILE if you want no logging (not recommended)
LOGFILE=$PMDIR/log

MAILDIR=$HOME/Mail

SPAMBOX="spambox/"

DEFAULT=$SPAMBOX

# excerpted from buildd-mail
:0
* ^Subject: Re: Log for .* build of |\
  ^Subject: Re: Should I build |\
  ^Subject: Processing of |\
  ^Subject: .*changes INSTALL|\
  ^Subject: .*changes ACCEPTED|\
  ^Subject: new version of
! $BUILDDMAIL

# maybe you want a copy of all spam sent to the admin
#:0 c
#! $BUILDDADMINEMAIL

If you are using a log file like the above, you may wish to periodically roll it with savelog -p $HOME/.procmail.d/log >/dev/null or logrotate.