Systemd 260: TPM2, sandboxing i nowe możliwości w systemie Linux

Przewodnik po sprzęcie » Poradniki zakupowe » Systemd 260: TPM2, sandboxing i nowe możliwości w systemie Linux

Wraz z pojawieniem się systemd 260, dystrybucje Linuksa stawiają kolejny ważny krok w kierunku nowocześniejszego, bezpieczniejszego ekosystemu zorientowanego na środowiska chmurowe, wirtualizację i automatyzację. Ta wersja nie tylko dopracowuje szczegóły: wprowadza znaczące zmiany w rozruchu, zarządzaniu usługami, sieciach, wykorzystaniu modułu TPM2 do zapewnienia integralności i szyfrowania oraz możliwościach sandboxingu na poziomie dysków.

Jednocześnie projekt wzmacnia swoją dokumentację i podejście do pracy z agentami sztucznej inteligencji , wyraźnie pokazując, że systemd jest kluczowym filarem, z którym łączy się coraz więcej narzędzi programistycznych i narzędzi do obserwacji. Jeśli zarządzasz systemami Linux na serwerach, w chmurze, na komputerach stacjonarnych w firmach lub w laboratoriach, warto poświęcić chwilę na zapoznanie się z wszystkimi nowymi funkcjami, aby zaplanować aktualizacje i zmiany konfiguracji.

Ostateczne pożegnanie z Systemem V i całkowitym uzależnieniem od napędów natywnych

Jedną z najbardziej rzucających się w oczy zmian w systemd 260 jest całkowite usunięcie obsługi skryptów Systemu V. Klasyczny proces rozruchu oparty na pliku /etc/init.d był wycofywany od lat, ale teraz skutecznie znika z kodu systemd.

Oznacza to, że komponenty odpowiedzialne za mostkowanie między skryptami SysV a jednostkami natywnymi zostały usunięte: systemd-rc-local-generator, rc-local.service, systemd-sysv-generator i systemd-sysv-install już nie istnieją. W rezultacie żadna usługa, która nadal opiera się na tych starszych mechanizmach, po prostu nie uruchomi się w systemach z systemem systemd 260.

Podczas procesu czyszczenia kilka opcji kompilacji Mesona zostało również oznaczonych jako przestarzałe lub usuniętych. Flagi -Drc-local=, -Dsysvinit-path= i -Dsysvrcnd-path= zostały przeniesione do archiwum, a inne, takie jak -Dintegration-tests= i -Dcryptolib=, zostały całkowicie usunięte. To jasny sygnał: wszystko musi być teraz obsługiwane przez jednostki natywne i nowoczesną infrastrukturę systemd.

W przypadku wielu europejskich infrastruktur, które nadal opierają się na starszych komponentach, ta zmiana wymaga przeglądu usług wewnętrznych, niestandardowych skryptów i starszych wdrożeń. Migracja do dobrze zdefiniowanych plików jednostek nie jest już tylko zalecana, ale wręcz obowiązkowa, jeśli chcesz nadal korzystać z usług w dystrybucjach integrujących systemd 260.

Wyższe wymagania jądra i skupienie się na obecnych środowiskach

Nowa wersja podnosi poprzeczkę dla jądra: od teraz minimalna obsługiwana wersja Linuksa to 5.10 , pozostawiając w tyle bardzo stare gałęzie, takie jak 5.4. Co więcej, projekt wskazuje, że idealnie użytkownicy powinni pracować na jądrze 5.14 lub nowszym , a szczególnie zaleca serię 6.6 , aby w pełni wykorzystać wszystkie dostępne funkcje.

Ten wzrost wymagań zazwyczaj nie stanowi problemu w nowoczesnych dystrybucjach, ale może komplikować sytuację w bardzo konserwatywnych środowiskach lub rozwiązaniach wbudowanych utrzymywanych przez wiele lat. Przed aktualizacją do systemd 260 zaleca się sprawdzenie, które jądro jest używane, szczególnie w europejskich centrach danych z długoterminowymi wdrożeniami lub niestandardowymi obrazami.

Na przeciwnym biegunie znajdują się dystrybucje ciągłe, takie jak Arch Linux czy openSUSE Tumbleweed, cieszące się dużą popularnością wśród osób poszukujących najnowszych funkcji. Zazwyczaj szybko integrują one zarówno nowe kernele, jak i nowe gałęzie systemd. Inne, takie jak Fedora, zachowują pewien stopień stabilności głównej wersji systemd przez cały cykl życia każdego wydania, co pozwala na nieco więcej czasu na planowanie migracji.

