One place for hosting & domains

      журналов

      Использование Journalctl для просмотра журналов Systemd и выполнения операций с ними


      Введение

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

      Журнальная система реализована в форме демона journald, который обрабатывает все сообщения ядра, initrd, служб и т. д. В этом учебном руководстве мы покажем, как использовать утилиту journalctl для доступа данными в журнале и управления этими данными.

      Общая идея

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

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

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

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

      Настройка времени системы

      Одно из преимуществ использования двоичного журнала заключается в возможности просмотра записей журнала как с локальным временем, так и с временем по Гринвичу (UTC). По умолчанию systemd использует для отображения результатов локальное время.

      В связи с этим, прежде чем мы начнем работу с журналом, нам нужно будет убедиться, что часовой пояс настроен правильно. Пакет systemd включает инструмент timedatectl, который может помочь с этой задачей.

      Прежде всего, нужно использовать опцию list-timezones для просмотра доступных часовых поясов:

      timedatectl list-timezones

      Эта опция выводит список часовых поясов, доступных в вашей системе. Когда вы найдете часовой пояс, соответствующий расположению вашего сервера, вы сможете установить его с помощью опцииset-timezone:

      sudo timedatectl set-timezone zone

      Чтобы убедиться, что ваша система использует правильное время, воспользуйтесь командой timedatectl без опций или с опцией status. Изображение на экране будет таким же:

      timedatectl status

            Local time: Thu 2015-02-05 14:08:06 EST
  Universal time: Thu 2015-02-05 19:08:06 UTC
        RTC time: Thu 2015-02-05 19:08:06
       Time zone: America/New_York (EST, -0500)
     NTP enabled: no
