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 ([EMAIL PROTECTED])
"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)
_______________________________________________ pld-devel-pl mailing list [EMAIL PROTECTED] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
