Unsurprisingly, I've been lax in maintaining things around here. Debian 13 was released quite a while ago and it has been a couple of years since I did any big updates on the server. My previous experience was good so I didn't spend long planning for this one.
The release
notes call out a few things of note for the upgrade from 12 but
it all seemed inconsequential for what I'm running or how things are
configured (OpenSSH changes around DSA for example don't matter to
me personally). I backed up some configuration files
to my remote backups server
and fired off the apt full-upgrade and it was a few
seconds of downloads followed by a few minutes of
installation. Possibly as a result of my continued quest toward
simplification I only had two packages with configuration file
changes from their package defaults (lighttpd and
openssh). Reviewing the changes took a few moments and then it was
time for a reboot which had the site down for under a minute.
A few years ago I installed performance copilot for metrics tracking when I saw it was suggested as part of cockpit. It ran without issue but I never did much with it because much like my own rudimentary metrics system it turns out I don't really stare at metrics dashboards much unless I'm paid to. My goals are not to produce charts but to make sure things are still working. Metrics don't seem to help me much in that regard and instead I do better by trying to hone the system down to something that is predisposed to not fail. This isn't a slight on performance copilot so much as my own inattention to things. It has been very low on my list of priorities to uninstall performance copilot for ages but because it was still working and only unused I never really seemed to get around to it.
It seems Debian 13 restructured some packages such that the
former cockpit-pcp package was made a virtual package
supplied by cockpit-bridge. As a result my prior
installation of pcp was orphaned and subject to
autoremoval. In some cases this might be an annoyance because I
would have to instead go mark the package to not remove it
but for me I happen to want the change and have simply been too lazy
to do it myself.
The result of this lingering package removal is that post-upgrade
the system is quietly humming along with an even more limited scope
of processes and continuing to serve traffic without issue. It is
probably a ridiculous goal but one of the things I think of
fondly about OpenBSD
is the very limited set of things that run on a working system
unless you specifically tell them to. Browsing top
post-upgrade and I am pretty comfortable with the list of processes
and my knowledge of what they are there for:
1:Def - 18:13:18 up 10:01, 1 user, load average: 0.00, 0.00, 0.00 Tasks: 97 total, 1 running, 96 sleeping, 0 stopped, 0 zombie %Cpu0 : 0.0 us, 0.5 sy, 0.0 ni, 99.2 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st MiB Mem : 464.7 total, 18.9 free, 203.3 used, 260.3 buff/cache MiB Swap: 0.0 total, 0.0 free, 0.0 used. 261.4 avail Mem 1 PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 1 root 20 23.7m 14.5m 10.4m S 3.1 0:04.40 systemd 276 root 20 65.8m 32.8m 31.4m S 7.1 0:05.84 `- systemd-journal 321 systemd+ 20 90.1m 7.9m 6.7m S 1.7 0:00.26 `- systemd-timesyn 327 root 20 32.8m 9.9m 7.2m S 2.1 0:00.21 `- systemd-udevd 574 root 20 7.1m 2.6m 2.3m S 0.5 0:00.12 `- cron 575 message+ 20 8.9m 4.9m 3.6m S 1.1 0:00.41 `- dbus-daemon 578 polkitd 20 301.0m 8.5m 6.2m S 1.8 0:01.01 `- polkitd 579 root 20 214.6m 4.4m 3.0m S 0.9 0:01.27 `- rsyslogd 580 root 20 18.6m 9.0m 7.8m S 1.9 0:00.21 `- systemd-logind 582 root 20 394.8m 10.1m 8.0m S 2.2 0:00.66 `- udisksd 583 daemon 20 3.8m 2.2m 2.1m S 0.5 0:00.01 `- atd 603 root 20 17.1m 5.0m 4.0m S 1.1 0:00.29 `- wpa_supplicant 621 root 20 381.8m 8.8m 6.9m S 1.9 0:00.10 `- ModemManager 623 root 20 132.6m 43.2m 17.4m S 9.3 0:00.70 `- firewalld 670 root 20 328.8m 14.1m 11.3m S 3.0 0:00.20 `- NetworkManager 673 systemd+ 20 20.8m 10.4m 8.9m S 2.2 0:00.26 `- systemd-network 694 root 20 5.8m 2.4m 1.5m S 0.5 `- dhclient 777 root 20 118.2m 28.2m 14.8m S 6.1 0:00.19 `- unattended-upgr 788 root 20 40.8m 12.5m 8.6m S 2.7 0:00.22 `- haproxy 1011 haproxy 20 109.6m 44.6m 6.8m S 9.6 0:03.40 `- haproxy 798 root 20 11.7m 7.7m 6.4m S 1.7 0:12.85 `- sshd 10370 root 20 19.7m 13.0m 10.8m S 2.8 0:00.02 `- sshd-session 10401 nolan 20 19.7m 7.6m 5.3m S 0.3 1.6 0:00.08 `- sshd-session 10402 nolan 20 6.0m 5.4m 3.1m S 1.2 0:00.02 `- bash 10406 nolan 20 7.4m 5.4m 3.2m R 1.2 0:00.05 `- top 890 root 20 8.0m 2.5m 2.3m S 0.5 0:00.08 `- agetty 1077 www-data 20 7.7m 4.4m 3.5m S 1.0 0:02.96 `- lighttpd 1101 Debian-+ 20 39.9m 22.0m 8.0m S 4.7 0:04.64 `- exim4 10376 nolan 20 21.7m 12.2m 9.8m S 2.6 0:00.10 `- systemd 10378 nolan 20 22.7m 3.9m 2.0m S 0.8 `- (sd-pam) 2 root 20 S 0:00.01 [kthreadd]
Having trimmed down the list by removing performance copilot and the
handful of supporting processes I'm considering a bit of spelunking
to understand better why a few of those running processes are
required and how they relate (looking specifically at the
wpa_supplicant, ModemManager,
NetworkManager, systemd-network, and
dhclient).
There are of course a few more bits and pieces that run but I tend to configure them to launch on demand via socket activation or CGI. That is one of the guards I use with the goal of predisposing the system to not fail. It isn't infinitely scalable but CGI means a bunch of clean up happens automatically and the web server remains focused on static content. HAProxy implements some rate limiting to protect against some basic resource exhaustion but as can be seen above the server tends toward idleness.
I previously said I would have to see if the move to HAProxy and
lighttpd would stick and I think the intervening 2 years have proven
their stickiness. I'm more confident in their configuration and
they've proven robust in operation. Similarly fossil has required
zero maintenance and I'm considering whether I should migrate my
hosted repositories which mostly serve as a reference point for work
detailed in posts like these rather than for any kind of external
contributions. More than anything I'm happy with the stability of
Debian and a few pieces of automation
like unattended-upgrades that keep things up to date
without too much thought.