Currently all mail services run on
tools-mail. A few pointers:
- Exim is hard. This documentation is not: http://bradthemad.org/tech/notes/exim_cheatsheet.php
- Most relevantly:
exim -q -vto manually run over the queue once
- Log files are in
Blocking a sender from sending outbound mail
/etc/exim4/deny_senders.list and add the envelope from address that you want to block on a new line.
$ echo 'firstname.lastname@example.org' | sudo -i tee -a /etc/exim4/deny_senders.list
$ sudo -i cat /etc/exim4/deny_senders.list
# Add MAIL FROM address to block. One per line
Stopping all in/outbound mail
If an incident seems to be occurring, be safe and stop exim before you spend a lot of time digging into the root cause. Having our MX address put on a blacklist for spamming is worse than some downtime.
$ sudo -i puppet agent --disable "Investigating exim incident -- $USER"
$ sudo -i puppet agent -tv # Check to see that Puppet is actually disabled
$ sudo -i service exim4 stop
$ ps axuww | grep exim # Did it really stop?
Now you can proceed to investigate the queue without more messages going in or out. SMTP is robust to network segmentation so even leaving things down for a few hours is not a huge problem. Messages will be delivered eventually.
Exim runs as a queue on each exec node
Each exec node (and most other hosts actually) run a local copy of exim that queues messages for outbound delivery via the
tools-mail smarthost. Even if you have purged the queue on the smarthost before restarting exim following an incident, there may be messages queued across the grid ready to flood in as soon as the service is back online.
- Provision new node
- Disable Puppet on new node, stop Exim service
- Update Hiera key
profile::toolforge::active_mail_relayto point to new instance
- Run Puppet everywhere
- Stop Puppet and Exim on the old node
- Swap floating IP to new node
- Enable Puppet and Exim service on new node
- Decomission old node