Hoe lang krijgt Fedora beveiligingsupdates op een VPS?

Hoe lang ontvangt een Fedora-release beveiligingsupdates?

Een Fedora-server moet ongeveer eenmaal per jaar een versie-upgrade krijgen, zolang de machine bestaat. Fedora brengt ongeveer elke zes maanden een nieuwe release uit. Elke release wordt ondersteund tot ongeveer vier weken nadat de release twee versies later is uitgebracht. Dat komt neer op ongeveer 13 maanden aan updates. Na die datum ontvangt de release helemaal geen beveiligingsoplossingen meer. De server blijft draaien met een pakketset die niemand meer bijwerkt.

De datums maken dit concreet. In augustus 2026 zijn Fedora 43 en Fedora 44 de ondersteunde releases. Fedora 44 is uitgebracht op 28 april 2026 en het einde van de levensduur staat gepland voor juni 2027. Fedora 42 is uitgebracht in april 2025 en bereikte het einde van de levensduur in mei 2026, vier weken nadat Fedora 44 was verschenen. Een server die vanuit een Fedora 42-image was opgebouwd, viel daardoor dertien maanden later buiten de ondersteuning, zonder dat iemand iets verkeerd had gedaan.

Fedora tegenover een LTS, in maanden

LTS staat voor long-term support: een release die de leverancier jarenlang in plaats van maanden van patches voorziet. EOL staat voor end of life: de datum waarop de patches stoppen. 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 13 maanden ondersteuning per release. Een Ubuntu LTS biedt 60, en een enterprise-rebuild zoals AlmaLinux biedt 120. Beschouw de tweede kolom als de beheerlast. Over tien jaar vereist Fedora ongeveer 10 upgrades van het volledige besturingssysteem, tegenover 2 voor de Ubuntu LTS. Het Debian-cijfer van 36 maanden betreft de reguliere beveiligingsondersteuning. Een afzonderlijk LTS-team verlengt de meeste releases tot ongeveer vijf jaar.

Dit zijn gepubliceerde ondersteuningsperioden, gecontroleerd in augustus 2026, en geen gemeten uptime. Waarom de releasecycli verschillen, wordt uitgelegd in het verschil tussen Ubuntu LTS en interim-releases op een server. Wat hier telt, is hoeveel werk elke optie voor u oplevert.

Wat een Fedora-versie-upgrade werkelijk inhoudt

DNF 5 is sinds Fedora 41 de standaardpakketbeheerder en dnf voert deze uit. De opdracht system-upgrade maakt deel uit van dnf5 zelf. U hoeft dus eerst geen plug-in te installeren. Als u van een Debian- of Ubuntu-server komt, heeft het meeste van wat u dagelijks typt een directe apt-naar-dnf-tegenhanger. De onderstaande versie-upgrade is een van de weinige taken zonder echt equivalent. Begin met de huidige release, volledig bijgewerkt:

sudo dnf upgrade --refresh
sudo reboot

De reboot is belangrijk omdat de upgrade wordt opgelost op basis van wat is geïnstalleerd en actief is. Een gedeeltelijk toegepaste kernel- of glibc-update maakt de volgende stap daardoor moeilijker te beoordelen. Bereid nu de nieuwe release voor. Vervang 44 door de release waarnaar u migreert:

sudo dnf system-upgrade download --releasever=44

Hiermee wordt de volledige transactie opgelost en elk pakket gedownload. Er wordt niets gewijzigd aan het actieve systeem. Reken op enkele duizenden pakketten en één tot drie gigabytes op een kleine server. Als dnf de transactie niet kan oplossen, stopt het proces hier en wordt het pakket genoemd dat de oplossing blokkeert. Dat is de gunstige situatie. De fout treedt dan op terwijl de machine nog actief is en u nog een shell hebt.

Voer de transactie daarna uit:

sudo dnf offline status
sudo dnf system-upgrade reboot

dnf offline status bevestigt dat een transactie is voorbereid en wacht. dnf system-upgrade reboot start de machine opnieuw op voor een offline transactie: een minimale boot waarin de RPM-transactie zelfstandig wordt uitgevoerd. Dat is nodig omdat het vervangen van glibc en systemd onder actieve services tot een gedeeltelijk geïnstalleerd systeem kan leiden. Uw server is gedurende de volledige transactie onbereikbaar. Op een kleine VPS duurt dit meestal enkele minuten. Daarna wordt de machine opnieuw opgestart met de nieuwe release. Plan twee reboots en een periode waarin SSH niet antwoordt.

Wanneer de server weer beschikbaar is:

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

/etc/fedora-release moet een regel afdrukken zoals Fedora release 44 (Forty Four). De subopdracht log toont het transactielogboek van die offline boot. Dit is het enige overzicht van wat er is gebeurd terwijl u geen shell had. distro-sync brengt achtergebleven pakketten over naar de versies van de nieuwe release. repoquery --extras geeft geïnstalleerde pakketten weer die niet meer in een ingeschakelde repository staan. Daar vindt u achtergebleven pakketten uit een repository die nooit voor de nieuwe release is gepubliceerd.

