Модуль 21. Работа с журналами и отладка системы

Введение

Говорят, что практика — это когда все работает, но непонятно как, а теория — это когда все понятно, но ничего не работает. Однако, когда теория совмещается с практикой, при этом ничего не работает и ничего не понятно, наступает время отладки.

Из этого модуля вы узнаете, как работает система журналирования в Linux и какие журналы можно использовать для быстрой отладки приложений. Мы обсудим эффективные подходы к выполнению отладки и детально разберем несколько часто встречающихся нештатных ситуаций.

Работа с журналами и сбор логов

На компьютерах Linux мы довольно часто используем приложения с открытыми исходными кодами, поэтому при выявлении проблемы, никто не мешает скомпилировать и запустить приложение в режиме отладки, но это все-таки далеко не самый простой способ.

Обычно системные администраторы ограничиваются внимательным изучением сообщений об ошибках, которые появляются в журналах в момент воспроизведения проблемы, поэтому нужно хорошо понимать, как работает эта система.

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

Разработчики каждого приложения вправе сами выбирать, какие именно события они будут логировать и куда будут их записывать, но все вендоры стараются придерживаться общих стандартов, т.к. понимают, что чем легче будет поддерживать их приложение, тем выше шансы, что их продукт окажется востребован на рынке. Поэтому среди разработчиков Linux признаком хорошего тона является запись событий в подсистему журналирования syslog.

Термином syslog (англ. system log — системный журнал) называют как саму службу централизованного ведения журналов событий, так и протокол, по которому она получает события от приложений. В операционной системе Windows аналогом syslog является подсистема, которая так и называется «Журнал событий» (англ. Event Log).

Сообщения syslog представляют собой обычные текстовые строки в формате:

<priority>timestamp hostname: message

Где:

• priority – определяет важность сообщения,

• timestamp – дату и время генерации события в системе

• hostname – позволяет организовать централизованное хранение событий со всех компьютеров в сети.

Приоритет включает в себя значение категории субъекта (facilities, см. табл. 8) и уровень важности события (severity, см. табл. 9) по формуле:

\[Priority = (facilities \cdot 8) + severity\]

Например, если нам потребуется зафиксировать событие Security (13) с уровнем Error (3), то нужно будет использовать приоритет:

\[Priority = (13 \cdot 8) + 3 = 107\]

В зависимости от значения приоритета и настроек syslog система может поместить событие в тот или иной файл, или вообще отбросить, что определяется фильтрами источников.

табл. 8 Коды категорий субъектов (facilities) в протоколе syslog.

#	Категория	Описание
0	kern	ядро операционной системы
1	user	программное обеспечение пользователя
2	mail	почтовая система
3	daemon	системные службы (daemons)
4	auth	сообщения безопасности (авторизации)
5	syslog	собственные сообщения syslogd
6	lpr	подсистема печати
7	news	подсистема новостных групп (телеконференций, NNTP)
8	uucp	подсистема UUCP (Unix-to-Unix Copy Protocol)
9	cron	службы времени
10	authpriv	сообщения безопасности (авторизации)
11	ftp	служба FTP
12	ntp	подсистема NTP
13	security	журнал аудита (упразнен, используйте auth)
14	console	аварийный журнал
15	solaris-cron	службы времени
16	local0	локальный 0
17	local1	локальный 1
18	local2	локальный 2
19	local3	локальный 3
20	local4	локальный 4
21	local5	локальный 6
22	local6	локальный 6
23	local7	локальный 7

табл. 9 Уровни важности (severity) в протоколе syslog.

#	Буквенный код*	Описание значения
0	emerg	Emergency – система не работоспособна
1	alert	Alert – система требует немедленного вмешательства
2	crit	Critical – состояние системы критическое
3	err	Error – сообщения об ошибках
4	warning	Warning – предупреждения о возможных проблемах
5	notice	Notice – сообщения о нормальных, но важных событиях
6	info	Informational – информационные сообщения
7	debug	Debug – отладочные сообщения

Примечание

Буквенный код применяется в фильтрах syslog-ng или утилите logger, подробнее см. справку man logger

Местом хранения системных журналов по стандарту FHS является каталог /var/log. Вот несколько наиболее важных из них:

• Файл /var/log/syslog — основной журнал, в котором хранятся все сообщения, кроме сообщений об аутентификации и сообщений почтовой службы.

• Файл /var/log/messages — сокращенная версия файла syslog. Сюда записываются несколько типов сообщений: почта, cron, сервисы systemd, сообщения от ядра, pam, аутентификация и др.

• Файл /var/log/auth.log — хранит сообщения об аутентификации служб и пользователей.

Стоит упомянуть также файлы:

• Файл /var/log/boot.log — хранит сообщения, сгенерированные во время загрузки ОС.

• Файл /var/log/kern.log — хранит сообщения от ядра ОС.

• Файл /var/log/daemon.log — хранит сообщения от различных служб (кроме почты, печати и планировщика cron).

• Файл /var/log/user.log – хранит сообщения от команд, выполняемых пользователями (NetworkManager, графическими программами и так далее).

Перечисляя файлы журналов, обычно упоминают еще wtmp и lastlog, но они хранят данные в бинарном формате и не имеют отношения к службе syslog:

• Файл /var/log/lastlog — информация о последних входах в систему пользователей.

• Файл /var/log/wtmp — хранит сообщения о сеансах пользователей, перезагрузках системы.

Для просмотра информации из этих файлов применяется утилита who, например, информацию о загрузке системы можно получить командой who -b.

Локальные приложения передают события в подсистему syslog через unix-сокет /dev/log, а для системных сообщений ядра отведены также сокет /dev/kmsg и псевдофайл /proc/kmsg. Но при написании кода разработчикам даже не требуется задумываться об этих сокетах, так как во всех современных языках программирования высокого уровня есть библиотеки, с помощью которых записать событие в журнал не сложнее, чем вывести строку на экран.

Более того, даже из скриптов bash событие в журнал можно записать одной строкой, например, вот так можно имитировать сообщение об ошибке уровня ядра:

localadmin@astra:~$ logger --priority kern.error 'Имитируем панику'

Это событие в соответствии с его приоритетом попадет в журнал /var/log/syslog.

localadmin@astra:~$ sudo tail -f /var/log/syslog
...
Jun 10 07:14:03 astra localadmin[4768]: Имитируем панику

Если вернуться к библиотекам логирования, то в них обычно реализуют множество дополнительных обработчиков, с помощью которых сообщения можно одновременно передавать в syslog, выводить на экран, записывать в собственный файл и многое другое. Например, служба SSSD позволяет сохранять события каждого компонента в отдельном файле.

Система журналирования syslog-ng

В системе Astra Linux Special Edition 1.7 для работы с системными журналами используется не старая служба syslog, а ее усовершенствованная версия syslog-ng (от англ. Syslog Next Generation) — это бесплатная реализация протокола syslog с открытым исходным кодом для nix-подобных систем.

Приложение расширяет исходную модель работы службы syslogd возможностями гибкой фильтрации на основе содержимого и добавляет такие важные функции, как возможность использования TCP для транспортировки сообщений. Передавать события на централизованный сервер журналирования можно не только на порт 514/UDP, но еще и 601/TCP, а в случае применения TLS дополнительно 6514/UDP и 6514/TCP.

Основным конфигурационным файлом службы является /etc/syslog-ng/syslog-ng.conf, в котором определяются объекты системы.

Приведем часть его содержимого:

localadmin@astra:~$ cat /etc/syslog-ng/syslog-ng.conf
@version: 3.19
@include "scl.conf"
...

В начале файла обозначается версия syslog-ng, и подключается файл scl.conf, который, в свою очередь, подключает все файлы с суффиксом *.conf из каталога /etc/syslog-ng/scl/*.

Аббревиатура SCL означает Syslog-ng Configuration Library — библиотека конфигураций syslog. Это набор файлов конфигураций, который по задумке разработчиков syslog-ng помогает избежать загромождения основного файла конфигурации и позволяет повторно использовать готовые фрагменты конфигурации на разных узлах.

В Astra Linux по умолчанию не существует каталога /etc/syslog-ng/scl, а все дополнительные файлы конфигурации располагаются непосредственно в каталоге /etc/syslog-ng/conf.d.

localadmin@astra:~$ tail /etc/syslog-ng/scl.conf -n 6

# This file is placed into /etc/syslog-ng in order to make it trivial to
# include in user written syslog-ng.conf files.  It sets up 'scl-root' and
# `include-path`, then includes all SCL supplied plugins.
#
@include 'scl/*/*.conf'

