Linux-server veilig updaten met apt

Op een verse server is een upgrade een formaliteit: er is niets wat kapot kan gaan. Zodra de server diensten draagt, beslissen details of een upgrade ongemerkt doorloopt of dat er daarna een configuratiebestand is overschreven, een dienst nog de oude bibliotheek in het geheugen houdt of de draaiende kernel een andere is dan die op de schijf. Dit artikel loopt ze op volgorde langs. De korte versie voor een net opgeleverd systeem staat in de checklist voor een nieuwe rootserver.

Alle gegevens gelden voor Debian 13 (trixie), Debian 12 (bookworm), Ubuntu 24.04 LTS en Ubuntu 22.04 LTS. De commando's zijn geschreven voor gebruik als root. Werkt u als gewone gebruiker, zet dan voor elk commando sudo.

Voordat u het eerste commando geeft: de weg terug

Een upgrade kan op drie manieren duur uitpakken: een vraag over een configuratiebestand overschrijft de SSH-configuratie, een nieuwe kernel start niet op, of de verbinding valt weg midden in een dpkg-transactie. Alle drie zijn beheersbaar, maar alleen als u vooraf maatregelen neemt.

Een sessie die een verbroken verbinding overleeft

Valt de SSH-verbinding weg tijdens het uitpakken, dan krijgt het lopende proces een SIGHUP en eindigt dpkg midden in een transactie. Het resultaat is een half geconfigureerde pakketdatabase. Voer langere upgrades daarom uit in een sessie die op de server doorloopt, ook als uw terminal verdwijnt:

apt install -y tmux
tmux new -s upgrade

Valt de verbinding uit, log dan opnieuw in en haal de sessie met tmux attach -t upgrade terug. Het proces liep intussen gewoon door.

De weg naar de server als SSH niet meer antwoordt

Bij KVM-rootservers en dedicated servers van KernelHost bereikt u de VNC-console in het klantenpaneel. Die hangt niet aan de netwerkstack van het gastsysteem en werkt ook wanneer er geen enkele dienst meer luistert. Log er van tevoren één keer op in en controleer of u het root-wachtwoord kent.

Voor het geval een kernel niet opstart, hebt u bovendien een zichtbaar startmenu nodig. Op servers staat dat vaak verborgen:

grep -E '^GRUB_TIMEOUT|^GRUB_TIMEOUT_STYLE' /etc/default/grub

Staat daar GRUB_TIMEOUT_STYLE=hidden of GRUB_TIMEOUT=0, zet dat dan op GRUB_TIMEOUT_STYLE=menu en GRUB_TIMEOUT=5 en roep update-grub aan. In een noodgeval kiest u in de VNC-console onder "Advanced options" de vorige kernel.

De toestand controleren en vastleggen

Drie controles vooraf, die vaker iets vinden dan u zou verwachten:

df -h / /boot /var
dpkg --audit
apt-get check

Controle: dpkg --audit geeft niets terug, apt-get check loopt zonder foutregel door, en in /boot is minstens 300 MB vrij. Een volle /boot is de vaakst voorkomende oorzaak van een afgebroken kernelupgrade, meer daarover in Schijf vol onder Linux. Meldt dpkg --audit iets, repareer dat dan eerst met dpkg --configure -a.

Leg daarna de huidige toestand vast, zodat u later kunt vergelijken:

dpkg --get-selections > /root/pakketten-voor-upgrade.txt
apt-mark showhold > /root/holds-voor-upgrade.txt
cp -a /etc/apt /root/apt-config-$(date +%F)

update, upgrade, full-upgrade en dist-upgrade

Deze vier woorden worden voortdurend door elkaar gehaald. Het verschil is niet cosmetisch: het bepaalt of er een nieuwe kernel wordt geïnstalleerd en of pakketten mogen verdwijnen.

Daaruit volgen twee dingen. Ten eerste: dist-upgrade heeft niets te maken met een overstap naar een nieuwe distributieversie. De naam is historisch, het commando blijft binnen uw huidige versie.

