logi

Raspberry Pi, LibreELEC, Kodi i zdalne logi via rsyslog

Parę lat temu, gdy pojawił się u mnie w domu bezprzewodowy router WiFi, postanowiłem wgrać na niego linux'a w postaci OpenWRT. Pierwszym kluczowym elementem konfiguracyjnym tego urządzenia było przesłanie jego logów systemowych przez sieć do mojego laptopa, tak by wszystkie zarejestrowane komunikaty zostały wyświetlone na konsoli mojego komputera z zainstalowanym Debianem. W ten sposób nie musiałem się co chwila logować na router po SSH (czy też przez panel webowy), by sprawdzić czy aby na pewno z tym urządzeniem jest wszystko w porządku. Teraz, po nabyciu Raspberry Pi 4B i wgraniu na niego LibreELEC z preinstalowanym Kodi, mam dokładnie to samo zadanie do zrealizowania. Trzeba zatem znaleźć sposób na przesłanie wszystkich logów generowanych przez system LibreELEC do demona rsyslogd , który jest uruchomiony na zdalnej maszynie.

Jak ustalić nazwę procesu korzystającego z sieci

Konfigurując filtr pakietów iptables/nftables na Debianie zwykle nie przykładamy większej wagi do procesów, które chcą nawiązać połączenia wychodzące z naszego linux'owego hosta. Mamy przecież "skonfigurowany" firewall w łańcuchach INPUT i FORWARD i wszelkie zagrożenia z sieci nie powinny nas dotyczyć. Problem w tym, że jeśli jakiś złowrogi proces zostanie uruchomiony w naszym systemie, to jest on w stanie komunikować się ze światem zewnętrznym praktycznie bez żadnych ograniczeń za sprawą braku jakichkolwiek reguł w łańcuchu OUTPUT . Można oczywiście temu zaradzić budując zaporę sieciową na bazie cgroups , gdzie każda aplikacja będzie miała oznaczone pakiety, przez co będzie można je rozróżnić i zablokować albo przepuścić przez filter. W tym wpisie jednak nie będziemy się zajmować konstrukcją tego typu FW, tylko spróbujemy sobie odpowiedzieć na pytanie jak namierzyć proces, który komunikuje się z siecią (lub też próbuje), posiadając jedynie log iptables/nftables .

Jak zalogować błędy podczas zamykania systemu Debian Linux

By wyłączyć komputer, jego system operacyjny musi pierw zatrzymać (lub też ubić siłowo) wszystkie działające usługi za wyjątkiem tego mającego PID z numerkiem 1. Zwykle proces zamykania się systemu Debian Linux nie trwa więcej niż parę sekund ale czasami pojawiają się dziwne problemy, które mogą to zadanie utrudnić lub też całkowicie uniemożliwić. Nawet jeśli system będzie się w stanie zresetować, to zanim to nastąpi, to na konsoli mogą pojawić się komunikaty mogące pomóc nam w zdiagnozowaniu dolegliwości, która doskwiera naszej maszynie. Problem w tym, że część tych wiadomości nie zostanie nigdy zalogowana do pliku, gdzie moglibyśmy ich poszukać. Dzieje się tak dlatego, że w pewnym określonym momencie zamykania się systemu trzeba wyłączyć usługę logowania, co zwykle widać w logu jako systemd-journald[]: Journal stopped . Gdy dziennik zostanie zatrzymany, żadna wiadomość, która od tego momentu pojawi się na ekranie, nie zostanie już zalogowana do pliku. Jeśli teraz pojawią nam się ostrzeżenia lub błędy, a po chwili komputer się zresetuje, to możemy mieć nie lada problem z ustaleniem przyczyny mimo, że system nam ją zgłasza. Przydałoby się zapisać te komunikaty, tylko jak to zrobić, skoro usługa logowania jest już nieaktywna?

Apache2: Jak odchudzić nieco plik access.log

Mając serwer www oparty o oprogramowanie Apache2, w pewnym momencie zacznie nas nieco przytłaczać kwestia logowania do pliku /var/log/apache2/access.log wszystkiego co się nawinie. Jak nazwa pliku sugeruje, znajdują się w nim komunikaty, które serwer generuje ilekroć tylko ktoś odwiedzi nasz serwis. Każdy zasób przesłany do klienta, np. style CSS czy obrazki, zostanie zalogowany w powyższym pliku. Generalnie rzecz ujmując, nie musimy logować wszystkich tych informacji, chyba, że ich faktycznie potrzebujemy. Trzeba jednak wziąć pod uwagę fakt, że w przypadku obciążonych serwerów, ilość operacji I/O dysku może być znaczna. Dodatkowo, miejsce na dysku za sprawą takiego obszernego logu może bardzo szybko się wyczerpać. W tym artykule postaramy się nieco ograniczyć apetyt serwera Apache2 na logi i oduczymy go logować większość zbędnych komunikatów za sprawą dyrektywy SetEnvIf/SetEnvIFNoCase .

"Internal dummy connection" w logu Apache2 (mpm_prefork)

Od czasu do czasu przeglądam sobie logi Apache2 w poszukiwaniu pewnych nieprawidłowości. Na dobrą sprawę, to nie ma tutaj zbytnio dużo roboty, przynajmniej póki co. Niemniej jednak, w pliku /var/log/apache2/access.log co jakiś czas pojawiają się komunikaty zawierające "internal dummy connection". Za co one odpowiadają i czy można je w zupełności zignorować bez stwarzania zagrożenia bezpieczeństwa dla serwera www?