NTP synchronized: no
 RTC in local TZ: no
      DST active: n/a

      В первой строке должно отображаться правильное время.

      Основы просмотра журнала

      Чтобы просмотреть журналы, собранные демоном journald, используйте команду journalctl.

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

      journalctl

      -- Logs begin at Tue 2015-02-03 21:48:52 UTC, end at Tue 2015-02-03 22:29:38 UTC. --
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journal[243]: Runtime journal is using 6.2M (max allowed 49.
Feb 03 21:48:52 localhost.localdomain systemd-journald[139]: Received SIGTERM from PID 1 (systemd).
Feb 03 21:48:52 localhost.localdomain kernel: audit: type=1404 audit(1423000132.274:2): enforcing=1 old_en
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: SELinux: 2048 avtab hash slots, 104131 rules.
Feb 03 21:48:52 localhost.localdomain kernel: input: ImExPS/2 Generic Explorer Mouse as /devices/platform/
Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  8 users, 102 roles, 4976 types, 294 bools, 1 sens,
Feb 03 21:48:52 localhost.localdomain kernel: SELinux:  83 classes, 104131 rules

. . .

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

      Данный формат будет знаком тем, кто привык к стандартным журналам syslog. Однако при этом способе данные собираются из большего числа источников, чем поддерживают стандартные приложения syslog. Журнальная система поддерживает журналы процесса начальной загрузки, ядра, initrd, стандартные журналы ошибок и вывода приложений и т. д.

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

      Если вы хотите вывести временные метки в формате UTC, вы можете использовать флаг --utc:

      journalctl --utc

      Фильтрация журнала по времени

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

      Вывод журналов текущей загрузки

      Флаг -b — одна из самых простых опций, которой вы часто будете пользоваться. С его помощью вы сможете вывести для просмотра все записи журнала, собранные с момента последней перезагрузки.

      journalctl -b

      Это поможет вам определять, какая информация важна для текущей среды, и управлять этой информацией.

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

      . . .

-- Reboot --

. . .

      Ее можно использовать в качестве логического разделителя информации между сеансами загрузки.

      Прошлые загрузки

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

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

      • sudo mkdir -p /var/log/journal

      Также вы можете отредактировать файл конфигурации журнальной системы:

      • sudo nano /etc/systemd/journald.conf

      В разделе [Journal] установите для опции Storage= значение persistent, чтобы включить постоянное хранение журналов:

      /etc/systemd/journald.conf

      . . .
[Journal]
Storage=persistent

      Если на вашем сервере включено хранение журналов предыдущих сеансов загрузки, утилита journalctl предоставит ряд команд, которые помогут работать с сеансами загрузки как с единицами хранения. Чтобы просмотреть сеансы загрузки, о которых известно journald, используйте опцию --list-boots с командой journalctl:

      journalctl --list-boots

      -2 caf0524a1d394ce0bdbcff75b94444fe Tue 2015-02-03 21:48:52 UTC—Tue 2015-02-03 22:17:00 UTC
-1 13883d180dc0420db0abcb5fa26d6198 Tue 2015-02-03 22:17:03 UTC—Tue 2015-02-03 22:19:08 UTC
 0 bed718b17a73415fade0e4e7f4bea609 Tue 2015-02-03 22:19:12 UTC—Tue 2015-02-03 23:01:01 UTC

      С этой опцией команда будет выводить по одной строке для каждого сеанса загрузки. Первый столбец — это относительный идентификатор сеанса загрузки, который удобно использовать для ссылки на сеанс загрузки с помощью journalctl. Если вам требуется абсолютный идентификатор, используйте значение boot ID во втором столбце. Два поля времени ближе к концу строки позволяют определить время сеанса загрузки.

      Чтобы вывести информацию из этих сеансов загрузки, вы можете использовать информацию из первого или второго столбца.

      Например, чтобы просмотреть журнал предыдущей загрузки, используйте относительный указатель -1 с флагом -b:

      journalctl -b -1

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

      journalctl -b caf0524a1d394ce0bdbcff75b94444fe

      Временные окна

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

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

      Значения времени могут иметь разные форматы. Для абсолютных значений времени нужно использовать следующий формат:

      YYYY-MM-DD HH:MM:SS

      Например, чтобы просмотреть все записи с 10 января 2015 г. 17:15, мы введем:

      journalctl --since "2015-01-10 17:15:00"

      Если какие-то компоненты вышеописанного формата будут пропущены, будут применены значения по умолчанию. Например, если дата не будет указана, по умолчанию будет использоваться текущая дата. Если компонент времени отсутствует, для замены будет использоваться значение “00:00:00” (полночь). Поле секунд можно опустить, и тогда для него будет по умолчанию использовано значение “00”:

      journalctl --since "2015-01-10" --until "2015-01-11 03:00"

      Журнальная система также понимает определенные относительные значения и именованные ярлыки. Например, вы можете использовать слова “yesterday” (вчера), “today” (сегодня), “tomorrow”(завтра), “now” (сейчас) и т. д. Чтобы указать относительное время, следует использовать префикс «-» или «+» перед числовым значением или использовать такие слова, как «ago» (назад) при построении фраз.

      Чтобы получить данные за вчерашний день, введите:

      journalctl --since yesterday

      Если вы получили отчеты о перебоях в работе службы, которые начались в 9:00 и закончились час назад, вы можете ввести следующую команду:

      journalctl --since 09:00 --until "1 hour ago"

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

      Фильтрация по значимости сообщений

      Мы изучили несколько возможных способов фильтрации записей в журнальной системе по временным рамкам. В этом разделе мы поговорим о фильтрации сообщений по значимым для вас службам или компонентам. Журнал systemd предоставляет много разных способов делать это.

      По единицам

      Возможно одним из наиболее полезных способов фильтрации является фильтрация по единицам, которые вас интересуют. Для такой фильтрации мы можем использовать опцию -u.

      Например, чтобы посмотреть все журналы единицы Nginx в нашей системе, мы можем ввести команду:

      journalctl -u nginx.service

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

      journalctl -u nginx.service --since today

      Такая фокусировка особенно полезна, если вы используете возможности чередования записей разных единиц в журнальной системе. Например, если ваш процесс Nginx использует единицу PHP-FPM для обработки динамического контента, вы можете объединить их данные в хронологическом порядке, указав обе единицы:

      journalctl -u nginx.service -u php-fpm.service --since today

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

      По процессу, пользователю или идентификатору группы

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

      Для этого нужно указать при фильтрации поле _PID. Например, если нас интересует PID 8088, мы можем ввести:

      journalctl _PID=8088

      В других случаях нам может понадобиться вывести все записи, зарегистрированные для определенного пользователя или группы. Это можно сделать с помощью фильтров _UID или _GID. Например, если ваш веб-сервер работает под именем пользователя www-data, вы можете найти идентификатор пользователя с помощью следующей команды:

      id -u www-data

      33

      После этого, вы сможете использовать возвращенный идентификатор для фильтрации результатов журнальной системы:

      journalctl _UID=33 --since today

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

      Символ подчеркивания в начале указывает, что поле _PID относится к последнему типу. Журнал автоматически регистрирует и индексирует значения PID процессов, регистрируемых для последующей фильтрации. Вы можете узнать все о доступных полях журнала, используя следующую команду:

      man systemd.journal-fields

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

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

      journalctl -F _GID

      32
99
102
133
81
84
100
0
124
87

      Она покажет вам все значения, сохраненные в журнальной системе для поля group ID. Это должно помочь вам в настройке фильтров.

      По пути компонента

      Также для фильтрации можно указать путь.

      Если путь указывает на исполняемый файл, journalctl выведет все записи, связанные с этим исполняемым файлом. Например, чтобы найти записи с исполняемым файлом bash, нужно ввести команду:

      journalctl /usr/bin/bash

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

      Отображение сообщений ядра

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

      Чтобы вывести только эти сообщения, можно добавить к команде флаг -k или --dmesg:

      journalctl -k

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

      journalctl -k -b -5

      По приоритету

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

      Вы можете использовать journalctl с опцией -p, чтобы вывести только сообщения с указанным или более высоким приоритетом. Это позволяет убрать из выводимых результатов сообщения с более низким приоритетом.

      Например, чтобы вывести только записи с уровнем серьезности error (ошибка) или выше, введите команду:

      journalctl -p err -b

      Эта команда покажет вам все сообщения с пометкой error (ошибка), critical (критическая ошибка), alert (тревога) или emergency (чрезвычайная ситуация). В журнальной системе реализованы стандартные уровни ошибок syslog. Вы можете использовать название уровня приоритета или соответствующее числовое значение. Вот эти значения, от наибольшего приоритета к наименьшему:

      • 0: emerg
      • 1: alert
      • 2: crit
      • 3: err
      • 4: warning
      • 5: notice
      • 6: info
      • 7: debug

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

      Изменение отображения журнальной системы

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

      Сокращение или расширение области вывода

      Мы можем настроить вид вывода данных journalctl, указав, что вывод можно сжать или раскрыть.

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

      Если вы предпочитаете урезать вывод и вставить многоточие в месте, где удалена информация, вы можете использовать опцию --no-full:

      journalctl --no-full

      . . .

Feb 04 20:54:13 journalme sshd[937]: Failed password for root from 83.234.207.60...h2
Feb 04 20:54:13 journalme sshd[937]: Connection closed by 83.234.207.60 [preauth]
Feb 04 20:54:13 journalme sshd[937]: PAM 2 more authentication failures; logname...ot

      Также вы можете сделать и обратное, и попросить journalctl вывести всю доступную информацию вне зависимости от того, содержит ли она непечатные символы. Для этого можно использовать флаг -a:

      journalctl -a

      Вывод в стандартный выход

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

      Для такого вывода следует использовать опцию --no-pager:

      journalctl --no-pager

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

      Форматы вывода

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

      Например, чтобы вывести журнала в формате JSON, нужно ввести следующую команду:

      journalctl -b -u nginx -o json

      { "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635", "__REALTIME_TIMESTAMP" : "1422990364739502", "__MONOTONIC_TIMESTAMP" : "27200938", "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d", "PRIORITY" : "6", "_UID" : "0", "_GID" : "0", "_CAP_EFFECTIVE" : "3fffffffff", "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee", "_HOSTNAME" : "desktop", "SYSLOG_FACILITY" : "3", "CODE_FILE" : "src/core/unit.c", "CODE_LINE" : "1402", "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading", "SYSLOG_IDENTIFIER" : "systemd", "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5", "_TRANSPORT" : "journal", "_PID" : "1", "_COMM" : "systemd", "_EXE" : "/usr/lib/systemd/systemd", "_CMDLINE" : "/usr/lib/systemd/systemd", "_SYSTEMD_CGROUP" : "/", "UNIT" : "nginx.service", "MESSAGE" : "Starting A high performance web server and a reverse proxy server...", "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973" }

. . .

      Это полезно, если вы используете утилиты для синтаксического анализа. Вы можете использовать формат json-pretty, чтобы сделать структуру данных проще, прежде чем передавать данные потребителю JSON:

      journalctl -b -u nginx -o json-pretty

      {
    "__CURSOR" : "s=13a21661cf4948289c63075db6c25c00;i=116f1;b=81b58db8fd9046ab9f847ddb82a2fa2d;m=19f0daa;t=50e33c33587ae;x=e307daadb4858635",
    "__REALTIME_TIMESTAMP" : "1422990364739502",
    "__MONOTONIC_TIMESTAMP" : "27200938",
    "_BOOT_ID" : "81b58db8fd9046ab9f847ddb82a2fa2d",
    "PRIORITY" : "6",
    "_UID" : "0",
    "_GID" : "0",
    "_CAP_EFFECTIVE" : "3fffffffff",
    "_MACHINE_ID" : "752737531a9d1a9c1e3cb52a4ab967ee",
    "_HOSTNAME" : "desktop",
    "SYSLOG_FACILITY" : "3",
    "CODE_FILE" : "src/core/unit.c",
    "CODE_LINE" : "1402",
    "CODE_FUNCTION" : "unit_status_log_starting_stopping_reloading",
    "SYSLOG_IDENTIFIER" : "systemd",
    "MESSAGE_ID" : "7d4958e842da4a758f6c1cdc7b36dcc5",
    "_TRANSPORT" : "journal",
    "_PID" : "1",
    "_COMM" : "systemd",
    "_EXE" : "/usr/lib/systemd/systemd",
    "_CMDLINE" : "/usr/lib/systemd/systemd",
    "_SYSTEMD_CGROUP" : "/",
    "UNIT" : "nginx.service",
    "MESSAGE" : "Starting A high performance web server and a reverse proxy server...",
    "_SOURCE_REALTIME_TIMESTAMP" : "1422990364737973"
}

. . .

      Для отображения можно использовать следующие форматы:

      • cat: отображает только само поле сообщения.
      • export: двоичный формат, подходящий для передачи или резервного копирования.
      • json: стандартный формат JSON с одной записью на строку.
      • json-pretty: код JSON в формате, более удобном для чтения человеком
      • json-sse: вывод в формате JSON в оболочке, совместимой с операцией add server-sent event
      • short: вывод в формате syslog по умолчанию
      • short-iso: формат по умолчанию, дополненный для отображения временных меток часов ISO 8601.
      • short-monotonic: формат по умолчанию с однотонными временными метками.
      • short-precise: формат по умолчанию с точностью до микросекунд
      • verbose: показывает все поля журнальной системы, доступные для ввода, в том числе те, которые обычно скрыты на внутреннем уровне.

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

      Мониторинг активных процессов

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

      Отображение последних журналов

      Чтобы вывести указанное количество записей, вы можете использовать опцию -n, которая работает как tail -n.

      По умолчанию отображается 10 последних записей:

      journalctl -n

      Вы можете указать желаемое количество записей, задав число после -n:

      journalctl -n 20

      Наблюдение за журналами

      Для активного наблюдения за журналами по мере их пополнения можно использовать флаг -f. Это будет работать именно так, как можно ожидать, если у вас есть опыт использования tail -f:

      journalctl -f

      Обслуживание журналов

      Вам может быть интересно, сколько места занимают все эти данные, которые мы уже видели. Более того, вы можете захотеть удалить какие-либо старые журналы и освободить место.

      Определение текущего использования дискового пространства

      Вы можете определить, сколько места занимает журнал на диске, используя флаг --disk-usage:

      journalctl --disk-usage

      Journals take up 8.0M on disk.

      Удаление старых журналов

      Если вы хотите сократить размер журнала, вы можете использовать для этого два разных способа (доступных в systemd версии 218 или выше).

      Если вы используете опцию --vacuum-size, вы можете сократить журнал, указав размер. При использовании этой опции старые записи будут удаляться, пока занимаемое журнальной системой место на диске не сократится до требуемого размера:

      sudo journalctl --vacuum-size=1G

      Также можно сократить размер журнала, указав время отсечки с помощью --vacuum-time. Любые записи вне этого времени удаляются. Эта опция позволяет сохранить записи, созданные после истечения определенного времени.

      Например, чтобы сохранить записи с прошлого года, вы можете ввести:

      sudo journalctl --vacuum-time=1years

      Ограничение расширения журналов

      Вы можете настроить свой сервер так, чтобы ограничить место, занимаемое журнальной системой. Для этого следует отредактировать файл /etc/systemd/journald.conf.

      Для ограничения роста занимаемого журнальной системой объема можно использовать следующие элементы:

      • SystemMaxUse=: указывает максимальное пространство на диске, которое может использоваться журнальной системой.
      • SystemKeepFree=: указывает пространство на диске, которое журнальная система должна оставлять свободным при добавлении записей в журналы.
      • SystemMaxFileSize=: определяет, до какого размера могут увеличиваться большие файлы журнала на диске до ротации.
      • RuntimeMaxUse=: указывает, сколько места на диске может использоваться для временного хранения (в /run filesystem).
      • RuntimeKeepFree=: указывает, сколько места на диске следует оставлять на диске для других целей при записи данных во временное хранилище (в файловой системе /run).
      • RuntimeMaxFileSize=: указывает, сколько места может занимать отдельный файл журнала во временном хранилище (в файловой системе /run) до ротации.

      Задавая эти значения, вы можете контролировать, сколько места на вашем сервере использует journald. Помните, что SystemMaxFileSize и RuntimeMaxFileSize будут применяться к архивным файлам для достижения заданных ограничений. Это важно помнить при интерпретации подсчета файлов после операции вакуумной очистки.

      Заключение

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



      Source link

      Централизация журналов с помощью Journald в Ubuntu 20.04


      Автор выбрал фонд Free and Open Source Fund для получения пожертвования в рамках программы Write for DOnations.

      Введение

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

      Централизованный сервер управления журналами дает ряд преимуществ по сравнению с хранением журналов на каждом хосте:

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

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

      Предварительные требования

      Для прохождения этого обучающего руководства вам потребуется следующее:

      • Два сервера Ubuntu 20.04.
      • Пользователь без прав root с привилегиями sudo на обоих серверах. Указания можно найти в руководстве «Начальная настройка сервера Ubuntu 20.04». Также вам следует настроить брандмауэр UFW на обоих серверах, как объясняется в этом руководстве.
      • Два хоста, указывающие на ваши серверы. Одно имя хоста для клиентской системы, которая генерирует журналы, и другое — для сервера сбора журналов. Узнайте, как назначать имена хостов для дроплетов DigitalOcean, ознакомившись с документацией по доменам и DNS.

      В этом руководстве мы будем использовать два типовых имени хоста:

      • client.your_domain: клиентская система, генерирующая журналы.
      • server.your_domain: сервер хранения журналов.

      Для начала этого обучающего модуля выполните вход на клиент и на сервер в отдельных терминалах через SSH как пользователь без прав root с привилегиями sudo.

      Примечание. В этом обучающем модуле блоки команд помечаются именем сервера (client или server), где должна запускаться команда.

      Шаг 1 — Установка systemd-journal-remote

      На этом шаге мы установим пакет systemd-journal-remote на серверах client и server. Этот пакет содержит компоненты, которые client и server используют для пересылки сообщений журнала.

      Вначале проведите обновление системы на серверах client и server, чтобы гарантировать использование актуальных версий системы и базы данных пакетов:

      Client and Server

      • sudo apt update

      • sudo apt upgrade

      Затем установите пакет systemd-journal-remote:

      Client and Server

      • sudo apt install systemd-journal-remote

      На сервере server активируйте и запустите два компонента systemd, необходимых для получения журнала, с помощью следующей команды:

      Server

      • sudo systemctl enable --now systemd-journal-remote.socket

      • sudo systemctl enable systemd-journal-remote.service

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

      Активируйте на сервере client компонент, используемый systemd для отправки сообщений журнала на сервер:

      Client

      • sudo systemctl enable systemd-journal-upload.service

      Откройте на сервере порты 19532 и 80 в брандмауэре UFW. Это позволит серверу получать сообщения журнала от клиента. Порт 80 используется certbot для генерирования сертификата TLS. Эти порты открываются с помощью следующих команд:

      Server

      • sudo ufw allow in 19532/tcp

      • sudo ufw allow in 80/tcp

      На клиенте нужно открыть только порт 80 с помощью следующей команды:

      Client

      Мы установили требуемые компоненты и настроили базовую конфигурацию системы на клиенте и сервере. Прежде чем настраивать эти компоненты для пересылки сообщений журнала, необходимо зарегистрировать сертификаты TLS от Let’s Encrypt для серверов client и server с помощью утилиты certbot.

      Шаг 2 — Установка Certbot и регистрация сертификатов

      Let’s Encrypt — это центр сертификации, выпускающий бесплатные сертификаты TLS. Эти сертификаты позволяют компьютерам шифровать данные, которыми они обмениваются, и выполнять взаимную аутентификацию. Эти сертификаты позволяют защитить компьютер с помощью протокола HTTPS в браузере. Эти же сертификаты могут использоваться любым другим приложением, для которого требуется такой же уровень безопасности. Процесс регистрации сертификата будет одинаковым вне зависимости от его предназначения.

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

      Вначале активируйте репозиторий Ubuntu universe, поскольку утилита certbot находится в репозитории universe. Если у вас уже активирован репозиторий universe, при запуске этих команд ничего не произойдет, так что вы можете безопасно запустить их:

      Client and Server

      • sudo apt install software-properties-common

      • sudo add-apt-repository universe

      • sudo apt update

      Затем установите certbot на обоих хостах:

      Client and Server

      После установки certbot запустите следующую команду для регистрации сертификатов на клиенте и на сервере:

      Client and Server

      • sudo certbot certonly --standalone --agree-tos --email sammy@your_domain -d your_domain

      Опции этой команды имеют следующее значение:

      • certonly: зарегистрировать сертификат и не вносить в систему никаких других изменений.
      • --standalone: использовать встроенный веб-сервер certbot для проверки запроса сертификата.
      • --agree-tos: автоматически принять условия обслуживания Let’s Encrypt.
      • --email your_email: этот адрес электронной почты Let’s Encrypt будет использовать для уведомлений об истечении срока действия сертификатов и отправки другой важной информации.
      • -d your_domain: имя хоста, для которого будет регистрироваться сертификат. Это значение должно соответствовать имени хоста системы, где вы запускаете команду.

      При запуске этой команды вам будет предложено передать Let’s Encrypt адрес электронной почты, чтобы они могли посылать вам новости и другую информацию об их работе. Это необязательно, и если вы не передадите свой адрес электронной почты, регистрация сертификата все равно пройдет нормально.

      После завершения процесса регистрации файлы ключа и сам сертификат будут размещены в каталоге /etc/letsencrypt/live/your_domain/, где your_domain — имя хоста, для которого вы зарегистрировали сертификат.

      В заключение вам нужно будет загрузить копию ЦС Let’s Encrypt и промежуточные сертификаты и поместить их в этот же файл. journald будет использовать этот файл для проверки подлинности сертификатов клиента и сервера при их взаимодействии друг с другом.

      Следующая команда загрузит два сертификата с сайта Let’s Encrypt и поместит их в один файл letsencrypt-combined-certs.pem в домашнем каталоге пользователя.

      Запустите эту команду на клиенте и на сервере для загрузки сертификатов и создания объединенного файла:

      Client and Server

      • curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} > ~/letsencrypt-combined-certs.pem

      Затем переместите этот файл в каталог Let’s Encrypt, содержащий ключи и сертификаты:

      Client and Server

      • sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/your_domain/

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

      Шаг 3 — Настройка сервера

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

      Компонент systemd-journal-remote отслеживает сообщения журнала. Откройте его файл конфигурации /etc/systemd/journal-remote.conf в текстовом редакторе, чтобы начать его настройку на сервере:

      • sudo nano /etc/systemd/journal-remote.conf

      Затем разкомментируйте все строки в разделе [Remote] и установите пути к только что созданным файлам TLS:

      /etc/systemd/journal-remote.conf

      [Remote]
