Fedora server onderhoud: hoe vaak moet u upgraden?

Hoe lang ontvangt een Fedora-release beveiligingsupdates?

Een Fedora-server heeft ongeveer één keer per jaar een versie-upgrade nodig, zolang de machine bestaat. Fedora brengt ongeveer elke zes maanden een nieuwe release uit. Elke release wordt ondersteund tot ongeveer vier weken na de release van twee versies later, wat neerkomt op ongeveer 13 maanden aan updates. Na die datum ontvangt de release helemaal geen beveiligingspatches meer. De server blijft draaien, met een pakketset die door niemand meer wordt bijgewerkt.

De data maken dit concreet. Per augustus 2026 zijn de ondersteunde releases Fedora 43 en Fedora 44. Fedora 44 kwam uit op 28 april 2026 en de end-of-life is gepland voor juni 2027. Fedora 42 kwam uit in april 2025 en bereikte de end-of-life in mei 2026, vier weken nadat Fedora 44 verscheen. Een server die was gebouwd op basis van een Fedora 42-image was daarom dertien maanden later niet meer ondersteund, zonder dat er sprake was van een foutieve handeling.

Fedora versus een LTS, in maanden

LTS staat voor long term support: een release die de leverancier jarenlang van patches voorziet in plaats van maanden. EOL staat voor end of life, de datum waarop de ondersteuning stopt. Hieronder staat wat elk project publiceert voor de release die u vandaag zou installeren.

[
  {
    "distro": "Fedora 44",
    "support_window": 13,
    "upgrades_per_decade": 10
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "support_window": 60,
    "upgrades_per_decade": 2
  },
  {
    "distro": "Debian 13 stable",
    "support_window": 36,
    "upgrades_per_decade": 3
  },
  {
    "distro": "AlmaLinux 10",
    "support_window": 120,
    "upgrades_per_decade": 1
  }
]

Fedora biedt u 13 maanden per release. Een Ubuntu LTS biedt 60, en een enterprise-rebuild zoals AlmaLinux biedt 120. Lees de tweede kolom als de werklast. Over een periode van tien jaar vereist Fedora ongeveer 10 upgrades van het volledige besturingssysteem, tegenover 2 bij de Ubuntu LTS. Het Debian-cijfer van 36 maanden betreft de reguliere beveiligingsondersteuning; een apart LTS-team verlengt de meeste releases tot ongeveer vijf jaar.

Dit zijn de gepubliceerde ondersteuningsperioden, gecontroleerd in augustus 2026, geen gemeten uptime. Waarom de cycli verschillen, leest u in het verschil tussen Ubuntu LTS en interim-releases op een server. Wat hier van belang is, is de hoeveelheid werk die elk systeem voor u met zich meebrengt.

Wat een Fedora-versie-upgrade daadwerkelijk inhoudt

DNF 5 is de standaard pakketbeheerder sinds Fedora 41, en dnf voert deze uit. Het system-upgrade-commando is onderdeel van dnf5 zelf, dus er hoeft vooraf geen plug-in te worden geïnstalleerd. Begin bij de huidige release, volledig bijgewerkt:

sudo dnf upgrade --refresh
sudo reboot

De herstart is van belang omdat de upgrade wordt opgelost op basis van wat er is geïnstalleerd en actief is; een half toegepaste kernel- of glibc-update maakt het lastiger om de volgende stap te analyseren. Bereid nu de nieuwe release voor. Vervang 44 door de release waarnaar u overstapt:

sudo dnf system-upgrade download --releasever=44

Dit lost de volledige transactie op, downloadt elk pakket en wijzigt niets aan het draaiende systeem. Houd rekening met enkele duizenden pakketten en één tot drie gigabyte aan data op een kleine server. Als dnf de transactie niet kan oplossen, stopt het hier en wordt het pakket genoemd dat de blokkade veroorzaakt. Dat is het gunstige scenario, omdat de fout optreedt terwijl de machine nog actief is en u nog over een shell beschikt.

