From 82452ac75fd39a19a12e860c40631012132c3bf5 Mon Sep 17 00:00:00 2001 From: nnz1024 <0comffdiz@inbox.ru> Date: Fri, 12 Sep 2014 23:23:00 +0400 Subject: [PATCH] Version v15.10 (2014-09-12 23:23) [AUTO] --- s4a.tex | 230 ++++++++++++++++++++++++++++++++++++++++++++++++++++---- 1 file changed, 216 insertions(+), 14 deletions(-) diff --git a/s4a.tex b/s4a.tex index 91d51ee..17aa63d 100644 --- a/s4a.tex +++ b/s4a.tex @@ -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 -- для устройств, подключенных по шине BCMA + ccw -- для устройств, подключенных по шине CCW o -- для устройств, встроенных в материнскую плату - s[f][d] -- для hotplug-слотов + s[f][d] -- для hotplug-слотов x -- при именовании по MAC-адресу - [P]ps[f][d] -- на основании физического + [P]ps[f][d] -- на основании физического расположения PCI-устройства [P]ps[f][u][..][c][i] -- идентификационная цепочка для 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}%