108.2 Урок 1

Сертифікат:

LPIC-1

Версія:

5.0

Розділ:

108 Основні системні служби

Тема:

108.2 Системне журналювання

Урок:

1 з 2

Вступ

Журнали можуть бути найкращим другом системного адміністратора. Журнали — це файли (зазвичай текстові), де в хронологічному порядку реєструються всі системні та мережеві події з моменту завантаження системи. Таким чином, спектр інформації, яку можна знайти в журналах, включає практично всі аспекти системи: невдалі спроби автентифікації, помилки програм і служб, хости, заблоковані міжмережним екраном тощо. Як ви можете собі уявити, журнали роблять життя системних адміністраторів значно легшим, коли йдеться про усунення несправностей, перевірку ресурсів, виявлення аномальної поведінки програм тощо.

У цьому уроці ми обговоримо одну з найпоширеніших засобів журналювання, які зараз є в дистрибутивах GNU/Linux: rsyslog. Ми вивчимо різні типи журналів, які існують, де вони зберігаються, яку інформацію містять і як цю інформацію можна отримати та відфільтрувати. Ми також обговоримо, як журнали можна зберігати на централізованих серверах у IP-мережах, ротацію журналів і кільцевий буфер ядра.

Системне журналювання

У той момент, коли ядро та різні процеси у вашій системі починають працювати та спілкуватися один з одним, багато інформації генерується у формі повідомлень, які, здебільшого, надсилаються до журналів.

Без журналювання пошук події, яка сталася на сервері, викликав би головний біль у системних адміністраторів, тому важливо мати стандартизований і централізований спосіб відстеження будь-яких системних подій. Журнали є визначальними та показовими, коли йдеться про усунення несправностей і безпеку, а також є надійними джерелами даних для розуміння системної статистики та прогнозування тенденцій.

Залишаючи осторонь systemd-journald (який ми обговоримо в наступному уроці), журналювання традиційно оброблялося трьома основними спеціальними службами: syslog, syslog-ng (syslog нового покоління) і rsyslog (“ракетно-швидкісна система обробки журналів”). rsyslog приніс важливі покращення (такі як підтримка RELP) і став найпопулярнішим вибором на сьогодні. Кожна з цих служб збирає повідомлення від інших служб і програм і зберігає їх у файлах журналу, зазвичай у папці /var/log. Однак деякі служби піклуються про власні журнали (наприклад, веб-сервер Apache HTTPD або система друку CUPS). Подібним чином ядро Linux використовує кільцевий буфер у пам’яті для зберігання повідомлень журналу.

Note	`RELP` означає Reliable Event Logging Protocol (Протокол надійної реєстрації подій) і розширює функціональні можливості протоколу системного журналу для забезпечення надійної доставки повідомлень.

Оскільки rsyslog став де факто стандартним засобом журналювання в усіх основних дистрибутивах, ми зосередимося на ньому в цьому уроці. rsyslog використовує модель клієнт-сервер. Клієнт і сервер можуть знаходитися на одному хості або на різних машинах. Повідомлення надсилаються та отримуються в певному форматі та можуть зберігатися на централізованих серверах rsyslog у IP-мережах. Демон rsyslog — rsyslogd — працює разом із klogd (який керує повідомленнями ядра). У наступних розділах буде розглянуто rsyslog та його інфраструктуру журналювання.

Note	Демон — це служба, яка працює у фоновому режимі. Зверніть увагу на останню літеру `d` в назвах демонов: `klogd` або `rsyslogd`.

Типи журналів

Оскільки журнали є змінними даними, вони зазвичай знаходяться в /var/log. Грубо кажучи, їх можна класифікувати на системні журнали та службові або програмні журнали.

Давайте розглянемо деякі системні журнали та інформацію, яку вони зберігають:

/var/log/auth.log: Діяльність, пов’язана з процесами автентифікації: зареєстровані користувачі, інформація sudo, завдання cron, невдалі спроби входу тощо.
/var/log/syslog: Централізований файл для практично всіх журналів, отриманих rsyslogd. Оскільки він містить дуже багато інформації, журнали розподіляються між іншими файлами відповідно до конфігурації, наданої в /etc/rsyslog.conf.
/var/log/debug: Налагоджувальна інформація з програм.
/var/log/kern.log: Повідомлення ядра.
/var/log/messages: Інформативні повідомлення, які стосуються не ядра, а інших служб. Це також місце призначення журналу віддаленого клієнта за замовчуванням у реалізації централізованого сервера журналу.
/var/log/daemon.log: Інформація, пов’язана з демонами або службами, що працюють у фоновому режимі.
/var/log/mail.log: Інформація, пов’язана з сервером електронної пошти, наприклад, postfix.
/var/log/Xorg.0.log: Інформація про графічну карту.
/var/run/utmp і /var/log/wtmp: Успішні входи.
/var/log/btmp: Невдалі спроби входу, наприклад, атака грубої сили через ssh.
/var/log/faillog: Невдалі спроби автентифікації.
/var/log/lastlog: Дата й час останніх входів користувачів.

Тепер розглянемо кілька прикладів журналів служб:

