Healthcard: warn when server runs out of support

[jelly]

Page: systemd (overview)

Add a warning in the healthcard before the machine runs out of support. Fedora these days has SUPPORT_END in /etc/os-release, Cockpit could show a warning X days before the server runs out of support that the user has to update.

[root@fedora-40-127-0-0-2-2201 ~]# cat /etc/os-release  | grep SUPPORT_END
SUPPORT_END=2025-05-13

If the warning needs to be actionable, we need to think about where we link too as cockpit has no "distro upgrade" action.

Side-note: we can check if Ubuntu for example also supports this now.

[jelly]

@garrett opinions? :)

[garrett]

I like this idea of having an EOL warning.

Is a month a good amount of time to allow someone to prepare to update to the next version?

I'd imagine it would basically be implemented in 3 big steps:

1. For a first pass, just having the warning should be enough.

2. A second pass could have distribution-specific ways to update documented in the UI.

   • It probably makes sense to have that integrated into the software page, and the link would go there?
     • (While it could be a popover, but I think that's not enough room and it can go away too easily.)
   • We could even extend these instructions and embed a terminal as root underneath, so someone could refer to the help text and type at the same time, without having to switch contexts. 😄 (This would be step 2.5, if so.)
     • Even still, we would never want to encourage someone to update in-place; so it should only show up when there isn't another UI to handle it and when it updates offline

3. Ideally, we'd have an action to do the update within Cockpit itself...

   • It'd be easiest to implement in atomic distributions, where downloading for a rebase and rebooting into the new version is basically the same as updating (except with a "rebase" instead).
   • Transactional distros (like those using dnf) would need to download the updates, reboot, apply the updates, and reboot again. That's definitely trickier, especially remotely with Cockpit, as there would be a large gap with no feedback where you hope it's working. I don't know how much we can make a UI for this kind of process.
   • For others, which I think includes Debian, Ubuntu, and derivatives... it's easier to update in-place, but quite risky (as updating could take out Cockpit or parts of the system Cockpit depends on).
   • For rolling releases like Arch or openSUSE Tumbleweed, it's just another update as usual.

Step 3 would be optional, especially because it's so tricky to do right in most distributions. We could have automated support for upgrading with atomic and rolling distros only, for example. And then consider dnf, but the in-place upgrades are asking for trouble and we'd probably never support that, even if we did support everything else.

[jelly]

Filled a Debian bug to support SUPPORT_END https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1080334