How to efficiently manage cron mails with many hosts?

lifepillar

lifepillar

Hello FreeBSD community,
first poster here. I hope my question won't be considered too general or not technical enough. I have currently a dozen jails (and still growing) in my server (FreeBSD 12.1). One jail is a mail server (Dovecot+OpenSMTPD), and each jail is configured to forward cron emails to the mail server (using dma). This setup works smoothly, but since everything in FreeBSD runs fine most of the time, every day (and week, and month) I get many similar pretty boring emails in my mailbox (once in a while I *do* get an interesting message, though—mostly about security vulnerabilities). I am wondering how I could reduce the overhead of such notifications. How do you deal with cron emails? Is some form of “digest” or aggregation possible using some tool? Or do you just suppress cron tasks and monitor your jails differently?
 
It's a good question.
In your case, if the emails you get are boring, then instead of getting emails, suppress them to either /dev/null (inherently bad in some cases) or use a facility like logger.

For example, if you don't want an email about backing up success (a recipe for disaster, I might add), then:
/usr/local/bin/my_backup_script > /dev/null 2>&1

However, if you want to take advantage of syslog, you can log the output to syslog and peruse it:
/usr/local/bin/my_backup_script 2>&1 | logger -t my_backup_script

This way the output is stored somewhere you can look at and not flood you with emails.

You could also write an email handler/parser for use by smrsh, but believe me I've done them, they're complex.
 
What you have here is a contradiction on goals, and insufficient tooling.

One one hand: You are using a general-purpose operating system, which is built to be quite secure. Part of that is auditing and monitoring, and part of that is sending you e-mails that the monitoring is going well. Why is making that OS secure so important? Because a general-purpose OS is designed for a computer that does many many tasks, and a security vulnerability can have wide-ranging effects.

On the other hand: You are actually running a dozen separate "virtual machines" (each jail is in reality a virtual operating system). Each of those VMs is doing one small task only. That is considered goodness, because then a security violation in any one of those is less likely to spread to other VMs.

The contradiction here is: You are using a very heavy-weight solution (a general purpose OS running in each jail) for a light-weight problem. It's like saying that solve all your transportation problems you need a big, heavy, complex vehicle (a minivan with high load capacity, many seats, all wheel drive for off-roading trips, large tank for going long distance, and so on). But then you buy a dozen expensive vehicles like that, and dedicate each only to a tiny task. In this example, you are using a 5-ton $100K machine for going to the store 1km away and pick up a small box of milk. You use the second 5-ton $100K machine to bring your kid to school every morning. A third one for the monthly trip to the vet. A fourth one ... you get the picture.

Where the insufficient tooling comes in: Because FreeBSD is intended to be a general-purpose server OS for individual machines, it has pretty good security protections turned on by default, which includes a heavyweight mechanism for sending security-related e-mails. Which are intended to be read. What it is lacking is automated tooling for distinguishing good news from bad news. In an environment where people deal with one general-purpose OS, that is not so much necessary; in an environment where people are running de-facto server farms, it is.

How do I deal with this? I have no jails (not even chrooting my Apache and Bind servers), and I just read all the mails once a day, takes a minute or two. I don't have a good suggestion other than gritting your teeth and living with it. Bad suggestions include ignoring the mails, or not using jails.
 
My solution:

- Important cron emails are left in my inbox daily
- The rest are moved to a Cron folder by my email client (SeaMonkey) and the folder is set to expire them after 60 days which leaves a long enough trail if I need to check something.
 
ralphbsz said:
What you have here is a contradiction on goals, and insufficient tooling.

[...]
The contradiction here is: You are using a very heavy-weight solution (a general purpose OS running in each jail) for a light-weight problem. It's like saying that solve all your transportation problems you need a big, heavy, complex vehicle (a minivan with high load capacity, many seats, all wheel drive for off-roading trips, large tank for going long distance, and so on). But then you buy a dozen expensive vehicles like that, and dedicate each only to a tiny task. In this example, you are using a 5-ton $100K machine for going to the store 1km away and pick up a small box of milk. You use the second 5-ton $100K machine to bring your kid to school every morning. A third one for the monthly trip to the vet. A fourth one ... you get the picture.
Click to expand...
Good one. This week I started with Docker. I do not like its not-so-logical command syntax, but it's an efficient way to keep things isolated from each other. One container for the SMTP stuff, one for the IMAP thing, one for the web server. And out of the box they all to not send out one single log email. Which is a bit dangerous, I think. So I have to find a way on my own how to keep an eye on the container's logs.
 
You must log in or register to reply here.
Back
Top