/var/log/cups/: Каталог для журналів Загальної системи друку Unix. Він зазвичай включає такі файли журналу за замовчуванням: error_log, page_log і access_log.
/var/log/apache2/ або /var/log/httpd: Каталог для журналів веб-сервера Apache. Він зазвичай містить такі файли журналу за замовчуванням: access.log, error_log і other_vhosts_access.log.
/var/log/mysql: Каталог для журналів системи керування реляційними базами даних MySQL. Зазвичай він включає такі файли журналу за замовчуванням: error_log, mysql.log і mysql-slow.log.
/var/log/samba/: Каталог для журналів протоколу Session Message Block (SMB). Він зазвичай включає такі файли журналу за замовчуванням: log., log.nmbd і log.smbd.

Note	Точна назва та вміст файлів журналу можуть відрізнятися в різних дистрибутивах Linux. Існують також журнали, присвячені певним дистрибутивам, наприклад `/var/log/dpkg.log` (містить інформацію про пакети `dpkg`) у Debian GNU/Linux та його похідних.

Читання журналів

Щоб читати файли журналу, спочатку переконайтеся, що ви є користувачем root або маєте дозвіл на читання файлу. Ви можете використовувати різні утиліти, такі як:

less або more

Командт, які дозволяють переглядати та прокручувати по одній сторінці за раз:

root@debian:~# less /var/log/auth.log
Sep 12 18:47:56 debian sshd[441]: Received SIGHUP; restarting.
Sep 12 18:47:56 debian sshd[441]: Server listening on 0.0.0.0 port 22.
Sep 12 18:47:56 debian sshd[441]: Server listening on :: port 22.
Sep 12 18:47:56 debian sshd[441]: Received SIGHUP; restarting.
Sep 12 18:47:56 debian sshd[441]: Server listening on 0.0.0.0 port 22.
Sep 12 18:47:56 debian sshd[441]: Server listening on :: port 22.
Sep 12 18:49:46 debian sshd[905]: Accepted password for carol from 192.168.1.65 port 44296 ssh2
Sep 12 18:49:46 debian sshd[905]: pam_unix(sshd:session): session opened for user carol by (uid=0)
Sep 12 18:49:46 debian systemd-logind[331]: New session 2 of user carol.
Sep 12 18:49:46 debian systemd: pam_unix(systemd-user:session): session opened for user carol by (uid=0)
(...)

zless або zmore

Те саме, що less і more, але використовується для журналів, які стискаються за допомогою gzip (загальна функція logrotate):

root@debian:~# zless /var/log/auth.log.3.gz
Aug 19 20:05:57 debian sudo:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/sbin/shutdown -h now
Aug 19 20:05:57 debian sudo: pam_unix(sudo:session): session opened for user root by carol(uid=0)
Aug 19 20:05:57 debian lightdm: pam_unix(lightdm-greeter:session): session closed for user lightdm
Aug 19 23:50:49 debian systemd-logind[333]: Watching system buttons on /dev/input/event2 (Power Button)
Aug 19 23:50:49 debian systemd-logind[333]: Watching system buttons on /dev/input/event3 (Sleep Button)
Aug 19 23:50:49 debian systemd-logind[333]: Watching system buttons on /dev/input/event4 (Video Bus)
Aug 19 23:50:49 debian systemd-logind[333]: New seat seat0.
Aug 19 23:50:49 debian sshd[409]: Server listening on 0.0.0.0 port 22.
(...)

tail

Перегляд останніх рядків у файлі (за замовчуванням 10 рядків). Потужність tail — значною мірою — полягає в перемикачі -f, який динамічно показуватиме нові рядки в міру їх додавання:

root@suse-server:~# tail -f /var/log/messages
2019-09-14T13:57:28.962780+02:00 suse-server sudo: pam_unix(sudo:session): session closed for user root
2019-09-14T13:57:38.038298+02:00 suse-server sudo:    carol : TTY=pts/0 ; PWD=/home/carol ; USER=root ; COMMAND=/usr/bin/tail -f /var/log/messages
2019-09-14T13:57:38.039927+02:00 suse-server sudo: pam_unix(sudo:session): session opened for user root by carol(uid=0)
2019-09-14T14:07:22+02:00 debian carol: appending new message from client to remote server...

head

Переглянути перші рядки у файлі (за замовчуванням 10 рядків):

root@suse-server:~# head -5 /var/log/mail
2019-06-29T11:47:59.219806+02:00 suse-server postfix/postfix-script[1732]: the Postfix mail system is not running
2019-06-29T11:48:01.355361+02:00 suse-server postfix/postfix-script[1925]: starting the Postfix mail system
2019-06-29T11:48:01.391128+02:00 suse-server postfix/master[1930]: daemon started -- version 3.3.1, configuration /etc/postfix
2019-06-29T11:55:39.247462+02:00 suse-server postfix/postfix-script[3364]: stopping the Postfix mail system
2019-06-29T11:55:39.249375+02:00 suse-server postfix/master[1930]: terminating on signal 15

grep

Утиліта фільтрації, яка дозволяє шукати певні рядки:

root@debian:~# grep "dhclient" /var/log/syslog
Sep 13 11:58:48 debian dhclient[448]: DHCPREQUEST of 192.168.1.4 on enp0s3 to 192.168.1.1 port 67
Sep 13 11:58:49 debian dhclient[448]: DHCPACK of 192.168.1.4 from 192.168.1.1
Sep 13 11:58:49 debian dhclient[448]: bound to 192.168.1.4 -- renewal in 1368 seconds.
(...)

Як ви могли помітити, вихідні дані друкуються в такому форматі:

