- Systemd 260 elimina definitivament el suport a scripts System V i exigeix unitats natives per a tots els serveis.
- La versió reforça la integració amb TPM2, incloent gestió de la SRK i utilitats com a tpm2_id i systemd-pcrextend.
- S'amplien de manera notable les capacitats de sandboxing, control de xarxa i recursos per servei, juntament amb noves opcions per a contenidors i màquines efímeres.
- El projecte incorpora documentació específica per a agents dIA i nous fluxos de revisió assistida per millorar la qualitat de les contribucions.
Amb l'arribada de systemd 260 les distribucions Linux fan un altre pas important cap a un ecosistema més modern, segur i orientat a entorns cloud, virtualització i automatització. Aquesta versió no es limita a polir detalls: introdueix canvis de pes en l'arrencada, en el maneig de serveis, a la xarxa, en l'ús de TPM2 per a integritat i xifratge, i en les capacitats d'aïllament (sandboxing) a nivell d'unitat.
Alhora, el projecte reforça la seva documentació i la seva manera de treballar amb agents d'intel·ligència artificial, deixant clar que systemd és un pilar crític al qual cada cop es connecten més eines de desenvolupament i observabilitat. Si administreu sistemes Linux en servidors, cloud, escriptoris corporatius o laboratoris, val la pena revisar amb calma totes aquestes novetats per planificar actualitzacions i ajustaments de configuració.
Adéu definitiu a System V i dependència total d'unitats natives
Un dels canvis més cridaners de systemd 260 és la retirada completa del suport per a scripts de System V. L'arrencada clàssica basada en /etc/init.d feia anys que estava en fase de retirada, però ara desapareix de manera efectiva del codi de systemd.
Això es tradueix que els components responsables de pontejar entre scripts SysV i unitats natives s'han eliminat: systemd-rc-local-generator, rc-local.service, systemd-sysv-generator i systemd-sysv-install deixen d'existir. Com a conseqüència, qualsevol servei que encara depengués d'aquests mecanismes heretats simplement no arrencarà en sistemes que adoptin systemd 260.
En el procés de neteja també s'han marcat com a obsoletes o s'han retirat diverses opcions de compilació de Meson. Les banderes -Drc-local=, -Dsysvinit-path= i -Dsysvrcnd-path= passen al bagul dels records, mentre que altres com -Dintegration-tests= i -Dcryptolib= s'eliminen directament. És un missatge clar: tot ha de passar per unitats natives i per la infraestructura moderna de systemd.
Per a moltes infraestructures europees que encara conserven peces antigues, aquest canvi obliga a revisar serveis interns, scripts casolans i desplegaments heretats. Migrar unit files ben definits ja no és recomanable: és obligatori si es vol continuar arrencant serveis en distribucions que integrin systemd 260.
Requisits de kernel més alts i focus en entorns actuals
La nova versió puja el llistó del nucli: a partir d'ara, la versió mínima de Linux suportada és la 5.10, deixant enrere branques molt veteranes com la 5.4. A més, el projecte assenyala que l'ideal és treballar sobre un nucli 5.14 o superior, i recomana especialment la sèrie 6.6 per aprofitar totes les funcionalitats disponibles.
Aquest augment dels requisits no sol ser un problema en distribucions modernes, però pot complicar la vida en entorns molt conservadors o en solucions encastades mantingudes durant molts anys. Abans d'actualitzar a systemd 260 convé verificar quin nucli s'està usant, especialment a centres de dades europeus amb desplegaments de llarga durada o en imatges personalitzades.
A l'extrem oposat, les distribucions de llançament continu com Arch Linux o openSUSE Tumbleweed, molt populars entre els que volen l'últim, solen incorporar amb rapidesa tant nous kernels com noves branques de systemd. Altres com Fedora mantenen certa estabilitat en la versió més gran de systemd durant el cicle de vida de cada release, cosa que dóna una mica més de marge per planificar migracions.
TPM2, integritat de l'arrencada i suport avançat de SRK
Un dels fronts on més està evolucionant systemd és en la integració amb TPM2 (Trusted Platform Module 2.0). Aquest xip, cada cop més habitual en plaques UEFI modernes i en maquinari de gamma mitjana i alta, permet ancorar secrets a l'estat del sistema, mesurar fases d'arrencada i desbloquejar volums xifrats automàticament quan l'entorn és l'esperat.
Systemd 260 aprofundeix en aquesta integració afegint eines i serveis que cobreixen diferents moments del boot. Una peça clau és systemd-tpm2-setup, responsable de preparar la infraestructura al voltant de la Storage Root Key (SRK) del TPM. Aquesta clau arrel serveix com a fonament criptogràfic per assegurar la comunicació amb el xip i per emmagatzemar de manera protegida altres secrets.
Durant l'arrencada es distingeixen dues fases: una molt primerenca a l'initrd i una altra ja al sistema arrel. A la primera, un servei de “Early TPM SRK Setup” comprova si el TPM ja té una SRK emmagatzemada i, en cas que no existeixi, la crea i la deixa disponible de forma temporal baix /run/systemd/tpm2-srk-public-key.*. Més endavant, un cop muntat el sistema de fitxers real, el servei consolidarà la SRK i verificarà que la clau emmagatzemada a /var/lib/systemd/tpm2-srk-public-key.pem coincideix amb la que hi ha al TPM.
En escenaris ben configurats es veuen entrades al journal de l'estil «SRK ja està emmagatzemada al TPM» i missatges que indiquen que la petjada de la SRK correspon a l'esperada. Si, per contra, l'entorn no està alineat (per exemple, en muntatges amb Yocto o en plaques com Raspberry Pi amb TPM per SPI i arrencades personalitzades amb U‑Boot i measured boot), poden donar-se situacions en què systemd no arribi a crear aquests fitxers sota /var/lib/systemd, generant dubtes sobre si.
Quan l'estat del TPM ha canviat, s'han tocat particions o s'ha modificat el flux d'arrencada, és possible que la política associada no encaixi. En aquests casos alguns mantenidors recomanen netejar el slot o la política TPM i tornar a matricular la clau, seguint procediments similars als descrits en guies de xifratge de disc amb TPM en entorns com openSUSE, on es detalla com recrear la política de PCR i reenllaçar el desbloqueig de volums.
Al marge de la SRK, una altra millora pràctica és la introducció a udev d'una utilitat interna anomenada tpm2_id. Aquesta eina integrada s'executa quan el sistema detecta un dispositiu TPM2 i extreu de forma automàtica l'identificador de fabricant i el model. Amb això se simplifica l'inventari de maquinari de seguretat, cosa molt útil en administracions públiques, empreses regulades o infraestructures crítiques on cal saber amb precisió quins mòduls TPM estan desplegats.
La integració amb la infraestructura de mesura d'arrencada també es reforça amb unitats específiques com systemd-pcrextend, que registren en diferents PCR (per exemple el PCR 11) esdeveniments com “enter-initrd”, “leave-initrd”, “sysinit” o “ready”. Aquesta seqüència d'extensions fa que el TPM acumuli un registre criptogràficament verificable del flux d'arrencada, que es pot utilitzar després per a polítiques de Trusted Boot o per a UKI (Unified Kernel Images) que validin l'estat de la màquina abans d'alliberar les claus.
Mesures de seguretat i sandboxing de serveis amb systemd
Systemd no només arrenca processos: també ofereix un conjunt molt ampli de directives de sandboxing per aïllar serveis i limitar el dany en cas de compromís. Aquest enfocament de “defensa en profunditat” es recolza en cgroups, namespaces, capabilities del kernel i filtres de trucades al sistema (seccomp).
Per avaluar la situació d'un servei concret, systemd inclou l'eina systemd-analyze security. En executar-la, genera un informe amb un índex d'exposició en una escala de 0 a 10, on com més baix millor. L'informe desglossa proteccions activades o absents (aïllament de xarxa, accés al sistema de fitxers, dispositius, etc.), de manera que resulta molt senzill detectar quins ajustaments falten i comprovar si els canvis introduïts milloren realment la puntuació.
En lloc d'editar la unitat original —el que es perdria en futures actualitzacions de paquets— és recomanable crear un anul · lar en /etc/systemd/system/mi-servicio.service.d/ amb un fitxer, per exemple, sandbox.conf. Després de modificar-lo, només cal recarregar la configuració amb systemload-daemon-reload i reiniciar el servei perquè les noves restriccions entrin en vigor.
En el plànol del sistema de fitxers, una de les opcions més importants és ProtectSystem=. Valors com strict, full o true munten diferents parts de l'arbre de manera només lectura. L'habitual, quan és possible, és fer servir ProtectSystem=strict, que fa que /usr, /boot, /efi i /etc siguin de només lectura per al servei. Si una aplicació necessita escriure a directoris concrets se li permet mitjançant ReadWritePaths=/ruta a la unitat.
Per reforçar la privadesa també es recomana Vetar l'accés als directoris d'usuari mitjançant ProtectHome=true, que impedeix que el servei pugui llegir /home, /root o /run/user. A més, TempPrivat=cert crea un espai /tmp i /var/tmp aïllat, evitant la visibilitat creuada de fitxers temporals entre processos.
En dispositius, PrivateDevices=true oculta l'arbre /dev real i el substitueix per un conjunt mínim de pseudodispositius segurs (null, zero, random, etc.). Si una unitat necessita un dispositiu concret (per exemple, un port sèrie o un bloc de disc), es pot concedir mitjançant DeviceAllow=/dev/xxx rw o en mode només lectura.
La xarxa també és un vector clau. Amb PrivateNetwork=true es crea un namespace de xarxa aïllat deixant únicament el loopback; el servei no veurà interfícies físiques ni es podrà comunicar amb l'exterior. Alternativament, es pot restringir quines famílies d'adreces pot fer servir mitjançant RestrictAddressFamilies=, permetent només AF_INET i AF_INET6 per a IPv4/IPv6, AF_UNIX per a sockets locals o fins i tot none per japonitzar per complet les capacitats de xarxa.
Pel que fa a privilegis, la directiva NoNewPrivileges=true és de les més poderoses: impedeix que el procés adquireixi nous privilegis mitjançant binaris setuid o canvis de capabilities. Tot plegat, encara que el servei executi codi vulnerable, no hauria de poder escalar a root a través dels mecanismes clàssics. Combinat amb CapabilityBoundingSet=, que defineix la llista exacta de capacitats permeses (per exemple, només CAP_NET_BIND_SERVICE per escoltar a ports baixos), es redueix al mínim la superfície d'atac.
Per anar encara més lluny, systemd permet filtrar trucades al sistema amb SystemCallFilter=. En lloc de mantenir una llista manual de syscalls, es fan servir grups predefinits com @system-service, @network-io, @basic-io o negar grups com ~@privileged. Amb systemd-analyze syscall-filter és possible inspeccionar quines trucades concretes formen part de cada grup. D'aquesta manera, es construeix un perfil d'execució molt limitat, semblant al que oferiria un sandbox dedicat.
Altres ajustaments rellevants són ProtectKernelTunables=true, que bloqueja la modificació de paràmetres del kernel a /proc/sys i /sys, ProtectKernelModules=true, que evita carregar o descarregar mòduls, ProtectKernelLogs=true, que impedeix llegir els registres del nucli, i ProtectControlGroups=true, que bloqueja escriptures a la jerarquia de cgroups. Tot això combina a la perfecció amb noves capacitats dʻaïllament dʻusuari com PrivateUsers=full, que a la versió 260 s'actualitza per mapejar el rang complet d'IDs d'usuari, eliminant trucs anteriors necessaris per a entorns amb systemd imbricat.
PrivateUsers, xaccess i nous controls d'accés a dispositius
el mecanisme PrivateUsers, pensat perquè els serveis s'executin en un espai d'IDs d'usuari aïllat, es consolida a systemd 260. L'opció PrivateUsers=full ara mapeja el rang complet d'identificadors, cosa que simplifica la vida en contenidors i en sistemes amb instàncies de systemd imbricades que es basen en versions una mica antigues (anteriors a la 257). Aquesta millora ha permès eliminar hacks que es feien servir per detectar aquestes instàncies antigues.
En paral·lel, components com systemd-logind i systemd-udevd estrenen el concepte de xaccess. Aquest mecanisme complementa la lògica clàssica de uaccess, que concedeix accés a certs dispositius (per exemple, d'àudio o vídeo) a usuaris amb sessions gràfiques en primer pla a la màquina local. Amb xaccess es poden delegar permisos a usuaris remots amb sessions marcades de forma especial, de manera que, per exemple, un usuari connectat per escriptori remot pugui accedir a dispositius de renderitzat GPU locals sense atorgar permisos amplis a tot el sistema.
La configuració d‟aquestes sessions passa per variables d‟entorn exposades via PAM, en concret PAMXDG_SESSION_EXTRA_DEVICE_ACCESS=, que permet definir quins dispositius concrets entren en aquesta lògica. És un enfocament molt alineat amb les necessitats de compliment normatiu i protecció de dades a la Unió Europea, on s'exigeix granularitat i traçabilitat en l'accés a maquinari sensible.
mstack, systemd-mstack i noves eines per a contenidors
A l'àmbit de la contenerització, systemd 260 introdueix la funcionalitat mstack i una ordre associat, systemd-mstack. La idea darrere de mstack és permetre definir un OverlayFS a partir de l'estructura d'un directori especial anomenat .mstack/, que segueix una especificació concreta per organitzar les seves capes.
La nova ordre de línia, systemd-mstack, facilita treballar amb aquestes “piles” de sistemes de fitxers de forma interactiva, afegint flexibilitat a l'hora de muntar entorns superposats per a contenidors o serveis molt aïllats. Aquesta funcionalitat està lligada també a millores en systemd-importd, que amplia el seu suport per descarregar i gestionar imatges OCI, reforçant així el paper de systemd com a motor de containerització i sandboxing, cosa molt habitual en proveïdors de cloud europeus i plataformes d'allotjament modernes.
Xarxa: integració amb ModemManager i noves opcions de rendiment
A la capa de xarxa, systemd-networkd segueix guanyant pes. Una de les novetats destacades és la seva integració amb ModemManager mitjançant el protocol “simple connect”, el que permet gestionar mòdems i connexions mòbils directament des de networkd sense dependre de ferramentes externes.
Per suportar aquest flux s'hi afegeix una nova secció als fitxers de configuració, amb paràmetres com APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=. Això facilita desplegaments a zones rurals o entorns amb connectivitat basada en xarxes mòbils, molt presents a determinats territoris d'Europa on no sempre hi ha fibra o línies fixes de qualitat.
En el plànol de rendiment, els fitxers .enllaç de systemd-networkd incorporen noves opcions específiques per a dispositius Ethernet. Entre elles trobem ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList i GenericReceiveOffloadUDPForwarding. Aquestes opcions permeten afinar la descàrrega de treball al maquinari i als drivers, una cosa clau en xarxes corporatives, centres de dades i proveïdors de serveis que necessiten esgotar cada mil·lisegon de latència.
A més, les interfícies Varlink i JSON de systemd-networkd ara són capaços d'informar adreces IP en un format llegible per a humans (cadenes) alhora que mantenen la representació com a array de sencers. Això simplifica la integració amb panells de monitorització, scripts dadministració o eines de tercers que no volen bregar amb formats numèrics poc intuïtius.
Portabilitat de serveis, màquines virtuals efímeres i serveis sense privilegis
La peça systemd-portabled, encarregada de gestionar serveis “portables” empaquetats en imatges, guanya una capacitat molt interessant: es pot executar com a servei a nivell d'usuari. Això significa que usuaris sense privilegis, a la sessió normal, poden llançar i gestionar serveis portables dins del seu propi espai sense recórrer a sudo ni elevar privilegis.
A més, des d'aquesta versió, portable pot generar polítiques i fixar la imatge associada a un servei portable, fent que aquesta imatge no es pugui modificar sense tornar a adjuntar-la. Els usuaris poden així muntar entorns autocontinguts amb garanties addicionals d'immutabilitat, una cosa força atractiva per a laboratoris, entorns de desenvolupament i sandboxes de proves.
D'altra banda, systemd-vmspawn —l'eina pensada per llançar màquines virtuals de manera integrada amb systemd— amplia les seves capacitats per registrar-se a systemd-machined dins de la sessió d'usuari. També introdueix una opció –ephemeral per crear màquines efímeres que es destrueixen en finalitzar-ne l'ús. Això encaixa de meravella amb pipelins de CI/CD, aules virtuals o plataformes educatives europees que requereixen aixecar i llençar màquines de forma ràpida i controlada.
Control fi de CPU, memòria i planificació amb SCHED_EXT i THP
Systemd 260 també es fica de ple en el control de rendiment amb noves directives. L'opció de servei CPUSchedulingPolicy= accepta ara el valor ext, que activa el planificador SCHED_EXT. Aquest planificador alternatiu obre la porta a experiments amb polítiques de planificació diferents a les estàndard del nucli, cosa que pot interessar en laboratoris de R+D o en desplegaments molt especialitzats.
A l'àrea de memòria apareix MemoryTHP=, que permet gestionar l'ús de Transparent Huge Pages (THP) per servei. En lloc de tenir un comportament global per a tot el sistema, es pot decidir si una unitat determinada ha d'aprofitar THP, desactivar-les o adoptar modes intermedis. Per a aplicacions crítiques en banca, assegurances o administracions públiques, aquest control granular pot marcar diferències en latència, consum de memòria i rendiment.
Noves comandes en systemctl i expansió de l'ús de Varlink
El conegut comando systemctl guanya una nova ordre: enqueue-marked. Aquesta acció invoca internament el mètode D-Bus EnqueueMarkedJobs() i permet treballar amb cues de feines i serveis prèviament marcats. Encara que pugui semblar un detall menor, per a equips d'operacions que orquesten granges de servidors a gran escala és una eina més per afinar fluxos de desplegament i automatització.
En paral·lel, el projecte continua estenent l'ús de Varlink com a mecanisme de comunicació entre components. Moltes peces de systemd exposen interfícies Varlink estables, que faciliten la integració amb eines externes, dashboards personalitzats o agents de monitoratge que necessitin un accés estructurat a la informació del sistema.
Camps d'identificació del sistema i experiència d'usuari
Una novetat curiosa, però útil per a algunes distribucions, és la introducció del camp FANCY_NAME= a l'arxiu /etc/os-release. Aquest camp s'assembla a PRETTY_NAME, però permet seqüències ANSI i caràcters Unicode més elaborats. Gràcies a això, distribucions i edicions específiques es poden presentar amb noms més vistosos o distintius.
El valor de FANCY_NAME es pot veure a través del gestor de systemd, mitjançant systemd-hostnamed o en consultar hostnamectl. Encara que és un canvi petit, en entorns descriptori i panells dadministració gràfics pot resultar pràctic per a identificar d'una ullada el sistema que s'està gestionant, especialment quan es fan servir moltes variants derivades.
Documentació específica per a agents d'IA i flux de revisió assistit
Un dels senyals més interessants de per on van els trets en el desenvolupament de systemd és l'aparició de documentació orientada expressament a agents d'intel·ligència artificial. Al repositori s'incorpora un arxiu AGENTS.md, pensat perquè eines danàlisi de codi i assistents de programació, i com recullen algunes guies de tecnologia, entenguin millor l'arquitectura del projecte, el seu estil, el flux de desenvolupament i les normes de contribució.
En aquest document es descriuen components, rutes de compilació, manera d'executar proves i integració i pautes per generar pegats acceptables. La intenció és que els agents d'IA que revisen codi o generen canvis treballin amb un context sòlid sobre com està organitzat systemd, reduint errors i suggeriments fora de lloc.
Al costat de AGENTS.md apareix un fitxer anomenat CLAU.md, que fa referència explícita al primer i està enfocat a orientar l'eina Claude Code, un dels assistents de desenvolupament basats en IA més utilitzats. D'aquesta manera, el projecte adopta de manera explícita la IA en el cicle de desenvolupament.
A més, s'hi inclou un fitxer de configuració claude-review.yml, on es defineix com cal revisar, amb ajuda de Claude Code, el procés d'anàlisi de sol·licituds de canvi (pull requests). En aquest context s'exigeix que les contribucions que hagin utilitzat IA incorporin etiquetes de divulgació com a Co-developed-by als pegats, deixant constància que una eina automàtica ha participat en l'elaboració del codi.
Amb tot aquest conjunt de canvis —neteja de suport heretat, refinament de sandboxing, millores en TPM2 i SRK, integració en xarxa avançada, noves capacitats de portabilitat i documentació pensada per a agents intel·ligents— systemd 260 reforça el seu paper central a l'ecosistema Linux modern. Per a administradors i desenvolupadors a Espanya i Europa, el repte immediat passa per revisar nuclis, adaptar configuracions d'arrencada i serveis i treure partit d'aquestes funcions per construir infraestructures més segures, automatitzades i alineades amb els usos actuals del sistema.