Maak vóór de downloadstap een snapshot van de schijf. De transactie wordt uitgevoerd terwijl u het scherm niet kunt zien. Als de transactie tijdens de offline boot mislukt, komt SSH niet terug. Uw enige toegang is dan de console die de provider aanbiedt, via VNC of serieel. Controleer vóór de start of u een console of snapshot hebt. Doe dit niet pas daarna.

Er is 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 bestand hebt aangepast, overschrijft RPM uw bestand niet. RPM schrijft de meegeleverde versie ernaast als .rpmnew. Daardoor blijft uw sshd of nginx zich precies gedragen zoals in de oude release, terwijl de nieuwe standaardinstellingen ongelezen op de schijf staan. Lees deze bestanden na elke upgrade. Installeer rpmconf en voer sudo rpmconf -a uit om ze één voor één te doorlopen en de verschillen te bekijken.

Externe repositories veroorzaken de upgradefout

De eigen pakketten van Fedora worden op de releasedag gezamenlijk bijgewerkt. Pakketten van buiten Fedora volgen een ander schema. In de URL van de meeste leveranciersrepositories staat $releasever. Zodra u een upgrade uitvoert, zoekt dnf daarom naar een pad dat mogelijk nog niet bestaat.

Geef uw repositories weer:

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

Test elke repository die niet van Fedora zelf afkomstig is tegen de doelrelease voordat u iets definitief uitvoert:

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

Als de leverancier voor die release heeft gepubliceerd, downloadt dnf de metagegevens en wordt het programma zonder foutmelding afgesloten. Als dat niet het geval is, krijgt u een 404 voor een pad zoals https://download.docker.com/linux/fedora/44/x86_64/stable/repodata/repomd.xml. Dezelfde fout stopt later ook system-upgrade download. In de eerste weken na een Fedora-release is dit de meest voorkomende reden waarom een upgrade niet start.

U hebt twee mogelijkheden. Wacht enkele weken totdat de leverancier de pakketten heeft gepubliceerd. Dat is meestal de juiste 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 worden niet meer beheerd. Als ze de transactie blokkeren, meldt dnf dat. Met --allowerasing kan dnf geïnstalleerde pakketten verwijderen om het conflict op te lossen. Controleer daarom de lijst met te verwijderen pakketten voordat u dit bevestigt. Op die manier verliezen beheerders soms een databaseserver die ze wilden behouden.

Wat gebeurt er met een Fedora-server die het onderhoudsvenster mist

Op de dag zelf gebeurt er niets. De fout treedt op zodra u de pakketbeheerder weer gebruikt. Releases waarvan de levensduur is verstreken, worden van het mirror-netwerk naar het archief verplaatst. Daarom mislukt dnf upgrade bij het ophalen van metagegevens, met een 404 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. Dat maakt dit probleem stil en gevaarlijk. De machine ontvangt geen beveiligingsupdates meer. U kunt ook niets meer installeren. Op de dag waarop er een beveiligingsadvies voor OpenSSH of nginx verschijnt, hebt u daarom geen ondersteunde manier meer om de machine te patchen.

Herstel is mogelijk, maar verloopt traag. U kunt de repositories laten verwijzen naar het Fedora-archief op https://dl.fedoraproject.org/pub/archive/fedora/linux/ en vanaf daar upgraden. Fedora gaat uit van een sprong van één of twee releases per keer. Een server die vier releases achterloopt, vereist daarom meerdere opeenvolgende sprongen. Elke sprong kan mislukken en tijdens elke sprong werkt u zonder inzicht vanuit een offline bootomgeving. Op een VPS is opnieuw opbouwen met een actuele image en de gegevens overzetten meestal de kortere en veiligere aanpak. Dat is hetzelfde werk als de eerste tien minuten op een nieuwe VPS.

Automatische updates patchen een release. Ze upgraden deze nooit.

Fedora kan de updates volgens een timer installeren:

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

De instellingen staan in /etc/dnf/automatic.conf. Deze overschrijven de meegeleverde standaardwaarden in /usr/share/dnf5/dnf5-plugins/automatic.conf. apply_updates is standaard uitgeschakeld. Zonder aanvullende configuratie downloadt de timer dus wel updates, maar installeert deze niets. Met upgrade_type kiest u tussen default en security. reboot accepteert never, when-changed of when-needed.

Hiermee blijft u binnen een release actueel. Fedora 43 wordt nooit automatisch bijgewerkt naar Fedora 44. Een versie-upgrade is een afzonderlijke, bewuste handeling waarbij het systeem opnieuw opstart voor een offline transactie. Dat is het praktische verschil met een LTS-release. Op Ubuntu houden onbeheerde beveiligingsupdates een machine gedurende de volledige periode van vijf jaar bijgewerkt zonder de versie te wijzigen. De versie-upgrade zelf is een geplande taak, zoals de upgrade van 24.04 naar 26.04, die eens in de paar jaar wordt uitgevoerd.

Wanneer Fedora de juiste server is om te gebruiken

Fedora is een goede keuze wanneer vernieuwing het doel is.

