Dowiedz się, jak zalogować się w systemie Linux

Jak rozumiem, jądro Linux loguje się do /proc/kmsgpliku (głównie wiadomości związane ze sprzętem) i /dev/loggniazda? Gdziekolwiek indziej? Czy inne aplikacje mogą również wysyłać wiadomości do /proc/kmsglub /dev/log? Last but not least, mam rację, że jest to demon syslog ( rsyslog , syslog-ng ), który sprawdza wiadomości z tych dwóch miejscach, a następnie rozprowadza tych różnych plików, takich jak /var/log/messageslub /var/log/kern.logczy nawet centralnego serwera syslog?

Uproszczony, wygląda mniej więcej tak:

Jądro rejestruje komunikaty (za pomocą printk()funkcji) w buforze pierścieniowym w przestrzeni jądra. Te komunikaty są udostępniane aplikacjom przestrzeni użytkownika na dwa sposoby: poprzez /proc/kmsgplik (pod warunkiem, że /procjest zamontowany) i poprzez połączenie sys_syslogsystemowe.

Istnieją dwie główne aplikacje, które czytają (i do pewnego stopnia mogą kontrolować) bufor pierścieniowy jądra: dmesg(1)i klogd(8). Ten pierwszy ma być uruchamiany na żądanie przez użytkowników, aby wydrukować zawartość bufora pierścieniowego. Ten ostatni jest demonem, który odczytuje wiadomości z /proc/kmsg(lub wywołuje sys_syslog, jeśli /procnie jest zamontowany) i wysyła je do syslogd(8)lub do konsoli. To obejmuje stronę jądra.

W przestrzeni użytkownika jest syslogd(8). Jest to demon, który nasłuchuje na wielu gniazdach domeny UNIX (głównie /dev/log, ale inne też można skonfigurować) i opcjonalnie na porcie UDP 514 dla komunikatów. Odbiera również wiadomości od klogd(8)( syslogd(8)nie przejmuje się /proc/kmsg). Następnie zapisuje te wiadomości w niektórych plikach /loglub nazwanych potokach lub wysyła je do niektórych hostów zdalnych (za pośrednictwem syslogprotokołu, na porcie UDP 514), zgodnie z konfiguracją w /etc/syslog.conf.

Aplikacje w przestrzeni użytkownika zwykle używają tej libcfunkcji syslog(3)do rejestrowania wiadomości. libcwysyła te wiadomości do gniazda domeny UNIX /dev/log(gdzie są one czytane syslogd(8)), ale jeśli aplikacja jest chroot(2)ustawiona na -ed, komunikaty mogą zostać zapisane na innych gniazdach, np /var/named/dev/log. do . Jest to oczywiście niezbędne dla aplikacji wysyłających te dzienniki i syslogd(8)uzgodnienia lokalizacji tych gniazd. Z tego powodu syslogd(8)można skonfigurować słuchanie dodatkowych gniazd poza standardem /dev/log.

Wreszcie syslogprotokół jest tylko protokołem datagramowym. Nic nie powstrzymuje aplikacji przed wysyłaniem datagramów syslog do dowolnego gniazda domeny UNIX (pod warunkiem, że jej poświadczenia pozwalają jej otworzyć gniazdo), całkowicie omijając syslog(3)funkcję libc. Jeśli datagramy są poprawnie sformatowane, syslogd(8)możesz użyć ich tak, jakby wiadomości zostały wysłane syslog(3).

Oczywiście powyższe dotyczy tylko „klasycznej” teorii pozyskiwania drewna. Inne demony (takie jak rsyslogi syslog-ng, jak wspomniałeś) mogą zastąpić zwykły syslogd(8)i robić różne fajne rzeczy, takie jak wysyłanie wiadomości do zdalnych hostów za pomocą szyfrowanych połączeń TCP, dostarczanie znaczników czasu wysokiej rozdzielczości i tak dalej. Jest też systemdpowolny fagocytozowanie części systemu UNIX w Linuksie. systemdma własne mechanizmy rejestrowania, ale tę historię musiałby opowiedzieć ktoś inny. :)

Różnice w świecie * BSD:

Na * BSD nie ma klogd(8)i /procalbo nie istnieje (na OpenBSD), albo jest w większości przestarzały (na FreeBSD i NetBSD). syslogd(8)odczytuje komunikaty jądra z urządzenia znakowego /dev/klogi dmesg(1)używa /dev/kmemdo dekodowania nazw jądra. Tylko OpenBSD ma /dev/log. FreeBSD używa dwóch gniazd domeny UNIX /var/run/logi var/rub/logprivzamiast tego, a NetBSD ma /var/run/log.

Druga odpowiedź wyjaśnia, jak mówi jej autor, „klasyczne logowanie” w systemie Linux. W dzisiejszych czasach nie działa to w wielu systemach.

Jądro

Mechanizmy jądra uległy zmianie.

