„Systemd 260“: TPM2, smėlio dėžės technologija ir naujos „Linux“ galimybės

Aparatinės įrangos vadovas » Pirkimo vadovai » „Systemd 260“: TPM2, smėlio dėžės technologija ir naujos „Linux“ galimybės

Atsiradus „systemd 260“, „Linux“ distribucijos žengia dar vieną svarbų žingsnį link modernesnės, saugesnės ekosistemos, orientuotos į debesijos aplinkas, virtualizaciją ir automatizavimą. Ši versija ne tik tobulina detales: joje įdiegti reikšmingi pakeitimai, susiję su paleidimu, paslaugų valdymu, tinklu, TPM2 naudojimu vientisumui ir šifravimui bei disko lygio „smėlio dėžės“ galimybėmis.

Tuo pačiu metu projektas stiprina savo dokumentaciją ir požiūrį į darbą su dirbtinio intelekto agentais , aiškiai parodydamas, kad „systemd“ yra labai svarbus ramstis, prie kurio jungiasi vis daugiau kūrimo ir stebėjimo įrankių. Jei tvarkote „Linux“ sistemas serveriuose, debesyje, įmonės kompiuteriuose ar laboratorijose, verta skirti akimirką peržiūrėti visas šias naujas funkcijas, kad suplanuotumėte atnaujinimus ir konfigūracijos koregavimus.

Galutinis atsisveikinimas su „System V“ ir visiška priklausomybe nuo vietinių diskų

Vienas ryškiausių „systemd 260“ pakeitimų yra visiškas „System V“ scenarijų palaikymo pašalinimas . Klasikinis įkrovos procesas, pagrįstas /etc/init.d, buvo palaipsniui panaikintas daugelį metų, tačiau dabar jis praktiškai išnyko iš „systemd“ kodo.

Tai reiškia, kad komponentai, atsakingi už sujungimą tarp „SysV“ scenarijų ir vietinių vienetų, buvo pašalinti: „systemd-rc-local-generator“, „rc-local.service“, „systemd-sysv-generator“ ir „systemd-sysv-install“ . Todėl bet kuri paslauga, kuri vis dar priklauso nuo šių senų mechanizmų, tiesiog nebus paleista sistemose, kurios įdiegia „systemd 260“.

Valymo proceso metu kelios „Meson“ kompiliavimo parinktys taip pat buvo pažymėtos kaip pasenusios arba pašalintos. Vėliavėlės -Drc-local=, -Dsysvinit-path= ir -Dsysvrcnd-path= buvo perkeltos į archyvus, o kitos, pvz. , -Dintegration-tests= ir -Dcryptolib=, buvo visiškai pašalintos. Tai aiškiai rodo: viską dabar turi tvarkyti vietiniai įrenginiai ir moderni „systemd“ infrastruktūra.

Daugeliui Europos infrastruktūrų, kurios vis dar naudoja senesnius komponentus, šis pakeitimas reikalauja peržiūrėti vidines paslaugas, pasirinktinius scenarijus ir senesnius diegimus. Perėjimas prie aiškiai apibrėžtų vienetų failų nebėra tik rekomenduojamas; tai privaloma, jei norite toliau vykdyti paslaugas distribucijose, kuriose integruota „systemd 260“.

Didesni branduolio reikalavimai ir dėmesys dabartinėms aplinkoms

Naujoji versija pakelia kartelę branduoliui: nuo šiol minimali palaikoma „Linux“ versija yra 5.10 , paliekant labai senas šakas, tokias kaip 5.4. Be to, projekte nurodoma, kad idealiu atveju vartotojai turėtų dirbti su 5.14 ar naujesne branduolio versija , ir ypač rekomenduojama 6.6 serija, kad būtų galima visapusiškai išnaudoti visas turimas funkcijas.

