stabilna wersja PLD :)

[Tomasz Pala]

On Sat, Dec 31, 2016 at 19:41:31 +0100, Krzysztof Szwaba wrote:

> Czy aktualnie wszystkie usługi posiadają w PLD pełne wsparcie
> dla systemd ?

Co rozumiesz przez "pełne"?

1. W rc-scripts wiele usług nie miało w ogóle
bądź miało jakieś ułomne, czasem w ogóle niedziałające skrypty.

2. Systemd obsługuje skrypty SysV, więc wsparcie w PLD dla systemd jest
NADZBIOREM rc-scripts. O ile skrypt SysV nie jest walnięty.

3. Założenie projektowe systemd jest takie, że unity przychodzą z
upstreamu, a nie są generowane przez dystrybucje - w PLD pakujemy te
pliki, ale oczywiście upstream może mieć także walnięte. W takiej jednak
sytuacji istnieje szansa, że zgłosili to ludzie z innych dystrybucji
więc znowu - rc-scripts jest podrzędne względem systemd, także w PLD.

Mówiąc krótko: jeżeli coś nie działa w systemd, to _prawdopodobnie_ w
rc-scripts też nie działało. Tutaj nie powiem już z taką stanowczością,
bo istnieje szansa, że coś w rc-scripts działało przypadkiem, mimo
łamania przez skrypt LSB czy wszelkich innych standardów.

Jeżeli pytasz natomiast o _natywne_ wsparcie dla systemd - odpowiem, że
nie ma to znaczenia. Oczywiście, jakieś foobard sprzed 23 lat nie będzie
zapewne miało .service, bo po prostu nikt tego nie używa. Np.
http://git.pld-linux.org/packages/tacacs.git


Rozwijając jeszcze odpowiedź, już z pewnością poza to, o co pytasz -
jeszcze dużo gnojówki z Wiejskiej wyleją, zanim same usługi będą miały
pełne wsparcie DLA systemd (w tę stronę). W systemd, poza nadrzędnym
supervisorem i journalem, o którym wiele niedorzeczności już
powiedziano, masz takie rzeczy jak watchdoga dla serwisów (sd_notify) czy nowe
struktury do logowania (zdecydowanie to bardziej rozbudowane, niż
facility i level, a do tego katalogi komunikatów). Zanim oprogramowanie
przesiądzie się z tych swoich furmanek (samodzielne
forkowanie/demonizacja procesów, pliki PID-ów) do mercedesa klasy S (bo
mniej więcej taka jest różnica pomiędzy rc-scripts a systemd), nie
będziesz chyba czekał z boku z widłami?

Pominę już tutaj takie oczywiste rzeczy jak kontrola zasobów na poziomie
unitów (MemoryLimit samo włącza accouting, nasz OOTB nice level, scheduling
policy, ionice), dropowanie uprawnień, ograniczanie dostępu do
katalogów, separacja sieci itp. Chyba w kernelu 4.10 doszła możliwość podpinania
BPF-a pod grupy - czyli zaraz będziesz mógł budować swoistego firewalla
dla aplikacji. Jak sobie wyobrażasz wykorzystanie tego mechanizmu bez
systemd? A w ogóle w jaki sposób dzisiaj nadajesz określonemu
użytkownikowi prawa do zarządzania określonymi usługami? - czy z roota
pracujesz? Zobacz sobie działanie systemd-nspawn --ephemeral na btrfsie.

Na prawdę trzeba mieć BARDZO DOBRY powód, żeby NIE korzystać z systemd.
Jeżeli takiego powodu nie znasz, to o rc-scripts spokojnie zapomnij.
Nawt jeżeli natrafisz na coś niedziałającego, to szybciej się uwiniesz z
naprawą pod systemd, niż gdybyś marnował czas na rzeźbienie skryptów.

A i tak od wszelkich wannabe i innego chaxiorstwa usłyszysz, że w systemd
chodzi o szybsze uruchamianie systemu;)

-- 
Tomasz Pala <gotar at pld-linux.org>