Systemd 260: TPM2, sandboxing dhe aftësi të reja në Linux

Përditësimi i fundit: 17 prill 2026
Author: Isaac
  • Systemd 260 heq përgjithmonë mbështetjen për skriptet e System V dhe kërkon njësi vendase për të gjitha shërbimet.
  • Ky version forcon integrimin me TPM2, duke përfshirë menaxhimin e SRK dhe shërbimet si tpm2_id dhe systemd-pcrextend.
  • Aftësitë e sandboxing-ut, kontrolli i rrjetit dhe burimet për shërbim janë zgjeruar ndjeshëm, së bashku me opsione të reja për kontejnerët dhe makinat epemerale.
  • Projekti përfshin dokumentacion specifik për agjentët e inteligjencës artificiale dhe rrjedha të reja pune të rishikimit të asistuar për të përmirësuar cilësinë e kontributeve.

Çfarë ka të re në systemd 260 me TPM2 dhe sandboxing

Me mbërritjen e systemd 260, shpërndarjet Linux po bëjnë një hap tjetër të rëndësishëm drejt një ekosistemi më modern dhe të sigurt të orientuar drejt mjediseve cloud, virtualizimit dhe automatizimit. Ky version nuk thjesht përmirëson detajet: ai prezanton ndryshime të rëndësishme në nisje, menaxhim shërbimesh, rrjetëzim, përdorimin e TPM2 për integritet dhe enkriptim, si dhe aftësitë e sandboxing në nivel disku.

Në të njëjtën kohë, projekti po forcon dokumentacionin dhe qasjen e tij ndaj punës me agjentët e inteligjencës artificiale , duke e bërë të qartë se systemd është një shtyllë kritike me të cilën po lidhen gjithnjë e më shumë mjete zhvillimi dhe vëzhgimi. Nëse menaxhoni sisteme Linux në servera, në cloud, në desktopë të korporatave ose në laboratorë, ia vlen të ndani një moment për të shqyrtuar të gjitha këto veçori të reja për të planifikuar përditësimet dhe rregullimet e konfigurimit.

Sistemi i shpëtimit SystemRescue
Artikuj të ngjashëm:
SystemRescue: sistemi përfundimtar i shpëtimit për PC-në tuaj

Një lamtumirë e fundit për System V dhe varësinë totale nga disqet native

Një nga ndryshimet më të habitshme në systemd 260 është heqja e plotë e mbështetjes për skriptet e System V. Procesi klasik i nisjes i bazuar në /etc/init.d ishte hequr gradualisht për vite me radhë, por tani ai praktikisht zhduket nga kodi systemd.

Kjo do të thotë që komponentët përgjegjës për lidhjen midis skripteve SysV dhe njësive native janë hequr: systemd-rc-local-generator, rc-local.service, systemd-sysv-generator dhe systemd-sysv-install nuk ekzistojnë më. Si rezultat, çdo shërbim që ende varet nga këto mekanizma të trashëguar thjesht nuk do të fillojë në sistemet që përdorin systemd 260.

Gjatë procesit të pastrimit, disa opsione ndërtimi të Meson janë shënuar gjithashtu si të vjetruara ose të hequra. Flamujt -Drc-local=, -Dsysvinit-path= dhe -Dsysvrcnd-path= janë dërguar në arkiva, ndërsa të tjerë si -Dintegration-tests= dhe -Dcryptolib= janë hequr tërësisht. Kjo dërgon një mesazh të qartë: gjithçka tani duhet të trajtohet nga njësitë vendase dhe infrastruktura moderne systemd.

Për shumë infrastruktura evropiane që ende mbështeten në komponentë të vjetër, ky ndryshim kërkon një rishikim të shërbimeve të brendshme, skripteve të personalizuara dhe vendosjeve të trashëguara. Migrimi në skedarë njësie të përcaktuara mirë nuk rekomandohet më vetëm; është i detyrueshëm nëse doni të vazhdoni të ekzekutoni shërbime në shpërndarje që integrojnë systemd 260.

Kërkesa më të larta për bërthamën dhe një fokus në mjediset aktuale

