Co tak naprawdę drażni w systemd
Mało który temat w świecie Linuksa potrafi wywołać tyle emocji przy piwie albo na forum co pytanie o systemd. Z jednej strony mamy ponad dekadę intensywnego rozwoju, ogromną adopcję i fakt, że większość dużych dystrybucji dawno uznała go za standard. Z drugiej – uporczywą krytykę, która nie znika mimo powszechnego wykorzystania projektu. Warto rozłożyć ją na czynniki pierwsze, bo sprowadzanie całej dyskusji do „bo tak” niewiele wyjaśnia.
Pierwszy zarzut dotyczy skali projektu. systemd zaczynał jako zamiennik klasycznego init, ale z czasem objął znacznie więcej: centralny dziennik zdarzeń (
Nie oznacza to, że wszystkie komponenty systemd działają z uprawnieniami roota – wiele usług korzysta z osobnych użytkowników systemowych i mechanizmów sandboxingu. Jednocześnie jednak część kodu wykonuje zadania uprzywilejowane lub współpracuje bezpośrednio z PID 1. W praktyce większa liczba komponentów odpowiedzialnych za podstawowe funkcje systemu oznacza większą powierzchnię wymagającą audytu bezpieczeństwa. Historia podatności, między innymi w
Dobrze ilustruje to Alpine Linux, który świadomie obrał zupełnie inną drogę: wykorzystuje OpenRC zamiast systemd i musl zamiast glibc. Nie dlatego, że OpenRC jest z definicji bezpieczniejszy. Po prostu wiele komponentów obecnych w systemd w ogóle tam nie istnieje. Mniejsza liczba usług systemowych i mniejsza złożoność upraszczają architekturę oraz ograniczają ilość kodu wymagającego utrzymania. Nie gwarantuje to automatycznie większego bezpieczeństwa, ale zmniejsza poziom skomplikowania systemu.
Drugim źródłem sporów jest filozofia projektowania. Klasyczny Unix promował niewielkie narzędzia wykonujące jedno zadanie i komunikujące się za pomocą prostych interfejsów, najczęściej tekstowych. systemd stawia na znacznie silniejszą integrację. Zamiast zestawu niezależnych programów otrzymujemy spójny ekosystem, którego elementy współpracują ze sobą i wykorzystują wspólne mechanizmy.
Dobrym kontrastem jest s6 autorstwa Laurenta Bercota. To zestaw małych programów realizujących nadzór nad usługami bez centralnego demona zarządzającego całym systemem. Nie oznacza to, że s6 jest obiektywnie lepsze od systemd. Pokazuje jedynie, że podobne cele można osiągnąć również poprzez większą modularność i podział odpowiedzialności między mniejsze narzędzia.
Trzecia kwestia ma charakter bardziej ekosystemowy niż techniczny. Wiele popularnych projektów zaczęło zakładać obecność komponentów systemd, zwłaszcza
Podobnie dystrybucje unikające systemd, takie jak Devuan, musiały przez lata utrzymywać własne rozwiązania lub alternatywne komponenty. Nikt ich do tego nie zmuszał, ale był to koszt pozostania poza dominującym ekosystemem.
Z tym wiąże się także koszt migracji. Im dłużej dystrybucja lub administrator wykorzystuje systemd, tym więcej pojawia się integracji: jednostki usług, timery, generatory, transient units czy zależności między usługami. Każda z tych funkcji jest przydatna, ale każda zwiększa koszt ewentualnego przejścia na inne rozwiązanie. Void Linux pokazuje, że można przez lata z powodzeniem opierać całą dystrybucję na runit. Jest to jednak przykład systemu zaprojektowanego od początku wokół tej technologii, a nie migracji z systemd. Łatwiej nie wejść do danego ekosystemu niż później z niego wychodzić.
Jest jeszcze kwestia czytelności konfiguracji i diagnozowania problemów. Drop-iny w katalogach
Trzeba jednak oddać systemd to, co mu się należy. SysVinit miał rzeczywiste ograniczenia: sekwencyjny start usług, brak natywnego nadzoru nad procesami, prymitywne zarządzanie zależnościami oraz skrypty, których jakość zależała od autora pakietu. systemd rozwiązał wiele z tych problemów, wprowadzając deklaratywne zależności, równoległy start usług, automatyczne restartowanie procesów, socket activation oraz spójny sposób zarządzania usługami.
To właśnie dlatego został przyjęty przez większość dużych dystrybucji, a nie z powodu „zmowy” czy wygody maintainerów.
Krytyka systemd nie polega więc na negowaniu jego osiągnięć. Pytanie brzmi raczej, czy wszystkie te funkcje musiały znaleźć się w jednym projekcie i czy równie skuteczne rozwiązania można było osiągnąć przy mniejszym stopniu integracji.
Różne systemy init odpowiadają na to pytanie na różne sposoby.
systemd – bardzo rozbudowany zestaw komponentów, natywne supervision usług, deklaratywne zależności, socket activation, scentralizowane logowanie, timery, zarządzanie sesjami i wiele usług systemowych. Filozofia: głęboka integracja całego stosu.
SysVinit – prosty init oparty na skryptach, bez natywnego supervision i z ograniczonym mechanizmem zależności. Filozofia: prostota i przewidywalność.
OpenRC – zgodny ze skryptami SysV, oferuje równoległy start i zarządzanie zależnościami, a supervision można dodać opcjonalnie. Filozofia: modularność przy zachowaniu kompatybilności.
runit – niewielki, bardzo szybki, z wbudowanym stałym nadzorem nad procesami. Filozofia: minimum funkcji potrzebnych do skutecznego zarządzania usługami.
s6 – zaawansowany zestaw narzędzi supervision zbudowany zgodnie z filozofią małych programów współpracujących przez proste interfejsy. Dodatkowe funkcje, takie jak socket activation, realizowane są przez osobne narzędzia. Filozofia: maksymalna modularność.
sinit – ekstremalnie mały init ograniczający się praktycznie do uruchomienia pierwszych procesów. Zarządzanie usługami pozostawia użytkownikowi. Filozofia: absolutny minimalizm.
Shepherd – system init wykorzystywany przez GNU Guix, napisany w Guile, z deklaratywną konfiguracją i możliwością dynamicznego przeładowywania usług. Filozofia: integracja z modelem konfiguracji Guix.
dinit – nowoczesny system init napisany w C++, oferujący supervision, zależności usług oraz socket activation przy stosunkowo niewielkim rozmiarze kodu. Filozofia: nowoczesne funkcje bez nadmiernej rozbudowy.
Nie istnieje więc jeden obiektywnie najlepszy system init. Wybór zawsze oznacza kompromis między funkcjonalnością, prostotą, stopniem integracji i łatwością utrzymania.
systemd pozostaje najbardziej kompletnym rozwiązaniem i oferuje najgłębszą integrację z obecnym ekosystemem Linuksa. s6 reprezentuje najbardziej konsekwentne podejście do klasycznej filozofii Uniksa, choć wymaga większej wiedzy administratora. runit od lat pokazuje, że prosty system supervision może napędzać pełnoprawną dystrybucję, czego przykładem jest Void Linux. sinit pozostaje rozwiązaniem dla zwolenników ekstremalnego minimalizmu, a Shepherd wyróżnia się przede wszystkim w ekosystemie GNU Guix.
To właśnie o ten kompromis od kilkunastu lat toczy się cała dyskusja wokół systemd.
#linux #systemd #unix #opensource #opensource #sysadmin #administracja #serwery #devops #programowanie #informatyka #cyberbezpieczenstwo #technologia #software #foss #gnu_linux #archlinux #debian #alpine #voidlinux #gnulinux #fsf
Mało który temat w świecie Linuksa potrafi wywołać tyle emocji przy piwie albo na forum co pytanie o systemd. Z jednej strony mamy ponad dekadę intensywnego rozwoju, ogromną adopcję i fakt, że większość dużych dystrybucji dawno uznała go za standard. Z drugiej – uporczywą krytykę, która nie znika mimo powszechnego wykorzystania projektu. Warto rozłożyć ją na czynniki pierwsze, bo sprowadzanie całej dyskusji do „bo tak” niewiele wyjaśnia.
Pierwszy zarzut dotyczy skali projektu. systemd zaczynał jako zamiennik klasycznego init, ale z czasem objął znacznie więcej: centralny dziennik zdarzeń (
journald), resolver DNS (resolved), zarządzanie sesjami (logind), konfigurację sieci (networkd), synchronizację czasu (timesyncd), timery będące alternatywą dla crona i wiele innych elementów. Każdy z tych komponentów z osobna ma swoje uzasadnienie. Kontrowersje budzi jednak fakt, że są rozwijane w ramach jednego ekosystemu, mają wspólny cykl wydawniczy i często korzystają ze wspólnej infrastruktury.Nie oznacza to, że wszystkie komponenty systemd działają z uprawnieniami roota – wiele usług korzysta z osobnych użytkowników systemowych i mechanizmów sandboxingu. Jednocześnie jednak część kodu wykonuje zadania uprzywilejowane lub współpracuje bezpośrednio z PID 1. W praktyce większa liczba komponentów odpowiedzialnych za podstawowe funkcje systemu oznacza większą powierzchnię wymagającą audytu bezpieczeństwa. Historia podatności, między innymi w
journald czy systemd-resolved, pokazuje, że nie jest to wyłącznie teoretyczny problem. Oczywiście podobne błędy zdarzają się również w innych projektach – różnica polega głównie na skali całego ekosystemu.Dobrze ilustruje to Alpine Linux, który świadomie obrał zupełnie inną drogę: wykorzystuje OpenRC zamiast systemd i musl zamiast glibc. Nie dlatego, że OpenRC jest z definicji bezpieczniejszy. Po prostu wiele komponentów obecnych w systemd w ogóle tam nie istnieje. Mniejsza liczba usług systemowych i mniejsza złożoność upraszczają architekturę oraz ograniczają ilość kodu wymagającego utrzymania. Nie gwarantuje to automatycznie większego bezpieczeństwa, ale zmniejsza poziom skomplikowania systemu.
Drugim źródłem sporów jest filozofia projektowania. Klasyczny Unix promował niewielkie narzędzia wykonujące jedno zadanie i komunikujące się za pomocą prostych interfejsów, najczęściej tekstowych. systemd stawia na znacznie silniejszą integrację. Zamiast zestawu niezależnych programów otrzymujemy spójny ekosystem, którego elementy współpracują ze sobą i wykorzystują wspólne mechanizmy.
Dobrym kontrastem jest s6 autorstwa Laurenta Bercota. To zestaw małych programów realizujących nadzór nad usługami bez centralnego demona zarządzającego całym systemem. Nie oznacza to, że s6 jest obiektywnie lepsze od systemd. Pokazuje jedynie, że podobne cele można osiągnąć również poprzez większą modularność i podział odpowiedzialności między mniejsze narzędzia.
Trzecia kwestia ma charakter bardziej ekosystemowy niż techniczny. Wiele popularnych projektów zaczęło zakładać obecność komponentów systemd, zwłaszcza
logind. Przykładowo środowisko GNOME korzysta z API dostarczanego przez logind, a dystrybucje nieużywające systemd potrzebowały kompatybilnej implementacji tego interfejsu. Tak powstały rozwiązania takie jak elogind, które pozwalają korzystać z części ekosystemu GNOME bez instalowania pełnego systemd.Podobnie dystrybucje unikające systemd, takie jak Devuan, musiały przez lata utrzymywać własne rozwiązania lub alternatywne komponenty. Nikt ich do tego nie zmuszał, ale był to koszt pozostania poza dominującym ekosystemem.
Z tym wiąże się także koszt migracji. Im dłużej dystrybucja lub administrator wykorzystuje systemd, tym więcej pojawia się integracji: jednostki usług, timery, generatory, transient units czy zależności między usługami. Każda z tych funkcji jest przydatna, ale każda zwiększa koszt ewentualnego przejścia na inne rozwiązanie. Void Linux pokazuje, że można przez lata z powodzeniem opierać całą dystrybucję na runit. Jest to jednak przykład systemu zaprojektowanego od początku wokół tej technologii, a nie migracji z systemd. Łatwiej nie wejść do danego ekosystemu niż później z niego wychodzić.
Jest jeszcze kwestia czytelności konfiguracji i diagnozowania problemów. Drop-iny w katalogach
.d, generatory tworzące jednostki podczas startu czy jednostki tymczasowe powstające dynamicznie sprawiają, że system jest bardzo elastyczny. Jednocześnie zwiększają liczbę miejsc, które trzeba przeanalizować podczas awarii. W praktyce administrator często korzysta z journalctl, systemctl status czy systemd-analyze, analizując wiele warstw konfiguracji. W klasycznym SysVinit większość logiki znajdowała się w skryptach /etc/init.d/, które można było po prostu przeczytać od początku do końca.Trzeba jednak oddać systemd to, co mu się należy. SysVinit miał rzeczywiste ograniczenia: sekwencyjny start usług, brak natywnego nadzoru nad procesami, prymitywne zarządzanie zależnościami oraz skrypty, których jakość zależała od autora pakietu. systemd rozwiązał wiele z tych problemów, wprowadzając deklaratywne zależności, równoległy start usług, automatyczne restartowanie procesów, socket activation oraz spójny sposób zarządzania usługami.
To właśnie dlatego został przyjęty przez większość dużych dystrybucji, a nie z powodu „zmowy” czy wygody maintainerów.
Krytyka systemd nie polega więc na negowaniu jego osiągnięć. Pytanie brzmi raczej, czy wszystkie te funkcje musiały znaleźć się w jednym projekcie i czy równie skuteczne rozwiązania można było osiągnąć przy mniejszym stopniu integracji.
Różne systemy init odpowiadają na to pytanie na różne sposoby.
systemd – bardzo rozbudowany zestaw komponentów, natywne supervision usług, deklaratywne zależności, socket activation, scentralizowane logowanie, timery, zarządzanie sesjami i wiele usług systemowych. Filozofia: głęboka integracja całego stosu.
SysVinit – prosty init oparty na skryptach, bez natywnego supervision i z ograniczonym mechanizmem zależności. Filozofia: prostota i przewidywalność.
OpenRC – zgodny ze skryptami SysV, oferuje równoległy start i zarządzanie zależnościami, a supervision można dodać opcjonalnie. Filozofia: modularność przy zachowaniu kompatybilności.
runit – niewielki, bardzo szybki, z wbudowanym stałym nadzorem nad procesami. Filozofia: minimum funkcji potrzebnych do skutecznego zarządzania usługami.
s6 – zaawansowany zestaw narzędzi supervision zbudowany zgodnie z filozofią małych programów współpracujących przez proste interfejsy. Dodatkowe funkcje, takie jak socket activation, realizowane są przez osobne narzędzia. Filozofia: maksymalna modularność.
sinit – ekstremalnie mały init ograniczający się praktycznie do uruchomienia pierwszych procesów. Zarządzanie usługami pozostawia użytkownikowi. Filozofia: absolutny minimalizm.
Shepherd – system init wykorzystywany przez GNU Guix, napisany w Guile, z deklaratywną konfiguracją i możliwością dynamicznego przeładowywania usług. Filozofia: integracja z modelem konfiguracji Guix.
dinit – nowoczesny system init napisany w C++, oferujący supervision, zależności usług oraz socket activation przy stosunkowo niewielkim rozmiarze kodu. Filozofia: nowoczesne funkcje bez nadmiernej rozbudowy.
Nie istnieje więc jeden obiektywnie najlepszy system init. Wybór zawsze oznacza kompromis między funkcjonalnością, prostotą, stopniem integracji i łatwością utrzymania.
systemd pozostaje najbardziej kompletnym rozwiązaniem i oferuje najgłębszą integrację z obecnym ekosystemem Linuksa. s6 reprezentuje najbardziej konsekwentne podejście do klasycznej filozofii Uniksa, choć wymaga większej wiedzy administratora. runit od lat pokazuje, że prosty system supervision może napędzać pełnoprawną dystrybucję, czego przykładem jest Void Linux. sinit pozostaje rozwiązaniem dla zwolenników ekstremalnego minimalizmu, a Shepherd wyróżnia się przede wszystkim w ekosystemie GNU Guix.
To właśnie o ten kompromis od kilkunastu lat toczy się cała dyskusja wokół systemd.
#linux #systemd #unix #opensource #opensource #sysadmin #administracja #serwery #devops #programowanie #informatyka #cyberbezpieczenstwo #technologia #software #foss #gnu_linux #archlinux #debian #alpine #voidlinux #gnulinux #fsf
No nic, powiem tyle że nie po to szkaluje korporacyjne oprogramowanie, by potem wrócić na system w którym jedynym dostępnym init systemem jest ten należący do korporacji.