Version v8.0 (2011-11-15 18:41) [AUTO]

s4a.tex

@@ -1864,8 +1864,8 @@ shed)~--- если первое из этих решений принимает
 Во многих других дистрибутивах также присутствуют каталоги похожего назначения.
 Связанные с ними вопросы неоднократно появляются в дискуссиях пользователей и
 разработчиков systemd. В этой статье мне хотелось бы рассказать, что я, как
-разработчик systemd, думаю об этих каталогах, и пояснить, почему я считаю
-необходимым от них отказаться. Стоит отметить, что это мое личное мнение, и оно
+разработчик systemd, думаю об этих каталогах, и пояснить, почему, на мой взгляд,
+от них лучше отказаться. Стоит отметить, что это мое личное мнение, и оно
 может не~совпадать с позицией проекта Fedora или моего работодателя.
 
 Начнем с небольшого исторического экскурса. Каталог +/etc/sysconfig+ появился в
@@ -1875,8 +1875,8 @@ shed)~--- если первое из этих решений принимает
 +/etc/default+. Многие дистрибутивы используют такие каталоги, называя их
 по-разному. Они имеются даже в некоторых ОС семейства Unix. (Например, в SCO.
 Если эта тема вас заинтересовала~--- рекомендую обратиться к вашему знакомому
-ветерану Unix, он расскажет подробнее и интереснее, чем я.) Несмотря на то,
-что подобные каталоги широко используются в Linux и Unix, они совершенно
+ветерану Unix, он расскажет гораздо подробнее и интереснее, чем я.) Несмотря на
+то, что подобные каталоги широко используются в Linux и Unix, они совершенно
 не~стандартизированы~--- ни в POSIX, ни в LSB/FHS, и результате мы имеем целый
 зоопарк их различных реализаций в разных дистрибутивах.
 
@@ -1890,7 +1890,7 @@ 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
@@ -1899,33 +1899,33 @@ Guidelines}, однако в обоих этих дистрибутивах ин
 init-скрипта, или даже сами не~являющиеся скриптами.
 
 Но почему вообще появились эти каталоги? Чтобы ответить на этот вопрос,
-обратимся к истории развития концепции SysV init-скриптов. Исторически, они
-располагаются в каталоге под названием +/etc/rc.d/init.d+ (или что-то похожее).
-Отметим, что каталог +/etc+ вообще-то предназначен для хранения файлов
-конфигурации, а не~исполняемого кода (в частности, скриптов). Однако, в начале
-своей истории, init-скрипты рассматривались именно как файлы конфигурации,
-и редактирование их администратором было общепринятой практикой. Но со временем,
-по мере роста и усложнения этих скриптов, их стали рассматривать уже не~как
-файлы конфигурации, а как некие программы. Чтобы упростить их настройку и
-обеспечить безопасность процесса обновления, настройки были вынесены в отдельные
-файлы, загружаемые при работе init-скриптов.
+обратимся к истории развития концепции SysV init-скриптов. Исторически,
+сложилось так, что они располагаются в каталоге под названием +/etc/rc.d/init.d+
+(или что-то похожее).  Отметим, что каталог +/etc+ вообще-то предназначен для
+хранения файлов конфигурации, а не~исполняемого кода (в частности, скриптов).
+Однако, в начале своей истории, init-скрипты рассматривались именно как файлы
+конфигурации, и редактирование их администратором было общепринятой практикой.
+Но со временем, по мере роста и усложнения этих скриптов, их стали рассматривать
+уже не~как файлы конфигурации, а как некие программы. Чтобы упростить их
+настройку и обеспечить безопасность процесса обновления, настройки были вынесены
+в отдельные файлы, загружаемые при работе init-скриптов.
 
 Попробуем составить некоторое представление о настройках, которые можно сделать