Versioni i ri ngre nivelin për kernelin: që nga tani e tutje, versioni minimal i mbështetur i Linux është 5.10 , duke lënë pas degë shumë të vjetra si 5.4. Për më tepër, projekti tregon se idealisht, përdoruesit duhet të punojnë në një kernel 5.14 ose më të lartë , dhe veçanërisht rekomandon serinë 6.6 për të përfituar plotësisht nga të gjitha veçoritë e disponueshme.

Kjo rritje e kërkesave zakonisht nuk është problem në shpërndarjet moderne, por mund t'i ndërlikojë gjërat në mjedise shumë konservatore ose zgjidhje të integruara që mirëmbahen për shumë vite. Para se të azhurnoni në systemd 260, këshillohet të verifikoni se cili bërthamë po përdoret, veçanërisht në qendrat evropiane të të dhënave me vendosje afatgjata ose imazhe të personalizuara.

Në anën tjetër të spektrit, shpërndarjet e versioneve të reja si Arch Linux ose openSUSE Tumbleweed, shumë të njohura në mesin e atyre që duan veçoritë më të fundit, kanë tendencë të përfshijnë shpejt si bërthama të reja ashtu edhe degë të reja të systemd. Të tjera, si Fedora, ruajnë një shkallë stabiliteti në versionin kryesor të systemd gjatë gjithë ciklit jetësor të çdo versioni, gjë që lejon pak më shumë kohë për të planifikuar migrimet.

TPM2, integriteti i nisjes dhe mbështetja e përparuar e SRK-së

Një nga fushat ku systemd po evoluon më shumë është integrimi i tij me TPM2 (Trusted Platform Module 2.0) . Ky çip, gjithnjë e më i zakonshëm në motherboard-et moderne UEFI dhe pajisjet e nivelit të mesëm dhe të lartë, lejon ankorimin e sekreteve në gjendjen e sistemit, matjen e fazave të nisjes dhe zhbllokimin automatik të vëllimeve të enkriptuara kur mjedisi është sipas pritjeve.

Systemd 260 e përmirëson më tej këtë integrim duke shtuar mjete dhe shërbime që mbulojnë faza të ndryshme të procesit të nisjes. Një komponent kyç është systemd-tpm2-setup , përgjegjës për përgatitjen e infrastrukturës rreth Çelësit të Rrënjës së Storage (SRK) të TPM-së . Ky çelës rrënjë shërben si bazë kriptografike për sigurimin e komunikimit me çipin dhe për ruajtjen e sigurt të sekreteve të tjera.

Gjatë nisjes, dallohen dy faza: njëra shumë e hershme në initrd dhe një tjetër një herë në sistemin rrënjë. Në të parën, një shërbim i quajtur "Early TPM SRK Setup" kontrollon nëse TPM ka tashmë një SRK të ruajtur dhe, nëse nuk ekziston, e krijon atë dhe e bën të disponueshëm përkohësisht nën /run/systemd/tpm2-srk-public-key.* . Më vonë, pasi të jetë montuar sistemi i vërtetë i skedarëve, shërbimi do të konsolidojë SRK-në dhe do të verifikojë që çelësi i ruajtur në /var/lib/systemd/tpm2-srk-public-key.pem përputhet me atë në TPM.

  Kontroll i plotë dhe audio e gjallë: Razer Kraken V4 Pro, arma juaj e re e lojërave

Në skenarë të konfiguruar mirë, do të shfaqen shënime në ditar si "SRK është ruajtur tashmë në TPM" dhe mesazhe që tregojnë se gjurma e SRK përputhet me atë të pritur. Megjithatë, nëse mjedisi nuk është konfiguruar siç duhet (për shembull, në konfigurime që përdorin Yocto ose në borde si Raspberry Pi me TPM të bazuar në SPI dhe metoda të personalizuara të nisjes si U-Boot dhe nisja e matur), mund të lindin situata ku systemd nuk arrin të krijojë këto skedarë nën /var/lib/systemd, duke ngritur dyshime nëse SRK është konfiguruar saktë.