Ten tweede is het verschil tussen apt upgrade en apt-get upgrade precies de reden waarom sommige servers zonder nieuwe kernel achterblijven. Debian koppelt de kernel via het metapakket linux-image-amd64, Ubuntu via linux-image-generic respectievelijk linux-image-virtual. Bij elke ABI-wisseling wijst dat metapakket naar een nieuw pakket, met het versienummer in de naam. apt-get upgrade installeert principieel geen nieuwe pakketten en laat de kernel dus liggen, terwijl apt upgrade hem wel installeert omdat een afhankelijkheid dat vereist. Gebruikt u apt-get upgrade in een onderhoudsscript, dan hebt u daar aanvullend --with-new-pkgs nodig.

Over de keuze van het gereedschap: vanuit een script schrijft apt de regel WARNING: apt does not have a stable CLI interface. Use with caution in scripts. Dat is geen foutmelding, maar wel een terechte aanwijzing. In scripts en Ansible-rollen hoort apt-get thuis, interactief werkt apt prettiger.

Het verloop met een controle na elke stap

Stap 1: de pakketlijsten ophalen.

apt update

Controle: de uitvoer bevat geen regel die met Err: of W: begint. Onderaan staat ofwel All packages are up to date. ofwel een getal gevolgd door packages can be upgraded. Elke foutregel hier betekent dat u met een onvolledig beeld verder zou werken.

Stap 2: bekijken wat er zou gebeuren. Deze stap ontbreekt in de meeste handleidingen en is de belangrijkste van het hele verloop.

apt list --upgradable
apt full-upgrade -s

De schakelaar -s simuleert en verandert niets. De regels onder The following packages will be REMOVED: zijn de enige die u werkelijk moet nakijken. Staat daar niets, dan is full-upgrade net zo onschuldig als upgrade. Staat daar een pakket dat u nodig hebt, gebruik dan apt upgrade en zoek de oorzaak apart uit.

Op Debian is apt install apt-listchanges daarnaast de moeite waard. Dat pakket toont vóór het installeren de changelogs en, belangrijker nog, de NEWS-bestanden van de pakketbeheerders. Daarin staat precies wat handwerk vraagt.

Stap 3: installeren.

apt upgrade

Blijf erbij. Het proces stelt vragen, en een -y beantwoordt alleen de vraag van apt zelf, niet de vragen over configuratiebestanden. Die komen van dpkg en wachten geduldig tot iemand antwoordt.

Controle:

apt list --upgradable
dpkg --audit
systemctl --failed
journalctl -p 3 -b --no-pager | tail -n 20

Verwacht wordt: apt list --upgradable geeft behalve Listing... niets terug, dpkg --audit zwijgt en systemctl --failed meldt 0 loaded units listed. Wat er werkelijk is gebeurd, staat blijvend in /var/log/apt/history.log, de volledige uitvoer van dpkg in /var/log/apt/term.log.

Tegengehouden pakketten: twee verschillende oorzaken

Als apt pakketten overslaat, zijn daar twee volstrekt verschillende redenen voor, die regelmatig door elkaar worden gehaald.

Ten eerste een echte blokkade. Iemand heeft het pakket uitdrukkelijk vastgezet:

apt-mark showhold

Geeft het commando iets terug, dan was dat een bewuste keuze, meestal bij databases of kernelmodules. Opheffen doet u met apt-mark unhold PAKKETNAAM, instellen met apt-mark hold PAKKETNAAM. Een blokkade op dpkg-niveau ziet u met dpkg --get-selections | grep -w hold.

Ten tweede de melding The following packages have been kept back:. Dat is geen blokkade. Het betekent: apt zou voor deze upgrade een pakket extra moeten installeren of er een moeten verwijderen, en dat mag het gebruikte commando niet. Het bewijs in één regel, zonder iets te veranderen:

apt full-upgrade -s | head -n 20

Duikt het pakket daar op, dan hebt u de verklaring gevonden en lost apt full-upgrade het op. Op Debian 13 geeft de nieuwere apt-generatie deze uitvoer anders vorm, inhoudelijk verandert er niets.

Het bijzondere geval Ubuntu. Ubuntu levert updates gespreid uit, niet alle servers krijgen ze op dezelfde dag. Een pakket kan dus worden tegengehouden terwijl er geen blokkade is en ook geen afhankelijkheid in de weg zit. De diagnose loopt via uitsluiting: apt-mark showhold is leeg, apt full-upgrade -s toont geen verwijdering, en apt-cache policy PAKKETNAAM noemt toch een nieuwere kandidaat. Wacht dan een paar dagen, of haal de update vervroegd binnen:

