From 5c9a94935188ddd7106ffcc50b80adace123b747 Mon Sep 17 00:00:00 2001 From: nnz1024 <0comffdiz@inbox.ru> Date: Thu, 29 Dec 2011 21:34:00 +0400 Subject: [PATCH] Version v8.4 (2011-12-29 21:34) [AUTO] --- s4a.tex | 95 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 94 insertions(+), 1 deletion(-) diff --git a/s4a.tex b/s4a.tex index dc20f7d..ae76757 100644 --- a/s4a.tex +++ b/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}