TPM2, integralność rozruchu i zaawansowana obsługa SRK

Jednym z obszarów, w których systemd rozwija się najprężniej, jest integracja z modułem TPM2 (Trusted Platform Module 2.0) . Ten układ, coraz częściej spotykany w nowoczesnych płytach głównych z interfejsem UEFI oraz sprzęcie średniej i wysokiej klasy, umożliwia zakotwiczenie poufnych informacji w stanie systemu, pomiar faz rozruchu i automatyczne odblokowywanie zaszyfrowanych woluminów, gdy środowisko jest zgodne z oczekiwaniami.

Systemd 260 dodatkowo rozszerza tę integrację, dodając narzędzia i usługi obejmujące różne etapy procesu rozruchu. Kluczowym komponentem jest systemd-tpm2-setup , odpowiedzialny za przygotowanie infrastruktury wokół klucza głównego pamięci masowej (SRK) modułu TPM . Ten klucz główny stanowi kryptograficzną podstawę do zabezpieczenia komunikacji z układem scalonym i bezpiecznego przechowywania innych poufnych informacji.

Podczas rozruchu rozróżnia się dwie fazy: bardzo wczesną w initrd i drugą w systemie głównym. W pierwszej fazie usługa o nazwie „Early TPM SRK Setup” sprawdza, czy moduł TPM ma już zapisany klucz SRK, a jeśli nie istnieje, tworzy go i tymczasowo udostępnia w katalogu /run/systemd/tpm2-srk-public-key.* . Później, po zamontowaniu rzeczywistego systemu plików, usługa konsoliduje klucz SRK i weryfikuje, czy klucz zapisany w pliku /var/lib/systemd/tpm2-srk-public-key.pem jest zgodny z kluczem w module TPM.

W dobrze skonfigurowanych scenariuszach wyświetlane będą wpisy dziennika, takie jak „SRK jest już zapisany w module TPM” oraz komunikaty wskazujące, że ślad SRK jest zgodny z oczekiwanym. Jeśli jednak środowisko nie jest poprawnie skonfigurowane (na przykład w konfiguracjach z Yocto lub na płytkach takich jak Raspberry Pi z modułem TPM opartym na SPI i niestandardowymi metodami rozruchu, takimi jak U-Boot i mierzony rozruch), mogą wystąpić sytuacje, w których systemd nie utworzy tych plików w katalogu /var/lib/systemd, co budzi wątpliwości co do prawidłowej konfiguracji SRK.

Po zmianie stanu modułu TPM, modyfikacji partycji lub modyfikacji sekwencji rozruchowej powiązana polityka może przestać obowiązywać. W takich przypadkach niektórzy administratorzy zalecają wyczyszczenie gniazda lub polityki TPM i ponowną rejestrację klucza , postępując zgodnie z procedurami podobnymi do opisanych w podręcznikach szyfrowania dysków z użyciem modułu TPM w środowiskach takich jak openSUSE, które szczegółowo opisują, jak ponownie utworzyć politykę PCR i ponownie połączyć odblokowywanie woluminów.

Oprócz SRK, kolejnym praktycznym ulepszeniem jest wprowadzenie wewnętrznego narzędzia o nazwie tpm2_id w udev . To zintegrowane narzędzie uruchamia się, gdy system wykryje urządzenie TPM2 i automatycznie pobiera identyfikator producenta i modelu . Upraszcza to inwentaryzację sprzętu zabezpieczającego, co jest bardzo przydatne w administracji publicznej, firmach regulowanych lub infrastrukturach krytycznych, gdzie niezbędna jest precyzyjna wiedza o tym, które moduły TPM są wdrożone.

Integrację z infrastrukturą pomiaru rozruchu dodatkowo wzmacniają specjalne jednostki, takie jak systemd-pcrextend , które rejestrują zdarzenia takie jak „enter-initrd”, „leave-initrd”, „sysinit” i „ready” w różnych PCR (np. PCR 11). Ta sekwencja rozszerzeń pozwala modułowi TPM zgromadzić kryptograficznie weryfikowalny zapis przebiegu rozruchu, który następnie może być wykorzystany w politykach zaufanego rozruchu (Trusted Boot) lub w UKI (Unified Kernel Images) do weryfikacji stanu komputera przed zwolnieniem kluczy.

