systemd 259: canvis clau i requisits del sistema

Informatec Digital » Recursos » systemd 259: canvis clau i requisits del sistema

L'aparició de systemd 259 com a versió estable suposa un altre gir de femella en un dels components més polèmics i essencials de l'ecosistema Linux. Parlem del marc d'inici i gestió de serveis que ja domina la majoria de distribucions, i que en aquest lliurament apreta encara més les femelles quant a requisits tècnics, seguretat i abandó de tecnologies heretades.

Aquesta actualització arriba després de diversos mesos de treball intens i se centra en tres grans fronts: compatibilitat amb noves biblioteques C, enduriment de la seguretat i neteja de codi legacy (scripts SysV, TPM 1.2, iptables, etc.). A més, introdueix canvis rellevants en la gestió de privilegis amb run0, en el tractament de la memòria amb systemd-oomd, en l'emmagatzematge de logs i en el model de dependències internes de libsystemd.

systemd 259 i el suport experimental per a musl

Un dels moviments més comentats d'aquesta versió és que systemd 259 incorpora per primera vegada compatibilitat parcial amb la biblioteca estàndard de C musl . Aquesta biblioteca es fa servir molt en sistemes lleugers, contenidors minimalistes i entorns embeguts, on es busca simplicitat i un consum reduït de recursos davant de glibc.

El suport per a la cuixa s'activa configurant l'opció "libc" del sistema de compilació Meson amb el valor "musl" . No obstant això, aquesta integració està lluny de ser completa: musl no implementa el mecanisme NSS (Name Service Switch), cosa que obliga a deshabilitar diverses peces de systemd quan es compila contra aquesta biblioteca.

En concret, en construir systemd 259 amb musl queden fora components clau com nss-systemd, nss-resolve, systemd-homed, systemd-userdbd i systemd-nsresourced . Tampoc no està disponible l'opció DynamicUser ni la possibilitat d'executar systemd-nspawn sense privilegis, especialment rellevant en entorns de contenidors on es depèn molt d'aquestes capacitats.

Els mateixos desenvolupadors avisen que no garanteixen mantenir aquest suport a llarg termini . La seva continuïtat dependrà de l'interès real de la comunitat, de la maduresa de les capes addicionals que aportin les funcions que la musl no inclou i dels informes d'errors específics per a aquesta biblioteca. Si la demanda és baixa o el manteniment és massa complex, no seria estrany que aquest suport es revisés en futures versions.

Amb tot, aquesta obertura cap a cuixa és important a nivell simbòlic: systemd feia anys que era criticat per la seva dependència gairebé exclusiva de glibc , cosa que ho feia poc amigable per a distribucions alternatives i escenaris molt minimalistes. Aquest pas no ho soluciona tot, però trenca amb aquesta imatge de peça totalment tancada a altres biblioteques C.

run0 i el nou model de privilegis: alternativa a sudo

Una altra gran protagonista de systemd 259 és la utilitat run0, plantejada com a substituta moderna i més segura de sudo. Aquesta eina ja estava construïda sobre systemd-run, però ara guanya una capacitat clau: l'opció --empower.

El nou argument –empower permet iniciar una sessió amb privilegis elevats sense canviar l'UID a root . En comptes de fer un canvi d'usuari tradicional, run0 estira les capacitats del nucli (per exemple, CAP_SYS_ADMIN) per atorgar exactament els permisos que calen per executar accions privilegiades, reduint l'exposició que suposa convertir-se en root del tot.

A més, els processos que s'arrenquen amb aquesta modalitat s'agrupen en un grup lògic “empower” amb accés a un conjunt ampli d'accions gestionades per Polkit . La idea és que l'augment de privilegis sigui granular i controlat, mantenint una separació més estricta que la que sol oferir el sudo clàssic, on sovint s'acaba obrint massa la porta.

Aquest enfocament encaixa amb la tendència d' evitar l'ús directe de l'usuari root sempre que sigui possible , cosa molt valorada en seguretat. Ara bé, l'eficàcia real de run0 encara s'haurà de demostrar en producció: caldrà veure com s'integra amb les polítiques de cada distribució, com es configuren les capacitats a la pràctica i com s'adapta l'administració de sistemes al nou flux de treball.

Fi del suport a SysV init i neteja de llegat

systemd 259 suposa també l' inici de la fi definitiva dels scripts de servei a l'estil System V . La compatibilitat amb aquests mecanismes clàssics feia anys que estava marcada com “en retirada”, i ara es concreta un calendari clar per a la seva eliminació.

En aquesta versió s'anuncia que, de cara a la següent gran entrega, desapareixeran components històrics com systemd-sysv-generator, systemd-rc-local-generator i systemd-sysv-install. És a dir, els scripts a /etc/init.d/ deixaran de ser tinguts en compte per systemd, cosa que tanca una transició que s'ha prolongat durant prop d'una dècada.