Далее следуют глобальные опции:

...
options {
   chain_hostnames(off); flush_lines(0); use_dns(no); use_fqdn(no);
   dns_cache(no); owner("root"); group("adm"); perm(0640);
   stats_freq(0); bad_hostname("^gconfd$");
};
...

Далее идет перечисление драйверов источников сообщений:

...
source s_src {
   system();
   internal();
};
...

Как видим, по умолчанию используются два источника:

• system() – отвечает за автоматическое определение платформы и сбор стандартных для этой платформы журналов.

• internal() – сообщения, генерируемые самой службой syslog-ng.

В операционной системе Astra Linux служба syslog-ng определяет, что рядом с ней работает служба journald, поэтому источник system() автоматически настраивает syslog-ng на чтение файла службы journald из каталога /run/log/journal/.

А служба journald, в свою очередь, получает все сообщения от приложений, т.к. файл /dev/log является обычной символической ссылкой на ее unix-сокет /run/systemd/journal/dev-log. Взаимодействие компонентов представлено на рис. 148.

рис. 148 Порядок получения сообщений службой syslog-ng

Далее следует раздел с драйверами приемников сообщений:

...
destination d_auth { file("/var/log/auth.log"); };
destination d_cron { file("/var/log/cron.log"); };
destination d_daemon { file("/var/log/daemon.log"); };
...

По умолчанию используются приемники двух типов:

• file() – запись сообщений в указанный файл;

• usertty() – отправка сообщений на терминал указанного пользователя, если сессия пользователя активна.

Следом идут фильтры:

...
filter f_dbg { level(debug); };
filter f_info { level(info); };
filter f_notice { level(notice); };
...

По умолчанию используются три типа фильтров:

• level – фильтрация сообщений по приоритету (severity), см. табл. 9;

• program – фильтрация сообщений по названию приложения;

• facility – фильтрация сообщений по субъекту (facility), см. табл. 8.

Затем в конфигурационном файле перечисляются пути логов (англ. log paths), которые связывают источники с фильтрами и получателями:

...
log { source(s_src); filter(f_auth); destination(d_auth); };
log { source(s_src); filter(f_cron); destination(d_cron); };
log { source(s_src); filter(f_daemon); destination(d_daemon); };
...

И уже в конце файла может быть настроена пересылка сообщений по сети:

# All messages send to a remote site
#
# log { source(s_src); destination(d_net); };

И подключение дополнительных файлов *.conf из каталога /etc/syslog-ng/conf.d/:

...
@include "/etc/syslog-ng/conf.d/*.conf"
...

Давайте посмотрим список дополнительных файлов в каталоге /etc/syslog-ng/conf.d:

localadmin@astra:~$ ls /etc/syslog-ng/conf.d
20-ufw.conf mod-astra-disk-space-running-out.conf  mod-astra-ram-running-out.conf
astraevents.conf mod-astra-previous-login.conf  mod-astra-unsigned-binary-file.conf
mod-astra.conf mod-astra-quota-depleted.conf

Как вы могли заметить, объекты задаются в следующем синтаксисе:

<Тип объекта> <Идентификатор объекта> {
   <параметр>(<опция> ..., ...) ...; ... };

Где:

• Тип объекта — драйвер источника и источник, драйвер приемника и приемник, путь, фильтр, анализатор, модификатор, шаблон, глобальная опция и др.

• Идентификатор объекта — уникальное имя, определяющее объект. Рекомендуется использовать имена с префиксами, указывающими на тип объекта, например, префикс «s_» для источников, префикс «d_» для приемников и т.д.

  Имена являются регистр-зависимыми. Желательно избегать имен, которые являются зарезервированными словами, но, если очень хочется, заключите это имя в кавычки. Повторное определение объектов не допускается, если не задан параметр: @define allow-config-dups 1.

• Параметр — список параметров объекта, которые заключаются в фигурные скобки. Параметры разделяются точкой с запятой.

• Опция — модификаторы параметров.

Определение объекта завершается символом точки с запятой.

Объекты syslog-ng

Система syslog-ng оперирует следующими объектами:

• Путь (англ. log path) – это комбинация источников, приемников и других объектов. Он указывает, откуда берется сообщение, как оно преобразуется и куда отправляется.

• Драйвер источника – метод коммуникации, используемый для получения сообщений.

• Источник (англ. source) – именованный набор сконфигурированных драйверов источников.

• Драйвер приемника – метод коммуникации, используемый для передачи протоколируемых сообщений.

• Приемник (англ. destinations) – именованный набор сконфигурированных драйверов приемников.

• Фильтр (англ. filters) – правило, применяемое для отбора сообщений.

• Анализатор (англ. parsers) – правило для анализа и разбора сообщений.

• Модификатор правил (англ. rewriting rules) – правило для изменения части сообщения.

• Макрос – идентификатор, для обращения к определенной части сообщения.

• Шаблон (англ. template) – набор макросов для реструктуризации сообщения.

• Глобальные опции (англ. options) – набор глобальных опций для детальной настройки syslog-ng

Источники и драйверы источников

Для источников служба syslog-ng использует следующий синтаксис:

source <идентификатор_объекта> { драйвер_источника(параметры); … };

Например:

source s_src { system(); internal(); };

Это же определение объекта может быть записано в несколько строк:

source s_src {
      system();
      internal();
};

По правилам именования в названии источника следует использовать префикс «s_». Полный список поддерживаемых драйверов представлен далее в табл. 10.

табл. 10 Поддерживаемые типы драйверов источника

Название	Описание
syslog()	Прием сообщений по протоколу IETF-syslog.
internal()	Сообщения, генерируемые службой syslog-ng.
system()	Автоматическое определение платформы и сбор со стандартных для этой платформы журналов
systemd-journal()	Прямое получение сообщений от служб журналов на платформах, использующих systemd.
systemd-syslog()	Получение сообщений через сокет от служб журналов на платформах, использующих systemd.
file()	Получение сообщений из указанного файла.
pipe()	Чтение сообщений из указанного именованного потока.
unix-dgram()	Получение сообщений через указанный сокет SOCK_DGRAM.
unix-stream()	Получение сообщений через указанный сокет SOCK_STREAM.
network()	Прием сообщений от удаленного хоста по протоколу BSD-syslog в сетях IPv4 и IPv6. Поддерживает сетевые протоколы UDP, TCP, в том числе с TLS.
program()	Запуск указанного приложения и чтение сообщений из его стандартного вывода.

Приемники и драйверы приемников

Для приемников служба syslog-ng использует следующий синтаксис:

destination <идентификатор_объекта> { драйвер_источника(параметры); … };

Например:

destination d_auth { file("/var/log/auth.log"); };

По правилам именования в названии приемника следует использовать префикс «d_». Полный список поддерживаемых драйверов представлен далее в табл. 11.

табл. 11 Поддерживаемые типы драйверов приемника