• U hebt een kernel of userspace nodig die nieuwer is dan wat een LTS-release biedt: voor recente hardware of een container- en systemd-stack die nog een jaar verwijderd is van een enterprise-release. Fedora stapt tijdens de levensduur van een release bovendien over op nieuwe upstream-kernels. Dit voordeel geldt dus niet alleen op het moment van installatie.
• U controleert wat er in RHEL (Red Hat Enterprise Linux) terechtkomt. Fedora levert input aan CentOS Stream, dat vervolgens input levert aan RHEL. Software die vandaag op Fedora wordt gebouwd en uitgevoerd, wordt daarmee getest tegen het enterprise-platform van over enkele jaren.
• De machine is bewust van korte duur. Een buildrunner of testmachine die na twee maanden wordt vernietigd, bereikt nooit de einddatum van zijn levensduur. Dezelfde redenering geldt voor wegwerp-VM's die u aan codeeragents ter beschikking stelt, waarbij de machine veel vaker opnieuw wordt gebouwd dan Fedora-releases verschijnen.
• Iemand is verantwoordelijk voor de upgrade. Fedora is geschikt voor een server met een aangewezen eigenaar en een agenda-item. Het is geen goede keuze voor een machine die iedereen is vergeten.

De middenweg: actuele pakketten op een stabiele basis

De meeste mensen die Fedora op een server willen, hebben twee of drie actuele pakketten nodig, niet een actueel besturingssysteem. Die twee zaken staan los van elkaar. Gebruik een LTS-versie of een enterprise-rebuild als basis en haal de nieuwe software alleen binnen waar dat daadwerkelijk nodig is. Met een containerimage krijgt u de nieuwe versie van de applicatie op een host die u daarvoor niet hoeft te upgraden (Docker op een VPS uitvoeren). Een leveranciersrepository voor het ene pakket dat u nodig hebt, zoals PostgreSQL of nginx, brengt alleen dat pakket naar een nieuwere versie en laat de basis ongemoeid.

De afweging werkt beide kanten op. Een container biedt u een nieuwe userspace op de oude kernel van de host. Dat helpt dus niet wanneer juist de kernel moet worden vernieuwd. Een leveranciersrepository levert één nieuw pakket op een basis die door de leverancier minder uitvoerig is getest. In beide gevallen blijven de beveiligingsupdates van het basissysteem het LTS-schema volgen. Juist dat schema zorgt bij Fedora jaarlijks voor een onderhoudsvenster.

Als u Fedora toch voor een server kiest, zet u de releasecyclus in de agenda. Wacht na het uitbrengen van een release enkele weken totdat de repositories van leveranciers zijn bijgewerkt. Maak vervolgens een snapshot, voer de upgrade uit en controleer daarna of de services weer zijn gestart. Die werkwijze kost ongeveer een uur per jaar en werkt goed. De aanpak die misgaat, is de aanpak waarbij u pas aan een upgrade denkt nadat er al iets is uitgevallen.

FAQ

Hoe lang wordt een Fedora-release ondersteund?

Ongeveer 13 maanden. Fedora brengt ongeveer elke zes maanden een release uit en ondersteunt elke release tot ongeveer vier weken na de release die twee versies later verschijnt. Fedora 44 is op 28 april 2026 uitgebracht en het einde van de levensduur staat gepland voor juni 2027. Na die datum ontvangt de release geen beveiligingsupdates meer en worden de pakketten van de mirrors naar het Fedora-archief verplaatst.

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 verder ligt. Twee releases tegelijk overslaan is precies de werkwijze voor een jaarlijks upgraderitme. Verder gaan is geen ondersteund upgradepad. Bovendien neemt bij elke extra release de kans toe dat een pakketnaamwijziging of een wijziging in de configuratie-indeling de transactie onderbreekt. Als een machine al meerdere releases achterloopt en het einde van de levensduur is bereikt, is opnieuw installeren met een actuele image normaal gesproken sneller dan een reeks upgrades.

Wat gebeurt er als mijn Fedora-server het einde van de levensduur bereikt?

De server blijft werken, maar ontvangt geen patches meer. De volgende dnf upgrade mislukt met een 404 op de metalink-URL voor uw release, omdat releases waarvan de levensduur is verstreken naar het archief op dl.fedoraproject.org worden verplaatst. U kunt de repositorybestanden naar dat archief laten verwijzen en in stappen upgraden, of de server opnieuw installeren met een ondersteunde release. Totdat u een van deze opties uitvoert, kan geen beveiligingsupdate de machine bereiken en kan geen pakket worden geïnstalleerd.

Is Fedora een slechte keuze voor een productieserver?

Het is een slechte standaardkeuze, maar met een goede reden kan het een redelijke keuze zijn. Het nadeel is dat u elk jaar het volledige besturingssysteem moet upgraden, voor onbepaalde tijd, op een machine die u misschien liever ongemoeid laat. Kies Fedora wanneer u een nieuwere kernel of userspace nodig hebt dan een LTS-release biedt, of wanneer de server bewust een korte levensduur heeft. Kies een LTS-release of een enterprise-rebuild wanneer u een server jarenlang wilt patchen zonder de versie te wijzigen.