Portal:Toolforge/Admin/Exim

From Wikitech

Email maintenance

Currently all mail services run on tools-mail. A few pointers:

Queue Length

Blocking a sender from sending outbound mail

Edit /etc/exim4/deny_senders.list and add the envelope from address that you want to block on a new line.

$ echo 'wiktcapt@tools.wmflabs.org' | sudo -i tee -a /etc/exim4/deny_senders.list
wiktcapt@tools.wmflabs.org
$ sudo -i cat /etc/exim4/deny_senders.list
# Add MAIL FROM address to block. One per line
wiktcapt@tools.wmflabs.org

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.

Failover

  1. Provision new node
  2. Disable Puppet on new node, stop Exim service
  3. Update Hiera key profile::toolforge::active_mail_relay to point to new instance
  4. Run Puppet everywhere
  5. Stop Puppet and Exim on the old node
  6. Swap floating IP to new node
  7. Enable Puppet and Exim service on new node
  8. Decomission old node

See also