Voer daarna het volgende uit:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status bevestigt dat een transactie klaarstaat en wacht. dnf system-upgrade reboot herstart de machine naar een offline transactie: een minimale boot waarbij de RPM-transactie zelfstandig wordt uitgevoerd. Dit werkt op deze manier omdat het vervangen van glibc en systemd onder draaiende services de oorzaak is van een half-geïnstalleerd systeem. Uw server is onbereikbaar gedurende de gehele transactie, meestal enkele minuten op een kleine VPS, waarna deze opnieuw opstart in de nieuwe release. Plan twee herstarts en een periode waarin SSH niet reageert.

Wanneer het systeem terug is:

cat /etc/fedora-release
sudo dnf system-upgrade log --number=-1
sudo dnf distro-sync
sudo dnf repoquery --extras

/etc/fedora-release zou een regel moeten tonen zoals Fedora release 44 (Forty Four). Het log-subcommando toont het transactielogboek van die offline boot; dit is het enige verslag van wat er is gebeurd terwijl u geen shell had. distro-sync haalt eventuele achtergebleven zaken naar de versies van de nieuwe release. repoquery --extras toont geïnstalleerde pakketten die niet langer in een ingeschakelde repository staan; hier vindt u de restanten van een repository die nooit is uitgebracht voor de nieuwe release.

Maak een snapshot van de schijf vóór de downloadstap. De transactie wordt uitgevoerd terwijl u geen zicht heeft op het scherm; als deze faalt tijdens de offline boot, zal SSH niet terugkeren en is uw enige toegangsmogelijkheid de console die de provider aanbiedt, zoals VNC of serieel. Controleer of u over een console of een snapshot beschikt vóórdat u begint, niet erna.

Nog een controle die vaak wordt overgeslagen:

sudo find /etc -name '*.rpmnew' -o -name '*.rpmsave'

Wanneer een pakket een nieuw standaardconfiguratiebestand bevat en u het oude heeft bewerkt, overschrijft RPM uw bestand niet. Het schrijft de versie uit het pakket ernaast als .rpmnew. Hierdoor blijft uw sshd of nginx zich precies zo gedragen als op de oude release, terwijl de nieuwe standaardinstellingen ongelezen op de schijf staan. Lees die bestanden na elke upgrade. Het installeren van rpmconf en het uitvoeren van sudo rpmconf -a loopt deze één voor één na en toont u de verschillen.

Repositories van derden veroorzaken problemen bij de upgrade

De eigen pakketten van Fedora worden allemaal tegelijk bijgewerkt op de dag van de release. Alles wat buiten Fedora valt, volgt een eigen planning. De meeste leveranciersrepositories gebruiken $releasever in hun URL, waardoor dnf direct na uw upgrade om een pad vraagt dat mogelijk nog niet bestaat.

Bekijk welke repositories u heeft:

sudo dnf repo list --enabled
grep -R -e baseurl -e metalink /etc/yum.repos.d/

Test voor elke repository die niet van Fedora zelf is of deze geschikt is voor de doelrelease voordat u actie onderneemt:

sudo dnf --releasever=44 --repo=docker-ce-stable makecache

Als de leverancier de software voor die release heeft gepubliceerd, downloadt dnf de metadata en sluit het programma geruisloos af. Zo niet, dan krijgt u een 404-foutmelding voor een pad zoals https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml, en dezelfde fout zal system-upgrade download later blokkeren. In de eerste weken na een Fedora-release is dit de meest voorkomende reden waarom een upgrade niet start.

U heeft twee opties. Wacht een paar weken tot de leverancier de software publiceert; dit is meestal de verstandigste keuze. Of voer de upgrade uit zonder die repository:

sudo dnf system-upgrade download --releasever=44 --disable-repo=docker-ce-stable

Het uitschakelen van een repository verwijdert de bijbehorende pakketten niet. Ze blijven geïnstalleerd en onbeheerd achter. Als ze de transactie blokkeren, meldt dnf dit. Door --allowerasing toe te voegen, staat u dnf toe om geïnstalleerde pakketten te verwijderen om het conflict op te lossen. Controleer daarom de lijst met te verwijderen pakketten zorgvuldig voordat u akkoord gaat. In die lijst staan vaak pakketten zoals een databaseserver die u eigenlijk wilde behouden.