Kur gjendja e TPM-së ka ndryshuar, ndarjet janë modifikuar ose sekuenca e nisjes është ndryshuar, politika përkatëse mund të mos jetë më e vlefshme. Në raste të tilla, disa mirëmbajtës rekomandojnë pastrimin e vendit ose politikës TPM dhe riregjistrimin e çelësit , duke ndjekur procedura të ngjashme me ato të përshkruara në udhëzuesit e enkriptimit të diskut me TPM në mjedise si openSUSE, të cilat detajojnë se si të rikrijohet politika PCR dhe të rilidhet zhbllokimi i vëllimit.

Përveç SRK-së, një tjetër përmirësim praktik është futja e një programi të brendshëm të quajtur tpm2_id në udev . Ky mjet i integruar funksionon kur sistemi zbulon një pajisje TPM2 dhe automatikisht nxjerr identifikuesin e prodhuesit dhe modelit . Kjo thjeshton inventarin e pajisjeve të sigurisë, i cili është shumë i dobishëm në administratat publike, kompanitë e rregulluara ose infrastrukturat kritike ku është thelbësore të dihet saktësisht se cilat module TPM janë vendosur.

Integrimi me infrastrukturën e matjes së nisjes forcohet më tej nga njësi specifike si systemd-pcrextend , të cilat regjistrojnë ngjarje të tilla si "enter-initrd", "leave-initrd", "sysinit" dhe "ready" në PCR të ndryshme (p.sh., PCR 11). Kjo sekuencë zgjerimesh lejon TPM-në të grumbullojë një regjistrim të verifikueshëm kriptografikisht të rrjedhës së nisjes, i cili më pas mund të përdoret për politikat e Nisjes së Besueshme ose për UKI (Imazhe të Unifikuara të Kernelit) për të validuar gjendjen e makinës para lëshimit të çelësave.

Masat e sigurisë dhe sandboxing i shërbimeve me systemd

Systemd jo vetëm që nis proceset, por ofron edhe një grup gjithëpërfshirës direktivash sandbox për të izoluar shërbimet dhe për të kufizuar dëmet në rast të një komprometimi. Kjo qasje e "mbrojtjes në thellësi" mbështetet në grupet c, hapësirat e emrave, aftësitë e bërthamës dhe filtrat e thirrjeve të sistemit (seccomp).

Për të vlerësuar sigurinë e një shërbimi specifik, systemd përfshin mjetin e sigurisë systemd-analyze . Ekzekutimi i tij gjeneron një raport me një rezultat ekspozimi në një shkallë nga 0 deri në 10, ku një rezultat më i ulët është më i mirë. Raporti analizon se cilat mbrojtje janë të aktivizuara ose të çaktivizuara (izolimi i rrjetit, qasja në sistemin e skedarëve, qasja në pajisje, etj.), duke e bërë të lehtë identifikimin e cilësimeve që mungojnë dhe verifikimin nëse ndryshimet e përmirësojnë në të vërtetë rezultatin.

Në vend që të modifikoni njësinë origjinale—e cila do të humbiste në përditësimet e ardhshme të paketave—rekomandohet të krijoni një shkel en /etc/systemd/system/mi-servicio.service.d/ me një skedar, për shembull, sandbox.confPasi ta modifikoni, thjesht ringarkoni konfigurimin me systemctl daemon-reload dhe rinisni shërbimin në mënyrë që kufizimet e reja të hyjnë në fuqi.

Në nivelin e sistemit të skedarëve, një nga opsionet më të rëndësishme është Mbrojtja e Sistemit=Vlera të tilla si strict, full o true Ata montojnë pjesë të ndryshme të pemës në modalitetin vetëm për lexim. Praktika e zakonshme, kur është e mundur, është përdorimi i ProtectSystem=strictKjo i bën /usr, /boot, /efi dhe /etc vetëm për lexim për shërbimin. Nëse një aplikacion duhet të shkruajë në drejtori specifike, atij i lejohet ta bëjë këtë duke përdorur LeximShtigjeShkrimi=/shteg në unitet.