Seal=false
SplitMode=host
ServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combined-certs.pem

      Здесь мы используем следующие опции:

      • Seal=false: Подписывать данные в журнале. Активируйте эту опцию, если вам требуется максимальный уровень безопасности, а в ином случае оставьте значение false.
      • SplitMode=host: журналы удаленных клиентов разделяются по хостам в каталоге /var/log/journal/remote. Если вы предпочитаете добавлять все журналы в один файл, установите значение SplitMode=false.
      • ServerKeyFile: файл закрытого ключа сервера.
      • ServerCertificateFile: файл сертификата сервера.
      • TrustedCertificateFile: файл, содержащий сертификаты ЦС Let’s Encrypt.

      Теперь необходимо изменить разрешения для содержащих сертификаты и ключ каталогов Let’s Encrypt, чтобы команда systemd-journal-remote могла считывать и использовать их.

      Вначале измените разрешения так, чтобы сертификат и закрытый ключ были доступны для чтения:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}

      • sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem

      Затем измените группового владельца закрытого ключа на группу systemd-journal-remote:

      • sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.your_domain/privkey.pem

      Теперь вы можете запустить systemd-journal-remote:

      • sudo systemctl start systemd-journal-remote.service

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

      Шаг 4 — Настройка клиента

      На этом шаге мы настроим компонент, пересылающий сообщения журнала на сервер хранения журналов. Этот компонент называется systemd-journal-upload.

      В конфигурации systemd-journal-upload по умолчанию используется временный пользователь, существующий только во время выполнения процесса. Это усложняет предоставление systemd-journal-upload разрешения на чтение сертификатов TLS и ключей. Для устранения этой проблемы необходимо создать нового пользователя системы с тем же именем, что и у временного пользователя, который будет использоваться вместо него.

      Вначале создайте нового пользователя systemd-journal-upload на клиенте с помощью следующей команды adduser:

      • sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload

      Опции этой команды:

      • --system: создать нового пользователя как системного. При этом пользователю присваивается числовой идентификатор UID ниже 1000. Идентификаторы UID выше 1000 обычно присваиваются учетным записям, которые используют пользователи-люди.
      • --home /run/systemd: задать /run/systemd как домашний каталог пользователя.
      • --no-create-home: не создавать набор домашних каталогов, поскольку он уже существует.
      • --disabled-login: этот пользователь не может входить на сервер, например, через SSH.
      • --group: создать группу с тем же именем, что и у пользователя.

      Затем необходимо задать разрешения и владельца файлов сертификатов Let’s Encrypt:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}

      • sudo chmod 0640 /etc/letsencrypt/live/client.your_domain/privkey.pem

      • sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.your_domain/privkey.pem

      Теперь отредактируйте конфигурацию systemd-journal-upload в файле /etc/systemd/journal-upload.conf. Откройте этот файл в текстовом редакторе:

      • sudo nano /etc/systemd/journal-upload.conf

      Отредактируйте файл следующим образом:

      /etc/systemd/journal-upload.conf

      [Upload]