Szyfrowanie logów w OpenWRT (syslog-ng)

We wpisie dotyczącym logread została podniesiona kwestia przesłania logów przez sieć. OpenWRT jest w stanie tego typu zadanie realizować po określeniu kilku dodatkowych opcji w pliku /etc/config/system . Trzeba jednak zdawać sobie sprawę, że tak przesyłane komunikaty nie będą w żaden sposób zabezpieczone. W sieci domowej raczej nie musimy sobie zawracać głowy tym mankamentem. Niemniej jednak, gdy w grę wchodzi przesyłanie logów do zdalnego serwera zlokalizowanego gdzieś w internecie, to taką komunikację należy zabezpieczyć przed podsłuchem. Niestety OpenWRT standardowo nie wspiera takich udziwnień ale dysponuje on pakietami, które mogą nam zapewnić taką funkcjonalność. Szyfrowanie logów możemy w łatwy sposób wdrożyć za pomocą pakietu syslog-ng3 . W nim znajduje się demon syslog-ng , który jest kompatybilny w pełni z innymi linux'owymi demonami logowania. Nie powinno zatem być problemów ze skonfigurowaniem tego całego mechanizmu.

W OpenWRT w wersji Chaos Calmer nie ma pakietu syslog-ng3 . W efekcie szyfrowanie logów routera nie jest obecnie możliwe. Ten wpis dotyczy jedynie wydania Barrier Breaker i zostanie zaktualizowany jak tylko wspomniany pakiet trafi do repozytorium.

Logread, czyli system logowania w OpenWRT

Każdy szanujący się system, nawet ten najmniejszy na bazie OpenWRT, musi posiadać mechanizm logowania komunikatów. Logi routera to bardzo ważna rzecz. Jeśli coś dolega naszemu małemu przyjacielowi, to jest niemal pewne, że właśnie wśród tych wiadomości znajdziemy przyczynę problemów. Każda usługa systemowa działająca na routerze przesyła logi, które są zbierane przez demon logowania. W Chaos Calmer odpowiadają za to logd oraz logread . Standardowa konfiguracja logów w OpenWRT nie jest raczej skomplikowana ale niewiele osób wie, że logi routera można zapisywać w pliku lub przesłać je przez sieć do innego hosta. W tym wpisie postaramy się właśnie zrealizować te dwa zadania.

Jak zdiagnozować kernel OOPS

Kernel linux'a, jak każdy inny program, podczas swojego działania może napotkać nieprzewidzianą przez programistów sytuację. W przypadku zwykłych aplikacji, pewne błędy krytyczne mogą doprowadzić do "naruszenia ochrony pamięci", co szerzej jest znane jako segfault. W przypadku wystąpienia tego błędu, proces zwykle jest unicestwiany. Co jednak w przypadku kernela? Odpowiedź jest prosta: kernel panic, czyli panika kernela, która pozostawia system w stanie braku jakichkolwiek oznak życia. Są jednak pewne błędy, z którymi kernel jest w stanie sobie poradzić i odzyskać sprawność w mniejszym lub większym stopniu. Te błędy są nazywane kernel OOPS. W tym wpisie postaramy się przeanalizować przykładowy OOPS i zobaczymy czy uda nam się ustalić przyczynę zaistniałego problemu.

Osadzanie urxvt na pulpicie przy pomocy Openbox'a

Wszyscy wiemy, że ogromna rzesza ludzi nie patrzy w logi systemowe. Nawet jeśli części z nas zdarza się to raz na jakiś czas, to zwykle nie wtedy, gdy coś złego się dzieje z naszym systemem. W przypadku jakichkolwiek problemów, mamy spore prawdopodobieństwo, że szereg zdarzeń może zostać zalogowanych w dzienniku systemowym. Dlaczego zatem nie osadzić jakiegoś terminala na pulpicie, w którym będą zbierane logi w czasie rzeczywistym? W takim przypadku co kilka (czy kilkanaście) minut będziemy w stanie podejrzeć wszystkie komunikaty jakie zostały zalogowane przez system. W tym wpisie postaramy się osadzić na pulpicie terminal urxvt i posłużymy się w tym celu menadżerem okien openbox .

Aktualizacja systemu i logowanie komunikatów

Aktualizacja systemu to chyba jedna z bardziej podstawowych czynności, które przeprowadzamy niemalże codziennie. Tak się złożyło, że chwilę po zakończeniu tego procesu musiałem wyłączyć w pośpiechu komputer. Nie zdążyłem przy tym przeczytać uważnie informacji, które zwrócił mi terminal. Oczywiście mógłbym zahibernować maszynę i wrócić do logu instalacji w wolnej chwili ale nie zawsze hibernacja jest możliwa. Poza tym, na myśl przychodzą mi osoby, które często zakładają wątki na forach o tym, że aktualizacja uwaliła ich system. Zawsze w takiej sytuacji prosi się danego człowieka o podanie logu z aktualizacji systemu albo przynajmniej próbuje się wyciągnąć od takiego delikwenta informację na temat tego co było aktualizowane. W większości przypadków, taki człowiek nie ma o tym kompletnie pojęcia, a jak już, to podaje bardzo nieprecyzyjne dane. Ten post ma na celu ułatwienie znalezienia informacji o tym co było przedmiotem aktualizacji, tak by mieć nieco jaśniejszy obraz tego co mogło nawalić.