Apply security updates

A security update fixes an already known flaw. Delaying it leaves open a door whose key is publicly available. On a NeoHeberg VPS, the kernel is managed by the platform: system packages update inside the container, but the kernel remains shared.

Update Debian packages

Debian publishes fixes in the security.debian.org repository. apt update only refreshes the indexes; it installs nothing.

sudo apt update
apt list --upgradable
sudo apt upgrade

apt list --upgradable shows what will be installed and from which repository. apt upgrade installs new versions without removing packages; apt full-upgrade may remove or replace some, which calls for a backup. Always simulate before touching production:

sudo apt-get -s upgrade

Then read important changes with apt changelog openssh-server before approving a critical service.

Kernel and reboot in a container

In a system container, uname -r returns the platform's shared kernel. Updating linux-image-* inside the container will not change the running kernel, even after a reboot, and you cannot load modules. Kernel flaws are handled at platform level; your work covers libraries and services.

A reboot is still required after a glibc, OpenSSL, systemd or OpenSSH update, because processes keep using the old library in memory. Check with:

cat /var/run/reboot-required 2>/dev/null
sudo needrestart -r l

Schedule that reboot in a short window, after a backup, and check services when the machine is back.

Automate security fixes

The unattended-upgrades package installs security updates automatically. Enable it and limit its scope to security repositories:

sudo apt install unattended-upgrades
sudo dpkg-reconfigure -plow unattended-upgrades

Configuration lives in /etc/apt/apt.conf.d/50unattended-upgrades and activation in 20auto-upgrades. Keep automatic reboot disabled and choose your own window: a server rebooting at the wrong time is as troublesome as an unpatched one. Logs are in /var/log/unattended-upgrades/.

On KeyHelp web hosting, PHP and system components are updated by the platform; you remain responsible for your site's extensions, themes and plugins.

Application dependencies

System packages do not cover your application code:

• PHP: apt updates PHP 8.4 and its extensions, then sudo systemctl reload php8.4-fpm reloads the service. Composer dependencies are updated separately with composer audit then composer update --with-dependencies in a tested environment.
• Node.js: the runtime comes from the platform, but your dependencies live in package.json. Use npm audit, update with a committed lockfile and redeploy. Avoid npm audit fix --force, which can break an API.
• WordPress: core, themes and plugins have their own cycle; a PHP update does not fix them.

Verify after the change

1. systemctl --failed should report no failed unit.
2. journalctl -p err -b shows errors since the last boot.
3. ss -tulpn confirms expected services still listen.
4. The site answers over HTTP and HTTPS, including IPv6.
5. apt list --upgradable no longer shows pending security fixes.

Keep a backup before any major version upgrade and never mix a security update with a version change in the same window.