Compare commits
10 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
720969dee5 | ||
|
|
f54a9fa59c | ||
|
|
a59846be38 | ||
|
|
4539170bae | ||
|
|
6a698b3e9a | ||
|
|
e71d20b589 | ||
|
|
946aabe425 | ||
|
|
d60da689e7 | ||
|
|
adb49af977 | ||
|
|
bc028b2c47 |
708
s4a.tex
708
s4a.tex
@@ -6,21 +6,30 @@
|
||||
\usepackage[T1,T2A]{fontenc}
|
||||
\usepackage{indentfirst} % Отступ в первом абзаце главы
|
||||
\usepackage{fancyvrb} % Продвинутые листинги и in-line commands
|
||||
% listings для данной ситуации, имхо, избыточен
|
||||
% listings в данной ситуации, IMHO, избыточен
|
||||
\usepackage{pdflscape} % Внимание! При выводе в DVI выборочный
|
||||
% поворот страниц работать не будет, хотя текст будет повернут.
|
||||
\usepackage[colorlinks,unicode,urlcolor=blue]{hyperref}
|
||||
% Заполняем поля PDF уже со включенной опцией unicode
|
||||
\hypersetup{pdftitle={systemd для администраторов},%
|
||||
pdfauthor={Lennart Poettering, Sergey Ptashnick}}
|
||||
% Не засоряем оглавление подразделами
|
||||
\setcounter{tocdepth}{1}
|
||||
% Несколько сокращений
|
||||
\newcommand{\sectiona}[1]{\section*{#1}\addcontentsline{toc}{section}{#1}}
|
||||
\newcommand{\hreftt}[2]{\href{#1}{\texttt{#2}}}
|
||||
\newcommand{\tbs}{\textbackslash}
|
||||
\newcommand{\hrf}[2]{\href{#1}{#2}}
|
||||
\newenvironment{caveat}[1][]{\smallskip\par\textbf{Предупреждение#1: }}%
|
||||
{\smallskip\par}
|
||||
% Примерный аналог символа \testSFii (присутствует в листингах),
|
||||
% но без использования пакета pmboxdraw, средствами graphicx
|
||||
\newcommand{\mytextSFii}{\raisebox{0pt}[0pt][\depth]{%
|
||||
\reflectbox{\rotatebox[origin=t]{270}{$\neg$}}}}
|
||||
% Из-за бага в пакете fancyvrb, в окружениях Verbatim нельзя использовать URL,
|
||||
% содержащие дефисы. Поэтому их определение приходится выносить за пределы
|
||||
% окружения
|
||||
\newcommand{\defhref}[3]{\newcommand{#1}{\href{#2}{#3}}}
|
||||
% Настройка макета страницы
|
||||
\setlength{\hoffset}{-1.5cm}
|
||||
\addtolength{\textwidth}{2cm}
|
||||
@@ -40,7 +49,7 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
|
||||
\begin{document}
|
||||
\sloppy
|
||||
\title{systemd для администраторов}
|
||||
\author{Lennart P\"{o}ttering (автор)\thanks{Первоисточник (на английском
|
||||
\author{Lennart Poettering (автор)\thanks{Первоисточник (на английском
|
||||
языке) опубликован на сайте автора: \url{http://0pointer.de/blog/projects}}\\%
|
||||
Сергей Пташник (русский перевод)\thanks{Актуальная версия перевода
|
||||
доступна на личной странице переводчика:
|
||||
@@ -70,7 +79,7 @@ Unported}}
|
||||
будем рассматривать ключевые новшества systemd, что может потребовать несколько
|
||||
более подробного изложения.
|
||||
\begin{flushright}
|
||||
Lennart P\"{o}ttering, 23 августа 2010~г.
|
||||
Lennart Poettering, 23 августа 2010~г.
|
||||
\end{flushright}
|
||||
|
||||
\section{Контроль процесса загрузки}
|
||||
@@ -1409,7 +1418,7 @@ systemd уже подготовлен для работы внутри таки
|
||||
|
||||
\section{Поиск виновных}
|
||||
|
||||
Fedora~15\footnote{Величайший в истории релиз свободной ОС}
|
||||
Fedora~15\footnote{Величайший в истории релиз свободной ОС.}
|
||||
является первым релизом Fedora, использующим systemd в качестве системы
|
||||
инициализации по умолчанию. Основной нашей целью при работе над выпуском F15
|
||||
является обеспечение полной взаимной интеграции и корректной работы всех
|
||||
@@ -1701,14 +1710,14 @@ shell-скриптов, разработанных для этих задач р
|
||||
\item Автоматический запуск +getty+ на serial-консолях.
|
||||
\item Взаимодействие с Plymouth.
|
||||
\item Создание уникального идентификатора системы.
|
||||
\item Установка часового пояса.
|
||||
\item Настройка часового пояса.
|
||||
\end{itemize}
|
||||
|
||||
В стандартной установке Fedora~15 запуск shell-скриптов требуется только для
|
||||
некоторых устаревших служб, а также для подсистемы хранения данных (поддержка
|
||||
LVM, RAID и multipath). Если они вам не~нужны, вы легко можете отключить их, и
|
||||
наслаждаться загрузкой, полностью очищенной от shell-костылей (я это сделал уже
|
||||
давно). Такая загрузка является уникальной возможностью Linux-систем.
|
||||
наслаждаться загрузкой, полностью очищенной от shell-костылей (лично я это
|
||||
сделал уже давно). Такая загрузка является уникальной возможностью Linux-систем.
|
||||
|
||||
Большинство перечисленных выше компонентов настраиваются через конфигурационные
|
||||
файлы в каталоге +/etc+. Некоторые из этих файлов стандартизированы для всех
|
||||
@@ -1717,9 +1726,9 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
|
||||
+/etc/crypttab+, +/etc/sysctl.conf+. Однако множество других, нестандартно
|
||||
расположенных файлов и каталогов вынуждали нас добавлять в код огромное
|
||||
количество операторов +#ifdef+, чтобы обеспечить поддержку различных вариантов
|
||||
расположения конфигураций в разных дистрибутивах. Такой положение дел сильно
|
||||
расположения конфигураций в разных дистрибутивах. Такое положение дел сильно
|
||||
усложняет жизнь нам всем, и при этом ничем не~оправдано~--- все эти файлы решают
|
||||
одни и те же задачи, но делают это немного по-разному.
|
||||
одни и те же задачи, просто немного по-разному.
|
||||
|
||||
Чтобы улучшить ситуацию и установить единый стандарт расположения базовых
|
||||
конфигурационных файлов во всех дистрибутивах, мы заставили systemd пользоваться
|
||||
@@ -1748,7 +1757,7 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
|
||||
\hreftt{http://0pointer.de/public/systemd-man/modules-load.d.html}{/etc/modules-load.d/*.conf}:
|
||||
каталог\footnote{Прим. перев.: Для описания этого и трех
|
||||
последующих каталогов автор пользуется термином <<drop-in
|
||||
directory>>. Этот термин означает каталог, в который можно
|
||||
directory>>. Данный термин означает каталог, в который можно
|
||||
поместить множество независимых файлов настроек, и при чтении
|
||||
конфигурации все эти файлы будут обработаны (впрочем, часто
|
||||
накладывается ограничение~--- обрабатываются только файлы с
|
||||
@@ -1819,7 +1828,7 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
|
||||
systemd, но уже сейчас в их число входят практически все ключевые дистрибутивы,
|
||||
\href{http://www.ubuntu.com/}{за исключением
|
||||
одного}\footnote{Прим. перев.: В конце 2010~года энтузиаст Andrew Edmunds
|
||||
\href{http://cgit.freedesktop.org/systemd/commit/?id=858dae181bb5461201ac1c04732d3ef4c67a0256}{добавил}
|
||||
\href{http://cgit.freedesktop.org/systemd/systemd/commit/?id=858dae181bb5461201ac1c04732d3ef4c67a0256}{добавил}
|
||||
в systemd базовую поддержку Ubuntu и
|
||||
\href{https://wiki.ubuntu.com/systemd}{подготовил} соответствующие пакеты,
|
||||
однако его инициатива не~встретила поддержки среди менеджеров Canonical. На
|
||||
@@ -1827,7 +1836,7 @@ systemd, но уже сейчас в их число входят практич
|
||||
этом есть что-то от <<проблемы курицы и яйца>>: стандарт становится настоящим
|
||||
стандартом только тогда, когда ему начинают следовать. В будущем мы намерены
|
||||
аккуратно форсировать процесс перехода на новые конфигурационные файлы:
|
||||
поддержка старых файлов будет удалена из systemd. Разумеется, этот процесс будет
|
||||
поддержка старых файлов будет удалена из systemd. Разумеется, процесс будет
|
||||
идти медленно, шаг за шагом. Но конечной его целью является переход всех
|
||||
дистрибутивов на единый набор базовых конфигурационных файлов.
|
||||
|
||||
@@ -1866,9 +1875,9 @@ shed)~--- если первое из этих решений принимает
|
||||
\textbf{Помогите нам стандартизировать Linux! Используйте новые конфигурационные
|
||||
файлы! Поддерживайте их в апстриме, поддерживайте их во всех дистрибутивах!}
|
||||
|
||||
Да, и если у вас возникнет такой вопрос: да, все эти файлы так или иначе
|
||||
И если у вас возникнет такой вопрос: да, все эти файлы так или иначе
|
||||
обсуждались с разными разработчиками из различных дистрибутивов. И некоторые из
|
||||
этих разработчиков планируют обеспечить поддержку новой конфигурации даже в
|
||||
разработчиков планируют обеспечить поддержку новой конфигурации даже в
|
||||
системах без systemd.
|
||||
|
||||
\section{О судьбе /etc/sysconfig и /etc/default}
|
||||
@@ -1904,15 +1913,15 @@ shell это соответствует оператору-точке <<+.+>>.
|
||||
окружения, определенные во включаемом коде. Как правило, код для включения
|
||||
не~содержит shebang'а (+#!/bin/sh+ в начале файла).} shell-скриптами, содержащими,
|
||||
главным образом, определения переменных. Большинство файлов из этих каталогов
|
||||
включаются в одноименные скрипты SysV init. Этот принцип отражен в
|
||||
включаются в одноименные скрипты SysV init. Данный принцип отражен в
|
||||
\href{http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit}{Debian
|
||||
Policy Manual (раздел 9.3.2)} и в
|
||||
\href{http://fedoraproject.org/wiki/Packaging:SysVInitScript}{Fedora Packaging
|
||||
Guidelines}, однако в обоих этих дистрибутивах иногда встречаются файлы,
|
||||
не~соответствующие такой схеме, например, не~имеющие соответствующего
|
||||
Guidelines}, однако в обоих дистрибутивах иногда встречаются файлы,
|
||||
не~соответствующие описанной схеме, например, не~имеющие соответствующего
|
||||
init-скрипта, или даже сами не~являющиеся скриптами.
|
||||
|
||||
Но почему вообще появились эти каталоги? Чтобы ответить на этот вопрос,
|
||||
Но почему вообще появились эти каталоги? Чтобы ответить на такой вопрос,
|
||||
обратимся к истории развития концепции SysV init-скриптов. Исторически,
|
||||
сложилось так, что они располагаются в каталоге под названием +/etc/rc.d/init.d+
|
||||
(или что-то похожее). Отметим, что каталог +/etc+ вообще-то предназначен для
|
||||
@@ -1961,16 +1970,16 @@ init-скрипта, или даже сами не~являющиеся скри
|
||||
+/etc/sysconfig+ (+/etc/default+) и почему этим каталогам нет места в мире
|
||||
systemd?
|
||||
\begin{itemize}
|
||||
\item Прежде всего, утрачены основная цель и смысл существования этих
|
||||
\item Прежде всего, утрачены основная цель и смысл существования таких
|
||||
каталогов: файлы конфигурации юнитов systemd не~являются
|
||||
программами, в отличие от init-скриптов SysV. Эти файлы
|
||||
представляют собой простые, декларативные описания конкретных
|
||||
задач и функций, и обычно содержат не~более шести строк. Они
|
||||
легко могут быть сгенерированы и проанализованы без
|
||||
использования Bourne shell. Их легко читать и понимать. Кроме
|
||||
того, их легко модифицировать: достаточно скопировать их из
|
||||
того, их легко модифицировать: достаточно скопировать файл из
|
||||
+/lib/systemd/system+ в +/etc/systemd/system+, после чего внести
|
||||
необходимые изменения в скопированный файл (при этом можно быть
|
||||
в созданную копию необходимые изменения (при этом можно быть
|
||||
уверенным, что изменения не~будут затерты пакетным менеджером).
|
||||
Изначальная причина появления обсуждаемых каталогов~---
|
||||
необходимость разделять код и параметры конфигурации~--- больше
|
||||
@@ -2065,7 +2074,7 @@ systemd?
|
||||
настоящее время не~поддерживается автоматическая загрузка
|
||||
модулей на основании информации о возможностях процессора,
|
||||
однако это будет исправлено в ближайшем будущем\footnote{Прим.
|
||||
перев.: Патчи от разработчиков systemd уже приняты в ядро, и
|
||||
перев.: Необходимые патчи уже приняты в ядро, и
|
||||
соответствующая функция поддерживается Linux, начиная с версии
|
||||
3.3.}. В случае, если нужный вам модуль ядра все же не~может
|
||||
быть подгружен автоматически, все равно существует гораздо более
|
||||
@@ -2101,7 +2110,7 @@ systemd?
|
||||
\item Найдите для них более подходящее место. Например, в случае с
|
||||
некоторыми общесистемными настройками (такими, как локаль или
|
||||
часовой пояс), мы надеемся аккуратно подтолкнуть дистрибутивы в
|
||||
правильно направлении (см. предыдущую главу).
|
||||
правильном направлении (см. предыдущую главу).
|
||||
\item Добавьте их поддержку в штатную систему настройки демона через
|
||||
собственные файлы конфигурации. К счастью, большинство служб,
|
||||
работающих в Linux, являются свободным программным обеспечением,
|
||||
@@ -2112,8 +2121,8 @@ systemd?
|
||||
время: необходимо обеспечить совместимость при обновлении. Тем не~менее, как
|
||||
минимум в новых пакетах, от таких файлов лучше отказаться.
|
||||
|
||||
Если требование совместимости критично, вы можете задействовать эти
|
||||
конфигурационные файлы даже в том случае, если настраиваете службы через
|
||||
В том случае, если требование совместимости критично, вы можете задействовать
|
||||
эти конфигурационные файлы даже в том случае, если настраиваете службы через
|
||||
штатные unit-файлы systemd. Если ваш файл из +sysconfig+ содержит лишь
|
||||
определения переменных, можно воспользоваться опцией
|
||||
+EnvironmentFile=-/etc/sysconfig/foobar+ (подробнее об этой опции см.
|
||||
@@ -2176,7 +2185,7 @@ systemd?
|
||||
|
||||
Получив такую команду, systemd сначала пытается найти файл конфигурации юнита с
|
||||
именем, точно соответствующим запрошенному. Если такой файл найти не~удается
|
||||
(при работе с экземплярами сервисов обычно так и происходит), из имени файла
|
||||
(при работе с экземплярами служб обычно так и происходит), из имени файла
|
||||
удаляется идентификатор экземпляра, и полученное имя используется при поиске
|
||||
\emph{шаблона} конфигурации. В нашем случае, если отсутствует файл с именем
|
||||
+serial-getty@ttyUSB0.service+, используется файл-шаблон под названием
|
||||
@@ -2200,7 +2209,7 @@ RestartSec=0
|
||||
параметры конфигурации, обеспечивающие совместимость с SysV, очистку экрана и
|
||||
удаление предыдущих пользователей с текущего TTY. Если вам интересно, можете
|
||||
посмотреть
|
||||
\href{http://cgit.freedesktop.org/systemd/plain/units/serial-getty@.service.m4}{полную
|
||||
\href{http://cgit.freedesktop.org/systemd/systemd/plain/units/serial-getty@.service.m4}{полную
|
||||
версию}.)
|
||||
|
||||
Этот файл похож на обычный файл конфигурации юнита, с единственным отличием: в
|
||||
@@ -2208,7 +2217,7 @@ RestartSec=0
|
||||
заменяет эти спецификаторы на идентификатор экземпляра службы. В нашем случае,
|
||||
при обращении к экземпляру +serial-getty@ttyUSB0.service+, они заменяются на
|
||||
<<+ttyUSB0+>>. Результат такой замены можно проверить, например, запросив
|
||||
состояние для этой службы:
|
||||
состояние для нашей службы:
|
||||
\begin{Verbatim}[commandchars=\\\{\}]
|
||||
$ systemctl status serial-getty@ttyUSB0.service
|
||||
serial-getty@ttyUSB0.service - Getty on ttyUSB0
|
||||
@@ -2239,7 +2248,7 @@ systemd предоставляет простой в использовании
|
||||
|
||||
Иногда возникает необходимость отказаться от использования общего шаблона
|
||||
для конкретного экземпляра (т.е. конфигурация данного экземпляра настолько
|
||||
сильно отличается от конфигурации остальных экземпляров данной службы, что
|
||||
сильно отличается от параметров остальных экземпляров данной службы, что
|
||||
механизм шаблонов оказывается неэффективен). Специально для таких случаев, в
|
||||
systemd и заложен предварительный поиск файла с именем, точно соответствующим
|
||||
указанному (прежде чем использовать общий шаблон). Таким образом, вы можете
|
||||
@@ -2278,11 +2287,10 @@ systemd и заложен предварительный поиск файла
|
||||
одноименному устройству). В то время как +%I+ удобно использовать в командной
|
||||
строке (+ExecStart+) и для формирования читабельных строк описания. Рассмотрим
|
||||
работу этих принципов на примере нашего юнит-файла\footnote{Прим. перев.: как
|
||||
видно из нижеприведенного примера, в командной строке +systemctl+ необходимо
|
||||
указывать экранированное имя юнита, что создает определенные трудности даже при
|
||||
наличии в оболочке <<умного>> автодополнения. Однако, на момент написания этих
|
||||
строк, в TODO проекта содержится пункт о добавлении в systemctl поддержки
|
||||
неэкранированных имен юнитов.}:
|
||||
видно из нижеприведенного примера, в командной строке +systemctl+ используется
|
||||
экранированное имя юнита, что создает определенные трудности даже при
|
||||
наличии в оболочке <<умного>> автодополнения. Однако, начиная с systemd v186,
|
||||
при работе с +systemctl+ можно указывать неэкранированные имена юнитов.}:
|
||||
\begin{landscape}
|
||||
\begin{Verbatim}[fontsize=\small,commandchars=|\{\}]
|
||||
# systemctl start 'serial-getty@serial-by\x2dpath-pci\x2d0000:00:1d.0\x2dusb\x2d0:1.4:1.1\x2dport0.service'
|
||||
@@ -2351,7 +2359,7 @@ systemd прежде всего ориентирована на локальны
|
||||
передавать запускаемой службе только один сокет, который формируется из потоков
|
||||
STDIN и STDOUT запущенного процесса. Поддержка этого механизма также
|
||||
присутствует в systemd~--- для обеспечения совместимости со множеством служб,
|
||||
поддерживающих сокет-активацию только в стиле inetd.
|
||||
у которых сокет-активация реализована только в стиле inetd.
|
||||
|
||||
Прежде, чем мы перейдем к примерам, рассмотрим три различных схемы, использующих
|
||||
сокет-активацию:
|
||||
@@ -2372,7 +2380,7 @@ STDIN и STDOUT запущенного процесса. Поддержка эт
|
||||
действительно понадобится. Пример~--- CUPS.
|
||||
\item \textbf{Сокет-активация для служб, запускающих по экземпляру на
|
||||
каждое соединение:} сокеты создаются на ранней стадии загрузки,
|
||||
и при каждом входящем соединении создается экземпляр службы,
|
||||
и при каждом входящем соединении запускается экземпляр службы,
|
||||
которому передается сокет соединения (слушающий сокет при этом
|
||||
остается у суперсервера, inetd или systemd). Эта схема подходит
|
||||
для редко используемых служб, не~критичных по производительности
|
||||
@@ -2409,12 +2417,12 @@ STDIN и STDOUT запущенного процесса. Поддержка эт
|
||||
большинстве систем, где она используется, частота обращений к ней не~превышает
|
||||
одного раза в час (как правило, она \emph{значительно} меньше этой величины).
|
||||
SSH уже очень давно поддерживает сокет-активацию в стиле inetd, согласно третьей
|
||||
схеме. Так как необходимость в этой службе возникает сравнительно редко, и
|
||||
схеме. Так как необходимость в данной службе возникает сравнительно редко, и
|
||||
число одновременно работающих процессов обычно невелико, она хорошо подходит для
|
||||
использования по этой схеме. Перерасход системных ресурсов должен быть
|
||||
незначителен: большую часть времени такая служба фактически не~выполняется и
|
||||
не~тратит ресурсы. Когда кто-либо начинает сеанс удаленной работы, она
|
||||
запускается, и останавливается немедленно по завершению сеанса, освобождая
|
||||
запускается, и останавливается немедленно по завершении сеанса, освобождая
|
||||
ресурсы. Что ж, посмотрим, как в systemd можно воспользоваться режимом
|
||||
совместимости с inetd и обеспечить сокет-активацию SSH.
|
||||
|
||||
@@ -2442,7 +2450,7 @@ service ssh {
|
||||
Подобный подход был некогда весьма популярен в Unix, но сейчас он уже постепенно
|
||||
выходит из моды, и поэтому в современных версиях xinetd поддерживается возможность
|
||||
явного указания номера порта. Одна из наиболее интересных настроек названа
|
||||
не~очень очевидно~--- +nowait+ (+wait=no+). Она определяет, будет ли служба
|
||||
не~вполне очевидно~--- +nowait+ (+wait=no+). Она определяет, будет ли служба
|
||||
работать по второй (+wait+) или третьей (+nowait+) схеме. И наконец, ключ +-i+
|
||||
активирует inetd-режим в SSH-сервере (без этого ключа он работает в независимом
|
||||
режиме).
|
||||
@@ -2564,23 +2572,36 @@ sshd.socket loaded active listening SSH So
|
||||
В завершение нашей дискуссии, сравним возможности xinetd и systemd, и выясним,
|
||||
может ли systemd полностью заменить xinetd, или нет. Вкратце: systemd
|
||||
поддерживает далеко не~все возможности xinetd и поэтому отнюдь не~является его
|
||||
полноценной заменой на все случаи жизни. В частности, если вы загляните в
|
||||
полноценной заменой на все случаи жизни. В частности, если вы заглянете в
|
||||
\href{http://linux.die.net/man/5/xinetd.conf}{список параметров конфигурации}
|
||||
xinetd, вы заметите, что далеко не~все эти опции доступны в systemd. Например, в
|
||||
systemd нет и никогда не~будет встроенных служб +echo+, +time+, +daytime+,
|
||||
+discard+ и т.д. Кроме того, systemd не~поддерживает TCPMUX и RPC. Впрочем,
|
||||
большинство этих опций уже не~актуальны в наше время. Подавляющее большинство
|
||||
inetd-служб не~используют эти опции (в частности, ни~одна из имеющихся в Fedora
|
||||
xinetd-служб не~требует поддержки перечисленных опций). Стоит отметить, что
|
||||
xinetd имеет некоторые интересные возможности, отсутствующие в systemd,
|
||||
например, списки контроля доступа для IP-адресов (IP ACL). Однако, большинство
|
||||
администраторов, скорее всего, согласятся, что настройка барндмауэра является
|
||||
более эффективным решением подобных задач, а для ценителей устаревших технологий
|
||||
systemd предлагает поддержку tcpwrap. С другой стороны, systemd тоже
|
||||
предоставляет ряд возможностей, отсутствующих в xinetd, в частности,
|
||||
индивидуальный контроль над каждым экземпляром службы (см. выше), и куда более
|
||||
полный
|
||||
\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{список настроек}
|
||||
б\'{о}льшая часть этих опций уже не~актуальна в наше время. Подавляющее
|
||||
большинство inetd-служб не~используют эти опции (в частности, ни~одна из
|
||||
имеющихся в Fedora xinetd-служб не~требует поддержки перечисленных опций). Стоит
|
||||
отметить, что xinetd имеет некоторые интересные возможности, отсутствующие в
|
||||
systemd, например, списки контроля доступа для IP-адресов (IP ACL). Однако,
|
||||
большинство администраторов, скорее всего, согласятся, что настройка брандмауэра
|
||||
является более эффективным решением подобных задач\footnote{Прим. перев.: Стоит
|
||||
отметить, что приведенный пример является не~единственным случаем, когда
|
||||
возможности брандмауэра Linux дублируются опциями xinetd. Например, количество
|
||||
соединений с каждого хоста может быть ограничено критерием connlimit, а
|
||||
скорость поступления входящих соединений можно контролировать сочетанием
|
||||
критериев limit и conntrack (+ctstate NEW+). Критерий recent позволяет создать
|
||||
аналог простейшей IDS/IPS, реализованной механизмом SENSORS в xinetd. Кроме
|
||||
того, в ряде случаев возможности брандмауэра значительно превосходят
|
||||
функциональность xinetd. Например, критерий hashlimit, опять-таки в сочетании с
|
||||
conntrack, позволяет ограничить скорость поступления входящих соединений с
|
||||
каждого хоста (не~путать с критерием connlimit, ограничивающим количество
|
||||
одновременно открытых соединений). Также стоит отметить, что интегрированная в
|
||||
Linux подсистема ipset гораздо лучше подходит для работы с большими списками
|
||||
разрешенных/запрещенных адресов, нежели встроенные механизмы xinetd.}, а для
|
||||
ценителей устаревших технологий systemd предлагает поддержку tcpwrap. С другой
|
||||
стороны, systemd тоже предоставляет ряд возможностей, отсутствующих в xinetd, в
|
||||
частности, индивидуальный контроль над каждым экземпляром службы (см. выше), и
|
||||
внушительный
|
||||
\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{набор настроек}
|
||||
для контроля окружения, в котором запускаются экземпляры. Я надеюсь, что
|
||||
возможностей systemd должно быть достаточно для решения большинства задач, а в
|
||||
тех редких случаях, когда вам потребуются специфические опции xinetd~--- ничто
|
||||
@@ -2594,6 +2615,589 @@ systemd предлагает поддержку tcpwrap. С другой сто
|
||||
systemd. Но, конечно, будет лучше, если этим займутся разработчики из апстрима
|
||||
приложения, или сопровождающие вашего дистрибутива.
|
||||
|
||||
\section{К вопросу о безопасности}
|
||||
|
||||
Одно из важнейших достоинств Unix-систем~--- концепция разделения привилегий
|
||||
между различными компонентами ОС. В частности, службы обычно работают от имени
|
||||
специальных системных пользователей, имеющих ограниченные полномочия, что
|
||||
позволяет уменьшить ущерб для системы в случае взлома этих служб.
|
||||
|
||||
Однако, такой подход предоставляет лишь самую минимальную защиту, так как
|
||||
системные службы, хотя уже и не~получают полномочий администратора (root), все
|
||||
равно имеют практически те же права, что и обычные пользователи. Чтобы
|
||||
обеспечить более эффективную защиту, нужно поставить более жесткие ограничения,
|
||||
отняв у служб некоторые привилегии, присущие обычным пользователям.
|
||||
|
||||
Такая возможность предоставляется системами мандатного контроля доступа (далее
|
||||
MAC, от Mandatory Access Control), например, SELinux. Если вам нужно обеспечить
|
||||
высокий уровень безопасности на своем сервере, то вам определенно стоит обратить
|
||||
свое внимание на SELinux. Что же касается systemd, то он предоставляет
|
||||
разработчикам и администраторам целый арсенал возможностей по ограничению
|
||||
локальных служб, и эти механизмы работают независимо от систем MAC. Таким
|
||||
образом, вне зависимости от того, смогли ли вы разобраться с SELinux~--- у вас
|
||||
появляется еще несколько инструментов, позволяющих повысить уровень
|
||||
безопасности.
|
||||
|
||||
В этой главе мы рассмотрим несколько таких опций, предоставляемых systemd, и
|
||||
обсудим вопросы их практического применения. Реализация этих опций основана на
|
||||
использовании ряда уникальных технологий безопасности, интегрированных в ядро
|
||||
Linux уже очень давно, но при этом практически неизвестных для большинства
|
||||
разработчиков. Мы постарались сделать соответствующие опции systemd максимально
|
||||
простыми в использовании, чтобы заинтересовать администраторов и апстримных
|
||||
разработчиков. Вот краткий перечень наиболее интересных возможностей:
|
||||
\begin{itemize}
|
||||
\item Изолирование служб от сети
|
||||
\item Предоставление службам независимых каталогов +/tmp+
|
||||
\item Ограничение доступа служб к отдельным каталогам
|
||||
\item Принудительное отключение полномочий (capabilities) для служб
|
||||
\item Запрет форка, ограничение на создание файлов
|
||||
\item Контроль доступа служб к файлам устройств
|
||||
\end{itemize}
|
||||
|
||||
Все эти опции описаны в man-страницах systemd, главным образом, в
|
||||
\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}.
|
||||
Если вам потребуются какие-либо уточнения, пожалуйста, обратитесь к этим
|
||||
страницам.
|
||||
|
||||
Все эти опции доступны на системах с systemd, вне зависимости от использования
|
||||
SELinux или любой другой реализации MAC.
|
||||
|
||||
Все эти опции не~так уж и обременительны, и поэтому их разумнее будет
|
||||
использовать даже в тех случаях, когда явная необходимость в них, казалось бы,
|
||||
отсутствует. Например: даже если вы полагаете, что ваша служба никогда не~пишет
|
||||
в каталог +/tmp+, и поэтому использование +PrivateTmp=yes+ (см. ниже) вроде бы и
|
||||
не~обязательно~--- лучше включить эту опцию, просто потому, что вы не~можете
|
||||
знать наверняка, как будут вести себя используемые вами сторонние библиотеки (и
|
||||
плагины для них). В частности, вы никогда не~узнаете, какие модули NSS могут
|
||||
быть включены в каждой конкретной системе, и пользуются ли они каталогом +/tmp+.
|
||||
|
||||
Мы надеемся, что перечисленные опции окажутся полезными как для администраторов,
|
||||
защищающих свои системы, так и для апстримных разработчиков, желающих сделать
|
||||
свои службы безопасными <<из коробки>>. Мы настоятельно рекомендуем
|
||||
разработчикам использовать такие опции по умолчанию в апстримных
|
||||
service-файлах~--- это сравнительно несложно, но дает значительные преимущества
|
||||
в плане безопасности.
|
||||
|
||||
\subsection{Изолирование служб от сети}
|
||||
|
||||
Простая, но мощная опция, которой вы можете воспользоваться при настройке
|
||||
службы~--- +PrivateNetwork=+:
|
||||
\begin{Verbatim}
|
||||
...
|
||||
[Service]
|
||||
ExecStart=...
|
||||
PrivateNetwork=yes
|
||||
...
|
||||
\end{Verbatim}
|
||||
Добавление этой строчки обеспечивает полную изоляцию от сети всех процессов
|
||||
данной службы. Они будут видеть лишь интерфейс обратной петли (+lo+), причем
|
||||
полностью изолированный от обратной петли основной системы. Чрезвычайно
|
||||
эффективная защита против сетевых атак.
|
||||
|
||||
\begin{caveat}
|
||||
Некоторым службам сеть необходима для нормальной работы. Разумеется, никто и
|
||||
не~говорит о том, чтобы применять +PrivateNetwork=yes+ к сетевым службам, таким,
|
||||
как Apache. Однако даже те службы, которые не~ориентированы на сетевое
|
||||
взаимодействие, могут нуждаться в сети для нормального функционирования, и порой
|
||||
эта потребность не~вполне очевидна. Например, если ваша система хранит
|
||||
учетные записи пользователей в базе LDAP, для выполнения системных вызовов
|
||||
наподобие +getpwnam()+ может потребоваться обращение к сети. Впрочем, даже в
|
||||
такой ситуации, как правило, можно использовать +PrivateNetwork=yes+, за
|
||||
исключением случаев, когда службе может потребоваться информация о пользователях
|
||||
с UID~$\geq1000$.
|
||||
\end{caveat}
|
||||
|
||||
Если вас интересуют технические подробности: эта возможность реализована с
|
||||
использованием технологии сетевых пространств имен (network namespaces). При
|
||||
задействовании данной опции, для службы создается новое пространство имен, в
|
||||
котором настраивается только интерфейс обратной петли.
|
||||
|
||||
\subsection{Предоставление службам независимых каталогов \texttt{/tmp}}
|
||||
|
||||
Еще одна простая, но мощная опция настройки служб~--- +PrivateTmp=+:
|
||||
\begin{Verbatim}
|
||||
...
|
||||
[Service]
|
||||
ExecStart=...
|
||||
PrivateTmp=yes
|
||||
...
|
||||
\end{Verbatim}
|
||||
При задействовании этой опции, служба получит свой собственный каталог +/tmp+,
|
||||
полностью изолированный от общесистемного +/tmp+. По давно сложившейся традиции,
|
||||
в Unix-системах каталог +/tmp+ является общедоступным для всех локальных служб и
|
||||
пользователей. За все эти годы, он стал источником огромного количества проблем
|
||||
безопасности. Чаще всего встречаются атаки с использованием символьных ссылок
|
||||
(symlink attacks) и атаки на отказ в обслуживании (DoS attacks). Использование
|
||||
независимой версии данного каталога для каждой службы делает подобные уязвимости
|
||||
практически бесполезными.
|
||||
|
||||
Для релиза Fedora~17
|
||||
\href{https://fedoraproject.org/wiki/Features/ServicesPrivateTmp}{утверждена}
|
||||
инициатива, направленная на включение этой опции по умолчанию для большинства
|
||||
системных служб.
|
||||
|
||||
\begin{caveat}
|
||||
Некоторые службы используют +/tmp+ не~по назначению,
|
||||
помещая туда сокеты IPC и другие подобные элементы, что само по себе уже
|
||||
является уязвимостью (хотя бы потому, что используемые при передаче информации
|
||||
файлы и каталоги должны иметь предсказуемые имена, что делает подобные службы
|
||||
уязвимыми к атакам через символьные ссылки и атакам на отказ в обслуживании).
|
||||
Подобные объекты лучше помещать в каталог +/run+, так как в нем присутствует
|
||||
строгое разделение доступа. В качестве примера такого некорректного
|
||||
использования +/tmp+ можно привести X11, размещающий там свои коммуникационные
|
||||
сокеты (впрочем, в данном конкретном случае некоторые меры безопасности все же
|
||||
присутствуют: сокеты размещаются в защищенном подкаталоге, который создается на
|
||||
ранних стадиях загрузки). Разумеется, для служб, использующих +/tmp+ в целях
|
||||
коммуникации, включение опции +PrivateTmp=yes+ недопустимо. К счастью, таких
|
||||
служб сейчас уже не~так уж и много.
|
||||
\end{caveat}
|
||||
|
||||
Эта опция использует технологию пространств имен файловых систем (filesystem
|
||||
namespaces), реализованную в Linux. При включении данной опции, для службы
|
||||
создается новое пространство имен, отличающееся от иерархии каталогов основной
|
||||
системы только каталогом +/tmp+.
|
||||
|
||||
\subsection{Ограничение доступа служб к отдельным каталогам}
|
||||
|
||||
Используя опции +ReadOnlyDirectories=+ и +InaccessibleDirectories=+, вы можете
|
||||
ограничить доступ службы к указанным каталогам только чтением, либо вообще
|
||||
запретить его:
|
||||
\begin{Verbatim}
|
||||
...
|
||||
[Service]
|
||||
ExecStart=...
|
||||
InaccessibleDirectories=/home
|
||||
ReadOnlyDirectories=/var
|
||||
...
|
||||
\end{Verbatim}
|
||||
Добавление этих двух строчек в файл конфигурации, приводит к тому, что служба
|
||||
полностью утрачивает доступ к содержимому каталога +/home+ (она видит лишь
|
||||
пустой каталог с правами доступа 000), а также не~может писать внутрь каталога
|
||||
+/var+.
|
||||
|
||||
\begin{caveat}
|
||||
К сожалению, в настоящее время опция +ReadOnlyDirectories=+ не~применяется
|
||||
рекурсивно к точкам монтирования, расположенным в поддереве указанного каталога
|
||||
(т.е. файловые системы, смонтированные в подкаталогах +/var+, по-прежнему
|
||||
останутся доступными на запись, если, конечно, не~перечислить их все поименно).
|
||||
Мы собираемся исправить это в ближайшее время.
|
||||
\end{caveat}
|
||||
|
||||
Механизм работы этой опции тоже реализован с использованием пространств имен
|
||||
файловых систем.
|
||||
|
||||
\subsection{Принудительное отключение полномочий (capabilities) для служб}
|
||||
|
||||
Еще одна чрезвычайно эффективная опция~--- +CapabilityBoundingSet=+, позволяющая
|
||||
контролировать список capabilities, которые смогут получить процессы службы:
|
||||
\begin{Verbatim}
|
||||
...
|
||||
[Service]
|
||||
ExecStart=...
|
||||
CapabilityBoundingSet=CAP_CHOWN CAP_KILL
|
||||
...
|
||||
\end{Verbatim}
|
||||
В нашем примере, служба может иметь лишь полномочия +CAP_CHOWN+ и +CAP_KILL+.
|
||||
Попытки какого-либо из процессов службы получить любые другие полномочия, даже с
|
||||
использованием suid-бинарников, будут пресекаться. Список возможных полномочий
|
||||
приведен на странице документации
|
||||
\href{http://linux.die.net/man/7/capabilities}{capabilities(7)}. К сожалению,
|
||||
некоторые из них являются слишком общими (разрешают очень многое), например,
|
||||
+CAP_SYS_ADMIN+, однако выборочное делегирование полномочий все же является
|
||||
неплохой альтернативой запуску службы с полными административными (рутовыми)
|
||||
привилегиями.
|
||||
|
||||
Как правило, определение списка полномочий, необходимых для работы конкретной
|
||||
службы, является довольно трудоемким процессом, требующим ряда проверок. Чтобы
|
||||
немного упростить эту задачу, мы добавили возможность создания <<черного
|
||||
списка>> привилегий, как альтернативы описанному выше механизму <<белого
|
||||
списка>>. Вместо того, чтобы указывать, какие привилегии можно оставить, вы
|
||||
можете перечислить, какие из них оставлять точно нельзя. Например: привилегия
|
||||
+CAP_SYS_PTRACE+, предназначенная для отладчиков, дает очень широкие полномочия
|
||||
в отношении всех процессов системы. Очевидно, что такие службы, как Apache,
|
||||
не~занимаются отладкой чужих процессов, и поэтому мы можем спокойно отнять у них
|
||||
данную привилегию:
|
||||
\begin{Verbatim}
|
||||
...
|
||||
[Service]
|
||||
ExecStart=...
|
||||
CapabilityBoundingSet=~CAP_SYS_PTRACE
|
||||
...
|
||||
\end{Verbatim}
|
||||
Наличие символа +~+ после знака равенства инвертирует принцип работы опции:
|
||||
следующий за ним перечень привилегий рассматривается уже не~как белый, а как
|
||||
черный список.
|
||||
|
||||
\begin{caveat}
|
||||
Некоторые службы, при отсутствии определенных привилегий, могут вести себя
|
||||
некорректно. Как уже говорилось выше, формирование списка необходимых полномочий
|
||||
для каждой конкретной службы может оказаться довольно трудной задачей, и лучше
|
||||
всего будет обратиться с соответствующим запросом к разработчикам службы.
|
||||
\end{caveat}
|
||||
|
||||
\begin{caveat}[~2]
|
||||
\href{https://forums.grsecurity.net/viewtopic.php?f=7&t=2522}{Привилегии~---
|
||||
отнюдь не~лекарство от всех бед.} Чтобы они работали действительно эффективно,
|
||||
возможно, придется дополнить их другими методиками защиты.
|
||||
\end{caveat}
|
||||
|
||||
Чтобы проверить, какие именно привилегии имеют сейчас ваши процессы, вы можете
|
||||
воспользоваться программой +pscap+ из комплекта +libcap-ng-utils+.
|
||||
|
||||
Применение опции +CapabilityBoundingSet=+ является простой, прозрачной и удобной
|
||||
альтернативой введению аналогичных ограничений через модификацию исходного кода
|
||||
всех системных служб.
|
||||
|
||||
\subsection{Запрет форка, ограничение на создание файлов}
|
||||
|
||||
Некоторые меры безопасности можно ввести при помощи механизма ограничения
|
||||
ресурсов. Как следует из его названия, этот механизм предназначен прежде всего
|
||||
для контроля использования ресурсов, а не~для контроля доступа. Однако, две его
|
||||
настройки могут быть использованы для запрета определенных действий:
|
||||
с помощью +RLIMIT_NPROC+ можно запретить службе форкаться (запускать
|
||||
дополнительные процессы), а +RLIMIT_FSIZE+ позволяет блокировать запись в файлы
|
||||
ненулевого размера:
|
||||
\begin{Verbatim}
|
||||
...
|
||||
[Service]
|
||||
ExecStart=...
|
||||
LimitNPROC=1
|
||||
LimitFSIZE=0
|
||||
...
|
||||
\end{Verbatim}
|
||||
Обратите внимание, что эти ограничения будут эффективно работать только в том
|
||||
случае, если служба будет работать от имени простого пользователя (не~root) и
|
||||
без привилегии +CAP_SYS_RESOURCE+ (блокирование этой привилегии можно
|
||||
обеспечить, например, описанной выше опцией +CapabilityBoundingSet=+). В
|
||||
противном случае, ничто не~мешает процессу поменять соответствующие ограничения.
|
||||
|
||||
\begin{caveat}
|
||||
+LimitFSIZE=+ действует очень жестко. Если процесс пытается записать файл
|
||||
ненулевого размера, он немедленно получает сигнал +SIGXFSZ+, который, как
|
||||
правило, прекращает работу процесса (в случае, если не~назначен обработчик
|
||||
сигнала). Кроме того, стоит отметить, что эта опция не~запрещает создание файлов
|
||||
нулевого размера.
|
||||
\end{caveat}
|
||||
|
||||
Подробности об этих и других опциях ограничения ресурсов можно уточнить на
|
||||
странице документации \href{http://linux.die.net/man/2/setrlimit}{setrlimit(2)}.
|
||||
|
||||
\subsection{Контроль доступа служб к файлам устройств}
|
||||
|
||||
Файлы устройств предоставляют приложениям интерфейс для доступа к ядру и
|
||||
драйверам. Причем драйверы, как правило, менее тщательно тестируются и не~так
|
||||
аккуратно проверяются на предмет наличия уязвимостей, по сравнению с основными
|
||||
компонентами ядра. Именно поэтому драйверы часто становятся объектами атаки
|
||||
злоумышленников. systemd позволяет контролировать доступ к устройствам
|
||||
индивидуально для каждой службы:
|
||||
\begin{Verbatim}
|
||||
...
|
||||
[Service]
|
||||
ExecStart=...
|
||||
DeviceAllow=/dev/null rw
|
||||
...
|
||||
\end{Verbatim}
|
||||
Приведенная конфигурация разрешит службе доступ только к файлу +/dev/null+,
|
||||
запретив доступ ко всем остальным файлам устройств.
|
||||
|
||||
Реализация данной опции построена на использовании cgroups-контроллера
|
||||
+devices+.
|
||||
|
||||
\subsection{Прочие настройки}
|
||||
|
||||
Помимо приведенных выше, простых и удобных в использовании опций, существует и
|
||||
ряд других других настроек, позволяющих повысить уровень безопасности. Но
|
||||
для их использования, как правило, уже требуются определенные изменения в
|
||||
исходном коде службы, и поэтому такие настройки представляют интерес прежде
|
||||
всего для апстримных разработчиков. В частности, сюда относится опция
|
||||
+RootDirectory=+ (позволяющая запустить службу +chroot()+-окружении), а также
|
||||
параметры +User=+ и +Group=+, определяющие пользователя и группу, от имени
|
||||
которых работает служба. Использование этих опций значительно упрощает
|
||||
написание демонов, так как работа по понижению привилегий ложится на плечи
|
||||
systemd.
|
||||
|
||||
Возможно, у вас возникнет вопрос, почему описанные выше опции не~включены по
|
||||
умолчанию. Отвечаем: чтобы не~нарушать совместимость. Многие из них несколько
|
||||
отступают от традиций, принятых в Unix. Например, исторически сложилось, так что
|
||||
+/tmp+ является общим для всех процессов и пользователей. Существуют программы,
|
||||
использующие этот каталог для IPC, и включение по умолчанию режима изоляции для
|
||||
+/tmp+ нарушит работу таких программ.
|
||||
|
||||
И несколько слов в заключение. Если вы занимаетесь сопровождением unit-файлов
|
||||
в апстримном проекте или в дистрибутиве, пожалуйста, подумайте о том, чтобы
|
||||
воспользоваться приведенными выше настройками. Если сопровождаемая вами служба
|
||||
станет более защищенной в конфигурации по умолчанию (<<из коробки>>), от этого
|
||||
выиграют не~только ваши пользователи, но и все мы, потому что Интернет станет
|
||||
чуть более безопасным.
|
||||
|
||||
\section{Отчет о состоянии службы и ее журнал}
|
||||
|
||||
При работе с системами, использующими systemd, одной из наиболее важных и часто
|
||||
используемых команд является +systemctl status+. Она выводит отчет о состоянии
|
||||
службы (или другого юнита). В таком отчете приводится статус службы (работает
|
||||
она или нет), список ее процессов и другая полезная информация.
|
||||
|
||||
В Fedora~17 мы ввели
|
||||
\href{http://0pointer.de/blog/projects/the-journal.html}{Journal}, новую
|
||||
реализацию системного журнала, обеспечивающую структурированное, индексированное
|
||||
и надежное журналирование, при сохранении совместимости с классическими
|
||||
реализациями syslog. Собственно, мы начали работу над~Journal только потому, что
|
||||
хотели добавить одну, казалось бы, простую, возможность: включить в вывод
|
||||
+systemctl status+ последние 10 сообщений, поступивших от службы в системный
|
||||
журнал. Но на практике оказалось, что в рамках классических механизмов syslog,
|
||||
реализация этой возможности чрезвычайно сложна и малоэффективна. С другой
|
||||
стороны, сообщения службы в системный журнал несут очень важную информацию о ее
|
||||
состоянии, и такая возможность действительно была бы очень полезной, особенно
|
||||
при диагностике нештатных ситуаций.
|
||||
|
||||
Итак, мы интегрировали Journal в systemd, и научили +systemctl+ работать с ним.
|
||||
Результат выглядит примерно так:
|
||||
\begin{Verbatim}[fontsize=\small,commandchars=\\\{\}]
|
||||
$ systemctl status avahi-daemon.service
|
||||
avahi-daemon.service - Avahi mDNS/DNS-SD Stack
|
||||
Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; enabled)
|
||||
Active: active (running) since Fri, 18 May 2012 12:27:37 +0200; 14s ago
|
||||
Main PID: 8216 (avahi-daemon)
|
||||
Status: "avahi-daemon 0.6.30 starting up."
|
||||
CGroup: name=systemd:/system/avahi-daemon.service
|
||||
\mytextSFii{} 8216 avahi-daemon: running [omega.local]
|
||||
\mytextSFii{} 8217 avahi-daemon: chroot helper
|
||||
|
||||
May 18 12:27:37 omega avahi-daemon[8216]: Joining mDNS multicast group on interface eth1.IPv4 with address 172.31.0.52.
|
||||
May 18 12:27:37 omega avahi-daemon[8216]: New relevant interface eth1.IPv4 for mDNS.
|
||||
May 18 12:27:37 omega avahi-daemon[8216]: Network interface enumeration completed.
|
||||
May 18 12:27:37 omega avahi-daemon[8216]: Registering new address record for 192.168.122.1 on virbr0.IPv4.
|
||||
May 18 12:27:37 omega avahi-daemon[8216]: Registering new address record for fd00::e269:95ff:fe87:e282 on eth1.*.
|
||||
May 18 12:27:37 omega avahi-daemon[8216]: Registering new address record for 172.31.0.52 on eth1.IPv4.
|
||||
May 18 12:27:37 omega avahi-daemon[8216]: Registering HINFO record with values 'X86_64'/'LINUX'.
|
||||
May 18 12:27:38 omega avahi-daemon[8216]: Server startup complete. Host name is omega.local. Local service cookie is 3555095952.
|
||||
May 18 12:27:38 omega avahi-daemon[8216]: Service "omega" (/services/ssh.service) successfully established.
|
||||
May 18 12:27:38 omega avahi-daemon[8216]: Service "omega" (/services/sftp-ssh.service) successfully established.
|
||||
\end{Verbatim}
|
||||
Очевидно, это отчет о состоянии всеми любимого демона mDNS/DNS-SD, причем после
|
||||
списка процессов, как мы и обещали, приведены сообщения этого демона в системный
|
||||
журнал. Миссия выполнена!
|
||||
|
||||
Команда +systemctl status+ поддерживает ряд опций, позволяющих настроить вывод
|
||||
информации в соответствии с вашими пожеланиями. Отметим две наиболее интересные
|
||||
из них: ключ +-f+ позволяет в реальном времени отслеживать обновление сведений
|
||||
(по аналогии с +tail -f+), а ключ +-n+ задает количество выводимых журнальных
|
||||
записей (как нетрудно догадаться, по аналогии с +tail -n+).
|
||||
|
||||
Журнальные записи собираются из трех различных источников. Во-первых, это
|
||||
сообщения службы в системный журнал, отправленные через функцию libc
|
||||
+syslog()+. Во-вторых, это сообщения, отправленные через штатный API системы
|
||||
Journal. И наконец, это весь текст, выводимый демоном в STDOUT и STDERR. Проще
|
||||
говоря, все, что демон считает нужным сказать администратору, собирается,
|
||||
упорядочивается и отображается в одинаковом формате.
|
||||
|
||||
Добавленная нами возможность, при всей своей простоте, может оказаться
|
||||
чрезвычайно полезной практически любому администратору. По-хорошему, ее стоило
|
||||
реализовать еще 15 лет назад.
|
||||
|
||||
\section{Самодокументированный процесс загрузки}
|
||||
|
||||
Нам часто приходится слышать жалобы, что процесс загрузки при использовании
|
||||
systemd очень сложен для понимания. Не~могу с этим согласиться. Более того, я
|
||||
берусь даже утверждать обратное: по сравнению с тем, что мы имели раньше (когда
|
||||
для того, чтобы разобраться в загрузке, нужно было иметь хорошие навыки
|
||||
программирования на языке Bourne Shell\footnote{Чья привлекательность очень
|
||||
коварна и обманчива.}), процесс загрузки стал более простым и прозрачным. Но
|
||||
определенная доля истины в этом критическом замечании все же есть: даже опытному
|
||||
Unix-администратору при переходе на systemd нужно изучить некоторые новые для
|
||||
себя вещи. Мы, разработчики systemd, обязаны максимально упростить такое
|
||||
обучение. Решая поставленную задачу, мы подготовили для вас кое-какие приятные
|
||||
сюрпризы, и предоставили хорошую документацию даже там, где это казалось
|
||||
невозможным.
|
||||
|
||||
Уже сейчас systemd располагает довольно обширной документацией, включая
|
||||
\href{http://www.freedesktop.org/software/systemd/man/}{страницы руководства}
|
||||
(на данный момент, их около сотни),
|
||||
\href{http://www.freedesktop.org/wiki/Software/systemd}{wiki-сайт проекта}, а
|
||||
также ряд статей в моем блоге. Тем не~менее, большое количество документации еще
|
||||
не~гарантирует простоты понимания. Огромные груды руководств выглядят пугающе, и
|
||||
неподготовленный читатель не~может разобраться, с какого места ему начинать
|
||||
чтение, если его интересует просто общая концепция.
|
||||
|
||||
Чтобы решить данную проблему, мы добавили в systemd небольшую, но очень изящную
|
||||
возможность: самодокументированный\footnote{Прим. перев.: В оригинале
|
||||
использован термин <<self-explanatory>>, который также можно перевести как
|
||||
<<само-объясняющий>>, <<самоочевидный>>.} процесс загрузки. Что мы под этим
|
||||
подразумеваем? То, что для каждого элемента процесса загрузки теперь имеется
|
||||
документация, прозрачно привязанная к этому элементу, так что ее поиск
|
||||
не~представляет трудности.
|
||||
|
||||
Иными словами, все штатные юниты systemd (которые, собственно, и формируют
|
||||
процесс загрузки, вызывая соответствующие программы) включают ссылки на страницы
|
||||
документации, описывающие назначение юнита/программы, используемые ими
|
||||
конфигурационные файлы и т.д. Если пользователь хочет узнать, для чего
|
||||
предназначен какой-либо юнит, какова его роль в процессе загрузки и как его
|
||||
можно настроить, может получить ссылки на соответствующую документацию, просто
|
||||
воспользовавшись давно известной командой +systemctl status+. Возьмем для
|
||||
примера +systemd-logind.service+:
|
||||
\defhref{\logind}{http://www.freedesktop.org/software/systemd/man/systemd-logind.service.html}%
|
||||
{man:systemd-logind.service(7)}
|
||||
\begin{Verbatim}[fontsize=\small,commandchars=\\\{\}]
|
||||
$ systemctl status systemd-logind.service
|
||||
systemd-logind.service - Login Service
|
||||
Loaded: loaded (/usr/lib/systemd/system/systemd-logind.service; static)
|
||||
Active: active (running) since Mon, 25 Jun 2012 22:39:24 +0200; 1 day and 18h ago
|
||||
Docs: \logind{}
|
||||
\href{http://www.freedesktop.org/software/systemd/man/logind.conf.html}{man:logind.conf(5)}
|
||||
\url{http://www.freedesktop.org/wiki/Software/systemd/multiseat}
|
||||
Main PID: 562 (systemd-logind)
|
||||
CGroup: name=systemd:/system/systemd-logind.service
|
||||
\mytextSFii{} 562 /usr/lib/systemd/systemd-logind
|
||||
|
||||
Jun 25 22:39:24 epsilon systemd-logind[562]: Watching system buttons on /dev/input/event2 (Power Button)
|
||||
Jun 25 22:39:24 epsilon systemd-logind[562]: Watching system buttons on /dev/input/event6 (Video Bus)
|
||||
Jun 25 22:39:24 epsilon systemd-logind[562]: Watching system buttons on /dev/input/event0 (Lid Switch)
|
||||
Jun 25 22:39:24 epsilon systemd-logind[562]: Watching system buttons on /dev/input/event1 (Sleep Button)
|
||||
Jun 25 22:39:24 epsilon systemd-logind[562]: Watching system buttons on /dev/input/event7 (ThinkPad Extra Buttons)
|
||||
Jun 25 22:39:25 epsilon systemd-logind[562]: New session 1 of user gdm.
|
||||
Jun 25 22:39:25 epsilon systemd-logind[562]: Linked /tmp/.X11-unix/X0 to /run/user/42/X11-display.
|
||||
Jun 25 22:39:32 epsilon systemd-logind[562]: New session 2 of user lennart.
|
||||
Jun 25 22:39:32 epsilon systemd-logind[562]: Linked /tmp/.X11-unix/X0 to /run/user/500/X11-display.
|
||||
Jun 25 22:39:54 epsilon systemd-logind[562]: Removed session 1.
|
||||
\end{Verbatim}
|
||||
|
||||
На первый взгляд, в выводе этой команды почти ничего не~изменилось. Но если вы
|
||||
вглядитесь повнимательнее, то заметите новое поле +Docs+, в котором приведены
|
||||
ссылки на документацию по данной службе. В нашем случае случае это два URI,
|
||||
ссылающихся на man-страницы, и один URL, указывающий на веб-страницу.
|
||||
man-страницы описывают соответственно предназначение службы и ее настройки, а
|
||||
веб-страница~--- базовые концепции, которые реализуются этой службой.
|
||||
|
||||
Тем, кто использует современные графические эмуляторы терминала, чтобы открыть
|
||||
соответствующую страницу документации, достаточно щелкнуть мышью по
|
||||
URI\footnote{Для нормальной работы данной функции, в эмуляторе терминала должен
|
||||
быть исправлена \href{https://bugzilla.gnome.org/show_bug.cgi?id=676452}{эта
|
||||
ошибка}, а в программе просмотра страниц помощи~---
|
||||
\href{https://bugzilla.gnome.org/show_bug.cgi?id=676482}{вот эта}.}. Иными
|
||||
словами, доступ к документации компонентов загрузки становится предельно
|
||||
простым: достаточно вызвать +systemctl status+, после чего щелкнуть по
|
||||
полученным ссылкам.
|
||||
|
||||
Если же вы используете не~графический эмулятор терминала (где можно просто
|
||||
щелкнуть по URI), а настоящий терминал, наличие URI где-то в середине вывода
|
||||
+systemctl status+ вряд ли покажется вам удобным. Чтобы упростить обращение к
|
||||
соответствующим страницам документации без использования мыши и
|
||||
копирования/вставки, мы ввели новую команду
|
||||
\begin{Verbatim}
|
||||
systemctl help systemd-logind.service
|
||||
\end{Verbatim}
|
||||
которая просто откроет в вашем терминале соответствующие man-страницы.
|
||||
|
||||
URI, ссылающиеся на документацию, формируются в соответствии со страницей
|
||||
руководства
|
||||
\href{https://www.kernel.org/doc/man-pages/online/pages/man7/url.7.html}{uri(7)}.
|
||||
Поддерживаются схемы +http+/+https+ (URL для веб-страниц) и +man+/+info+
|
||||
(локальные страницы руководства).
|
||||
|
||||
Разумеется, добавленная нами возможность не~обеспечивает полной очевидности
|
||||
абсолютно всего, хотя бы потому, что пользователь должен как минимум знать про
|
||||
команду +systemctl status+ (а также вообще про программу +systemctl+ и про то,
|
||||
что такое юнит). Но при наличии этих базовых знаний, пользователю уже
|
||||
не~составит труда получить информацию по интересующим его вопросам.
|
||||
|
||||
Мы надеемся, что добавленный нами механизм для связи работающего кода и
|
||||
соответствующей документации станет значительным шагом к полностью прозрачному и
|
||||
предельно простому для понимания процессу загрузки.
|
||||
|
||||
Описанная функциональность частично присутствует в Fedora~17, а в полном
|
||||
объеме она будет представлена в Fedora~18.
|
||||
|
||||
В завершение, стоит отметить, что использованная нами идея не~является такой уж
|
||||
новой: в SMF, системе инициализации Solaris, уже используется практика
|
||||
добавления ссылок на документацию в описании службы. Однако, в Linux такой
|
||||
подход является принципиально новым, и systemd сейчас является наиболее
|
||||
документированной и прозрачной системой загрузки для данной платформы.
|
||||
|
||||
Если вы занимаетесь разработкой или сопровождением пакетов и создаете файл
|
||||
конфигурации юнита, пожалуйста, включите в него ссылки на документацию. Это
|
||||
очень просто: достаточно добавить в секции +[Unit]+ поле +Documentation=+ и
|
||||
перечислить в нем соответствующие URI. Подробнее об этом поле см. на странице
|
||||
руководства
|
||||
\href{http://www.freedesktop.org/software/systemd/man/systemd.unit.html}{systemd.unit(5)}.
|
||||
Чем больше будет документированных юнитов, тем проще станет работа системного
|
||||
администратора. (В частности, я уже направил в FPC
|
||||
\href{https://fedorahosted.org/fpc/ticket/192}{предложение} внести
|
||||
соответствующие пожелания в нормативные документы, регулирующие подготовку
|
||||
пакетов для Fedora.)
|
||||
|
||||
Да, кстати: если вас интересует общий обзор процесса загрузки systemd, то вам
|
||||
стоит обратить внимание на
|
||||
\href{http://www.freedesktop.org/software/systemd/man/bootup.html}{новую
|
||||
страницу руководства}, где представлена псевгдорафическая потоковая диаграмма,
|
||||
описывающая процесс загрузки и роль ключевых юнитов.
|
||||
|
||||
\section{Сторожевые таймеры}
|
||||
|
||||
Разрабатывая systemd, мы ориентируемся на три основных области его применения:
|
||||
мобильные/встраиваемые устройства, настольные системы и промышленные серверы.
|
||||
Мобильные и встраиваемые системы, как правило, располагают очень скромными
|
||||
ресурсами и вынуждены очень экономно расходовать энергию. Настольные системы
|
||||
куда менее ограничены по мощности но, тем не~менее, все же проигрывают в этом
|
||||
плане промышленным серверам. Но, как ни~странно это прозвучит, существуют
|
||||
возможности, востребованные в обоих крайних случаях (встраиваемые системы и
|
||||
серверы), но не~очень актуальные в промежуточной ситуации (десктопы). В
|
||||
частности, к ним относится поддержка
|
||||
\href{http://ru.wikipedia.org/wiki/Watchdog}{сторожевых таймеров} (watchdogs),
|
||||
как аппаратных, так и программных.
|
||||
|
||||
Во встраиваемых системах часто используются аппаратные сторожевые таймеры,
|
||||
выполняющие сброс системы, когда программа перестает отвечать (точнее, перестает
|
||||
периодически посылать таймеру сигнал <<все в порядке>>). Таким образом,
|
||||
обеспечивается повышение надежности системы: что бы ни~случилось, система
|
||||
обязательно попытается привести себя в рабочее состояние. На десктопах такая
|
||||
функциональность практически не~востребована\footnote{Тем не~менее, сейчас
|
||||
аппаратные сторожевые таймеры все чаще появляются и в настольных системах, так
|
||||
как стоят они относительно дешево и доступны практически во всех современных
|
||||
чипсетах.}. В то же время, она весьма актуальна для высокодоступных серверных
|
||||
систем.
|
||||
|
||||
Начиная с версии 183, systemd полностью поддерживает аппаратные сторожевые
|
||||
таймеры (доступные через интерфейс +/dev/watchdog+), а также обеспечивает
|
||||
программный сторожевой контроль системных служб. В целом эта схема (если она
|
||||
задействована) работает так. systemd периодически обращается к аппаратному
|
||||
таймеру. В том случае, если systemd или ядро зависают, аппаратный таймер,
|
||||
не~получив очередного обращения, автоматически перезапустит систему. Таким
|
||||
образом, ядро и systemd защищены от бесконечного зависания на аппаратном уровне.
|
||||
В то же время, сам systemd предоставляет интерфейс, реализующий логику
|
||||
программных сторожевых таймеров для отдельных служб. Таким образом можно
|
||||
обеспечить, например, принудительный перезапуск службы в случае ее зависания.
|
||||
Для каждой службы можно независимо настроить частоту опроса и задать
|
||||
соответствующее действие. Соединив оба звена (аппаратный сторожевой таймер,
|
||||
контролирующий ядро и systemd, и программные сторожевые таймеры, посредством
|
||||
которых systemd контролирует отдельные службы), мы получаем надежную схему
|
||||
надзора за всеми системными компонентами.
|
||||
|
||||
Чтобы задействовать аппаратный таймер, достаточно задать ненулевое значение
|
||||
параметра +RuntimeWatchdogSec=+ в файле +/etc/systemd/system.conf+. По умолчанию
|
||||
этот параметр равен нулю (т.е. аппаратный таймер не~задействован). Установив его
|
||||
равным, например, <<20s>>, мы включим аппаратный сторожевой таймер. Если в
|
||||
течение 20 секунд таймер не~получит очередного сигнала <<все в порядке>>,
|
||||
система автоматически перезагрузится. Отметим, что systemd отправляет такие
|
||||
сигналы с периодом, равным половине заданного интервала~--- в нашем случае,
|
||||
через каждые 10 секунд. Собственно, это все. Просто задав один простой параметр,
|
||||
вы обеспечите аппаратный контроль работоспособности systemd и
|
||||
ядра\footnote{Небольшой совет: если вы занимаетесь отладкой базовых системных
|
||||
компонентов~--- не~забудьте отключить сторожевой таймер. Иначе ваша система
|
||||
может неожиданно перезагрузиться, когда отладчик остановит процесс init и тот
|
||||
не~может вовремя отправить сообщение таймеру.}.
|
||||
|
||||
Заметим, что с аппаратным сторожевым таймером (+/dev/watchdog+)
|
||||
должна работать только одна программа. Этой программой может быть либо systemd,
|
||||
либо отдельный демон сторожевого таймера (например,
|
||||
\href{http://linux.die.net/man/8/watchdog}{watchdogd})~--- выбор остается за
|
||||
вами.
|
||||
|
||||
Стоит упомянуть здесь еще одну опцию из файла +/etc/systemd/system.conf+~---
|
||||
+ShutdownWatchdogSec=+. Она позволяет настроить аппаратный сторожевой таймер для
|
||||
контроля процесса перезагрузки. По умолчанию она равна <<10min>>. Если в
|
||||
процессе остановки системы перед перезагрузкой она зависнет, аппаратный таймер
|
||||
принудительно перезагрузит ее по истечении данного интервала.
|
||||
|
||||
\end{document}
|
||||
|
||||
vim:ft=tex:tw=80:spell:spelllang=ru
|
||||
|
||||
Reference in New Issue
Block a user