- A Systemd 260 véglegesen eltávolítja a System V szkriptek támogatását, és natív egységeket igényel minden szolgáltatáshoz.
- Ez a verzió megerősíti a TPM2-vel való integrációt, beleértve az SRK-kezelést és a segédprogramokat, mint például a tpm2_id és a systemd-pcrextend.
- Jelentősen bővülnek a sandboxing képességek, a hálózatvezérlés és a szolgáltatásonkénti erőforrások, valamint új lehetőségek a konténerek és az efemer gépek számára.
- A projekt AI-ügynökökre vonatkozó speciális dokumentációt és új, támogatott felülvizsgálati munkafolyamatokat tartalmaz a hozzájárulások minőségének javítása érdekében.
Érkezésével rendszer 260 A Linux disztribúciók újabb fontos lépést tesznek egy modernebb, biztonságosabb, felhőalapú környezetekre, virtualizációra és automatizálásra épülő ökoszisztéma felé. Ez a verzió nem csak a részleteket csiszolja: jelentős változtatásokat vezet be a rendszerindítás, a szolgáltatáskezelés, a hálózatépítés, a TPM2 integritás- és titkosítási használata, valamint a meghajtószintű sandboxing képességek terén.
Ugyanakkor a projekt megerősíti a dokumentációját és a velük való munkamódszerét. mesterséges intelligencia ügynökökEz egyértelművé teszi, hogy a systemd egy kritikus pillér, amelyhez egyre több fejlesztői és megfigyelhetőségi eszköz csatlakozik. Ha Linux rendszereket kezel szervereken, a felhőben, vállalati asztali gépeken vagy laboratóriumokban, érdemes egy pillanatot szánni arra, hogy áttekintse ezeket az új funkciókat, hogy megtervezhesse a frissítéseket és a konfigurációs módosításokat.
Végső búcsú a System V-től és a natív meghajtóktól való teljes függőségtől
A systemd 260 egyik legszembetűnőbb változása a a System V szkriptek támogatásának teljes megvonásaA klasszikus, /etc/init.d fájlon alapuló rendszerindítási folyamat évek óta kivezetés alatt állt, de most gyakorlatilag eltűnt a systemd kódból.
Ez azt jelenti, hogy a SysV szkriptek és a natív egységek közötti áthidalásért felelős komponenseket eltávolították: systemd-rc-local-generator, rc-local.service, systemd-sysv-generator és systemd-sysv-install Megszűnnek létezni. Következésképpen minden olyan szolgáltatás, amely továbbra is ezektől az örökölt mechanizmusoktól függ, egyszerűen nem indul el a systemd 260-at használó rendszereken.
A tisztítási folyamat során számos Meson build opciót elavultként vagy eltávolítottként jelöltek meg. A zászlók -Drc-local=, -Dsysvinit-path= és -Dsysvrcnd-path= némelyek az emlékek törzsébe szorulnak, míg mások, mint például -Dintegration-tests= és -Dcryptolib= Közvetlenül eltávolításra kerülnek. Ez egyértelmű üzenet: mindennek natív egységeken és a modern systemd infrastruktúrán kell keresztülmennie.
Számos olyan európai infrastruktúra esetében, amelyek még mindig régebbi komponensekre támaszkodnak, ez a változás szükségessé teszi a belső szolgáltatások, az egyéni szkriptek és a korábbi telepítések felülvizsgálatát. A jól definiált egységfájlokra való migrálás már nem csak ajánlott; kötelező, ha továbbra is futtatni szeretné a szolgáltatásokat a systemd 260-at integráló disztribúciókon.
Magasabb kernelkövetelmények és a jelenlegi környezetekre való összpontosítás
Az új verzió magasabbra teszi a lécet a kernel számára: mostantól a A minimálisan támogatott Linux verzió az 5.10hátrahagyva a nagyon régi ágakat, mint például az 5.4. Ezenkívül a projekt azt jelzi, hogy ideális esetben egy olyan 5.14-os vagy újabb kernelés különösen ajánlja a 6.6 sorozat hogy kihasználhassa az összes elérhető funkciót.
Ez a követelménynövekedés általában nem jelent problémát a modern disztribúciókban, de bonyolíthatja a dolgokat nagyon konzervatív környezetekben vagy évekig karbantartott beágyazott megoldásokban. A systemd 260-ra való frissítés előtt célszerű ellenőrizni, hogy melyik kernelt használják, különösen a következő esetekben: Európai adatközpontok hosszú távú telepítésekkel vagy egyéni képekben.
A spektrum másik végén a gördülő kiadású disztribúciók, mint például az Arch Linux vagy az openSUSE Tumbleweed, amelyek nagyon népszerűek azok körében, akik a legújabb funkciókat szeretnék, általában gyorsan beépítik mind az új kerneleket, mind a systemd új ágait. Mások, mint például a Fedora, bizonyos fokú stabilitást tartanak fenn a systemd főverziójában az egyes kiadások életciklusa során, ami valamivel több időt biztosít a migrációk megtervezésére.
TPM2, rendszerindítási integritás és fejlett SRK-támogatás
A systemd egyik legnagyobb fejlődési területe a következővel való integrációja: TPM2 (Megbízható platform modul 2.0)Ez a chip, amely egyre gyakoribb a modern UEFI alaplapokban, valamint a közép- és felsőkategóriás hardverekben, lehetővé teszi a titkosítások rendszerállapothoz való rögzítését, a rendszerindítási fázisok mérését és... titkosított kötetek feloldása automatikusan, amikor a környezet a vártnak megfelelő.
A Systemd 260 továbbfejleszti ezt az integrációt azáltal, hogy olyan eszközöket és szolgáltatásokat ad hozzá, amelyek a rendszerindítási folyamat különböző szakaszait lefedik. Egy kulcsfontosságú összetevő... systemd-tpm2-setup, amely a körüli infrastruktúra előkészítéséért felelős Tároló gyökérkulcs (SRK) a TPM. Ez a gyökérkulcs szolgál kriptográfiai alapként a chippel való kommunikáció biztonságossá tételéhez és más titkok biztonságos tárolásához.
Az indítás során két fázis különböztethető meg: egy nagyon korai az initrd-ben, és egy másik a gyökérrendszerben. Az elsőben egy „Korai TPM SRK beállítás” nevű szolgáltatás ellenőrzi, hogy a TPM-nek van-e már tárolt SRK-ja, és ha nem létezik, létrehozza azt, és ideiglenesen elérhetővé teszi a következő címen: /run/systemd/tpm2-srk-public-key.*Később, miután a tényleges fájlrendszer felcsatolódott, a szolgáltatás összevonja az SRK-t, és ellenőrzi, hogy a benne tárolt kulcs a /var/lib/systemd/tpm2-srk-public-key.pem Ez egybeesik a TPM-ben szereplővel.
Jól konfigurált forgatókönyvekben ilyen naplóbejegyzések láthatók. "Az SRK már el van mentve a TPM-ben" és üzeneteket, amelyek azt jelzik, hogy az SRK lábnyoma megegyezik a várttal. Ha viszont a környezet nincs összehangolva (például Yocto-val rendelkező beállításokban vagy olyan alaplapokon, mint a Raspberry Pi SPI TPM-mel és egyéni rendszerindítási metódusokkal U-Boot-tal és mért rendszerindítással), előfordulhatnak olyan helyzetek, amikor a systemd nem tudja létrehozni ezeket a fájlokat a /var/lib/systemd alatt, ami kétségeket vet fel azzal kapcsolatban, hogy az SRK megfelelően van-e konfigurálva.
Amikor a TPM állapota megváltozott, a partíciók módosultak, vagy a rendszerindítási folyamat megváltozott, a kapcsolódó szabályzat már nem alkalmazható. Ilyen esetekben egyes karbantartók azt javasolják, hogy Töröld a TPM nyílást vagy szabályzatot, és regisztráld újra a kulcsot, a lemeztitkosítási útmutatókban leírtakhoz hasonló eljárásokat követve, TPM-mel olyan környezetekben, mint az openSUSE, ahol részletesen ismertetik a PCR-házirend újralétrehozását és a kötet feloldásának újbóli összekapcsolását.
Az SRK mellett egy másik gyakorlati fejlesztés az udev-ben egy belső segédprogram bevezetése, az úgynevezett tpm2_azonosítóEz az integrált eszköz akkor fut, amikor a rendszer TPM2 eszközt észlel, és Automatikusan kinyeri a gyártó azonosítóját és a modellt.Ez leegyszerűsíti a biztonsági hardverek leltározását, ami nagyon hasznos a közigazgatásban, a szabályozott vállalatoknál vagy a kritikus infrastruktúráknál, ahol pontosan tudni kell, hogy mely TPM modulok vannak telepítve.
A startup mérési infrastruktúrával való integrációt olyan specifikus egységekkel is megerősítik, mint például systemd-pcrextendamelyek olyan eseményeket naplóznak, mint az „enter-initrd”, a „leave-initrd”, a „sysinit” vagy a „ready” különböző PCR-ekben (például PCR 11). Ez a bővítménysorozat lehetővé teszi a TPM számára, hogy kriptográfiailag ellenőrizhető rekordot gyűjtsön a rendszerindítási folyamatról, amelyet aztán felhasználhat a megbízható rendszerindítási szabályzatokhoz vagy a következőhöz: UKI (Egységes Kernel Images) amelyek a billentyűk elengedése előtt ellenőrzik a gép állapotát.
Biztonsági intézkedések és szolgáltatások sandboxolása a systemd segítségével
A Systemd nemcsak folyamatokat indít, hanem nagyon széleskörű lehetőségeket is kínál. sandboxing irányelvek a szolgáltatások elkülönítése és a károk korlátozása kompromittálás esetén. Ez a „mélyreható védelem” megközelítés cgroupokra, névterekre, kernel képességekre és rendszerhívás-szűrőkre (seccomp) támaszkodik.
Egy adott szolgáltatás állapotának felméréséhez a systemd tartalmazza az eszközt systemd-biztonsági elemzésFuttatáskor egy jelentést generál, amely 0-tól 10-ig terjedő skálán mutatja a kitettségi indexet, ahol az alacsonyabb érték jobb. A jelentés lebontja az engedélyezett vagy hiányzó védelmeket (hálózati izoláció, fájlrendszer-hozzáférés, eszközök stb.), így a sebezhetőségek észlelése rendkívül egyszerű. milyen kiigazításokra van szükség és ellenőrizd, hogy a bevezetett változtatások valóban javítják-e az eredményt.
Az eredeti egység szerkesztése helyett – amely a jövőbeli csomagfrissítésekben elveszne – ajánlott egy felülírás en /etc/systemd/system/mi-servicio.service.d/ egy fájllal, például sandbox.confA módosítás után egyszerűen töltse be újra a konfigurációt a következővel: systemctl daemon-reload és indítsa újra a szolgáltatást, hogy az új korlátozások érvénybe lépjenek.
Fájlrendszer szinten az egyik legfontosabb lehetőség a Védőrendszer=Olyan értékek, mint például strict, full o true A fa különböző részeit csak olvasható módban csatolják. A szokásos gyakorlat, amikor lehetséges, a következő használata: ProtectSystem=strictEzáltal a /usr, /boot, /efi és /etc könyvtárak írásvédetté válnak a szolgáltatás számára. Ha egy alkalmazásnak adott könyvtárakba kell írnia, akkor ezt a következőképpen teheti meg: ReadWritePaths=/elérésiút egységben.
Az adatvédelem további fokozása érdekében ajánlott a felhasználói könyvtárakhoz való hozzáférés korlátozása is a következőkön keresztül: ProtectHome=trueami megakadályozza, hogy a szolgáltatás olvassa a /home, /root vagy /run/user könyvtárakat. Továbbá, PrivateTmp=true Létrehoz egy elszigetelt /tmp és /var/tmp területet, megakadályozva az ideiglenes fájlok folyamatok közötti láthatóságát.
Az eszközökön, PrivateDevices=true Elrejti a tényleges /dev fát, és egy minimális számú biztonságos pszeudo-eszközzel helyettesíti (null, nulla, véletlenszerű stb.). Ha egy egységnek egy adott eszközre van szüksége (például egy soros portra vagy egy lemezblokkra), akkor az a következőképpen adható meg: DeviceAllow=/dev/xxx rw vagy írásvédett módban.
A hálózat szintén kulcsfontosságú vektor. PrivateNetwork=true Létrejön egy elszigetelt hálózati névtér, csak a loopback marad meg; a szolgáltatás nem fogja látni a fizikai interfészeket, és nem lesz képes kommunikálni a külvilággal. Alternatív megoldásként korlátozhatja, hogy mely címcsaládokat használhatja a következőképpen: RestrictAddressFamilies=csak az AF_INET és az AF_INET6 engedélyezett IPv4/IPv6 esetén, az AF_UNIX helyi socketekhez, vagy akár none a hálózati képességek teljes japánosítása.
A kiváltságokat illetően az irányelv NincsenekÚjJogjogosultságok=igaz Ez az egyik legerősebb: megakadályozza, hogy a folyamat új jogosultságokat szerezzen setuid binárisokon vagy képességmódosításokon keresztül. Röviden, még ha a szolgáltatás sebezhető kódot is futtat, nem szabadna képesnek lennie arra, hogy a hagyományos mechanizmusokon keresztül root jogosultságra emelkedjen. A következőkkel kombinálva: CapabilityBoundingSet=Az engedélyezett képességek pontos listájának meghatározásával (pl. csak a CAP_NET_BIND_SERVICE figyelhet az alacsony portokon) minimalizálható a támadási felület.
Még tovább menve, a systemd lehetővé teszi a rendszerhívások szűrését a következővel: SystemCallFilter=A rendszerhívások manuális listájának fenntartása helyett előre definiált csoportokat használnak, például @system-service, @network-io, @basic-io vagy tagadja meg az olyan csoportokat, mint ~@privileged. a systemd-analyze syscall-filter Lehetőség van megvizsgálni, hogy mely hívások tartoznak az egyes csoportokhoz. Ez lehetővé teszi egy nagyon korlátozott végrehajtási profil felépítését, hasonlóan ahhoz, amit egy dedikált tesztkörnyezet kínálna.
Egyéb releváns kiigazítások a következők: ProtectKernelTunables=true, amely blokkolja a kernel paraméterek módosítását a /proc/sys és /sys könyvtárakban, ProtectKernelModules=trueami megakadályozza a modulok be- vagy kirakodását, ProtectKernelLogs=trueami megakadályozza a kernel regiszterek olvasását, és ProtectControlGroups=trueamely blokkolja a cgroups hierarchiába való írást. Mindez zökkenőmentesen ötvözhető az új felhasználóelkülönítési képességekkel, mint például a PrivateUsers=full, amely a 260-as verzióban frissült, hogy a felhasználói azonosítók teljes skáláját leképezze, kiküszöbölve a beágyazott systemd-vel rendelkező környezetekhez korábban szükséges kerülő megoldásokat.
PrivateUsers, xaccess és új eszközhozzáférés-vezérlés
A mechanizmus Privát felhasználókÚgy tervezték, hogy szolgáltatásokat futtasson egy elszigetelt felhasználói azonosítójú területen, és a systemd 260-ban van konszolidálva. A beállítás PrivateUsers=full Mostantól az azonosítók teljes skáláját leképezi, leegyszerűsítve a dolgokat konténerekben és a régebbi (257 előtti) verziókon alapuló beágyazott systemd példányokkal rendelkező rendszereken. Ez a fejlesztés kiküszöbölte a régebbi példányok észlelésére használt hackeket.
Ezzel párhuzamosan olyan komponensek, mint pl. systemd-logind és systemd-udevd Bevezetik a koncepciót, xaccessEz a mechanizmus kiegészíti a klasszikus logikát uaccessAz xaccess hozzáférést biztosít bizonyos eszközökhöz (pl. hang- vagy videóeszközökhöz) a helyi gépen előtérben futó grafikus munkamenettel rendelkező felhasználók számára. Az engedélyek delegálhatók az xaccess-nek. távoli felhasználók speciálisan megjelölt munkamenetekkelígy például egy távoli asztalon keresztül csatlakozó felhasználó hozzáférhet a helyi GPU renderelő eszközökhöz anélkül, hogy széleskörű jogosultságokat adna a teljes rendszernek.
Ezen munkamenetek konfigurációja magában foglalja a PAM-on keresztül elérhető környezeti változókat, konkrétan PAMXDG_SESSION_EXTRA_DEVICE_ACCESS=Ez lehetővé teszi annak meghatározását, hogy mely konkrét eszközök tartoznak ebbe a keretrendszerbe. Ez a megközelítés nagymértékben összhangban van az Európai Unió szabályozási megfelelőségi és adatvédelmi követelményeivel, amelyek részletességet és nyomon követhetőséget követelnek meg az érzékeny hardverekhez való hozzáférésben.
mstack, systemd-mstack és új konténereszközök
A konténerezés területén a systemd 260 bemutatja a funkcionalitást mstack és egy hozzá tartozó parancs, systemd-mstackAz mstack mögött az a gondolat áll, hogy lehetővé tegye egy OverlayFS nevű speciális könyvtár szerkezetén alapul .mstack/, amely a rétegek rendszerezésére egy adott specifikációt követ.
Az új parancssori eszköz, a systemd-mstack, megkönnyíti a fájlrendszer-"vermek" interaktív kezelését, rugalmasságot biztosítva a réteges környezetek beállításakor konténerek vagy erősen elszigetelt szolgáltatások számára. Ez a funkció a következő fejlesztésekhez is kapcsolódik: systemd-importd, amely kiterjeszti támogatását a következőkre: OCI-képek letöltése és kezeléseEz megerősíti a systemd szerepét, mint konténerizációs és sandboxing motor, ami nagyon gyakori az európai felhőszolgáltatóknál és a modern tárhelyplatformoknál.
Hálózat: Integráció a ModemManagerrel és új teljesítménynövelő opciók
A hálózati rétegen a systemd-networkd egyre nagyobb jelentőségre tesz szert. Az egyik figyelemre méltó új funkciója a következő: integráció a ModemManagerrel az „egyszerű csatlakozás” protokoll használatávalEz lehetővé teszi a modemek és a mobilkapcsolatok közvetlen kezelését a networkd-ből, külső eszközök használata nélkül.
Ennek a folyamatnak a támogatása érdekében egy új szakasz került hozzáadásra. a konfigurációs fájlokhoz, olyan paraméterekkel, mint APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=Ez megkönnyíti a telepítéseket a vidéki területeken vagy mobilhálózatokon alapuló kapcsolattal rendelkező környezetben, nagyon elterjedt Európa bizonyos területein, ahol nem mindig van optikai kábel vagy minőségi vezetékes telefon.
Teljesítmény szempontjából a fájlok .link A systemd-networkd új, kifejezetten Ethernet-eszközökhöz készült opciókat tartalmaz. Ezek közé tartoznak: ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList és GenericReceiveOffloadUDPForwardingEzek a beállítások lehetővé teszik a munka hardverre és illesztőprogramokra történő áthárításának finomhangolását, ami kulcsfontosságú a vállalati hálózatokban, adatközpontokban és szolgáltatóknál, akiknek minimalizálniuk kell a késleltetés minden egyes milliszekundumát.
Továbbá, az interfészek Varlink és JSON A systemd-networkd mostantól képes IP-címeket jelenteni egy formátumban ember által olvasható (karakterláncok), miközben megőrzi az egész számok tömbjeként való ábrázolást. Ez leegyszerűsíti az integrációt a monitorozó irányítópultokkal, adminisztrációs szkriptekkel vagy harmadik féltől származó eszközökkel, amelyek nem kívánnak nem intuitív numerikus formátumokkal foglalkozni.
Szolgáltatáshordozhatóság, rövid életű virtuális gépek és nem privilegizált szolgáltatások
A darab systemd-portabledA képekbe csomagolt „hordozható” szolgáltatások kezeléséért felelős szoftver egy nagyon érdekes képességre tesz szert: képes futni felhasználói szintű szolgáltatáskéntEz azt jelenti, hogy a privilégium nélküli felhasználók normál munkamenetükben elindíthatnak és kezelhetnek hordozható szolgáltatásokat a saját területükön belül anélkül, hogy sudo-t vagy emelt szintű jogosultságokat kellene igénybe venniük.
Továbbá, ettől a verziótól kezdve a hordozható szabályzatok létrehozása és egy hordozható szolgáltatáshoz társított rendszerkép létrehozásaEz megakadályozza, hogy a képfájlt újra csatolás nélkül módosítsák. A felhasználók így önálló környezeteket hozhatnak létre a megváltoztathatatlanság további garanciáival, ami meglehetősen vonzó a laboratóriumok, fejlesztői környezetek és tesztkörnyezetek számára.
Továbbá, systemd-vmspawn —az eszköz, amelyet virtuális gépek systemd-vel integrált indítására terveztek— kibővíti a regisztráció lehetőségeit systemd-machined a felhasználói munkameneten belülBemutat egy lehetőséget is -tiszavirág életű hogy olyan rövid életű gépeket hozzanak létre, amelyeket használatuk végén megsemmisítenek. Ez tökéletesen illeszkedik a CI/CD-folyamatokhoz, a virtuális tantermekhez vagy az európai oktatási platformokhoz, amelyek megkövetelik gépek gyors és ellenőrzött emelésére és húzására.
Finomhangolt CPU, memória és ütemezés vezérlés SCHED_EXT és THP segítségével
A Systemd 260 új szabályzatokkal a teljesítményvezérlésbe is belemerül. A szolgáltatási opció CPUSchedulingPolicy= most fogadd el az értéket ext, ami aktiválja az ütemezőt SCHED_EXTEz az alternatív tervező megnyitja az utat kísérletezések különböző tervezési politikákkal a kernel szabványokhoz, ami érdekes lehet a K+F laboratóriumokban vagy a magasan specializált telepítésekben.
A memóriaterületen megjelenik MemóriaTHP=amely lehetővé teszi a használat kezelését Átlátszó hatalmas oldalak (THP) szolgáltatásonként. A teljes rendszerre vonatkozó globális viselkedés helyett eldönthető, hogy egy adott egység kihasználja-e a THP előnyeit, letiltja-e azt, vagy köztes módokat alkalmazzon. A banki, biztosítási vagy közigazgatási kritikus alkalmazások esetében ez a részletes szabályozás különbséget jelenthet a következőkben: késleltetés, memóriafogyasztás és teljesítmény.
Új parancsok a systemctl-ben és a Varlink kibővített használata
A jól ismert kommandós systemctl új megrendelést nyer: sorba helyezés jelölésselEz a művelet belsőleg meghívja a D-Bus metódust. Sorba helyezésJelöltJobok() és lehetővé teszi az előre kiválasztott feladatok és szolgáltatások soraival való munkát. Bár ez apró részletnek tűnhet, kulcsfontosságú az operatív csapatok számára, akik összehangolják a feladatokat. nagyméretű szerverfarmok Ez egy újabb eszköz a telepítési és automatizálási munkafolyamatok finomítására.
Ezzel párhuzamosan a projekt folytatja a következők használatának bővítését: Varlink komponensek közötti kommunikációs mechanizmusként. A systemd számos része stabil Varlink interfészeket tesz elérhetővé, amelyek megkönnyítik az integrációt külső eszközökkel, egyéni műszerfalakkal vagy monitorozó ügynökökkel, amelyeknek strukturált hozzáférésre van szükségük a rendszerinformációkhoz.
Rendszerazonosító mezők és felhasználói élmény
Egy érdekes, de hasznos új funkció egyes disztribúciókban a mező bevezetése. KÜLÖNLEGES_NÉV= az archívumban /etc/os-releaseEz a mező hasonlít a PRETTY_NAME mezőre, de engedélyezi ANSI szekvenciák és bonyolultabb Unicode karakterekEnnek köszönhetően az egyes disztribúciók és kiadások figyelemfelkeltőbb vagy jellegzetesebb nevekkel jeleníthetők meg.
A FANCY_NAME értéke a systemd kezelőn keresztül tekinthető meg a következő használatával: systemd-hostnamed vagy konzultáció során hostnamectlBár apró változásról van szó, asztali környezetekben és grafikus adminisztrációs paneleken hasznos lehet a következők számára: a rendszer egy pillantással történő azonosítása amelyet kezelnek, különösen sok származtatott változat esetén.
AI-ügynökökre és segített felülvizsgálati munkafolyamatra vonatkozó speciális dokumentáció
A systemd fejlesztés irányának egyik legérdekesebb jele a kifejezetten erre irányuló dokumentáció megjelenése. mesterséges intelligencia ügynökökEgy fájl szerepel a tárházban AGENTS.mdkódelemző eszközökhöz és programozási asszisztensekhez tervezték, és ahogy néhányan megjegyezték technológiai útmutatók, jobban megértsék a projekt architektúráját, stílusát, fejlesztési folyamatát és közreműködési irányelveit.
Ez a dokumentum leírja a komponenseket, a build útvonalakat, a tesztek és integráció futtatásának módját, valamint az elfogadható javítások létrehozásának irányelveit. A cél az, hogy a kódot felülvizsgáló vagy módosításokat generáló MI-ügynökök együttműködhessenek a következőkkel: szilárd kontextus a systemd felépítésérőla hibák és a félreértett javaslatok csökkentése.
Az AGENTS.md mellett megjelenik egy fájl, melynek neve CLAUDE.mdEz explicit módon hivatkozik az elsőre, és a Claude Code eszköz, az egyik legszélesebb körben használt mesterséges intelligencia alapú fejlesztői asszisztens irányítására összpontosít. Ily módon a projekt explicit módon beépíti a mesterséges intelligenciát a fejlesztési ciklusába.
Ezenkívül egy konfigurációs fájl is tartozik hozzá. claude-review.ymlahol a Claude Code segítségével meghatározzák, hogyan kell felülvizsgálni a módosítási kérelmek (pull requestek) elemzésének folyamatát. Ebben az összefüggésben a mesterséges intelligenciát használó közreműködéseknek tartalmazniuk kell közzétételi címkék mint Co-developed-by a javításokban, bizonyítékot hagyva arra, hogy egy automatizált eszköz részt vett a kód létrehozásában.
Mindezen változtatásokkal – a régi támogatás megszüntetésével, a sandboxing finomításával, a TPM2 és az SRK fejlesztéseivel, a fejlett hálózati integrációval, az új hordozhatósági képességekkel és az intelligens ügynökök számára tervezett dokumentációval – rendszer 260 Ez megerősíti központi szerepét a modern Linux ökoszisztémában. A spanyol és európai rendszergazdák és fejlesztők számára az azonnali kihívás a kernelek felülvizsgálata, a rendszerindítási konfigurációk és szolgáltatások adaptálása, valamint ezen funkciók kihasználása a jelenlegi rendszerhasználattal összhangban lévő biztonságosabb, automatizált infrastruktúrák kiépítése érdekében.