Название	Описание
syslog()	Отправка сообщений на удаленный хост по протоколу IETF-syslog protocol. Поддерживает сетевые протоколы TCP, UDP и TLS.
usertty()	Отправка сообщений на терминал указанного пользователя, если сессия пользователя активна.
file()	Запись сообщений в указанный файл.
pipe()	Запись сообщений в указанный именованный поток.
unix-dgram()	Отправка сообщений в формате BSD через указанный сокет SOCK_DGRAM.
unix-stream()	Отправка сообщений в формате Linux через указанный сокет SOCK_STREAM.
network()	Отправка сообщений на удаленный хост по протоколу BSD через сети IPv4 IPv6. Поддерживает сетевые протоколы TCP, UDP и TLS.
program()	Запуск указанной программы и отправка сообщений на ее стандартный ввод.
sql()	Сохранение сообщений в СУБД SQL. Требует установки и настройки СУБД.
elasticsearch(), elasticsearch2()	Отправка сообщений на сервер Elasticsearch. Вариант драйвера elasticsearch2 поддерживает Elasticsearch версии 2 и новее.
hdfs()	Запись сообщений в указанный файл на узле Hadoop Distributed File System (HDFS).
kafka()	Публикация сообщений подписчикам через шину Apache Kafka.
loggly()	Отправка сообщения провайдеру Loggly (https://www.loggly.com/)
logmatic()	Отправка сообщения провайдеру Logmatic.io (https://logmatic.io/)
mongodb()	Сохранение сообщений в СУБД MongoDB.

Фильтры в файле конфигурации syslog-ng

Для фильтров служба syslog-ng использует следующий синтаксис:

filter <идентификатор_объекта> { тип_фильтра(фильтрующее_выражение); ... };

Например:

filter f_auth {
   facility(auth, authpriv) and not filter(f_debug) and not filter(f_audit);
};

Как вы можете заметить, допускается использование логических операндов «and» и «not». По правилам именования в названии фильтра следует использовать префикс «f_». Полный список поддерживаемых фильтров представлен далее в табл. 12.

табл. 12 Поддерживаемые типы фильтров

Название	Описание
filter()	Вызов другого фильтра.
level(), priority()	Фильтрация сообщений по приоритету (severity, см. табл. 9). Допускает перечисление в виде массива, например: level(warn .. emerg) – все события с уровнем критичности от предупреждения до экстренных. .
facility()	Фильтрация сообщений по указанному объекту (facility, см. табл. 8).
host()	Фильтрация сообщений по имени хоста-отправителя.
message()	Фильтрация по регулярным выражениям Perl*, применяемым к содержимому сообщения.
source()	Фильтрация сообщений по указанному источнику.
program()	Фильтрация сообщений по названию приложения.
netmask()	Фильтрация сообщений по IP-адресу хоста-отправителя.
match()	Фильтрация по регулярным выражениям Perl, применяемым к заголовку и содержимому сообщения. Дополнительную информацию можно получить командой man pcre.
tags()	Фильтрация сообщений по наличию указанных тегов.
inlist()	Фильтрация сообщений по черным и белым спискам в файлах.

Пути в файле конфигураций syslog-ng

Для путей служба syslog-ng использует следующий синтаксис:

log{ source(...); filter(...); destination(...); };

Например:

log { source(s_src); filter(f_auth); destination(d_auth); };

Формат сообщений о событиях

В настоящее время существует два стандартных формата сообщений syslog:

• BSD-syslog (классический)

• IETF-syslog (новый)

Формат BSD-syslog

Общий размер сообщения не может быть больше 1024 байт, формат сообщения:

<PRIORITY><HEADER><MESSAGE>

Где:

• <PRIORITY> – как уже было сказано выше, приоритет кодирует значение категории субъекта, т.е. категорию подсистемы, от которой получено сообщение, и уровень важности события (англ. Severity — строгость). Используется формула \((facilities \cdot 8) + severity\).

• <HEADER> – содержит метку времени и имя хоста (без имени домена) или IP-адрес устройства.

• <MESSAGE> – содержит имя программы или процесса, сгенерировавшего сообщение, и текст самого сообщения.

Пример сообщения:

<165>Oct 11 22:14:15 mymachine auth[8710]: 'su root' failed for ivani on /dev/pts/8

Формат сообщения IETF-syslog

Формат сообщения:

<ЗАГОЛОВОК><СТРУКТУРИРОВАННЫЕ ДАННЫЕ><СООБЩЕНИЕ>

Где:

• <ЗАГОЛОВОК> состоит из:

  • PRIORITY — представляет Facility и Severity сообщения, рассчитывается по той же формуле: \((facilities \cdot 8) + severity\).

  • VERSION — номер версии стандарта протокола syslog. В настоящее время это значение может быть только 1.

  • ISOTIMESTAMP — время создания сообщения в формате ISO 8601 (yyyy-mm-ddThh:mm:ss+-ZONE).

  • HOSTNAME — устройство, которое первоначально отправило сообщение.

  • APPLICATION — устройство или приложение, которое сгенерировало сообщение.

  • PID – имя или идентификатор процесса приложения, отправившего сообщение.

  • MESSAGEID – идентификационный номер сообщения.

• <СТРУКТУРИРОВАННЫЕ ДАННЫЕ> – часть сообщения может содержать метаинформацию о сообщении syslog или специфическую для приложения информацию, такую как счетчики трафика или IP-адреса.

  Структурированные данные состоят из блоков данных, заключенных в скобки ([]). Каждый блок включает в себя идентификатор блока и одну или несколько пар имя=значение.

• <СООБЩЕНИЕ> – содержит текст самого сообщения в UTF-8.

Пример сообщения IETF-syslog:

<165>1 2003-10-11T22:14:15.003Z mymachine.example.com evntslog 4322 ID47 [exampleSDID@32473 iut="3" eventSource="Application" eventID="1011"] An application event log entry...

Настройка централизованного журналирования

Служба syslog-ng позволяет отправлять сообщения от клиентов на сервер для возможности их централизованного хранения. Эта возможность задействована в продукте ALD Pro для построения подсистемы аудита. При выполнении настройки изменения нужно вносить как на стороне клиента, так и на сервере. Опишем общий порядок настройки.

Настройка syslog-ng на сервере

1. Создать сертификат и приватный ключ для сервера и разместить их в подкаталогах cert.d, key.d, ca.d каталога /etc/syslog-ng.

2. Изменить конфигурационный файл /etc/syslog-ng/syslog-ng.conf – определить в нем:

   • Источник, используя драйвер network(), указав в нем значения параметров port, transport, tls.

   • Приемники для логов, которые будут поступать на сервер с клиентов.

   • Пути сообщений, связав определённые источники и приемники и при необходимости фильтры, анализаторы и модификаторы.

3. Перезапустить службу syslog-ng.

Пример настройки сервера:

source s_tls_source {
network( ip("0.0.0.0") port(6514) transport("tls")
tls(
   key-file("/etc/syslog-ng/key.d/serverkey.pem")
   cert-file("/etc/syslog-ng/key.d/servercert.pem")
   ca-dir("/etc/syslog-ng/ca.d")));
};

destination d_tls_kern { file("/var/log/hosts/$HOST/kern.log"); };

log {source(s_tls_source); filter(f_kern); destination(d_tls_kern); };

Настройка syslog-ng на клиентах

1. Создать сертификат и приватный ключ для клиента и настроить доверие к сертификату сервера.

2. Изменить конфигурационный файл /etc/syslog-ng/syslog-ng.conf – определить в нем:

   • Приемники для логов, передаваемых на сервер журналирования, используя драйвер network(), указав в нем значения параметров IP-адрес, port, transport, tls.

   • Указать путь сообщений, связав локальные источники с приемниками на сервере.

3. Перезапустить службу syslog-ng.

Пример настройки клиента:

destination d_tls_destination {

network ("<ip_адрес>" port(6514) transport("tls")

tls(
   key-file("/etc/syslog-ng/key.d/clientkey.pem")
   cert-file("/etc/syslog-ng/key.d/clientcert.pem")
   ca-dir("/etc/syslog-ng/ca.d"))); };

log { source(s_src); destination(d_tls_destination); };

Управление службой с помощью утилиты syslog-ng-ctl

Для управления syslog-ng может применяться утилита syslog-ng-ctl, основные команды которой:

• Команда syslog-ng-ctl stats – вывести статистику по использованию источников и приемников.

• Команда syslog-ng-ctl <verbose|trace|debug> – изменить режим логирования, например, чтобы включить режим отладки первого уровня необходимо выполнить команду: sudo syslog-ng-ctl debug --set=1

• Команда syslog-ng-ctl reload|stop – перезапустить или остановить службу.

• Команда syslog-ng -s – проверить синтаксис конфигурационных файлов.

Дополнительную информацию читайте в справке man syslog-ng и man syslog-ng-ctl.

Система журналирования systemd-journald

Служба systemd-journald входит в состав подсистемы инициализации systemd и журналирует:

• сообщения от ядра;

• сообщения, отправляемые с помощью стандартной библиотечной функции syslog();

• сообщения, отправляемые с помощью «родного» для systemd-journald API;

• сообщения из стандартных потоков вывода (stdout, stderr) служб, запускаемых с помощью systemd;

• сообщения из подсистемы аудита.

Настройка systemd-journald осуществляется через конфигурационный файл /etc/systemd/journald.conf и с помощью утилиты journalctl.

Если заглянуть в этот файл, то можно увидеть, что все параметры закомментированы, но следует обратить внимание на параметр Storage, который может иметь следующие значения:

• volatile – в файл /run/log/journal (временная память);

• persistent – в файл /var/log/journal (постоянная память);

• auto (по умолчанию) – если есть каталог /var/log/journal, то в нем, а если нет, то в /run/log/journal.

В Astra Linux параметр Storage не задан, поэтому по умолчанию предполагается auto, и каталог /run/log/journal не существует, поэтому система сохраняет файлы журналов только во временной памяти.

Для работы с systemd-journald используется утилита journalctl. Например, при вызове sudo journalctl без параметров будут выведены все сообщения системы:

localadmin@astra:~$ sudo journalctl | head -n 3
-- Logs begin at Mon 2023-09-25 08:48:40 MSK, end at Tue 2023-09-26 11:37:34 MSK. --
сен 25 08:48:40 astra kernel: Linux version 5.15.0-70-generic (builder@build5) (gcc (AstraLinuxSE 8.3.0-6) 8.3.0, GNU ld (GNU Binutils for AstraLinux) 2.31.1) #astra2 SMP Mon Apr 10 13:35:08 UTC 2023 (Astra 5.15.0-70.astra2-generic 5.15.92)
сен 25 08:48:40 astra kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-5.15.0-70-generic root=UUID=1864fbac-4e75-42ec-9a52-c0944d4fd6b9 ro parsec.mac=0 quiet net.ifnames=0
...

Некоторые полезные опции утилиты:

• Команда journalctl -f – просмотр событий в реальном времени (аналог tail -f <имя_журнала>).

• Команда journalctl -u <имя_юнита> – сообщения от определенного юнита systemd.

• Команда journalctl -k – сообщения от ядра.

• Команда journalctl -p <приоритет> – вывод сообщений только определённого приоритета (уровня критичности).

• Команда journalctl -n <число> – вывод последних n сообщений (аналог tail –n <число> <имя_журнала>)

• Команда journalctl <имя_поля=значение> – вывод сообщений с фильтрацией по значению полей. Чаще всего используют поля _UID, _PID и _SYSTEMD_UNIT.

• Команда journalctl -N – вывод списка полей, используемых в сообщениях.

• Команда journalctl -F <поле> – вывод списка возможных значений для указанного поля.

• Команда journalctl -o verbose — вывод сообщения в расширенном формате, т.е. кроме сообщения выводится список полей и их значений.

Пример поиска ошибок в логах с применением команды grep:

localadmin@astra:~$ sudo journalctl --since "1 hour ago" | grep err
[sudo] пароль для localadmin:
авг 07 17:34:07 astra spice-vdagent[2195]:    error message: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag
авг 07 17:34:07 astra spice-vdagent[2195]:    error message: Cannot invoke method; proxy is for a well-known name without an owner and proxy was constructed with the G_DBUS_PROXY_FLAGS_DO_NOT_AUTO_START flag

Для отправки сообщений в systemd-journald можно использовать утилиты systemd-cat и logger. С помощью опции -p можно задавать приоритет сообщения. Примеры использования:

localadmin@astra:~$ echo "Что-то пошло не так!" | sudo systemd-cat -p 3
localadmin@astra:~$ sudo journalctl -p 3 -n 1
-- Logs begin at Mon 2023-09-25 08:48:40 MSK, end at Tue 2023-09-26  12:01:54 MSK. --
сен 26 12:01:45 astra cat[8361]: Что-то пошло не так!

Настройка ротации журналов

Система ротации журналов logrotate позволяет очищать или архивировать файлы журналов по достижению определенных лимитов, например, по размеру или возрасту. По умолчанию утилита запускается ежедневно через планировщика заданий cron, см. файл /etc/cron.daily/logrotate.

Основной конфигурационный файл находится в /etc/logrotate.conf. Дополнительные файлы с суффиксом *.conf можно разместить в каталоге /etc/logrotate.d/.

Посмотрим настройки по умолчанию (основной файл конфигурации /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

# use date as a suffix of the rotated file
#dateext

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

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

# system-specific logs may be also be configured here.

Где:

• weekly – период ротации. Файлы журналов подвергаются ротации weekly, если текущий день недели меньше дня недели последней ротации или если со времени последней ротации прошло больше недели. Возможные значения weekly, daily, monthly, yearly.

• rotate <количество> – файлы журнала ротируются указанное количество раз перед тем, как будут удалены или отправлены на адрес, указанный в директиве mail. Если количество равно нулю, прежние версии удаляются, а не ротируются. Количество по умолчанию – 4.

• create <режим> <владелец> <группа> – сразу после ротации (до запуска сценария postrotate) создается файл журнала (с таким же именем, как у только что ротированного файла журнала). Назначение полей:

  • <режим> — определяет права доступа для файла журнала в восьмеричном представлении (как в утилите chmod).

  • <владелец> — определяет пользователя, который будет назначен владельцем файла.

  • <группа> — определяет группу, которая будет назначена владельцем файла. Если какое-то из полей не задано, будут использоваться параметры исходного файла журнала. Эта опция может быть отключена с помощью опции nocreate.

Дополнительно используются следующие директивы:

• compress – сжимать старые журналы.

• maxsize <размер> – ротация по размеру.

• maxage <количество_дней> – предписывает удалять журналы, у которых возраст старше указанного.

• postrotate <скрипт> – указывает, какой скрипт должен быть выполнен после ротации.

Графическая утилита «Системный журнал»

В Astra Linux доступна графическая утилита для просмотра журналов и событий «Системный журнал» (KSystemlog), см. рис. 149. Запустить ее можно из командной строки sudo ksystemlog или из меню Пуск ‣ Панель управления ‣ Безопасность ‣ Журнал аудита.

рис. 149 Окно утилиты «Системный журнал»

Утилита «Системный журнал» позволяет просматривать события из основных системных журналов, журнала ядра, аудита, графической подсистемы, служб systemd. В том числе вы можете расширять список источников. Работая с утилитой, вам доступен также поиск сообщений по заданным критериям.

Инструмент astra-create-debug-logs

В состав Astra Linux входит утилита astra-create-debug-logs, с помощью которой можно автоматически собрать архив с файлами журналов системных служб.

Запускать утилиту нужно от имени суперпользователя, файл будет создан в каталоге /tmp/.

localadmin@astra:~$ sudo astra-create-debug-logs
[sudo] пароль для localadmin:
cur_ilev=0   sysmaxilev=0
Создание архива с системными журналами и конфигурацией ОС ASTRALINUX 1-7-4 ..
Архив с системными журналами ASTRALINUX-1-7-4:
-rw-r--r-- 1 root root 5,3M авг  7 17:51 /tmp/astra-logs-1-7-4-07_08_2024-17_51_32.tar.xz

Сбор информации о работе ОС и ee производительности

Информацию о работе операционной системы и производительности отдельных ее компонентов можно получить множеством способов. Общую информацию об использовании ЦП, памяти, файла подкачки и сети можно посмотреть, например, с помощью графической утилиты «Системный монитор», см. рис. 150.

рис. 150 Окно программы «Системный монитор»

Однако для получения более детализированной информации необходимо использовать специальные утилиты, см. рис. 151.

рис. 151 Утилиты и источники информации для проверки и мониторинга подсистем Linux

Информация о процессах

Утилиты ps, top, htop служат для получения информации о процессах и потоках в системе. Работа с ними была рассмотрена в модуле, посвященном процессам.

Утилита vmstat (от англ. Virtual Machine Statistic) показывает информацию о процессах, памяти, страницах, I/O и о работе процессора. Пользователи vmstat могут указать интервал дискретизации, который дает возможность наблюдать работу системы в близком к реальному времени.

Информация о подсистеме хранения

Утилита iostat (от англ. I/O Statistic) входит в пакет sysstat и позволяет проанализировать загруженность системы. Она выводит основные параметры ввода/вывода данных, а также количество записанных или прочитанных данных. Кроме того, утилита выводит параметры загруженности процессора. Её можно использовать для оптимизации работы системы.

Утилита iotop (от англ. I/O Top) входит в пакет iotop и позволяет отслеживать в реальном времени загрузку дисковой подсистемы по процессам. Аналог top, но в разрезе нагрузки на дисковую подсистему.

Утилита lsof (от англ. LiSt of Open Files) позволяет просматривать информацию о том, какие процессы и пользователи открыли файл.

Системные вызовы

Утилита strace (от англ. System Trace) используется для мониторинга и влияния на взаимодействия между процессами и ядром Linux, включая системные вызовы, доставку сигналов и изменения состояния процесса. Утилита использует функции ядра ptrace, поэтому для ее использования нужно отключить блокировку этого механизма командой astra-ptrace-lock disable.

Утилита ltrace (от англ. Library Trace) просто запускает и исполняет указанную команду до завершения. Она перехватывает и записывает вызовы динамических библиотек, вызываемые исполняемым процессом, и сигналы, полученные этим процессом. Она также может перехватывать и выводить системные вызовы, выполняемые программой.

Утилита ldd (от англ. List Dynamic Dependencies) выдает список зависимостей от общих объектов (списка разделяемых библиотек, используемых исполняемыми файлами или разделяемыми библиотеками).

Утилита ftrace (от англ. Function Tracer) позволяет узнать, что происходит внутри ядра. Ее можно использовать для отладки или анализа задержек и проблемы с производительностью, возникающие за пределами пользовательского пространства.

Сеть и еще раз сеть

Утилита netstat (от англ. Network Statistic) входит в пакет net-tools и позволяет просматривать состояние TCP-соединений (как входящих, так и исходящих), таблицы маршрутизации, число сетевых интерфейсов и сетевую статистику по протоколам.

Утилита ss (от англ. Socket Statistic) входит в пакет iproute2. Она является аналогом утилиты netstat, но работает быстрее и проще в использовании. Она даёт более подробные сведения о TCP-подключениях и о состояниях соединений, чем большинство других инструментов.

Утилита route входит в пакет iproute2, позволяет работать с таблицами IP-маршрутизации.

Утилита iptables позволяет настраивать правила фильтрации IP-пакетов на низком уровне.

Служба ufw (от англ. Uncomplicated FireWall) – упрощенный файрвол, который позволяет изменять настройки межсетевого экрана.

Утилита tcpdump позволяет захватывать сетевой трафик с учетом фильтров. Вывод может быть направлен как в файл, так и на стандартный вывод. Это наиболее часто используемый инструмент для устранения неполадок, связанных с работой сетевых приложений.

Приложение wireshark — это очень популярный инструмент для захвата и анализа сетевого трафика. Приложение поддерживает парсинг не только протоколов TCP/ IP, но и большинства протоколов прикладного уровня, включая DNS, NTP, HTTP, LDAP, Kerberos и др. А для возможности парсинга TLS-трафика вы можете предоставить приложению доступ к файлу с сессионными ключами.

Внимание

Подавляющее большинство проблем в домене возникает между компонентами, которые взаимодействуют друг с другом по сети, поэтому инструменты из этого раздела и конкретно Wireshark, если не серебряная пуля, то уж точно хлеб с маслом для каждого доменного администратора!

Универсальные программы и наборы утилит

Когда вы освоитесь с базовыми инструментами, можно будет посмотреть на универсальные программы сбора статистики и анализа производительности.

Утилита perf (от англ. Performance) является инструментом для сбора статистики и анализа производительности. Счетчики производительности для Linux — это подсистема на базе ядра, которая закладывает основу для анализа производительности. Она охватывает функции аппаратного уровня (CPU/PMU, блок мониторинга производительности), а также функции программного обеспечения (программные счетчики, точки трассировки).

Для использования необходимо установить пакет linux-tools-common и возможно специализированный пакет для текущей версии ядра linux-tools-<версия ядра>.

Документация: https://perf.wiki.kernel.org/index.php/Main_Page.

Утилита stap (от англ. System Tap) позволяет собирать и анализировать информацию о работающей Linux системе. В отличие от встроенных средств, таких как netstat, ps и top, это приложение было разработано с целью предоставить больше возможностей для сбора и предоставления информации.

Утилита представляет собой интерфейс командной строки и скриптовый язык программирования. Системные администраторы могут использовать SystemTap для мониторинга и анализа производительности системы, а разработчики программного обеспечения могут использовать SystemTap для анализа поведения приложения в работающей системе.

Документация доступна по ссылке http://sourceware.org/systemtap/.

Dtrace – это инструмент для динамической трассировки ядра системы и приложений в реальном времени, главным образом, с целью их профайлинга и отладки.

eBPF (от англ. Enhanced Berkeley Packet Filter) – это механизм ядра, предоставляющий возможности трассировки и профайлинга как самого ядра, так и пользовательских приложений. Разработан как портированная и расширенная версия BPF (фильтр, умеющий, например, фильтровать пакеты для libpcap / tcpdump прямо в ядре).

Для использования необходимо установить пакет bpftrace.

Документация: https://github.com/iovisor/bpftrace.

Bpftrace (от англ. Berkeley Packet Filter Trace) — это инструмент, аналогичный DTrace, реализованный поверх eBPF. Считается стабильным, быстрым и пригодным для запуска в боевом окружении.

bcc (от англ. BPF Compiler Collection) – набор инструментов для создания программ, использующих возможности eBPF. При написании кода с использованием bcc в качестве языка программирования используется смесь Python и C. Также в bcc входит большой набор готовых утилит для профайлинга программ и мониторинга системы.

В состав bcc входят более 100 инструментов. Из них можно выделить следующие инструменты, полезные для администрирования:

• Утилита bashreadline — вывод введенных команд bash для всей ОС (во всех сеансах).

• Утилита biotop — top для дисков: итоговый ввод-вывод блочных устройств по процессам.

• Утилита biosnoop — отслеживание блокировок устройств ввода-вывода с помощью PID и задержек.

• Утилита dirtop — top для каталогов: операции чтения и записи по каталогам.

• Утилита execsnoop — отслеживание новых процессов с помощью системных вызовов exec().

• Утилита exitsnoop — отслеживание завершения процесса (сигналы выхода и сигналы о фатальных ошибках).

• Утилита ext4dist — итоговое распределение задержек операций ext4 в виде гистограммы.

• Утилита ext4slower — отслеживание медленных операций ext4.

• Утилита filetop — top для файлов: операции чтения и записи по файлам.

• Утилита mountsnoop — отслеживание системных вызовов монтирования и размонтирования по всей системе.

• Утилита oomkill — отследить убийцу процесса, чье убийство вызвано нехваткой памяти (OOM).

• Утилита tcptracer — отслеживание установленных TCP-соединений (connect(), Accept(), close()).

Для использования необходимо установить пакеты: bpfcc-tools, libbpfcc и libbpfcc-dev

Документация: https://github.com/iovisor/bcc.

Пакет sysstat (от англ. System Statistic) — это набор системных утилит для контроля производительности активности использования операционной системы Linux и её подсистем. С помощью приложений можно получить информацию о системе, скорости операций ввода-вывода, использовании центрального процессора, памяти, подкачки, прерываний, сети, tty и о многом другом.

В состав пакета входят следующие утилиты:

• Утилита iostat — сообщает статистику ЦП и статистику ввода/вывода для блочных устройств.

• Утилита mpstat — сообщает статистику по отдельному или объединенному процессору.

• Утилита pidstat — сообщает статистику по задачам (процессам) Linux: ввод-вывод, процессор, память и т. д.

• Утилита cifsiostat — сообщает статистику CIFS.

Вы можете также запланировать выполнение некоторых утилит через cron или systemd для сбора данных о производительности в фоновом режиме:

• Утилита sar — собирает и хранит информацию о деятельности системы (см. ниже список показателей, собираемых sar).

• Утилита sadc — это сборщик данных о деятельности системы, используемый в качестве бэкенда для sar.

• Утилита sa1 — собирает и сохраняет двоичные данные в файле ежедневных данных о деятельности системы. Это интерфейс sadc, предназначенный для запуска из cron или systemd.

• Утилита sa2 — пишет сводный ежедневный отчет о деятельности. Это интерфейс sar, предназначенный для запуска из cron или systemd.

• Утилита sadf — отображает данные, собранные sar, в нескольких форматах (CSV, XML, JSON и т. д.) и может использоваться для обмена данными с другими программами. Эту команду также можно использовать для рисования графиков различных действий, собранных sar, в формате SVG (масштабируемая векторная графика).

Интервал выборки по умолчанию составляет 10 минут, но его, конечно, можно изменить (он может составлять всего 1 секунду).

Документация: https://github.com/sysstat/sysstat.

Поиск и устранение неисправностей

Термин «баг» вошел в инженерный жаргон еще во времена Эдисона, что было задолго до первых компьютеров, и означал небольшие неисправности в работе оборудования, а ремонтников называли соответственно «багхантерами». Очевидно, что термин перекочевал и к инженерам-программистам, поэтому, когда в компьютере Mark II была обнаружена проблема из-за мотылька, застрявшего в реле, эту историю в шутку назвали «первым случаем обнаружения реального бага».

Но как бы не назывался процесс устранения неисправностей — отладка или дебаггинг — он был, есть и остается крайне важным элементом обеспечения надежной работы технических систем.

Подходы к выполнению отладки

Как в программировании вычислительная сложность алгоритмов может отличаться в несколько раз, так при выполнении отладки вы можете использовать определенные подходы, которые значительно повысят ваши шансы на успех и сократят общее время решения проблемы. Сами по себе эти рекомендации не принесут вам удачи, но чем больше вы будете тренироваться в их использовании, тем чаще вам будет везти.

Воспроизведите ошибку

Как ни странно, но первый шаг на пути решения любой технической проблемы – это способность воспроизвести ее, то есть воссоздать условия, в которых эта ошибка возникает.

В первую очередь вам нужно понять, какие именно настройки или действия приводят к появлению ошибки, так как наблюдение за «жуком» в его естественной среде обитания даст возможность локализовать проблему, изменяя внешние условия ее воспроизведения. Это так называемый «динамический анализ».

Именно поэтому многие службы технической поддержки делают обязательным поле «Шаги по воспроизведению» при подаче заявки, но, как говорится, у правильной девушки в сумочке всегда должен быть загранпаспорт, купальник, фата и… губозакаточная машинка.

Локализуйте ошибку

Если вы научились воспроизводить ошибку, то вам нужно понять, в какой части системы она возникает. Наиболее популярной стратегией при этом, к сожалению, является метод «перебора», он же «грубой силы» или «метод тыка», так как он не требует глубоких познаний о работе системы. Как говорится: «Что тут думать? Прыгать надо!». Но журналов в системе слишком много, поэтому мы настоятельно рекомендуем хотя бы проанализировать процесс обработки данных, в рамках которого возникает ошибка, чтобы сократить круг подозреваемых.

Однако более эффективной стратегией является применение бинарного поиска при локализации ошибки — да, да, это про быстрый поиск по сортированному массиву данных, который имеет сложность O (log(n)). Если проанализировать любую ИТ-технологию, то это всегда окажется последовательный процесс обработки данных компонентами системы A->B->C->D->E->F->G, поэтому вы можете поделить эту цепочку пополам и внимательно проанализировать компонент D, который находится посередине. Если вы обнаружите, что до этого компонента данные успешно доходят, то можно будет отбросить первую половину цепочки и сконцентрироваться на изучении компонентов E-F-G, применяя тот же подход еще раз, а затем еще раз и еще. Но чем длиннее будет эта цепочка, тем больше времени вам сэкономит бинарный поиск.

Приведем еще один пример, в котором вы можете применить бинарный поиск. Допустим, у вас есть некоторая служба, которая не стартует, когда вы запускаете ее с определенным набором из 50 параметров в конфигурационном файле. В этом случае вы можете очень долго проверять каждый параметр по одному, а можете удалить вторую половину списка, а потом еще половину и… О, вы схватываете на лету!

Определите первопричину и устраните ее

А вот теперь наступает самый интересный этап решения проблем: вам нужно определить, что является первопричиной проблемы и как ее можно устранить.

Тут вам потребуется глубоко погрузиться в логику работы приложения, что делают найденные вами параметры и как они влияют на работу компонентов системы. Возможно, потребуется провести серию экспериментов, используя разные значения параметров. Ну и, конечно же, не забываем про «О’кей Гугл, где мои штаны!». Хотя сейчас популярнее уже Chat GPT, но с этим ИИ нужно быть построже, чтобы не купиться на восемь ног у лошади и не довести дело до «мне нужна твоя одежда, сапоги и мотоцикл» )))