Për të përmirësuar më tej privatësinë, rekomandohet gjithashtu të kufizohet qasja në drejtoritë e përdoruesve duke përdorur `ProtectHome=true` , e cila parandalon shërbimin të lexojë `/home`, `/root` ose `/run/user`. Përveç kësaj, `PrivateTmp=true` krijon hapësira të izoluara `/tmp` dhe `/var/tmp`, duke parandaluar dukshmërinë e kryqëzuar të skedarëve të përkohshëm midis proceseve.

Në pajisje, `PrivateDevices=true` fsheh pemën aktuale `/dev` dhe e zëvendëson atë me një grup minimal pseudo-pajisjesh të sigurta (null, zero, të rastësishme, etj.). Nëse një disk ka nevojë për një pajisje specifike (për shembull, një port serial ose një bllok disku), ajo mund të jepet duke përdorur `DeviceAllow=/dev/xxx rw` ose në modalitetin vetëm për lexim.

Rrjeti është gjithashtu një vektor kyç. Me PrivateNetwork=e vërtetë Krijohet një hapësirë ​​emrash rrjeti e izoluar, duke lënë vetëm loopback-un; shërbimi nuk do të shohë ndërfaqe fizike dhe nuk do të jetë në gjendje të komunikojë me botën e jashtme. Si alternativë, mund të kufizoni se cilat familje adresash mund të përdorë. RestrictAddressFamilies=duke lejuar vetëm AF_INET dhe AF_INET6 për IPv4/IPv6, AF_UNIX për socket-et lokale ose edhe none për të japonezizuar plotësisht aftësitë e rrjetit.

Lidhur me privilegjet, direktiva `NoNewPrivileges=true` është një nga më të fuqishmet: ajo parandalon që procesi të fitojë privilegje të reja përmes binarëve setuid ose ndryshimeve të aftësive. Shkurt, edhe nëse shërbimi ekzekuton kod të cenueshëm, ai nuk duhet të jetë në gjendje të përshkallëzohet në root përmes mekanizmave tradicionalë. I kombinuar me `CapabilityBoundingSet=` , i cili përcakton listën e saktë të aftësive të lejuara (për shembull, vetëm `CAP_NET_BIND_SERVICE` për të dëgjuar në portat me ngarkesë të ulët), sipërfaqja e sulmit minimizohet.

  Samsung Exynos 1480 në Galaxy A55 5G: performancë më e mirë se A44 në Geekbench

Për të shkuar edhe më tej, systemd lejon filtrimin e thirrjeve të sistemit me SystemCallFilter=Në vend të mirëmbajtjes manuale të thirrjeve sistemore, përdoren grupe të paracaktuara, si p.sh. @system-service, @network-io, @basic-io ose moho grupe si ~@privileged. me systemd-analizo syscall-filter Është e mundur të inspektohet se cilat thirrje specifike i përkasin secilit grup. Kjo lejon ndërtimin e një profili ekzekutimi shumë të kufizuar, të ngjashëm me atë që do të ofronte një sandbox i dedikuar.

Cilësime të tjera relevante përfshijnë `ProtectKernelTunables=true` , i cili bllokon modifikimin e parametrave të kernelit në `/proc/sys` dhe `/sys`; `ProtectKernelModules=true` , i cili parandalon ngarkimin ose shkarkimin e moduleve; `ProtectKernelLogs=true` , i cili parandalon leximin e regjistrave të kernelit; dhe `ProtectControlGroups=true` , i cili bllokon shkrimet në hierarkinë cgroups. E gjithë kjo funksionon pa probleme me aftësitë e reja të izolimit të përdoruesve, të tilla si ` PrivateUsers=full` , i cili në versionin 260 është përditësuar për të hartëzuar gamën e plotë të ID-ve të përdoruesve, duke eliminuar zgjidhjet e mëparshme të kërkuara për mjediset e ndërthurura systemd.

PrivateUsers, xaccess dhe kontrolle të reja të aksesit në pajisje