Per a administradors que encara mantenien serveis personalitzats basats en scripts SysV , això obliga a posar fil a l'agulla: cal inventariar tots aquests scripts i migrar-los a unitats natives de systemd (.service, .socket, etc.). Les distribucions grans ja tenen gairebé tota aquesta transició feta, però en entorns a mida o instal·lacions antigues encara poden quedar “relíquies” funcionant en segon pla.

Aquest procés de neteja de llegat no es limita a SysV. En versions recents de systemd ja es venia retirant suport per a mètodes clàssics com /forcefsck o /fastboot , substituint-los per paràmetres de kernel i mecanismes de credencials més moderns. Amb 259, la direcció és la mateixa: menys compatibilitat cap enrere a canvi d'un codi base més mantenible i coherent.

Requisits mínims de systemd 259: kernel, biblioteques i entorn

Un dels canvis que pot tenir més impacte en sistemes antics és l' augment dels requisits mínims de programari per executar systemd 259 . Aquesta versió ja no es preocupa per maquinari ni stacks massa vells, i empeny de manera clara cap a plataformes modernes.

Entre els requisits destacats que es consoliden a systemd 259 hi ha: una aposta per plataformes modernes

• Kernel de Linux 5.10 com a mínim (amb una recomanació d'anar com a mínim a 5.14).
• glibc2.34 com a versió mínima de la biblioteca estàndard GNU.
• OpenSSL 3.0.0 com a base obligatòria per a les funcions de xifratge suportades.
• util-linux 2.37 com a requisit per a les utilitats bàsiques del sistema.
• libxcrypt 4.4.0 per a la gestió de funcions criptogràfiques relacionades amb contrasenyes.
• cryptsetup 2.4.0 i libseccomp 2.4.0 per a xifratge de volums i filtratge de trucades al sistema.
• 3.9.0 Python com a dependència mínima per a eines auxiliars.
• En algunes notes s'esmenta també elfutils 0.177 com a part del conjunt de dependències actualitzades.

Aquest enduriment implica que equips molt antics o distribucions que s'aferren a branques de nucli prèvies a 5.10 queden automàticament fora del suport per a aquesta versió, llevat que n'actualitzin la base tecnològica. A canvi, s'aconsegueix un ecosistema més homogeni amb menys casos especials i solucions de compromís.

Per a la majoria de distribucions generalistes d'escriptori i servidor, aquests requisits no haurien de ser un drama: les branques LTS modernes del nucli ja superen de sobres la barrera de 5.10 i les biblioteques esmentades estan àmpliament difoses. Els problemes més grans poden arribar en sistemes embeguts, appliances o instal·lacions molt conservadores que no s'actualitzen amb freqüència.

seguretat reforçada: TPM 2.0, xifrat i restriccions de dispositius

Al camp de la seguretat, systemd 259 prem el pas amb diverses decisions de pes. La més visible és que systemd-boot i systemd-stub abandonen definitivament el suport per a TPM 1.2 , de manera que a partir d'ara només es contempla TPM 2.0 com a estàndard de referència.

Aquest canvi significa que, en sistemes que es recolzaven en TPM 1.2 per gestionar polítiques d'arrencada segura o claus de xifratge , caldrà actualitzar el maquinari (per exemple, canviant la placa base) si es vol seguir usant aquestes funcions amb les noves versions de systemd-boot. Molts usuaris d'escriptori Linux tenen TPM i Secure Boot desactivats, així que és possible que ni notin el canvi, però en entorns corporatius o d'alta seguretat sí que pot tenir impacte.

En lliuraments previs, com systemd 258, ja s'havien realitzat ajustaments importants en aquesta línia: OpenSSL va passar a ser l'única biblioteca de xifratge suportada per systemd-resolved i systemd-importd , deixant fora alternatives com GnuTLS i libgcrypt. Tot plegat apunta a una consolidació al voltant d'un conjunt d'eines criptogràfiques més reduït i controlat.

També a la branca 258 es van introduir restriccions més severes d'accés per defecte a tty/pts : els nodes es creen amb permisos 0600 en lloc de 0620, evitant que altres usuaris puguin escriure a les nostres terminals. És un altre exemple de com systemd fa temps que ajusta detalls de baix nivell que, sumats, reforcen la seguretat global del sistema.

libsystemd més modular i amb càrrega dinàmica

A la recerca de més eficiència i una menor càrrega de dependències, systemd 259 introdueix canvis profunds en la forma en què libsystemd interactua amb altres biblioteques del sistema . L'objectiu és que no tot s'arrossega des de l'inici, sinó que es carregui només quan cal.

Concretament, libsystemd passa a usar dlopen() per a carregar dinàmicament llibreries com libacl, libblkid, libseccomp, libselinux i libmount . Això vol dir que aquestes dependències no s'enllacen de manera rígida en temps de compilació ni es carreguen sempre en memòria: només s'activen quan alguna funcionalitat específica ho requereix.

Aquest mateix mecanisme amb dlopen() també s'aplica a la integració amb el subsistema d'auditoria de Linux i amb PAM . D'aquesta manera, l'arrencada i l'operació normal de systemd poden ser més lleugers en entorns que no necessiten totes aquestes peces alhora.

D'altra banda, la funcionalitat proporcionada anteriorment per la biblioteca libcap s'ha integrat directament a libsystemd . Així s'elimina una dependència externa més, simplificant la cadena de construcció i reduint possibles punts de fallada o incompatibilitat.

En línies generals, aquest enfocament aporta una millor modularitat i un menor footprint de memòria i disc , especialment en sistemes on es busca una arrencada ràpida i un conjunt de serveis molt ajustat.

Canvis en xarxa i contenidors: adéu iptables, hola nftables

L'àrea de xarxes i de virtualització també pateix canvis rellevants. A partir de systemd 259, systemd-networkd i systemd-nspawn deixen de suportar la creació de regles NAT mitjançant iptables/libiptc . L'únic backend de firewall admès passa a ser nftables.

Això afecta directament contenidors gestionats amb systemd-nspawn que depenien de NAT via iptables , així com a xarxes definides en systemd-networkd que utilitzaven regles de traducció d'adreces amb el backend clàssic. En proves amb versions candidates, s'han observat errors silenciosos en la funcionalitat de NAT fins que es migrava tota la configuració a nftables.

Més enllà de la traducció d'adreces, systemd-resolved guanya la capacitat d'usar ganxos locals en /run/systemd/resolve.hook/, que s'executen cada vegada que es fa una consulta de resolució de noms local. Això obre la porta a personalitzacions avançades de DNS i lògica específica per part de l'administrador.

En l'àmbit de la importació i gestió d'imatges, systemd-importd incorpora lògica nativa per treballar amb fitxers TAR, recolzant-se en libarchive de la utilitat tar de GNU. A més, tant systemd-importd com systemd-machined poden ara executar-se en mode usuari, gestionant imatges de sistema col·locades a ~/.local/state/machines/.

Per controlar aquests modes, la utilitat importctl afegeix les opcions “–user” i “–system” , permetent triar fàcilment si volem operar en el context de l'usuari oa nivell de sistema. Aquest enfocament és útil per a entorns de desenvolupament i proves on no es vol tocar la configuració global de la màquina.

Journal persistent per defecte i gestió de l'espai al disc

Un altre canvi amb impacte pràctic és la modificació del mode d'emmagatzematge per defecte del journal, el subsistema de logs de systemd. Fins ara, el comportament "automàtic" depenia de l'existència o no del directori /var/log/journal.

Amb systemd 259, el mode per defecte passa a ser «persistent» , independentment de si aquesta carpeta existia abans o no. És a dir, el journal es guardarà en disc de forma permanent per defecte, en lloc de limitar-se a emmagatzematge volàtil a RAM.

Aquesta decisió té pros i contres. D'una banda, facilita molt el diagnòstic de problemes , ja que els logs sobreviuen als reinicis sense que l'administrador hagi de fer res d'especial. De l'altra, en sistemes encastats, contenidors lleugers o entorns amb emmagatzematge molt limitat, es pot traduir en un augment notable del consum de disc.

En aquests escenaris serà més important que mai ajustar les polítiques de rotació i mida del journal , o fins i tot forçar una manera d'emmagatzematge diferent si es vol evitar un desgast excessiu (per exemple, en memòries flaix amb cicles d'escriptura limitats).

