Levensduur en release-upgrades

Module 4: Software en updates · Leestijd: 11 minuten

Leerdoel: Na deze les kun je de levensduur van je distributie opzoeken, weet je wat "end of life" voor je server betekent, en kun je een release-upgrade veilig plannen en uitvoeren.

Kernbegrippen: release, LTS, standaardondersteuning, Debian LTS, Ubuntu ESM en Ubuntu Pro, end of life (EOL), /etc/os-release, do-release-upgrade, minimale en volledige upgrade, pakketbronnen van derden, snapshot, curl | bash

Elke release heeft een houdbaarheidsdatum

Automatische updates (les 4.2) werken alleen zolang je distributie nog updates maakt voor jouw versie. Elke release van Debian en Ubuntu krijgt een vaste periode beveiligingsupdates. Daarna stopt het: je server krijgt geen fixes meer, ook niet voor ernstige lekken. Dat heet end of life (EOL).

Welke versie je hebt, zie je zo:

anna@web1:~$ cat /etc/os-release
PRETTY_NAME="Debian GNU/Linux 13 (trixie)"
NAME="Debian GNU/Linux"
VERSION_ID="13"
VERSION="13 (trixie)"
VERSION_CODENAME=trixie
...

Op Ubuntu staat er bijvoorbeeld VERSION="24.04.3 LTS (Noble Numbat)".

Debian

Debian ondersteunt een release ongeveer drie jaar volledig. Daarna neemt het Debian LTS-team het over voor nog twee jaar, met beveiligingsupdates voor de meest gebruikte pakketten. Voor de huidige releases (stand november 2026, nakijken op debian.org/releases):

Debian 12 krijgt dus nog updates via LTS, maar zit in de laatste fase. Een nieuwe server installeer je op Debian 13.

Ubuntu

Ubuntu brengt elke twee jaar in april een LTS-release uit (Long Term Support), met vijf jaar standaard beveiligingsonderhoud. Met een Ubuntu Pro-abonnement (voor persoonlijk gebruik gratis op een paar machines) komt daar ESM (Expanded Security Maintenance) bij, tot tien jaar in totaal.

Tussen de LTS-releases door verschijnen tussenversies (zoals 25.10) met maar negen maanden ondersteuning. Die zijn niet bedoeld voor een server die jaren moet draaien. Kies voor een server altijd een LTS.

Wat EOL voor jou betekent

Een server op een release die geen updates meer krijgt, werkt gewoon door. Dat is juist het verraderlijke: je merkt niets, tot iemand een lek gebruikt dat overal gerepareerd is behalve bij jou. Daarnaast:

• nieuwe software (een nieuwe PHP-versie, een nieuwe Docker-release) wordt niet meer voor jouw release gebouwd;
• pakketbronnen van derden stoppen ook, vaak eerder;
• hoe langer je wacht, hoe groter de sprong. Debian ondersteunt het overslaan van een release niet: van 11 naar 13 moet via 12.

Zet de EOL-datum van je server daarom in je agenda, met een herinnering een half jaar ervoor.

Twee manieren: upgraden of opnieuw opbouwen

Er zijn twee nette routes naar een nieuwe release.

1. In-place upgrade: je werkt de bestaande server bij naar de nieuwe release. Snel, alles blijft staan, maar oude restjes en eigen aanpassingen gaan mee.
2. Nieuw opbouwen: je maakt een nieuwe server met de nieuwe release, zet je diensten er opnieuw op (handig met de notities uit les 10.4 of met Docker Compose, module 9), zet de gegevens over uit je back-up en schakelt de DNS om (les 7.1). Meer werk, maar schoon, en het is meteen een test van je back-up.

Voor een kleine server met een paar diensten is een in-place upgrade prima. Draait er veel maatwerk, of is de server al een paar keer geüpgraded, overweeg dan opnieuw opbouwen.

Een in-place upgrade voorbereiden

Zorg voor deze vijf dingen voordat je begint:

1. Een snapshot in het paneel van je aanbieder, vlak voor je begint, én een recente back-up buiten de server (module 8). Een snapshot is je snelle weg terug als de upgrade halverwege misgaat.
2. Een tweede ingang: de console van je aanbieder. Je werkt via SSH, en als de netwerkinstellingen of de SSH-server tijdens de upgrade veranderen, wil je via de console verder kunnen. De Debian-releasenotes zeggen het letterlijk: zorg vooraf voor een andere manier om in te loggen.
3. De releasenotes lezen, vooral het hoofdstuk "Issues to be aware of". Voor Debian 13 staan daar bijvoorbeeld: /tmp staat nu standaard in het geheugen, /etc/sysctl.conf wordt niet meer gelezen (gebruik /etc/sysctl.d/), en /boot moet groot genoeg zijn.
4. Bronnen van derden nalopen. Pakketten die niet van Debian of Ubuntu zelf komen, kunnen tijdens de upgrade conflicteren. Bekijk welke bronnen je hebt (ls /etc/apt/sources.list.d/) en of de maker al een versie voor de nieuwe release heeft.
5. Een sessie die een verbroken verbinding overleeft. Start de upgrade in tmux of screen. Valt je internet weg, dan loopt de upgrade door en pak je hem op met tmux attach.

Debian: de stappen

Uit de releasenotes van Debian 13, voor een upgrade van 12 naar 13:

root@web1:~# apt update && apt full-upgrade          # eerst de huidige release helemaal bij
root@web1:~# sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/debian.sources
root@web1:~# apt update
root@web1:~# apt upgrade --without-new-pkgs          # minimale upgrade
root@web1:~# apt full-upgrade                        # volledige upgrade
root@web1:~# reboot

Gebruik je nog /etc/apt/sources.list, dan pas je de codenaam daar aan. Bronnen van derden zet je tijdens de upgrade tijdelijk uit (hernoemen naar .disabled) en daarna weer aan met de codenaam van de nieuwe release, als de maker die heeft.

Let tijdens de upgrade op de vragen over configuratiebestanden. Heb je een bestand zelf aangepast, zoals sshd_config, dan vraagt dpkg of je jouw versie wilt houden. Houd je eigen versie als je weet waarom je hem hebt aangepast, en vergelijk daarna met de nieuwe versie (.dpkg-dist).

Na de herstart:

anna@web1:~$ cat /etc/os-release | grep VERSION=
VERSION="13 (trixie)"
anna@web1:~$ systemctl --failed
anna@web1:~$ sudo apt autoremove

systemctl --failed (les 6.1) moet leeg zijn. Kijk ook of je websites en containers werken, en of je bewaking (les 8.3) groen is.

Ubuntu: do-release-upgrade

Ubuntu heeft er een eigen programma voor:

anna@web1:~$ sudo apt update && sudo apt full-upgrade
anna@web1:~$ sudo do-release-upgrade

Twee dingen om te weten. Ten eerste biedt Ubuntu een upgrade van de ene LTS naar de volgende pas aan na de eerste puntrelease (bijvoorbeeld 26.04.1, een paar maanden na april). Dat is bewust: de eerste maanden worden de grootste problemen opgelost. Ten tweede: draai je de upgrade via SSH, dan meldt do-release-upgrade dat hij voor de zekerheid een extra SSH-server op een reservepoort start. Die poort moet dan wel door je firewall (les 5.2) mogen als je hem nodig hebt; meestal heb je hem niet nodig omdat je de console hebt.

De grote valkuil: software van buiten de distributie

Upgrades lopen bijna altijd mis op software die niet uit de distributie komt. Drie gewoonten maken het verschil:

• Geen curl https://... | bash. Een script van internet dat je rechtstreeks als root uitvoert, kan van alles aan je server veranderen: bronnen toevoegen, sleutels voor alle bronnen vertrouwen, bestanden overschrijven. Je weet niet wat er gebeurde, en bij de volgende upgrade breekt het. Download zo'n script, lees het, en doe de stappen liever zelf.
• Een extra bron alleen van de maker zelf, met een eigen sleutel (Signed-By, les 4.1), en noteer in je serverdocumentatie waarom hij er staat.
• Geen losse .deb-bestanden van websites als het ook uit de distributie of de bron van de maker kan. Die krijgen nooit updates.

Op AlmaLinux en Rocky Linux

Een "major"-versie (9, 10) krijgt daar ongeveer tien jaar updates, en tussentijdse versies (9.6, 9.7) werk je gewoon bij met dnf upgrade. Een sprong naar een nieuwe major-versie in-place is mogelijk met het hulpprogramma ELevate (AlmaLinux), maar veel beheerders kiezen bij een sprong naar een nieuwe major-versie toch voor nieuw opbouwen.

In de praktijk

In het VPS-scherm van WebOké maak je vóór een upgrade een snapshot (hoogstens twee tegelijk, op dezelfde opslag als je VPS) en heb je de console als tweede ingang. Bij andere aanbieders heet dat vergelijkbaar: snapshot, VNC- of webconsole, rescue. Een snapshot vervangt geen back-up buiten de server; verwijder hem als alles werkt, want hij groeit mee met elke wijziging.

Samenvatting

• Elke release krijgt een vaste periode beveiligingsupdates; daarna is hij end of life en krijgt je server geen fixes meer.
• Debian: ongeveer drie jaar plus twee jaar LTS; Ubuntu LTS: vijf jaar plus ESM tot tien jaar. Kies voor een server altijd een LTS en zet de einddatum in je agenda.
• Bereid een upgrade voor met een snapshot, een back-up, de console, de releasenotes en een tmux-sessie.
• Debian: bronnen naar de nieuwe codenaam, apt upgrade --without-new-pkgs, apt full-upgrade; Ubuntu: do-release-upgrade, na de eerste puntrelease.
• Software van buiten de distributie is de grootste bron van upgradeproblemen: geen curl | bash, alleen bronnen van de maker met een eigen sleutel.

Quiz

Opdracht

Opdracht O4.3: Je upgradeplan. Zoek op welke release je server draait en tot wanneer die beveiligingsupdates krijgt. Maak daarna een upgradeplan: welke bronnen van derden heb je, hoe maak je een snapshot en een back-up, hoe kom je via de console binnen, welke stappen voer je uit, hoe test je daarna, en kies je voor in-place upgraden of nieuw opbouwen (met reden)?

Verder lezen

• Snapshots en backups van je VPS
• Een eigen ISO koppelen of je VPS opnieuw installeren
• Debian-releases en ondersteuningsperiodes: https://www.debian.org/releases/
• Debian 13, releasenotes hoofdstuk 4 (upgraden) en 5 (aandachtspunten): https://www.debian.org/releases/trixie/release-notes/
• Ubuntu, release-cyclus: https://ubuntu.com/about/release-cycle
• Ubuntu Server-documentatie, Upgrade your release: https://ubuntu.com/server/docs/how-to/software/upgrade-your-release/