Środki bezpieczeństwa i sandboxing usług z systemd

Systemd nie tylko uruchamia procesy, ale oferuje również kompleksowy zestaw dyrektyw sandboxingowych , które izolują usługi i ograniczają szkody w przypadku naruszenia bezpieczeństwa. To podejście „głębokiej obrony” opiera się na grupach cgroup, przestrzeniach nazw, możliwościach jądra oraz filtrach wywołań systemowych (seccomp).

Aby ocenić bezpieczeństwo konkretnej usługi, systemd zawiera narzędzie systemd-analyze security . Po jego uruchomieniu generowany jest raport z oceną narażenia w skali od 0 do 10, gdzie niższy wynik oznacza lepszy wynik. Raport zawiera szczegółowe informacje o tym, które zabezpieczenia są włączone lub wyłączone (izolacja sieciowa, dostęp do systemu plików, dostęp do urządzenia itp.), co ułatwia identyfikację brakujących ustawień i weryfikację, czy zmiany rzeczywiście poprawiają ocenę.

Zamiast edytować oryginalną jednostkę, która zostałaby utracona w przyszłych aktualizacjach pakietu, zaleca się utworzenie Zastąp en /etc/systemd/system/mi-servicio.service.d/ na przykład z plikiem sandbox.confPo modyfikacji wystarczy ponownie załadować konfigurację za pomocą systemctl daemon-reload i uruchom ponownie usługę, aby nowe ograniczenia zaczęły obowiązywać.

Na poziomie systemu plików jedną z najważniejszych opcji jest ProtectSystem=Wartości takie jak strict, full o true Montują różne części drzewa w trybie tylko do odczytu. Zwyczajowo, gdy to możliwe, używa się ProtectSystem=strictDzięki temu katalogi /usr, /boot, /efi i /etc są dla usługi tylko do odczytu. Jeśli aplikacja potrzebuje zapisać dane do określonych katalogów, może to zrobić za pomocą ReadWritePaths=/ścieżka w jedności.

Aby jeszcze bardziej zwiększyć prywatność, zaleca się również ograniczenie dostępu do katalogów użytkowników za pomocą parametru `ProtectHome=true` , który uniemożliwia usłudze odczytanie katalogów `/home`, `/root` lub `/run/user`. Dodatkowo parametr `PrivateTmp=true` tworzy odizolowane przestrzenie `/tmp` i `/var/tmp`, uniemożliwiając krzyżową widoczność plików tymczasowych między procesami.

W urządzeniach parametr `PrivateDevices=true` ukrywa faktyczne drzewo `/dev` i zastępuje je minimalnym zestawem bezpiecznych pseudourządzeń (null, zero, losowe itd.). Jeśli napęd potrzebuje konkretnego urządzenia (na przykład portu szeregowego lub bloku dysku), można je uzyskać za pomocą parametru `DeviceAllow=/dev/xxx rw` lub w trybie tylko do odczytu.

Sieć jest również kluczowym wektorem. Sieć prywatna=prawda Tworzona jest izolowana przestrzeń nazw sieciowych, pozostawiając jedynie pętlę zwrotną; usługa nie będzie widzieć interfejsów fizycznych i nie będzie mogła komunikować się ze światem zewnętrznym. Alternatywnie, możesz ograniczyć rodziny adresów, z których może korzystać, Ogranicz rodziny adresów=zezwalając tylko na AF_INET i AF_INET6 dla IPv4/IPv6, AF_UNIX dla gniazd lokalnych lub nawet none aby w pełni zjaponizować możliwości sieci.

Jeśli chodzi o uprawnienia, dyrektywa `NoNewPrivileges=true` jest jedną z najskuteczniejszych: zapobiega ona uzyskiwaniu przez proces nowych uprawnień poprzez pliki binarne z setuid lub zmiany uprawnień. Krótko mówiąc, nawet jeśli usługa wykonuje podatny kod, nie powinna być w stanie uzyskać dostępu do roota za pomocą tradycyjnych mechanizmów. W połączeniu z dyrektywą `CapabilityBoundingSet=` , która definiuje dokładną listę dozwolonych uprawnień (na przykład tylko `CAP_NET_BIND_SERVICE` do nasłuchiwania na portach o niskim priorytecie), powierzchnia ataku jest minimalizowana.

