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 <[email protected]> _______________________________________________ pld-devel-pl mailing list [email protected] http://lists.pld-linux.org/mailman/listinfo/pld-devel-pl