Wat gebeurt er met een Fedora-server die de updateperiode mist

Er gebeurt op de dag zelf niets. Het probleem treedt op zodra u de pakketbeheerder weer gebruikt. Releases die het einde van hun levenscyclus hebben bereikt, worden van het mirror-netwerk naar het archief verplaatst. Hierdoor faalt dnf upgrade bij het ophalen van metadata, met een 404-foutmelding op de metalink-URL voor uw release:

Status code: 404 for https://mirrors.fedoraproject.org/metalink?repo=fedora-42&arch=x86_64

De machine blijft netwerkverkeer afhandelen, wat dit een geruisloos en gevaarlijk proces maakt. De server ontvangt geen beveiligingsupdates meer. Daarnaast is het onmogelijk om nieuwe software te installeren. Op de dag dat er een beveiligingsadvies voor OpenSSH of nginx verschijnt, heeft u dus geen ondersteunde methode meer om de server te patchen.

Herstel is mogelijk, maar tijdrovend. U kunt de repositories omleiden naar het Fedora-archief op https://dl.fedoraproject.org/pub/archive/fedora/linux/ en vanaf daar upgraden. Fedora verwacht een overstap van maximaal één of twee releases tegelijk. Een server die vier releases achterloopt, vereist dus meerdere opeenvolgende stappen. Elke stap brengt een risico op falen met zich mee, waarbij u telkens blind werkt in een offline boot-omgeving. Bij een VPS is het meestal sneller en veiliger om de server opnieuw op te bouwen vanaf een actuele image en de data te migreren. Dit kost evenveel werk als de eerste tien minuten op een nieuwe VPS.

Automatische updates patchen een release. Ze voeren nooit een upgrade uit.

Fedora kan updates installeren op basis van een timer:

sudo dnf install -y dnf5-plugin-automatic
sudo systemctl enable --now dnf5-automatic.timer

Instellingen bevinden zich in /etc/dnf/automatic.conf, wat de standaardwaarden in /usr/share/dnf5/dnf5-plugins/automatic.conf overschrijft. apply_updates staat standaard uit, waardoor de timer updates wel downloadt maar niets installeert. upgrade_type kiest tussen default en security. reboot accepteert never, when-changed of when-needed.

Dit houdt uw systeem actueel binnen een release. Het zal Fedora 43 nooit naar Fedora 44 verplaatsen, omdat een versie-upgrade een afzonderlijke, bewuste handeling is die opnieuw opstart naar een offline transactie. Dat is het praktische verschil met een LTS. Op Ubuntu voeren onbeheerde beveiligingsupgrades een machine door de volledige periode van vijf jaar zonder enige versie-wijziging, en de versie-upgrade zelf is een geplande taak zoals de upgrade van 24.04 naar 26.04 die eens in de paar jaar plaatsvindt.

Wanneer Fedora de juiste keuze is voor een server

Fedora is een goede keuze wanneer nieuwheid het voornaamste doel is.

• U heeft een kernel of userspace nodig die nieuwer is dan wat een LTS-release biedt: recente hardware, of een container- en systemd-stack die nog een jaar verwijderd is van een enterprise-release. Fedora stapt tijdens een release bovendien over op nieuwe upstream-kernels, dus dit is niet alleen een eenmalig voordeel bij de installatie.
• U valideert wat er in RHEL (Red Hat Enterprise Linux) terechtkomt. Fedora voedt CentOS Stream, wat weer RHEL voedt. Software die vandaag op Fedora bouwt en draait, wordt dus getest tegen het enterprise-platform van over een paar jaar.
• De machine is ontworpen voor een korte levensduur. Een build-runner of een testomgeving die na twee maanden wordt verwijderd, bereikt nooit zijn end-of-life-datum. Dezelfde logica geldt voor tijdelijke VM's die u aan coding agents geeft, waarbij de machine veel vaker opnieuw wordt opgebouwd dan dat er Fedora-releases verschijnen.
• Iemand is verantwoordelijk voor de upgrade. Fedora is prima op een server met een aangewezen beheerder en een agenda-item. Het is een slechte keuze voor een machine die iedereen is vergeten.