Mekanizmi PrivateUsers , i projektuar për të lejuar shërbimet të ekzekutohen në një hapësirë ​​të izoluar të ID-së së përdoruesit, është konsoliduar në systemd 260. Opsioni PrivateUsers=full tani hartëzon gamën e plotë të identifikuesve, duke thjeshtuar gjërat në kontejnerë dhe në sisteme me instanca të ndërthurura systemd bazuar në versione më të vjetra (para 257). Ky përmirësim ka eliminuar sulmet hakuese që përdoreshin më parë për të zbuluar këto instanca më të vjetra.

Paralelisht, komponentë si systemd-logind dhe systemd-udevd prezantuan konceptin e xaccess . Ky mekanizëm plotëson logjikën klasike të uaccess , e cila u jep akses në pajisje të caktuara (për shembull, audio ose video) përdoruesve me seanca grafike në plan të parë në makinën lokale. Me xaccess, lejet mund t'u delegohen përdoruesve të largët me seanca të shënuara posaçërisht , në mënyrë që, për shembull, një përdorues i lidhur nëpërmjet desktopit të largët të mund të hyjë në pajisjet lokale të renderimit të GPU-së pa u dhënë leje të gjera të gjithë sistemit.

Konfigurimi i këtyre seancave përfshin variablat e mjedisit të ekspozuara nëpërmjet PAM, konkretisht PAMXDG_SESSION_EXTRA_DEVICE_ACCESS= , i cili lejon përcaktimin se cilat pajisje specifike përfshihen në këtë logjikë. Kjo qasje është shumë në përputhje me kërkesat e përputhshmërisë rregullatore dhe mbrojtjes së të dhënave të Bashkimit Evropian, ku kërkohet detaje të hollësishme dhe gjurmueshmëri për aksesin në harduerin e ndjeshëm.

mstack, systemd-mstack dhe mjete të reja kontejnerësh

Në fushën e kontejnerizimit, systemd 260 prezanton funksionalitetin mstack dhe një komandë e lidhur, systemd-mstackIdeja pas mstack është të lejojë përcaktimin e një OverlayFS bazuar në strukturën e një drejtorie të veçantë të quajtur .mstack/, e cila ndjek një specifikim specifik për organizimin e shtresave të saj.

Mjeti i ri i linjës së komandës, systemd-mstack, e bën më të lehtë punën me këto pirgje të sistemit të skedarëve në mënyrë interaktive, duke shtuar fleksibilitet gjatë konfigurimit të mjediseve me shtresa për kontejnerë ose shërbime shumë të izoluara. Ky funksionalitet është i lidhur edhe me përmirësimet në systemd-importd , i cili zgjeron mbështetjen e tij për shkarkimin dhe menaxhimin e imazheve OCI , duke përforcuar kështu rolin e systemd si një motor kontejnerizimi dhe sandboximi, diçka shumë e zakonshme midis ofruesve evropianë të cloud-it dhe platformave moderne të hostimit.

Rrjeti: Integrimi me ModemManager dhe opsione të reja të performancës

Në shtresën e rrjetit, systemd-networkd vazhdon të fitojë rëndësi. Një nga karakteristikat e reja të dukshme është integrimi i tij me ModemManager nëpërmjet protokollit "lidhje e thjeshtë" , i cili lejon që modemet dhe lidhjet mobile të menaxhohen direkt nga networkd pa u mbështetur në mjete të jashtme.

Për të mbështetur këtë rrjedhë, është shtuar një seksion i ri. në skedarët e konfigurimit, me parametra të tillë si APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=Kjo lehtëson vendosjet në zona rurale ose mjedise me lidhje të bazuara në rrjetet mobile, shumë i pranishëm në territore të caktuara të Evropës ku nuk ka gjithmonë fibra ose linja fikse cilësore.

Për sa i përket performancës, skedarët systemd-networkd .link përfshijnë opsione të reja posaçërisht për pajisjet Ethernet. Këto përfshijnë ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList dhe GenericReceiveOffloadUDPForwarding . Këto opsione lejojnë rregullimin e imët të zhvendosjes së punës te hardueri dhe drajverët, gjë që është thelbësore në rrjetet e korporatave, qendrat e të dhënave dhe ofruesit e shërbimeve që duhet të minimizojnë çdo milisekondë të latencës.