Šis reikalavimų padidėjimas paprastai nėra problema šiuolaikiniuose platinimuose, tačiau jis gali apsunkinti reikalus labai konservatyvioje aplinkoje arba daugelį metų palaikomuose įterptuosiuose sprendimuose. Prieš atnaujinant į „systemd 260“, patartina patikrinti, kuris branduolys naudojamas, ypač Europos duomenų centruose, kuriuose diegiami ilgalaikiai procesai arba kuriami pasirinktiniai atvaizdai.

Kitame spektro gale yra riedančių leidimų distribucijos, tokios kaip „Arch Linux“ ar „openSUSE Tumbleweed“, labai populiarios tarp tų, kurie nori naujausių funkcijų, linkusios greitai integruoti tiek naujus branduolius, tiek naujas „systemd“ šakas. Kitos, pavyzdžiui, „Fedora“, išlaiko tam tikrą stabilumą pagrindinėje „systemd“ versijoje per visą kiekvieno leidimo gyvavimo ciklą, o tai suteikia šiek tiek daugiau laiko planuoti perkėlimus.

TPM2, įkrovos vientisumas ir išplėstinis SRK palaikymas

Viena iš sričių, kurioje „systemd“ labiausiai vystosi, yra integracija su TPM2 (Trusted Platform Module 2.0) . Šis lustas, vis labiau paplitęs šiuolaikinėse UEFI pagrindinėse plokštėse ir vidutinės bei aukštos klasės aparatinėje įrangoje, leidžia susieti paslaptis su sistemos būsena, matuoti įkrovos fazes ir automatiškai atrakinti užšifruotus tomus, kai aplinka yra tinkama.

„Systemd 260“ dar labiau patobulina šią integraciją, pridėdama įrankius ir paslaugas, apimančias skirtingus įkrovos proceso etapus. Pagrindinis komponentas yra „systemd-tpm2-setup“ , atsakingas už infrastruktūros, susijusios su TPM saugyklos šakniniu raktu (SRK), paruošimą . Šis šakninis raktas tarnauja kaip kriptografinis pagrindas, užtikrinantis ryšį su lustu ir saugaus kitų paslapčių saugojimo.

Paleidimo metu išskiriami du etapai: labai ankstyvas – initrd diske (initrd) ir antras – šakninėje sistemoje. Pirmajame etape paslauga, vadinama „Ankstyva TPM SRK sąranka“, patikrina, ar TPM jau turi saugomą SRK, o jei jo nėra, jį sukuria ir laikinai padaro prieinamą faile /run/systemd/tpm2-srk-public-key.* . Vėliau, prijungus tikrąją failų sistemą, paslauga sujungs SRK ir patikrins, ar raktas, saugomas faile /var/lib/systemd/tpm2-srk-public-key.pem , atitinka TPM esantį raktą.

Tinkamai sukonfigūruotuose scenarijuose bus rodomi žurnalo įrašai, pvz., „SRK jau saugomas TPM“, ir pranešimai, rodantys, kad SRK pėdsakas atitinka laukiamą. Tačiau jei aplinka nėra tinkamai sukonfigūruota (pvz., sistemose, kuriose naudojama „Yocto“, arba tokiose plokštėse kaip „Raspberry Pi“ su SPI pagrindu veikiančiu TPM ir pasirinktiniais įkrovos metodais, pvz., „U-Boot“ ir išmatuotu įkrovos režimu), gali kilti situacijų, kai „systemd“ nepavyksta sukurti šių failų aplanke /var/lib/systemd, todėl kyla abejonių, ar SRK buvo tinkamai sukonfigūruotas.

Kai pasikeičia TPM būsena, modifikuojami skaidiniai arba pakeičiama paleidimo seka, susijusi politika gali nebegalioti. Tokiais atvejais kai kurie prižiūrėtojai rekomenduoja išvalyti TPM lizdą arba politiką ir iš naujo užregistruoti raktą , laikantis procedūrų, panašių į aprašytas disko šifravimo vadovuose su TPM tokiose aplinkose kaip „openSUSE“, kuriose išsamiai aprašoma, kaip atkurti PCR politiką ir iš naujo susieti tomo atrakinimą.

