Fedora Hummingbird: amikor maga az operációs rendszer is konténer lesz

A Red Hat Summit 2026-on bejelentett Fedora Hummingbird első pillantásra úgy hangzik, mint egy újabb kísérleti Fedora spin. De ami a motorháztető alatt van, az annál jóval radikálisabb: a Fedora Hummingbird egy teljesen konténer-alapú, rolling release Fedora Linux disztribúció, amely az egész operációs rendszert OCI image-ként szállítja — ugyanúgy, ahogy egy alkalmazáskonténert szállítanál, csak ez esetben maga az OS az a konténer. Ez nem iteráció. Ez egy architektúraváltás.

Honnan jött az ötlet?

A Fedora Hummingbird mögött álló gondolat nem új — de mostanáig senki nem vitte végig az egész operációs rendszer szintjéig.

A Red Hat 2025 novemberében indította el a Project Hummingbird korai hozzáférési programját, amelynek eredeti célja egy katalógus volt: minimális, megerősített, „distroless" konténer image-ek gyűjteménye, amelyeket közel nulla CVE-státuszon tartanak. Amikor egy sebezhetőséget javítanak az upstream forrásnál, a build pipeline megtalálja, újraépíti az érintett image-t, és kiszállítja.

A logika tehát bevált a konténerek szintjén. A Fedora Hummingbird ugyanezt a logikát alkalmazza egy teljes méretű operációs rendszerre, Konflux-alapú build pipeline-nal, és a csomagok több mint 95%-át a Fedora Rawhide-ból veszi.

A kérdés, amelyet a projekt megválaszol: ha a konténerek esetében már megoldottuk a folyamatos, automatikus, közel nulla CVE-s szállítást — miért ne lehetne ugyanez igaz magára a gazdaoperációs rendszerre?

Hogyan működik? Az OCI-alapú OS anatómiája

A hagyományos Linux disztribúcióknál az operációs rendszer csomagok halmazaként létezik, amelyeket egy csomagkezelő (apt, dnf, pacman) kezel. Frissítéskor a csomagkezelő részlegesen módosítja a futó rendszert — ez az oka annak, hogy előfordulhat részleges frissítési állapot, konfiguráció-drift, és az örök klasszikus: „nálam működött, mielőtt frissítettem."

A Fedora Hummingbird esetében az OS maga egy OCI image — ugyanúgy épül és szállítódik, mint bármely más konténer, és atomikusan frissül, beépített rollback lehetőséggel. Nincs részleges frissítési állapot. Nincs konfiguráció-drift. A gyökérfájlrendszer csak olvasható. Minden írható állapot a /var és az /etc könyvtárakban él, tisztán elkülönítve az OS tartalmától.

A bootable container koncepció

A kulcs a bootc eszköz és az OCI image formátum kombinációja. Mivel az OCI konténer egy teljes, indítható operációs rendszer elrendezést tartalmaz, szabványos konténerparancsokkal vizsgálható a belső könyvtárszerkezete. Az ostree és sysroot könyvtárak jelenléte — amelyek nem léteznek a hagyományos alkalmazáskonténer rétegekben — megerősíti, hogy valóban egy teljes, indítható operációs rendszer elrendezésről van szó.

Más szóval: a szokásos podman pull paranccsal lehúzható, és bootc-image-builder segítségével konvertálható — qcow2 (QEMU/KVM), AMI (AWS), vagy nyers telepítő ISO formátumba.

Az ARK kernel

A Fedora Hummingbird az ARK kernelt (Always Ready Kernel) használja a CKI projektből, amely közvetlenül Linus Torvalds mainline fejlesztési ágát követi, és a CKI tesztelési és mérnöki keretrendszerét használja a gyors kernel-frissítésekhez.

Ez azt jelenti, hogy a Hummingbird kernelfrissítései — szemben a hagyományos disztribúciókkal — nem várnak heteket a stabil kernelre, hanem szinte azonnal követik az upstream fejlesztést. A biztonság szempontjából ez különösen fontos: a Copy Fail és a Dirty Frag tanulsága pontosan az volt, hogy a hagyományos disztribúciók patch-szállítási ciklusa túl lassú ahhoz, hogy lépést tartson az aktívan kihasznált sebezhetőségekkel.

Mit jelent ez a gyakorlatban?

Frissítés, ahogy azt a fejlesztők szeretik

# Az aktuális OS image lehúzása
podman pull quay.io/hummingbird-community/bootc-os:latest

# Frissítés alkalmazása (következő indításkor lép érvénybe)
bootc update