Зафиксируйте ваши находки в документах

В завершение поговорим о том, что мы так часто забываем: обязательно задокументируйте ваши изыскания, чтобы упростить работу себе и своим коллегам в будущем.

Не поленитесь оставить подробный комментарий непосредственно в конфигурационном файле, в системе отслеживания изменений, а если у вас все по ITIL, то и в системе управления изменениями.

Делайте так, даже если вам кажется, что это была простая проблема, а то ежу, может быть, и понятно, но у него слишком высокий IQ.

Неисправности, возникающие на начальных стадиях загрузки

К неисправностям, возникающим на начальных стадиях загрузки, можно отнести повреждение загрузочного сектора, файлов загрузчика или недостаток места. Рассмотрим эти проблемы и способы их решения на примере виртуальной машины, загрузка которой выполняется по сценарию BIOS->MBR.

Создание резервной копии таблицы разделов

С помощью утилиты fdisk мы можем создать резервную копию разделов. Для этого необходимо запустить утилиту, указав необходимое устройство, выбрать пункт «записать разметку в файл сценария sfdisk», ввести команду «O» и указать имя файла sda.bkp:

localadmin@astra:~$ sudo fdisk /dev/sda
Добро пожаловать в fdisk (util-linux 2.33.1).
Изменения останутся только в памяти до тех пор, пока вы не
решите записать их. Будьте внимательны, используя команду write.

