while doing routine maintenance on my servers today, I updated EntropyBot (a Limnoria bot for IRC) to use the system Python 3 version instead of the local pyenv based Python 2.x install that has been running for years

with that there shouldn't be any software running on my servers that's using Python 2


routine maintenance for my servers is rebooting for kernel updates

unattended-upgrades lets me know when my servers need rebooting by prefixing the e-mail subject with [reboot required] and I have a specific saved search in my mail client to filter those e-mails

I run a short script that calls ansible to make sure there aren't any other pending upgrades and to do a autoremove on old kernels and then I reboot the servers one by one with the bastion host being the last one to be rebooted

Show thread

also since I'm on this topic, unattended-upgrades can actually do the autoremove part automatically

from /etc/apt/apt.conf.d/50unattended-upgrades

Unattended-Upgrade::Remove-Unused-Dependencies "true";

I push a copy of this file on server deployment with that change and also set the e-mail address to send mail to

Show thread

unattended-upgrades can also reboot your machine automatically without confirmation at a specific time but that option is not enabled by default obviously

and enabling that is entirely dependent on your situation and environment

Show thread

the Linode guide on monitoring and maintaining your server has this bit:

"There are ways to automate the installation of software updates, but this is not recommended. You should always manually review the lists of available patches before installing updates."

I disagree. This is how you end up with servers that are years behind on critical security updates. If you are using a stable and long term distro on a server (as you should) you should be using something like unattended-upgrades.

Show thread

On a Ubuntu LTS release most of the time package updates are fixes for security vulnerabilities and very rarely cause any sort of regressions.

I don't see much reason to hold those updates up for manual review until you have extremely strict change management rules in place, in which case I hope you have a priority process for security vulnerabilities in particular.

Show thread

Lean on and trust the good work distro maintainers already do for you instead of creating more unnecessary busywork for yourself.

Show thread

the other problem with that advice from the Linode guide is that it is targeted at beginner sysadmins and those are the kind of people who are almost definitely not qualified to be reading and understanding patches and checking diffs to review security updates for potential regressions

that's not meant to be an insult, that's not a skill you can expect to be all that common even amongst seasoned sysadmins

hell that's not something I can reasonably do either

Show thread

@packetcat Agreed.

Weirdly enough, speaking of Ubuntu 20.04...

I have one VM that I'm testing the upgrade on, and weirdly enough, after about half a day after boot, it seems to "lose" its IPv4 address? I can't remote into it via SSH anymore, and have to use virt-manager to see its console and yep: no IPv4 address when I run ifconfig.

Heard about this weird issue yet?

@mdm I've seen that before on a 18.04 system that used netplan + systemd-networkd

might be a similar bug

are you using DHCP or a static config?

might be worth using NetworkManager with netplan instead to avoid that issue



@packetcat DHCP (it's a static IP assigned by the AP, though, but I don't think the VM would know that, right?).

@mdm right, the VM wouldn't know the difference between a static lease and a dynamic one

its most likely a bug with the DHCP implementation in systemd-networkd, failing at DHCP renewal probably or some other similar issue

@packetcat Ooh -- that sounds like something I need to report to a bugtracker. :D

Glad I tested this, this time, before the 20.04.1 update came out.

Sign in to participate in the conversation
McNamarii Town

This is a private mastodon server for members of the Team McNamara Group.