Aby pójść jeszcze dalej, systemd umożliwia filtrowanie wywołań systemowych za pomocą Filtr wywołań systemowychZamiast utrzymywać ręczną listę wywołań systemowych, stosuje się wstępnie zdefiniowane grupy, takie jak @system-service, @network-io, @basic-io lub odmówić grupom takim jak ~@privileged. Z systemd-analyze filtr wywołań systemowych Można sprawdzić, które konkretne wywołania należą do każdej grupy. Pozwala to na zbudowanie bardzo ograniczonego profilu wykonania, podobnego do tego, jaki oferowałaby dedykowana piaskownica.

Inne istotne ustawienia obejmują `ProtectKernelTunables=true` , które blokuje modyfikację parametrów jądra w `/proc/sys` i `/sys`; `ProtectKernelModules=true` , które uniemożliwia ładowanie i usuwanie modułów; `ProtectKernelLogs=true` , które uniemożliwia odczyt logów jądra; oraz `ProtectControlGroups=true` , które blokuje zapisy do hierarchii cgroups. Wszystko to działa bezproblemowo dzięki nowym możliwościom izolacji użytkowników, takim jak ` PrivateUsers=full` , które w wersji 260 zostało zaktualizowane w celu mapowania pełnego zakresu identyfikatorów użytkowników, eliminując wcześniejsze obejścia wymagane w zagnieżdżonych środowiskach systemd.

PrivateUsers, xaccess i nowe funkcje kontroli dostępu do urządzeń

Mechanizm PrivateUsers , zaprojektowany w celu umożliwienia usługom działania w odizolowanej przestrzeni identyfikatorów użytkowników, został skonsolidowany w systemd 260. Opcja PrivateUsers=full mapuje teraz pełen zakres identyfikatorów, upraszczając obsługę kontenerów i systemów z zagnieżdżonymi instancjami systemd opartymi na starszych wersjach (przed 257). To ulepszenie wyeliminowało obejścia, które wcześniej służyły do ​​wykrywania tych starszych instancji.

Równolegle, komponenty takie jak systemd-logind i systemd-udevd wprowadziły koncepcję xaccess . Mechanizm ten uzupełnia klasyczną logikę uaccess , która przyznaje dostęp do określonych urządzeń (na przykład audio lub wideo) użytkownikom z sesjami grafiki pierwszoplanowej na komputerze lokalnym. Dzięki xaccess uprawnienia mogą być delegowane użytkownikom zdalnym ze specjalnie oznaczonymi sesjami , dzięki czemu na przykład użytkownik połączony za pośrednictwem pulpitu zdalnego może uzyskać dostęp do lokalnych urządzeń renderujących GPU bez konieczności udzielania szerokich uprawnień całemu systemowi.

Konfiguracja tych sesji obejmuje zmienne środowiskowe udostępniane przez PAM, a konkretnie PAMXDG_SESSION_EXTRA_DEVICE_ACCESS= , które pozwalają zdefiniować, które konkretne urządzenia są objęte tą logiką. To podejście jest ściśle zgodne z wymogami Unii Europejskiej dotyczącymi zgodności z przepisami i ochrony danych, gdzie granularność i identyfikowalność są wymagane w celu uzyskania dostępu do wrażliwego sprzętu.

mstack, systemd-mstack i nowe narzędzia kontenerowe

W obszarze konteneryzacji systemd 260 wprowadza funkcjonalność stos i powiązane polecenie, systemd-mstackPomysł stojący za mstack polega na umożliwieniu zdefiniowania NakładkaFS na podstawie struktury specjalnego katalogu o nazwie .mstack/, który stosuje się do konkretnych specyfikacji dotyczących organizacji warstw.

Nowe narzędzie wiersza poleceń, systemd-mstack, ułatwia interaktywną pracę z tymi stosami systemów plików, zwiększając elastyczność podczas konfigurowania środowisk warstwowych dla kontenerów lub silnie odizolowanych usług. Ta funkcjonalność jest również powiązana z ulepszeniami w narzędziu systemd-importd , które rozszerzają obsługę pobierania i zarządzania obrazami OCI , wzmacniając tym samym rolę systemd jako mechanizmu konteneryzacji i sandboxingu, co jest bardzo powszechne wśród europejskich dostawców usług chmurowych i nowoczesnych platform hostingowych.

Sieć: integracja z ModemManager i nowe opcje wydajności

W warstwie sieciowej systemd-networkd stale zyskuje na znaczeniu. Jedną z istotnych nowych funkcji jest integracja z ModemManager poprzez protokół „simple connect” , który umożliwia zarządzanie modemami i połączeniami mobilnymi bezpośrednio z poziomu networkd, bez konieczności korzystania z narzędzi zewnętrznych.