Команда (m для справки): O

Введите имя файла скрипта: sda.bkp

Сценарий записан успешно.

Команда (m для справки): q

localadmin@astra:~$ ls -l sda.bkp
-rw-r--r-- 1 root root 250 сен 26 21:35 sda.bkp

Запишем этот файл на другой диск (на один из тех, что были созданы в процессе изучения модуля про работу с файловыми системами и работе с блочными устройствами):

localadmin@astra:~$ sudo mount /dev/sdb2 /mnt/data
localadmin@astra:~$ sudo cp sda.bkp /mnt/data/
localadmin@astra:~$ ls /mnt/data
lost+found sda.bkp test.txt

Создание резервной копии загрузочного сектора

Мы можем восстановить загрузочный сектор путем повторной установки GRUB, а можем просто скопировать первый сектор размером 512 байт. Примонтируем диск и скопируем на него данные начальной области диска, используя утилиту dd:

localadmin@astra:~$ sudo mount /dev/sdb2 /mnt/data
localadmin@astra:~$ sudo dd if=/dev/sda of=/mnt/data/sda_boot.dd.bkp bs=512 count=4
4+0 записей получено
4+0 записей отправлено
2048 байт (2,0 kB, 2,0 KiB) скопирован, 0,000500627 s, 4,1 MB/s
localadmin@astra:~$ ls /mnt/data
lost+found sda.bkp sda_boot.dd.bkp test.txt

