Dist upgrades when you’ve neglected a server for 3 years is a fun activity. Many versions of the upgrader don’t work, need to take a specific upgrade path that lacks documentation. Mainly achieved by trial and error.
At one point I rebuilt a server by fully abandoning the package database and reinstalling everything as overwrites. Converted a slackware install into a Debian install in situ by cannibalizing it from the inside out. Pretty proud of that one, even 20 years later.
Edit: to clarify, yes you MUST keep your server up to date (and have backups) but what I’m questioning is… if the OS a server actually matters much when most of the actual “serving” is done by containers, which might themselves get updates, or not, but are isolated.
Also, the actual isolation of container environments varies greatly, on a per container basis. Containers are far less isolated than virtual machines, and virtual machines are less isolated than separate hosts.
Neither containers or VMs will will protect from attacks on the host, see regreSSHion. You may be able to limit access to your host by using containers or VMs, but container escapes and VM escapes are not impossible.
There is much time and effort required to maintain each of these layers. With “stable” distros like Debian, It is often the responsibility of the distribution to provide fixes for the packages they provide.
Given Debian as the example, you are relying on the Debian package maintainer and Debian security team to address vulnerabilities by manually backporting security patches from the current software version to whatever ancient (stable) version of the package is in use, which can take much time and effort.
While Debian has a large community, it may be unwise to use a “stable” distro with few resources for maintaining packages.
OTOH, bleeding edge distros like Arch get many of their patches directly from the original author as a new version release, placing a lower burden on package maintainers. However, rolling releases can be more vulnerable to supply chain attacks like the XZ backdoor due to their frequent updates.
Dist upgrades when you’ve neglected a server for 3 years is a fun activity. Many versions of the upgrader don’t work, need to take a specific upgrade path that lacks documentation. Mainly achieved by trial and error.
Do your upgrades regularly, kids . 😁
At one point I rebuilt a server by fully abandoning the package database and reinstalling everything as overwrites. Converted a slackware install into a Debian install in situ by cannibalizing it from the inside out. Pretty proud of that one, even 20 years later.
edit: oh gods… more like 24.
Wow, 2000’s era was the wild west of Linux. 😁 I remember installing distros from DVDs attached to magazines. 🤭
In times of containers, does it even matter?
Edit: to clarify, yes you MUST keep your server up to date (and have backups) but what I’m questioning is… if the OS a server actually matters much when most of the actual “serving” is done by containers, which might themselves get updates, or not, but are isolated.
Yes, it matters.
Also, the actual isolation of container environments varies greatly, on a per container basis. Containers are far less isolated than virtual machines, and virtual machines are less isolated than separate hosts.
Neither containers or VMs will will protect from attacks on the host, see regreSSHion. You may be able to limit access to your host by using containers or VMs, but container escapes and VM escapes are not impossible.
There is much time and effort required to maintain each of these layers. With “stable” distros like Debian, It is often the responsibility of the distribution to provide fixes for the packages they provide.
Given Debian as the example, you are relying on the Debian package maintainer and Debian security team to address vulnerabilities by manually backporting security patches from the current software version to whatever ancient (stable) version of the package is in use, which can take much time and effort.
While Debian has a large community, it may be unwise to use a “stable” distro with few resources for maintaining packages.
OTOH, bleeding edge distros like Arch get many of their patches directly from the original author as a new version release, placing a lower burden on package maintainers. However, rolling releases can be more vulnerable to supply chain attacks like the XZ backdoor due to their frequent updates.