Aby ułatwić ten przepływ, dodano nową sekcję. do plików konfiguracyjnych, z parametrami takimi jak APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=Ułatwia to wdrażanie w obszary wiejskie lub środowiska z łącznością opartą na sieciach komórkowych, powszechnie występujący na niektórych obszarach Europy, gdzie nie zawsze jest dostęp do światłowodów lub dobrej jakości linii stacjonarnych.

Pod względem wydajności pliki systemd-networkd .link zawierają nowe opcje przeznaczone specjalnie dla urządzeń Ethernet. Należą do nich: ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList i GenericReceiveOffloadUDPForwarding . Opcje te pozwalają na precyzyjne dostrojenie sposobu przenoszenia zadań na sprzęt i sterowniki, co jest kluczowe w sieciach korporacyjnych, centrach danych i u dostawców usług, którzy muszą minimalizować każdą milisekundę opóźnienia.

Co więcej, interfejsy Varlink i JSON w systemie systemd-networkd mogą teraz raportować adresy IP w formacie czytelnym dla człowieka (ciągi znaków), zachowując jednocześnie reprezentację w postaci tablicy liczb całkowitych. Upraszcza to integrację z panelami monitorującymi, skryptami zarządzania lub narzędziami innych firm, które nie chcą obsługiwać nieintuicyjnych formatów liczbowych.

Przenośność usług, efemeryczne maszyny wirtualne i usługi bez uprawnień

Komponent systemd-portabled , odpowiedzialny za zarządzanie usługami „przenośnymi” w obrazach, zyskuje bardzo interesującą funkcję: może teraz działać jako usługa na poziomie użytkownika . Oznacza to, że użytkownicy bez uprawnień, w ramach swojej zwykłej sesji, mogą uruchamiać i zarządzać usługami przenośnymi w swojej własnej przestrzeni bez konieczności korzystania z sudo lub uprawnień podwyższonych.

Co więcej, począwszy od tej wersji, portabled może generować polityki i blokować obraz powiązany z usługą przenośną , uniemożliwiając modyfikację tego obrazu bez jego ponownego podłączania. Pozwala to użytkownikom na konfigurowanie niezależnych środowisk z dodatkowymi gwarancjami niezmienności, co jest szczególnie atrakcyjną funkcją dla laboratoriów, środowisk programistycznych i środowisk testowych.

Z drugiej strony, systemd-vmspawn – narzędzie zaprojektowane do uruchamiania maszyn wirtualnych w sposób zintegrowany z systemd – rozszerza swoje możliwości o rejestrację w systemie systemd-machine w ramach sesji użytkownika . Wprowadza również opcję `-ephemeral`, która umożliwia tworzenie maszyn efemerycznych, które są niszczone po zakończeniu użytkowania. Jest to idealne rozwiązanie dla potoków CI/CD, wirtualnych klas szkolnych lub europejskich platform edukacyjnych, które wymagają szybkiego i kontrolowanego tworzenia i niszczenia maszyn wirtualnych.

Precyzyjne sterowanie procesorem, pamięcią i harmonogramem za pomocą SCHED_EXT i THP

Systemd 260 zagłębia się również w kontrolę wydajności dzięki nowym zasadom. Opcja usługi Zasady planowania procesora CPU= teraz zaakceptuj wartość ext, który aktywuje harmonogram SCHED_EXTTen alternatywny planer otwiera drzwi do eksperymenty z różnymi politykami planowania do standardów jądra, co może być interesujące dla laboratoriów badawczo-rozwojowych lub w przypadku wysoce wyspecjalizowanych wdrożeń.

W obszarze pamięci znajdziesz opcję `MemoryTHP=` , która umożliwia zarządzanie wykorzystaniem Transparent Huge Pages (THP) dla poszczególnych usług. Zamiast globalnego, systemowego ustawienia, możesz decydować, czy dana jednostka powinna korzystać z THP, wyłączyć je lub zastosować tryby pośrednie. W przypadku kluczowych aplikacji w bankowości, ubezpieczeniach lub administracji publicznej ta szczegółowa kontrola może znacząco wpłynąć na opóźnienia, zużycie pamięci i wydajność.

Nowe polecenia w systemctl i rozszerzone wykorzystanie Varlink