URL=https://server.your_domain:19532
ServerKeyFile=/etc/letsencrypt/live/client.your_domain/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/client.your_domain/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/client.your_domain/letsencrypt-combined-certs.pem

      Перезапустите службу systemd-journal-upload, чтобы она использовала новую конфигурацию:

      • sudo systemctl restart systemd-journal-upload.service

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

      Шаг 5 — Тестирование клиента и сервера

      На этом шаге мы проверим пересылку клиентом сообщений журнала на сервер и правильность их сохранения на сервере.

      Сервер хранения журналов сохраняет журналы клиентов в каталоге /var/log/journal/remote/. Когда мы перезапустили клиент в конце последнего шага, он начал отправлять сообщения журнала, и поэтому теперь в каталоге /var/log/journal/remote/ содержится файл журнала. Имя файла будет соответствовать имени хоста, использованному для сертификата TLS.

      Используйте команду ls, чтобы проверить наличие файла журнала клиента на сервере:

      Server

      • sudo ls -la /var/log/journal/remote/

      Эта команда выводит содержимое каталога, показывая файл журнала:

      Output
      total 16620
drwxr-xr-x  2 systemd-journal-remote systemd-journal-remote     4096 Jun 30 16:17  .
drwxr-sr-x+ 4 root                   systemd-journal            4096 Jun 30 15:55  ..
-rw-r-----  1 systemd-journal-remote systemd-journal-remote 8388608 Jul  1 10:46 'remote-CN=client.your_domain'

      Затем запишите сообщение журнала на клиенте, чтобы проверить получение сервером сообщений от клиента ожидаемым образом. Мы используем утилиту logger для создания сообщения журнала на клиенте. Если все работает нормально, systemd-journal-upload перешлет это сообщение на сервер.

      Запустите на клиенте следующую команду logger:

      Client

      • sudo logger -p syslog.debug "### TEST MESSAGE from client.your_domain ###"

      Опция -p syslog.debug в этой команде указывает принадлежность и серьезность сообщения. Мы установим значение syslog.debug, чтобы показать, что это тестовое сообщение. Эта команда записывает сообщение ### TEST MESSAGE from client.your_domain ### в журнал клиента, а systemd-journal-upload пересылает его на сервер.

      Откройте файл журнала клиента на сервере и проверьте поступление сообщений журнала от клиента. Это двоичный файл журнала, поэтому вы не сможете открыть его с помощью таких инструментов, как less. Вместо этого откройте файл с помощью команды journalctl с опцией --file=, позволяющей указать определенный файл журнала:

      Server

      • sudo journalctl --file=/var/log/journal/remote/remote-CN=client.your_domain.journal

      Сообщение журнала будет выглядеть следующим образом:

      Test log message
      . . .
