Levetid og release-oppgraderinger

Modul 4: Programvare og oppdateringer · Lesetid: 11 minutter

Læringsmål: Etter denne leksjonen kan du slå opp levetiden til distribusjonen din, du vet hva "end of life" betyr for serveren din, og du kan planlegge og gjennomføre en release-oppgradering på en trygg måte.

Nøkkelbegreper: release, LTS, standard støtte, Debian LTS, Ubuntu ESM og Ubuntu Pro, end of life (EOL), /etc/os-release, do-release-upgrade, minimal og full oppgradering, pakkekilder fra tredjeparter, snapshot, curl | bash

Hver release har en utløpsdato

Automatiske oppdateringer (leksjon 4.2) virker bare så lenge distribusjonen din fortsatt lager oppdateringer for din versjon. Hver release av Debian og Ubuntu får sikkerhetsoppdateringer i en fast periode. Deretter er det slutt: serveren din får ingen rettelser lenger, heller ikke for alvorlige sårbarheter. Det kalles end of life (EOL).

Hvilken versjon du har, ser du slik:

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
...

På Ubuntu står det for eksempel VERSION="24.04.3 LTS (Noble Numbat)".

Debian

Debian gir full støtte til en release i omtrent tre år. Deretter tar Debian LTS-teamet over i to år til, med sikkerhetsoppdateringer for de mest brukte pakkene. For de nåværende releasene (per november 2026, sjekk debian.org/releases):

Debian 12 får altså fortsatt oppdateringer via LTS, men er i siste fase. En ny server installerer du med Debian 13.

Ubuntu

Ubuntu gir ut en LTS-release (Long Term Support) hvert annet år i april, med fem års standard sikkerhetsvedlikehold. Med et Ubuntu Pro-abonnement (gratis til personlig bruk på noen få maskiner) kommer ESM (Expanded Security Maintenance) i tillegg, til sammen opptil ti år.

Mellom LTS-releasene kommer det mellomversjoner (som 25.10) med bare ni måneders støtte. De er ikke ment for en server som skal kjøre i flere år. Velg alltid en LTS til en server.

Hva EOL betyr for deg

En server på en release som ikke lenger får oppdateringer, fortsetter å virke. Det er nettopp det som er lumskt: du merker ingenting før noen utnytter en sårbarhet som er rettet overalt, bortsett fra hos deg. I tillegg:

• ny programvare (en ny PHP-versjon, en ny Docker-release) bygges ikke lenger for din release;
• pakkekilder fra tredjeparter stopper også, ofte tidligere;
• jo lenger du venter, desto større blir hoppet. Debian støtter ikke å hoppe over en release: fra 11 til 13 må du gå via 12.

Før derfor inn EOL-datoen for serveren din i kalenderen, med en påminnelse et halvt år før.

To måter: oppgradere eller bygge på nytt

Det finnes to ryddige veier til en ny release.

1. Oppgradering på stedet (in-place): du oppdaterer den eksisterende serveren til den nye releasen. Raskt, alt blir stående, men gamle rester og egne tilpasninger blir med.
2. Bygge på nytt: du lager en ny server med den nye releasen, setter opp tjenestene dine på nytt (enkelt med notatene fra leksjon 10.4 eller med Docker Compose, modul 9), flytter dataene fra sikkerhetskopien og bytter DNS (leksjon 7.1). Mer arbeid, men rent, og det er samtidig en test av sikkerhetskopien din.

For en liten server med noen få tjenester holder det fint med en oppgradering på stedet. Kjører det mye spesialtilpasset, eller er serveren allerede oppgradert noen ganger, bør du vurdere å bygge på nytt.

Forberede en oppgradering på stedet

Sørg for disse fem tingene før du begynner:

1. Et snapshot i panelet hos leverandøren din, rett før du begynner, og en fersk sikkerhetskopi utenfor serveren (modul 8). Et snapshot er den raske veien tilbake hvis oppgraderingen går galt midtveis.
2. En ekstra inngang: konsollen hos leverandøren din. Du jobber via SSH, og hvis nettverksinnstillingene eller SSH-serveren endrer seg under oppgraderingen, vil du kunne fortsette via konsollen. Debians release notes sier det rett ut: sørg på forhånd for en annen måte å logge inn på.
3. Les release notes, særlig kapittelet "Issues to be aware of". For Debian 13 står det for eksempel der at /tmp nå ligger i minnet som standard, at /etc/sysctl.conf ikke lenger leses (bruk /etc/sysctl.d/), og at /boot må være stor nok.
4. Gå gjennom kilder fra tredjeparter. Pakker som ikke kommer fra Debian eller Ubuntu selv, kan komme i konflikt under oppgraderingen. Se hvilke kilder du har (ls /etc/apt/sources.list.d/), og om leverandøren allerede har en versjon for den nye releasen.
5. En økt som overlever et brudd i forbindelsen. Start oppgraderingen i tmux eller screen. Faller internett ut, fortsetter oppgraderingen, og du henter den opp igjen med tmux attach.

Debian: stegene

Fra release notes for Debian 13, for en oppgradering fra 12 til 13:

root@web1:~# apt update && apt full-upgrade          # oppdater gjeldende utgivelse helt først
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          # minimal oppgradering
root@web1:~# apt full-upgrade                        # full oppgradering
root@web1:~# reboot