De gulden middenweg: actuele pakketten op een stabiele basis

De meeste mensen die Fedora op een server willen, hebben behoefte aan twee of drie actuele pakketten, niet aan een actueel besturingssysteem. Deze zaken zijn te scheiden. Gebruik een LTS-distributie of een enterprise-rebuild als basis en haal de nieuwe software binnen waar u deze daadwerkelijk nodig heeft. Een container-image biedt de nieuwe versie van de applicatie op een host die u hiervoor nooit hoeft te upgraden (Docker draaien op een VPS). Een vendor-repository voor het specifieke pakket dat u nodig heeft, zoals PostgreSQL of nginx, werkt dat ene onderdeel bij terwijl de basis ongewijzigd blijft.

De afweging is in beide gevallen transparant. Een container biedt een nieuwe userspace op de oude kernel van de host; dit helpt dus niet als u juist een nieuwe kernel nodig heeft. Een vendor-repository levert één nieuw pakket op een basis die door de leverancier minder uitgebreid is getest. In beide gevallen blijven de beveiligingsupdates van het basissysteem gebonden aan de LTS-cyclus, en die cyclus is precies het onderdeel dat bij Fedora elk jaar een onderhoudsvenster vereist.

Als u toch voor Fedora op een server kiest, plan de cyclus dan in uw agenda. Wacht na het uitbrengen van een release enkele weken totdat de vendor-repositories zijn bijgewerkt, maak een snapshot, voer de upgrade uit en verifieer vervolgens of de services weer correct functioneren. Dit ritme kost ongeveer een uur per jaar en het werkt. De versie die problemen oplevert, is de versie waarbij de upgrade pas wordt herinnerd op het moment dat er al iets is uitgevallen.

FAQ

Hoe lang wordt een Fedora-release ondersteund?

Ongeveer 13 maanden. Fedora brengt ongeveer elke zes maanden een nieuwe versie uit en ondersteunt elke release tot ongeveer vier weken na de release van twee versies later. Fedora 44 werd uitgebracht op 28 april 2026 en de end-of-life is gepland voor juni 2027. Wanneer die datum is verstreken, ontvangt de release geen beveiligingsupdates meer en worden de pakketten van de mirrors verplaatst naar het archief van Fedora.

Kan ik een Fedora-release overslaan en twee versies tegelijk upgraden?

Ja, binnen bepaalde grenzen. dnf system-upgrade download --releasever= accepteert een doelversie die één of twee releases vooruit ligt, en twee versies tegelijk upgraden is precies hoe een jaarlijks upgraderitme werkt. Verder gaan is geen ondersteund pad, en elke extra release vergroot de kans dat een pakketnaamwijziging of een wijziging in het configuratieformaat de transactie blokkeert. Als een machine al enkele releases achterloopt en de end-of-life is gepasseerd, is het opnieuw opbouwen vanaf een actuele image meestal sneller dan een reeks upgrades.

Wat gebeurt er als mijn Fedora-server de end-of-life bereikt?

De server blijft draaien, maar ontvangt geen patches meer. De volgende dnf upgrade mislukt met een 404-foutmelding op de metalink-URL voor uw release, omdat releases die hun end-of-life hebben bereikt, worden verplaatst naar het archief op dl.fedoraproject.org. U kunt de repository-bestanden naar dat archief laten verwijzen en in stappen upgraden, of de server opnieuw opbouwen op een ondersteunde release. Totdat u een van beide doet, kan geen enkele beveiligingsupdate de machine bereiken en zal geen enkel pakket worden geïnstalleerd.

Is Fedora een slechte keuze voor een productieserver?

Het is een slechte standaardkeuze, maar een redelijke keuze als u daar een specifieke reden voor heeft. De kosten zijn een volledige upgrade van het besturingssysteem per jaar, voor altijd, op een machine die u liever niet aanraakt. Kies voor Fedora wanneer u een kernel of userspace nodig heeft die nieuwer is dan wat een LTS-versie biedt, of wanneer de server van nature een korte levensduur heeft. Kies voor een LTS-versie of een enterprise-rebuild wanneer u een server jarenlang wilt patchen zonder de versie te wijzigen.