Be SRK, dar vienas praktinis patobulinimas yra vidinės priemonės, vadinamos „tpm2_id“ , įdiegimas „udev“ . Ši integruota priemonė paleidžiama, kai sistema aptinka TPM2 įrenginį ir automatiškai išgauna gamintojo bei modelio identifikatorių . Tai supaprastina saugos įrangos inventorizaciją, kuri yra labai naudinga viešojo administravimo įstaigose, reguliuojamose įmonėse ar ypatingos svarbos infrastruktūros objektuose, kur būtina tiksliai žinoti, kurie TPM moduliai yra įdiegti.

Integraciją su įkrovos matavimo infrastruktūra dar labiau sustiprina specialūs vienetai, tokie kaip „ systemd-pcrextend“ , kurie registruoja tokius įvykius kaip „enter-initrd“, „leave-initrd“, „sysinit“ ir „ready“ įvairiuose PCR (pvz., PCR 11). Ši plėtinių seka leidžia TPM kaupti kriptografiškai patikrinamą įkrovos srauto įrašą, kurį vėliau galima naudoti patikimos įkrovos politikoms arba UKI (vieningiesiems branduolio atvaizdams), siekiant patikrinti kompiuterio būseną prieš išleidžiant raktus.

Saugumo priemonės ir paslaugų smėlio dėžės kūrimas naudojant „systemd“

„Systemd“ ne tik paleidžia procesus, bet ir siūlo išsamų „smėlio dėžės“ direktyvų rinkinį, skirtą izoliuoti paslaugas ir apriboti žalą kompromitavimo atveju. Šis „gynybos gilumoje“ metodas remiasi cgroups, vardų erdvėmis, branduolio galimybėmis ir sistemos iškvietimų filtrais (seccomp).

Norint įvertinti konkrečios paslaugos saugumą, „systemd“ įtraukia saugos įrankį „systemd-analyze“ . Jį paleidus, sukuriama ataskaita su poveikio balu skalėje nuo 0 iki 10, kur mažesnis balas yra geresnis. Ataskaitoje suskirstoma, kurios apsaugos yra įjungtos arba išjungtos (tinklo izoliacija, prieiga prie failų sistemos, prieiga prie įrenginių ir kt.), todėl lengva nustatyti trūkstamus nustatymus ir patikrinti, ar pakeitimai iš tikrųjų pagerina balą.

Užuot redagavus originalų vienetą (kuris būtų prarastas atliekant būsimus paketų atnaujinimus), rekomenduojama sukurti nepaisyti en /etc/systemd/system/mi-servicio.service.d/ su failu, pavyzdžiui, sandbox.confPakeitus konfigūraciją, tiesiog iš naujo įkelkite ją naudodami systemctl daemon-reload ir paleiskite paslaugą iš naujo, kad įsigaliotų nauji apribojimai.

Failų sistemos lygmeniu vienas iš svarbiausių variantų yra Apsaugoti sistemą=Vertybės, tokios kaip strict, full o true Jie prijungia skirtingas medžio dalis tik skaitymo režimu. Įprasta praktika, kai įmanoma, yra naudoti Apsaugoti sistemą = griežtaTai leidžia /usr, /boot, /efi ir /etc tik skaityti šiai paslaugai. Jei programai reikia rašyti į konkrečius katalogus, ji tai gali daryti naudodama ReadWritePaths=/kelias vienybėje.

Siekiant dar labiau padidinti privatumą, taip pat rekomenduojama apriboti prieigą prie vartotojų katalogų naudojant `ProtectHome=true` , kuris neleidžia paslaugai skaityti `/home`, `/root` arba `/run/user`. Be to, `PrivateTmp=true` sukuria izoliuotas `/tmp` ir `/var/tmp` erdves, užkertant kelią laikinųjų failų matomumui tarp procesų.