Për më tepër, ndërfaqet Varlink dhe JSON të systemd-networkd tani mund të raportojnë adresat IP në një format të lexueshëm nga njeriu (vargje) duke ruajtur përfaqësimin si një varg numrash të plotë. Kjo thjeshton integrimin me panelet e monitorimit, skriptet e menaxhimit ose mjetet e palëve të treta që nuk duan të merren me formate numerike jo intuitive.

Lëvizshmëria e shërbimit, makinat virtuale të përkohshme dhe shërbimet e paprivilegjuara

Komponenti systemd-portabled , përgjegjës për menaxhimin e shërbimeve "portative" të paketuara në imazhe, fiton një aftësi shumë interesante: tani mund të funksionojë si një shërbim në nivel përdoruesi . Kjo do të thotë që përdoruesit pa privilegje, në seancën e tyre normale, mund të nisin dhe menaxhojnë shërbime portative brenda hapësirës së tyre pa përdorur sudo ose privilegje të larta.

  FlexRAM: Memoria revolucionare prej metali të lëngshëm që mund të ndryshojë teknologjinë

Për më tepër, duke filluar me këtë version, portabled mund të gjenerojë politika dhe të bllokojë imazhin e lidhur me një shërbim portativ , duke parandaluar modifikimin e atij imazhi pa e ribashkuar atë. Kjo u lejon përdoruesve të konfigurojnë mjedise të pavarura me garanci të shtuara të pandryshueshmërisë, një veçori veçanërisht tërheqëse për laboratorët, mjediset e zhvillimit dhe sandbox-et e testimit.

Nga ana tjetër, systemd-vmspawn — mjeti i projektuar për të nisur makina virtuale në një mënyrë të integruar me systemd — zgjeron aftësitë e tij për t'u regjistruar me systemd-machined brenda seancës së përdoruesit . Ai gjithashtu prezanton një opsion `-ephemeral` për të krijuar makina efemerale që shkatërrohen pas përfundimit të përdorimit të tyre. Ky është një opsion i përsosur për tubacionet CI/CD, klasat virtuale ose platformat arsimore evropiane që kërkojnë krijimin dhe shkatërrimin e shpejtë dhe të kontrolluar të makinave virtuale.

Kontroll i përsosur i CPU-së, memories dhe planifikimit me SCHED_EXT dhe THP

Systemd 260 gjithashtu thellohet në kontrollin e performancës me politika të reja. Opsioni i shërbimit Politika e Planifikimit të CPU-së= tani pranoni vlerën ext, i cili aktivizon planifikuesin SCHED_EXTKy planifikues alternativ hap derën për eksperimente me politika të ndryshme planifikimi sipas standardeve të bërthamës, diçka që mund të jetë me interes në laboratorët e Kërkimit dhe Zhvillimit ose në zbatime shumë të specializuara.

Në zonën e memories, do të gjeni `MemoryTHP=` , e cila ju lejon të menaxhoni përdorimin e Transparent Huge Pages (THP) në bazë të çdo shërbimi. Në vend të një cilësimi global në të gjithë sistemin, mund të vendosni nëse një njësi specifike duhet të përdorë THP, ta çaktivizojë atë ose të miratojë modalitete të ndërmjetme. Për aplikacionet kritike në bankë, sigurime ose qeveri, ky kontroll i detajuar mund të bëjë një ndryshim të rëndësishëm në vonesën, konsumin e memories dhe performancën.

Komanda të reja në systemctl dhe përdorim i zgjeruar i Varlink

Komanda e njohur systemctl merr një të re: enqueue-marked . Ky veprim thërret në mënyrë të brendshme metodën D-Bus EnqueueMarkedJobs() dhe lejon punën me radhë pune dhe shërbimesh të para-shënuara. Ndërsa mund të duket si një detaj i vogël, për ekipet e operacioneve që orkestrojnë ferma serverash në shkallë të gjerë, është një mjet tjetër për rafinimin e rrjedhave të punës së vendosjes dhe automatizimit.