Jun 29 13:10:09 client root[3576]: ### TEST MESSAGE from client.your_domain ###

      Ваш сервер централизованного хранения журналов успешно получает журналы вашей клиентской системы.

      Заключение

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



      Source link

      Централизация журналов с помощью Journald в Debian 10


      Автор выбрал фонд Free and Open Source Fund для получения пожертвования в рамках программы Write for DOnations.

      Введение

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

      Централизованный сервер управления журналами дает ряд преимуществ по сравнению с хранением журналов на каждом хосте:

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

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

      Предварительные требования

      Для прохождения этого обучающего руководства вам потребуется следующее:

      • Два сервера Debian 10.
      • Пользователь без прав root с привилегиями sudo на обоих серверах. Инструкции можно найти в руководстве «Начальная настройка сервера с Debian 10». Также вам следует настроить брандмауэр UFW на обоих серверах, как объясняется в этом руководстве.
      • Два хоста, указывающие на ваши серверы. Одно имя хоста для клиентской системы, которая генерирует журналы, и другое — для сервера сбора журналов. Узнайте, как назначать имена хостов для дроплетов DigitalOcean, ознакомившись с документацией по доменам и DNS.

      В этом руководстве мы будем использовать два типовых имени хоста:

      • client.your_domain: клиентская система, генерирующая журналы.
      • server.your_domain: сервер хранения журналов.

      Для начала этого обучающего модуля выполните вход на клиент и на сервер в отдельных терминалах через SSH как пользователь без прав root с привилегиями sudo.

      Примечание. В этом обучающем модуле блоки команд помечаются именем сервера (client или server), где должна запускаться команда.

      Шаг 1 — Установка systemd-journal-remote

      На этом шаге мы установим пакет systemd-journal-remote на серверах client и server. Этот пакет содержит компоненты, которые client и server используют для пересылки сообщений журнала.

      Вначале проведите обновление системы на серверах client и server, чтобы гарантировать использование актуальных версий системы и базы данных пакетов:

      Client and Server

      • sudo apt update

      • sudo apt upgrade

      Затем установите пакет systemd-journal-remote:

      Client and Server

      • sudo apt install systemd-journal-remote

      На сервере server активируйте и запустите два компонента systemd, необходимых для получения журнала, с помощью следующей команды:

      Server

      • sudo systemctl enable --now systemd-journal-remote.socket

      • sudo systemctl enable systemd-journal-remote.service

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

      Активируйте на сервере client компонент, используемый systemd для отправки сообщений журнала на сервер:

      Client

      • sudo systemctl enable systemd-journal-upload.service

      Откройте на сервере порты 19532 и 80 в брандмауэре UFW. Это позволит серверу получать сообщения журнала от клиента. Порт 80 используется certbot для генерирования сертификата TLS. Эти порты открываются с помощью следующих команд:

      Server

      • sudo ufw allow in 19532/tcp

      • sudo ufw allow in 80/tcp

      На клиенте нужно открыть только порт 80 с помощью следующей команды:

      Client

      Мы установили требуемые компоненты и настроили базовую конфигурацию системы на клиенте и сервере. Прежде чем настраивать эти компоненты для пересылки сообщений журнала, необходимо зарегистрировать сертификаты TLS от Let’s Encrypt для серверов client и server с помощью утилиты certbot.

      Шаг 2 — Установка Certbot и регистрация сертификатов

      Let’s Encrypt — это центр сертификации, выпускающий бесплатные сертификаты TLS. Эти сертификаты позволяют компьютерам шифровать данные, которыми они обмениваются, и выполнять взаимную аутентификацию. Эти сертификаты позволяют защитить компьютер с помощью протокола HTTPS в браузере. Эти же сертификаты могут использоваться любым другим приложением, для которого требуется такой же уровень безопасности. Процесс регистрации сертификата будет одинаковым вне зависимости от его предназначения.

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

      Вначале установите certbot и утилиту curl на обоих хостах:

      Client and Server

      • sudo apt install certbot curl

      После установки certbot запустите следующую команду для регистрации сертификатов на клиенте и на сервере:

      Client and Server

      • sudo certbot certonly --standalone --agree-tos --email sammy@your_domain -d your_domain

      Опции этой команды имеют следующее значение:

      • certonly: зарегистрировать сертификат и не вносить в систему никаких других изменений.
      • --standalone: использовать встроенный веб-сервер certbot для проверки запроса сертификата.
      • --agree-tos: автоматически принять условия обслуживания Let’s Encrypt.
      • --email your-email: этот адрес электронной почты Let’s Encrypt будет использовать для уведомлений об истечении срока действия сертификатов и отправки другой важной информации.
      • -d your_domain: имя хоста, для которого будет регистрироваться сертификат. Это значение должно соответствовать имени хоста системы, где вы запускаете команду.

      При запуске этой команды вам будет предложено передать Let’s Encrypt адрес электронной почты, чтобы они могли посылать вам новости и другую информацию об их работе. Это необязательно, и если вы не передадите свой адрес электронной почты, регистрация сертификата все равно пройдет нормально.

      После завершения процесса регистрации файлы ключа и сам сертификат будут размещены в каталоге /etc/letsencrypt/live/your_domain/, где your_domain — имя хоста, для которого вы зарегистрировали сертификат.

      В заключение вам нужно будет загрузить копию ЦС Let’s Encrypt и промежуточные сертификаты и поместить их в этот же файл. journald будет использовать этот файл для проверки подлинности сертификатов клиента и сервера при их взаимодействии друг с другом.

      Следующая команда загрузит два сертификата с сайта Let’s Encrypt и поместит их в один файл letsencrypt-combined-certs.pem в домашнем каталоге пользователя.

      Запустите эту команду на клиенте и на сервере для загрузки сертификатов и создания объединенного файла:

      Client and Server

      • curl -s https://letsencrypt.org/certs/{isrgrootx1.pem.txt,letsencryptauthorityx3.pem.txt} > ~/letsencrypt-combined-certs.pem

      Затем переместите этот файл в каталог Let’s Encrypt, содержащий ключи и сертификаты:

      Client and Server

      • sudo cp ~/letsencrypt-combined-certs.pem /etc/letsencrypt/live/your_domain/

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

      Шаг 3 — Настройка сервера

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

      Компонент systemd-journal-remote отслеживает сообщения журнала. Откройте его файл конфигурации /etc/systemd/journal-remote.conf в текстовом редакторе, чтобы начать его настройку на сервере:

      • sudo nano /etc/systemd/journal-remote.conf

      Затем разкомментируйте все строки в разделе [Remote] и установите пути к только что созданным файлам TLS:

      /etc/systemd/journal-remote.conf

      [Remote]
