Compare commits
2 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
82452ac75f | ||
|
|
3046243a83 |
373
s4a.tex
373
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}
|
||||
@@ -2702,7 +2703,7 @@ systemd 187.}:
|
||||
\footnote{Прим. перев.: Начиная с systemd версии 206, значительная часть
|
||||
обсуждаемых здесь настроек вынесена на отдельную страницу
|
||||
\href{http://www.freedesktop.org/software/systemd/man/systemd.cgroup.html}%
|
||||
{systemd.cgroup(5)}. Начиная с systemd 207, эта страница переименована в
|
||||
{systemd.cgroup(5)}. Начиная с systemd 208, эта страница переименована в
|
||||
\href{http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html}%
|
||||
{systemd.resource-control(5)}.}. Если вам потребуется дополнительная информация,
|
||||
вы можете обратиться к ним.
|
||||
@@ -2797,7 +2798,14 @@ PrivateTmp=yes
|
||||
присутствуют: сокеты размещаются в защищенном подкаталоге, который создается на
|
||||
ранних стадиях загрузки). Разумеется, для служб, использующих +/tmp+ в целях
|
||||
коммуникации, включение опции +PrivateTmp=yes+ недопустимо. К счастью, подобных
|
||||
служб сейчас уже не~так уж и много.
|
||||
служб сейчас уже не~так уж и много\footnote{Прим. перев.: Начиная с systemd 209,
|
||||
поддерживается опция +JoinsNamespaceOf=+ (секция +[Unit]+), позволяющая
|
||||
поместить два и более юнитов в одну <<песочницу>> (пространство имен), в
|
||||
результате чего такие юниты смогут взаимодействовать между собой, как через
|
||||
сетевой интерфейс обратной петли, так и через файлы в каталоге +/tmp+,
|
||||
при этом оставаясь изолированными от остальной системы. Подробности можно
|
||||
уточнить на странице руководства
|
||||
\href{http://www.freedesktop.org/software/systemd/man/systemd.unit.html}{systemd.unit(5)}.}.
|
||||
\end{caveat}
|
||||
|
||||
Эта опция использует технологию пространств имен файловых систем (filesystem
|
||||
@@ -3296,7 +3304,7 @@ URI, ссылающиеся на документацию, формируютс
|
||||
отмонтирует файловые системы и выполняет принудительную перезагрузку (в
|
||||
результате, перезагрузка происходит быстрее, чем обычно, но файловые системы
|
||||
остаются неповрежденными). И наконец, +reboot-immediate+ даже не~пытается отдать
|
||||
дань вежливости (убить процессы и отмонтировать файловый системы)~--- оно
|
||||
дань вежливости (убить процессы и отмонтировать файловые системы)~--- оно
|
||||
немедленно выполняет жесткую перезагрузку системы (это поведение практически
|
||||
аналогично срабатыванию аппаратного сторожевого таймера). Все перечисленный
|
||||
настройки подробно описаны на странице руководства
|
||||
@@ -3527,14 +3535,16 @@ getty\footnote{Отметим, что +systemctl enable+ \emph{для экзем
|
||||
\texttt{ln -s /usr/lib/systemd/system/serial-getty@.service
|
||||
/etc/systemd/system/getty.target.wants/serial-getty@ttyS2.service ; systemctl
|
||||
daemon-reload}.}\footnote{\label{ftn:enableserial}Прим. перев.: На самом деле,
|
||||
работать с символьными ссылками придется даже в современных версиях systemd (на
|
||||
момент написания этих строк, последней является версия 206), так как
|
||||
разработчики забыли включить в файл +serial-getty@.service+ секцию +[Install]+,
|
||||
в результате чего попытка выполнения +systemctl enable+ для экземпляра
|
||||
соответствующей службы ведет к закономерной ошибке. Впрочем, исправить это
|
||||
несложно: достаточно скопировать данный файл в +/etc/systemd/system/+, после
|
||||
чего дописать в него секцию +[Install]+ с параметром +WantedBy=getty.target+, а
|
||||
затем выполнить +systemctl daemon-reload+.}:
|
||||
работать с символьными ссылками пришлось бы даже в более свежих версиях
|
||||
systemd (до 209 включительно), так как в файле +serial-getty@.service+
|
||||
отсутствовала секция +[Install]+, в результате чего попытка выполнения
|
||||
+systemctl enable+ для экземпляра соответствующей службы приводила к
|
||||
закономерной ошибке. Данная проблема была устранена только в systemd 210.
|
||||
В~случае использования более старых версий, исправить ее можно и самостоятельно:
|
||||
достаточно скопировать указанный файл из +/usr/lib/systemd/system/+ в
|
||||
+/etc/systemd/system/+, после чего дописать в него секцию +[Install]+,
|
||||
содержащую параметр +WantedBy=getty.target+, и затем выполнить
|
||||
+systemctl daemon-reload+.}:
|
||||
\begin{Verbatim}
|
||||
# systemctl enable serial-getty@ttyS2.service
|
||||
# systemctl start serial-getty@ttyS2.service
|
||||
@@ -3576,8 +3586,9 @@ daemon-reload}.}\footnote{\label{ftn:enableserial}Прим. перев.: На с
|
||||
а также сообщения, которые процессы служб выводят на STDOUT и STDERR. Полученная
|
||||
информация индексируется и предоставляется пользователю по запросу. Journal
|
||||
может работать одновременно с традиционными демоном syslog (например, rsyslog
|
||||
или syslog-ng), либо полностью его заменять. Более подробно см. в
|
||||
\href{http://0pointer.de/blog/projects/the-journal.html}{первом анонсе}.
|
||||
или syslog-ng), либо полностью его заменять. За подробностями стоит
|
||||
обратиться к \href{http://0pointer.de/blog/projects/the-journal.html}{первому
|
||||
анонсу}.
|
||||
|
||||
Journal был включен в Fedora начиная с F17. В Fedora~18 journal вырос в мощный и
|
||||
удобный механизм работы с системным журналом. Однако, и в~F17, и в~F18 journal
|
||||
@@ -4090,9 +4101,9 @@ systemd создавать соответствующие группы, доба
|
||||
документации}. Отметим, что из-за планируемого прекращения поддержки параметра
|
||||
+memory.soft_limit_in_bytes+ на уровне ядра, опция +MemorySoftLimit=+ была
|
||||
\href{http://cgit.freedesktop.org/systemd/systemd/commit/?id=ddca82aca08712a302cfabdbe59f73ee9ed3f73a}%
|
||||
{удалена} из systemd начиная с версии 207.}. При этом поддерживаются суффиксы K,
|
||||
M, G и T, обозначающие соответственно, килобайт, мегабайт, гигабайт и терабайт
|
||||
(по основанию 1024).
|
||||
{удалена} из systemd, начиная с версии 208.}. При этом поддерживаются суффиксы
|
||||
K, M, G и T, обозначающие соответственно, килобайт, мегабайт, гигабайт и
|
||||
терабайт (по основанию 1024).
|
||||
\begin{Verbatim}
|
||||
.include /usr/lib/systemd/system/httpd.service
|
||||
|
||||
@@ -4416,7 +4427,11 @@ $ gdbus call --system --dest org.freedesktop.systemd1 --object-path /org/freedes
|
||||
те, которые пока не~поддерживают, ее
|
||||
\href{http://0pointer.de/blog/projects/socket-activation.html}{не~так уж} и
|
||||
\href{http://0pointer.de/blog/projects/socket-activation2.html}{сложно}
|
||||
добавить). Реализованный в systemd механизм управления
|
||||
добавить\footnote{Прим. перев.: Начиная с версии 209, в состав systemd входит
|
||||
утилита
|
||||
\hreftt{http://www.freedesktop.org/software/systemd/man/systemd-socket-proxyd.html}%
|
||||
{systemd-socket-proxyd}, позволяющая использовать сокет-активацию даже для
|
||||
служб, которые ее не~поддерживают.}). Реализованный в systemd механизм управления
|
||||
\hyperref[sec:instances]{экземплярами служб} позволяет подготовить
|
||||
универсальные шаблоны конфигурации служб, и в соответствии с ними для каждого
|
||||
сайта будет запускаться свой экземпляр службы. Кроме того, не~стоит забывать,
|
||||
@@ -4545,14 +4560,22 @@ ListenStream=23
|
||||
слушать 23-й TCP-порт хоста. В примере выбран именной 23-й, потому что 22-й
|
||||
скорее всего окажется занят SSH-сервером самого хоста. nspawn виртуализует
|
||||
списки процессов и точек монтирования, но не~сетевые стеки, поэтому порты хоста
|
||||
и гостей не~должны конфликтовать\footnote{Прим. перев.: Ограниченные возможности
|
||||
виртуализации сети в +systemd-nspawn+ значительно затрудняют использование
|
||||
описываемой технологии. Ее практическое применение будет иметь смысл
|
||||
либо в lxc-libvirt, либо после расширения возможностей nspawn. Впрочем, опытные
|
||||
администраторы легко могут найти обходные пути, например: присваивание хосту
|
||||
дополнительного IP-адреса (безо всякой виртуализации, командой +ip addr add+) и
|
||||
привязка слушающих сокетов к конкретным адресам (в параметре +ListenStream=+
|
||||
сокет-файлов и/или в директиве +ListenAddress+ файла +sshd_config+ хоста).}.
|
||||
и гостей не~должны конфликтовать\footnote{Прим. перев.: До выхода 209 версии
|
||||
systemd, возможности по виртуализации сети в +systemd-nspawn+ были весьма
|
||||
ограниченными (поддерживалась только полная изоляция сети от хоста), что весьма
|
||||
затрудняло использование описываемой технологии. Впрочем, опытные администраторы
|
||||
легко могли найти обходные пути, например: присваивание хосту дополнительного
|
||||
IP-адреса (безо всякой виртуализации, командой +ip addr add+) и привязка
|
||||
слушающих сокетов к конкретным адресам (в параметре +ListenStream=+ сокет-файлов
|
||||
и/или в директиве +ListenAddress+ файла +sshd_config+ хоста). Начиная с systemd
|
||||
версии 209, +systemd-nspawn+ предоставляет довольно широкие возможности по
|
||||
виртуализации сети: проброс сетевого интерфейса хоста в контейнер
|
||||
(+--network-interface=+), а также создание в контейнере виртуального сетевого
|
||||
интерфейса (+--network-veth+), связывающего его с хостом. Такой виртуальный
|
||||
интерфейс при необходимости может быть объединен в мост с интерфейсами хоста
|
||||
(+--network-bridge=+), что обеспечит доступ из контейнера к соответствующим
|
||||
сегментам сети. Подробности см. на~странице руководства
|
||||
\href{http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html}{systemd-nspawn(1)}.}.
|
||||
|
||||
Пока что systemd, работающий внутри контейнера, не~знает, что делать с тем
|
||||
сокетами, которые ему передает systemd хоста. Если вы попробуете подключиться к
|
||||
@@ -4776,9 +4799,8 @@ systemd 198, необязательно копировать файл целик
|
||||
Чтобы обеспечить автоматически запуск getty на этом порту при каждой загрузке,
|
||||
нужно поместить соответствующую символьную ссылку в каталог
|
||||
+getty.target.wants/+\footnote{Прим. перев.: Приведенная в оригинале команда
|
||||
+systemctl enable serial-getty@ttyS2.service+ работать не~будет (по крайней
|
||||
мере, в версиях до 206 включительно). Подробнее
|
||||
см.~примечание~\ref{ftn:enableserial}.}:
|
||||
+systemctl enable serial-getty@ttyS2.service+ в systemd версии 209 и ниже
|
||||
работать не~будет. Подробнее см.~примечание~\ref{ftn:enableserial}.}:
|
||||
\begin{Verbatim}
|
||||
# ln -s /usr/lib/systemd/system/serial-getty@.service \
|
||||
> /etc/systemd/system/getty.target.wants/serial-getty@ttyS2.service
|
||||
@@ -4953,8 +4975,8 @@ $ systemd --test --system --unit=foobar.target
|
||||
|
||||
\section{Диагностика неполадок\sfnote{Перевод статьи
|
||||
<<\href{http://freedesktop.org/wiki/Software/systemd/Debugging}{Debugging
|
||||
systemd Problems}>> с официального сайта проекта, по состоянию на 2013-05-26
|
||||
08:34:30 (коммит 10ae3).}}
|
||||
systemd Problems}>> с официального сайта проекта, по состоянию на 2013-12-20
|
||||
10:44:01 (коммит abb5a).}}
|
||||
|
||||
\subsection{Диагностика проблем с загрузкой}
|
||||
|
||||
@@ -5086,7 +5108,7 @@ systemctl enable debug-shell.service
|
||||
\begin{Verbatim}
|
||||
cd $ПУТЬ_К_ВАШЕМУ_КОРНЮ/etc/systemd/system
|
||||
mkdir -p sysinit.target.wants
|
||||
ln -s /lib/systemd/system/debug-shell.service sysinit.target.wants/
|
||||
ln -s /usr/lib/systemd/system/debug-shell.service sysinit.target.wants/
|
||||
\end{Verbatim}
|
||||
|
||||
Отладочная оболочка будет запущена с правами +root+ на консоли +tty9+
|
||||
@@ -5165,8 +5187,8 @@ sync && poweroff -f
|
||||
systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M enforcing=0
|
||||
\end{Verbatim}
|
||||
|
||||
\item Создайте файл +/lib/systemd/system-shutdown/debug.sh+, добавьте
|
||||
ему право на запуск и запишите в него следующие строки:
|
||||
\item Создайте файл +/usr/lib/systemd/system-shutdown/debug.sh+,
|
||||
добавьте ему право на запуск и запишите в него следующие строки:
|
||||
\begin{Verbatim}
|
||||
#!/bin/sh
|
||||
mount -o remount,rw /
|
||||
@@ -5285,7 +5307,7 @@ systemctl dump > systemd-dump.txt
|
||||
\section{Совместимость с SysV\sfnote{Перевод статьи
|
||||
<<\href{http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities}%
|
||||
{Compatibility with SysV}>> с официального сайта проекта, по
|
||||
состоянию на 2013-05-18 08:20:25 (коммит fa003).}}
|
||||
состоянию на 2013-10-06 21:37:19 (коммит 4db1c).}}
|
||||
|
||||
systemd обеспечивает высокий уровень совместимости с поведением классической
|
||||
системы инициализации SysV init, реализованной во многих дистрибутивах. Это
|
||||
@@ -5421,7 +5443,7 @@ API для скриптов. Тем не~менее, существует ряд
|
||||
\section{Предсказуемые имена сетевых интерфейсов\sfnote{Перевод статьи
|
||||
<<\href{http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames}%
|
||||
{Predictable Network Interface Names}>> с официального сайта проекта, по
|
||||
состоянию на 2013-09-10 01:52:06 (коммит c0524).}}
|
||||
состоянию на 2014-02-21 15:36:45 (коммит 5613f).}}
|
||||
|
||||
Начиная с версии 197, systemd/udev присваивает сетевым интерфейсам (Ethernet,
|
||||
WLAN, WWAN\footnote{Прим. перев.: WWAN (Wireless Wide Area Network)~---
|
||||
@@ -5562,40 +5584,65 @@ systemd/udev\footnote{Прим. перев.: См. коммит
|
||||
\begin{enumerate}
|
||||
\item Вы можете полностью отключить новую схему, вернувшись к
|
||||
классическим непредсказуемым именам. Для этого достаточно
|
||||
заблокировать (замаскировать) соответствующий файл правил udev:
|
||||
заблокировать (замаскировать) файл правил udev, отвечающий за
|
||||
именование интерфейсов:
|
||||
\begin{Verbatim}
|
||||
ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules
|
||||
ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules
|
||||
\end{Verbatim}
|
||||
(Заметим, что в версиях systemd со 197 по 208 соответствующий
|
||||
файл назывался +80-net-name-slot.rules+.)
|
||||
\item Вы можете вручную назначить интерфейсам наиболее понятные для вас
|
||||
имена (например, +internet0+, +dmz0+, +lan0+). Для этого,
|
||||
подготовьте свои собственные правила, указав в них нужные имена
|
||||
при помощи параметра +NAME+, после чего сохраните их в файл с
|
||||
более высоким приоритетом, чем правила по умолчанию, например,
|
||||
+/etc/udev/rules.d/70-my-net-names.rules+. (Приоритет файлов
|
||||
определяется на основании алфавитной сортировки их имен.)
|
||||
+/etc/udev/rules.d/70-my-net-names.rules+\footnote{Прим. перев.:
|
||||
Начиная с systemd 209, существует более удобный способ настройки
|
||||
имен и других параметров сетевых интерфейсов (MAC-адреса,
|
||||
скорости, дуплекса, MTU, состояния Wake on LAN)~--- он описан в
|
||||
секции <<Network Link Configuration>> на странице руководства
|
||||
\href{http://www.freedesktop.org/software/systemd/man/udev.html#Network%20Link%20Configuration}{udev(7)}.}.
|
||||
(Приоритет файлов определяется на основании алфавитной
|
||||
сортировки их имен.)
|
||||
\item Вы можете скорректировать правила, используемые по умолчанию,
|
||||
например, задействовав схему именования интерфейсов по
|
||||
MAC-адресам. Для, этого скопируйте файл правил в каталог +/etc+
|
||||
MAC-адресам. Для, этого скопируйте соответствующий
|
||||
конфигурационный файл в каталог +/etc+
|
||||
\begin{Verbatim}
|
||||
cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-slot.rules
|
||||
cp /usr/lib/systemd/network/99-default.link /etc/systemd/network/99-default.link
|
||||
\end{Verbatim}
|
||||
после чего измените его так, как считаете нужным.
|
||||
после чего измените значение параметра +NamePolicy=+ так, как
|
||||
считаете нужным (подробнее см.~секцию <<Network Link
|
||||
Configuration>> на странице руководства
|
||||
\href{http://www.freedesktop.org/software/systemd/man/udev.html#Network%20Link%20Configuration}{udev(7)})%
|
||||
\footnote{Прим. перев.: В systemd версий со 197 по 208, за
|
||||
логику именования интерфейсов отвечал файл правил udev
|
||||
+/usr/lib/udev/rules.d/80-net-name-slot.rules+, поэтому
|
||||
копировать из +/usr/lib+ в +/etc+ и редактировать нужно было
|
||||
именно его. Начиная с версии 209, управление именованием
|
||||
интерфейсов вынесено в udev-утилиту (built-in) +net_setup_link+,
|
||||
которая вызывается через файл правил
|
||||
+/etc/udev/rules.d/80-net-setup-link.rules+ и настраивается
|
||||
через файлы +*.link+, размещенные в каталогах
|
||||
+{/etc,/run,/usr/lib}/systemd/network+. За подготовку исходных
|
||||
данных, на основе которых формируются имена интерфейсов, как и
|
||||
раньше, отвечает утилита +net_id+.}.
|
||||
\end{enumerate}
|
||||
|
||||
Кроме того, начиная с systemd версии 199, поддерживается параметр загрузки
|
||||
+net.ifnames=0+, позволяющий отключить механизм предсказуемых имен (указание его
|
||||
в файле конфигурации загрузчика эквивалентно первому из вышеперечисленных
|
||||
вариантов).
|
||||
в файле конфигурации загрузчика практически эквивалентно первому из
|
||||
вышеперечисленных вариантов).
|
||||
|
||||
\subsection{Как именно работает новая схема?}
|
||||
|
||||
Подробности технической реализации описаны в блоке комментариев в
|
||||
\href{http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20}%
|
||||
{исходном коде net-id built-in}. Ознакомьтесь с ним, если у вас возникают
|
||||
{исходном коде net\_id built-in}. Ознакомьтесь с ним, если у вас возникают
|
||||
вопросы, касающиеся расшифровки новых имен\footnote{Прим. перев.: Далее
|
||||
приводится перевод упомянутого блока комментариев. Последним коммитом,
|
||||
затронувшим данный файл, на момент перевода является a4bbe от 8 июля
|
||||
2013 г.}.
|
||||
затронувшим данный файл, на момент перевода является 1cb5d от 11 августа
|
||||
2014 г.}.
|
||||
|
||||
\begin{Verbatim}
|
||||
Предсказуемые имена сетевых интерфейсов формируются на основании:
|
||||
@@ -5606,14 +5653,17 @@ cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-sl
|
||||
|
||||
Первые два символа в имени определяют тип интерфейса:
|
||||
en -- ethernet
|
||||
wl -- wlan
|
||||
ww -- wwan
|
||||
sl -- SLIP (IP через последовательный порт)
|
||||
wl -- WLAN
|
||||
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-устройств
|
||||
@@ -5651,7 +5701,7 @@ Multi-function PCI устройство с двумя портами:
|
||||
ID_NET_NAME_MAC=enx78e7d1ea46dc
|
||||
ID_NET_NAME_PATH=enp2s0f1
|
||||
|
||||
Подключенная к PCI wlan-карта:
|
||||
Подключенная к PCI WLAN-карта:
|
||||
/sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/wlp3s0
|
||||
ID_NET_NAME_MAC=wlx0024d7e31130
|
||||
ID_NET_NAME_PATH=wlp3s0
|
||||
@@ -5780,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{Итак, ваша служба настроена на запуск только после достижения цели
|
||||
@@ -5788,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 Все имеющиеся физические сетевые интерфейсы, на которых
|
||||
@@ -5836,15 +5889,15 @@ network.target, однако, несмотря на это, она все рав
|
||||
такое реагирование в коде демона, на самом деле, не~так уж и сложно. Существует
|
||||
множество хорошо известных сетевых служб, которые уже давно поддерживают такую
|
||||
возможность. Подобные службы можно запускать в любой момент, они устойчивы к
|
||||
сбоям, и в любой ситуации работают корректно.
|
||||
сбоям, и работают корректно во всех возможных ситуациях.
|
||||
|
||||
+network.target+ предназначена для поддержки программ, созданных в
|
||||
\verb+$network+ предназначена для поддержки программ, созданных в
|
||||
предположении, что сеть доступна постоянно (т.е. написанных не~очень аккуратно).
|
||||
Конкретные требования таких программ могут сильно отличаться. Например,
|
||||
IMAP-серверу будет достаточно наличия IP-адреса, на котором можно слушать. В то
|
||||
время как для клиентов сетевых файловых систем требуется требуется доступность и
|
||||
работоспособность сервера, а также, опционально, наличие работоспособного DNS.
|
||||
Таким образом, конкретные требования к +network.target+ сильно зависят от
|
||||
Таким образом, конкретные требования к \verb+$network+ сильно зависят от
|
||||
решаемой задачи.
|
||||
|
||||
По соображениям надежности, загрузка системы не~должна зависеть от второстепенных
|
||||
@@ -5852,6 +5905,12 @@ IMAP-серверу будет достаточно наличия IP-адрес
|
||||
процесс загрузки системы (за исключением ситуаций, когда сетевое соединение
|
||||
действительно необходимо для работы системы, например, при загрузке по сети).
|
||||
|
||||
\begin{comment}
|
||||
% Настоящий фрагмент документации применим к systemd версий 212 и ниже.
|
||||
% Начиная с 11.06.2014 он удален из официальной документации.
|
||||
% Пока остается здесь в виде комментария, для особо дотошных пользователей
|
||||
% старых версий systemd.
|
||||
|
||||
По умолчанию, +network.target+ не~несет какой-либо сакральной смысловой
|
||||
нагрузки. Сама по себе настройка службы на запуск после достижения этой цели
|
||||
не~дает видимого эффекта. Наполнить +network.target+ смыслом должен сам
|
||||
@@ -5897,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+, а о том, как можно исправить
|
||||
@@ -5916,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}%
|
||||
|
||||
Reference in New Issue
Block a user