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

s4a.tex

@@ -16,7 +16,11 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
 % Несколько сокращений
 \newcommand{\sectiona}[1]{\section*{#1}\addcontentsline{toc}{section}{#1}}
 \newcommand{\hreftt}[2]{\href{#1}{\texttt{#2}}}
-\newcommand{\llangl}{\reflectbox{\rotatebox[origin=c]{270}{$\neg$}}}
+\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}
@@ -581,6 +585,7 @@ systemd именует группы в соответствии с назван
 последующих статьях мы обсудим этот вопрос более подробно. 
 
 \section{HOW-TO: преобразование SysV init-скрипта в systemd service-файл}
+\label{sec:convert}
 
 Традиционно, службы Unix и Linux (демоны) запускаются через SysV init-скрипты.
 Эти скрипты пишутся на языке Bourne Shell (+/bin/sh+), располагаются в
@@ -2193,7 +2198,7 @@ serial-getty@ttyUSB0.service - Getty on ttyUSB0
 	  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
-		  \llangl{} 5443 /sbin/agetty -s ttyUSB0 115200,38400,9600
+		  \mytextSFii{} 5443 /sbin/agetty -s ttyUSB0 115200,38400,9600
 \end{Verbatim}
 Собственно, это и есть ключевая идея организации экземпляров служб. Как видите,
 systemd предоставляет простой в использовании механизм шаблонов, позволяющих
@@ -2203,8 +2208,8 @@ systemd предоставляет простой в использовании
 Вы можете создавать дополнительные экземпляры таких служб, просто добавляя
 символьные ссылки в каталоги +*.wants/+. Например, чтобы обеспечить запуск getty
 на ttyUSB0 при каждой загрузке, достаточно создать такую ссылку:
-\begin{Verbatim}
-# ln -s /lib/systemd/system/serial-getty@.service \
+\begin{Verbatim}[commandchars=\\\{\}]
+# ln -s /lib/systemd/system/serial-getty@.service \tbs{}
 /etc/systemd/system/getty.target.wants/serial-getty@ttyUSB0.service
 \end{Verbatim}
 При этом файл конфигурации, на который указывает ссылка (в нашем случае
@@ -2242,13 +2247,7 @@ systemd и заложен предварительный поиск файла
 конце концов, нам нужно было выбрать что-то. Если вы собираетесь комментировать
 наш алгоритм экранирования~--- пожалуйста, также укажите, где вы живете, чтобы я
 мог приехать к вам и раскрасить ваш велосипедный гараж в синий с желтыми
-полосами. Спасибо!}\,\footnote{Прим. перев.: В предыдущем примечании автор снова
-намекает на Паркинсовский Закон Тривиальности. Действительно, выбор алгоритма
-экранирования практически не~влияет ни на работу systemd, ни на управлением им
-(файлы/юниты с экранированными именами, как правило либо создаются специальными
-программами-генераторами, либо формируются systemd на лету; при выводе состояния
-показываются и неэкранированные имена; при вводе команд, как обычно, на
-помощь приходит автодополнение оболочки).}. Например, чтобы обратиться
+полосами. Спасибо!}. Например, чтобы обратиться
 последовательному USB-порту по его адресу на шине, нам нужно использовать имя
 наподобие +serial/by-path/pci-0000:00:1d.0-usb-0:1.4:1.1-port0+. Экранированная
 версия этого имени~---
@@ -2262,7 +2261,7 @@ systemd и заложен предварительный поиск файла
 строке (+ExecStart+) и для формирования читабельных строк описания. Рассмотрим
 работу этих принципов на примере нашего юнит-файла:
 \begin{landscape}
-\begin{Verbatim}[fontsize=\small]
+\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
@@ -2270,7 +2269,7 @@ serial-getty@serial-by\x2dpath-pci\x2d0000:00:1d.0\x2dusb\x2d0:1.4:1.1\x2dport0.
 	  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
-		    5788 /sbin/agetty -s serial/by-path/pci-0000:00:1d.0-usb-0:1.4:1.1-port0 115200 38400 9600
+		  |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}
 Как видите, в качестве идентификатора экземпляра используется экранированная
@@ -2284,6 +2283,82 @@ 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. В этой главе мы рассмотрим
+как провести аналогичное преобразование для служб 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