Seal=false
SplitMode=host
ServerKeyFile=/etc/letsencrypt/live/server.your_domain/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/server.your_domain/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/server.your_domain/letsencrypt-combined-certs.pem

      Здесь мы используем следующие опции:

      • Seal=false: Подписывать данные в журнале. Активируйте эту опцию, если вам требуется максимальный уровень безопасности, а в ином случае оставьте значение false.
      • SplitMode=host: журналы удаленных клиентов разделяются по хостам в каталоге /var/log/journal/remote. Если вы предпочитаете добавлять все журналы в один файл, установите значение SplitMode=false.
      • ServerKeyFile: файл закрытого ключа сервера.
      • ServerCertificateFile: файл сертификата сервера.
      • TrustedCertificateFile: файл, содержащий сертификаты ЦС Let’s Encrypt.

      Теперь необходимо изменить разрешения для содержащих сертификаты и ключ каталогов Let’s Encrypt, чтобы команда systemd-journal-remote могла считывать и использовать их.

      Вначале измените разрешения так, чтобы сертификат и закрытый ключ были доступны для чтения:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}

      • sudo chmod 0640 /etc/letsencrypt/live/server.your_domain/privkey.pem

      Затем измените группового владельца закрытого ключа на группу systemd-journal-remote:

      • sudo chgrp systemd-journal-remote /etc/letsencrypt/live/server.your_domain/privkey.pem

      Теперь вы можете запустить systemd-journal-remote:

      • sudo systemctl start systemd-journal-remote.service

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

      Шаг 4 — Настройка клиента

      На этом шаге мы настроим компонент, пересылающий сообщения журнала на сервер хранения журналов. Этот компонент называется systemd-journal-upload.

      В конфигурации systemd-journal-upload по умолчанию используется временный пользователь, существующий только во время выполнения процесса. Это усложняет предоставление systemd-journal-upload разрешения на чтение сертификатов TLS и ключей. Для устранения этой проблемы необходимо создать нового пользователя системы с тем же именем, что и у временного пользователя, который будет использоваться вместо него.

      Вначале создайте нового пользователя systemd-journal-upload на клиенте с помощью следующей команды adduser:

      • sudo adduser --system --home /run/systemd --no-create-home --disabled-login --group systemd-journal-upload

      Опции этой команды:

      • --system: Создать нового пользователя как системного. При этом пользователю присваивается числовой идентификатор UID ниже 1000. Идентификаторы UID выше 1000 обычно присваиваются учетным записям, которые используют пользователи-люди.
      • --home /run/systemd: задать /run/systemd как домашний каталог пользователя.
      • --no-create-home: не создавать набор домашних каталогов, поскольку он уже существует.
      • --disabled-login: этот пользователь не может входить на сервер, например, через SSH.
      • --group: создать группу с тем же именем, что и у пользователя.

      Затем необходимо задать разрешения и владельца файлов сертификатов Let’s Encrypt:

      • sudo chmod 0755 /etc/letsencrypt/{live,archive}

      • sudo chmod 0640 /etc/letsencrypt/live/client.your_domain/privkey.pem

      • sudo chgrp systemd-journal-upload /etc/letsencrypt/live/client.your_domain/privkey.pem

      Теперь отредактируйте конфигурацию systemd-journal-upload в файле /etc/systemd/journal-upload.conf. Откройте этот файл в текстовом редакторе:

      • sudo nano /etc/systemd/journal-upload.conf

      Отредактируйте файл следующим образом:

      /etc/systemd/journal-upload.conf

      [Upload]