Įrenginiuose `PrivateDevices=true` paslepia tikrąjį `/dev` medį ir pakeičia jį minimaliu saugių pseudoįrenginių rinkiniu (null, zero, random ir pan.). Jei diskui reikia konkretaus įrenginio (pavyzdžiui, nuosekliojo prievado arba disko bloko), jį galima suteikti naudojant `DeviceAllow=/dev/xxx rw` arba tik skaitymo režimu.

Tinklas taip pat yra pagrindinis vektorius. Privatus tinklas = tiesa Sukuriama izoliuota tinklo vardų erdvė, paliekant tik kilpinį ryšį; paslauga nematys fizinių sąsajų ir negalės bendrauti su išoriniu pasauliu. Arba galite apriboti, kurias adresų šeimas ji gali naudoti, RestrictAddressFamilies=leidžiant tik AF_INET ir AF_INET6 IPv4/IPv6, AF_UNIX vietiniams lizdams arba net none visiškai japonizuoti tinklo galimybes.

Kalbant apie privilegijas, direktyva „NoNewPrivileges=true“ yra viena iš galingiausių: ji neleidžia procesui įgyti naujų privilegijų naudojant „setuid“ dvejetainius failus arba keičiant galimybes. Trumpai tariant, net jei paslauga vykdo pažeidžiamą kodą, ji neturėtų galėti pereiti į root teises naudojant tradicinius mechanizmus. Kartu su „CapabilityBoundingSet=“ , kuri apibrėžia tikslų leidžiamų galimybių sąrašą (pavyzdžiui, tik „CAP_NET_BIND_SERVICE“, skirta klausytis žemo lygio prievaduose), atakos paviršius sumažinamas iki minimumo.

Dar labiau, „systemd“ leidžia filtruoti sistemos skambučius su SystemCallFilter=Užuot rankiniu būdu tvarkant sisteminių skambučių sąrašą, naudojamos iš anksto nustatytos grupės, pvz. @system-service, @network-io, @basic-io arba neleisti tokioms grupėms kaip ~@privileged. Su systemd-analyze syscall-filter Galima patikrinti, kurie konkretūs skambučiai priklauso kiekvienai grupei. Tai leidžia sukurti labai ribotą vykdymo profilį, panašų į tą, kurį siūlo speciali smėlio dėžė.

