In order to monitor some of the machines I maintain, I rely on a simple email setup using logcheck. Unfortunately that system completely breaks down if mail delivery stops.
This is the simple setup I've come up with to ensure that mail doesn't pile up on the remote machine.
Server setup
The first thing I did on the server-side is to follow Sean Whitton's advice and configure postfix so that it keeps undelivered emails for 10 days (instead of 5 days, the default):
postconf -e maximal_queue_lifetime=10d
Then I created a new user:
adduser mailq-check
with a password straight out of pwgen -s 32
.
I gave ssh permission to that user:
adduser mailq-check sshuser
and then authorized my new ssh key (see next section):
sudo -u mailq-check -i
mkdir ~/.ssh/
cat - > ~/.ssh/authorized_keys
Then I added restrict,command="/usr/bin/mailq"
to the authorized_keys
entry so that
it looks like this:
restrict,command="/usr/bin/mailq" ssh-ed25519 AAAAC3N... francois@machine
This means that this account cannot use any of the powerful ssh features like port forwarding and is limited to running a single command.
If your server also allows users to login using GDM,
then you'll probably want to hide that user from the list of available
users by putting the following in /var/lib/AccountsService/users/mailq-check
:
[User]
XSession=
SystemAccount=true
Laptop setup
On my laptop, the machine from where I monitor the server's mail queue, I first created a new password-less ssh key:
ssh-keygen -t ed25519 -f .ssh/egilsstadir-mailq-check
cat ~/.ssh/egilsstadir-mailq-check.pub
which I then installed on the server.
Then I added this cronjob in /etc/cron.d/egilsstadir-mailq-check
:
0 2 * * * francois /usr/bin/ssh -o ClearAllForwardings=yes -i /home/francois/.ssh/egilsstadir-mailq-check mailq-check@egilsstadir mailq | grep -v "Mail queue is empty"
and that's it. I get a (locally delivered) email whenever the mail queue on the server is non-empty.
The ClearAllForwardings
option is there to disable any LocalForward
you
may have set in ~/.ssh/config
and which could cause this cron job to fail
if you are already logged into that machine (and therefore using up the
local port).
There is a race condition built into this setup since it's possible that the server will want to send an email at 2am. However, all that does is send a spurious warning email in that case and so it's a pretty small price to pay for a dirt simple setup that's unlikely to break.
As part of regular operating system hygiene, I run a cron job which updates package metadata and looks for obsolete packages and configuration files.
While there is already some easily available information on how to purge unneeded or obsolete packages and how to clean up config files properly in maintainer scripts, the guidance on how to delete obsolete config files is not easy to find and somewhat incomplete.
These are the obsolete conffiles I started with:
$ dpkg-query -W -f='${Conffiles}\n' | grep 'obsolete$'
/etc/apparmor.d/abstractions/evince ae2a1e8cf5a7577239e89435a6ceb469 obsolete
/etc/apparmor.d/tunables/ntpd 5519e4c01535818cb26f2ef9e527f191 obsolete
/etc/apparmor.d/usr.bin.evince 08a12a7e468e1a70a86555e0070a7167 obsolete
/etc/apparmor.d/usr.sbin.ntpd a00aa055d1a5feff414bacc89b8c9f6e obsolete
/etc/bash_completion.d/initramfs-tools 7eeb7184772f3658e7cf446945c096b1 obsolete
/etc/bash_completion.d/insserv 32975fe14795d6fce1408d5fd22747fd obsolete
/etc/dbus-1/system.d/com.redhat.NewPrinterNotification.conf 8df3896101328880517f530c11fff877 obsolete
/etc/dbus-1/system.d/com.redhat.PrinterDriversInstaller.conf d81013f5bfeece9858706aed938e16bb obsolete
To get rid of the /etc/bash_completion.d/
files, I first determined what
packages they were registered to:
$ dpkg -S /etc/bash_completion.d/initramfs-tools
initramfs-tools: /etc/bash_completion.d/initramfs-tools
$ dpkg -S /etc/bash_completion.d/insserv
initramfs-tools: /etc/bash_completion.d/insserv
and then did the following based on Paul Wise's instructions and this StackExchange answer:
$ rm /etc/bash_completion.d/initramfs-tools /etc/bash_completion.d/insserv
$ apt-get -o Dpkg::Options::="--force-confmiss" install --reinstall initramfs-tools insserv
For some reason that didn't work for the /etc/dbus-1/system.d/
files
and I had to purge and reinstall the relevant package:
$ dpkg -S /etc/dbus-1/system.d/com.redhat.NewPrinterNotification.conf
system-config-printer-common: /etc/dbus-1/system.d/com.redhat.NewPrinterNotification.conf
$ dpkg -S /etc/dbus-1/system.d/com.redhat.PrinterDriversInstaller.conf
system-config-printer-common: /etc/dbus-1/system.d/com.redhat.PrinterDriversInstaller.conf
$ apt purge system-config-printer-common
$ apt install system-config-printer
The files in /etc/apparmor.d/
were even more complicated to deal with
because purging the packages that they come from didn't help:
$ dpkg -S /etc/apparmor.d/abstractions/evince
evince: /etc/apparmor.d/abstractions/evince
$ apt purge evince
$ dpkg-query -W -f='${Conffiles}\n' | grep 'obsolete$'
/etc/apparmor.d/abstractions/evince ae2a1e8cf5a7577239e89435a6ceb469 obsolete
/etc/apparmor.d/usr.bin.evince 08a12a7e468e1a70a86555e0070a7167 obsolete
I was however able to get rid of them by also purging the apparmor profile packages that are installed on my machine:
$ apt purge apparmor-profiles apparmor-profiles-extra evince ntp
$ apt install apparmor-profiles apparmor-profiles-extra evince ntp
Not sure why I had to do this but I suspect that these files used to be
shipped by one of the apparmor packages and then eventually migrated to the
evince
and ntp
packages directly and dpkg got confused.
If you're in a similar circumstance, you want want to search for the file you're trying to get rid of on Google and then you might end up on http://apt-browse.org/ which could lead you to the old package that used to own this file.