Compare commits

...

1 Commits

Author SHA1 Message Date
nnz1024
82452ac75f Version v15.10 (2014-09-12 23:23) [AUTO] 2017-08-17 23:05:42 +03:00

230
s4a.tex
View File

@@ -7,6 +7,7 @@
\usepackage{indentfirst} % Отступ в первом абзаце главы
\usepackage{fancyvrb} % Продвинутые листинги и in-line commands
% listings в данной ситуации, IMHO, избыточен
\usepackage{verbatim} % Окружение comment
\usepackage{pdflscape} % Внимание! При выводе в DVI выборочный
% поворот страниц работать не будет, хотя текст будет повернут.
\usepackage[colorlinks,unicode,urlcolor=blue]{hyperref}
@@ -3303,7 +3304,7 @@ URI, ссылающиеся на документацию, формируютс
отмонтирует файловые системы и выполняет принудительную перезагрузку (в
результате, перезагрузка происходит быстрее, чем обычно, но файловые системы
остаются неповрежденными). И наконец, +reboot-immediate+ даже не~пытается отдать
дань вежливости (убить процессы и отмонтировать файловый системы)~--- оно
дань вежливости (убить процессы и отмонтировать файловые системы)~--- оно
немедленно выполняет жесткую перезагрузку системы (это поведение практически
аналогично срабатыванию аппаратного сторожевого таймера). Все перечисленный
настройки подробно описаны на странице руководства
@@ -5640,7 +5641,7 @@ cp /usr/lib/systemd/network/99-default.link /etc/systemd/network/99-default.link
{исходном коде net\_id built-in}. Ознакомьтесь с ним, если у вас возникают
вопросы, касающиеся расшифровки новых имен\footnote{Прим. перев.: Далее
приводится перевод упомянутого блока комментариев. Последним коммитом,
затронувшим данный файл, на момент перевода является e0d4a от 9 января
затронувшим данный файл, на момент перевода является 1cb5d от 11 августа
2014 г.}.
\begin{Verbatim}
@@ -5657,10 +5658,12 @@ cp /usr/lib/systemd/network/99-default.link /etc/systemd/network/99-default.link
ww -- WWAN
Последующие символы определяеются используемой схемой:
b<number> -- для устройств, подключенных по шине BCMA
ccw<number> -- для устройств, подключенных по шине CCW
o<index> -- для устройств, встроенных в материнскую плату
s<slot>[f<function>][d<dev_id>] -- для hotplug-слотов
s<slot>[f<function>][d<dev_port>] -- для hotplug-слотов
x<MAC> -- при именовании по MAC-адресу
[P<domain>]p<bus>s<slot>[f<function>][d<dev_id>] -- на основании физического
[P<domain>]p<bus>s<slot>[f<function>][d<dev_port>] -- на основании физического
расположения PCI-устройства
[P<domain>]p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]
-- идентификационная цепочка для USB-устройств
@@ -5827,7 +5830,7 @@ systemctl mask tmp.mount
\section{Запуск служб после появления сети\sfnote{Перевод статьи
<<\href{http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget}{Running
Services After the Network is up}>> с официального сайта проекта, по состоянию
на 2013-07-16 15:16:55 (коммит 8b44c).}}
на 2014-06-11 13:22:03 (коммит 0ff8f).}}
\label{sec:networktarget}
\yousaywtfsk{Итак, ваша служба настроена на запуск только после достижения цели
@@ -5835,12 +5838,15 @@ network.target, однако, несмотря на это, она все рав
сети. У вас возникают вопросы: <<Почему так происходит?>> и <<Как это
исправить?>>.}
Цель +network.target+ является systemd-шным аналогом LSB-сущности (facility)
\verb+$network+. Определение этой сущности в стандарте
В некоторых LSB-совместимых скриптах инициализации, при описания зависимостей
используется сущность (facility) \verb+$network+. Определение этой сущности в
стандарте
\href{http://refspecs.linuxbase.org/LSB_3.1.1/LSB-Core-generic/LSB-Core-generic/facilname.html}%
{довольно расплывчато} и оставляет широкий простор для различных трактовок. Вот
примеры некоторых из них:
\begin{itemize}
\item Запущен демон управления сетью (например, NetworkManager или
systemd-networkd).
\item Все заданные в настройках сетевые интерфейсы переведены в состояние
UP и получили IP-адреса.
\item Все имеющиеся физические сетевые интерфейсы, на которых
@@ -5883,15 +5889,15 @@ network.target, однако, несмотря на это, она все рав
такое реагирование в коде демона, на самом деле, не~так уж и сложно. Существует
множество хорошо известных сетевых служб, которые уже давно поддерживают такую
возможность. Подобные службы можно запускать в любой момент, они устойчивы к
сбоям, и в любой ситуации работают корректно.
сбоям, и работают корректно во всех возможных ситуациях.
+network.target+ предназначена для поддержки программ, созданных в
\verb+$network+ предназначена для поддержки программ, созданных в
предположении, что сеть доступна постоянно (т.е. написанных не~очень аккуратно).
Конкретные требования таких программ могут сильно отличаться. Например,
IMAP-серверу будет достаточно наличия IP-адреса, на котором можно слушать. В то
время как для клиентов сетевых файловых систем требуется требуется доступность и
работоспособность сервера, а также, опционально, наличие работоспособного DNS.
Таким образом, конкретные требования к +network.target+ сильно зависят от
Таким образом, конкретные требования к \verb+$network+ сильно зависят от
решаемой задачи.
По соображениям надежности, загрузка системы не~должна зависеть от второстепенных
@@ -5899,6 +5905,12 @@ IMAP-серверу будет достаточно наличия IP-адрес
процесс загрузки системы (за исключением ситуаций, когда сетевое соединение
действительно необходимо для работы системы, например, при загрузке по сети).
\begin{comment}
% Настоящий фрагмент документации применим к systemd версий 212 и ниже.
% Начиная с 11.06.2014 он удален из официальной документации.
% Пока остается здесь в виде комментария, для особо дотошных пользователей
% старых версий systemd.
По умолчанию, +network.target+ не~несет какой-либо сакральной смысловой
нагрузки. Сама по себе настройка службы на запуск после достижения этой цели
не~дает видимого эффекта. Наполнить +network.target+ смыслом должен сам
@@ -5944,7 +5956,196 @@ service-файл, запускающий любую заданную вами п
{апстримный файл} +NetworkManager-wait-online.service+. В завершение,
не~забудьте выполнить для своей службы +systemctl enable+.}.
\subsection*{А что делать нам, разработчикам?}
\end{comment}
% Далее приводится новая редакция (с 11.06.2014) соответствующего фрагмента
% документации, применимая к systemd версий 213 и выше.
\subsection{Как это реализовано в systemd}
В systemd существует сразу три юнита (целевых состояния, target units), в
совокупности берущих на себя роль LSB-сущности \verb+$network+\footnote{Прим.
перев.: Приведенные здесь сведения применимы только к systemd версий 213 и выше,
в которых появился юнит +network-online.target+. О том, как сущность
\verb+$network+ работала в предыдущих версиях systemd, желающие могут
прочитать в примечании~\ref{ftn:lsbnetwork}.}:
\begin{itemize}
\item +network.target+ не~играет существенной роли в процессе
\emph{загрузки} системы. Активация данного целевого состояния
лишь показывает, что программа управления сетью была запущена.
А вот будет ли к этому моменту настроена сеть~---
не~регламентируется. Основное назначение данного юнита~---
синхронизация операций при \emph{остановке} системы. Так как
порядок остановки юнитов обратен порядку их запуска, все юниты,
в описании которых указано +After=network.target+, при
выключении системы будут остановлены до того, как отключится
сеть. Это позволит программам корректно закрывать все сетевые
соединения, а не~оставлять их <<повисшими>>. Обратите внимание,
что +network.target+ является \emph{пассивным} юнитом: вы
не~можете запустить его ни~вручную (через +systemctl start+),
ни~через зависимости своих служб (+Wants+ и +Requires+).
Активацией и деактивацией данного юнита занимается программа,
управляющая сетью в вашей системе. В юнит-файлах служб,
использующих сеть, целесообразно указывать
+After=network.target+, но ни~в~коем случае
не~+Wants=network.target+, и уж тем более
не~+Requires=network.target+\footnote{Прим. перев.: Концепция
активных и пассивных юнитов более подробно пояснена на странице
руководства
\hreftt{http://www.freedesktop.org/software/systemd/man/systemd.special.html}{systemd.special(7)}.
Она описывает взаимосвязь двух классов служб: потребители
(consumers) и поставщики (providers). Например, служба
управления сетью является поставщиком (сети), а демон
торрент-клиента~--- потребителем. Синхронизация между ними может
осуществляться посредством как пассивных, так и активных целевых
состояний. Разница между активными и пассивными целевыми
юнитами состоит в том, что для активных целей
+Requires+/+Wants+ зависимости прописываются в юнит-файле
службы-потребителя, а для пассивных~--- в юнит-файле
службы-поставщика. Никакой магии здесь нет~--- это
просто соглашение между авторами юнит-файлов. В рамках этого же
принципа, в конфигурационные файлы пассивных юнитов
добавляется директива +RefuseManualStart=yes+, запрещающая их
активацию <<вручную>>.}.
\item +network-online.target+ активируется только после появления сети.
Трактовка понятия <<появилась сеть>> остается на совести
разработчиков программы, управляющей сетью\footnote{Прим.
перев.: Определением момента готовности сети обычно занимается
отдельная утилита. В~NetworkManager это +nm-online+, в
systemd-networkd~---
\hreftt{http://www.freedesktop.org/software/systemd/man/systemd-networkd-wait-online.html}{systemd-networkd-wait-online(8)}.
В~случае NM, сеть считается готовой после появления на любом из
управляемых им устройств корректного IP-адреса (глобального или
локального), в случае networkd~--- после того, как для всех
интерфейсов, прописанных в его конфигурации, завершится процесс
настройки (успешно или с ошибкой), причем как минимум для одного
интерфейса настройка должна завершиться успешно.}. Обычно оно
подразумевает, что одному или нескольким сетевым интерфейсам
присвоены маршрутизируемые IP-адреса. Основная задача
обсуждаемого юнита~--- обеспечить задержку запуска отдельных
служб до того момента, как появится сеть. Данный юнит является
\emph{активным}, т.е. его можно указывать в зависимостях служб,
которым необходима запущенная сеть (и, в то же время, нельзя
указывать в зависимостях у самой службы управления сетью). По
умолчанию, этот юнит автоматически прописывается в зависимости к
точкам монтирования всех удаленных файловых систем (например,
NFS, SMBFS/CIFS), приведенным в файле +/etc/fstab+. Таким
образом, монтирование этих файловых систем начнется только после
того, как появится сеть. Однако, если таких точек монтирования
не~указано, а также отсутствуют службы, явно требующие по
зависимостям данный юнит, он вообще не~активируется в процессе
загрузки системы, что позволяет избежать нежелательных задержек
в случае проблем с сетью. Настоятельно рекомендуется
не~злоупотреблять зависимостями от этого юнита. В частности, для
серверных приложений, как правило, такая зависимость избыточна
(обычно, сервер может работать даже в отсутствие внешней сети,
обслуживая локальные соединения). Основная задача обсуждаемого
юнита~--- своевременный запуск клиентских программ, которые
не~могут работать без сети.
\item +network-pre.target+\footnote{Прим. перев.: Поддержка данного
юнита добавлена в systemd-networkd начиная с systemd 214. Тогда
же в официальной документации появились первые упоминания о нем.
Однако, ничто не~мешает использовать этот юнит и в более ранних
версиях systemd~--- достаточно скопировать соответствующий
\href{http://cgit.freedesktop.org/systemd/systemd/tree/units/network-pre.target}%
{конфигурационный файл} в каталог +/etc/systemd/system+.}
активируется до того, как начнется настройка сетевых
интерфейсов. Основная функция этого юнита~--- своевременный
запуск служб, выполняющих настройку брандмауэра. Таким образом,
к моменту появления сети брандмауэр будет уже готов к отражению
возможных атак. Указанный юнит является \emph{пассивным}~--- вы
не~можете запустить его вручную, и его нельзя указывать в
качестве +Requires+/+Wants+-зависимости в юнит-файлах службы
управления сетью. Напротив, такие зависимости должны
прописываться у тех служб, которые должны быть запущены до
появления сети. В юнит-файле службы управления сетью
целесообразно указать +After=network-pre.target+, но
не~+Wants=network-pre.target+/+Requires=network-pre.target+. В
то же время, в юнит-файлах служб, которые должны быть запущены
до появления сети (например, уже обсуждавшиеся выше службы
брандмауэра), наоборот, рекомендуется указывать
+Before=network-pre.target+ и +Wants=network-pre.target+. Таким
образом, данное целевое состояние будет активироваться в нужный
момент только в том случае, если у какой-либо из ваших служб
действительно имеется такая зависимость. Если же подобных служб
нет, +network-pre.target+ не~будет активироваться вообще.
\end{itemize}
Когда systemd встречает в LSB-заголовках init-скриптов зависимость
\verb+$network+, он преобразовывает ее в зависимости
+Wants=network-online.target+ и +After=network-online.target+, что позволяет
обеспечить поведение, более или менее соответствующее требованиям
LSB\footnote{\label{ftn:lsbnetwork}Прим. перев.: Трансляция LSB-сущности
\verb+$network+ в +network-online.target+ введена в systemd начиная с systemd
213. В systemd версий до 212 включительно, \verb+$network+ транслировалась в
+network.target+. Что приводило к довольно неожиданным эффектам~--- как уже
упоминалось выше, активация +network.target+ вовсе не~означает, что сеть уже
настроена. В связи с этим, официальная документация рекомендовала привязывать
+network.target+ к моменту запуска сети, например, через
+NetworkManager-wait-online.service+. Соответствующие команды приведены чуть
ниже по тексту. Они действуют даже в новых версиях systemd, но особого смысла
уже не~несут~--- задача синхронизации решается юнитом +network-online.target+,
который в случае необходимости активируется автоматически (реализовано в
юнит-файлах systemd-networkd 213 и выше, NetworkManager 0.9.9.95 и выше).}.
За дальнейшими подробностями вы можете обратиться к странице руководства
\hreftt{http://www.freedesktop.org/software/systemd/man/systemd.special.html}{systemd.special(7)}.
\subsection{Короче, как заставить network.target работать?}
Это зависит от конфигурации вашей системы и конкретных требований ваших служб
(см. выше). Многие службы управления сетью предоставляют возможность
принудительной активации +network-online.target+, в результате чего
+network.target+ по своему эффекту становится практически эквивалентной
+network-online.target+.
Если вы используете NetworkManager, вы можете задействовать
специальную службу +NetworkManager-wait-online.service+:
\begin{Verbatim}
systemctl enable NetworkManager-wait-online.service
\end{Verbatim}
Если же вы используете systemd-networkd, соответствующая служба будет называться
+systemd-networkd-wait-online.service+:
\begin{Verbatim}
systemctl enable systemd-networkd-wait-online.service
\end{Verbatim}
Включение такой службы позволит гарантировать, что загрузка продолжится только
после того, как все заданные в настройках сетевые интерфейсы будут переведены
в состояние UP и получат IP-адреса. Максимальное время ожидания~--- 90
секунд\footnote{Прим. перев.: У NetworkManager в апстримной конфигурации по
умолчанию сейчас используется значение 30 секунд. См. параметр +--timeout+
программы +nm-online+ в файле настроек службы
+/usr/lib/systemd/system/NetworkManager-wait-online.service+. У systemd-networkd
время ожидания ограничивается тайм-аутом systemd для запуска служб, по умолчанию
90 секунд.}.
Обратите внимание, что включение подобных служб может сильно замедлить загрузку.
Обе эти службы по умолчанию отключены\footnote{Прим. перев.: У внимательного
читателя может возникнуть вопрос: как же определяется момент активации
+network-online.target+, если юниты, отвечающие за ожидание сети, отключены? На
самом деле все довольно просто: при установке NetworkManager/systemd-networkd
соответствующие +*-wait-online+-юниты прописываются в зависимости к
+network-online.target+ при помощи симлинков в
+/etc/systemd/system/network-online.target.wants+. В результате, когда
какая-нибудь служба укажет зависимость от +network-online.target+, будет
автоматически активирована и соответствующая служба +*-wait-online+. Если таких
служб нет, то и активации не~произойдет. Однако, если вы принудительно включите
службу +*-wait-online+ при помощи приведенных выше команд, она будет прописана
в зависимости уже к +multi-user.target+, а значит, будет активироваться при
каждой загрузке.}.
Как альтернативный вариант, вы можете поменять непосредственно юнит-файл той
службы, которая нуждается в сети, добавив туда опции
+After=network-online.target+ и +Wants=network-online.target+\footnote{Прим.
перев.: Собственно, этот путь и является единственно разумным в большинстве
случаев. Привязка +network.target+ к +network-online.target+, описанная выше,
фактически, является пережитком проблем старых версий systemd (212 и ниже),
когда, по воле его разработчиков, LSB-сущность \texttt{\$network}
транслировалась в +network.target+.}.
\subsection{А что делать нам, разработчикам?}
Если вы~--- не~администратор, а разработчик сетевой службы, то вам стоит
задуматься не~о том, что делать с +network.target+, а о том, как можно исправить
@@ -5963,9 +6164,10 @@ service-файл, запускающий любую заданную вами п
{rtnetlink} и реагируйте соответствующим образом. Это наиболее
правильный, но далеко не~всегда самый простой способ.
\item Если вы разрабатываете серверное приложение: слушайте только
адреса 0.0.0.0 и 127.0.0.1. Оба этих псевдо-адреса должны быть
доступны постоянно. Если ваша программа будет слушать только их,
ей будут глубоко безразличны изменения конфигурации сети.
адреса [::], [::1], 0.0.0.0 и 127.0.0.1. Все эти псевдо-адреса
должны быть доступны постоянно. Если ваша программа будет
слушать только их, ей будут глубоко безразличны изменения
конфигурации сети.
\item Если вы разрабатываете серверное приложение и вам нужно слушать
некий заданный адрес: воспользуйтесь опцией
\href{https://www.kernel.org/doc/man-pages/online/pages/man7/ip.7.html}%