systemd-oomd, seguiment d'OOM i control de recursos

La gestió de memòria i els escenaris de “Out Of Memory” també reben millores interessants. El component systemd-oomd, encarregat de reaccionar davant de situacions de memòria insuficient , incorpora noves propietats per oferir més visibilitat.

En concret, ara es disposa de les propietats OOMKills i ManagedOOMKills als serveis , que recullen el nombre de processos acabats pel kernel o pel propi systemd-oomd a causa de manca de memòria. Aquesta informació es pot consultar directament amb les eines de systemd, facilitant l'anàlisi posterior d'incidents.

Quan un procés es descontrola i comença a cruspir-se la RAM fins al punt de posar en perill el sistema , aquestes mètriques permeten veure d'una ullada quines unitats s'han vist afectades, quantes vegades s'ha disparat el mecanisme d'OOM i quins components estan provocant més pressió de memòria.

Per a administradors d'entorns d'alt nivell de càrrega o sistemes amb recursos molt ajustats, aquesta capacitat d'observabilitat més gran sobre els OOM resulta especialment útil, ja que ajuda a identificar serveis mal dimensionats o fuites de memòria que abans podien passar desapercebudes.

Altres millores notables a systemd 259

A més dels grans blocs anteriors, systemd 259 ve carregat de nombroses millores i petits ajustaments repartits per tot l'ecosistema . Moltes són molt tècniques, però convé repassar-les perquè juntes sumen un canvi rellevant.

