Version v8.5 (2012-01-02 01:38) [AUTO]

s4a.tex

@@ -43,7 +43,8 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
 \author{Lennart P\"{o}ttering (автор)\thanks{Первоисточник (на английском
 языке) опубликован на сайте автора: \url{http://0pointer.de/blog/projects}}\\%
 Сергей Пташник (русский перевод)\thanks{Актуальная версия перевода
-доступна на портале OpenNet: \url{http://wiki.opennet.ru/Systemd}}\\%
+доступна на личной странице переводчика:
+\url{http://www2.kangran.su/~nnz/pub/s4a/}}\\%
 \small Данный документ доступен на условиях лицензии
 \href{http://creativecommons.org/licenses/by-sa/3.0/legalcode}{CC-BY-SA}}
 \maketitle
@@ -58,7 +59,7 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
 инициализации. Окончательный переход на systemd произошел лишь в Fedora~15.}.
 Помимо Fedora, systemd также поддерживает и другие дистрибутивы, в частности,
 \href{http://en.opensuse.org/SDB:Systemd}{OpenSUSE}\footnote{Прим. перев.:
-сейчас systemd поддерживается практически во всех популярных дистрибутивах для
+Сейчас systemd поддерживается практически во всех популярных дистрибутивах для
 настольных систем.}.  systemd предоставляет администраторам целый ряд новых
 возможностей, значительно упрощающих процесс обслуживания системы. Эта статья
 является первой в серии публикаций, планируемых в ближайшие месяцы. В каждой из
@@ -78,9 +79,9 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
 systemd эти сообщения будут пробегать все быстрее и быстрее, вследствие чего,
 читать их будет все труднее. К тому же, многие пользователи применяют
 графические оболочки загрузки (например, Plymouth), полностью скрывающие эти
-сообщения. Тем не~менее, информация, которую несут эти сообщения, была и
-остается чрезвычайно важной~--- они показывают, успешно ли запустилась каждая
-служба, или попытка ее запуска закончилась ошибкой (зеленое
+сообщения. Тем не~менее, информация, которую они несут, была и остается
+чрезвычайно важной~--- они показывают, успешно ли запустилась каждая служба, или
+попытка ее запуска закончилась ошибкой (зеленое
 \texttt{[~\textcolor{green}{OK}~]} или красное
 \texttt{[~\textcolor{red}{FAILED}~]} соответственно). Итак, с ростом скорости
 загрузки систем, возникает неприятная ситуация: информация о результатах
@@ -208,7 +209,9 @@ ntpd.service - Network Time Service
 \end{Verbatim}
 
 systemd сообщает нам, что ntpd был запущен (с идентификатором процесса 953) и
-аварийно завершил работу (с кодом выхода 255).
+аварийно завершил работу (с кодом выхода 255)\footnote{Прим. перев.:
+Впоследствии, про просьбам пользователей, считавших, что слово <<maintenance>>
+недостаточно точно отражает ситуацию, оно было заменено на <<failed>>.}.
 
 В последующих версиях systemd, мы планируем добавить возможность вызова в
 таких ситуациях ABRT (Automated Bug Report Tool), но для этого необходима
@@ -242,7 +245,7 @@ CGI-программы, а демон cron~--- команды, предписа
 к разработке демонов). Также, не~будем забывать, что процесс легко может
 изменить свое имя посредством +PR_SETNAME+, или задав значение
 +argv[0]+, что также усложняет процесс его опознания\footnote{Прим.
-перев.: стоит отметить, что перечисленные ситуации могут возникнуть не~только
+перев.: Стоит отметить, что перечисленные ситуации могут возникнуть не~только
 вследствие ошибок в коде и/или конфигурации программ, но и в результате злого
 умысла. Например, очень часто встречается ситуация, когда установленный на
 взломанном сервере процесс-бэкдор маскируется под нормального демона, меняя
@@ -584,7 +587,7 @@ systemd именует группы в соответствии с назван
 службам, но и процессов, запущенных в рамках пользовательских сеансов. В
 последующих статьях мы обсудим этот вопрос более подробно. 
 
-\section{HOW-TO: преобразование SysV init-скрипта в systemd service-файл}
+\section{Преобразование SysV init-скрипта в systemd service-файл}
 \label{sec:convert}
 
 Традиционно, службы Unix и Linux (демоны) запускаются через SysV init-скрипты.
@@ -867,7 +870,7 @@ service-файлы. Но, к счастью, <<проблемных>> скрип
 Впрочем, этот метод не~вполне корректен, так как он действует не~только на
 самого демона, но и на другие процессы с тем же именем. Иногда подобное
 поведение может привести к неприятным последствиям. Более правильным будет
-использование pid-файла: +kill $(cat /var/run/syslogd.pid)$+. Вот, вроде
+использование pid-файла: \verb+kill $(cat /var/run/syslogd.pid)+. Вот, вроде
 бы, и все, что вам нужно\ldots{} Или мы упускаем еще что-то?
 
 Действительно, мы забываем одну простую вещь: существуют службы, такие, как
@@ -905,15 +908,17 @@ Apache, crond, atd, которые по роду служебной деятел
 как бы она ни пыталась сбежать из-под нашего контроля при помощи двойного
 форка или
 \href{http://ru.wikipedia.org/wiki/Fork-%D0%B1%D0%BE%D0%BC%D0%B1%D0%B0}{форк-бомбардировки}%
-\footnote{Прим. перев.: стоит особо отметить, что использование контрольных
+\footnote{Прим. перев.: Стоит особо отметить, что использование контрольных
 групп не~только упрощает процесс уничтожения форк-бомб, но и значительно
-уменьшает ущерб от работающей форк-бомбы. Так как systemd автоматически
-помещает каждую службу и каждый пользовательский сеанс в свою контрольную
-группу по ресурсу процессорного времени, запуск форк-бомбы одним
-пользователем или службой не~создаст значительных проблем с отзывчивостью
-системы у других пользователей и служб. Таким образом, в качестве основной
-угрозы форк-бомбардировки остаются лишь возможности исчерпания памяти и
-идентификаторов процессов (PID).}.
+уменьшает ущерб от работающей форк-бомбы. Так как systemd автоматически помещает
+каждую службу и каждый пользовательский сеанс в свою контрольную группу по
+ресурсу процессорного времени, запуск форк-бомбы одним пользователем или службой
+не~создаст значительных проблем с отзывчивостью системы у других пользователей и
+служб. Таким образом, в качестве основной угрозы форк-бомбардировки остаются
+лишь возможности исчерпания памяти и идентификаторов процессов (PID). Впрочем, и
+их тоже можно легко устранить: достаточно задать соответствующие лимиты в
+конфигурационном файле службы (см.
+\href{http://www.0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}).}.
 
 В некоторый случах возникает необходимость отправить сигнал именно основному
 процессу службы. Например, используя +SIGHUP+, мы можем заставить демона
@@ -1048,7 +1053,13 @@ systemd и на этот случай есть простое решение, и
 		\end{Verbatim}
 
 		Итак, блокировка сводится к созданию символьной ссылки
-		с именем соответствующей службы, указывающей на +/dev/null+.
+		с именем соответствующей службы, указывающей на
+		+/dev/null+\footnote{Прим. перев.: Впоследствии в программу
+		+systemctl+ была добавлена поддержка команд +mask+ и +unmask+,
+		упрощающих процесс блокирования и разблокирования юнитов.
+		Например, для блокирования службы +ntpd.service+ теперь
+		достаточно команды +systemctl mask ntpd.service+. Фактически
+		она сделает то же самое, что и приведенная выше команда +ln+.}.
 		После такой операции служба не~может быть запущена ни~вручную,
 		ни~автоматически. Символьная ссылка создается в каталоге
 		+/etc/systemd/system/+, а ее имя должно соответствовать имени
@@ -1077,7 +1088,7 @@ systemd и на этот случай есть простое решение, и
 		файлом из пакета).
 
 		Стоит отметить, что блокировка службы, как и ее отключение,
-		является перманентной мерой\footnote{Прим. перев.: подробно
+		является перманентной мерой\footnote{Прим. перев.: Подробно
 		описав принцип работы блокировки службы (юнита), автор забывает
 		привести практические примеры ситуаций, когда эта возможность
 		оказывается полезной.
@@ -1090,21 +1101,14 @@ systemd и на этот случай есть простое решение, и
 		ошибочно указано +systemctl restart+ (+service restart+), что
 		является прямым указанием на запуск службы, если она еще
 		не~запущена. Вследствие таких ошибок, отключенная служба может
-		<<ожить>> в самый неподходящий момент.
-		
-		Другой пример~---
-		ограничение возможностей непривилегированного пользователя при
-		управлении системой. Даже если такому пользователю делегировано
-		(через механизмы sudo или PolicyKit) право на использование
-		+systemctl+, это еще не~означает, что он сможет запустить
-		заблокированную службу~--- права на выполнение +rm+ (удаление
-		блокирующей символьной ссылки) выдаются отдельно.}.
+		<<ожить>> в самый неподходящий момент.}.
 \end{itemize}
 
 После прочтения изложенного выше, у читателя может возникнуть вопрос: как
 отменить произведенные изменения? Что ж, ничего сложного тут нет:
 +systemctl start+ отменяет действия +systemctl stop+, +systemctl enable+
-отменяет действие +systemctl disable+, а +rm+ отменяет действие +ln+.
+отменяет действие +systemctl disable+, а +rm+ отменяет действие
++ln+.
 
 \section{Смена корня}
 
@@ -1144,8 +1148,8 @@ systemd и на этот случай есть простое решение, и
 init, многие параметры среды выполнения (в частности, лимиты на системные
 ресурсы, переменные окружения, и т.п.) наследуются от оболочки, из которой был
 запущен init-скрипт. При использовании systemd ситуация меняется радикально:
-пользователь просто уведомляет init-демона о необходимости запустить ту или иную
-службу, и тот запускает демона в чистом, созданном <<с нуля>> и тщательно
+пользователь просто уведомляет процесс init о необходимости запустить ту или
+иную службу, и тот запускает демона в чистом, созданном <<с нуля>> и тщательно
 настроенном окружении, параметры которого никак не~зависят от настроек среды, из
 которой была отдана команда. Такой подход полностью отменяет традиционный метод
 запуска демонов в chroot-окружениях: теперь демон порождается процессом init
@@ -1173,19 +1177,19 @@ chroot в самой программе. Прежде всего, коррект
 chroot-окружения требует глубокого понимания принципов работы программы.
 Например, нужно точно знать, какие каталоги нужно bind-монтировать из основной
 системы, чтобы обеспечить все необходимые для работы программы каналы связи.  С
-учетом вышесказанного, эффективная chroot-защита обеспечивается в том случае,
-когда она реализована в коде самого демона. Именно разработчик лучше других
-знает (\emph{обязан} знать), как правильно сконфигурировать chroot-окружение, и
-какой минимальный набор файлов, каталогов и файловых систем необходим внутри
-него для нормальной работы демона. Уже сейчас существуют демоны, имеющие
-встроенную поддержку chroot.  К сожалению, в системе Fedora, установленной с
-параметрами по умолчанию, таких демонов всего два:
+учетом вышесказанного, эффективная chroot-защита обеспечивается только в том
+случае, когда она реализована в коде самого демона. Именно разработчик лучше
+других знает (\emph{обязан} знать), как правильно сконфигурировать
+chroot-окружение, и какой минимальный набор файлов, каталогов и файловых систем
+необходим внутри него для нормальной работы демона. Уже сейчас существуют
+демоны, имеющие встроенную поддержку chroot.  К сожалению, в системе Fedora,
+установленной с параметрами по умолчанию, таких демонов всего два:
 \href{http://avahi.org/}{Avahi} и RealtimeKit. Оба они написаны одним очень
 хитрым человеком ;-) (Вы можете собственноручно убедиться в этом, выполнив
 команду +ls -l /proc/*/root+.)
 
 Возвращаясь к теме нашего обсуждения: разумеется, systemd позволяет помещать
-выбранных демонов в chroot, и управлять ими точно так же, как и другими.
+выбранных демонов в chroot, и управлять ими точно так же, как и остальными.
 Достаточно лишь указать параметр +RootDirectory=+ в соответствующем
 service-файле. Например:
 \begin{Verbatim}
@@ -1252,7 +1256,7 @@ InaccessibleDirectories=/home
 руководства}.)
 
 Фактически, FSNS по множеству параметров превосходят +chroot()+. Скорее всего,
-Avahi и ReltimeKit в ближайшем будущем перейдут с +chroot()+ к использованию
+Avahi и RealtimeKit в ближайшем будущем перейдут от +chroot()+ к использованию
 FSNS.
 
 Итак, мы рассмотрели вопросы использования chroot для обеспечения безопасности.
@@ -1267,7 +1271,7 @@ chroot-окружения, по сути, весьма примитивны: о
 отличается лишь содержимое файловой системы, все остальное у них общее.
 Например, если вы обновляете дистрибутив, установленный в chroot-окружении, и
 пост-установочный скрипт пакета отправляет +SIGTERM+ процессу init для его
-перезапуска\footnote{Прим. перев.: во избежание путаницы отметим, что перезапуск
+перезапуска\footnote{Прим. перев.: Во избежание путаницы отметим, что перезапуск
 процесса init (PID~1) <<на лету>> при получении +SIGTERM+ поддерживается только
 в systemd, в классическом SysV init такой возможности нет.}, на него среагирует
 именно хост-система! Кроме того, хост и chroot'нутая система будут иметь общую
@@ -1288,7 +1292,7 @@ systemd имеет целый ряд возможностей, полезных
 Таким образом, пакетные скрипты смогут включить/отключить запуск <<своих>> служб
 при загрузке (или в других ситуациях), однако команды наподобие
 +systemctl restart+ (обычно выполняется при обновлении пакета) не~дадут никакого
-эффекта внутри chroot-окружения\footnote{Прим. перев.: автор забывает отметить
+эффекта внутри chroot-окружения\footnote{Прим. перев.: Автор забывает отметить
 не~вполне очевидный момент: такое поведение +systemctl+ проявляется только в
 <<мертвых>> окружениях, т.е. в тех, где не~запущен процесс init, и
 соответственно отсутствуют управляющие сокеты в +/run/systemd+. Такая ситуация
@@ -1304,7 +1308,7 @@ debootstrap/febootstrap. В этом случае возможности +system
 +chroot(1)+~--- она не~только подменяет корневой каталог, но и создает отдельные
 пространства имен для дерева файловых систем (FSNS) и для идентификаторов
 процессов (PID NS), предоставляя легковесную реализацию системного
-контейнера\footnote{Прим. перев.: используемые в +systemd-nspawn+ механизмы 
+контейнера\footnote{Прим. перев.: Используемые в +systemd-nspawn+ механизмы 
 ядра Linux, такие, как FS NS и PID NS, также лежат в основе
 \href{http://lxc.sourceforge.net/}{LXC}, системы контейнерной изоляции для
 Linux, которая позиционируется как современная альтернатива классическому
@@ -1323,7 +1327,7 @@ Linux, которая позиционируется как современна
 ему в штатном режиме. Также, в отличие от +chroot(1)+, внутри окружения 
 будут автоматически смонтированы +/proc+ и +/sys+.
 
-Следующий пример иллюстрирует возможность запустить Debian в на Fedora-хосте
+Следующий пример иллюстрирует возможность запустить Debian на Fedora-хосте
 всего тремя командами:
 \begin{Verbatim}
 # yum install debootstrap
@@ -1342,15 +1346,18 @@ Linux, которая позиционируется как современна
 После быстрой загрузки вы получите приглашение оболочки, запущенной внутри
 полноценной ОС, функционирующей в контейнере. Изнутри контейнера невозможно
 увидеть процессы, которые находятся вне его. Контейнер сможет пользоваться сетью
-хоста, однако не~имеет возможности изменить ее настройки (это может привести к
-серии ошибок в процессе загрузки гостевой ОС, но ни~одна из этих ошибок
-не~должна быть критической). Контейнер получает доступ к +/sys+ и +/proc/sys+,
-однако, во избежание вмешательства контейнера в конфигурацию ядра и аппаратного
-обеспечения хоста, эти каталоги будут смонтированы только для чтения. Обратите
-внимание, что эта защита блокирует лишь \emph{случайные}, \emph{непредвиденные}
-попытки изменения параметров. При необходимости, процесс внутри контейнера,
-обладающий достаточными полномочиями, сможет перемонтировать эти файловые
-системы в режиме чтения-записи.
+хоста\footnote{Прим. перев.: Впоследствии в +systemd-nspawn+ была добавлена
+опция +--private-network+, изолирующая систему внутри контейнера от сети хоста:
+такая система будет видеть только свой собственный интерфейс обратной петли.},
+однако не~имеет возможности изменить ее настройки (это может привести к серии
+ошибок в процессе загрузки гостевой ОС, но ни~одна из этих ошибок не~должна быть
+критической). Контейнер получает доступ к +/sys+ и +/proc/sys+, однако, во
+избежание вмешательства контейнера в конфигурацию ядра и аппаратного обеспечения
+хоста, эти каталоги будут смонтированы только для чтения. Обратите внимание, что
+эта защита блокирует лишь \emph{случайные}, \emph{непредвиденные} попытки
+изменения параметров. При необходимости, процесс внутри контейнера, обладающий
+достаточными полномочиями, сможет перемонтировать эти файловые системы в режиме
+чтения-записи.
 
 Итак, что же такого хорошего в +systemd-nspawn+?
 \begin{enumerate}
@@ -1500,41 +1507,40 @@ $ systemd-analyze blame
 
 Но почему эта служба вообще присутствует в нашем процессе загрузки? На самом
 деле, мы можем прекрасно обойтись и без нее. Она нужна лишь как часть
-используемой в Fedora схемы инициализации устройств хранения, а именно,
-набора скриптов, выполняющих настройку LVM, RAID и multipath-устройств. На
-сегодняшний день, реализация этих систем не~поддерживает собственного механизма
-поиска и опроса устройств, и поэтому их запуск должен производиться только после
-того, как эта работа уже проделана~--- тогда они могут просто последовательно
+используемой в Fedora схемы инициализации устройств хранения, а именно, набора
+скриптов, выполняющих настройку LVM, RAID и multipath-устройств. На сегодняшний
+день, реализация этих систем не~поддерживает собственного механизма поиска и
+опроса устройств, и поэтому их запуск должен производиться только после того,
+как эта работа уже проделана~--- тогда они могут просто последовательно
 перебирать все диски. Однако, такой подход противоречит одному из
-фундаментальных требований к современным компьютерам:
-возможности подключать и отключать оборудование в любой момент, как при
-выключенном компьютере, так и при включенном. Для некоторых
-технологий невозможно точно определить момент завершения формирования списка устройств
-(например, это характерно для USB и iSCSI), и поэтому процесс опроса
-таких устройств обязательно должен включать некоторую фиксированную задержку,
-гарантирующую, что все подключенные устройства успеют отозваться. С точки зрения
-скорости загрузки это, безусловно, негативный эффект: соответствующие скрипты
-заставляют нас ожидать завершения опроса устройств, хотя большинство этих
-устройств не~являются необходимыми на данной стадии загрузки. В частности, в
-рассматриваемой нами системе LVM, RAID и multipath вообще
-не~используются!\footnote{Наиболее правильным решением в данном случае будет
-ожидание событий подключения устройств (реализованное через libudev или
-аналогичную технологию) с соответствующей обработкой каждого такого события~---
-подобный подход позволит нам продолжить загрузку, как только будут готовы все
-устройства, необходимые для ее продолжения. Для того, чтобы загрузка была
-быстрой, мы должны ожидать завершения инициализации только тех устройств, которые
-\emph{действительно} необходимы для ее продолжения на данной стадии. Ожидать
-остальные устройства в данном случае смысла нет. Кроме того, стоит отметить, что
-в числе программ, не~приспособленных для работы с динамически меняющимся
-оборудованием и построенных в предположении о неизменности списка устройств,
-кроме служб хранения, есть и другие подсистемы. Например, в нашем случае работа 
-initrd занимает так много времени главным образом из-за того, что для запуска
-Plymouth необходимо дождаться завершения инициализации всех устройств
-видеовывода. По неизвестной причине (во всяком случае, неизвестной для меня)
-подгрузка модулей для моих видеокарт Intel занимает довольно продолжительное
-время, что приводит к беспричинной задержке процесса загрузки. (Нет, я протестую
-не~против опроса устройств, но против необходимости ожидать его завершения, чтобы
-продолжить загрузку.)}
+фундаментальных требований к современным компьютерам: возможности подключать и
+отключать оборудование в любой момент, как при выключенном компьютере, так и при
+включенном. Для некоторых технологий невозможно точно определить момент
+завершения формирования списка устройств (например, это характерно для USB и
+iSCSI), и поэтому процесс опроса таких устройств обязательно должен включать
+некоторую фиксированную задержку, гарантирующую, что все подключенные устройства
+успеют отозваться. С точки зрения скорости загрузки это, безусловно, негативный
+эффект: соответствующие скрипты заставляют нас ожидать завершения опроса
+устройств, хотя большинство этих устройств не~являются необходимыми на данной
+стадии загрузки. В частности, в рассматриваемой нами системе LVM, RAID и
+multipath вообще не~используются!\footnote{Наиболее правильным решением в данном
+случае будет ожидание событий подключения устройств (реализованное через libudev
+или аналогичную технологию) с соответствующей обработкой каждого такого
+события~--- подобный подход позволит нам продолжить загрузку, как только будут
+готовы все устройства, необходимые для ее продолжения. Для того, чтобы загрузка
+была быстрой, мы должны ожидать завершения инициализации только тех устройств,
+которые \emph{действительно} необходимы для ее продолжения на данной стадии.
+Ожидать остальные устройства в данном случае смысла нет. Кроме того, стоит
+отметить, что в числе программ, не~приспособленных для работы с динамически
+меняющимся оборудованием и построенных в предположении о неизменности списка
+устройств, кроме служб хранения, есть и другие подсистемы. Например, в нашем
+случае работа initrd занимает так много времени главным образом из-за того, что
+для запуска Plymouth необходимо дождаться завершения инициализации всех
+устройств видеовывода. По неизвестной причине (во всяком случае, неизвестной для
+меня) подгрузка модулей для моих видеокарт Intel занимает довольно
+продолжительное время, что приводит к беспричинной задержке процесса загрузки.
+(Нет, я возражаю не~против опроса устройств как такового, но против
+необходимости ожидать его завершения, чтобы продолжить загрузку.)}
 
 С учетом вышесказанного, мы можем спокойно исключить +udev-settle.service+ из
 нашего процесса загрузки, так как мы не~используем ни~LVM, ни~RAID,
@@ -1549,8 +1555,8 @@ Plymouth необходимо дождаться завершения иници
 После перезагрузки мы видим, что загрузка стала на одну секунду быстрее. Но
 почему выигрыш оказался таким маленьким? Из-за второго осквернителя нашей
 загрузки~--- cryptsetup. На рассматриваемой нами системе зашифрован раздел
-+/home+. Специально для тестирования я записал пароль в файл, чтобы исключить
-влияние скорости ручного набора пароля. К сожалению, для подключения
++/home+. Специально для нашего тестирования я записал пароль в файл, чтобы
+исключить влияние скорости ручного набора пароля. К сожалению, для подключения
 шифрованного раздела cryptsetup требует более пяти секунд. Будем ленивы, и
 вместо того, чтобы исправлять ошибку в cryptsetup\footnote{На самом деле, я
 действительно пытался исправить эту ошибку. Задержки в cryptsetup, по
@@ -1567,7 +1573,7 @@ cryptsetup, что снижение этого времени с 1 секунд
 может продолжить загрузку и приступить к запуску служб. Но первое обращение
 к +/home+ (в отличие, например, от +/var+), происходит на поздней стадии
 процесса загрузки (когда пользователь входит в систему). Следовательно, нам
-нужно сделать так, чтобы этот каталога автоматически монтировался при загрузке,
+нужно сделать так, чтобы этот каталог автоматически монтировался при загрузке,
 но процесс загрузки не~ожидал завершения работы +cryptsetup+, +fsck+ и +mount+
 для этого раздела. Как же сделать точку монтирования доступной, не~ожидая, пока
 завершится процесс монтирования? Этого можно достичь, воспользовавшись
@@ -1737,7 +1743,7 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
 		конфигурация общесистемной локали.
 	\item
 		\hreftt{http://0pointer.de/public/systemd-man/modules-load.d.html}{/etc/modules-load.d/*.conf}:
-		каталог\footnote{Прим. перев.: для описания этого и трех
+		каталог\footnote{Прим. перев.: Для описания этого и трех
 		последующих каталогов автор пользуется термином <<drop-in
 		directory>>. Этот термин означает каталог, в который можно
 		поместить множество независимых файлов настроек, и при чтении
@@ -1791,8 +1797,8 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
 		наличия уникального и постоянного идентификатора компьютера.
 	\item
 		\hreftt{http://0pointer.de/public/systemd-man/machine-info.html}{/etc/machine-info}:
-		новый конфигурационный файл, хранящий информации о полном имени
-		(описательном) хоста (например, <<Компьютер Леннарта>>) и
+		новый конфигурационный файл, хранящий информации о полном 
+		(описательном) имени хоста (например, <<Компьютер Леннарта>>) и
 		значке, которым он будет обозначаться в графических оболочках,
 		работающих с сетью (раньше этот значок мог определяться,
 		например, файлом +/etc/favicon.png+). Данный конфигурационный
@@ -1809,18 +1815,18 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
 момент эти файлы полностью поддерживаются только дистрибутивами, основанными на
 systemd, но уже сейчас в их число входят практически все ключевые дистрибутивы,
 \href{http://www.ubuntu.com/}{за исключением
-одного}\footnote{Прим. перев.: в конце 2010~года энтузиаст Andrew Edmunds
+одного}\footnote{Прим. перев.: В конце 2010~года энтузиаст Andrew Edmunds
 \href{http://cgit.freedesktop.org/systemd/commit/?id=858dae181bb5461201ac1c04732d3ef4c67a0256}{добавил}
 в systemd базовую поддержку Ubuntu и
 \href{https://wiki.ubuntu.com/systemd}{подготовил} соответствующие пакеты,
 однако его инициатива не~встретила поддержки среди менеджеров Canonical. На
 момент написания этих строк (май 2011 года) проект остается заброшенным уже пять
-месяцев (с середины декабря 2010~г.).}. В этом есть что-то от <<пролемы курицы и
-яйца>>: стандарт становится начинает работать как стандарт только тогда, когда
-ему начинают следовать. В будущем мы намерены аккуратно форсировать процесс
-перехода на новые конфигурационные файлы: поддержка старых файлов будет удалена
-из systemd. Разумеется, этот процесс будет идти медленно, шаг за шагом. Но
-конечной его целью является переход всех дистрибутивов на единый набор базовых
+месяцев (с середины декабря 2010~г.).}. В этом есть что-то от <<проблемы курицы
+и яйца>>: стандарт становится настоящим стандартом только тогда, когда ему
+начинают следовать. В будущем мы намерены аккуратно форсировать процесс перехода
+на новые конфигурационные файлы: поддержка старых файлов будет удалена из
+systemd. Разумеется, этот процесс будет идти медленно, шаг за шагом. Но конечной
+его целью является переход всех дистрибутивов на единый набор базовых
 конфигурационных файлов.
 
 Многие из этих файлов используются не~только программами для настройки системы,
@@ -1847,7 +1853,7 @@ shell-скриптов, выполняющих тривиальные задач
 выбрали то, что должно устроить большинство людей. Форматы конфигурационных
 файлов максимально просты, и их можно легко читать и записывать даже из
 shell-скриптов. Да, +/etc/bikeshed.conf+ могло бы быть неплохим именем
-для файла конфигурации!\footnote{Прим. перев.: здесь автор намекает на
+для файла конфигурации!\footnote{Прим. перев.: Здесь автор намекает на
 \href{http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality}{Паркинсоновский
 Закон Тривиальности}, который гласит, что самые жаркие споры возникают вокруг
 наиболее простых вопросов. В частности, в качестве примера Паркинсон приводит
@@ -1887,7 +1893,7 @@ shed)~--- если первое из этих решений принимает
 зоопарк их различных реализаций в разных дистрибутивах.
 
 Назначение этих каталогов определено весьма расплывчато. Абсолютное большинство
-находящихся в них файлов являются включаемыми\footnote{Прим. перев.: здесь автор
+находящихся в них файлов являются включаемыми\footnote{Прим. перев.: Здесь автор
 использует термин sourcable, происходящий от bash'овской директивы +source+,
 обеспечивающей включение в скрипт кода из внешнего файла. В классическом POSIX
 shell это соответствует оператору-точке <<+.+>>. В отличие от прямого запуска
@@ -1927,7 +1933,7 @@ init-скрипта, или даже сами не~являющиеся скри
 	\item Режим остановки для демона.
 	\item Общесистемные настройки, например, системная локаль, часовой пояс,
 		параметры клавиатуры для консоли.
-	\item Избыточные информация о системных настройках, например, указание,
+	\item Избыточная информация о системных настройках, например, указание,
 		установлены ли аппаратные часы по Гринвичу или по местному
 		времени.
 	\item Списки правил брандмауэра, не~являются скриптами (!).
@@ -2056,11 +2062,13 @@ systemd?
 		Одно из немногих исключений из этого правила~--- к сожалению, в
 		настоящее время не~поддерживается автоматическая загрузка
 		модулей на основании информации о возможностях процессора,
-		однако это будет исправлено в ближайшем будущем. В случае, если
-		нужный вам модуль ядра все же не~может быть подгружен
-		автоматически, все равно существует гораздо более удобные методы
-		указать его принудительную подгрузку~--- например, создав
-		соответствующий файл в каталоге
+		однако это будет исправлено в ближайшем будущем\footnote{Прим.
+		перев.: Патчи от разработчиков systemd уже приняты в ядро, и
+		соответствующая функция поддерживается Linux, начиная с версии
+		3.3.}. В случае, если нужный вам модуль ядра все же не~может
+		быть подгружен автоматически, все равно существует гораздо более
+		удобные методы указать его принудительную подгрузку~---
+		например, путем создания соответствующего файла в каталоге
 		\hreftt{http://0pointer.de/public/systemd-man/modules-load.d.html}{/etc/modules-load.d/}
 		(стандартный метод настройки принудительной подгрузки модулей).
 	\item И наконец, хотелось бы отметить, что каталог +/etc+ определен как
@@ -2091,16 +2099,16 @@ systemd?
 	\item Найдите для них более подходящее место. Например, в случае с
 		некоторыми общесистемными настройками (такими, как локаль или
 		часовой пояс), мы надеемся аккуратно подтолкнуть дистрибутивы в
-		правильно направлении (см. предыдущий эпизод).
+		правильно направлении (см. предыдущую главу).
 	\item Добавьте их поддержку в штатную систему настройки демона через
 		собственные файлы конфигурации. К счастью, большинство служб,
 		работающих в Linux, являются свободным программным обеспечением,
 		так что сделать это довольно просто.
 \end{itemize}
 
-Существует лишь одна причина поддерживать эти файлы еще некоторое
+Существует лишь одна причина поддерживать файлы +/etc/sysconfig+ еще некоторое
 время: необходимо обеспечить совместимость при обновлении. Тем не~менее, как
-минимум в новых пакетах, от этих файлов лучше отказаться.
+минимум в новых пакетах, от таких файлов лучше отказаться.
 
 Если требование совместимости критично, вы можете задействовать эти
 конфигурационные файлы даже в том случае, если настраиваете службы через
@@ -2117,6 +2125,7 @@ systemd?
 вместо бинарника демона.
 
 \section{Экземпляры служб}
+\label{sec:instances}
 
 Большинство служб в Linux/Unix являются одиночными (singleton): в каждый момент
 времени на данном хосте работает только один экземпляр службы. В качестве
@@ -2142,7 +2151,15 @@ systemd?
 \emph{foobar}~--- строка, идентифицирующая службу (проще говоря, ее имя), а
 +.service+~--- суффикс, присутствующий в именах всех файлов конфигурации служб.
 Сами эти файлы могут находиться в каталогах +/etc/systemd/systemd+ и
-+/lib/systemd/system+ (а также, возможно, и в других). Для служб, работающих в
++/lib/systemd/system+ (а также, возможно, и в других\footnote{Прим. перев.: В
+качестве <<других>> каталогов, в которых выполняется поиск юнит-файлов, можно
+упомянуть +/run/systemd/system+, в который помещаются временные файлы
+конфигурации, созданные администратором или программами-генераторами и
+действующие только текущем сеансе, и +/usr/lib/systemd/system+, в котором
+находятся юнит-файлы для обычных служб, запускаемых на поздних стадиях загрузки
+(то время, как в упомянутом каталоге +/lib/systemd/system+ находятся файлы
+конфигурации ключевых системных юнитов, которые требуются на раннем этапе
+загрузки, до монтирования +/usr+).}). Для служб, работающих в
 нескольких экземплярах, эта схема становится немного сложнее:
 \emph{foobar}+@+\emph{quux}+.service+, где \emph{foobar}~--- имя службы,
 общее для всех экземпляров, а \emph{quux}~--- идентификатор конкретного
@@ -2189,7 +2206,7 @@ RestartSec=0
 нем используются спецификаторы \%I и \%i. В момент загрузки юнита, systemd
 заменяет эти спецификаторы на идентификатор экземпляра службы. В нашем случае,
 при обращении к экземпляру +serial-getty@ttyUSB0.service+, они заменяются на
-<<+ttyUSB0+>>. Результат этой замены можно проверить, например, запросив
+<<+ttyUSB0+>>. Результат такой замены можно проверить, например, запросив
 состояние для этой службы:
 \begin{Verbatim}[commandchars=\\\{\}]
 $ systemctl status serial-getty@ttyUSB0.service
@@ -2233,21 +2250,21 @@ systemd и заложен предварительный поиск файла
 В приведенном выше файле, в некоторых местах используется спецификатор +%I+, а
 в других~--- +%i+. У вас может возникнуть закономерный вопрос~--- чем они
 отличаются? +%i+ всегда точно соответствует идентификатору экземпляра, в то
-время, как +%I+ соответствует экранированной (escaped) версии этого
+время, как +%I+ соответствует неэкранированной (unescaped) версии этого
 идентификатора. Когда идентификатор не~содержит спецсимволов (например,
-+ttyUSB0+). Но имена устройств, например, содержат слеши (<</>>), которые
-не~могут присутствовать в имени юнита (и в имени файла на Unix). Поэтому, перед
-использованием такого имени в качестве идентификатора устройства, оно должно
-быть экранировано~--- <</>> заменяются на <<->>, а большинство других
-специальных символов (включая <<->>) заменяются последовательностями вида
-+\xAB+, где AB~--- ASCII-код символа, записанный в шестнадцатеричной системе
-счисления\footnote{Согласен, этот алгоритм дает на выходе не~очень читабельный
-результат. Но этим грешат практически все алгоритмы экранирования. В данном
-случае, были использован механизм экранирования из udev, с одним изменением. В
-конце концов, нам нужно было выбрать что-то. Если вы собираетесь комментировать
-наш алгоритм экранирования~--- пожалуйста, также укажите, где вы живете, чтобы я
-мог приехать к вам и раскрасить ваш велосипедный гараж в синий с желтыми
-полосами. Спасибо!}. Например, чтобы обратиться
++ttyUSB0+), результат в обоих случаях одинаковый. Но имена устройств, например,
+содержат слеши (<</>>), которые не~могут присутствовать в имени юнита (и в имени
+файла на Unix). Поэтому, перед использованием такого имени в качестве
+идентификатора устройства, оно должно быть экранировано~--- <</>> заменяются на
+<<->>, а большинство других специальных символов (включая <<->>) заменяются
+последовательностями вида +\xAB+, где AB~--- ASCII-код символа, записанный в
+шестнадцатеричной системе счисления\footnote{Согласен, этот алгоритм дает на
+выходе не~очень читабельный результат. Но этим грешат практически все алгоритмы
+экранирования. В данном случае, был использован механизм экранирования из udev,
+с одним изменением. В конце концов, нам нужно было выбрать что-то. Если вы
+собираетесь комментировать наш алгоритм экранирования~--- пожалуйста, оставьте
+свой адрес, чтобы я мог приехать к вам и раскрасить ваш сарай для велосипедов в
+синий с желтыми полосами. Спасибо!}. Например, чтобы обратиться к
 последовательному USB-порту по его адресу на шине, нам нужно использовать имя
 наподобие +serial/by-path/pci-0000:00:1d.0-usb-0:1.4:1.1-port0+. Экранированная
 версия этого имени~---
@@ -2259,7 +2276,12 @@ systemd и заложен предварительный поиск файла
 спецификатор используется для ссылки на юнит +dev-%i.device+, соответствующий
 одноименному устройству). В то время как +%I+ удобно использовать в командной
 строке (+ExecStart+) и для формирования читабельных строк описания. Рассмотрим
-работу этих принципов на примере нашего юнит-файла:
+работу этих принципов на примере нашего юнит-файла\footnote{Прим. перев.: как
+видно из нижеприведенного примера, в командной строке +systemctl+ необходимо
+указывать экранированное имя юнита, что создает определенные трудности даже при
+наличии в оболочке <<умного>> автодополнения. Однако, на момент написания этих
+строк, в TODO проекта содержится пункт о добавлении в 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'
@@ -2274,7 +2296,7 @@ serial-getty@serial-by\x2dpath-pci\x2d0000:00:1d.0\x2dusb\x2d0:1.4:1.1\x2dport0.
 \end{landscape}
 Как видите, в качестве идентификатора экземпляра используется экранированная
 версия, в то время как в строке описания и в командной строке +getty+
-используется неэкранированная версия. Как и предполагалось.
+фигурирует неэкранированный вариант, как и предполагалось.
 
 (Небольшое замечание: помимо +%i+ и +%I+, существует еще несколько
 спецификаторов, и большинство из них доступно и в обычных файлах конфигурации
@@ -2286,35 +2308,35 @@ serial-getty@serial-by\x2dpath-pci\x2d0000:00:1d.0\x2dusb\x2d0:1.4:1.1\x2dport0.
 \section{Службы с активацией в стиле inetd}
 
 В одной из предыдущих глав (гл.~\ref{sec:convert}) я рассказывал, как можно
-преобразовать SysV init-скрипт в юнит-файл systemd. В этой главе мы рассмотрим
+преобразовать SysV init-скрипт в юнит-файл systemd. В этой главе мы рассмотрим,
 как провести аналогичное преобразование для служб inetd.
 
-Начнем с небольшого экскурса в историю вопроса. По давно устоявшейся традиции,
+Начнем с небольшого экскурса в историю вопроса. Уже многие годы 
 inetd считается одной из базовых служб Unix-систем. Работая как суперсервер, он
 слушает сетевые сокеты от имени различных служб, и активирует соответствующие
 службы при поступлении на эти сокеты входящих соединений. Таким образом, он
 обеспечивает механизм активации по запросу (on-demand activation). Подобный
 подход избавляет от необходимости держать постоянно работающими все серверные
 процессы, что позволяет поддерживать множество служб даже на системах с очень
-ограниченными ресурсами. На протяжении многих лет, дистрибутивы Linux
-поставляются с различными реализациями inetd. Наиболее популярные из них~--- BSD
+ограниченными ресурсами. В дистрибутивах Linux можно встретить
+несколько различных реализаций inetd. Наиболее популярные из них~--- BSD
 inetd и xinetd. Хотя inetd во многих дистрибутивах до сих пор устанавливается по
-умолчанию, сейчас уже он редко используется для запуска сетевых служб~--- теперь 
+умолчанию, сейчас он уже редко используется для запуска сетевых служб~--- теперь 
 большинство из них запускаются автономно при загрузке системы (основной
 аргумент в пользу такой схемы~--- она позволяет обеспечить более высокую
 производительность служб).
 
 Одной из ключевых возможностей systemd (а также launchd от Apple) является
-сокет-активация~--- тот самый механизм, давным-давно реализованный inetd,
+сокет-активация~--- тот же самый механизм, давным-давно реализованный inetd,
 однако в данном случае ключевые цели немного другие. Сокет-активация в стиле
 systemd прежде всего ориентирована на локальные сокеты (+AF_UNIX+), хотя
 поддерживаются также и сетевые сокеты (+AF_INET+). И более важное отличие~---
 сокет-активация в systemd обеспечивает не~только экономию системных ресурсов,
-но также и эффективную параллелизацию работы (так как она
-позволяет запускать клиентов и серверы одновременно, непосредственно после
-создания сокета), упрощение процесса конфигурации (отпадает необходимость явно
-указывать зависимости между службами) и увеличение надежности (служебный или
-экстренный, в случае падения, перезапуск службы не~приводит к недоступности
+но также и эффективную параллелизацию работы (так как она позволяет запускать
+клиентские и серверные процессы одновременно, непосредственно после создания
+сокета), упрощение процесса конфигурации (отпадает необходимость явно указывать
+зависимости между службами) и увеличение надежности (перезапуск службы,
+служебный или экстренный~--- в случае падения~--- не~приводит к недоступности
 сокета). Тем не~менее, systemd ничуть не~хуже inetd может запускать службы в
 ответ на входящие сетевые соединения.
 
@@ -2327,7 +2349,7 @@ systemd прежде всего ориентирована на локальны
 Однако, интерфейс, традиционно используемый в inetd, еще проще. Он позволяет
 передавать запускаемой службе только один сокет, который формируется из потоков
 STDIN и STDOUT запущенного процесса. Поддержка этого механизма также
-присутствует в systemd~--- для обеспечения совместимости с множеством служб
+присутствует в systemd~--- для обеспечения совместимости со множеством служб,
 поддерживающих сокет-активацию только в стиле inetd.
 
 Прежде, чем мы перейдем к примерам, рассмотрим три различных схемы, использующих
@@ -2338,7 +2360,7 @@ STDIN и STDOUT запущенного процесса. Поддержка эт
 		загрузки, и единственный экземпляр службы тут же начинает
 		обслуживать все поступающие запросы. Такая схема подходит для
 		часто используемых системных служб~--- очевидно, что такие
-		службы лучше запускать как можно раньше, и по вомзожности
+		службы лучше запускать как можно раньше, и по возможности
 		параллельно. В качестве примера можно привести D-Bus и Syslog.
 	\item \textbf{Сокет-активация для одиночных служб:} сокеты создаются на
 		ранних стадиях загрузки, и единственный экземпляр службы
@@ -2354,10 +2376,222 @@ STDIN и STDOUT запущенного процесса. Поддержка эт
 		остается у суперсервера, inetd или systemd). Эта схема подходит
 		для редко используемых служб, не~критичных по производительности
 		(каждый новый процесс занимает сравнительно немного ресурсов).
-		Пример:SSH.
+		Пример: SSH.
 \end{enumerate}
 
+Описанные схемы отнюдь не~эквивалентны с точки зрения производительности. Первая
+и вторая схема, после завершения запуска службы, обеспечивают точно такую же
+производительность, как и в случае с независимой (stand-alone) службой (т.е.
+службой, запущенной без использования суперсервера и сокет-активации), так как
+слушающий сокет передается непосредственно процессу службы, и дальнейшая
+обработка входящих соединений происходит точно так же, как и в независимой
+службе. В то же время, производительность третьей из предложенных схем порою
+оставляет желать лучшего: каждое входящее соединение порождает еще один процесс
+службы, что, при большом количестве соединений, может привести к значительному
+потреблению системных ресурсов. Впрочем, эта схема имеет и свои достоинства.
+В частности, обеспечивается эффективная изоляция обработки клиентских запросов
+и, кроме того, выбор такой схемы активации значительно упрощает процесс
+разработки службы.
 
+В systemd наибольшее внимание уделяется первой из этих схем, однако остальные
+две тоже прекрасно поддерживаются. В свое время, я
+\href{http://0pointer.de/blog/projects/socket-activation2.html}{рассказывал},
+какие изменения в коде службы нужно сделать для обеспечения работы по второй
+схеме, на примере сервера CUPS. Что же касается inetd, то он предназначен прежде
+всего для работы по третьей схеме, хотя поддерживает и вторую (но не~первую).
+Именно из-за специфики этой схемы inetd получил репутации <<медленного>> (что,
+на самом деле, немного несправедливо).
+
+Итак, изучив теоретическую сторону вопроса, перейдем к практике и рассмотрим,
+как inetd-служба может быть интегрирована с механизмами сокет-активации systemd.
+В качестве примера возьмем SSH, известную и широко распространенную службу. На
+большинстве систем, где она используется, частота обращений к ней не~превышает
+одного раза в час (как правило, она \emph{значительно} меньше этой величины).
+SSH уже очень давно поддерживает сокет-активацию в стиле inetd, согласно третьей
+схеме. Так как необходимость в этой службе возникает сравнительно редко, и
+число одновременно работающих процессов обычно невелико, она хорошо подходит для
+использования по этой схеме. Перерасход системных ресурсов должен быть
+незначителен: большую часть времени такая служба фактически не~выполняется и
+не~тратит ресурсы. Когда кто-либо начинает сеанс удаленной работы, она
+запускается, и останавливается немедленно по завершению сеанса, освобождая
+ресурсы. Что ж, посмотрим, как в systemd можно воспользоваться режимом
+совместимости с inetd и обеспечить сокет-активацию SSH.
+
+Так выглядит строка с конфигурацией службы SSH для классического inetd:
+\begin{Verbatim}
+ssh stream tcp nowait root /usr/sbin/sshd sshd -i
+\end{Verbatim}
+
+Аналогичный фрагмент конфигурации для xinetd:
+\begin{Verbatim}
+service ssh {
+        socket_type = stream
+        protocol = tcp
+        wait = no
+        user = root
+        server = /usr/sbin/sshd
+        server_args = -i
+}
+\end{Verbatim}
+
+Б\'{о}льшая часть опций интуитивно понятна, кроме того, нетрудно заметить, что оба
+этих текста повествуют об одном и том же. Однако, некоторые моменты не~вполне
+очевидны. Например, номер прослушиваемого порта (22) не~указывается в явном
+виде. Он определяется путем поиска имени службы в базе данных +/etc/services+.
+Подобный подход был некогда весьма популярен в Unix, но сейчас он уже постепенно
+выходит из моды, и поэтому в современных версиях xinetd поддерживается возможность
+явного указания номера порта. Одна из наиболее интересных настроек названа
+не~очень очевидно~--- +nowait+ (+wait=no+). Она определяет, будет ли служба
+работать по второй (+wait+) или третьей (+nowait+) схеме. И наконец, ключ +-i+
+активирует inetd-режим в SSH-сервере (без этого ключа он работает в независимом
+режиме).
+
+На языке systemd эти фрагменты конфигурации превращаются в два файла. Первый из
+них, +sshd.socket+, содержит информацию о прослушиваемом сокете:
+\begin{Verbatim}
+[Unit]
+Description=SSH Socket for Per-Connection Servers
+
+[Socket]
+ListenStream=22
+Accept=yes
+
+[Install]
+WantedBy=sockets.target
+\end{Verbatim}
+
+Смысл большинства опций вполне очевиден. Сделаю лишь пару замечаний.
++Accept=yes+ соответствует режиму +nowait+. Надеюсь, предложенное мною название
+более точно отражает смысл опции~--- в режиме +nowait+ суперсвервер сам вызывает
++accept()+ для слушающего сокета, в то время как в режиме +wait+ эта работа
+ложится на процесс службы. Опция +WantedBy=sockets.target+ обеспечивает
+активацию данного юнита в нужный момент при загрузке системы.
+
+Второй из этих файлов~--- +sshd@.service+:
+\begin{Verbatim}
+[Unit]
+Description=SSH Per-Connection Server
+
+[Service]
+ExecStart=-/usr/sbin/sshd -i
+StandardInput=socket
+\end{Verbatim}
+
+Большинство представленных здесь опций, как всегда, понятны интуитивно. Особое
+внимание стоит обратить лишь на +StandardInput=socket+, которая, собственно, и
+включает для данной службы режим совместимости с inetd-активацией. Опция
++StandardInput=+ позволяет указать, куда будет подключен поток STDIN процесса
+данной службы (подробности см.
+\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{на странице
+руководства}). Задав для нее значение +socket+, мы обеспечиваем подключение
+этого потока к сокету соединения, как того и требует механизм inetd-активации.
+Заметим, что явно указывать опцию +StandardOutput=+ в данном случае
+необязательно~--- она автоматически устанавливается в то же значение, что и
++StandardInput+, если явно не~указано что-то другое. Кроме того, можно отметить
+наличие <<+-+>> перед именем бинарного файла sshd. Таким образом мы указываем
+systemd игнорировать код выхода процесса sshd. По умолчанию, systemd сохраняет
+коды выхода для всех экземпляров службы, завершившихся с ошибкой (сбросить эту
+информацию можно командой +systemctl reset-failed+). SSH
+довольно часто завершается с ненулевым кодом выхода, и мы разрешаем systemd
+не~регистрировать подобные <<ошибки>>.
+
+Служба +sshd@.service+ предназначена для работы в виде независимых экземпляров
+(такие службы мы рассматривали в предыдущей главе~\ref{sec:instances}). Для
+каждого входящего соединения systemd будет создавать свой экземпляр этой службы,
+причем идентификатор экземпляра формируется на основе реквизитов соединения.
+
+Быть может, вы спросите: почему для настройки inetd-службы в systemd требуется
+два файла конфигурации, а не~один? Отвечаем: чтобы избежать излишнего
+усложнения, мы обеспечиваем максимально прозрачную связь между работающими
+юнитами и соответствующими им юнит-файлами. Такой подход позволяет независимо
+оперировать юнитом сокета и юнитами соответствующих служб при формировании графа
+зависимостей и при управлении юнитами. В частности, вы можете остановить
+(удалить) сокет, не~затрагивая уже работающие экземпляры соответствующей службы,
+или остановить любой из этих экземпляров, не~трогая другие экземпляры и сам
+сокет.
+
+Посмотрим, как наш пример будет работать. После того, как мы поместим оба
+предложенных выше файла в каталог +/etc/systemd/system+, мы сможем включить
+сокет (то есть, обеспечить его активацию при каждой нормальной загрузке) и
+запустить его (то есть активировать в текущем сеансе работы):
+
+\begin{Verbatim}
+# systemctl enable sshd.socket
+ln -s '/etc/systemd/system/sshd.socket' '/etc/systemd/system/sockets.target.wants/sshd.socket'
+# systemctl start sshd.socket
+# systemctl status sshd.socket
+sshd.socket - SSH Socket for Per-Connection Servers
+	  Loaded: loaded (/etc/systemd/system/sshd.socket; enabled)
+	  Active: active (listening) since Mon, 26 Sep 2011 20:24:31 +0200; 14s ago
+	Accepted: 0; Connected: 0
+	  CGroup: name=systemd:/system/sshd.socket
+\end{Verbatim}
+
+Итак, наш сокет уже прослушивается, но входящих соединений на него пока
+не~поступало (счетчик +Accepted:+ показывает количество принятых соединений
+с момента создания сокета, счетчик +Connected:+~--- количество активных
+соединений на текущий момент).
+
+Подключимся к нашему серверу с двух разных хостов, и посмотрим на список служб:
+\begin{Verbatim}[fontsize=\small]
+$ systemctl --full | grep ssh
+sshd@172.31.0.52:22-172.31.0.4:47779.service  loaded active running       SSH Per-Connection Server
+sshd@172.31.0.52:22-172.31.0.54:52985.service loaded active running       SSH Per-Connection Server
+sshd.socket                                   loaded active listening     SSH Socket for Per-Connection Servers
+\end{Verbatim}
+
+Как и следовало ожидать, работают два экземпляра нашей службы, по одному на
+соединение, и их в названиях указаны IP-адреса и TCP-порты источника и
+получателя. (Заметим, что в случае с локальными сокетами типа +AF_UNIX+ там были
+бы указаны идентификаторы процесса и пользователя, соответствующие подключенному
+клиенту.) Таким образом, мы можем независимо выслеживать и убивать отдельные
+экземпляры sshd (например, если нам нужно прервать конкретный удаленный сеанс):
+\begin{Verbatim}
+# systemctl kill sshd@172.31.0.52:22-172.31.0.4:47779.service
+\end{Verbatim}
+
+Вот, пожалуй, и все, что вам нужно знать о портировании inetd-служб в systemd и
+дальнейшем их использовании.
+
+Применительно к SSH, в большинстве случаев схема с inetd-активацией позволяет
+сэкономить системные ресурсы и поэтому оказывается более эффективным решением,
+чем использование обычного service-файла sshd, обеспечивающего запуск одиночной
+службы без использования сокет-активации (поставляется в составе пакета и может
+быть включен при необходимости). В ближайшее время я собираюсь направить
+соответствующий запрос относительно нашего пакета SSH в багтрекер Fedora.
+
+В завершение нашей дискуссии, сравним возможности 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}{список настроек}
+для контроля окружения, в котором запускаются экземпляры. Я надеюсь, что
+возможностей systemd должно быть достаточно для решения большинства задач, а в
+тех редких случаях, когда вам потребуются специфические опции xinetd~--- ничто
+не~мешает вам запустить его в дополнение к systemd. Таким образом, уже сейчас в
+большинстве случаев xinetd можно выкинуть из числа обязательных системных
+компонентов. Можно сказать, что systemd не~просто возвращает функциональность
+классического юниксового inetd, но еще и восстанавливает ее ключевую
+роль в Linux-системах.
+
+Теперь, вооруженные этими знаниями, вы можете портировать свои службы с inetd на
+systemd. Но, конечно, будет лучше, если этим займутся разработчики из апстрима
+приложения, или сопровождающие вашего дистрибутива.
 
 \end{document}