Ha mostanában ismerkedtél meg a változtathatatlan Linux disztribúciók világával, például a Fedora Silverblue-val, az openSUSE MicroOS-szal, vagy akár a Steam Deckkel, előbb-utóbb bele fogsz futni ebbe a problémába.

Megpróbálsz elvégezni egy egyszerű feladatot, például betenni egy saját scriptet a

/usr/bin

alá, vagy létrehozni egy globális konfigurációs könyvtárat, a terminál pedig hibát dob:

Read-only file system.

Ez kifejezetten frusztráló. A stabilitás, az atomikus frissítések és a rendszer „törhetetlensége” miatt választottál immutable OS-t. Most mégis úgy érzed, mintha csak vendég lennél a saját gépeden.

A hagyományos megoldások – például egy overlay filesystem kézi felcsatolása, vagy a rpm-ostree használata csomagok rétegezéséhez – vagy újraindítást igényelnek, vagy bonyolult, kézi menedzseléssel járnak.

A systemd-sysext-et kifejezetten erre a problémára készítették. Ez a gyakran figyelmen kívül hagyott segédprogram a háttérben az OverlayFS-t használja, de kompatibilitás-ellenőrzést, systemd integrációt és egy szabványos formátumot is ad hozzá. Így futásidőben, dinamikusan tudod a binárisokat és library-ket a

/usr

alá „összefésülni” anélkül, hogy hozzányúlnál az alatta lévő, csak olvasható image-hez, és újraindítás nélkül.

Gyors áttekintés a változtathatatlanságról

Ahhoz, hogy megértsd, miért van szükség a

sysext

-re, először azt kell megértened, miért mozdul a Linux világa a változtathatatlanság felé. Egy hagyományos, „módosítható” disztribúcióban, mint a Ubuntu vagy az Arch, a root filesystem egy hatalmas, írható munkaterület. Bármely root jogosultságú folyamat módosíthat bármilyen fájlt a

/usr

vagy a

/bin

alatt.

Ez ugyan teljes szabadságot ad, de a rendszer „elsodródásának” egyik fő forrása is. Idővel a kézi módosítások, az ütköző library-k és a félresikerült csomagtelepítések kiszámíthatatlanná teszik a rendszert.

A változtathatatlan disztribúciók ezt úgy oldják meg, hogy az operációs rendszert csak olvasható image-ként kezelik. Amikor frissítesz, nem egyes fájlokat cserélgetsz; ehelyett a rendszer egy teljesen új, előre ellenőrzött OS-verzióra vált. Ettől lesz a rendszer „atomikus”: vagy tökéletesen működik, vagy visszagördül az előző verzióra.

A probléma: a „csak olvasható” korlát

Bár a változtathatatlanság remek a stabilitás szempontjából, a „menet közbeni” hibakeresésnél kész rémálom. Egy hagyományos rendszeren, ha meg kell néznem, miért van blokkolva egy hálózati port, gyorsan felrakom az

nmap

-et vagy a

tcpdump

-ot. Egy immutable rendszeren viszont meg vagyok lőve. Ezt könnyen kipróbálhatod azzal, hogy kézzel próbálsz meg hozzáadni egy fájlt a rendszer binárisaihoz:

sudo touch /usr/bin/test_file

A fájl létrehozása helyett elutasító üzenetet kapsz:

touch: cannot touch '/usr/bin/test_file': Read-only file system

. Ez azt bizonyítja, hogy még

sudo

mellett is zárolva van az OS magja. Ha „hivatalosan” akarsz hozzáadni egy eszközt (layering), futtatnod kellene egy parancsot, például

rpm-ostree install

, majd újra kellene indítanod a gépet. Egy gyors feladathoz ez óriási megszakítás. Ráadásul ez a „rpm-ostree” inkább Fedora Silverblue-sajátosság, nem működik a nem Fedora alapú atomic disztrókon.

Hogyan működnek valójában a System Extensions

Én úgy tekintek a

systemd-sysext

-re, mint egy digitális „overlay”-re. Ahelyett, hogy a csak olvasható fájlrendszerrel küzdenénk, felépítünk egy kicsi könyvtárstruktúrát, amiben benne vannak az eszközeink, majd megmondjuk a rendszernek, hogy virtuálisan „olvassza össze” ezt a meglévő

/usr

fölé.

Ehhez egy kernel funkciót használnak, az OverlayFS-t. Az alap (csak olvasható) rendszer lesz a „Lower” réteg, a kiterjesztés pedig az „Upper” réteg. Az eredmény egy „Merged” nézet, amivel a felhasználó dolgozik. Az alkalmazások számára úgy tűnik, mintha a fájlok mindig is ott lettek volna.

1. lépés: az első system extension felépítése

Egy system extension létrehozásához nincs szükség bonyolult build rendszerekre. A legegyszerűbb formájában a

sysext

csak egy könyvtárstruktúra, ami tükrözi a Linux gyökerét. Készítsünk egy munkaterületet egy egyedi eszközhöz. Először tükrözzük a Linux fájlrendszer-hierarchiáját:

mkdir -p my-tool-ext/usr/bin
mkdir -p my-tool-ext/usr/lib/extension-release.d/

Ezután készítsünk egy egyszerű teszteszközt. Valós környezetben ide betehetnél egy lefordított binárist, például az