Paralelisht, projekti vazhdon të zgjerojë përdorimin e Varlink si një mekanizëm komunikimi midis komponentëve. Shumë pjesë të systemd ekspozojnë ndërfaqe të qëndrueshme Varlink, të cilat lehtësojnë integrimin me mjete të jashtme, panele të personalizuara ose agjentë monitorimi që kërkojnë akses të strukturuar në informacionin e sistemit.

Fushat e identifikimit të sistemit dhe përvoja e përdoruesit

Një veçori e re kurioze, por e dobishme për disa shpërndarje është futja e fushës FANCY_NAME= në arkiv /etc/os-releaseKjo fushë i ngjan PRETTY_NAME, por lejon Sekuencat ANSI dhe karakteret Unicode më të hollësishmeFalë kësaj, shpërndarje dhe botime specifike mund të paraqiten me emra më tërheqës ose dallues.

Vlera e FANCY_NAME mund të shihet përmes menaxherit systemd, duke përdorur systemd-hostnamed ose duke pyetur hostnamectl . Edhe pse është një ndryshim i vogël, në mjediset e desktopit dhe panelet grafike të administrimit mund të jetë i dobishëm për identifikimin e shpejtë të sistemit që po menaxhohet, veçanërisht kur trajtohen shumë variante derivative.

Dokumentacion specifik për agjentët e inteligjencës artificiale dhe rrjedhën e punës së rishikimit të asistuar

Një nga shenjat më interesante të drejtimit të zhvillimit të systemd është shfaqja e dokumentacionit të orientuar posaçërisht drejt agjentëve të inteligjencës artificiale . Depozita përfshin një skedar AGENTS.md , i projektuar për të ndihmuar mjetet e analizës së kodit dhe asistentët e programimit, si dhe disa udhëzues teknologjikë , për të kuptuar më mirë arkitekturën, stilin, rrjedhën e zhvillimit dhe udhëzimet e kontributit të projektit.

Ky dokument përshkruan komponentët, shtigjet e ndërtimit, mënyrën e ekzekutimit të testeve dhe integrimeve, si dhe udhëzimet për gjenerimin e patch-eve të pranueshme. Qëllimi është t'u ofrojë agjentëve të IA-së që shqyrtojnë kodin ose bëjnë ndryshime një kuptim të fortë të mënyrës se si është organizuar systemd , duke zvogëluar gabimet dhe sugjerimet e gabuara.

Krahas AGENTS.md është një skedar i quajtur CLAUDE.md , i cili i referohet në mënyrë të qartë të parit dhe është projektuar për të udhëhequr mjetin Claude Code, një nga asistentët e zhvillimit të bazuar në IA më të përdorur gjerësisht. Në këtë mënyrë, projekti e përfshin në mënyrë të qartë IA-në në ciklin e tij të zhvillimit.

Për më tepër, përfshihet një skedar konfigurimi. claude-review.ymlku përcaktohet se si duhet të rishikohet procesi i analizimit të kërkesave për ndryshime (kërkesat tërheqëse), me ndihmën e Claude Code. Në këtë kontekst, kontributet që kanë përdorur IA duhet të përfshijnë etiketat e zbulimit si Co-developed-by në patch-e, duke lënë prova se një mjet i automatizuar ka marrë pjesë në krijimin e kodit.

Me këtë grup gjithëpërfshirës ndryshimesh - pastrimin e mbështetjes së trashëguar, rafinimin e sandboxing-ut, përmirësimin e TPM2 dhe SRK, integrimin e avancuar të rrjetit, aftësitë e reja të transportueshmërisë dhe dokumentacionin e projektuar për agjentë inteligjentë - systemd 260 përforcon rolin e tij qendror në ekosistemin modern Linux. Për administratorët dhe zhvilluesit në Spanjë dhe Evropë, sfida e menjëhershme qëndron në rishikimin e bërthamave, përshtatjen e konfigurimeve dhe shërbimeve të nisjes, dhe shfrytëzimin e këtyre veçorive për të ndërtuar infrastruktura më të sigurta dhe të automatizuara, të përputhura me përdorimin aktual të sistemit.