Nie jesteś zalogowany.
Jeśli nie posiadasz konta, zarejestruj je już teraz! Pozwoli Ci ono w pełni korzystać z naszego serwisu. Spamerom dziękujemy!
Prosimy o pomoc dla małej Julki — przekaż 1% podatku na Fundacji Dzieciom zdazyć z Pomocą.
Więcej informacji na dug.net.pl/pomagamy/.
Strony: 1
Wszystkie logi standardowo trafiają do journal'a systemd. Niektóre z tych komunikatów przechodzą przez rsyslog/syslog i mogą na tym etapie zostać odfiltrowane i przekierowane do innych plików/urządzeń. O ile samo filtrowanie i przekierowanie działa bez zarzutu, to jednak logi z journal'a nie znikają i w zasadzie pojawiają się w dwóch miejscach.
Najbardziej to drażnią mnie logi audytu (te mające taga audit), zwykle notowane przy stosowaniu polityki AppArmor. Same logi może i są bardzo użyteczne ale nie zmienia to faktu, że strasznie one syfią w logu systemowym i dlatego chciałbym je dać na osobną konsolę. Generalnie to w konfiguracji rsyslog'a mam takie zwrotki:
if $msg contains 'audit:' and $msg contains 'apparmor=' then -/dev/log-apparmor if $msg contains 'audit:' and $msg contains 'apparmor=' then -/var/log/apparmor.log & stop kern.* -/var/log/kern.log kern.* -/dev/log-kernel & stop
Czyli logi od AppArmor'a lecą sobie osobno, a kernela osobno. Po ich dopasowaniu niby ma się zakończyć ich przetwarzanie i tak się dzieje. Niemniej jednak, kopia logu i tak trafia do journal'a systemd za sprawą jednego z tych transportów:
# journalctl --field _TRANSPORT audit syslog journal stdout kernel driver
Wcześniej miałem zdublowane logi audtu, które wyglądały mniej więcej tak (sformatowane dla czytelności):
Apr 09 14:08:15 morfikownia audit[1397]: AVC apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/sensors" pid=1397 comm="apparmor_parser" Apr 09 14:08:15 morfikownia kernel: audit: type=1400 audit(1523275695.613:76): apparmor="STATUS" operation="profile_load" profile="unconfined" name="/usr/bin/sensors" pid=1397 comm="apparmor_parser"
Czyli raz były one notowane przez audit a drugi raz przez kernel, a wiadomość jest dokładnie taka sama w obu przypadkach. Na szczęście to dublowanie można wyłączyć przez
# systemctl mask systemd-journald-audit.socket
I ten komunikat z samym audit zniknie z logu ale dalej w logu figuruje kernel: audit: i pytanie jak go wywalić z journal'a. xD
Ktoś wie może jak wyłączyć te określone transporty journal'a? Bo to by w zasadzie rozwiązało cały problem.
Offline
W dmesg nie masz czasem logów AA?
Ja sobie skrobnąłem takiego skrypta:
root ~> cat `which aaupdate`
#!/bin/bash dmesg | grep apparmor | grep -v 93 >/var/log/grsec/apparmor.log ; aa-logprof -f /var/log/grsec/apparmor.log
I nawet robi, co ma robić.
Jest tylko problem z rtmin+-93 w logach AA, bo aa-logprof na razie wywala się na takim logu.
Stąd to grep -v 93.
Ostatnio edytowany przez Jacekalex (2018-04-09 20:12:57)
Offline
Ja sobie ogarnąłem te logi już (mam osobny plik i urządzenie FIFO na to), tylko problem jest taki, że ten spam od AppArmor'a leci do także do journal'a i chcę temu jakoś zapobiec.
Offline
Ja wszystkie systemowe logi wywaliłem na sockety FIFO, żeby rsyslog dyzia nie katował.
Inna sprawa, że mam uczulenie na Systemd.
Może Auditd coś miesza z logami AA, masz to zainstalowane?
Offline
Nie mam auditd. Z nim tych logów audytu to by było dopiero od groma. xD Ten systemd po prostu zbiera logi audytu bezpośrednio z podsystemu audit i kernel i dlatego były dwie kopie logów apparmor'a: jedna z samym audit, druga z kernel: audit: . Ten pierwszy transport udało się wyłączyć ale nadal w logu mam kernel: audit: , gdy mi coś AppArmor zablokuje i chciałbym się tego pozbyć, czyli albo wywalić wszystkie logi kernela z journala, albo jedynie te kernel: audit: i dać to do osobnego pliku/FIFO.
W linijce kernela można wrzucić audit=0 ale to wyłącza całkowicie logi audytu i AppArmor już nic nie zwraca.
Tu też ludzie narzekają na to:
https://github.com/systemd/systemd/issues/959
Ostatnio edytowany przez morfik (2018-04-10 11:35:49)
Offline
do dmesg trafiaja logi z apparmora
journalctl -k |grep audit
można przecież zastosować składnie która podaje logi z ostatniego czasu lub ileś wpisów wstecz...
lub ...
journalctl -k -f |grep audit
Offline
Zajrzyj w źródełka apparmor-notify, może tam coś nowego wymyślili w tej sprawie.
https://packages.debian.org/buster/apparmor-notify
EDIT:
On czyta z /var/log/audit/audit.log
Ostatnio edytowany przez Jacekalex (2018-05-04 18:47:17)
Offline
Raczej ci od systemd powinni skonfigurować transporty logowania, by była możliwość ich włączenia lub wyłączenia, bo póki co to domyślnie wszystkie są włączone. Ten transport audit można wyłączyć ale w dalszym ciągu to kernel loguje te wiadomości z audit. Niby nie mam już zdublowanych logów ale transportu kernel'a w journal'u chyba się póki co nie da wyłączyć. xD
Offline
Ci od Systemd mają ważniejsze sprawy na głowie, RH ma dla nich dużo poważniesze zadania.
Offline
Mam nadzieje że do Gentoo ten syf jako przymus nigdy nie wejdzie, jak dla mnie robi za dużo rzeczy na raz, a dev i tak dodają do niego nowe funkcje, bez głębszego zastanowienia, czy chociażby przetestowania, czy owe funkcje poprawnie działają...
Ostatnio edytowany przez makalega (2018-06-02 21:34:34)
Offline
Strony: 1