# Rollback, ha valami nem tetszik
bootc rollback

Nincs sudo dnf upgrade, nincs újraindítás utáni meglepetés, nincs „valami eltört a frissítés után" debugolás. Ha a frissítés nem tetszik, egy paranccsal visszaállsz az előző állapotra.

Telepítés konténerből VM-be vagy bare metalra

# Indítható qcow2 image generálása (QEMU/KVM-hez)
podman run --rm \
  --privileged \
  --pull=newer \
  -v /var/lib/containers/storage:/var/lib/containers/storage \
  -v /path/to/config.toml:/config.toml \
  -v /output:/output \
  quay.io/centos-bootc/bootc-image-builder:latest \
  --type qcow2 \
  quay.io/hummingbird-community/bootc-os:latest

Ugyanez a parancs --type ami-val AWS AMI-t generál, --type raw-val bare metal telepítő képet.

Egyedi OS image saját konfigurációval

Mivel az OS egy konténer image, a testreszabás is konténeres logikával történik — egy Containerfile-lal:

FROM quay.io/hummingbird-community/bootc-os:latest

# Saját csomagok telepítése
RUN dnf install -y vim htop tmux && dnf clean all

# Saját konfiguráció hozzáadása
COPY my-sshd-config /etc/ssh/sshd_config.d/my-settings.conf

# Saját systemd service engedélyezése
RUN systemctl enable my-service.service

Ez az image aztán buildelhető, pusholható egy registry-be, és bármely Hummingbird-kompatibilis rendszerre telepíthető — legyen az fejlesztői laptop, CI/CD runner, vagy production szerver.

Mi változik a biztonság szempontjából?

A build pipeline izolált, reprodukálható buildeket használ, rögzített csomaglistákból. A konfigurációs drift és a részleges frissítési állapotok az architektúra szintjén ki vannak zárva.

Ez nem marketingszöveg — ez az immutable OS modell alapvető tulajdonsága. Ha a gyökérfájlrendszer csak olvasható, egy támadó — még ha sikerül is kódot futtatnia — nem tudja tartósan módosítani az OS tartalmát. Az újraindítás visszaállítja az eredeti, ismert jó állapotot.

Az x86_64 és aarch64 architektúrákat egyaránt támogatja, és konténerben, virtuális gépen és bare metal telepítésben is fut.

Ez a vége a hagyományos Linuxnak?

Röviden: nem. Fontos megérteni, hogy ez egy korai fázisú projekt, nem a jelenlegi Fedora kiadások helyettesítője.

A Fedora Hummingbird egy meghatározott célközönségnek szól: felhős fejlesztőknek, Kubernetes-operátoroknak, CI/CD infrastruktúrát üzemeltetőknek — azoknak, akik már konténeres gondolkodásmódban élnek, és számukra az OS kezelése legyen ugyanolyan egyszerű, mint egy konténer frissítése.

A Red Hat a Fedora Hummingbirdöt ingyenes belépőpontként pozicionálja a saját AI ökoszisztémájába, amely összeköti a kísérletezést az enterprise környezetekkel RHEL-en és OpenShiften.

A hagyományos asztali felhasználónak, aki egy jól karbantartott, stabil Fedora Workstationt használ, ez a projekt jelenleg nem releváns. De aki szerverparkot üzemeltet, vagy Kubernetes csomópontokat karbantart — az figyeljen oda.

Kipróbálhatod most

Az image már elérhető: quay.io/hummingbird-community/bootc-os. A projekt nyílt forráskódú, és elérhető a GitLabon.

# Az image lehúzása és belső struktúra vizsgálata
podman run --rm quay.io/hummingbird-community/bootc-os:latest ls /

Az OS alap már elérhető a Hummingbird konténer-repository-ból, és a jelenlegi image már most lehúzható és elindítható. Az integrációs munka még folyamatban van — az image jelenleg Hummingbird-built RPM-ek és Fedora csomagok keveréke, és a fejlesztők dolgoznak a kettő szorosabb összehangolásán.

Összefoglalás

A Copy Fail és a Killswitch vita egy kényelmetlenül egyszerű kérdést tett fel: mi lenne, ha az OS architektúrája szintjén zárná ki a részleges frissítési állapotokat és a konfigurációs driftet? A Fedora Hummingbird erre a kérdésre ad egy kísérleti választ — és ha ez a modell bevált, a következő évtized Linux infrastruktúrája egészen másképp fog kinézni.

Forrás: Fedora Magazine, It's FOSS, Linuxiac, Help Net Security