rc-scripts strikes back (długie)

[Tomasz Trojanowski]

Luźne rozważania na temat rc-scriptów

Próby wdrożenia naszych rc-skryptów na Pewnym Dziwnym Systemie(TM) 
doprowadziła mnie do zastanowienia się nad tym czego oczekiwałbym od
rc-skryptów. Było to już oczywiście dyskutowane, ale racji tego że
archiwa list poszły się pier^H^H^Haść razem z dyskiem laptopa, a
lists.pld-linux.org zawiera to co zawiera, nie nogę zweryfikować co
jest wtórnym pomysłem, a co stanowi twórczość własną. Więc wybaczcie,
jeśli nie zwiększę komuś wskaźnika cytowań.

1. Zalezności

Obecny model oparty o skrypty startowe SysV mają dość uciążliwą wadę -
wymagają sztywnego ustalenia "numerków" określających priorytety 
uruchamiania poszczególnych usług. Jako że uważam, że od tego mamy
komputery żeby robiły za nas wszystko co możliwe, albo jeszcze więcej,
nie widze potrzeby żeby deweloper miał się zajmowac ustalaniem jakichś
numerków -- wystarczy że ustali pewne zalezności np. networking przed
apache, timezone przed syslog, syslog przed ssh. A sam silnik skryptów
ustali sobie konieczność uruchamiania.

Są mi znane dwa rozwiązania które dostarczają obsługę zalezności w
skryptach startowych, obydwa bardzo podobne: skrypty Free(Net)BSD
i skrypty R.Goocha. Rożnią się one tylko technicznym rozwiązaniem
odnajdywania zależności.

Dodatkowo skrypty skrypty FreeBSD są za bardzo rozdrobnione. Są tam
nawet osobne skrypty do tworzenia /etc/motd czy ustalania hostname, czy
nawet uruchamiania swapu. Takie rzeczy powinny IMO zostać w monolitycznym
skrypcie startowym (u nas rc.sysinit), a na osobne pliki rozbite tylko
usługi (z racji ewentualnej konieczności ich startowania i stopowania
niezaleznie od samego startowania systemu). Generalnie, rzeczy które i tak
są zawsze robione tylko raz nie powinny być wydzielane do osobnych plików.

Kolejną wadą tych rozwiązań jest problem z wyłączaniem uruchamiania
pewnych usług w procesie bootwania systemu, ale to można rozwiązać
w prosty sposób zachowując system symlinków w /etc/rc.d/rc?.d ale
bez "numerków". Na tej podstawie może być określane jakie usługi bają
być uruchamiane onboot.

Brakuje mi jeszcze "logiki rozmytej" w rodzaju:
- uruchom usługę xxx najwcześniej jak to możliwe (z naszego podwórka random
   albo killall, to ostatnie z racji odwrócenia kolejności stopowania
   usług)
- uruchom usługę yyy nie wcześniej niż to będzie konieczne (u nas allowlogin)

No i na koniec, to co już zostało nie tak dawno wspomniane na pld-devel-en.
Konieczność restartowania niektórych usług przy restartowaniu innych
dhcp, htb przy restarcie networking.

2. Jednoczesność zdarzeń

Ktoś (twittner?) pisał o uruchamianiu kilku usług jednocześnie. Jak dla mnie
nie ma to wiekszego znaczenia. Desktopy (i ich użytkownicy) mnie nie
interesują :P, a większość moich maszyn i tak jest restartowana średnio trzy
razy w roku. Inna sprawa, że podczas fsckowania i tak mi mysql i apache
nie wstaną (przynajmniej nie na znanych z linuksa filesystemów).

3. Runlevele

No właśnie, czy na współczesnych maszynach ktoś jeszcze tego do czegokolwiek
używa? Moim zdaniem najwyższy czas zrezygnować z zaszłości historycznych
i podziękować runlevelom za współpracę, pozostawiając ewentualnie dwa tryby
pracy: single i normal. Czyba że się mylę.

Widzę to tak, że w /etc/rc.d są katalogi:
init.d   - ze skryptami poszczególnych usług
normal.d - z linkami do skryptów uruchamianych w "normalnym" trybie
single.d - z linkami do skryptów uruchamianych w singlu

4. networking

Ta usługa jako całość wydaje mi sie za bardzo skompilowana. FAjnie byłoby 
ją podzielić ja mniejsze składowe. Prosty przykład:
netif   - podnosi fizyczne interfejsy
routing - ustala routing (i wymaga netif)
bridge  - uruchamia bridge'a (i wymaga netif)
ppp     - podnosi ppp (i przychodzi z pakietem ppp)

To ostatnie chyba jednak mocno naciągane

5. Ktoś doczytał to do końca?

19. Koniec

Pozdrawiam

-- 
Tomasz Trojanowski (tomek w uninet.com.pl)

"Between depriving a man of one hour from his life and depriving him of
his life there exist only a difference of degree." (FH, Dune Messiah)