Maintenance: reboot your relay(s) for new LTS kernels

Chatmail Relays
,
1

Hi all, my intended audience here is all the awesome people who are adding relays but (based on me reading comments) maybe not Linux professionals or live and breathe this stuff. (I’m a retired Linux systems nerd fwiw)

We’re in one of those ugly timelines in history where a swath of kernel vulnerabilities resulting in root access have been uncovered (search “CopyFail”, there have been variants with other names) and rock stable distributions like Debian 12 LTS are having to release more kernels more frequently than is normal. Most of the time they are a “once in awhile” thing on Debian stable LTS servers.

We have seen multiple kernel upgrades in a very (very very for Debian) short time, another one just rolled out. The 5 second no-tools way to know if you need to reboot is easy:

uname -a
ls -latr /boot

Is the version from the first command, including all the dashes, lower than the second sitting on disk? You have a new kernel and need to reboot. Now add tools to make this nicer. :slight_smile:

Are you vulnerable, how important is this, etc. - that answer always depends on the details of the server you put together, hard to answer without details. Everyone involved in this world is trying to solve all these issues, your (our) role is to apply their fixes to do your best to simply not be vulnerable.

An ounce of prevention is worth a pound of cure, as the old adage goes. Unattended Upgrades does all the hard work, you just need to reboot to activate.

2

Thanks for noting. Note that most recent vulnerabilities were affecting multi-user systems, while a chatmail server is usually only accessed by the admin.

Anyway, a valid workaround would to invoke shutdown -r +60 "scheduled" via /etc/cron.daily. If you wanted to be fancy, you may hook it up conditionally:

3

Quick note on the above, the Chatmail deployment sets the systemd journal to 3 days volatile (in memory only), a nightly reboot may result in losing some logs you may have otherwise wanted for a day or two for normal system debugging.

(if going this route, a standard drop-in override can adjust the logging to your preferences, for example maybe log to disk but set retention to 1 or 2 days could be an adjustment)