apt -o APT::Get::Always-Include-Phased-Updates=true upgrade

Op Debian 13 en Debian 12 bestaat die gespreide uitlevering niet, daar vervalt deze oorzaak bij voorbaat.

Als apt naar een configuratiebestand vraagt

Deze vraag verschijnt alleen wanneer er twee voorwaarden tegelijk gelden: het bestand is sinds de installatie lokaal gewijzigd, en het pakket brengt een nieuwe versie mee. De vraag ziet er zo uit:

Configuration file '/etc/ssh/sshd_config'
 ==> Modified (by you or by a script) since installation.
 ==> Package distributor has shipped an updated version.
   What would you like to do about it ?  Your options are:
    Y or I  : install the package maintainer's version
    N or O  : keep your currently-installed version
      D     : show the differences between the versions
      Z     : start a shell to examine the situation
 The default action is to keep your current version.
*** sshd_config (Y/I/N/O/D/Z) [default=N] ?

De standaardwaarde is N, dus uw eigen versie behouden. Dat is het veilige antwoord, maar niet in elke situatie het juiste.

Bij /etc/ssh/sshd_config is extra voorzichtigheid op zijn plaats: een Y kan PermitRootLogin en PasswordAuthentication terugzetten op de standaardwaarde van het pakket, en precies daaraan hangt uw toegang. Eigen SSH-instellingen horen daarom in een eigen bestand onder /etc/ssh/sshd_config.d/, zoals beschreven in SSH beveiligen en key-login instellen. Een bestand dat in het pakket helemaal niet voorkomt, veroorzaakt nooit een vraag.

Wat u ook antwoordt, dpkg gooit niets weg. Bij N komt de nieuwe versie ernaast te staan als .dpkg-dist, bij Y uw oude versie als .dpkg-old. Die bestanden doornemen is het eigenlijke nawerk:

find /etc -name '*.dpkg-dist' -o -name '*.dpkg-old' -o -name '*.dpkg-new' -o -name '*.ucf-dist'
diff -u /etc/ssh/sshd_config /etc/ssh/sshd_config.dpkg-dist

Voor onbeheerde runs, bijvoorbeeld in een onderhoudsscript, legt u het gedrag vooraf vast. Deze combinatie behoudt uw versie en stelt geen vragen:

DEBIAN_FRONTEND=noninteractive apt-get -y \
  -o Dpkg::Options::="--force-confdef" \
  -o Dpkg::Options::="--force-confold" \
  upgrade

--force-confnew is het tegenovergestelde en neemt altijd de versie uit het pakket. Op een server met een eigen configuratie is dat zelden wat u wilt.

Kernelupdates en de vraag naar de herstart

Een nieuwe kernel belandt bij de installatie in /boot en in het startmenu. De draaiende kernel blijft tot de herstart onveranderd in het geheugen. Een server kan dus tegelijk volledig bijgewerkt en kwetsbaar zijn. Het eenvoudigste bewijs is een vergelijking:

uname -r
ls -1 /boot/vmlinuz-*

Staat er in /boot een hogere versie dan uname -r meldt, dan is een herstart nodig. Op Ubuntu 24.04 en 22.04 bestaat daarnaast een markeringsbestand dat ook updates van bibliotheken meeneemt:

test -f /var/run/reboot-required && cat /var/run/reboot-required.pkgs

Het tweede bestand noemt de pakketten die om de herstart hebben gevraagd. Op Debian 13 en Debian 12 wordt die markering niet betrouwbaar aangemaakt, daar is needrestart de juiste weg.

needrestart: welke diensten nog de oude bibliotheek gebruiken

Een update van OpenSSL of glibc vervangt het bestand op de schijf. Elk proces dat het al had geladen, werkt verder met de oude versie. needrestart vindt precies die processen. Op Ubuntu 24.04 en 22.04 is het voorgeïnstalleerd en meldt het zich na elke upgrade met een schermvullende vraag, op Debian installeert u het zelf:

