- Systemd 260 трајно уклања подршку за System V скрипте и захтева изворне јединице за све сервисе.
- Ова верзија јача интеграцију са TPM2, укључујући управљање SRK-ом и услужне програме као што су tpm2_id и systemd-pcrextend.
- Могућности „sandboxing“-а, контрола мреже и ресурси по сервису су значајно проширени, заједно са новим опцијама за контејнере и ефемерне машине.
- Пројекат укључује специфичну документацију за вештачку интелигенцију агенте и нове токове рада уз помоћ прегледа како би се побољшао квалитет доприноса.
Доласком systemd 260, Линукс дистрибуције чине још један важан корак ка модернијем, безбеднијем екосистему усмереном ка клауд окружењима, виртуелизацији и аутоматизацији. Ова верзија не само да усавршава детаље: она уводи значајне промене у покретање система, управљање услугама, умрежавање, коришћење TPM2 за интегритет и шифровање, као и могућности „sandbox“-а на нивоу диска.
Истовремено, пројекат јача своју документацију и свој приступ раду са агентима вештачке интелигенције , јасно стављајући до знања да је systemd кључни стуб са којим се повезује све више и више алата за развој и посматрање. Ако управљате Linux системима на серверима, у облаку, на корпоративним десктоп рачунарима или у лабораторијама, вреди одвојити тренутак да прегледате све ове нове функције како бисте планирали ажурирања и подешавања конфигурације.
Коначни опроштај од System V и потпуна зависност од нативних дискова
Једна од најупечатљивијих промена у systemd 260 је потпуно уклањање подршке за System V скрипте . Класични процес покретања заснован на /etc/init.d је годинама био постепено укинут, али сада ефикасно нестаје из systemd кода.
То значи да су компоненте одговорне за премошћавање између SysV скрипти и нативних јединица уклоњене: systemd-rc-local-generator, rc-local.service, systemd-sysv-generator и systemd-sysv-install више не постоје. Као резултат тога, било која услуга која и даље зависи од ових наслеђених механизама једноставно се неће покренути на системима који усвајају systemd 260.
Током процеса чишћења, неколико опција за изградњу Месона је такође означено као застарело или уклоњено. Заставице -Drc-local=, -Dsysvinit-path= и -Dsysvrcnd-path= су премештене у архиву, док су друге попут -Dintegration-tests= и -Dcryptolib= потпуно уклоњене. Ово шаље јасну поруку: све сада мора бити обрађено помоћу изворних јединица и модерне systemd инфраструктуре.
За многе европске инфраструктуре које се и даље ослањају на старије компоненте, ова промена захтева преглед интерних сервиса, прилагођених скрипти и старих имплементација. Миграција на добро дефинисане јединичне датотеке више није само препоручена; обавезна је ако желите да наставите са покретањем сервиса на дистрибуцијама које интегришу systemd 260.
Виши захтеви за језгро и фокус на тренутна окружења
Нова верзија подиже лествицу за кернел: од сада је минимална подржана верзија Линукса 5.10 , остављајући за собом веома старе гране попут 5.4. Штавише, пројекат указује да би идеално било да корисници раде на кернелу 5.14 или новијем , и посебно препоручује серију 6.6 како би се у потпуности искористиле све доступне функције.
Ово повећање захтева обично није проблем у модерним дистрибуцијама, али може да искомпликује ствари у веома конзервативним окружењима или уграђеним решењима која се одржавају дуги низ година. Пре надоградње на systemd 260, препоручљиво је проверити које се језгро користи, посебно у европским центрима података са дугорочним имплементацијама или прилагођеним сликама.
На супротном крају спектра, дистрибуције са сталним издањима попут Arch Linux-а или openSUSE Tumbleweed-а, веома популарне међу онима који желе најновије функције, имају тенденцију да брзо укључују и нова језгра и нове гране systemd-а. Друге, попут Fedora-е, одржавају одређени степен стабилности у главној верзији systemd-а током животног циклуса сваког издања, што омогућава мало више времена за планирање миграција.
TPM2, интегритет покретања и напредна SRK подршка
Једно од подручја у којем се systemd највише развија јесте његова интеграција са TPM2 (Trusted Platform Module 2.0) . Овај чип, све чешћи у модерним UEFI матичним плочама и хардверу средње и високе класе, омогућава повезивање тајни са стањем система, мерење фаза покретања и аутоматско откључавање шифрованих томова када је окружење очекивано.
Systemd 260 додатно побољшава ову интеграцију додавањем алата и услуга које покривају различите фазе процеса покретања система. Кључна компонента је systemd-tpm2-setup , одговорна за припрему инфраструктуре око TPM-овог коренског кључа за складиштење (SRK) . Овај коренски кључ служи као криптографска основа за обезбеђивање комуникације са чипом и за безбедно чување других тајни.
Током покретања система, разликују се две фазе: веома рана у initrd-у и друга у коренском систему. У првој, услуга под називом „Рано подешавање TPM SRK-а“ проверава да ли TPM већ има сачувани SRK и, ако не постоји, креира га и привремено га чини доступним под /run/systemd/tpm2-srk-public-key.* . Касније, када се монтира прави фајл систем, услуга ће консолидовати SRK и проверити да ли се кључ сачуван у /var/lib/systemd/tpm2-srk-public-key.pem подудара са оним у TPM-у.
У добро конфигурисаним сценаријима, приказиваће се уноси у дневник као што је „SRK је већ сачуван у TPM-у“ и поруке које указују да се SRK отисак подудара са очекиваним. Међутим, ако окружење није правилно конфигурисано (на пример, у подешавањима која користе Yocto или на плочама као што је Raspberry Pi са TPM-ом заснованим на SPI-ју и прилагођеним методама покретања као што су U-Boot и мерено покретање), могу се појавити ситуације у којима systemd не успева да креира ове датотеке у /var/lib/systemd, што доводи до сумње у то да ли је SRK правилно конфигурисан.
Када се стање TPM-а промени, партиције буду модификоване или се промени редослед покретања, повезана политика можда више неће бити важећа. У таквим случајевима, неки одржаваоци препоручују брисање TPM слота или политике и поновну регистрацију кључа , пратећи процедуре сличне онима описаним у водичима за шифровање диска са TPM-ом у окружењима као што је openSUSE, који детаљно описују како поново креирати PCR политику и поново повезати откључавање волумена.
Поред SRK-а, још једно практично побољшање је увођење интерног услужног програма под називом tpm2_id у udev . Овај интегрисани алат се покреће када систем детектује TPM2 уређај и аутоматски издваја произвођача и идентификатор модела . Ово поједностављује инвентар безбедносног хардвера, што је веома корисно у јавним администрацијама, регулисаним компанијама или критичним инфраструктурама где је неопходно прецизно знати који су TPM модули распоређени.
Интеграција са инфраструктуром за мерење покретања је додатно ојачана специфичним јединицама попут systemd-pcrextend , које евидентирају догађаје као што су „enter-initrd“, „leave-initrd“, „sysinit“ и „ready“ у различитим PCR-има (нпр. PCR 11). Овај низ екстензија омогућава TPM-у да акумулира криптографски проверљив запис тока покретања, који се затим може користити за политике поузданог покретања или за UKI (Unified Kernel Images) ради валидације стања машине пре отпуштања кључева.
Безбедносне мере и изолација услуга помоћу systemd-а
Systemd не само да покреће процесе, већ нуди и свеобухватан скуп директива за „sandbox“ како би изоловао сервисе и ограничио штету у случају компромитовања. Овај приступ „дубинске одбране“ ослања се на контролне групе (cgroups), именске просторе, могућности језгра (kernel) и филтере системских позива (seccomp).
Да би проценио безбедност одређене услуге, systemd укључује алатку за безбедност systemd-analyze . Његовим покретањем генерише се извештај са оценом изложености на скали од 0 до 10, где је нижа оцена боља. Извештај анализира које су заштите омогућене или онемогућене (изолација мреже, приступ систему датотека, приступ уређајима итд.), што олакшава идентификацију недостајућих подешавања и проверу да ли промене заиста побољшавају оцену.
Уместо уређивања оригиналне јединице — која би била изгубљена у будућим ажурирањима пакета — препоручује се креирање оборити en /etc/systemd/system/mi-servicio.service.d/ са датотеком, на пример, sandbox.confНакон измене, једноставно поново учитајте конфигурацију са системцтл даемон-релоад и поново покрените услугу како би нова ограничења ступила на снагу.
На нивоу фајл система, једна од најважнијих опција је ЗаштитниСистем=Вредности као што су strict, full o true Они монтирају различите делове стабла у режиму само за читање. Уобичајена пракса, када је то могуће, је да се користе ProtectSystem=strictОво чини /usr, /boot, /efi и /etc директоријуме само за читање за сервис. Ако апликација треба да пише у одређене директоријуме, то јој је дозвољено коришћењем ReadWritePaths=/путања у јединству.
Да би се додатно побољшала приватност, препоручује се и ограничавање приступа корисничким директоријумима помоћу `ProtectHome=true` , што спречава сервис да чита `/home`, `/root` или `/run/user`. Поред тога, `PrivateTmp=true` креира изоловане просторе `/tmp` и `/var/tmp`, спречавајући унакрсну видљивост привремених датотека између процеса.
У уређајима, `PrivateDevices=true` скрива стварно `/dev` стабло и замењује га минималним скупом безбедних псеудо-уређаја (null, zero, random, итд.). Ако је диску потребан одређени уређај (на пример, серијски порт или блок диска), он се може одобрити коришћењем `DeviceAllow=/dev/xxx rw` или у режиму само за читање.
Мрежа је такође кључни вектор. Са ПриватнаМрежа=тачно Креира се изоловани мрежни именски простор, остављајући само повратну петљу; сервис неће видети физичке интерфејсе и неће моћи да комуницира са спољним светом. Алтернативно, можете ограничити које породице адреса може да користи тако што ћете РестрицтАддрессФамилиес=дозвољава само AF_INET и AF_INET6 за IPv4/IPv6, AF_UNIX за локалне сокете или чак none да потпуно јапанизује мрежне могућности.
Што се тиче привилегија, директива `NoNewPrivileges=true` је једна од најмоћнијих: она спречава процес да стиче нове привилегије путем setuid бинарних датотека или промена могућности. Укратко, чак и ако сервис извршава рањиви код, не би требало да буде у могућности да ескалира до root-а путем традиционалних механизама. У комбинацији са `CapabilityBoundingSet=` , која дефинише тачну листу дозвољених могућности (на пример, само `CAP_NET_BIND_SERVICE` за слушање на ниским портовима), површина напада је минимизирана.
Да би ишли још даље, systemd омогућава филтрирање системских позива помоћу СистемЦаллФилтер=Уместо ручног одржавања листе системских позива, користе се унапред дефинисане групе, као што су @system-service, @network-io, @basic-io или одбити групе попут ~@privileged. Са systemd-analyze syscall-filter Могуће је проверити који специфични позиви припадају свакој групи. Ово омогућава конструисање веома ограниченог профила извршавања, слично ономе што би понудио наменски „sandbox“.
Остала релевантна подешавања укључују `ProtectKernelTunables=true` , које блокира модификацију параметара кернела у `/proc/sys` и `/sys`; `ProtectKernelModules=true` , које спречава учитавање или истовар модула; `ProtectKernelLogs=true` , које спречава читање логова кернела; и `ProtectControlGroups=true` , које блокира писање у хијерархију cgroups. Све ово беспрекорно функционише са новим могућностима изолације корисника као што је ` PrivateUsers=full` , која је у верзији 260 ажурирана да мапира цео опсег корисничких ИД-ова, елиминишући претходна решења потребна за угнежђена systemd окружења.
PrivateUsers, xaccess и контроле приступа новим уређајима
Механизам PrivateUsers , дизајниран да омогући сервисима да раде у изолованом простору корисничких ID-ова, консолидован је у systemd 260. Опција PrivateUsers=full сада мапира цео опсег идентификатора, поједностављујући ствари у контејнерима и на системима са угнежђеним systemd инстанцама заснованим на старијим верзијама (пре верзије 257). Ово побољшање је елиминисало хакове који су се раније користили за откривање ових старијих инстанци.
Паралелно са тим, компоненте попут systemd-logind и systemd-udevd увеле су концепт xaccess-а . Овај механизам допуњује класичну логику uaccess-а , који додељује приступ одређеним уређајима (на пример, аудио или видео) корисницима са сесијама графике у првом плану на локалној машини. Са xaccess-ом, дозволе се могу делегирати удаљеним корисницима са посебно означеним сесијама , тако да, на пример, корисник повезан преко удаљене радне површине може приступити локалним GPU уређајима за рендеровање без додељивања широких дозвола целом систему.
Конфигурација ових сесија укључује променљиве окружења које се излажу путем PAM-а, тачније PAMXDG_SESSION_EXTRA_DEVICE_ACCESS= , што омогућава дефинисање који су одређени уређаји укључени у ову логику. Овај приступ је у великој мери усклађен са захтевима Европске уније за усклађеност са прописима и заштиту података, где се захтевају грануларност и могућност праћења за приступ осетљивом хардверу.
mstack, systemd-mstack и нови алати за контејнере
У области контејнеризације, systemd 260 уводи функционалност стек и повезану команду, системски-мстекИдеја која стоји иза mstack-а је да омогући дефинисање OverlayFS на основу структуре посебног директоријума под називом .mstack/, који прати специфичну спецификацију за организовање својих слојева.
Нови алат командне линије, systemd-mstack, олакшава интерактивни рад са овим стековима фајл система, додајући флексибилност приликом подешавања слојевитих окружења за контејнере или високо изоловане сервисе. Ова функционалност је такође повезана са побољшањима у systemd-importd , који проширује своју подршку за преузимање и управљање OCI сликама , чиме се јача улога systemd-а као механизма за контејнеризацију и „sandbox“ (изолацију у затвореном простору), што је веома уобичајено међу европским добављачима услуга у облаку и модерним платформама за хостинг.
Мрежа: Интеграција са ModemManager-ом и нове опције перформанси
На мрежном слоју, systemd-networkd наставља да добија на значају. Једна од значајних нових карактеристика је његова интеграција са ModemManager-ом путем протокола „simple connect“ , који омогућава директно управљање модемима и мобилним везама из networkd-а без ослањања на спољне алате.
Да би се подржао овај ток, додат је нови одељак. у конфигурационе датотеке, са параметрима као што су APN=, AllowedAuthenticationMechanisms=, User=, Password=, IPFamily=, AllowRoaming=, PIN=, OperatorId=, RouteMetric= y UseGateway=Ово олакшава распоређивање у рурална подручја или средине са повезивањем заснованим на мобилним мрежама, веома присутна на одређеним територијама Европе где нема увек оптичких влакана или квалитетних фиксних телефона.
Што се тиче перформанси, .link датотеке systemd-networkd укључују нове опције посебно за Ethernet уређаје. То укључује ScatterGather, ScatterGatherFragmentList, TCPECNSegmentationOffload, TCPMangleIdSegmentationOffload, GenericReceiveOffloadList и GenericReceiveOffloadUDPForwarding . Ове опције омогућавају фино подешавање преноса посла на хардвер и драјвере, што је кључно у корпоративним мрежама, центрима података и код добављача услуга којима је потребно да минимизирају сваку милисекунду латенције.
Штавише, Varlink и JSON интерфејси systemd-networkd-а сада могу да пријављују IP адресе у људски читљивом формату (стрингови), док задржавају репрезентацију као низ целих бројева. Ово поједностављује интеграцију са контролним таблама за праћење, скриптама за управљање или алатима трећих страна који не желе да се баве неинтуитивним нумеричким форматима.
Преносивост сервиса, ефемерне виртуелне машине и непривилеговани сервиси
Компонента systemd-portabled , одговорна за управљање „преносивим“ сервисима упакованим у слике, добија веома занимљиву могућност: сада може да се покреће као сервис на нивоу корисника . То значи да непривилеговани корисници, у својој нормалној сесији, могу да покрећу и управљају преносивим сервисима унутар свог простора без прибегавања sudo-у или повећаним привилегијама.
Штавише, почевши од ове верзије, portabled може да генерише политике и закључа слику повезану са преносивим сервисом , спречавајући модификацију те слике без њеног поновног повезивања. Ово омогућава корисницима да подесе самостална окружења са додатним гаранцијама непроменљивости, што је посебно атрактивна карактеристика за лабораторије, развојна окружења и тестне sandbox-ове.
С друге стране, systemd-vmspawn — алат дизајниран за покретање виртуелних машина на интегрисан начин са systemd — проширује своје могућности регистрације са systemd-machined унутар корисничке сесије . Такође уводи опцију `-ephemeral` за креирање ефемерних машина које се уништавају након завршетка њихове употребе. Ово је савршено решење за CI/CD цевоводе, виртуелне учионице или европске образовне платформе које захтевају брзо и контролисано креирање и уништавање виртуелних машина.
Фино подешена контрола процесора, меморије и заказивања помоћу SCHED_EXT и THP
Systemd 260 се такође бави контролом перформанси помоћу нових политика. Опција услуге Политика заказивања процесора= сада прихватите вредност ext, што активира распоред СЦХЕД_ЕКСТОвај алтернативни планер отвара врата ка експерименти са различитим политикама планирања према стандардима језгра, нешто што би могло бити од интереса за истраживачко-развојне лабораторије или у високо специјализованим применама.
У области меморије, наћи ћете `MemoryTHP=` , која вам омогућава да управљате употребом транспарентних огромних страница (THP) на нивоу појединачних сервиса. Уместо глобалног подешавања на нивоу целог система, можете одлучити да ли одређена јединица треба да користи THP, да га онемогући или да усвоји средње режиме. За критичне апликације у банкарству, осигурању или влади, ова детаљна контрола може направити значајну разлику у латенцији, потрошњи меморије и перформансама.
Нове команде у systemctl-у и проширена употреба Varlink-а
Позната команда systemctl добија нову: enqueue-marked . Ова радња интерно позива D-Bus метод EnqueueMarkedJobs() и омогућава рад са редовима претходно означених послова и услуга. Иако се може чинити као мали детаљ, за оперативне тимове који оркестрирају велике фарме сервера, то је још један алат за усавршавање радних процеса имплементације и аутоматизације.
Паралелно, пројекат наставља да проширује употребу Varlink-а као механизма комуникације између компоненти. Многи делови systemd-а пружају стабилне Varlink интерфејсе, који олакшавају интеграцију са спољним алатима, прилагођеним контролним таблама или агентима за праћење којима је потребан структурирани приступ системским информацијама.
Поља за идентификацију система и корисничко искуство
Занимљива, али корисна нова карактеристика за неке дистрибуције је увођење поља FANCY_NAME= у архиву /etc/os-releaseОво поље подсећа на PRETTY_NAME, али дозвољава ANSI секвенце и сложенији Unicode знаковиЗахваљујући томе, одређене дистрибуције и издања могу бити представљене са упечатљивијим или препознатљивијим именима.
Вредност FANCY_NAME може се видети преко systemd менаџера, коришћењем systemd-hostnamed или упитом hostnamectl . Иако је то мала промена, у десктоп окружењима и графичким администраторским панелима може бити корисна за брзу идентификацију система којим се управља, посебно када се ради о многим изведеним варијантама.
Посебна документација за AI агенте и потпомогнути ток рада за преглед
Један од најзанимљивијих знакова правца развоја systemd-а је појава документације посебно усмерене ка агентима вештачке интелигенције . Репозиторијум укључује датотеку AGENTS.md , дизајнирану да помогне алатима за анализу кода и асистентима за програмирање, као и неке технолошке водиче , да боље разумеју архитектуру пројекта, стил, ток развоја и смернице за допринос.
Овај документ описује компоненте, путање изградње, како се покрећу тестови и интеграције, као и смернице за генерисање прихватљивих закрпа. Намера је да се агентима вештачке интелигенције који прегледају код или праве измене пружи чврсто разумевање како је systemd организован , смањујући грешке и погрешно упућене предлоге.
Уз AGENTS.md налази се датотека под називом CLAUDE.md , која експлицитно упућује на прву и дизајнирана је да води алат Claude Code, једног од најчешће коришћених развојних асистената заснованих на вештачкој интелигенцији. На овај начин, пројекат експлицитно укључује вештачку интелигенцију у свој развојни циклус.
Поред тога, укључена је и конфигурациона датотека. claude-review.ymlгде је дефинисано како треба прегледати процес анализе захтева за променама (захтеви за повлачење), уз помоћ Клода Кода. У овом контексту, доприноси који су користили вештачку интелигенцију морају да укључе ознаке за откривање информација као Co-developed-by у закрпама, остављајући доказе да је аутоматизовани алат учествовао у креирању кода.
Овим свеобухватним скупом промена – чишћењем застареле подршке, усавршавањем „sandbox“ система, побољшањем TPM2 и SRK, напредном мрежном интеграцијом, новим могућностима преносивости и документацијом дизајнираном за интелигентне агенте – systemd 260 појачава своју централну улогу у модерном Линукс екосистему. За администраторе и програмере у Шпанији и Европи, непосредни изазов лежи у прегледу језгара, прилагођавању конфигурација покретања и услуга и искоришћавању ових функција за изградњу безбеднијих, аутоматизованих инфраструктура усклађених са тренутном употребом система.