Levetid og release-oppgraderinger

Modul 4: Programvare og oppdateringer · Lesetid: 11 minutter

Læringsmål: Etter denne leksjonen kan du finne 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, standardstø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) fungerer bare så lenge distribusjonen din fortsatt lager oppdateringer for versjonen din. Hver release av Debian og Ubuntu får sikkerhetsoppdateringer i en fast periode. Deretter er det slutt: serveren din får ingen flere rettelser, 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 (status 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 andre å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, opptil ti år totalt.

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 årevis. 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 som før. Det er nettopp det som er lumskt: du merker ingenting, helt til noen utnytter en sårbarhet som er rettet overalt unntatt hos deg. I tillegg:

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

Før derfor EOL-datoen for serveren din inn 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. In-place-oppgradering: du oppdaterer den eksisterende serveren til den nye releasen. Raskt, og 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 fungerer en in-place-oppgradering fint. Kjører det mye spesialtilpasset på den, eller er serveren allerede oppgradert noen ganger, bør du vurdere å bygge på nytt.

Forberede en in-place-oppgradering

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 halvveis.
2. En ekstra inngang: konsollen hos leverandøren din. Du jobber via SSH, og hvis nettverksinnstillingene eller SSH-serveren endres under oppgraderingen, vil du kunne fortsette via konsollen. Release-notatene til Debian sier det rett ut: sørg på forhånd for en annen måte å logge inn på.
3. Les release-notatene, særlig kapitlet "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 utvikleren allerede har en versjon for den nye releasen.
5. En økt som tåler en brutt forbindelse. Start oppgraderingen i tmux eller screen. Faller internett ut, fortsetter oppgraderingen, og du henter den opp igjen med tmux attach.

Debian: stegene

Fra release-notatene til 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 utvikleren har det.

Følg med på spørsmålene om konfigurasjonsfiler under oppgraderingen. Har du selv endret en fil, 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 etterpå 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 fungerer, og at overvåkingen din (leksjon 8.3) er grønn.

Ubuntu: do-release-upgrade

Ubuntu har et eget program for dette:

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

To ting du bør 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 løses de største problemene. 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 utenfra distribusjonen

Oppgraderinger går nesten alltid galt på grunn av programvare som ikke kommer fra distribusjonen. Tre vaner utgjø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 utvikleren selv, med en egen nøkkel (Signed-By, leksjon 4.1), og noter i serverdokumentasjonen hvorfor den er der.
• Ingen løse .deb-filer fra nettsteder hvis det også finnes i distribusjonen eller i utviklerens kilde. De får aldri oppdateringer.

På AlmaLinux og Rocky Linux

En "major"-versjon (9, 10) får der omtrent ti år med oppdateringer, og mellomversjoner (9.6, 9.7) oppdaterer du helt vanlig med dnf upgrade. Et in-place-hopp til en ny major-versjon 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 noe tilsvarende: snapshot, VNC- eller nettkonsoll, rescue. Et snapshot erstatter ikke en sikkerhetskopi utenfor serveren; slett det når alt fungerer, 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 flere rettelser.
• 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-notatene 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 utenfra distribusjonen er den største kilden til oppgraderingsproblemer: ingen curl | bash, bare kilder fra utvikleren 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 gjennomfører du, hvordan tester du etterpå, og velger du in-place-oppgradering 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-notater kapittel 4 (oppgradering) og 5 (ting å være obs 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