Pkiety rc z serwisami i nie tylko (kawałek sennych przemyśleń)

[Tomasz Kłoczko]

Podpatrzyłem w specu do ssh jedną ciekawą konstrukcję, która umożliwia
uczynienie upgradeu bardziej automatyczny. Otóż, jeżeli dany serwis
generuje plik z PIDem procesu serwera usługi (najczęściej w /var/run) to
można wykorzystać to do tego żeby przy upgrade pakietu sam serwis został
zrestartowany.

W ssh.spec wygląda to mniej więcej tak:

%post server
/sbin/chkconfig --add sshd

if test -r /var/run/sshd.pid
	then /etc/rc.d/init.d/sshd restart >&2
fi

%preun server
if [ "$1" = 0 ] then
	/etc/rc.d/init.d/sshd stop >&2
	/sbin/chkconfig --del sshd
fi

Wydaje mi się że powinniśmy powyższy schemat rozpropagować na wszystkie
możliwe pakiety.

W tej chwili siedzę nad hc-cron, w którego zamierzam załadować przy okazji
upgradeu do 0.11 powyższe (z nowym Qrczakowym patchem do /etc/crontab.d).
To samo niemal analogicznie zaraz trafi (jak tylko skończę hc) do
vixie-cron.

Przy powyższym tylko należy uważać na jedną sprawę. Otóż chodzi o to
żeby "/etc/rc.d/init.d/<service> restart" zabijało poprzedni(e) proces(y)  
i startowało nowy(e). Jeżeli ktoś miałby się chęć wziąć wg powyższego np.
za binda to tam restart w rc od niego jest IMHO skopany, bo to jest tylko
tak naprawdę odpowiednik "killall -HUP named".

Wogóle możnaby może rozszerzyć zestaw paramerów w skryptach rc
serwisów, żeby było to coś na podobieństwo:

* stop		- stop serwisu,
* start		- start serwisu,
* restart	- restart serwisu z zabiciem wszystkich procesów
		  (niezwłocznie) i uruchomieniem wszystkiego od początku,
* reloadcfg	- ponowne przeczytanie konfiguracji bez restartu samego
		  serwisu (to co zazwyczaj jest podpięte pod czytanie
		  SIGHUP),
* status	- status uruchomienia serwisu (np. w "firewall status"
		  podpiołem wyświetlanie wszystkich tablic FW).

Może ktoś ma jeszcze inne pomysły na sformalizowanie powyższego w dalszym
stopniu ? albo może na potrzeby Debiana wymyślono coś więcej lub jakoś
pod inną nazwaą niż to co wymyśliłem sobie na poczekani czyli owe
reloadcfg ?

Jeszcze jedna uwaga dotycząca samych skryptów rc do serwisów.
Jeżeli skrypt takowy możnaby jakoś sparametryzować, to ewentualne
parametry powinny wpaść do /etc/sysconfig/<service> gdzie w pliku tym
byłyby tylko lista zmiennych z warościami.
Tak mogłoby być z kilkoma rzeczami np. w squidzie. Ma on taką paskudną
cechę, że skrypt jaki jest RH bez modyfikacji nie pójdzie na pewnych
maszynkach.

Przykład:
Mam taki jeden serwerek w jednym z LO w Gdyni, który jest podpięty słąbym
modemem na dzierżawce. Robi on za masq FW i stoi na nim też named, który
co prawda z zewnątrz nie jest dostępny ale zanim wstanie poprawnie to już
startuje squid, który przy starcie musi mieć już komletny przynajmniej DNS
cache i jeżeli nie może się odwołać do pewnych nazw to kończy działalność,
a ludzkowie lokalnie nie mogli przez to korzystać z proxy. Nie pomaga tu w
tym wypadku dodanie do /etc/resolv.conf kolejnej linijki z nameservis
wskazującym na zewnętrzny DNS serwer gdyż linia jest dość cienka i straty
są na tyle duże, że squid nie doczekuje się tak czy inaczej odpowiedzi ani
z wstającego nameda lokalnie ani od tego zdalnego. Rozwiązaniem jest
odhashowanie w /etc/rc.d/init.d/squid linijki z:

#SQUID_OPTS="-D"

Które powoduje, że squid potrafi podnieść sie bez DNS. taka modyfikacja
jest o tyle paskudna, że narusza sumę kontrolą skrypty czyli od tego
momentu ktoś kto tam z jakiś powodów się dostanie w tym skrypcie
niepostrzeżenie może podłożyć własne rzeczy bez wzbudzania od razu
dalszych podejrzeń. Sam z tego typu wejść w kilku miejscach korzystałem
.. kiedyś ;) i opierajc się tylko o bazę rpm-a, którą admin kontroluje
automatycznie lub ręcznie można "podmodyfikować" trochę sysytem bez
wzbudzania od razu alarmu.

Rozwiązaniem byłoby wstawienie w /etc/rc.d/init.d/squid linijki
z włączeniem zmiennych w śrtodowisko skrypty z /etc/sysconfig/squid.
Tylko nie mogłoby być to proste:

. /etc/sysconfig/squid

z w sirodku SQUID_OPTS="-D" gdyż różnie dobrze w tym SQUID_OPTS mogłoby
się znaleźć "-D; /tmp/podłożenieżaby". Czyli w pliku tym musiałoby być
raczej:

DNS_CHECK_ON_STATR=no

które w samym skrypcie rc byłoby przetwarzane na opcję -D dla
uruchamianego squida.
Akurat w squidzie jest takich parę rzeczy, które dałoby się wrzućić do
pliku bedącego w /etc/sysconfig.

Tak na dobrą sprawę to ów includ zmiennych też nie mógłby być robiony
przez proste:

. /etc/sysconfig/<service>

bo między linikami ze zmiennymi można wstawić co się chce i to się
normalnie wykona. Czyli do do /etc/rc.d/init.d/functions trzeba by może
dodać funkcje do bezpiecznego czytania zmiennych z podanego pliku jako
parametry dal skryptu czyli żeby wyglądało to mniej więcej tak:

readvariables([/etc/sysconfig/]<service>)

lub jakos podobnego.

Sam nie podejmuję się zrobienia na razie powyżeszego także jak ktoś chce
to się może zmieżyć z napisaniem takiej funkcyjki lub może wręcz programu,
który w bezpieczny sposówb parsowałby podany plik i który pzrez eval
możnaby wywołać.

Nie dość, że całość będzie bezpieczniejsza to jeszcze sam
/etc/sysconfig/<service> zawierajacy wyczerpującą listę przełączników i
różnych zmienych byłby czytelniejszy lub wręcz samokomentujacy się
(poprzez odpowiednio logiczne/sugestywne dobieranie nazw zmiennych).

Także wydaje mi się, że pod kontem powyższego powinny być także przejrzane
wszystkie skrypty rc. Także i te które podnoszą poszczególne interfejsy
sieciowe czy robiące inne rzeczy, żeby w miarę możliwości zanim
wykorzystają zawartość jakiś plików, który nie są pod parasolem PM żeby
jakoś wrappowały/próbowały wykrywać podejrzane rzeczy przekazywane w
tychże plikach.

I jeszcze jedno. Samo już zgrupowanie takich plików, które potencjalnie
swoją zawartością mogą coś nabruździć w jednym katalogiu jak
/etc/sysconfig dałoby to że choćby najmnijej łatwiej by się je
kontrolowało z wykorzystaniem dodatkowych narzędzi jak CVS czy tripwire
czy nawet poprzez ręczne (oczne) kontrolowanie od czasu do czasu.

kloczek
PS. Prawie usypiający ..
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*