ncdu

-t vagy a

htop

-ot, de ehhez az útmutatóhoz egy script tökéletes:

echo -e '#!/bin/sh\necho "Sysext is active on Fedora!"' > my-tool-ext/usr/bin/floss-tool
chmod +x my-tool-ext/usr/bin/floss-tool

2. lépés: a metaadatok „útlevele”

Ez a legkritikusabb lépés, és itt szokott elakadni az ember. A

systemd-sysext

kapuőrként működik. Nem fogja összefésülni a kiterjesztést, amíg pontosan nem tudja, melyik OS-verzióhoz készült. Hogy kiderítsd, mit vár el a rendszered, futtasd ezt:

cat /etc/os-release | grep -E '^ID=|^VERSION_ID='

Nálam ez

ID=Fedora

és

VERSION_ID=43

értékeket ad vissza. Ha követed a leírást, mindenképp cseréld ki ezeket az értékeket arra, amit a saját rendszered jelez. Ha Silverblue 39-et használsz, akkor azokat a számokat írd be.

Most hozd létre a kötelező release fájlt:

 
echo "ID=Fedora" > my-tool-ext/usr/lib/extension-release.d/extension-release.my-tool-ext
echo "VERSION_ID=43" >> my-tool-ext/usr/lib/extension-release.d/extension-release.my-tool-ext

Mielőtt bármit összefésülnénk az éles rendszerrel, érdemes még egyszer ellenőrizni a munkánkat. Egy

systemd-sysext

image gyakorlatilag a root könyvtárad tükre, ezért a fájlok hierarchiájának pontosan stimmelnie kell. Az elrendezést így tudod ellenőrizni:

ls -R my-tool-ext

A binárisnak a

usr/bin

alatt kell lennie, a metaadatokat tartalmazó „útlevélnek” pedig a

usr/lib/extension-release.d/

könyvtárban. Ha ezek nincsenek a megfelelő helyen, a rendszer nem fogja tudni, hogyan „térképezze fel” őket az összefésülés során.

3. lépés: az összefésülés

Most, hogy az extension „útlevele” elkészült, áthelyezzük a rendszer extension útvonalára, majd elindítjuk az összefésülést. Ekkor kerüljük meg az írásvédett korlátot:

sudo cp -r my-tool-ext /var/lib/extensions/
sudo systemd-sysext merge

Ezután ellenőrizd a bináris helyét. A rendszernek normál rendszereszközként kell látnia:

ls -l /usr/bin/floss-tool
floss-tool

Az állapotot is ellenőrizheted, és futtathatod az új eszközt:

systemd-sysext status

A rendszered technikailag továbbra is írásvédett, de újraindítás nélkül sikerült új funkciót „beoltanod” bele.

Hibaelhárítás: amikor az összefésülés nem sikerül

Az egyik leggyakoribb bosszúság, amikor ezt a hibát látod:

No suitable extensions found (1 ignored due to incompatible image)

. Ez nem bug, hanem egy biztonsági funkció. Ha az

extension-release

fájl szerint Fedora 42-t használsz, de közben már Fedora 43-ra frissítettél, a

systemd

letiltja az összefésülést.

Erre azért van szükség, mert a libraryk gyakran változnak a verziók között, és egy inkompatibilis bináris összefésülése instabilitást okozhat. Ha ebbe a hibába futsz, egyszerűen frissítsd a metaadatokat, hogy egyezzenek az aktuális

os-release

tartalmával, majd futtasd újra az összefésülést.

Visszaállítás nyom nélkül

A

systemd-sysext

legerősebb tulajdonsága nem csak az, hogy milyen könnyen hozzáad eszközöket, hanem az is, hogy mennyire tisztán el tudja távolítani őket. A hagyományos csomagkezelés gyakran hátrahagy config fájlokat vagy libraryket, amelyek idővel teleszemetelik a rendszert. A

sysext

esetén a visszavonás tiszta elátvolítása a:

sudo systemd-sysext unmerge

Ha most megpróbálod futtatni az eszközt, a shell

No such file or directory

hibát ad. Az overlay eltűnt, és a

/usr

könyvtárad pontosan olyan, mint az OS telepítésekor volt.

Miért jobb ez, mint a konténeres megközelítés

Gyakori kérdés: „Miért nem elég egyszerűen a Distrobox?” A konténerek remekek általános alkalmazásokhoz, de elkülönített névtérben futnak. Ha egy kernel problémát próbálsz debugolni, vagy hardveres perifériákat elemzel, ez az elszigetelés útban lehet. A

systemd-sysext

közvetlenül a hostra teszi az eszközt. Ugyanazokkal a jogosultságokkal és rálátással rendelkezik, mint egy, az OS-sel együtt szállított program. Ha olyan eszközre van szükséged, amely a rendszer részeként működik, nem csak „a rendszeren fut”, akkor a

sysext

a célzott megoldás.

Összegzés

Az immutable Linux felé tett lépésnek nem kell „lezárt” élményt jelentenie. Az olyan eszközök, mint a

systemd-sysext

, megmutatják, hogy a kettő nem zárja ki egymást. Megkapjuk az írásvédett alap biztonságát, és közben megmarad a rugalmasság is: bármilyen szükséges eszközt azonnal be tudunk illeszteni.