Livslängd och release-uppgraderingar

Modul 4: Programvara och uppdateringar · Lästid: 11 minuter

Lärandemål: Efter den här lektionen kan du ta reda på hur länge din distribution stöds, du vet vad "end of life" betyder för din server och du kan planera och genomföra en release-uppgradering på ett säkert sätt.

Nyckelbegrepp: release, LTS, standardsupport, Debian LTS, Ubuntu ESM och Ubuntu Pro, end of life (EOL), /etc/os-release, do-release-upgrade, minimal och fullständig uppgradering, paketkällor från tredje part, snapshot, curl | bash

Varje release har ett bäst före-datum

Automatiska uppdateringar (lektion 4.2) fungerar bara så länge din distribution fortfarande tar fram uppdateringar för din version. Varje release av Debian och Ubuntu får säkerhetsuppdateringar under en bestämd period. Sedan tar det slut: din server får inga fler rättningar, inte ens för allvarliga sårbarheter. Det kallas end of life (EOL).

Vilken version du har ser du så här:

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 till exempel VERSION="24.04.3 LTS (Noble Numbat)".

Debian

Debian ger en release fullt stöd i ungefär tre år. Sedan tar Debian LTS-teamet över i ytterligare två år, med säkerhetsuppdateringar för de mest använda paketen. För de aktuella releaserna (läget i november 2026, kontrollera på debian.org/releases):

Debian 12 får alltså fortfarande uppdateringar via LTS, men är inne i sista fasen. En ny server installerar du med Debian 13.

Ubuntu

Ubuntu släpper vartannat år i april en LTS-release (Long Term Support), med fem års standardunderhåll av säkerheten. Med en Ubuntu Pro-prenumeration (gratis för privat bruk på ett fåtal maskiner) tillkommer ESM (Expanded Security Maintenance), upp till tio år totalt.

Mellan LTS-releaserna kommer mellanversioner (som 25.10) med bara nio månaders support. De är inte avsedda för en server som ska köras i flera år. Välj alltid en LTS för en server.

Vad EOL betyder för dig

En server med en release som inte längre får uppdateringar fortsätter att fungera som vanligt. Det är just det som är lömskt: du märker ingenting, tills någon utnyttjar en sårbarhet som är åtgärdad överallt utom hos dig. Dessutom:

• ny programvara (en ny PHP-version, en ny Docker-release) byggs inte längre för din release;
• paketkällor från tredje part slutar också, ofta tidigare;
• ju längre du väntar, desto större blir hoppet. Debian stöder inte att du hoppar över en release: från 11 till 13 måste du gå via 12.

Lägg därför in din servers EOL-datum i kalendern, med en påminnelse ett halvår innan.

Två sätt: uppgradera eller bygga om

Det finns två rena vägar till en ny release.

1. In-place-uppgradering: du uppdaterar den befintliga servern till den nya releasen. Det går snabbt och allt finns kvar, men gamla rester och egna ändringar följer med.
2. Bygga om: du skapar en ny server med den nya releasen, installerar dina tjänster på nytt (smidigt med anteckningarna från lektion 10.4 eller med Docker Compose, modul 9), flyttar över data från din säkerhetskopia och ställer om DNS (lektion 7.1). Mer arbete, men rent, och samtidigt ett test av din säkerhetskopia.

För en liten server med några få tjänster fungerar en in-place-uppgradering utmärkt. Kör den mycket specialanpassat, eller har servern redan uppgraderats några gånger, så överväg att bygga om.

Förbered en in-place-uppgradering

Se till att du har de här fem sakerna innan du börjar:

1. En snapshot i din leverantörs panel, precis innan du börjar, och dessutom en färsk säkerhetskopia utanför servern (modul 8). En snapshot är din snabba väg tillbaka om uppgraderingen går fel halvvägs.
2. En andra ingång: din leverantörs konsol. Du arbetar via SSH, och om nätverksinställningarna eller SSH-servern ändras under uppgraderingen vill du kunna fortsätta via konsolen. Debians release notes säger det rakt ut: se till i förväg att du har ett annat sätt att logga in.
3. Läs release notes, särskilt kapitlet "Issues to be aware of". För Debian 13 står där till exempel att /tmp nu ligger i minnet som standard, att /etc/sysctl.conf inte längre läses (använd /etc/sysctl.d/) och att /boot måste vara tillräckligt stor.
4. Gå igenom källor från tredje part. Paket som inte kommer från Debian eller Ubuntu själva kan orsaka konflikter under uppgraderingen. Kontrollera vilka källor du har (ls /etc/apt/sources.list.d/) och om utvecklaren redan har en version för den nya releasen.
5. En session som klarar ett avbrott i anslutningen. Starta uppgraderingen i tmux eller screen. Försvinner din internetanslutning fortsätter uppgraderingen, och du plockar upp den igen med tmux attach.

Debian: stegen

Från release notes för Debian 13, för en uppgradering från 12 till 13:

root@web1:~# apt update && apt full-upgrade          # uppdatera först den aktuella releasen helt
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 uppgradering
root@web1:~# apt full-upgrade                        # fullständig uppgradering
root@web1:~# reboot

Använder du fortfarande /etc/apt/sources.list ändrar du kodnamnet där. Källor från tredje part stänger du tillfälligt av under uppgraderingen (byt namn till .disabled) och slår sedan på igen med den nya releasens kodnamn, om utvecklaren har en sådan.

Var uppmärksam på frågorna om konfigurationsfiler under uppgraderingen. Har du själv ändrat en fil, som sshd_config, frågar dpkg om du vill behålla din version. Behåll din egen version om du vet varför du ändrade den, och jämför sedan med den nya versionen (.dpkg-dist).

Efter omstarten:

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

systemctl --failed (lektion 6.1) ska vara tom. Kontrollera också att dina webbplatser och containrar fungerar och att din bevakning (lektion 8.3) är grön.

Ubuntu: do-release-upgrade

Ubuntu har ett eget program för det:

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

Två saker är bra att veta. För det första erbjuder Ubuntu en uppgradering från en LTS till nästa först efter den första punktreleasen (till exempel 26.04.1, några månader efter april). Det är medvetet: under de första månaderna löses de största problemen. För det andra: kör du uppgraderingen via SSH meddelar do-release-upgrade att den för säkerhets skull startar en extra SSH-server på en reservport. Den porten måste då släppas igenom av din brandvägg (lektion 5.2) om du behöver den; oftast behöver du den inte eftersom du har konsolen.

Den stora fallgropen: programvara utanför distributionen

Uppgraderingar går nästan alltid fel på grund av programvara som inte kommer från distributionen. Tre vanor gör skillnaden:

• Ingen curl https://... | bash. Ett skript från internet som du kör direkt som root kan ändra vad som helst på din server: lägga till källor, lita på nycklar för alla källor, skriva över filer. Du vet inte vad som hände, och vid nästa uppgradering går det sönder. Ladda ner ett sådant skript, läs det och gör hellre stegen själv.
• En extra källa bara från utvecklaren själv, med en egen nyckel (Signed-By, lektion 4.1), och skriv i din serverdokumentation varför den finns där.
• Inga lösa .deb-filer från webbplatser om du lika gärna kan hämta programmet från distributionen eller utvecklarens källa. De får aldrig uppdateringar.

På AlmaLinux och Rocky Linux

En "major"-version (9, 10) får där ungefär tio års uppdateringar, och mellanversioner (9.6, 9.7) uppdaterar du helt enkelt med dnf upgrade. Ett hopp till en ny major-version in-place går att göra med verktyget ELevate (AlmaLinux), men många administratörer väljer ändå att bygga om vid ett hopp till en ny major-version.

I praktiken

I WebOkés VPS-vy skapar du en snapshot före en uppgradering (högst två samtidigt, på samma lagring som din VPS) och har konsolen som andra ingång. Hos andra leverantörer heter det ungefär likadant: snapshot, VNC- eller webbkonsol, rescue. En snapshot ersätter inte en säkerhetskopia utanför servern; ta bort den när allt fungerar, eftersom den växer med varje ändring.

Sammanfattning

• Varje release får säkerhetsuppdateringar under en bestämd period; sedan är den end of life och din server får inga fler rättningar.
• Debian: ungefär tre år plus två år LTS; Ubuntu LTS: fem år plus ESM upp till tio år. Välj alltid en LTS för en server och lägg in slutdatumet i kalendern.
• Förbered en uppgradering med en snapshot, en säkerhetskopia, konsolen, release notes och en tmux-session.
• Debian: källorna till det nya kodnamnet, apt upgrade --without-new-pkgs, apt full-upgrade; Ubuntu: do-release-upgrade, efter den första punktreleasen.
• Programvara utanför distributionen är den största källan till uppgraderingsproblem: ingen curl | bash, bara källor från utvecklaren med en egen nyckel.

Quiz

Uppgift

Uppgift O4.3: Din uppgraderingsplan. Ta reda på vilken release din server kör och hur länge den får säkerhetsuppdateringar. Gör sedan en uppgraderingsplan: vilka källor från tredje part har du, hur skapar du en snapshot och en säkerhetskopia, hur kommer du in via konsolen, vilka steg utför du, hur testar du efteråt, och väljer du in-place-uppgradering eller att bygga om (med motivering)?

Läs mer

• Snapshots och backuper av din VPS
• Montera en egen ISO eller installera om din VPS
• Debian-releaser och supportperioder: https://www.debian.org/releases/
• Debian 13, release notes kapitel 4 (uppgradering) och 5 (saker att tänka på): https://www.debian.org/releases/trixie/release-notes/
• Ubuntu, releasecykel: https://ubuntu.com/about/release-cycle
• Ubuntu Server-dokumentationen, Upgrade your release: https://ubuntu.com/server/docs/how-to/software/upgrade-your-release/