Znane polecenie systemctl zyskuje nowe: enqueue-marked . Ta akcja wewnętrznie wywołuje metodę EnqueueMarkedJobs() magistrali D-Bus i umożliwia pracę z kolejkami wstępnie oznaczonych zadań i usług. Choć może się to wydawać mało istotne, dla zespołów operacyjnych zarządzających dużymi farmami serwerów jest to kolejne narzędzie do udoskonalania przepływów pracy związanych z wdrażaniem i automatyzacją.

Równocześnie projekt stale rozszerza wykorzystanie Varlinka jako mechanizmu komunikacji między komponentami. Wiele elementów systemd udostępnia stabilne interfejsy Varlink, które ułatwiają integrację z narzędziami zewnętrznymi, niestandardowymi pulpitami nawigacyjnymi lub agentami monitorującymi, które wymagają ustrukturyzowanego dostępu do informacji systemowych.

Pola identyfikacji systemu i doświadczenie użytkownika

Ciekawą, ale przydatną nową funkcją dla niektórych dystrybucji jest wprowadzenie pola FANCY_NAME= w archiwum /etc/os-releaseTo pole jest podobne do PRETTY_NAME, ale pozwala Sekwencje ANSI i bardziej rozbudowane znaki UnicodeDzięki temu konkretne dystrybucje i edycje mogą być prezentowane pod bardziej przyciągającymi wzrok i wyróżniającymi się nazwami.

Wartość zmiennej FANCY_NAME można sprawdzić w menedżerze systemd, używając polecenia systemd-hostnamed lub zapytania hostnamectl . Chociaż jest to niewielka zmiana, w środowiskach graficznych i graficznych panelach administracyjnych może być przydatna do szybkiej identyfikacji zarządzanego systemu , szczególnie w przypadku obsługi wielu wariantów pochodnych.

Specyficzna dokumentacja dla agentów AI i wspomaganego przepływu pracy przeglądu

Jednym z najciekawszych sygnałów rozwoju systemd jest pojawienie się dokumentacji specjalnie ukierunkowanej na agentów sztucznej inteligencji . Repozytorium zawiera plik AGENTS.md , zaprojektowany, aby pomóc narzędziom do analizy kodu i asystentom programistycznym, a także przewodnikom technologicznym , lepiej zrozumieć architekturę, styl, przepływ rozwoju i wytyczne dotyczące wkładu w projekt.

W tym dokumencie opisano komponenty, ścieżki kompilacji, sposób uruchamiania testów i integracji oraz wytyczne dotyczące generowania akceptowalnych poprawek. Celem jest zapewnienie agentom AI, którzy przeglądają kod lub wprowadzają zmiany, dogłębnej wiedzy na temat organizacji systemu Systemd , co pozwoli ograniczyć liczbę błędów i błędnych sugestii.

Obok pliku AGENTS.md znajduje się plik o nazwie CLAUDE.md , który wyraźnie odwołuje się do tego pierwszego i został zaprojektowany do obsługi narzędzia Claude Code, jednego z najpopularniejszych asystentów programistycznych opartych na sztucznej inteligencji. W ten sposób projekt wyraźnie uwzględnia sztuczną inteligencję w swoim cyklu rozwoju.

Dodatkowo dołączony jest plik konfiguracyjny. claude-review.ymlgdzie zdefiniowano, jak należy analizować proces analizowania wniosków o zmianę (pull requestów) z pomocą Claude Code. W tym kontekście wymagane jest, aby wkłady wykorzystujące sztuczną inteligencję uwzględniały etykiety informacyjne jako Co-developed-by w poprawkach, pozostawiając dowód, że w tworzeniu kodu brało udział narzędzie automatyczne.

Dzięki temu kompleksowemu zestawowi zmian – uporządkowaniu obsługi starszych wersji, udoskonaleniu sandboxingu, ulepszeniu TPM2 i SRK, zaawansowanej integracji sieciowej, nowym możliwościom przenośności oraz dokumentacji opracowanej dla inteligentnych agentów – systemd 260 wzmacnia swoją centralną rolę w nowoczesnym ekosystemie Linuksa. Dla administratorów i programistów w Hiszpanii i Europie bezpośrednim wyzwaniem jest przegląd jąder, dostosowanie konfiguracji i usług rozruchowych oraz wykorzystanie tych funkcji do budowy bezpieczniejszych, zautomatyzowanych infrastruktur dostosowanych do obecnego sposobu użytkowania systemu.