Создание загрузочного диска

Если политика безопасности компании позволяет, то вы можете воспользоваться готовым образом LiveCD, например, от gparted https://gparted.org/livecd.php. В противном случае вам нужно будет создать загрузочный образ самостоятельно, например, используя ALP-live.

ALP-live (Astra Linux Portable) — это образ операционной системы, предназначенный для работы сразу после загрузки со съемного носителя (СD, DVD, USB-Flash) без установки на жесткий диск. В статьях на wiki.astralinux.ru подробно рассказывается о том, как создать загрузочную USB-флешку, ссылки на статьи:

• Создание собственных ALP-live образов (Live-CD/Live-USB) в Astra Linux

• Создание загрузочных носителей USB flash drive

Создадим образ ALP-live, добавив в него пакет testdisk с одноименной утилитой, с помощью которой можно восстановить поврежденную таблицу разделов на диске. Перед созданием образа необходимо подключить новый диск размером не менее 20 ГБ, так как на дисках, подключённых к виртуальной машине, не хватит места для его размещения.

localadmin@astra:~$ sudo lsblk /dev/sdf
[sudo] пароль для localadmin:
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sdf   8:80  0  20G  0 disk
localadmin@astra:~$ sudo fdisk /dev/sdf
Добро пожаловать в fdisk (util-linux 2.33.1).
Изменения останутся только в памяти до тех пор, пока вы не решите записать их.
Будьте внимательны, используя команду write.
Устройство не содержит стандартной таблицы разделов.
Создана новая метка DOS с идентификатором 0x30b1441c.
Команда (m для справки): g
Created a new GPT disklabel (GUID: 6B5EF8A8-EC37-BB4C-90A8-637820464532).
Команда (m для справки): n
Номер раздела (1-128, default 1): <enter>
Первый сектор (2048-41943006, default 2048): <enter>
Last sector, +/-sectors or +/-size{K,M,G,T,P} (2048-41943006, default 41943006): <enter>
Создан новый раздел 1 с типом 'Linux filesystem' и размером 20 GiB.
Команда (m для справки): w
Таблица разделов была изменена.
Вызывается ioctl() для перечитывания таблицы разделов. Синхронизируются диски.
localadmin@astra:~$ sudo mkfs /dev/sdf1
mke2fs 1.44.5 (15-Dec-2018)
Creating filesystem with 5242619 4k blocks and 1310720 inodes
Filesystem UUID: 010804eb-fe4a-44e8-86d9-a77e21a0973e
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208, 4096000
Allocating group tables: done
Writing inode tables: done
Writing superblocks and filesystem accounting information: done