Jądro generuje dane wyjściowe do bufora w pamięci. Oprogramowanie aplikacji może uzyskać do tego dostęp na dwa sposoby. Podsystem rejestrowania zwykle uzyskuje do niego dostęp jako pseudo-FIFO o nazwie /proc/kmsg. Tego źródła informacji dziennika nie można z powodzeniem udostępniać między czytnikami dziennika, ponieważ jest on czytany jeden raz. Jeśli współużytkuje je wiele procesów, każdy z nich otrzymuje tylko część strumienia danych dziennika jądra. Jest także przeznaczony tylko do odczytu.

Innym sposobem uzyskania dostępu jest nowsze /dev/kmsgurządzenie postaci. Jest to interfejs do odczytu i zapisu, który można udostępniać wielu procesom klienckim. Jeśli współużytkuje je wiele procesów, wszystkie odczytują ten sam pełny strumień danych, na które nie mają wpływu. Jeśli otworzą go w celu dostępu do zapisu, mogą również wstrzykiwać wiadomości do strumienia dziennika jądra, tak jakby zostały wygenerowane przez jądro.

/proc/kmsgi /dev/kmsgpodać dane dziennika w formie innej niż RFC-5424.

Aplikacje

Aplikacje uległy zmianie.

Funkcja biblioteki GNU C syslog()w głównych próbach połączenia się z AF_LOCALnazwanym gniazdem datagramu /dev/logi zapisania w nim wpisów dziennika. (Funkcja biblioteki BSD C syslog()używa obecnie /var/run/logjako nazwy gniazda i próbuje /var/run/logprivnajpierw.) Aplikacje mogą oczywiście mieć własny kod, aby to zrobić bezpośrednio. Funkcja biblioteki to po prostu kod (do otwierania, łączenia, zapisywania i zamykania gniazda), wykonujący w końcu we własnym kontekście procesu aplikacji.

Aplikacje mogą również wysyłać wiadomości RFC 5424 za pośrednictwem UDP na lokalny serwer RFC 5426, jeśli nasłuchuje na gnieździe AF_INET/ AF_INET6datagramie na komputerze.

Dzięki presji ze strony świata Daemontools w ciągu ostatnich dwóch dziesięcioleci wiele dæmons obsługuje działanie w trybie, w którym nie używają syslog()funkcji biblioteki GNU C ani gniazd UDP, a jedynie wypluwają swoje dane dziennika do standardowego błędu w zwykła moda na Uniksa.

zarządzanie logami za pomocą nosh i ogólnie rodziny daemontools

Dzięki rodzinie zestawów narzędzi daemontools rejestrowanie jest bardzo elastyczne. Ale ogólnie rzecz biorąc, w całej rodzinie chodzi o to, że każdy „główny” demon ma powiązany „rejestr”. „główne” dæmons działają podobnie jak procesy inne niż demon i zapisują swoje komunikaty w dzienniku do standardowego błędu (lub standardowego wyjścia), który podsystem zarządzania usługami łączy za pośrednictwem potoku (który utrzymuje otwarte, aby dane dziennika nie zostały utracone restart usługi) na standardowe wejście dæmon „logowania”.

Wszystkie dæmons „logujące” uruchamiają program, który gdzieś loguje . Ogólnie ten program jest coś multiloglub cyclogże czyta ze standardowego wejścia i zapisuje (nanosekundy o czasie,) plików w ściśle size-ograniczona, obracane automatycznie, wyłączny zapisu, katalog zalogować. Ogólnie rzecz biorąc, wszystkie te demony działają pod egidą indywidualnych dedykowanych nieuprzywilejowanych kont użytkowników.

Tak więc powstaje w dużej mierze rozproszony system rejestrowania, w którym dane dziennika każdej usługi są przetwarzane osobno.

Jedno można uruchomić coś podobnego klogdlub syslogdczy rsyslogdpod zarządzania usługami daemontools mieszkaniami. Jednak świat Daemontools zdał sobie sprawę wiele lat temu, że struktura zarządzania usługami z „logowaniem” dæmons nadaje się do robienia rzeczy w prostszy sposób. Nie ma potrzeby łączenia wszystkich strumieni dziennika w jeden gigantyczny mish-mash, analizowania danych dziennika, a następnie przekierowywania strumieni z powrotem do osobnych plików dziennika; a następnie (w niektórych przypadkach) przykręcić z boku niewiarygodny mechanizm zewnętrznego obracania kłody. Struktura rodziny daemontools jako część standardowego zarządzania logami już wykonuje rotację logów, zapis plików logów i separację strumienia.

Ponadto: model ładowania łańcuchowego upuszczania uprawnień z narzędziami wspólnymi dla wszystkich usług oznacza, że ​​programy rejestrujące nie potrzebują uprawnień administratora; a model UCSPI oznacza, że ​​muszą tylko dbać o różnice, takie jak transport strumieniowy w porównaniu z transportem datagramów.