Kiti svarbūs nustatymai yra „ProtectKernelTunables=true“ , kuris blokuoja branduolio parametrų modifikavimą `/proc/sys` ir `/sys`; „ProtectKernelModules=true`“ , kuris neleidžia įkelti arba iškelti modulių; „ProtectKernelLogs=true`“ , kuris neleidžia skaityti branduolio žurnalų; ir „ProtectControlGroups=true` , kuris blokuoja rašymą į „cgroups“ hierarchiją. Visa tai sklandžiai veikia su naujomis vartotojų atskyrimo galimybėmis, tokiomis kaip „ PrivateUsers=full“ , kuri 260 versijoje atnaujinta, kad būtų susietas visas vartotojų ID diapazonas, panaikinant ankstesnius sprendimus, reikalingus įdėtoms „systemd“ aplinkoms.

„PrivateUsers“, „xaccess“ ir naujų įrenginių prieigos valdikliai

„PrivateUsers“ mechanizmas , skirtas leisti paslaugoms veikti izoliuotoje vartotojo ID erdvėje, yra konsoliduotas „systemd 260“. Parinktis „PrivateUsers=full “ dabar susieja visą identifikatorių diapazoną, supaprastindama procesą konteineriuose ir sistemose su įdėtaisiais „systemd“ egzemplioriais, pagrįstais senesnėmis versijomis (iki 257). Šis patobulinimas pašalino įsilaužimus, kurie anksčiau buvo naudojami šiems senesniems egzemplioriams aptikti.

Lygiagrečiai tokie komponentai kaip „systemd-logind“ ir „systemd-udevd“ pristatė „xaccess“ koncepciją . Šis mechanizmas papildo klasikinę „uaccess“ logiką , kuri suteikia prieigą prie tam tikrų įrenginių (pavyzdžiui, garso ar vaizdo) vartotojams, turintiems priekinio plano grafikos sesijas vietiniame kompiuteryje. Naudojant „xaccess“, leidimus galima deleguoti nuotoliniams vartotojams su specialiai pažymėtomis sesijomis , kad, pavyzdžiui, per nuotolinį darbalaukį prisijungęs vartotojas galėtų pasiekti vietinius GPU atvaizdavimo įrenginius nesuteikdamas plačių leidimų visai sistemai.

Šių seansų konfigūracija apima aplinkos kintamuosius, prieinamus per PAM, konkrečiai PAMXDG_SESSION_EXTRA_DEVICE_ACCESS= , kuris leidžia apibrėžti, kurie konkretūs įrenginiai yra įtraukti į šią logiką. Šis metodas labai gerai atitinka Europos Sąjungos norminių aktų atitikties ir duomenų apsaugos reikalavimus, kuriuose reikalaujama prieigos prie jautrios aparatinės įrangos detalumo ir atsekamumo.

mstack, systemd-mstack ir nauji konteinerių įrankiai

Konteinerių tvarkymo srityje „systemd 260“ pristato funkcionalumą mstack ir susijusią komandą, systemd-mstack„mstack“ idėja yra leisti apibrėžti Perdangos failų sistema remiantis specialaus katalogo, vadinamo .mstack/, kuris laikosi konkrečios specifikacijos savo sluoksniams organizuoti.

Naujasis komandinės eilutės įrankis „systemd-mstack“ palengvina interaktyvų darbą su šiais failų sistemų paketais, suteikdamas lankstumo nustatant sluoksniuotas aplinkas konteineriams ar labai izoliuotoms paslaugoms. Ši funkcija taip pat susijusi su „systemd-importd“ patobulinimais , kurie išplečia jo palaikymą OCI atvaizdų atsisiuntimui ir valdymui , taip sustiprindami „systemd“ vaidmenį kaip konteinerizavimo ir smėlio dėžės modulio, o tai labai įprasta tarp Europos debesijos paslaugų teikėjų ir šiuolaikinių prieglobos platformų.

Tinklas: integracija su „ModemManager“ ir naujos našumo parinktys

Tinklo lygmenyje „systemd-networkd“ ir toliau įgauna svarbą. Viena iš pastebimų naujų funkcijų yra integracija su „ModemManager“ per „simple connect“ protokolą , kuris leidžia valdyti modemus ir mobiliuosius ryšius tiesiogiai iš „networkd“, nenaudojant išorinių įrankių.

Siekiant paremti šį srautą, pridedamas naujas skyrius. konfigūracijos failuose su tokiais parametrais kaip APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=Tai palengvina diegimą kaimo vietovėse arba aplinkoje, kurioje ryšys pagrįstas mobiliaisiais tinklais, labai paplitęs tam tikrose Europos teritorijose, kur ne visada yra šviesolaidis arba kokybiškos fiksuotojo ryšio linijos.

Kalbant apie našumą, „systemd-networkd .link“ failuose yra naujų parinkčių, skirtų specialiai Ethernet įrenginiams. Tai „ScatterGather“, „ScatterGatherFragmentList“, „TCPECNSegmentationOffload“, „TCPMangleIdSegmentationOffload“, „GenericReceiveOffloadList“ ir „GenericReceiveOffloadUDPForwarding“ . Šios parinktys leidžia tiksliai suderinti darbo perkėlimą į aparatinę įrangą ir tvarkykles, o tai labai svarbu įmonių tinkluose, duomenų centruose ir paslaugų teikėjams, kuriems reikia sumažinti kiekvieną delsos milisekundę.

Be to, „systemd-networkd“ „Varlink“ ir JSON sąsajos dabar gali pateikti IP adresus žmonėms skaitomu formatu (eilutėmis), išlaikydamos sveikųjų skaičių masyvo atvaizdavimą. Tai supaprastina integraciją su stebėjimo ataskaitų suvestinėmis, valdymo scenarijais ar trečiųjų šalių įrankiais, kurie nenori dirbti su neintuityviais skaitiniais formatais.

Paslaugų perkeliamumas, trumpalaikės virtualios mašinos ir neprivilegijuotos paslaugos

„systemd-portabled“ komponentas , atsakingas už atvaizduose supakuotų „perkeliamų“ paslaugų valdymą, įgauna labai įdomią galimybę: dabar jis gali veikti kaip vartotojo lygio paslauga . Tai reiškia, kad neprivilegijuoti vartotojai įprastos sesijos metu gali paleisti ir valdyti perkeliamas paslaugas savo erdvėje, nenaudodami sudo ar padidintų privilegijų.

Be to, nuo šios versijos „portabled“ gali generuoti politikas ir užrakinti su nešiojamąja paslauga susietą atvaizdą , neleisdama modifikuoti to atvaizdo jo neprijungus iš naujo. Tai leidžia vartotojams sukurti savarankiškas aplinkas su papildomomis nekintamumo garantijomis – tai ypač patraukli funkcija laboratorijoms, kūrimo aplinkoms ir bandymų smėlio dėžėms.

Kita vertus, „systemd-vmspawn “ – įrankis, skirtas virtualioms mašinoms paleisti integruotu būdu su „systemd“, – išplečia savo galimybes registruotis su „systemd-machined“ vartotojo sesijos metu . Taip pat pristatoma parinktis „-ephemeral“ , skirta kurti trumpalaikes mašinas, kurios sunaikinamos baigus jas naudoti. Tai puikiai tinka CI/CD kanalams, virtualioms klasėms ar Europos švietimo platformoms, kurioms reikalingas greitas ir kontroliuojamas virtualių mašinų kūrimas ir sunaikinimas.

Tikslus procesoriaus, atminties ir planavimo valdymas naudojant SCHED_EXT ir THP

„Systemd 260“ taip pat gilinasi į našumo valdymą, naudodama naujas politikas. Aptarnavimo parinktis CPUSchedulingPolicy= dabar priimkite vertę ext, kuris aktyvuoja planuoklį SCHED_EXTŠis alternatyvus planuotojas atveria duris eksperimentai su skirtingomis planavimo politikomis prie branduolio standartų, o tai gali būti įdomu mokslinių tyrimų ir plėtros laboratorijoms arba labai specializuotiems diegimams.

Atminties srityje rasite `MemoryTHP=` , kuris leidžia valdyti skaidrių didelių puslapių (THP) naudojimą kiekvienai paslaugai atskirai. Vietoj sistemos masto, visuotinio nustatymo galite nuspręsti, ar konkretus įrenginys turėtų naudoti THP, jį išjungti ar naudoti tarpinius režimus. Svarbiose bankininkystės, draudimo ar vyriausybės programose šis detalus valdymas gali turėti didelės įtakos delsai, atminties sunaudojimui ir našumui.

Naujos komandos systemctl ir išplėstas Varlink naudojimas

Jau pažįstama „systemctl“ komanda įgijo naują pavadinimą: „enqueue-marked“ . Šis veiksmas viduje iškviečia „D-Bus“ metodą „EnqueueMarkedJobs()“ ir leidžia dirbti su iš anksto pažymėtų užduočių ir paslaugų eilėmis. Nors tai gali atrodyti kaip nedidelė detalė, operacijų komandoms, tvarkančioms didelio masto serverių ūkius, tai dar vienas įrankis diegimo ir automatizavimo darbo eigoms tobulinti.

Lygiagrečiai projektas toliau plečia „Varlink“ naudojimą kaip komunikacijos mechanizmą tarp komponentų. Daugelyje „systemd“ dalių yra stabilios „Varlink“ sąsajos, kurios palengvina integraciją su išoriniais įrankiais, pritaikytais ataskaitų suvestinėmis arba stebėjimo agentais, kuriems reikalinga struktūrizuota prieiga prie sistemos informacijos.

Sistemos identifikavimo laukai ir naudotojo patirtis

Keista, bet naudinga nauja kai kurių distribucijų funkcija yra lauko įvedimas IŠPARDAVIMAS= archyve /etc/os-releaseŠis laukas panašus į PRETTY_NAME, bet leidžia ANSI sekos ir sudėtingesni Unicode simboliaiDėl to konkretūs platinimai ir leidimai gali būti pateikiami su akį traukiančiais ar išskirtinesniais pavadinimais.

FANCY_NAME reikšmę galima peržiūrėti per „systemd“ tvarkyklę, naudojant „systemd-hostnamed“ arba užklausiant „hostnamectl“ . Nors tai nedidelis pakeitimas, darbalaukio aplinkose ir grafinėse administravimo plokštėse jis gali būti naudingas norint greitai identifikuoti valdomą sistemą , ypač tvarkant daug išvestinių variantų.

Speciali dokumentacija, skirta dirbtinio intelekto agentams ir pagalbinei peržiūros darbo eigai

Vienas įdomiausių „systemd“ kūrimo krypties požymių yra specialiai dirbtinio intelekto agentams skirtos dokumentacijos atsiradimas . Saugykloje yra failas AGENTS.md , skirtas padėti kodo analizės įrankiams ir programavimo asistentams, taip pat kai kurie technologijų vadovai , padedantys geriau suprasti projekto architektūrą, stilių, kūrimo eigą ir indėlio gaires.

Šiame dokumente aprašomi komponentai, kūrimo keliai, kaip vykdyti testus ir integracijas, bei gairės, kaip generuoti priimtinus pataisymus. Tikslas – suteikti dirbtinio intelekto agentams, kurie peržiūri kodą arba atlieka pakeitimus, tvirtą supratimą apie „systemd“ struktūrą , taip sumažinant klaidų ir netinkamų pasiūlymų skaičių.

Greta AGENTS.md yra failas pavadinimu CLAUDE.md , kuriame aiškiai nurodomas pirmasis failas ir kuris skirtas valdyti „Claude Code“ įrankį – vieną iš plačiausiai naudojamų dirbtiniu intelektu pagrįstų kūrimo asistentų. Tokiu būdu projektas aiškiai įtraukia dirbtinį intelektą į savo kūrimo ciklą.

Be to, pridedamas konfigūracijos failas. claude-review.ymlkur apibrėžiama, kaip, pasitelkiant Claude'o kodą, turėtų būti peržiūrėtas pakeitimų užklausų (pull requests) analizės procesas. Šiame kontekste dirbtinio intelekto panaudojimu paremti įnašai turi būti įtraukti atskleidimo etiketės kaip Co-developed-by pataisose, palikdamas įrodymų, kad kuriant kodą dalyvavo automatizuotas įrankis.

Su šiuo išsamiu pakeitimų rinkiniu – senosios sistemos palaikymo panaikinimu, smėlio dėžės aplinkos patobulinimu, TPM2 ir SRK patobulinimu, pažangia tinklo integracija, naujomis perkeliamumo galimybėmis ir intelektualiems agentams skirta dokumentacija – „systemd 260“ sustiprina savo pagrindinį vaidmenį šiuolaikinėje „Linux“ ekosistemoje. Ispanijos ir Europos administratoriams ir kūrėjams neatidėliotinas iššūkis yra peržiūrėti branduolius, pritaikyti įkrovos konfigūracijas ir paslaugas bei panaudoti šias funkcijas, siekiant sukurti saugesnę, automatizuotą infrastruktūrą, suderintą su dabartiniu sistemos naudojimu.