Entre les novetats de l'API, la interfície basada en el protocol Varlink s'amplia per permetre accedir a la configuració de serveis i executar trucades IPC com Reload() y Reexecute(). També s'hi afegeixen trucades específiques per gestionar funcionalitats de systemd-repart, systemd-resolved i systemd-networkd.

Al terreny de configuració i unitats, s'introdueix l'opció ExecReloadPost , que permet llançar ordres just després de recarregar la configuració d'un servei. A més, els fitxers de configuració que acabin en «.ignore» passen a ser descartats automàticament , un truc senzill per desactivar fitxers sense haver d'esborrar-los o reanomenar-los de forma més dràstica.

Les unitats temporals guanyen la propietat RootDirectoryFileDescriptor, que defineix el descriptor de fitxer corresponent al directori arrel, i se suma una nova opció UserNamespacePath, que permet vincular una unitat a un espai de noms d'usuari especificant una ruta a /proc. A systemd-nspawn, apareix la directiva NamespacePath a la secció dels fitxers .nspawn per indicar l'espai de noms de xarxa a utilitzar.

Altres components com systemd-sysext i systemd-confext incorporen fitxers de configuració dedicats en /etc/systemd/systemd-sysext.conf y /etc/systemd/systemd-confext.conf. Les variables d'entorn SYSTEMD_SYSEXT_OVERLAYFS_MOUNT_OPTIONS y SYSTEMD_CONFEXT_OVERLAYFS_MOUNT_OPTIONS permeten ajustar les opcions de muntatge per a Overlayfs.

Al món d'udev, s'afegeix l'opció OPTIONS=»dump-json» a systemd-udevd per mostrar l'estat actual d'un esdeveniment en format JSON, la funció net_id genera noms predictibles per a interfícies sense fil en sistemes amb DeviceTree i es creen enllaços simbòlics /dev/gpio/by-id/... per a dispositius GPIO.

La part dusuaris i comptes també es reforça: la base de dades dels usuaris incorpora un camp UUID, la utilitat userdbctl admet l'opció “–uuid” per cercar per aquest identificador, i homectl update ara suporta “–recovery-key” per afegir claus de recuperació a comptes existents.

Al systemd-homed s'incorporen les opcions “–prompt-shell” i “–prompt-groups” durant la primera arrencada mitjançant systemd-homed-firstboot.service, i en systemd-firstboot apareix “–prompt-keymap-auto” per preguntar pel mapa de teclat quan s'usa la consola local al primer inici.

El gestor d'arrencada systemd-boot suma la possibilitat de definir el nivell de detall del log amb el paràmetre log-level en loader.conf o amb el camp SMBIOS io.systemd.boot.loglevel. A més, es consoliden requisits més estrictes per a particions com XBOOTLDR, que ara ha d'anar a VFAT, en línia amb el que ja es demana a l'ESP en sistemes UEFI moderns.

Al plànol de xarxa avançada, systemd-networkd afegeix les opcions EmitDomain i Domain per al servidor DHCP i s'implementa un controlador que determina els noms de host emesos a través de DHCP amb ajuda de la resolució DNS. Per la seva banda, systemd-modules-load passa a carregar mòduls del nucli de forma paral·lela , reduint els temps d'arrencada en equips amb molts controladors.

Finalment, a l'apartat d'integritat, systemd-integrity-setup suma suport per a algorismes HMAC-SHA256, PHMAC-SHA256 i PHMAC-SHA512 , ampliant el ventall d'opcions criptogràfiques disponibles per protegir la integritat del sistema.

Amb tot aquest conjunt de canvis, systemd 259 es consolida com una versió molt tècnica, exigent i clarament orientada al futur . Empeny a deixar enrere tecnologies heretades com SysV init, iptables o TPM 1.2, reforça la seguretat i el control de recursos, millora la modularitat interna i obre la porta a noves configuracions amb cuixa, encara que sigui de forma parcial i condicional. Per a usuaris finals en distribucions de llançament puntual, moltes novetats passaran gairebé desapercebudes; per a administradors i projectes que visquin enganxats a la darrera versió, és el moment de revisar acuradament scripts, unitats i requisits de maquinari abans de fer el salt.