Мітка часу.
Ім’я хосту, з якого надійшло повідомлення.
Назва програми/служби, яка створила повідомлення.
PID програми, яка створила повідомлення.
Опис дії, що відбулася.

Є кілька прикладів, коли журнали є не текстовими, а двійковими файлами, і, отже, ви повинні використовувати спеціальні команди для їх аналізу:

/var/log/wtmp

Використовуйте who (або w):

root@debian:~# who
root    pts/0        2020-09-14 13:05 (192.168.1.75)
root    pts/1        2020-09-14 13:43 (192.168.1.75)

/var/log/btmp

Використовуйте utmpdump або last -f:

root@debian:~# utmpdump /var/log/btmp
Utmp dump of /var/log/btmp
[6] [01287] [    ] [dave     ] [ssh:notty   ] [192.168.1.75        ] [192.168.1.75   ] [2019-09-07T19:33:32,000000+0000]

/var/log/faillog

Використовуйте faillog:

root@debian:~# faillog -a | less
Login       Failures Maximum Latest                   On

root            0        0   01/01/70 01:00:00 +0100
daemon          0        0   01/01/70 01:00:00 +0100
bin             0        0   01/01/70 01:00:00 +0100
sys             0        0   01/01/70 01:00:00 +0100
sync            0        0   01/01/70 01:00:00 +0100
games           0        0   01/01/70 01:00:00 +0100
man             0        0   01/01/70 01:00:00 +0100
lp              0        0   01/01/70 01:00:00 +0100
mail            0        0   01/01/70 01:00:00 +0100
(...)

/var/log/lastlog

Використовуйте lastlog:

root@debian:~# lastlog | less
Username         Port     From             Latest
root                                       Never logged in
daemon                                     Never logged in
bin                                        Never logged in
sys                                        Never logged in
(...)
sync                                       Never logged in
avahi                                      Never logged in
colord                                     Never logged in
saned                                      Never logged in
hplip                                      Never logged in
carol            pts/1    192.168.1.75     Sat Sep 14 13:43:06 +0200 2019
dave             pts/3    192.168.1.75     Mon Sep  2 14:22:08 +0200 2019

Note	Існують також графічні засоби для читання файлів журналів, наприклад: `gnome-logs` і `KSystemLog`.

Як повідомлення перетворюються на журнали

Наступний процес ілюструє, як повідомлення записується до файлу журналу:

Програми, служби та ядро записують повідомлення в спеціальні файли (сокети та буфери пам’яті), наприклад, /dev/log або /dev/kmsg.
rsyslogd отримує інформацію з сокетів або буферів пам’яті.
Залежно від правил, знайдених у /etc/rsyslog.conf та/або файлах /etc/ryslog.d/, rsyslogd переміщує інформацію до відповідного файлу журналу (зазвичай знаходиться в /var/log `).

Note	Сокет — це спеціальний файл, який використовується для передачі інформації між різними процесами. Щоб отримати список усіх сокетів у вашій системі, ви можете використати команду `systemctl list-sockets --all`.

Об’єкти, пріоритети та дії

Конфігураційний файл rsyslog — це /etc/rsylog.conf (у деяких дистрибутивах ви також можете знайти файли конфігурації в /etc/rsyslog.d/). Зазвичай він розділений на три розділи: MODULES, GLOBAL DIRECTIVES і RULES. Давайте подивимося на них, вивчивши файл rsyslog.conf на нашому хості Debian GNU/Linux 10 (buster) — для цього можна використати sudo less /etc/rsyslog.conf.

MODULES містить підтримку модулів для журналювання, можливості повідомлень і отримання журналу UDP/TCP:

#################
#### MODULES ####
#################

module(load="imuxsock") # provides support for local system logging
module(load="imklog")   # provides kernel logging support
#module(load="immark")  # provides --MARK-- message capability

# provides UDP syslog reception
#module(load="imudp")
#input(type="imudp" port="514")

# provides TCP syslog reception
#module(load="imtcp")
#input(type="imtcp" port="514")

GLOBAL DIRECTIVES дозволяють нам налаштувати низку речей, таких як журнали та дозволи каталогу журналів:

###########################
#### GLOBAL DIRECTIVES ####
###########################

#
# Use traditional timestamp format.
# To enable high precision timestamps, comment out the following line.
#
$ActionFileDefaultTemplate RSYSLOG_TraditionalFileFormat

#
# Set the default permissions for all log files.
#
$FileOwner root
$FileGroup adm
$FileCreateMode 0640
$DirCreateMode 0755
$Umask 0022

#
# Where to place spool and state files
#
$WorkDirectory /var/spool/rsyslog

#
# Include all config files in /etc/rsyslog.d/
#
$IncludeConfig /etc/rsyslog.d/*.conf

В RULES визначені facilities, priorities і actions. Параметри в цьому розділі вказують демону журналювання фільтрувати повідомлення відповідно до певних правил і реєструвати їх або надсилати, куди потрібно. Щоб зрозуміти ці правила, ми повинні спочатку пояснити поняття засобів і пріоритетів rsyslog. Кожне повідомлення журналу отримує номер facility і ключове слово, пов’язане з внутрішньою підсистемою Linux, яка створює повідомлення:

Номер Ключове слово Опис

0

kern

Повідомлення ядра Linux

1

користувач

Повідомлення на рівні користувача

2

пошта

Поштова система

3

демон

Системні демони

4

auth, authpriv

Повідомлення безпеки/авторизації

5

syslog

Повідомлення syslogd

6

lpr

Підсистема рядкового принтера

7

новини

Підсистема новин мережі

8

uucp

Підсистема UUCP (протокол копіювання Unix-to-Unix).

9

cron

Демон годинника

10

auth, authpriv

Повідомлення безпеки/авторизації

11

ftp

Демон FTP (протокол передачі файлів).

12

ntp

Демон NTP (протокол мережевого часу).

13

безпека

Журнал аудиту

14

консоль

Сповіщення журналу

15

cron

Демон годинника

16 - 23

від local0 до local7

Локальне використання 0 - 7

Крім того, кожному повідомленню присвоюється рівень пріоритету:

Код Вага Ключове слово Опис

0

Emergency

emerg, panic

Система непридатна для використання

1

Alert

alert

Треба негайно діяти

2

Critical

crit

Критичні стани

3

Error

err, error

Аварійні стани

4

Warning

warn, warning

Стан попередження

5

Notice

notice

Нормальний, але важливий стан

6

Informational

info

Інформаційні повідомлення

7

Debug

debug

Повідомлення рівня налагодження

Ось фрагмент rsyslog.conf з нашої системи Debian GNU/Linux 10 (buster), який містить кілька прикладів правил:

###############
#### RULES ####
###############

# First some standard log files.  Log by facility.
#
auth,authpriv.*                 /var/log/auth.log
*.*;auth,authpriv.none          -/var/log/syslog
#cron.*                         /var/log/cron.log
daemon.*                        -/var/log/daemon.log
kern.*                          -/var/log/kern.log
lpr.*                           -/var/log/lpr.log
mail.*                          -/var/log/mail.log
user.*                          -/var/log/user.log

#
# Logging for the mail system.  Split it up so that
# it is easy to write scripts to parse these files.
#
mail.info                       -/var/log/mail.info
mail.warn                       -/var/log/mail.warn
mail.err                        /var/log/mail.err

#
# Some "catch-all" log files.
#
*.=debug;\
        auth,authpriv.none;\
	news.none;mail.none     -/var/log/debug
*.=info;*.=notice;*.=warn;\
	auth,authpriv.none;\
	cron,daemon.none;\
	mail,news.none          -/var/log/messages

Формат правила такий: <facility>.<priority> <action>

Селектор <facility>.<priority> фільтрує повідомлення на відповідність. Рівні пріоритету є ієрархічно інклюзивними, що означає, що rsyslog відповідатиме повідомленням із вказаним пріоритетом і вищим за нього. <action> показує, яку дію виконати (куди надсилати повідомлення журналу). Ось кілька прикладів для наочності:

auth,authpriv.*                 /var/log/auth.log

Незалежно від їх пріоритету (*), усі повідомлення від об’єктів auth або authpriv надсилатимуться до /var/log/auth.log.

*.*;auth,authpriv.none          -/var/log/syslog

Усі повідомлення — незалежно від їхнього пріоритету (*) — з усіх об’єктів (*) — відкидаючи повідомлення з auth або authpriv (звідси суфікс .none) — буде записано в /var/log/syslog (знак дефіс (-) перед шляхом запобігає надмірному запису на диск). Зверніть увагу на крапку з комою (;), щоб розділити селектор, і кому (,), щоб об’єднати два засоби в одному правилі (auth,authpriv).

mail.err                        /var/log/mail.err

Повідомлення від засобу mail з рівнем пріоритету error або вищим (critical, alert або emergency) надсилатимуться до /var/log/mail.err.

*.=debug;\
        auth,authpriv.none;\
	news.none;mail.none     -/var/log/debug

Повідомлення від усіх об’єктів із пріоритетом debug і жодним іншим (=) записуватимуться до /var/log/debug, за винятком будь-яких повідомлень, що надходять від auth, authpriv, news і засобів mail (зверніть увагу на синтаксис: ;\).

Записи в системному журналі вручну: `logger`

Команда logger стане в нагоді для сценаріїв оболонки або для тестування. logger додаватиме будь-яке отримане повідомлення до /var/log/syslog (або до /var/log/messages під час входу на віддалений центральний сервер журналу, як ви побачите далі в цьому уроці):

carol@debian:~$ logger this comment goes into "/var/log/syslog"

Щоб надрукувати останній рядок у /var/log/syslog, використовуйте команду tail з опцією -1:

root@debian:~# tail -1 /var/log/syslog
Sep 17 17:55:33 debian carol: this comment goes into /var/log/syslog

`rsyslog` як центральний сервер журналу

Щоб пояснити цю тему, ми збираємося додати новий хост до наших налаштувань. Схема така:

Роль Ім’я хоста ОС IP-адреса

Центральний сервер журналу

suse-server

openSUSE Leap 15.1

192.168.1.6

Клієнт

debian

Debian GNU/Linux 10 (buster)

192.168.1.4

Почнемо з налаштування сервера. Перш за все, ми переконаємося, що rsyslog запущений і працює:

root@suse-server:~# systemctl status rsyslog
 rsyslog.service - System Logging Service
   Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; vendor preset: enabled)
   Active: active (running) since Thu 2019-09-17 18:45:58 CEST; 7min ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 832 (rsyslogd)
    Tasks: 5 (limit: 4915)
   CGroup: /system.slice/rsyslog.service
           └─832 /usr/sbin/rsyslogd -n -iNONE

openSUSE поставляється зі спеціальним файлом конфігурації для віддаленого журналювання: /etc/rsyslog.d/remote.conf. Увімкніть отримання повідомлень від клієнтів (віддалених хостів) через TCP. Ми повинні розкоментувати рядки, які завантажують модуль і запускають сервер TCP на порту 514:

# ######### Receiving Messages from Remote Hosts ##########
# TCP Syslog Server:
# provides TCP syslog reception and GSS-API (if compiled to support it)
$ModLoad imtcp.so  # load module
##$UDPServerAddress 10.10.0.1  # force to listen on this IP only
$InputTCPServerRun 514  # Starts a TCP server on selected port

# UDP Syslog Server:
#$ModLoad imudp.so  # provides UDP syslog reception
##$UDPServerAddress 10.10.0.1  # force to listen on this IP only
#$UDPServerRun 514  # start a UDP syslog server at standard port 514

Коли це буде зроблено, ми повинні перезапустити службу rsyslog і перевірити, чи сервер прослуховує порт 514:

root@suse-server:~# systemctl restart rsyslog
root@suse-server:~# netstat -nltp | grep 514
[sudo] password for root:
tcp        0      0 0.0.0.0:514             0.0.0.0:*               LISTEN      2263/rsyslogd
tcp6       0      0 :::514                  :::*                    LISTEN      2263/rsyslogd

Далі ми повинні відкрити порти в брандмауері та перезавантажити конфігурацію:

root@suse-server:~# firewall-cmd --permanent --add-port 514/tcp
success
root@suse-server:~# firewall-cmd --reload
success

Note	З появою openSUSE Leap 15.0 `firewalld` повністю замінив класичний `SuSEFirewall2`.

Шаблони та умови фільтрів

За замовчуванням журнали клієнта будуть записані у файл /var/log/messages сервера разом із журналами самого сервера. Однак ми створимо шаблон і умову фільтра, щоб журнали нашого клієнта зберігалися у власних чітких каталогах. Для цього ми додамо наступне до /etc/rsyslog.conf (або /etc/rsyslog.d/remote.conf):

$template RemoteLogs,"/var/log/remotehosts/%HOSTNAME%/%$NOW%.%syslogseverity-text%.log"
if $FROMHOST-IP=='192.168.1.4' then ?RemoteLogs
& stop

Шаблон

Шаблон відповідає першому рядку та дозволяє вказати формат імен журналів за допомогою динамічної генерації імен файлів. Шаблон складається з:

Директиви шаблону ($template)
Назви шаблону (RemoteLogs)
Тексту шаблону ("/var/log/remotehosts/%HOSTNAME%/%$NOW%.%syslogseverity-text%.log")
Параметрів (необов’язково)

Наш шаблон називається RemoteLogs, і його текст складається зі шляху в /var/log. Усі журнали нашого віддаленого хоста потраплять до каталогу remotehosts, де буде створено підкаталог на основі імені хоста машини (%HOSTNAME%). Ім’я кожного файлу в цьому каталозі складатиметься з дати (%$NOW%), рівня серйозності (він же пріоритет) повідомлення в текстовому форматі (%syslogseverity-text%) і суфікса .log. Слова між знаками відсотка є властивостями і дозволяють отримати доступ до вмісту повідомлення журналу (дата, пріоритет тощо). Повідомлення syslog має низку добре визначених властивостей, які можна використовувати в шаблонах. Доступ до цих властивостей здійснюється — і їх можна змінювати — за допомогою так званого замінника властивостей, який передбачає запис їх між знаками відсотків.

Стан фільтра

Решта два рядки відповідають умові фільтра та пов’язаній з ним дії:

Фільтр на основі виразів (if $FROMHOST-IP=='192.168.1.4')
Дія (then ?RemoteLogs, & stop)

Перший рядок перевіряє IP-адресу віддаленого хоста, який надсилає журнал, і, якщо вона збігається з адресою нашого клієнта Debian, застосовує шаблон RemoteLogs. Останній рядок (& stop) гарантує, що повідомлення не надсилаються одночасно до /var/log/messages (а лише до файлів у каталозі /var/log/remotehosts).

Note	Щоб дізнатися більше про шаблони, властивості та правила, ви можете переглянути сторінку посібника для `rsyslog.conf`.

Після оновлення конфігурації ми знову запустимо rsyslog і підтвердимо, що в /var/log ще немає каталогу remotehosts:

root@suse-server:~# systemctl restart rsyslog
root@suse-server:~# ls /var/log/
acpid             chrony     localmessages   pbl.log          Xorg.0.log
alternatives.log  cups       mail            pk_backend_zypp  Xorg.0.log.old
apparmor          firebird   mail.err        samba            YaST2
audit             firewall   mail.info       snapper.log      zypp
boot.log          firewalld  mail.warn       tallylog         zypper.log
boot.msg          krb5       messages        tuned
boot.omsg         lastlog    mysql           warn
btmp              lightdm    NetworkManager  wtmp

Сервер налаштовано. Далі ми налаштуємо клієнт.

Знову ж таки, ми повинні переконатися, що rsyslog встановлено та працює:

root@debian:~# sudo systemctl status rsyslog
 rsyslog.service - System Logging Service
   Loaded: loaded (/lib/systemd/system/rsyslog.service; enabled; vendor preset:
   Active: active (running) since Thu 2019-09-17 18:47:54 CEST; 7min ago
     Docs: man:rsyslogd(8)
           http://www.rsyslog.com/doc/
 Main PID: 351 (rsyslogd)
    Tasks: 4 (limit: 4915)
   CGroup: /system.slice/rsyslog.service
           └─351 /usr/sbin/rsyslogd -n

У нашому прикладі середовища ми реалізували розпізнавання імен на клієнті, додавши рядок 192.168.1.6 suse-server до /etc/hosts. Таким чином, ми можемо звертатися до сервера або за назвою (suse-server), або за IP-адресою (192.168.1.6).

Наш клієнт Debian не постачається з файлом remote.conf у /etc/rsyslog.d/, тому ми застосуємо наші налаштування у /etc/rsyslog.conf. У кінці файлу ми напишемо такий рядок:

*.* @@suse-server:514

Нарешті, ми перезапускаємо rsyslog.

root@debian:~# systemctl restart rsyslog

Тепер давайте повернемося до нашої машини suse-server і перевіримо існування remotehost в /var/log:

root@suse-server:~# ls /var/log/remotehosts/debian/
2019-09-17.info.log  2019-09-17.notice.log

У нас уже є два журнали всередині /var/log/remotehosts, як описано в нашому шаблоні. Щоб завершити цей розділ, ми запускаємо tail -f 2019-09-17.notice.log на suse-server, надсилаючи журнал вручну з нашого клієнта Debian і підтверджуючи, що повідомлення додаються до файлу журналу як очікується (параметр -t надає тег для нашого повідомлення):

root@suse-server:~# tail -f /var/log/remotehosts/debian/2019-09-17.notice.log
2019-09-17T20:57:42+02:00 debian dbus[323]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
2019-09-17T21:01:41+02:00 debian anacron[1766]: Anacron 2.3 started on 2019-09-17
2019-09-17T21:01:41+02:00 debian anacron[1766]: Normal exit (0 jobs run)

carol@debian:~$ logger -t DEBIAN-CLIENT Hi from 192.168.1.4

root@suse-server:~# tail -f /var/log/remotehosts/debian/2019-09-17.notice.log
2019-09-17T20:57:42+02:00 debian dbus[323]: [system] Successfully activated service 'org.freedesktop.nm_dispatcher'
2019-09-17T21:01:41+02:00 debian anacron[1766]: Anacron 2.3 started on 2019-09-17
2019-09-17T21:01:41+02:00 debian anacron[1766]: Normal exit (0 jobs run)
2019-09-17T21:04:21+02:00 debian DEBIAN-CLIENT: Hi from 192.168.1.4

Механізм ротації журналів

Журнали регулярно чергуються, що служить двом основним цілям:

Запобігання використанню старими файлами журналів дискового простору більше, ніж необхідно.
Зберігання журналів до керованої довжини для зручності перегляду.

Утиліта, яка відповідає за ротацію (або циклічність) журналів, — це logrotate, і її робота включає такі дії, як переміщення файлів журналу під новою назвою, їх архівування та/або стиснення, іноді надсилання їх електронною поштою системному адміністратору та зрештою їх видалення, коли вони застарівають. Існують різні угоди щодо іменування цих змінених файлів журналу (наприклад, додавання суфікса з датою до назви файлу); однак просто додавання суфікса з цілим числом є звичайною практикою:

root@debian:~# ls /var/log/messages*
/var/log/messages  /var/log/messages.1  /var/log/messages.2.gz  /var/log/messages.3.gz  /var/log/messages.4.gz

Давайте тепер пояснимо, що станеться під час наступної ротації журналу:

messages.4.gz буде видалено та втрачено.
Вміст messages.3.gz буде переміщено до messages.4.gz.
Вміст messages.2.gz буде переміщено до messages.3.gz.
Вміст messages.1 буде переміщено до messages.2.gz.
Вміст messages буде переміщено до messages.1, а messages буде порожнім і готовим до реєстрації нових записів журналу.

Зауважте, як, згідно з директивами logrotate, які ви незабаром побачите, три старіші файли журналу стискаються, а два найновіші – ні. Крім того, ми будемо зберігати журнали за останні 4-5 тижнів. Щоб прочитати повідомлення 1-тижневої давності, ми звернемося до messages.1 (і так далі).

logrotate запускається як автоматизований процес або завдання cron щодня за допомогою сценарію /etc/cron.daily/logrotate і читає файл конфігурації /etc/logrotate.conf. Цей файл містить кілька глобальних параметрів і добре прокоментований, до кожного параметра введено коротке пояснення його призначення:

carol@debian:~$ sudo less /etc/logrotate.conf
# see "man logrotate" for details
# rotate log files weekly
weekly

# keep 4 weeks worth of backlogs
rotate 4

# create new (empty) log files after rotating old ones
create

# uncomment this if you want your log files compressed
#compress

# packages drop log rotation information into this directory
include /etc/logrotate.d

(...)

Як бачите, файли конфігурації в /etc/logrotate.d для певних пакунків також включені. Ці файли здебільшого містять локальні визначення та вказують файли журналу для ротації (пам’ятайте, що локальні визначення мають пріоритет над глобальними, а пізніші визначення замінюють попередні). Далі наведено уривок визначення в /etc/logrotate.d/rsyslog:

/var/log/messages
{
        rotate 4
        weekly
        missingok
        notifempty
        compress
        delaycompress
        sharedscripts
        postrotate
                invoke-rc.d rsyslog rotate > /dev/null
        endscript
}

Як ви бачите, кожна директива відокремлена від свого значення пробілом та/або необов’язковим знаком рівності (=). Рядки між postrotate і endscript повинні з’являтися в рядках окремо. Пояснення полягає в наступному:

rotate 4: Зберігає журнали на 4 тижні.
weekly: Щотижня проводить ротацію файлів журналів.
missingok: Не видає повідомлення про помилку, якщо файл журналу відсутній; просто переходить до наступного.
notifempty: Не проводить ротацію журналу, якщо він порожній.
compress: Стискає файли журналу за допомогою gzip (за замовчуванням).
delaycompress: Відкладає стиснення попереднього файлу журналу до наступного циклу ротації (ефективно, лише коли використовуються в поєднанні зі стисненням). Це корисно, коли програмі не можна наказати закрити свій файл журналу, і, таким чином, вона може продовжувати запис у попередній файл журналу протягом деякого часу.
sharedscripts: Пов’язано зі сценаріями prerotate і postrotate. Щоб запобігти багаторазовому виконанню сценарію, запустіть сценарії лише один раз незалежно від того, скільки файлів журналу відповідає заданому шаблону (наприклад, /var/log/mail/*). Сценарії не запускатимуться, якщо жоден із журналів у шаблоні не вимагає ротації. Крім того, якщо сценарії завершуються з помилками, будь-які інші дії не виконуватимуться для журналів.
postrotate: Вказує на початок сценарію postrotate.
invoke-rc.d rsyslog rotate > /dev/null: Використовуйте /bin/sh, щоб запустити invoke-rc.d rsyslog rotate > /dev/null після ротації журналів.
endscript: Вкажіть кінець сценарію postrotate.

Note	Щоб отримати повний список директив і пояснень, зверніться до man-сторінки для `logrotate.conf`.

Кільцевий буфер ядра

Оскільки ядро генерує кілька повідомлень до того, як rsyslogd стане доступним під час завантаження, необхідний механізм реєстрації цих повідомлень. Ось тут і вступає в дію кільцевий буфер ядра. Це структура даних фіксованого розміру, і, отже, у міру збільшення нових повідомлень найстаріші зникатимуть.

Команда dmesg виводить кільцевий буфер ядра. Через розмір буфера цю команду зазвичай використовують у поєднанні з утилітою фільтрації тексту grep. Наприклад, щоб шукати повідомлення, пов’язані з пристроями універсальної послідовної шини:

root@debian:~# dmesg | grep "usb"
[    1.241182] usbcore: registered new interface driver usbfs
[    1.241188] usbcore: registered new interface driver hub
[    1.250968] usbcore: registered new device driver usb
[    1.339754] usb usb1: New USB device found, idVendor=1d6b, idProduct=0001, bcdDevice= 4.19
[    1.339756] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
(...)

Вправи до посібника

Які утиліти/команди ви б використали в наведених нижче сценаріях:

Призначення та файл журналу Утиліта

Читання /var/log/syslog.7.gz

Читання /var/log/syslog

Фільтр за словом renewal в /var/log/syslog

Читання /var/log/faillog

Динамічне читання /var/log/syslog

Переставте наступні записи журналу таким чином, щоб вони представляли дійсне повідомлення журналу з належною структурою:
- debian-server
- sshd
- [515]:
- Sep 13 21:47:56
- Server listening on 0.0.0.0 port 22
  
  Правильний порядок:
Які правила ви б додали до /etc/rsyslog.conf, щоб виконати кожну з наступних дій:
- Надсилати всі повідомлення засобом mail і з пріоритететом/серйозністю crit (і вище) до /var/log/mail.crit:
- Надсилати всі повідомлення засобом mail з пріоритетами alert і emergency до /var/log/mail.urgent:
- За винятком тих, що надходять із засобів cron і ntp, надсилати всі повідомлення — незалежно від їхнього засобу та пріоритету — до /var/log/allmessages:
- Спершу правильно налаштуйте всі необхідні параметри, надішліть усі повідомлення засобом mail на віддалений хост, IP-адреса якого 192.168.1.88, використовуючи TCP і вказавши порт за замовчуванням:
- Незалежно від об’єкту, надсилайте всі повідомлення з пріоритетом warning (_тільки з пріоритетом warning _) до /var/log/warnings, запобігаючи надмірному запису на диск:

Розгляньте наступні дані з /etc/logrotate.d/samba та поясніть різні варіанти:

carol@debian:~$ sudo head -n 11 /etc/logrotate.d/samba
/var/log/samba/log.smbd {
        weekly
        missingok
        rotate 7
        postrotate
                [ ! -f /var/run/samba/smbd.pid ] || /etc/init.d/smbd reload > /dev/null
        endscript
        compress
        delaycompress
        notifempty
}

Варіант Значення

weekly

missingok

rotate 7

postrotate

endscript

compress

delaycompress

notifyempty

Дослідницькі вправи

У розділі “Шаблони та умови фільтрації” ми використовували фільтр на основі виразу як умову фільтрації. Фільтри на основі властивостей є іншим типом фільтрів, унікальних для rsyslogd. Переробіть наш фільтр на основі виразів у фільтр на основі властивостей:

Фільтр на основі виразів Фільтр на основі властивостей

if $FROMHOST-IP=='192.168.1.4' then ?RemoteLogs
omusrmsg — це вбудований модуль rsyslog, який полегшує сповіщення користувачів (він надсилає повідомлення журналу на термінал користувача). Напишіть правило для надсилання всіх надзвичайних повідомлень з усіх об’єктів як root, так і звичайному користувачеві carol.

Підсумки

На цьому уроці ви вивчили:

Ведення журналу має вирішальне значення для адміністрування системи.
rsyslogd - це утиліта, яка відповідає за збереження акуратності та порядку журналів.
Деякі служби піклуються про власні журнали.
Грубо кажучи, журнали можна класифікувати на системні журнали та журнали служб/програм.
Існує ряд утиліт, зручних для читання журналів: less, more, zless, zmore, grep, head і tail.
Більшість файлів журналу є звичайними текстовими файлами; однак існує невелика кількість двійкових файлів журналу.
Що стосується журналу, rsyslogd отримує відповідну інформацію зі спеціальних файлів (сокетів і буферів пам’яті) перед її обробкою.
Для класифікації журналів rsyslogd використовує правила в /etc/rsyslog.conf або /etc/rsyslog.d/*`.
Будь-який користувач може вручну вводити власні повідомлення в системний журнал за допомогою утиліти logger.
rsyslog дозволяє зберігати всі журнали в IP-мережах на централізованому сервері журналів.
Шаблони стають у пригоді для динамічного форматування імен файлів журналу.
Ротація журналів має подвійну мету: запобігти використанню надмірного дискового простору старими журналами та щоб зробити консультаційні журнали керованими.

Відповіді до вправ посібника

Які утиліти/команди ви б використали в наведених нижче сценаріях:

Призначення та файл журналу Утиліта

Читання /var/log/syslog.7.gz

zmore або zless

Читання /var/log/syslog

more або less

Фільтр за словом renewal в /var/log/syslog

grep

Читання /var/log/faillog

faillog -a

Динамічне читання /var/log/syslog

tail -f

Переставте наступні записи журналу таким чином, щоб вони представляли дійсне повідомлення журналу з належною структурою:
- debian-server
- sshd
- [515]:
- Sep 13 21:47:56
- Server listening on 0.0.0.0 port 22
  
  Правильний порядок:
  Sep 13 21:47:56 debian-server sshd[515]: Server listening on 0.0.0.0 port 22
Які правила ви б додали до /etc/rsyslog.conf, щоб виконати кожну з наступних дій:
- Надсилати всі повідомлення засобом mail і з пріоритететом/серйозністю crit (і вище) до /var/log/mail.crit:
  mail.crit /var/log/mail.crit
- Надсилати всі повідомлення засобом mail з пріоритетами alert і emergency до /var/log/mail.urgent:
  mail.alert /var/log/mail.urgent
- За винятком тих, що надходять із засобів cron і ntp, надсилати всі повідомлення — незалежно від їхнього засобу та пріоритету — до /var/log/allmessages:
  *.*;cron.none;ntp.none /var/log/allmessages
- Спершу правильно налаштуйте всі необхідні параметри, надішліть усі повідомлення засобом mail на віддалений хост, IP-адреса якого 192.168.1.88, використовуючи TCP і вказавши порт за замовчуванням:
  mail.* @@192.168.1.88:514
- Незалежно від об’єкту, надсилайте всі повідомлення з пріоритетом warning (_тільки з пріоритетом warning _) до /var/log/warnings, запобігаючи надмірному запису на диск:
  *.=warning -/var/log/warnings

Розгляньте наступні дані з /etc/logrotate.d/samba та поясніть різні варіанти:

carol@debian:~$ sudo head -n 11 /etc/logrotate.d/samba
/var/log/samba/log.smbd {
        weekly
        missingok
        rotate 7
        postrotate
                [ ! -f /var/run/samba/smbd.pid ] || /etc/init.d/smbd reload > /dev/null
        endscript
        compress
        delaycompress
        notifempty
}

Варіант Значення

weekly

Щотижнева ротація файлів журналу.

missingok

Не видавати повідомлення про помилку, якщо журнал відсутній; просто перейти до наступного.

rotate 7

Зберігання 7 тижнів інформації про невиконанні завдання.

postrotate

Запуск сценарію у наступному рядку після ротації журналів.

endscript

Визначення кінця сценарію postrotate.

compress

Стиснення журналів за допомогою gzip.

delaycompress

У поєднанні з compress відкладення стиснення до наступного циклу ротації.

notifyempty

Не проводити ротацію журнала, якщо він порожній.

Відповіді до дослідницьких вправ

У розділі “Шаблони та умови фільтрації” ми використовували фільтр на основі виразу як умову фільтрації. Фільтри на основі властивостей є іншим типом фільтрів, унікальних для rsyslogd. Переробіть наш фільтр на основі виразів у фільтр на основі властивостей:

Фільтр на основі виразів Фільтр на основі властивостей

if $FROMHOST-IP=='192.168.1.4' then ?RemoteLogs

:fromhost-ip, isequal, "192.168.1.4" ?RemoteLogs

omusrmsg — це вбудований модуль rsyslog, який полегшує сповіщення користувачів (він надсилає повідомлення журналу на термінал користувача). Напишіть правило для надсилання всіх надзвичайних повідомлень з усіх об’єктів як root, так і звичайному користувачеві carol.
```
*.emerg                        :omusrmsg:root,carol
```