syslog-ng startowany po bindzie

Tomasz Pala gotar at polanet.pl
Tue Nov 22 21:42:30 CET 2011


On Tue, Nov 22, 2011 at 21:03:18 +0100, Adam Osuchowski wrote:

> No to przydało by się taką mapę zależności serwisów stworzyć.

...albo zupełnie zmienić podejście. Ręczne budowanie sieci zależności
prędzej czy później stworzy nam pętle, jest podatne na błędy i ogólnie
rzecz biorąc nie jest to rozwiązanie na miarę współczesnych systemów.

> Ja zgłaszam, że bind wymaga sysloga, Ty zgłosiłeś, że syslog z kolei wymaga
> zebry. Tutaj pewnie też zależy dużo od konfiguracji, bo taki syslog nie
> zawsze musi słuchać na interfejsach sieciowych, a tylko na uniksowym

Otóż to. Dlatego usługa tego typu powinna być startowana nie wtedy, gdy ktoś
ręcznie ustali (czy to priorytetem w SysV, czy zależnościami upstarta),
lecz wtedy, gdy faktycznie cokolwiek do niej się odwołuje. Jak mój
syslog będzie chciał gadać po sieci, to ją odpali, a jak bind będzie
chciał sobie coś lognąć, to jego odpali.

> sockecie. Masz RW do CVSa -- stwórz plik z taką mapą zależności, niech inni
> też dopiszą coś ze swojego podwórka, może da się coś z tym zrobić jak
> będzie większy pogląd na sprawę.

Wydaje mi się, że lepiej poświęcić ten czas na wdrożenie systemd.
Używają już tego Wiodące Marki, zalet ma dużo więcej, a jedyną wadą jest
z tego co wyczytałem ...postać autora (PA, avahi).

Mam akurat parę serwerów na warsztacie, to sobie z jednego popsuję.
Jest wstecznie kompatybilny z SysV (z upstartem chyba też, chociaż ponoć
jako dropin replacement lepiej nie mieć dużo natywnych), więc
teoretycznie tego typu problem rozwiązujesz po prostu tworząc dla binda
i sysloga wpisy systemd (i podsyłając na listę do spakietowania:>).

> Tylko, że ja nie mam jednej maszyny tylko kilkanaście, z czego jeszcze
> kilka z vserverami więc to wszystko razy kilka(-naście) wirtualek i z tego
> się już robi masakra jeżeli chodzi o opanowanie. Samych instancji binda mam

Ja skończyłem liczyć w okolicach 40. Później zrobiłem template systemu z
konfiguracją...

> dopisać itd. Powoli zaczyna z tego wychodzić własna dystrybucja, a na to
> nie mam ani siły ani czasu ani ochoty. Dlatego też, chciałem, na ile to
> możliwe, mieć jak najwięcej działających rzeczy w vanilla distro.

Zależnie od stopnia upierdliwości warto zainwestować czas w jakiegoś
gita do trzymania swoich rzeczy i trochę oskryptowania. W dystrybucji
np. do dziś nie mam jak zapisać ACL-ek czy capabilities (a niektóre są
oczywiste, choćby dostęp do passwd/shadow czy sieci zamiast pełnego SUID/SGID
na binarkach).

>> > A nie wystarczyłoby 'rndc reload', gdy już wszystko co trzeba wstanie?
>> 
>> Jak się wie, to wystarczy. Ja tego typu problemy rozwiązuję monitem,
>> który robi zwyczajny restart niedziałającej usługi i z głowy, ale to
>> jest łatanie czegoś, co kiedyś działało bez rzeźby.
> 
> ,,rndc reload'' nie wystarczy bo to jest restart logiczny w obrębie tego
> samego procesu, a jak on już jest chrootnięty to jest pozamiatane jeśli
> chodzi o /dev/log.

Ale interfejsy powinno łyknąć (skoro ma nawet konfigurowalny interwał
odświeżania).

Tak czy inaczej po głębszej analizie tematu osobiście skłaniam się ku
systemd i na dobrą sprawę jest mi już teraz obojętne, co w SysV zostanie
zmienione, bo to podejście jest broken by design. To jest nienaprawialne.

Najwyraźniej nie tylko my mieliśmy tego rodzaju problemy, skoro ktoś się
zajął ich kompleksowym rozwiązaniem, nie ma co wymyślać na nowo koła i
tkwić w średniowieczu, więc z mojej strony EOT na temat numerków.

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


More information about the pld-devel-pl mailing list