Bruker du fortsatt /etc/apt/sources.list, endrer du kodenavnet der. Kilder fra tredjeparter slår du midlertidig av under oppgraderingen (gi dem nytt navn til .disabled) og slår dem på igjen etterpå med kodenavnet til den nye releasen, hvis leverandøren har det.

Følg med på spørsmålene om konfigurasjonsfiler under oppgraderingen. Har du endret en fil selv, som sshd_config, spør dpkg om du vil beholde din versjon. Behold din egen versjon hvis du vet hvorfor du endret den, og sammenlign deretter med den nye versjonen (.dpkg-dist).

Etter omstarten:

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

systemctl --failed (leksjon 6.1) skal være tom. Sjekk også at nettstedene og containerne dine virker, og at overvåkingen din (leksjon 8.3) er grønn.

Ubuntu: do-release-upgrade

Ubuntu har et eget program til dette:

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

To ting er greit å vite. For det første tilbyr Ubuntu en oppgradering fra én LTS til den neste først etter den første punktreleasen (for eksempel 26.04.1, noen måneder etter april). Det er med vilje: de første månedene blir de største problemene løst. For det andre: kjører du oppgraderingen via SSH, melder do-release-upgrade at den for sikkerhets skyld starter en ekstra SSH-server på en reserveport. Den porten må da slippes gjennom brannmuren din (leksjon 5.2) hvis du trenger den; som regel trenger du den ikke, fordi du har konsollen.

Den store fallgruven: programvare fra utenfor distribusjonen

Oppgraderinger går nesten alltid galt på programvare som ikke kommer fra distribusjonen. Tre vaner gjør forskjellen:

• Ingen curl https://... | bash. Et skript fra internett som du kjører direkte som root, kan endre hva som helst på serveren din: legge til kilder, stole på nøkler for alle kilder, overskrive filer. Du vet ikke hva som skjedde, og ved neste oppgradering knekker det. Last ned et slikt skript, les det, og gjør heller stegene selv.
• En ekstra kilde bare fra leverandøren selv, med en egen nøkkel (Signed-By, leksjon 4.1), og noter i serverdokumentasjonen din hvorfor den er der.
• Ingen løse .deb-filer fra nettsteder når du kan få det fra distribusjonen eller fra leverandørens kilde. De får aldri oppdateringer.

På AlmaLinux og Rocky Linux

Der får en "major"-versjon (9, 10) omtrent ti år med oppdateringer, og mellomversjoner (9.6, 9.7) oppdaterer du helt vanlig med dnf upgrade. Et hopp til en ny major-versjon på stedet er mulig med verktøyet ELevate (AlmaLinux), men mange administratorer velger likevel å bygge på nytt ved et hopp til en ny major-versjon.

I praksis

I VPS-skjermen hos WebOké tar du et snapshot før en oppgradering (maks to samtidig, på samme lagring som VPS-en din), og du har konsollen som ekstra inngang. Hos andre leverandører heter det omtrent det samme: snapshot, VNC- eller webkonsoll, rescue. Et snapshot erstatter ikke en sikkerhetskopi utenfor serveren; slett det når alt virker, for det vokser med hver endring.

Oppsummering

• Hver release får sikkerhetsoppdateringer i en fast periode; deretter er den end of life, og serveren din får ingen rettelser lenger.
• Debian: omtrent tre år pluss to år LTS; Ubuntu LTS: fem år pluss ESM opptil ti år. Velg alltid en LTS til en server, og før sluttdatoen inn i kalenderen.
• Forbered en oppgradering med et snapshot, en sikkerhetskopi, konsollen, release notes og en tmux-økt.
• Debian: kilder til det nye kodenavnet, apt upgrade --without-new-pkgs, apt full-upgrade; Ubuntu: do-release-upgrade, etter den første punktreleasen.
• Programvare fra utenfor distribusjonen er den største kilden til oppgraderingsproblemer: ingen curl | bash, bare kilder fra leverandøren med en egen nøkkel.

Quiz

Oppgave

Oppgave O4.3: Oppgraderingsplanen din. Finn ut hvilken release serveren din kjører, og hvor lenge den får sikkerhetsoppdateringer. Lag deretter en oppgraderingsplan: hvilke kilder fra tredjeparter har du, hvordan tar du et snapshot og en sikkerhetskopi, hvordan kommer du inn via konsollen, hvilke steg utfører du, hvordan tester du etterpå, og velger du oppgradering på stedet eller å bygge på nytt (med begrunnelse)?

Les mer

• Snapshots og backup av VPS-en din
• Koble til en egen ISO eller installer VPS-en din på nytt
• Debian-releaser og støtteperioder: https://www.debian.org/releases/
• Debian 13, release notes kapittel 4 (oppgradering) og 5 (ting å være oppmerksom på): https://www.debian.org/releases/trixie/release-notes/
• Ubuntu, release-syklus: https://ubuntu.com/about/release-cycle
• Ubuntu Server-dokumentasjon, Upgrade your release: https://ubuntu.com/server/docs/how-to/software/upgrade-your-release/
• Oppgrader VPS-en din til en ny versjon av Debian eller Ubuntu
• VPS: fra første innlogging til sikker server 1.5: Snapshots: et sikkerhetsnett før hver store endring