Forum Debian Users Gang

Po cóż rzeźbić w Cronie, jak jest do tego kilka gotowych narzędzi?

Np:
1. Monit:
http://www.debian-administration.org/article/269/Mo … rs_with_monit

2. Daemontools:
Stosowany pierwotnie do Qmaila, trzeba w nim rzeźbić skrypty run, jest z tym trochę gimnastyki i czasem kombinowania, ale za to każdy uruchomiony proces dostaje takiego maleńkiego nadzorcę, program supervise, który po prostu pilnuje, czy demon jest uruchomiony.

Ostatnio zatrudniłem go do Nginxa, który został zrzucony z uprawnień roota:

root      4838  0.0  0.0   1072   604 ?        S    sie07   0:19 supervise nginx
nginx     4914  0.0  0.0 175840  3864 ?        Ss   sie07   0:00 nginx: master process /usr/sbin/nginx -c /etc/nginx/nginx.conf
nginx     4915  0.0  0.1 175844  5460 ?        S    sie07   0:00 nginx: worker process

Niedawno też w ten sposób odpalałem clamd, bo mi się nie chciało kombinować ze zjebanym skryptem startowym demona clamd.
Skrypt do demontoolsa jest kosmicznie trudny, np:

cat /service/nginx/run
#!/bin/sh
exec 2>&1
exec /usr/sbin/nginx -c /etc/nginx/nginx.conf -g 'daemon off;'

Sznurek:
http://cr.yp.to/daemontools.html
http://thedjbway.b0llix.net/daemontools/overview.html

3.Jak ktoś lubi rękodzieło artystyczne, to i bashem (albo zsh|csh) też się da:
http://ubuntu.pl/forum/viewtopic.php?f=135&t=159704
tylko w pętelkach while lepiej dać sleep na kilka sekund, żeby w razie jakiejś poważniejszej awarii demona (kiedy uparcie nie zamierza wstawać), nie dosować własnej maszyny.

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2014-08-08 18:00:36)

yossarian napisał(-a):

Możesz zaprzyjaźnić się z systemd.
Tam powinno działać to bez dłubaniny.

Kod:

man systemd.service

Systemd - to jest gigantyczny SPOF dla każdego systemu, do serwera nadaje się, jak 25 kg młotek blacharski do nosa.

W dodatku jest rozwijany jak NM czy PA, w RHEL chodzi idealnie zawsze,
w innych dystrybucjach już nie koniecznie, o ile developerzy danej dystrybucji nie sprawdzają z benedyktyńską dokładnością każdej kolejnej wersji.

Dlatego lepiej się trzymać takich programów, które robią tylko jedną rzecz,
ale  najlepiej, jak to jest możliwe,  wtedy w systemie jest względny spokój i porządek.

Tu conieco o jakości umysłowej Developerów Systemd:
http://www.muktware.com/2014/04/linus-torvalds-happ … sievers/25151
Ale czego  się można  spodziewać po programie popełnionym przez ludzi w dużej części  związanych z rozwojem  PA.

Ostatnio edytowany przez Jacekalex (2014-08-08 18:01:19)

Oczywiście, że jest, oczywiście, że standardowo, i oczywiście, że moim zdaniem do wywalenia, z przyczyn wspomnianych dwa posty wyżej.

Dla porównania Daemontools:

 svstat /service/*/
/service/freeswitch/: up (pid 32533) 1782 seconds
/service/nginx/: up (pid 32532) 1782 seconds
/service/php/: up (pid 32531) 1782 seconds

Tylko kłopot polega na tym, że daemontools strasznie "dużo" pamięci zajmuje:

psmemng | egrep 'sv|super'
 12.0 KiB +   0.0 KiB =  12.0 KiB    supervise (3)
 88.0 KiB + 556.0 KiB = 644.0 KiB    svscan

Daemontools sprawdza się też w tak hardcorowych miejscach, jak np serwer, gdzie masz 16 pacjentów, każdy musi mieć osobny proces php z osobnym socketem unix, i do tego każdy proces php musi mieć indywidualnie, dla pacjenta, ustawione limity w cgroup, i osobny plik konfiguracyjny.

Wskazówka:
W SystemD i SysVinit też da się to zrobić, jak, to masz na lekturę do poduszki.:DDDD
Przyjemnej zabawy.
Możesz też przy okazji ujawnić tą słodką tajemnicę, po jaką cholerę na serwerze internetowym trzymać udev, logind i podobne bzdury, jak tam chodzi 5 usług na krzyż, każda na osobnym koncie pacjenta, w osobnej klatce ACL lub Chroot i z osobnymi limitami i priorytetami nice i ionice.

Moim zdaniem statyczny dev lub mdev, demony sieciowe, serwer SQL, syslog, ewentualnie snort, fail2ban czy inny IPS, i to wszystko.

PS:
Jak ożenić Fail2ban z SystemD i logami w postaci binarnej?

To musisz oświecić deweloperów RH, CentOS, Debiana i Ubuntu bo widocznie o serwerach nie mają zielonego pojęcia ;)

Ile initów masz do wyboru w Debianie?
Nikogo oświecać nie muszę, uważam popularność SystemD za objaw instynktu stadnego, czy raczej konformizmu normatywnego.
Zwłaszcza, że głównym powodem wdrożenia SystemD było Gnome3 i LoginD,
czyli rzeczy na prawdziwych serwerach "niezbędne". ;)

Pozdro
;-)

Ostatnio edytowany przez Jacekalex (2015-03-08 08:12:04)

Wiem, że na upstart na ubuntu ma to wbudowane w siebie, to pewnie podobne do systemd.

Ja jednak sobie obadam tego monita, bo z wierzchu co wyczytałem, to ma chyba wszystko czego potrzebuję.