URL=https://server.your_domain:19532
ServerKeyFile=/etc/letsencrypt/live/client.your_domain/privkey.pem
ServerCertificateFile=/etc/letsencrypt/live/client.your_domain/fullchain.pem
TrustedCertificateFile=/etc/letsencrypt/live/client.your_domain/letsencrypt-combined-certs.pem

      Перезапустите службу systemd-journal-upload, чтобы она использовала новую конфигурацию:

      • sudo systemctl restart systemd-journal-upload.service

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

      Шаг 5 — Тестирование клиента и сервера

      На этом шаге мы проверим пересылку клиентом сообщений журнала на сервер и правильность их сохранения на сервере.

      Сервер хранения журналов сохраняет журналы клиентов в каталоге /var/log/journal/remote/. Когда мы перезапустили клиент в конце последнего шага, он начал отправлять сообщения журнала, и поэтому теперь в каталоге /var/log/journal/remote/ содержится файл журнала. Имя файла будет соответствовать имени хоста, использованному для сертификата TLS.

      Используйте команду ls, чтобы проверить наличие файла журнала клиента на сервере:

      Server

      • sudo ls -la /var/log/journal/remote/

      Эта команда выводит содержимое каталога, показывая файл журнала:

      Output
      total 16620
drwxr-xr-x  2 systemd-journal-remote systemd-journal-remote     4096 Jun 30 16:17  .
drwxr-sr-x+ 4 root                   systemd-journal            4096 Jun 30 15:55  ..
-rw-r-----  1 systemd-journal-remote systemd-journal-remote 8388608 Jul  1 10:46 'remote-CN=client.your_domain'

      Затем запишите сообщение журнала на клиенте, чтобы проверить получение сервером сообщений от клиента ожидаемым образом. Мы используем утилиту logger для создания сообщения журнала на клиенте. Если все работает нормально, systemd-journal-upload перешлет это сообщение на сервер.

      Запустите на клиенте следующую команду logger:

      Client

      • sudo logger -p syslog.debug "### TEST MESSAGE from client.your_domain ###"

      Опция -p syslog.debug в этой команде указывает принадлежность и серьезность сообщения. Мы установим значение syslog.debug, чтобы показать, что это тестовое сообщение. Эта команда записывает сообщение ### TEST MESSAGE from client.your_domain ### в журнал клиента, а systemd-journal-upload пересылает его на сервер.

      Откройте файл журнала клиента на сервере и проверьте поступление сообщений журнала от клиента. Это двоичный файл журнала, поэтому вы не сможете открыть его с помощью таких инструментов, как less. Вместо этого откройте файл с помощью команды journalctl с опцией --file=, позволяющей указать определенный файл журнала:

      Server

      • sudo journalctl --file=/var/log/journal/remote/remote-CN=client.your_domain.journal

      Сообщение журнала будет выглядеть следующим образом:

      Test log message
      . . .
Jun 29 13:10:09 client root[3576]: ### TEST MESSAGE from client.your_domain ###

      Ваш сервер централизованного хранения журналов успешно получает журналы вашей клиентской системы.

      Заключение

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



      Source link

      Forgot Your Password ?