Version v8.4 (2011-12-29 21:34) [AUTO]

s4a.tex

@@ -2477,7 +2477,100 @@ systemd игнорировать код выхода процесса sshd. По
 Служба +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}