apt install -y needrestart
needrestart -b

De modus -b levert een machineleesbare uitvoer. Twee gegevens daaruit zijn doorslaggevend: NEEDRESTART-KSTA met de waarde 1 betekent dat de draaiende kernel de verwachte is, elke andere waarde betekent dat er een nieuwere klaarligt. Elke regel NEEDRESTART-SVC noemt een dienst die opnieuw gestart zou moeten worden.

Het gedrag stuurt u met de omgevingsvariabele NEEDRESTART_MODE: a herstart diensten automatisch, l maakt alleen een lijst, i vraagt na. Permanent staat hetzelfde in /etc/needrestart/needrestart.conf. Voor scripts is de variabele de betere keuze, omdat die niets aan de configuratie verandert:

NEEDRESTART_MODE=a DEBIAN_FRONTEND=noninteractive apt-get -y upgrade

Eén beperking moet u kennen: needrestart kijkt naar de processen van het hostsysteem. Diensten in containers vernieuwt het niet, daar hebt u nieuwe images voor nodig.

De versiewissel is een categorie op zich

Een overstap van Debian 12 naar Debian 13 of van Ubuntu 22.04 naar 24.04 is geen upgrade in de hierboven bedoelde zin. Zo'n overstap vervangt de pakketbronnen en daarmee vrijwel elk pakket. Drie regels gelden daarbij altijd: één versie per ronde, geen tussenversies overslaan, en vooraf een back-up waaruit de server te herstellen is.

Op Debian zet u eerst de bronnen om. Debian 12 gebruikt daarvoor /etc/apt/sources.list, Debian 13 het bestand /etc/apt/sources.list.d/debian.sources in het nieuwere formaat. Daarna volgt een bewuste procedure in twee stappen, die de release notes zo voorschrijven:

apt update
apt-get upgrade --without-new-pkgs
apt full-upgrade

De middelste stap werkt eerst de pakketten bij die geen herschikking nodig hebben. Dat houdt het aantal pakketten dat tegelijk verandert klein en maakt een afgebroken run herstelbaar. Vergeet de component non-free-firmware niet: die is sinds Debian 12 zelfstandig en ontbreekt in oude bronbestanden. Kent uw apt het commando apt modernize-sources (te controleren met apt --version), dan zet dat het oude bronbestand om naar het nieuwe formaat.

Op Ubuntu bestaat daar eigen gereedschap voor, en dat is het enige dat u zou moeten gebruiken:

apt install -y ubuntu-release-upgrader-core
do-release-upgrade -c
do-release-upgrade

De schakelaar -c controleert alleen en verandert niets. Of er een overstap wordt aangeboden, hangt af van Prompt in /etc/update-manager/release-upgrades: bij lts verschijnt alleen de sprong naar de volgende LTS-versie, en pas na de eerste tussenuitgave daarvan. De weg van 20.04 naar 24.04 loopt dwingend via 22.04.

Een detail dat velen verrast: draait do-release-upgrade via SSH, dan start het een extra SSH-dienst op poort 1022 als terugvaloptie en wijst het erop dat u die poort zo nodig in de firewall moet openen. Gebruik dat, maar vertrouw er niet op. De tmux-sessie en de toegang via de VNC-console zijn betrouwbaarder.

Opruimen na de upgrade

Na een grotere ronde blijven er drie soorten resten liggen: gedownloade pakketbestanden, verweesde pakketten en configuratieresten van verwijderde pakketten.

apt autoremove --purge
apt autoclean

autoclean verwijdert uit /var/cache/apt/archives alleen de bestanden die toch niet meer worden aangeboden. apt clean leegt de cache volledig en levert dus meer ruimte op, maar maakt van elke herinstallatie een nieuwe download.

Configuratieresten herkent u aan de dpkg-status rc, dus verwijderd, maar de configuratie is er nog:

dpkg -l | awk '/^rc/ {print $2}'

Wat daar staat, verwijdert u definitief met apt purge PAKKETNAAM. Bij oude kernels is meer zorgvuldigheid geboden, want een misgreep zorgt ervoor dat de server niet meer opstart:

uname -r
dpkg -l 'linux-image-*' | awk '/^ii/ {print $2}'