-через эти файлы. Вот краткий неполный список различных параметров, которые могут
-быть заданы через переменные окружения в таких файлах (составлен мною по
+через эти файлы. Вот краткий и неполный список различных параметров, которые
+могут быть заданы через переменные окружения в таких файлах (составлен мною по
 результатам исследования соответствующих каталогов в Fedora и Debian):
 \begin{itemize}
 	\item Дополнительные параметры командной строки для бинарника демона.
 	\item Настройки локали для демона.
 	\item Тайм-аут остановки для демона.
 	\item Режим остановки для демона.
-	\item Системные настройки, например, системная локаль, часовой пояс,
+	\item Общесистемные настройки, например, системная локаль, часовой пояс,
 		параметры клавиатуры для консоли.
 	\item Избыточные информация о системных настройках, например, указание,
 		установлены ли аппаратные часы по Гринвичу или по местному
 		времени.
-	\item Списки правил брандмауэра, не~являются скриптом (!).
-	\item Привязки к процессорным ядрам для демона.
+	\item Списки правил брандмауэра, не~являются скриптами (!).
+	\item Привязка к процессорным ядрам для демона.
 	\item Настройки, не~относящиеся к процессу загрузки, например,
 		информация по установке пакетов с новыми ядрами, конфигурация
 		nspluginwrapper, разрешение на выполнение
@@ -1943,8 +1943,9 @@ init-скрипта, или даже сами не~являющиеся скри
 	\item Приоритет OOM killer'а для демона.
 \end{itemize}
 
-А теперь давайте ответим на вопрос: что плохого в +/etc/sysconfig+
-(+/etc/default+) и почему этим каталогам нет места в мире systemd?
+А теперь давайте ответим на вопрос: что же такого неправильного в
++/etc/sysconfig+ (+/etc/default+) и почему этим каталогам нет места в мире
+systemd?
 \begin{itemize}
 	\item Прежде всего, утрачены основная цель и смысл существования этих
 		каталогов: файлы конфигурации юнитов systemd не~являются
@@ -1955,12 +1956,12 @@ init-скрипта, или даже сами не~являющиеся скри
 		использования Bourne shell. Их легко читать и понимать. Кроме
 		того, их легко модифицировать: достаточно скопировать их из
 		+/lib/systemd/system+ в +/etc/systemd/system+, после чего внести
-		необходимые изменения в скопированный файл. При этом можно быть
-		уверенным, что изменения не~будут затерты пакетным менеджером.
+		необходимые изменения в скопированный файл (при этом можно быть
+		уверенным, что изменения не~будут затерты пакетным менеджером).
 		Изначальная причина появления обсуждаемых каталогов~---
 		необходимость разделять код и параметры конфигурации~--- больше
 		не~существует, так как файлы описания юнитов не~являются кодом.
-		Проще говоря, обсуждаемые каталоги пытаются решить проблему,
+		Проще говоря, обсуждаемые каталоги являются решением проблемы,
 		которой уже не~существует.
 	\item Обсуждаемые каталоги и файлы в них очень сильно привязаны к
 		специфике дистрибутивов. Мы же планируем, используя systemd,
@@ -1972,8 +1973,8 @@ init-скрипта, или даже сами не~являющиеся скри
 		Так как расположение обсуждаемых каталогов и настраиваемые через
 		них параметры сильно отличаются от дистрибутива к дистрибутиву,
 		пытаться поддерживать их в апстримных файлах конфигурации юнитов
-		просто бессмысленно. Хранение конфигурации в обсуждаемых
-		каталогов~--- один из факторов, превращающих Linux в зоопарк
+		просто бессмысленно. Хранение параметров конфигурации в этих  
+		каталогах~--- один из факторов, превращающих Linux в зоопарк
 		несовместимых решений.
 	\item Большинство настроек, задаваемых через эти каталоги, являются
 		избыточными в мире systemd. Например, различные службы позволяют
@@ -1992,8 +1993,8 @@ init-скрипта, или даже сами не~являющиеся скри
 		Например, возьмем вышеупомянутую возможность задавать
 		идентификатор пользователя/группы для процесса. Эту задачу
 		должен решать разработчик ПО или дистрибутива. Вмешательство
-		администратора в эту настройку, как правило, лишено смысла~---
-		только разработчик располагает всей информацией,
+		администратора в данную настройку, как правило, лишено
+		смысла~--- только разработчик располагает всей информацией,
 		позволяющий предотвратить конфликты идентификаторов и имен
 		пользователей и групп.
 	\item Формат файлов, используемых для сохранения настроек, плохо
@@ -2004,24 +2005,24 @@ init-скрипта, или даже сами не~являющиеся скри
 		предупреждения при этом не~выводится.
 	\item Кроме того, такая организация не~исключает влияния
 		конфигурационных параметров на среду исполнения: например,
-		изменение перменных +IFS+ и +LANG+ может существенно повлиять на
-		результат интерпретации init-скрипта.
+		изменение переменных +IFS+ и +LANG+ может существенно повлиять
+		на результат интерпретации init-скрипта.
 	\item Интерпретация этих файлов требует запуска еще одного экземпляра
 		оболочки, что приводит к задержкам при загрузке\footnote{Прим.
 		перев.: Здесь автор несколько заблуждается. Скрипты, включенные
 		через директиву +source+, исполняются тем же экземпляром
 		оболочки, что и вызвавший их скрипт.}.
-	\item Файлы из +/etc/sysconfig+ часто пытаются использовать в качетсве
+	\item Файлы из +/etc/sysconfig+ часто пытаются использовать в качестве
 		суррогатной замены файлов конфигурации для тех демонов, которые
 		не~имеют встроенной поддержки конфигурационных файлов. В
 		частности, вводятся специальные переменные, позволяющие задать
 		аргументы командной строки, используемые при запуске демона.
 		Встроенная поддержка конфигурационных файлов является более
-		удобной альтернативой такому подходу, ведь глядя на ключи
+		удобной альтернативой такому подходу, ведь, глядя на ключи
 		<<+-k+>>, <<+-a+>>, <<+-f+>>, трудно догадаться об их
 		назначении. Очень часто, из-за ограниченности словаря, на
 		различных демонов одни и те же ключи действуют совершенно
-		по-разному. (Для одного демона ключ <<+-f+>> содержит указание
+		по-разному (для одного демона ключ <<+-f+>> содержит указание
 		демонизироваться при запуске, в то время как для другого эта
 		опция действует прямо противоположным образом.) В отличие от
 		конфигурационных файлов, строка запуска не~может включать
@@ -2040,20 +2041,20 @@ init-скрипта, или даже сами не~являющиеся скри
 		+systemctl enable+/+disable+ (или +chkconfig on+/+off+).
 		Добавление дополнительного уровня настройки не~приносит никакой
 		пользы и лишь усложняет работу администратора.
-	\item Что списка принудительно загружаемых модулей ядра: в настоящее
-		время существуют куда более удобные пути для автоматической
-		подгрузки модулей при загрузке системы. Например, многие модули
-		+udev+ подгружает автоматически, при обнаружении
-		соответствующего оборудования. Этот же принцип распространяется
-		на ACPI и другие высокоуровневые технологии. Одно из немногих
-		ислючений из этого правила~--- к сожалению, в настоящее время
-		не~поддерживается автоматическая загрузка модулей на основании
-		информации о возможностях процессора, однако это будет
-		исправлено в ближайшем будущем. В случае, если нужный вам модуль
-		ядра все же не~может быть подгружен автоматически, все равно 
-		существует гораздо более удобные методы указать его
-		принудительную подгрузку~--- например, создав соответствующий
-		файл в каталоге
+	\item Что касается списка принудительно загружаемых модулей ядра~--- в
+		настоящее время существуют куда более удобные пути для
+		автоматической подгрузки модулей при загрузке системы. Например,
+		многие модули автоматически подгружаются +udev+'ом при
+		обнаружении соответствующего оборудования. Этот же принцип
+		распространяется на ACPI и другие высокоуровневые технологии.
+		Одно из немногих исключений из этого правила~--- к сожалению, в
+		настоящее время не~поддерживается автоматическая загрузка
+		модулей на основании информации о возможностях процессора,
+		однако это будет исправлено в ближайшем будущем. В случае, если
+		нужный вам модуль ядра все же не~может быть подгружен
+		автоматически, все равно существует гораздо более удобные методы
+		указать его принудительную подгрузку~--- например, создав
+		соответствующий файл в каталоге
 		\hreftt{http://0pointer.de/public/systemd-man/modules-load.d.html}{/etc/modules-load.d/}
 		(стандартный метод настройки принудительной подгрузки модулей).
 	\item И наконец, хотелось бы отметить, что каталог +/etc+ определен как
@@ -2064,22 +2065,23 @@ init-скрипта, или даже сами не~являющиеся скри
 \end{itemize}
 
 Что же можно предложить в качестве современной, совместимой с systemd
-альтернативы этим каталогам? Ниже приведен список советов, как поступить с тем
-или иным параметром конфигурации:
+альтернативы настройке системы через файлы в этих каталогах? Ниже приведены
+несколько рекомендаций, как лучше поступить с задаваемыми таким образом параметрами
+конфигурации:
 \begin{itemize}
 	\item Попробуйте просто отказаться от них. Если они полностью избыточны (например,
 		настройка аппаратных часов на Гринвич/местное время), то убрать
 		их будет довольно легко (если не~рассматривать вопросы
 		обеспечения совместимости). Если аналогичные по смыслу опции
 		штатно поддерживаются systemd, нет никакого смысла дублировать
-		их где-то еще. (Перечень опций, которые можно задать для любой
+		их где-то еще (перечень опций, которые можно задать для любой
 		службы, приведен на страницах справки
 		\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}
 		и
 		\href{http://0pointer.de/public/systemd-man/systemd.service.html}{systemd.service(5)}.)
 		Если же ваша настройка просто добавляет еще один уровень
-		отключения запуска службы, откажитесь от нее, чтобы не~плодить
-		лишние сущности.
+		отключения запуска службы~--- не~плодите лишние сущности,
+		откажитесь от нее.
 	\item Найдите для них более подходящее место. Например, в случае с
 		некоторыми общесистемными настройками (такими, как локаль или
 		часовой пояс), мы надеемся аккуратно подтолкнуть дистрибутивы в
@@ -2091,21 +2093,91 @@ init-скрипта, или даже сами не~являющиеся скри
 \end{itemize}
 
 Существует лишь одна причина поддерживать эти файлы еще некоторое
-время: необходимо обеспечить совместимость при обновлении. Тем не~менее, в новых
-пакетах от этих файлов лучше отказаться.
+время: необходимо обеспечить совместимость при обновлении. Тем не~менее, как
+минимум в новых пакетах, от этих файлов лучше отказаться.
 
-Если требование совместимости критично, вы можете задейстовать эти
+Если требование совместимости критично, вы можете задействовать эти
 конфигурационные файлы даже в том случае, если настраиваете службы через
 штатные unit-файлы systemd. Если ваш файл из +sysconfig+ содержит лишь
 определения переменных, можно воспользоваться опцией
 +EnvironmentFile=-/etc/sysconfig/foobar+ (подробнее об этой опции см.
 \href{http://0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}),
-которая позволит определить соответствующие переменные окружения, которые будут
-использованы при запуске службы. Если же для задания настроек вам необходим
-полноценный язык программирования, вы можете им воспользоваться. Например,
-создайте в +/usr/lib/<your package>/+ простой скрипт, который включает
-соответствующие файлы, а затем запускает бинарник демона через +exec+. После
-чего просто укажите этот скрипт в опции +ExecStart=+ вместо бинарника демона.
+позволяющей прочитать из файла набор переменных окружения, который будет
+установлен при запуске службы. Если же для задания настроек вам необходим
+полноценный язык программирования~--- ничто не~мешает им воспользоваться.
+Например, вы можете создайть в +/usr/lib/<your package>/+ простой скрипт,
+который включает соответствующие файлы, а затем запускает бинарник демона через
++exec+. После чего достаточно просто указать этот скрипт в опции +ExecStart=+
+вместо бинарника демона.
+
+\section{Экземпляры служб}
+
+Большинство служб в Linux/Unix являются одиночными (singleton): в каждый момент
+времени на данном хосте работает только один экземпляр службы. В качестве
+примера таких одиночных служб можно привести Syslogd, Postfix, Apache. Однако,
+существуют службы, запускающие по несколько экземпляров себя на одном хосте.
+Например, службы наподобие Dovecot IMAP запускают по одному экземпляру на каждый
+локальный порт и/или IP-адрес. Другой пример, который можно встретить
+практически во всех системах~--- \emph{getty}, небольшая служба, запускающаяся на
+каждом TTY (от +tty1+ до +tty6+). На некоторых серверах, в зависимости от
+сделанных администратором настроек или параметров загрузки, могут запускаться
+дополнительные экземпляры getty, для подключаемых к COM-портам терминалов или
+для консоли системы виртуализации. Еще один пример службы, работающей в
+нескольких экземплярах (по крайней мере, в мире systemd)~--- \emph{fsck},
+программа проверки файловой системы, которая запускается по одному экземпляру
+на каждое блочное устройство, требующее такой проверки. И наконец, стоит
+упомянуть службы с активацией в стиле inetd~--- через сокет, по одному
+экземпляру на каждое соединение. В этой статье я попытаюсь рассказать, как в
+systemd реализовано управление <<многоэкземплярными>> службами, и какие выгоды
+системный администратор может извлечь из этой возможности.
+
+Если вы читали предыдущие статьи из этого цикла, вы, скорее всего, уже знаете,
+что службы systemd именуются по схеме \emph{foobar}+.service+, где
+\emph{foobar}~--- строка, идентифицирующая службу (проще говоря, ее имя), а
++.service+~--- суффикс, присутствующий в именах всех файлов конфигурации служб.
+Сами эти файлы могут находиться в каталогах +/etc/systemd/systemd+ и
++/lib/systemd/system+ (а также, возможно, и в других). Для служб, работающих в
+нескольких экземплярах, эта схема становится немного сложнее:
+\emph{foobar}+@+\emph{quux}+.service+, где \emph{foobar}~--- имя службы,
+общее для всех экземпляров, а \emph{quux}~--- идентификатор конкретного
+экземпляра. Например, +serial-gett@ttyS2.service+~--- это служба getty для
+COM-порта, запущенная на +ttyS2+.
+
+При необходимости, экземпляры служб можно легко создать динамически. Скажем, вы
+можете, безо всяких дополнительных настроек, запустить новый экземпляр getty на
+последовательном порту, просто выполнив +systemctl start+ для нового экземпляра:
+\begin{Verbatim}
+# systemctl start serial-getty@ttyUSB0.service
+\end{Verbatim}
+
+Получив такую команду, systemd сначала пытается найти файл конфигурации юнита с
+именем, точно соответствующим запрошенному. Если такой файл найти не~удается
+(при работе с экземплярами сервисов обычно так и происходит), из имени файла
+удаляется идентификатор экземпляра, и полученное имя используется при поиске
+\emph{шаблона} конфигурации. В нашем случае, если отсутствует файл с именем
++serial-getty@ttyUSB0.service+, используется файл-шаблон под названием
++serial-getty@.service+. Таким образом, для всех экземпляров данной службы,
+используется один и тот же шаблон конфигурации. В случае с getty для COM-портов,
+этот шаблон, поставляемый в комплекте с systemd
+(файл +/lib/systemd/system/serial-getty@.service+) выглядит примерно так:
+\begin{Verbatim}
+[Unit]
+Description=Serial Getty on %I
+BindTo=dev-%i.device
+After=dev-%i.device systemd-user-sessions.service
+
+[Service]
+ExecStart=-/sbin/agetty -s %I 115200,38400,9600
+Restart=always
+RestartSec=0
+\end{Verbatim}
+(Заметим, что приведенная здесь версия немного сокращена, по сравнению с реально
+используемой в systemd. Удалены не~относящиеся к теме нашего обсуждения
+параметры конфигурации, обеспечивающие совместимость с SysV, очистку экрана и
+удаление предыдущих пользователей с текущего TTY. Если вам интересно, можете
+посмотреть
+\href{http://cgit.freedesktop.org/systemd/plain/units/serial-getty@.service.m4}{полную
+версию}.)
 
 \end{document}