Version v8.2 (2011-12-15 02:11) [AUTO]

s4a.tex

@@ -16,6 +16,11 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
 % Несколько сокращений
 \newcommand{\sectiona}[1]{\section*{#1}\addcontentsline{toc}{section}{#1}}
 \newcommand{\hreftt}[2]{\href{#1}{\texttt{#2}}}
+\newcommand{\tbs}{\textbackslash}
+% Примерный аналог символа \testSFii (присутствует в листингах),
+% но без использования пакета pmboxdraw, средствами graphicx
+\newcommand{\mytextSFii}{\raisebox{0pt}[0pt][\depth]{%
+	\reflectbox{\rotatebox[origin=t]{270}{$\neg$}}}}
 % Настройка макета страницы
 \setlength{\hoffset}{-1.5cm}
 \addtolength{\textwidth}{2cm}
@@ -580,6 +585,7 @@ systemd именует группы в соответствии с назван
 последующих статьях мы обсудим этот вопрос более подробно. 
 
 \section{HOW-TO: преобразование SysV init-скрипта в systemd service-файл}
+\label{sec:convert}
 
 Традиционно, службы Unix и Linux (демоны) запускаются через SysV init-скрипты.
 Эти скрипты пишутся на языке Bourne Shell (+/bin/sh+), располагаются в
@@ -2126,10 +2132,10 @@ systemd?
 нескольких экземплярах (по крайней мере, в мире systemd)~--- \emph{fsck},
 программа проверки файловой системы, которая запускается по одному экземпляру
 на каждое блочное устройство, требующее такой проверки. И наконец, стоит
-упомянуть службы с активацией в стиле inetd~--- через сокет, по одному
-экземпляру на каждое соединение. В этой статье я попытаюсь рассказать, как в
-systemd реализовано управление <<многоэкземплярными>> службами, и какие выгоды
-системный администратор может извлечь из этой возможности.
+упомянуть службы с активацией в стиле inetd~--- при обращении через сокет, по
+одному экземпляру на каждое соединение. В этой статье я попытаюсь рассказать,
+как в systemd реализовано управление <<многоэкземплярными>> службами, и какие
+выгоды системный администратор может извлечь из этой возможности.
 
 Если вы читали предыдущие статьи из этого цикла, вы, скорее всего, уже знаете,
 что службы systemd именуются по схеме \emph{foobar}+.service+, где
@@ -2179,6 +2185,180 @@ RestartSec=0
 \href{http://cgit.freedesktop.org/systemd/plain/units/serial-getty@.service.m4}{полную
 версию}.)
 
+Этот файл похож на обычный файл конфигурации юнита, с единственным отличием: в
+нем используются спецификаторы \%I и \%i. В момент загрузки юнита, systemd
+заменяет эти спецификаторы на идентификатор экземпляра службы. В нашем случае,
+при обращении к экземпляру +serial-getty@ttyUSB0.service+, они заменяются на
+<<+ttyUSB0+>>. Результат этой замены можно проверить, например, запросив
+состояние для этой службы:
+\begin{Verbatim}[commandchars=\\\{\}]
+$ systemctl status serial-getty@ttyUSB0.service
+serial-getty@ttyUSB0.service - Getty on ttyUSB0
+	  Loaded: loaded (/lib/systemd/system/serial-getty@.service; static)
+	  Active: active (running) since Mon, 26 Sep 2011 04:20:44 +0200; 2s ago
+	Main PID: 5443 (agetty)
+	  CGroup: name=systemd:/system/getty@.service/ttyUSB0
+		  \mytextSFii{} 5443 /sbin/agetty -s ttyUSB0 115200,38400,9600
+\end{Verbatim}
+Собственно, это и есть ключевая идея организации экземпляров служб. Как видите,
+systemd предоставляет простой в использовании механизм шаблонов, позволяющих
+динамически создавать экземпляры служб. Добавим несколько дополнительных
+замечаний, позволяющих эффективно использовать этот механизм:
+
+Вы можете создавать дополнительные экземпляры таких служб, просто добавляя
+символьные ссылки в каталоги +*.wants/+. Например, чтобы обеспечить запуск getty
+на ttyUSB0 при каждой загрузке, достаточно создать такую ссылку:
+\begin{Verbatim}[commandchars=\\\{\}]
+# ln -s /lib/systemd/system/serial-getty@.service \tbs{}
+/etc/systemd/system/getty.target.wants/serial-getty@ttyUSB0.service
+\end{Verbatim}
+При этом файл конфигурации, на который указывает ссылка (в нашем случае
++serial-getty@.service+), будет вызван с тем именем экземпляра, которое указанно
+в названии этой ссылки (в нашем случае~--- +ttyUSB0+).
+
+Вы не~сможете обратиться к юниту-шаблону без указания идентификатора экземпляра.
+В частности, команда +systemctl start serial-getty@.service+ завершится ошибкой.
+
+Иногда возникает необходимость отказаться от использования общего шаблона
+для конкретного экземпляра (т.е. конфигурация данного экземпляра настолько
+сильно отличается от конфигурации остальных экземпляров данной службы, что
+механизм шаблонов оказывается неэффективен). Специально для таких случаев, в
+systemd и заложен предварительный поиск файла с именем, точно соответствующим
+указанному (прежде чем использовать общий шаблон). Таким образом, вы можете
+поместить файл с именем, точно соответствующим полному титулу экземпляра, в
+каталог +/etc/systemd/system/+~--- и содержимое этого файла, при обращении
+к выбранному экземпляру, полностью перекроет все настройки, сделанные в общем
+шаблоне.
+
+В приведенном выше файле, в некоторых местах используется спецификатор +%I+, а
+в других~--- +%i+. У вас может возникнуть закономерный вопрос~--- чем они
+отличаются? +%i+ всегда точно соответствует идентификатору экземпляра, в то
+время, как +%I+ соответствует экранированной (escaped) версии этого
+идентификатора. Когда идентификатор не~содержит спецсимволов (например,
++ttyUSB0+). Но имена устройств, например, содержат слеши (<</>>), которые
+не~могут присутствовать в имени юнита (и в имени файла на Unix). Поэтому, перед
+использованием такого имени в качестве идентификатора устройства, оно должно
+быть экранировано~--- <</>> заменяются на <<->>, а большинство других
+специальных символов (включая <<->>) заменяются последовательностями вида
++\xAB+, где AB~--- ASCII-код символа, записанный в шестнадцатеричной системе
+счисления\footnote{Согласен, этот алгоритм дает на выходе не~очень читабельный
+результат. Но этим грешат практически все алгоритмы экранирования. В данном
+случае, были использован механизм экранирования из udev, с одним изменением. В
+конце концов, нам нужно было выбрать что-то. Если вы собираетесь комментировать
+наш алгоритм экранирования~--- пожалуйста, также укажите, где вы живете, чтобы я
+мог приехать к вам и раскрасить ваш велосипедный гараж в синий с желтыми
+полосами. Спасибо!}. Например, чтобы обратиться
+последовательному USB-порту по его адресу на шине, нам нужно использовать имя
+наподобие +serial/by-path/pci-0000:00:1d.0-usb-0:1.4:1.1-port0+. Экранированная
+версия этого имени~---
++serial-by\x2dpath-pci\x2d0000:00:1d.0\x2dusb\x2d0:1.4:1.1\x2dport0+. +%I+ будет
+ссылаться на первую из этих строк, +%i+~--- на вторую. С практической точки
+зрения, это означает, что спецификатор +%i+ можно использовать в том случае,
+когда надо сослаться на имена других юнитов, например, чтобы описать
+дополнительные зависимости (в случае с +serial-getty@.service+, этот
+спецификатор используется для ссылки на юнит +dev-%i.device+, соответствующий
+одноименному устройству). В то время как +%I+ удобно использовать в командной
+строке (+ExecStart+) и для формирования читабельных строк описания. Рассмотрим
+работу этих принципов на примере нашего юнит-файла:
+\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'
+# systemctl status 'serial-getty@serial-by\x2dpath-pci\x2d0000:00:1d.0\x2dusb\x2d0:1.4:1.1\x2dport0.service'
+serial-getty@serial-by\x2dpath-pci\x2d0000:00:1d.0\x2dusb\x2d0:1.4:1.1\x2dport0.service - Serial Getty on serial/by-path/pci-0000:00:1d.0-usb-0:1.4:1.1-port0
+	  Loaded: loaded (/lib/systemd/system/serial-getty@.service; static)
+	  Active: active (running) since Mon, 26 Sep 2011 05:08:52 +0200; 1s ago
+	Main PID: 5788 (agetty)
+	  CGroup: name=systemd:/system/serial-getty@.service/serial-by\x2dpath-pci\x2d0000:00:1d.0\x2dusb\x2d0:1.4:1.1\x2dport0
+		  |mytextSFii{} 5788 /sbin/agetty -s serial/by-path/pci-0000:00:1d.0-usb-0:1.4:1.1-port0 115200 38400 9600
+\end{Verbatim}
+\end{landscape}
+Как видите, в качестве идентификатора экземпляра используется экранированная
+версия, в то время как в строке описания и в командной строке +getty+
+используется неэкранированная версия. Как и предполагалось.
+
+(Небольшое замечание: помимо +%i+ и +%I+, существует еще несколько
+спецификаторов, и большинство из них доступно и в обычных файлах конфигурации
+юнитов, а не~только в шаблонах. Подробности можно посмотреть на
+\href{http://0pointer.de/public/systemd-man/systemd.unit.html}{странице
+руководства}, содержащей полный перечень этих спецификаторов с краткими
+пояснениями.)
+
+\section{Службы с активацией в стиле inetd}
+
+В одной из предыдущих глав (гл.~\ref{sec:convert}) я рассказывал, как можно
+преобразовать SysV init-скрипт в юнит-файл systemd. В этой главе мы рассмотрим
+как провести аналогичное преобразование для служб inetd.
+
+Начнем с небольшого экскурса в историю вопроса. По давно устоявшейся традиции,
+inetd считается одной из базовых служб Unix-систем. Работая как суперсервер, он
+слушает сетевые сокеты от имени различных служб, и активирует соответствующие
+службы при поступлении на эти сокеты входящих соединений. Таким образом, он
+обеспечивает механизм активации по запросу (on-demand activation). Подобный
+подход избавляет от необходимости держать постоянно работающими все серверные
+процессы, что позволяет поддерживать множество служб даже на системах с очень
+ограниченными ресурсами. На протяжении многих лет, дистрибутивы Linux
+поставляются с различными реализациями inetd. Наиболее популярные из них~--- BSD
+inetd и xinetd. Хотя inetd во многих дистрибутивах до сих пор устанавливается по
+умолчанию, сейчас уже он редко используется для запуска сетевых служб~--- теперь 
+большинство из них запускаются автономно при загрузке системы (основной
+аргумент в пользу такой схемы~--- она позволяет обеспечить более высокую
+производительность служб).
+
+Одной из ключевых возможностей systemd (а также launchd от Apple) является
+сокет-активация~--- тот самый механизм, давным-давно реализованный inetd,
+однако в данном случае ключевые цели немного другие. Сокет-активация в стиле
+systemd прежде всего ориентирована на локальные сокеты (+AF_UNIX+), хотя
+поддерживаются также и сетевые сокеты (+AF_INET+). И более важное отличие~---
+сокет-активация в systemd обеспечивает не~только экономию системных ресурсов,
+но также и эффективную параллелизацию работы (так как она
+позволяет запускать клиентов и серверы одновременно, непосредственно после
+создания сокета), упрощение процесса конфигурации (отпадает необходимость явно
+указывать зависимости между службами) и увеличение надежности (служебный или
+экстренный, в случае падения, перезапуск службы не~приводит к недоступности
+сокета). Тем не~менее, systemd ничуть не~хуже inetd может запускать службы в
+ответ на входящие сетевые соединения.
+
+Любая сокет-активация требует соответствующей поддержки со стороны самой
+запускаемой службы. systemd предоставляет очень простой интерфейс, который может
+быть использован службами для обеспечения сокет-активации. В основе этого
+\href{http://0pointer.de/blog/projects/socket-activation.html}{простого и
+минималистичного} механизма лежит функция
+\hreftt{http://0pointer.de/public/systemd-man/sd_listen_fds.html}{sd\_listen\_fds()}.
+Однако, интерфейс, традиционно используемый в inetd, еще проще. Он позволяет
+передавать запускаемой службе только один сокет, который формируется из потоков
+STDIN и STDOUT запущенного процесса. Поддержка этого механизма также
+присутствует в systemd~--- для обеспечения совместимости с множеством служб
+поддерживающих сокет-активацию только в стиле inetd.
+
+Прежде, чем мы перейдем к примерам, рассмотрим три различных схемы, использующих
+сокет-активацию:
+\begin{enumerate}
+	\item \textbf{Сокет-активация, ориентированная на параллелизацию,
+		упрощение и надежность:} сокеты создаются на ранних стадиях
+		загрузки, и единственный экземпляр службы тут же начинает
+		обслуживать все поступающие запросы. Такая схема подходит для
+		часто используемых системных служб~--- очевидно, что такие
+		службы лучше запускать как можно раньше, и по вомзожности
+		параллельно. В качестве примера можно привести D-Bus и Syslog.
+	\item \textbf{Сокет-активация для одиночных служб:} сокеты создаются на
+		ранних стадиях загрузки, и единственный экземпляр службы
+		запускается при получении входящих запросов. Такая схема больше
+		подходит для редко используемых служб, позволяя обеспечить
+		экономию системных ресурсов и уменьшить время загрузки, просто
+		отложив активацию службы до того момента, когда она
+		действительно понадобится. Пример~--- CUPS.
+	\item \textbf{Сокет-активация для служб, запускающих по экземпляру на
+		каждое соединение:} сокеты создаются на ранней стадии загрузки,
+		и при каждом входящем соединении создается экземпляр службы,
+		которому передается сокет соединения (слушающий сокет при этом
+		остается у суперсервера, inetd или systemd). Эта схема подходит
+		для редко используемых служб, не~критичных по производительности
+		(каждый новый процесс занимает сравнительно немного ресурсов).
+		Пример:SSH.
+\end{enumerate}
+
+
+
 \end{document}
 
 vim:ft=tex:tw=80:spell:spelllang=ru