Смонтируем новый раздел в /opt, так как именно там будет создаваться Live_CD:

localadmin@astra:~$ sudo mount /dev/sdf1 /opt
localadmin@astra:~$ df
Файловая система 1K-блоков Использовано Доступно Использовано% Cмонтировано в
udev                960260            0   960260            0% /dev
tmpfs               202552         5900   196652            3% /run
/dev/sda1         15421320     11601024  3015128           80% /
tmpfs              1012740           12  1012728            1% /dev/shm
tmpfs                 5120            4     5116            1% /run/lock
/dev/sdb1           485348           14   455638            1% /var/log/myservicelog
/dev/sdf1         20596416           24 19547872            1% /opt

Установим пакет live-build-astra командой:

localadmin@astra:~$ sudo apt install live-build-astra

Добавим «testdisk» в конфигурационный файл /usr/share/live-build-astra/customyze/astra_extend.list для включения этого пакета в образ:

localadmin@astra:~$ sudo vim /usr/share/live-build-astra/customyze/astra_extend.list
localadmin@astra:~$ cat /usr/share/live-build-astra/customyze/astra_extend.list
linux-astra-modules-5.4
linux-astra-modules-5.10
testdisk

Соберем образ командой sudo live-build-astra. Эта операция займет некоторое время.

localadmin@astra:~$ sudo live-build-astra
...
итого 3312804
-rw-r--r-- 1 root root 3388997632 сен 27 05:05 1.7_x86-64-1.7.0-27.09.2023_05.04.livecd.iso

Скопируем созданный образ с виртуальной машины на хостовую. В случае с VirtualBox это можно сделать через общую папку (доступна в настройках виртуальной машины).

Вызов нештатной ситуации в демонстрационных целях

Предупреждение

Если вы хотите повторить эксперименты, предложенные далее, то настоятельно рекомендуем перед этим сделать снимок состояния виртуальной машины.

Для демонстрации намеренно испортим загрузочный сектор. Для этого запишем нули в первые 512 байт на диске с помощью команды:

localadmin@astra:~$ sudo dd if=/dev/zero of=/dev/sda bs=512 count=1
1+0 записей получено
1+0 записей отправлено
512 байт скопировано, 0,000190076 s, 2,7 MB/s

Теперь перезагрузим машину, чтобы зафиксировать ошибку No bootable medium found! Как вы заметили, мы столкнулись с нештатной ситуацией: система не может быть загружена, так как не видит загрузочный диск.

рис. 152 Ошибка No bootable medium found

Восстановление таблицы разделов из резервной копии

Для восстановления поврежденной таблицы разделов необходимо выполнить ряд шагов:

1. Загрузимся в режиме восстановления. Для этого подключим к компьютеру установочный диск и выберем пункт «Режим восстановления»

2. Согласимся с принятием лицензии.

3. Выберем настройки клавиатуры.

4. Необходимо подождать некоторое время, пока прогрузятся необходимые компоненты.

5. Далее настроим сеть.

6. Настроим время.

7. Запустим оболочку без монтирования ФС. В следующем диалоге необходимо выбрать пункт «Не использовать файловую систему», так как нам необходимо исправить ошибки разметки дисков.

8. И выберем «Запуск оболочки в рабочей среде программы установки».

9. Соглашаемся с предупреждением об отказе от монтирования файловых систем.

10. Примонтируем устройство с резервной копией:

    В нашем случае файл с резервной копией находится на жестком диске, подключенном к компьютеру, поэтому дополнительных действий не требуется. Если бы он находился на внешнем носителе информации, то его необходимо было бы подключить к компьютеру.

    В консоли введем команды для создания каталога /mnt/data и примонтируем в него диск:

~ # mkdir /mnt/data
~ # mount /dev/sdb2 /mnt/data

11. Восстановим таблицу разделов из резервной копии:

• Введем команду fdisk /dev/sda.

• Выберем пункт «загрузить разметку из файла сценария sfdisk», введя I, укажем файл /mnt/data/sda.bkp и запишем изменения, введя w.

12. Примонтируем раздел /dev/sda и проверим его содержимое.

Команды для ввода:

~ # fdisk -l /dev/sda
~ # mkdir /mnt/sda
~ # mount /dev/sda1 /mnt/sda
~ # ls /mnt/sda

13. Запишем загрузочный сектор GRUB в MBR-запись, для этого выйдем из консоли командой exit и выберем другую ФС.

14. Выберем /dev/sda1 и затем пункт «Переустановка системного загрузчика GRUB».

15. Переустановим его в главную загрузочную область устройства /dev/sda.

16. Перезагрузим компьютер.

17. Как видите, работа компьютера успешно восстановлена!

Восстановление загрузочной области диска из сохраненной копии

Первые шаги до 10-го пункта включительно аналогичны действиям из предыдущего раздела по восстановлению таблицы разделов из резервной копии. Поэтому продолжим с 11го шага.

11. Восстановим начальную область диска из резервной копии командой:

    ~ # dd if=/mnt/data/sda_boot.dd.bkp of=/dev/sda
    ~ # fdisk -l /dev/sda
    

    

    Как видите, разделы снова нам видны. В этом случае нам не требуется отдельно переустанавливать загрузчик GRUB в MBR – он был восстановлен.

12. Перезагрузим компьютер exit и в пункте меню перезапустить.

13. Как видите, работа компьютера снова успешно восстановлена!

Восстановление таблицы разделов с помощью утилиты testdisk

Для восстановления работоспособности этим способом:

1. Загрузим образ ALP-live с подготовленной ранее USB-флешки.

   • Подключим к системе созданную ранее загрузочную флешку.

   • Загрузим компьютер, выбрав один из доступных вариантов ядра.

     

   • Войдем в систему с пустым паролем и откроем терминал горячим сочетанием клавиш Alt + t. Утилите testdisk необходимо минимум 24 строки для нормальной работы, поэтому откройте окно во весь экран.

2. Используя утилиту testdisk, восстановим таблицу разделов:

   Запустим утилиту sudo testdisk /dev/sda, где /dev/sda – устройство с поврежденной таблицей разделов, и подтвердим выбор устройства.

3. Выберем тип разделов. В нашем случае это Intel (MBR), однако это может быть и EFI GPT, если разметка у диска была GPT.

4. Далее выберем первый пункт – Analyse.

5. Подтвердим «быстрый поиск» (англ. Quick Search).

6. Ознакомимся с результатами поиска.

   

7. При необходимости воспользуемся «глубоким поиском».

Процесс займет какое-то время:

8. После того, как мы убедились, что разделы были найдены, можно записать таблицу разделов на диск командой «Write». Подтвердим запись с помощью «Y».

9. Перезагружать систему не будем, выйдем из утилиты сочетанием Ctrl + с.

   

10. Проверим разделы на /dev/sda.

Как видите, утилита не совсем верно восстановила разделы, так как их было три, а стало два. Раздел 2 был расширенным и включал раздел подкачки. Однако это не должно помешать загрузке с раздела /dev/sda1. Осталось восстановить загрузчик в главной загрузочной области.

11. Восстановим загрузчик в главной загрузочной области.

Для восстановления загрузчика необходимо выполнить два действия. Во-первых, перемонтировать раздел с загрузчиком, а затем установить загрузчик, указав корень ФС и устройство:

astra-live@Live-Astra:~$ sudo grub-install --root-directory=/mnt/ dev/sda

12. Извлечем загрузочную флешку и перезагрузим компьютер.

13. И снова удача! Говорят, что удача, как женщина: если за ней не бегать, то она обидится и сама придёт, чтобы все высказать.

Повреждение файлов загрузчика

При повреждении файлов загрузчика GRUB или файлов из каталога /boot для восстановления работоспособности можно воспользоваться одной из следующих процедур.

Восстановление GRUB

Для восстановления загрузчика необходимо:

1. Загрузиться в режиме восстановления с установочного диска.

2. Запустить оболочку в разделе установки системы.

   

3. Перейти в консоль tty, например, горячим сочетанием клавиш:

   Ctrl + Alt + F2

4. Смонтировать корневую ФС в /target, выполнив команду:

   ~ # chroot /target
   

5. Используя пакетный менеджер, проверить версию GRUB: grup-pc (Legacy) или grub-efi-amd64 (EFI). При необходимости заменить пакет на подходящий.

   sh-5.0# apt list | grep grub
   

   

6. Переустановить GRUB командой:

   sh-5.0# grub-install /dev/sda
   

   

7. Пересоздать конфигурационный файл GRUB командой:

   sh-5.0# update-grub
   

   

8. Перезагрузить компьютер. Работоспособность GRUB восстановлена!

   

С дополнительными рекомендациями по замене таблицы разделов с MBR на GPT можно ознакомиться в статье Установка загрузчика GRUB2 в UEFI GPT

Пересоздание образа initrd

При повреждении образа initrd его можно легко восстановить. Для этого необходимо:

1. Загрузиться в режиме восстановления с установочного диска.

2. Запустить оболочку в разделе установки системы.

3. В консоли выполнить команду:

root@astra:/# update-initramfs -u

Если необходимо пересоздать образ для определенной версии ядра, то нужно добавить ключ -k и указать версию, например:

root@astra:/# update-initramfs -u -k 5.15.0-70-generic

4. Перезагрузить компьютер. Работоспособность восстановлена!

Если для пересоздания образа Initrd в каталоге /boot не хватает места, то вы можете загрузиться в режиме восстановления и выполнить следующие действия:

• Удалить неиспользуемые данные, например, старые версии ядра или версии

localadmin@astra:~$ ls /boot
config-5.15.0-33-generic initrd.img-5.15.0-33-generic System.map-5.15.0-33-generic
config-5.15.0-70-generic initrd.img-5.15.0-70-generic System.map-5.15.0-70-generic
grub old-vmlinuz-5.15.0-33-generic vmlinuz-5.15.0-70-generic

• Смонтировать временную ФС в /boot, пересоздать образ Initrd и заменить его в оригинальном каталоге /boot

  1. Смонтируйте временную ФС mount -t tmpfs none /boot.

  2. Создайте образ Initrd для требуемой версии ядра, например:

     root@astra:~# update-initramfs -u -k 5.15.0-70-generic
     

  3. Сохраните созданный образ (при размонтировании временной ФС все её содержимое будет удалено).

     root@astra:~# cp -r /boot/initrd.img-5.15.0-70-generic /home
     

  4. Размонтируйте временную ФС.

     root@astra:~# umount /boot
     

  5. Замените старый образ на новый.

     root@astra:~# cp -r /home/initrd.img-5.15.0-70-generic /boot/
     

  6. Обновите конфигурацию загрузчика GRUB

     root@astra:~# update-grub
     

  7. Перезагрузите систему.

Проверка файловой системы на ошибки

Некоторые ошибки в работе диска можно исправить с помощью следующих утилит:

• fsck – утилита для проверки и восстановления файловой системы;

• badblocks – утилита для выявления сбойных блоков.

Утилита badblocks

Использование утилиты badblocks может выполняться в разных режимах:

• Режим по умолчанию. В этом режиме утилита проверяет чтение/запись блоков данных на устройстве без повреждения текущих данных. Для использования этого режима файловая система должна быть размонтирована

localadmin@astra:~$ sudo badblocks -v /dev/sda -o ~/bad_sectors.txt
Checking blocks 0 to 16777215
Checking for bad blocks (read-only test):
done
Pass completed, 0 bad blocks found. (0/0/0 errors)

• Если мы хотим выполнить проверку на смонтированной ФС, это возможно только в режиме чтения блоков, например:

localadmin@astra:~$ sudo badblocks -vn /dev/sdb2 -o ~/bad_sectors.txt
Checking for bad blocks in non-destructive read-write mode
From block 0 to 301055
Testing with random pattern: Pass completed, 0 bad blocks found. (0/0/0 errors)

• Если необходимо выполнить проверку с реальной записью данных на диск, то необходимо использовать ключ -w.

Предупреждение

Использование ключа -w приведет к уничтожению имеющихся данных на устройстве – будьте осторожны!

Результаты утилиты badblocks могут быть переданы утилите fsck, чтобы сообщить файловой системе о сбойных блоках и исключить их из использования, например, командой:

localadmin@astra:~$ sudo fsck -l ~/bad_sectors.txt /dev/sdb2

С другими опциями вы можете ознакомиться в справке man badblocks.

Утилита fsck

Для проверки диска утилитой fsck это устройство не должно быть смонтировано.

localadmin@astra:~$ sudo fsck /dev/sdb2
fsck из util-linux 2.33.1
e2fsck 1.44.5 (15-Dec-2018)
/dev/sdb2: clean, 14/75480 files, 15696/301056 blocks

Пример использования для смонтированного устройства:

localadmin@astra:~$ sudo fsck /dev/sdb1
fsck из util-linux 2.33.1  e2fsck 1.44.5 (15-Dec-2018)
Logs: clean, 11/128016 files, 26666/512000 blocks
localadmin@astra:~$ sudo mount /dev/sdb1

С другими опциями вы можете ознакомиться в справке man fsck.

Неисправности, возникающие на финальных стадиях загрузки

После загрузки системы проблем может быть тоже предостаточно, но вспомним анекдот и рассмотрим те, что связаны с паролями:

Сидят два админа на работе, грустят, заходит третий и спрашивает:

—Че такие грустные?

— Да вчера пиво пили… и пароли меняли…

Обнуление счётчика неудачных попыток ввода пароля

Если было превышено максимальное количество попыток ввода пароля, но пароль не утерян, то можно обнулить этот счетчик, но вам потребуется пароль от GRUB. Для этого необходимо:

1. Перезагрузить компьютер и при появлении меню загрузчика войти в режим редактирования нажатием клавиши e.

2. Вывести имя пользователя и пароль от GRUB.

   

3. В интерфейсе редактирования изменить строку, начинающуюся со слова linux:

   • удалить «ro» и «quite».

   • добавить в конец строки init=/bin/bash/.

   

4. Выполнить загрузку нажатием клавиши: F10. Дождаться загрузки и появления приглашения командной строки.

5. В случае, если ФС доступна только на чтение, выполнить ее перемонтирование командой:

   root@(none):/# mount -o rw,remount /
   

   

6. Сбросить счетчик неудачных попыток ввода пароля командой:

   root@(none):/# faillog –r
   

   

7. Перезагрузить компьютер и войти в систему под своими учетными данными.

Сброс пароля учетной записи администратора

Все мы помним, что обычному пользователю пароль можно сбросить командой passwd, но что делать, если вам требуется восстановить пароль от администратора? Для этого нужно:

1. Загрузиться в режиме восстановления с установочного диска.

2. Запустить оболочку в разделе установки системы (например, /dev/sda1).

3. Перейти в консоль tty, например, горячим сочетанием клавиш:

   Ctrl + Alt + F2

4. Смонтировать корневую ФС в /target, выполнив команду:

~ # chroot /target

5. С помощью текстового редактора удалить хеш пароля в файлах /etc/shadow, /etc/shadow-.

6. Перезагрузить машину и выполнить вход без пароля с последующей его установкой.

Практика и тестирование

Пришло время проверить себя пройти материал на практике и ответить на тестовые вопросы

• Практическая работа: Модуль 21. Файловая система в Linux. Работа с блочными устройствами и LVM
• Тест: Модуль 21. Работа с журналами и анализ производительности. Отладка при нештатных ситуациях.

Заключение

Мы заканчиваем курс молодого бойца по общим вопросам администрирования Linux, так как считаем такой объем уже достаточным для освоения доменных технологий.

Далее мы перейдем к изучению централизованной системы управления ИТ-инфраструктурой ALD Pro, рассмотрим ее устройство и принцип работы отдельных компонентов технологического стека, основными из которых являются: служба каталога FreeIPA, агентская часть доменного компьютера SSSD, групповые политики на базе системы управления конфигурациями SaltStack.

Дополнительные источники информации

• Журналы работы системных служб

• LiveCD от gparted

• Создание собственных ALP-live образов (Live-CD/Live-USB) в Astra Linux

• Создание загрузочных носителей USB flash drive