Zestaw narzędzi nosh jest tego przykładem. Podczas gdy można uruchomić rsyslogdpod nim, po wyjęciu z pudełka, i po prostu zarządzać jądrem /run/logi danymi wejściowymi dziennika UDP w stary sposób; to również zapewnia bardziej „daemontools rodzime” sposoby zalogowaniu te rzeczy:

• klogdusługa, która czyta z /proc/kmsgi po prostu pisze, że strumień dziennika do standardowego błędu. Odbywa się to za pomocą prostego programu o nazwie klog-read. Powiązany dziennik dæmon przekazuje strumień dziennika ze standardowym wejściem do /var/log/sv/klogdkatalogu dziennika.
• local-syslog-readusługa, która czyta z datagramy /dev/log( /run/logna BSD) i po prostu pisze, że strumień dziennika do standardowego błędu. Odbywa się to przez program o nazwie syslog-read. Powiązany dziennik dæmon przekazuje strumień dziennika ze standardowym wejściem do /var/log/sv/local-syslog-readkatalogu dziennika.
• udp-syslog-readusługa nasłuchuje na porcie UDP Syslog, czyta co jest wysyłane do niego i po prostu pisze, że strumień dziennika do standardowego błędu. Ponownie program jest syslog-read. Powiązany dziennik dæmon przekazuje strumień dziennika ze standardowym wejściem do /var/log/sv/udp-syslog-readkatalogu dziennika.
• (w BSD) local-priv-syslog-readusługa, która odczytuje datagramy /run/logprivi po prostu zapisuje strumień dziennika do standardowego błędu. Ponownie program jest syslog-read. Powiązany dziennik dæmon przekazuje strumień dziennika ze standardowym wejściem do /var/log/sv/local-priv-syslog-readkatalogu dziennika.

Zestaw narzędzi zawiera również export-to-rsyslognarzędzie, które może monitorować jeden lub kilka katalogów dziennika (za pomocą systemu nieinwazyjnych kursorów dziennika ) i wysyłać nowe wpisy w formie RFC 5424 przez sieć do wyznaczonego serwera RFC 5426.

zarządzanie logami z systemd

Systemd ma jeden monolityczny program zarządzania dziennika systemd-journald. Działa to jako usługa zarządzana przez systemd.

• Czyta /dev/kmsgdane dziennika jądra.
• Odczytuje /dev/log(symboliczny link /run/systemd/journal/dev-log) do danych dziennika aplikacji z GNU C Library za syslog()funkcją.
• Nasłuchuje na AF_LOCALgnieździe w strumieniu /run/systemd/journal/stdoutdanych dziennika pochodzących z usług Systemd zarządzane.
• Nasłuchuje na AF_LOCALgnieździe datagramowym na /run/systemd/journal/socketdanych pochodzących z dziennika programów, które mówią protokół czasopism Systemd specyficzne (tj sd_journal_sendv()et al.).
• Miesza je wszystkie razem.
• Zapisuje do zestawu systemowych plików dzienników dla poszczególnych użytkowników w /run/log/journal/lub /var/log/journal/.
• Jeśli może się połączyć (jako klient) z AF_LOCALgniazdem datagramu /run/systemd/journal/syslog, zapisuje tam dane dziennika, jeśli skonfigurowano przekazywanie do syslog.
• Jeśli skonfigurowano, zapisuje dane dziennika do bufora jądra za pomocą /dev/kmsgmechanizmu zapisu .
• Jeśli skonfigurowano, zapisuje dane dziennika również na terminalach i urządzeniu konsoli.

Złe rzeczy zdarzają się w całym systemie, jeśli ten program ulegnie awarii lub usługa zostanie zatrzymana.

systemd sam organizuje standardowe wyjścia i błędy (niektórych) usług do przyłączenia do /run/systemd/journal/stdoutgniazda. Więc dæmons, którzy logują się do standardowego błędu w normalny sposób, wysyłają swoje dane wyjściowe do dziennika.

To całkowicie zastępuje klogd, syslogd, syslog-ng i rsyslogd.

Wymagane są teraz specyficzne dla systemu. W systemie systemowym nie stają się końcem serwera /dev/log. Zamiast tego przyjmują jedno z dwóch podejść:

• Stają się końcem serwera /run/systemd/journal/syslog, który (jeśli pamiętasz) systemd-journaldpróbuje połączyć się i zapisać dane dziennika. Kilka lat temu skonfigurowano by w tym imuxsockcelu metodę wprowadzania rsyslogd .
• Czytają bezpośrednio z dziennika systemowego, używając biblioteki systemowej, która rozumie format dziennika binarnego i która może monitorować pliki dziennika i katalog pod kątem dodawania nowych pozycji. Obecnie konfiguruje się w tym imjournalcelu metodę wprowadzania danych rsyslogd .