A apărut systemd 261 și, ca de obicei, vine cu o listă lungă de noutăți, unele cu adevărat utile, altele care mă fac să ridic o sprânceană și să mă întreb încotro se îndreaptă acest proiect.
Înainte să intru în detalii, trebuie să spun că am ajuns într-un punct în care relația mea cu systemd a început să devină... complicată. Mi-a plăcut când a apărut, părea o idee bună: un manager de servicii modern, cu pornire paralelă, cu jurnalizare centralizată, cu o interfață mai coerentă decât SysV init-ul care era o adunătură de scripturi bash lipite cu scotch. Dar de la versiune la versiune, systemd tot crește, tot absoarbe funcționalități noi, și mă întreb sincer dacă nu cumva, la un moment dat, o să avem un sistem de operare numit systemd care rulează pe un kernel Linux, nu invers.
Dar să vedem ce aduce versiunea 261.
Una dintre noutățile principale este un nou subsistem pentru accesarea metadatelor din cloud, prin systemd-imdsd. Practic, dacă rulezi o mașină virtuală pe Amazon EC2, Azure, Google Compute Engine, Hetzner sau alte platforme, acest serviciu creează o interfață locală unificată prin care programele pot citi metadatele instanței, fără să se conecteze direct la endpoint-ul fiecărui furnizor în parte. Ideea în sine nu e rea - standardizarea accesului la metadate are sens dacă lucrezi cu infrastructură cloud. Există și o bază de date hardware (hwdb.d/40-imds.hwdb) care identifică platforma pe care rulezi prin informații SMBIOS, recunoscând furnizori precum Scaleway, Tencent Cloud, Alibaba ECS sau Vultr, nu doar cei mari.
Tot la capitolul cloud, versiunea 261 adaugă și posibilitatea de a restricționa accesul la rețea către serviciile de metadate ale platformelor recunoscute, lucru recomandat pentru instalările unde securitatea contează, deși notele de lansare avertizează că poate intra în conflict cu unelte clasice precum cloud-init care se așteptau la acces direct.
O altă noutate este storagectl, un nou instrument în linie de comandă care expune resursele de stocare printr-o interfață Varlink unificată, destinat stocării gestionate pentru utilizatori. Și mai interesant pentru cei care se joacă cu instalări noi este systemd-sysinstall, un installer textual simplu pentru sisteme de operare, care folosește capacitățile de partiționare și gestionare a credențialelor deja existente în systemd, copiind sistemul de pe un mediu temporar de boot precum un stick USB. Da, ai citit bine - systemd are acum și un installer de sistem de operare.
Pe partea de TPM, sistemul primește ConditionSecurity=measured-os, o condiție nouă pentru unități care verifică dacă sistemul a pornit cu semantici de boot măsurat, mai generică decât vechea ConditionSecurity=measured-uki. systemd-boot și systemd-stub măsoară acum și date SMBIOS de tip 1, 2 și 11 în PCR 1, pentru cazurile în care firmware-ul nu face aceste măsurători. A fost adăugat și un serviciu nou, systemd-tpm2-swtpm.service, pentru a rula un TPM software ca fallback pe sisteme care nu au TPM fizic.
PID 1 suportă acum mecanismele Live Update Orchestration și Kexec Handover din kernel, ceea ce înseamnă că unitățile din spațiul de stocare al descriptorilor de fișiere peste kexec dacă kernel-ul permite și dacă FileDescriptorStorePreserve=yes este setat. Același lucru este disponibil acum și pentru managerii de sesiune ale utilizatorilor.
systemd-networkd primește și el câteva lucruri noi, inclusiv comanda networkctl dhcp-lease INTERFACE care afișează informațiile despre DHCP activ. systemd-resolved suportă acum înregistrări DNS statice din fișiere JSON în directoare drop-in sub systemd/resolve/static.d/, extinde rolul clasicului /etc/hosts cu ceva mai flexibil, și recitește intrările din /etc/hosts la reload.
La capitolul containere și mașini virtuale, systemd-vmspawn primește suport pentru volume bind, operare headless, gestionare NVRAM EFI, boot direct fără firmware UEFI, tipuri selectabile de disc și manipulare a stocării prin interfața Varlink io.systemd.MachineInstance.
Există și o noutate de genul ConditionFraction=, o condiție pentru rollout-uri treptate pe flote de mașini, care folosește ID-ul mașinii și un șir de tag-uri pentru a determina dacă o unitate trebuie să ruleze pe un anumit procent din sisteme. Util dacă administrezi zeci sau sute de servere și vrei să testezi ceva pe 10% din ele mai întâi.
Acum că am trecut prin lista de noutăți, revin la ce spuneam la început. Am fost un timp convins că fragmentarea Linux-ului este o problemă și că ar fi nevoie de mai multă unificare - un init system mai consistent, unelte mai standardizate, mai puțină diversitate care complică lucrurile. Și systemd părea răspunsul la asta, cel puțin la nivel de init. Dar cu fiecare versiune nouă îmi dau seama că tocmai diversitatea asta, faptul că există distros care fug de systemd, că există oameni care construiesc alternative, că nu există o singură cale, este de fapt ceea ce face Linux-ul interesant și rezistent. Nu mai sunt pro-unificare. Uniformitatea vine cu propriul ei set de probleme.
Iar systemd continuă să crească. Acum are subsistem cloud, installer de OS, gestionare de stocare pentru utilizatori, TPM software, și câte și mai câte. La câte funcții se tot adaugă, atât utile cât și mai puțin necesare, proiectul a ajuns să nu îmi mai placă în aceeași măsură în care îmi plăcea la început. Nu că ar fi rău, are și lucruri bine gândite, dar direcția e clară: systemd vrea să fie totul. Și dacă mai continuă în ritmul ăsta, la un moment dat va fi mai ușor să întrebi ce nu face systemd decât ce face.
Comentarii