Verwijder nooit de kernel die de eerste regel noemt, en houd daarnaast een oudere werkende kernel aan, zodat het startmenu een terugvaloptie heeft. Meestal doet apt autoremove --purge dat toch al correct.

Veelvoorkomende fouten en oplossingen

E: Could not get lock /var/lib/dpkg/lock-frontend. It is held by process 1234 (unattended-upgr): er loopt al een tweede pakketbewerking, meestal de automatische beveiligingsupdate. Niet afbreken, maar laten aflopen. De volledige aanpak inclusief reparatie staat in apt-fout "Could not get lock" oplossen.

E: dpkg was interrupted, you must manually run 'dpkg --configure -a' to correct the problem.: een eerdere run is onderbroken, meestal door een verbroken verbinding. Voer precies dat commando uit en herhaal daarna de upgrade.

E: Unmet dependencies. Try 'apt --fix-broken install' with no packages (or specify a solution).: een pakket is geïnstalleerd, maar de afhankelijkheden ervan ontbreken. apt --fix-broken install haalt ze alsnog op. Komt de fout terug, dan ligt het bijna altijd aan een externe bron die pakketten voor een andere distributieversie aanbiedt.

E: Release file for http://deb.debian.org/debian/dists/trixie/InRelease is not valid yet (invalid for another 5h 3min 2s).: de klok van de server loopt achter. Controleer met timedatectl status of System clock synchronized: yes wordt gemeld, corrigeer de tijd en herhaal apt update. Aan de repository ligt het niet.

W: GPG error: ... The following signatures couldn't be verified because the public key is not available: NO_PUBKEY ..., gevolgd door E: The repository '...' is not signed.: de handtekeningsleutel van een externe bron ontbreekt of is vervangen. De sleutel hoort tegenwoordig in /etc/apt/keyrings/ en wordt in de bronvermelding aangehaald via signed-by respectievelijk via het veld Signed-By:. apt-key is afgeschaft en hoort niet meer te worden gebruikt.

E: Repository '... InRelease' changed its 'Suite' value from 'stable' to 'oldstable': dat gebeurt gewoon wanneer er een nieuwe Debian-versie verschijnt en uw bronnen naar stable wijzen in plaats van naar de codenaam. Bevestig dat eenmalig met apt update --allow-releaseinfo-change en zet de bronnen daarna om naar de codenaam. Een server die stable volgt, stapt anders ooit onbedoeld over op een andere distributieversie.

E: The repository 'http://... Release' does not have a Release file.: de bron biedt voor uw versie niets aan, meestal omdat een externe bron de codenaam nog niet ondersteunt of omdat de distributie het einde van de ondersteuning heeft bereikt. Schakel de betreffende regel uit en controleer de bron.

No space left on device midden in het uitpakken: /boot of /var zit vol. Ruim op met dpkg --configure -a, maak ruimte vrij en probeer het opnieuw. Vóór elke kernelupgrade loont een blik op df -h /boot.

debconf: unable to initialize frontend: Dialog: alleen een aanwijzing, geen storing. De melding verschijnt zonder volwaardige terminal, bijvoorbeeld in een script. Met DEBIAN_FRONTEND=noninteractive verdwijnt ze.

De vier systemen vergeleken

De eindcontrole

Dat een commando zonder fout terugkwam, betekent niet dat het systeem in orde is. Deze zes controles zeggen wel iets:

1. apt list --upgradable geeft behalve Listing... niets terug.
2. apt-mark showhold bevat alleen wat u bewust hebt geblokkeerd.
3. dpkg --audit zwijgt.
4. needrestart -b meldt NEEDRESTART-KSTA: 1 en geen openstaande diensten.
5. systemctl --failed somt niets op.
6. find /etc -name '*.dpkg-dist' vindt niets meer, omdat u elke afwijking hebt afgewerkt.

Vraagt punt vier om een herstart, plan die dan in en voer hem uit. Een server die maandenlang op een openstaande herstart wacht, verzamelt precies de kwetsbaarheden waartegen u eigenlijk hebt bijgewerkt. Controleer daarna nog één keer uname -r en systemctl --failed. De herstart is het moment waarop blijkt of alles weer netjes opstart.