Version v17.0 (2017-02-17 17:55) [AUTO]

s4a.tex

@@ -23,7 +23,7 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
 	{\smallskip\par}
 \newcommand{\sfnote}[1]{\texorpdfstring{\protect\footnote%
 	{Прим. перев.: #1}}{}}
-\newcommand{\qna}[1]{\medskip\par\textbf{Вопрос: #1}\par Ответ:}
+\newcommand{\qna}[1]{\medskip\par\textbf{Вопрос: #1}\nopagebreak\par Ответ:}
 \newcommand\yousaywtf[1]{\emph{#1}}
 \newcommand\yousaywtfsk[1]{\yousaywtf{#1}\medskip\par}
 % Настройка макета страницы
@@ -3918,6 +3918,7 @@ SELinux ;-) Разумеется, такое дополнение работае
 формате +/var/log/messages+, но с относительными метками времени, как в dmesg.
 
 \section{Управление ресурсами с помощью cgroups}
+\label{sec:resources}
 
 Важную роль в современных компьютерных системах играют механизмы управления
 использованием ресурсов: когда вы запускаете на одной системе несколько
@@ -4667,13 +4668,13 @@ libvirt-lxc или nspawn, но не~c qemu/kvm или xen.
 Если вы будете администрировать несколько таких контейнеров, вас наверняка
 порадует одна из возможностей journal: при запуске на хосте утилиты +journalctl+
 с ключом +-m+, она автоматически обнаружит журналы гостевых контейнеров и
-объединит их вывод с выводом журнала хоста\footnote{Прим. перев.: Этот трюк
+объединит их вывод с выводом журнала хоста\footnote{\label{ftn:jrnmerge}Прим.
-работает благодаря опции +-j+, которую мы передаем программе +systemd-nspawn+
+перев.: Этот трюк работает благодаря опции +-j+, которую мы передаем программе
-при запуске контейнера (см. файл юнита выше). В соответствии с ней, в каталоге
++systemd-nspawn+ при запуске контейнера (см. файл юнита выше). В соответствии с
-+/var/log/journal+ хоста создается символьная ссылку на соответствующий каталог
+ней, в каталоге +/var/log/journal+ хоста создается символьная ссылку на
-гостя. При этом, так как сообщения от гостей имеют другие machine ID, journalctl
+соответствующий каталог гостя. При этом, так как сообщения от гостей имеют
-хоста не~выводит их, если явно не~указать +-m+. Подробности см. на страницах
+другие machine ID, journalctl хоста не~выводит их, если явно не~указать +-m+.
-руководства
+Подробности см. на страницах руководства
 \href{http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html}{systemd-nspawn(1)}
 и
 \href{http://www.freedesktop.org/software/systemd/man/journalctl.html}{journalctl(1)}.}.
@@ -4697,6 +4698,479 @@ systemd, начиная с версии 197. Тем не~менее, наша р
 мощных и хорошо масштабируемых серверных систем. За дополнительной информацией
 обращайтесь к документации или приходите на наш IRC-канал. Спасибо за внимание!
 
+\section{Интеграция с контейнерами}
+
+В последнее время, все большую популярность набирает тема использования
+Linux-контейнеров, а вместе с ней на первый план выходят различные реализации
+систем управления контейнерами, такие, как libvirt-lxc, LXC и Docker. В данной
+статье я попробую рассказать о некоторых механизмах интеграции между systemd и
+подобными системами, обеспечивающих унифицированное, <<бесшовное>>
+управление службами, работающими на хосте и в его контейнерах.
+
+В центре нашего внимания будут находиться контейнеры операционных систем (OS
+containers), в которых запускается собственный процесс init. Работающая внутри
+такого контейнера система во многом аналогична полноценной ОС, выполняющейся на
+физическом компьютере\footnote{Прим. перев.: Этим они отличаются от контейнеров
+приложений (apps containers), в которых запускается только само приложение и его
+вспомогательные процессы. Стоит отметить, что из-за широкого использования
+механизмов cgroups и namespaces в systemd, практически любой service-юнит можно
+превратить в контейнер приложения при помощи ряда настроек в его
+конфигурационном файле. См. главы~\ref{sec:chroots}, \ref{sec:security},
+\ref{sec:resources}.}. Б\'{о}льшая часть описанного в данной статье применима ко
+всем программам для управления контейнерами, разработанным с учетом
+\href{http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/}{рекомендаций}
+по интеграции с systemd (в частности, такая интеграция обеспечена в libvirt-lxc).
+Однако, для простоты изложения, в практических примерах мы будем использовать
+\href{http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html}{systemd-nspawn},
+минималистичную утилиту для управления контейнерами, поставляемую в комплекте с
+systemd. Она использует те же низкоуровневые механизмы, что и другие системы
+управления контейнерами, но отличается предельной простотой использования, пусть
+даже в ущерб гибкости, универсальности и настраиваемости. Мы сами активно
+используем эту утилиту при разработке и тестировании systemd.
+
+Итак, начнем. Первой нашей задачей является развертывание в отдельном каталоге
+образа гостевой операционной системы:
+\begin{Verbatim}
+# yum -y --releasever=20 --nogpg --installroot=/srv/mycontainer \
+> --disablerepo='*' --enablerepo=fedora \
+> install systemd passwd yum fedora-release vim-minimal
+\end{Verbatim}
+
+Эта команда загрузит пакеты, необходимых для создания минимального образа
+Fedora~20, и установит их в каталог +/srv/mycontainer+. Аналогичные команды
+существуют и для других дистрибутивов, в частности, некоторые из них приведены в
+разделе примеров страницы руководства
+\href{http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html\#Examples}{systemd-nspawn(1)}.
+
+Наш контейнер практически готов, осталось лишь задать для него пароль +root+:
+\begin{Verbatim}
+# systemd-nspawn -D /srv/mycontainer
+Spawning container mycontainer on /srv/mycontainer
+Press ^] three times within 1s to kill container.
+-bash-4.2# passwd
+Changing password for user root.
+New password:
+Retype new password:
+passwd: all authentication tokens updated successfully.
+-bash-4.2# ^D
+Container mycontainer exited successfully.
+#
+\end{Verbatim}
+
+Мы использовали systemd-nspawn в <<режиме chroot>>, чтобы получить
+командную оболочку внутри контейнера (не~запуская гостевую систему целиком), и из этой
+оболочки задать пароль +root+. На этом предварительная настройка заканчивается.
+Теперь мы можем загрузить ОС внутри контейнера и войти в нее, используя заданный
+нами пароль:
+\begin{Verbatim}[fontsize=\small]
+$ systemd-nspawn -D /srv/mycontainer -b
+Spawning container mycontainer on /srv/mycontainer.
+Press ^] three times within 1s to kill container.
+systemd 208 running in system mode. (+PAM +LIBWRAP +AUDIT +SELINUX +IMA +SYSVINIT +LIBCRYPTSETUP +GCRYPT +ACL +XZ)
+Detected virtualization 'systemd-nspawn'.
+
+Welcome to Fedora 20 (Heisenbug)!
+
+[  OK  ] Reached target Remote File Systems.
+[  OK  ] Created slice Root Slice.
+[  OK  ] Created slice User and Session Slice.
+[  OK  ] Created slice System Slice.
+[  OK  ] Created slice system-getty.slice.
+[  OK  ] Reached target Slices.
+[  OK  ] Listening on Delayed Shutdown Socket.
+[  OK  ] Listening on /dev/initctl Compatibility Named Pipe.
+[  OK  ] Listening on Journal Socket.
+         Starting Journal Service...
+[  OK  ] Started Journal Service.
+[  OK  ] Reached target Paths.
+         Mounting Debug File System...
+         Mounting Configuration File System...
+         Mounting FUSE Control File System...
+         Starting Create static device nodes in /dev...
+         Mounting POSIX Message Queue File System...
+         Mounting Huge Pages File System...
+[  OK  ] Reached target Encrypted Volumes.
+[  OK  ] Reached target Swap.
+         Mounting Temporary Directory...
+         Starting Load/Save Random Seed...
+[  OK  ] Mounted Configuration File System.
+[  OK  ] Mounted FUSE Control File System.
+[  OK  ] Mounted Temporary Directory.
+[  OK  ] Mounted POSIX Message Queue File System.
+[  OK  ] Mounted Debug File System.
+[  OK  ] Mounted Huge Pages File System.
+[  OK  ] Started Load/Save Random Seed.
+[  OK  ] Started Create static device nodes in /dev.
+[  OK  ] Reached target Local File Systems (Pre).
+[  OK  ] Reached target Local File Systems.
+         Starting Trigger Flushing of Journal to Persistent Storage...
+         Starting Recreate Volatile Files and Directories...
+[  OK  ] Started Recreate Volatile Files and Directories.
+         Starting Update UTMP about System Reboot/Shutdown...
+[  OK  ] Started Trigger Flushing of Journal to Persistent Storage.
+[  OK  ] Started Update UTMP about System Reboot/Shutdown.
+[  OK  ] Reached target System Initialization.
+[  OK  ] Reached target Timers.
+[  OK  ] Listening on D-Bus System Message Bus Socket.
+[  OK  ] Reached target Sockets.
+[  OK  ] Reached target Basic System.
+         Starting Login Service...
+         Starting Permit User Sessions...
+         Starting D-Bus System Message Bus...
+[  OK  ] Started D-Bus System Message Bus.
+         Starting Cleanup of Temporary Directories...
+[  OK  ] Started Cleanup of Temporary Directories.
+[  OK  ] Started Permit User Sessions.
+         Starting Console Getty...
+[  OK  ] Started Console Getty.
+[  OK  ] Reached target Login Prompts.
+[  OK  ] Started Login Service.
+[  OK  ] Reached target Multi-User System.
+[  OK  ] Reached target Graphical Interface.
+
+Fedora release 20 (Heisenbug)
+Kernel 3.18.0-0.rc4.git0.1.fc22.x86_64 on an x86_64 (console)
+
+mycontainer login: root
+Password:
+-bash-4.2#
+\end{Verbatim}
+
+Наш испытательный стенд готов. Начнем рассмотрение механизмов интеграции systemd
+и контейнеров с утилиты machinectl. Запустив ее без параметров, мы получим
+список работающих в данный момент контейнеров:
+\begin{Verbatim}
+$ machinectl
+MACHINE                          CONTAINER SERVICE
+mycontainer                      container nspawn
+
+1 machines listed.
+\end{Verbatim}
+
+Команда +machinectl status+ позволяет получить детальную информацию о выбранном
+контейнере:
+\begin{Verbatim}[fontsize=\small]
+$ machinectl status mycontainer
+mycontainer:
+       Since: Mi 2014-11-12 16:47:19 CET; 51s ago
+      Leader: 5374 (systemd)
+     Service: nspawn; class container
+        Root: /srv/mycontainer
+     Address: 192.168.178.38
+              10.36.6.162
+              fd00::523f:56ff:fe00:4994
+              fe80::523f:56ff:fe00:4994
+          OS: Fedora 20 (Heisenbug)
+        Unit: machine-mycontainer.scope
+              ├─5374 /usr/lib/systemd/systemd
+              └─system.slice
+                ├─dbus.service
+                │ └─5414 /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-act...
+                ├─systemd-journald.service
+                │ └─5383 /usr/lib/systemd/systemd-journald
+                ├─systemd-logind.service
+                │ └─5411 /usr/lib/systemd/systemd-logind
+                └─console-getty.service
+                  └─5416 /sbin/agetty --noclear -s console 115200 38400 9600
+\end{Verbatim}
+В частности, она отображает дерево контрольных групп и процессов контейнера, его
+IP-адреса и корневой каталог.
+
+Команда +machinectl login+ позволяет войти внутрь работающего контейнера,
+запустив в нем еще одну командную оболочку:
+\begin{Verbatim}
+# machinectl login mycontainer
+Connected to container mycontainer. Press ^] three times within 1s to exit session.
+
+Fedora release 20 (Heisenbug)
+Kernel 3.18.0-0.rc4.git0.1.fc22.x86_64 on an x86_64 (pts/0)
+
+mycontainer login:
+\end{Verbatim}
+
+Команда +machinectl reboot+ перезагружает контейнер:
+\begin{Verbatim}
+# machinectl reboot mycontainer
+\end{Verbatim}
+
+Команда +machinectl poweroff+ выключает контейнер:
+\begin{Verbatim}
+# machinectl poweroff mycontainer
+\end{Verbatim}
+
+Пожалуй, этих минимальных сведений о machinectl должно быть достаточно. Стоит
+заметить, что ее функциональность не~ограничиваются приведенными здесь командами.
+За подробностями рекомендуем обратиться 
+к~\href{http://www.freedesktop.org/software/systemd/man/machinectl.html}{странице
+руководства}. Еще раз отметим, что данные команды применимы не~только к
+контейнерам на базе systemd-nspawn, но и к другим системам управления
+контейнерами, реализованным с учетом
+\href{http://www.freedesktop.org/wiki/Software/systemd/writing-vm-managers/}{наших
+рекомендаций}, в частности, libvirt-lxc.
+
+Помимо machinectl, в systemd существует и ряд других инструментов, упрощающих
+работу с контейнерами. В частности, большинство управляющих утилит systemd имеют
+встроенную поддержку контейнеров: при помощи ключа +-M+ вы можете указать имя
+нужного вам контейнера, и соответствующая утилита будет работать так, как будто
+запущена внутри этого контейнера\footnote{Прим. перев.: Поддержка данной опции
+добавлена в systemctl, journalctl, loginctl, machinectl, hostnamectl,
+timedatectl, localectl, busctl, systemd-analyze, systemd-run начиная с systemd
+209, в systemd-cgls~--- с systemd 203.}.  Например (не~забудьте снова запустить
+наш тестовый контейнер, если вы его до этого выключили):
+\begin{Verbatim}
+# hostnamectl -M mycontainer set-hostname "wuff"
+\end{Verbatim}
+Приведенная здесь команда
+\href{http://www.freedesktop.org/software/systemd/man/hostnamectl.html}{hostnamectl(1)}
+устанавливает в локальном контейнере +mycontainer+ имя хоста <<+wuff+>>.
+
+А вот пример использования того же ключа +-M+ в программе
+\href{http://www.freedesktop.org/software/systemd/man/systemctl.html}{systemctl(1)}:
+\begin{Verbatim}[fontsize=\small]
+# systemctl -M mycontainer
+UNIT                                 LOAD   ACTIVE SUB       DESCRIPTION
+-.mount                              loaded active mounted   /
+dev-hugepages.mount                  loaded active mounted   Huge Pages File System
+dev-mqueue.mount                     loaded active mounted   POSIX Message Queue File System
+proc-sys-kernel-random-boot_id.mount loaded active mounted   /proc/sys/kernel/random/boot_id
+[...]
+time-sync.target                     loaded active active    System Time Synchronized
+timers.target                        loaded active active    Timers
+systemd-tmpfiles-clean.timer         loaded active waiting   Daily Cleanup of Temporary Directories
+
+LOAD   = Reflects whether the unit definition was properly loaded.
+ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
+SUB    = The low-level unit activation state, values depend on unit type.
+
+49 loaded units listed. Pass --all to see loaded but inactive units, too.
+To show all installed unit files use 'systemctl list-unit-files'.
+\end{Verbatim}
+Как нетрудно догадаться, эта команда выводит список активных юнитов гостевой
+системы контейнера. (Чтобы не~загромождать нашу статью лишним текстом, часть
+листинга пропущена.)
+
+Перезапустить службу внутри гостевой системы также не~представляет проблемы:
+\begin{Verbatim}
+# systemctl -M mycontainer restart systemd-resolved.service
+\end{Verbatim}
+
+Поддержка контейнеров в утилите +systemctl+ не~ограничивается ключом +-M+.
+Она имеет еще и ключ +-r+ (рекурсивный режим)\footnote{Прим. перев.:
+Поддержка этой опции при выводе списка юнитов появилась начиная с systemd~212,
+при выводе списков таймеров и сокетов (+systemctl list-timers+ и 
++systemctl list-sockets+)~--- начиная с systemd~213.}, позволяющий выводить
+объединенный список юнитов для хоста и всех работающих гостевых систем:
+\begin{Verbatim}[fontsize=\small]
+# systemctl -r
+UNIT                                        LOAD   ACTIVE SUB       DESCRIPTION
+boot.automount                              loaded active waiting   EFI System Partition Automount
+proc-sys-fs-binfmt_misc.automount           loaded active waiting   Arbitrary Executable File Formats File Syst
+sys-devices-pci0000:00-0000:00:02.0-drm-card0-card0\x2dLVDS\x2d1-intel_backlight.device loaded active plugged   /sys/devices/pci0000:00/0000:00:02.0/drm/ca
+[...]
+timers.target                               loaded active active    Timers
+mandb.timer                                 loaded active waiting   Daily man-db cache update
+systemd-tmpfiles-clean.timer                loaded active waiting   Daily Cleanup of Temporary Directories
+mycontainer:-.mount                         loaded active mounted   /
+mycontainer:dev-hugepages.mount             loaded active mounted   Huge Pages File System
+mycontainer:dev-mqueue.mount                loaded active mounted   POSIX Message Queue File System
+[...]
+mycontainer:time-sync.target                loaded active active    System Time Synchronized
+mycontainer:timers.target                   loaded active active    Timers
+mycontainer:systemd-tmpfiles-clean.timer    loaded active waiting   Daily Cleanup of Temporary Directories
+
+LOAD   = Reflects whether the unit definition was properly loaded.
+ACTIVE = The high-level unit activation state, i.e. generalization of SUB.
+SUB    = The low-level unit activation state, values depend on unit type.
+
+191 loaded units listed. Pass --all to see loaded but inactive units, too.
+To show all installed unit files use 'systemctl list-unit-files'.
+\end{Verbatim}
+
+Как видно из листинга, сначала выводится список юнитов хоста, после которого
+идет список юнитов нашего контейнера. Перед именами юнитов гостевой системы,
+через двоеточие, указывается имя контейнера. (По традиции, листинг сокращен.)
+
+Команда +systemctl list-machines+ опрашивает процессы init всех работающих
+контейнеров, и по результатам выводит список работающих систем 
+(хостовой и всех гостевых), с указанием их текущего состояния и наличия 
+ошибок загрузки.
+\begin{Verbatim}
+# systemctl list-machines
+NAME         STATE   FAILED JOBS
+delta (host) running      0    0
+mycontainer  running      0    0
+miau         degraded     1    0
+waldi        running      0    0
+
+4 machines listed.
+\end{Verbatim}
+
+Для большей наглядности мы запустили еще два контейнера. В одном из них
+произошла ошибка запуска юнита, поэтому его состояние характеризуется как
+<<+degraded+>>.
+
+А теперь обсудим поддержку контейнеров в утилите
+\href{http://www.freedesktop.org/software/systemd/man/journalctl.html}{journalctl(1)}.
+Во-первых, она позволяет использовать описанную выше опцию +-M+:
+\begin{Verbatim}[fontsize=\small]
+# journalctl -M mycontainer -n 8
+Nov 12 16:51:13 wuff systemd[1]: Starting Graphical Interface.
+Nov 12 16:51:13 wuff systemd[1]: Reached target Graphical Interface.
+Nov 12 16:51:13 wuff systemd[1]: Starting Update UTMP about System Runlevel Changes...
+Nov 12 16:51:13 wuff systemd[1]: Started Stop Read-Ahead Data Collection 10s After Completed Startup.
+Nov 12 16:51:13 wuff systemd[1]: Started Update UTMP about System Runlevel Changes.
+Nov 12 16:51:13 wuff systemd[1]: Startup finished in 399ms.
+Nov 12 16:51:13 wuff sshd[35]: Server listening on 0.0.0.0 port 24.
+Nov 12 16:51:13 wuff sshd[35]: Server listening on :: port 24.
+\end{Verbatim}
+
+Во-вторых, стоит упомянуть опцию +-m+ (режим слияния), выводящую объединенный
+поток журнальных записей хоста и всех его гостевых систем\footnote{Прим. перев.:
+Чтобы данная опция действительно работала именно так, необходимо, чтобы в
+каталоге +/var/log/journal+ хоста присутствовали символьные ссылки на каталоги с
+логами гостевых систем, либо было выполнено их bind-монтирование. См.
+примечание~\ref{ftn:jrnmerge}. Стоит заметить что, помимо логов контейнеров, в
+этом каталоге могут оказаться и логи других компьютеров, если у вас настроен их
+сбор с помощью
+\href{http://www.freedesktop.org/software/systemd/man/systemd-journal-remote.html}{systemd-journal-remote(8)}
+или иных инструментов.}.: 
+\begin{Verbatim}
+# journalctl -m -e
+\end{Verbatim}
+(Здесь вывод команды опущен полностью. Думаю, вам будет несложно представить
+себе, как он выглядит.)
+
+Поддержка контейнеров присутствует не~только в утилитах systemd, но и в
+программах из комплекта procps\footnote{Прим. перев.: Начиная с выпуска procps
+3.3.8.}:
+\begin{Verbatim}[fontsize=\small]
+# ps -eo pid,machine,args
+ PID MACHINE        COMMAND
+   1 -              /usr/lib/systemd/systemd --switched-root --system --deserialize 20
+[...]
+2915 -              emacs contents/projects/containers.md
+3403 -              [kworker/u16:7]
+3415 -              [kworker/u16:9]
+4501 -              /usr/libexec/nm-vpnc-service
+4519 -              /usr/sbin/vpnc --non-inter --no-detach --pid-file /var/run/NetworkManager/nm-vpnc-bfda8671-f025-4812-a66b-362eb12e7f13.pid -
+4749 -              /usr/libexec/dconf-service
+4980 -              /usr/lib/systemd/systemd-resolved
+5006 -              /usr/lib64/firefox/firefox
+5168 -              [kworker/u16:0]
+5192 -              [kworker/u16:4]
+5193 -              [kworker/u16:5]
+5497 -              [kworker/u16:1]
+5591 -              [kworker/u16:8]
+5711 -              sudo -s
+5715 -              /bin/bash
+5749 -              /home/lennart/projects/systemd/systemd-nspawn -D /srv/mycontainer -b
+5750 mycontainer    /usr/lib/systemd/systemd
+5799 mycontainer    /usr/lib/systemd/systemd-journald
+5862 mycontainer    /usr/lib/systemd/systemd-logind
+5863 mycontainer    /bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation
+5868 mycontainer    /sbin/agetty --noclear --keep-baud console 115200 38400 9600 vt102
+5871 mycontainer    /usr/sbin/sshd -D
+6527 mycontainer    /usr/lib/systemd/systemd-resolved
+[...]
+\end{Verbatim}
+Здесь приводится (сокращенный) список процессов хоста и всех гостевых систем.
+Во втором столбце указывается имя контейнера (<<+-+>> соответствует системе
+хоста).
+
+Но наша работа по поддержке взаимодействия с контейнерами этим
+не~ограничивается. В частности, мы добавили такую поддержку в <<sd-bus>>~---
+разрабатываемую нами клиентскую библиотеку D-Bus/kdbus. Если вызов
++sd_bus_open_system()+ позволяет подключаться к шине вашей локальной системы, то
+\hreftt{http://www.freedesktop.org/software/systemd/man/sd_bus_open_system_container.html}{sd\_bus\_open\_system\_container()}
+открывает соединение к шине выбранного гостевого контейнера, обеспечивая прямой
+доступ к ее интерфейсам и методам.
+
+\hreftt{http://www.freedesktop.org/software/systemd/man/sd_pid_get_machine_name.html}{sd-login.h}
+и \href{http://www.freedesktop.org/wiki/Software/systemd/machined/}{D-Bus
+интерфейс демона machined} предоставляют API для реализации поддержки
+контейнеров в сторонних программах. В частности, они содержат функции для
+определения имени контейнера по PID процесса, получения списка работающих
+контейнеров и т.д.
+
+systemd-networkd также имеет встроенную поддержку контейнеров. Когда он
+запускается внутри контейнера, он автоматически задействует DHCP-клиент и
+выполняет настройку IPv4LL-адреса\footnote{Прим. перев.: Механизм IPv4LL
+предоставляет простой метод автоматической настройки сетевых адресов в пределах
+одного сегмента. Сетевому интерфейсу присваивается случайно выбранный незанятый
+IP-адрес из специально зарезервированного диапазона 162.254.0.0/16.} на
+виртуальном сетевом интерфейсе с именем +host0+ (имя и назначение этого
+интерфейса оговаривается в
+\href{http://www.freedesktop.org/wiki/Software/systemd/ContainerInterface/}{наших
+рекомендациях}, которые должны поддерживаться вашей системой управления
+контейнерами). Когда networkd работает на хост-системе, он
+предоставляет функции DHCP-сервера и настраивает IPv4LL-адреса на всех
+виртуальных интерфейсах с именами вида +ve-имя_контейнера+.
+
+И наконец, последний из рассматриваемых в этой статье аспектов интеграции
+systemd и контейнеров: взаимодействие с NSS. В составе свежих версий
+systemd\footnote{Прим.  перев.: Начиная с версии 216.} поставляется NSS-модуль
+nss-mymachines, позволяющий преобразовывать имена контейнеров в их IP-адреса
+при помощи вызовов
+\hreftt{http://man7.org/linux/man-pages/man3/gethostbyname.3.html}{gethostbyname()}
+и
+\hreftt{http://man7.org/linux/man-pages/man3/getaddrinfo.3.html}{getaddrinfo()}.
+Разумеется, это применимо лишь к контейнерам, которые имеют собственное сетевое
+пространство имен (netns), т.е. свой сетевой стек. Команда systemd-nspawn,
+приведенная выше, запускает контейнер в сетевом стеке хоста, поэтому, чтобы
+продемонстрировать работу обсуждаемых механизмов, нам придется перезапустить
+этот контейнер с отдельным сетевым стеком, в котором systemd-nspawn создаст
+виртуальный сетевой интерфейс (+veth+), связывающий контейнер с хостом:
+\begin{Verbatim}
+# machinectl poweroff mycontainer
+# systemd-nspawn -D /srv/mycontainer --network-veth -b
+\end{Verbatim}
+
+Теперь, если в контейнере и на хосте работает systemd-networkd, мы можем
+обращаться к контейнеру через сеть просто по его имени, которое при помощи
+модуля nss-mymachines будет автоматически преобразовано в его
+IP-адрес\footnote{Прим. перев.: Для корректной работы модуля nss-mymachines,
+он должен быть указан в конфигурационном файле +/etc/nsswitch.conf+, в строке
+hosts. В частности, в поставляемом с systemd варианте этого файла, данная
+строчка выглядит так: <<+hosts: files mymachines resolve myhostname+>>. Помимо
+mymachines, в ней фигурируют и другие NSS-модули systemd: resolve отвечает
+за взаимодействие с кэширующим DNS-сервером systemd-resolved, а myhostname
+обеспечивает корректное преобразование системного имени хоста в IP-адрес
+127.0.0.2, даже при отсутствии соответствующей записи в +/etc/hosts+.}:
+\begin{Verbatim}
+# ping mycontainer
+PING mycontainer (10.0.0.2) 56(84) bytes of data.
+64 bytes from mycontainer (10.0.0.2): icmp_seq=1 ttl=64 time=0.124 ms
+64 bytes from mycontainer (10.0.0.2): icmp_seq=2 ttl=64 time=0.078 ms
+\end{Verbatim}
+
+Разумеется, преобразование имен контейнеров в IP-адреса и обратно работает
+не~только для утилиты +ping+, но и для всех остальных программ, использующих
+функции libc +gethostbyname()+ и +getaddrinfo()+, в том числе и для нашей
+любимой и незаменимой +ssh+.
+
+Вот и все, о чем я хотел рассказать в данной статье. Мы кратко прошлись по
+основным моментам интеграции systemd и контейнеров. Изложение не~претендует на
+полноту, и очень многие детали оказались <<за бортом>>~--- о них вы можете
+узнать из документации. Кроме того, в настоящее время мы продолжаем работу над
+более тесной интеграцией с контейнерами, так что ожидайте новых возможностей в
+этой области с ближайшими выпусками systemd.
+
+В завершение стоит отметить, что концепция машины (machine) применима не~только
+к контейнерам, но и, в некоторой степени, к полноценным виртуальным машинами.
+Однако, в случае виртуальных машин, доступ к гостевым системам с хоста
+реализуется несколько сложнее, чем в контейнерах~--- вместо прямого доступа к
+системным вызовам, приходится использовать взаимодействие через
+сеть\footnote{Прим. перев.: Можно предположить, что здесь автор пытается
+намекнуть на опцию +-H [user@]host[:container]+, позволяющую обращаться к
+другим хостам и их контейнерам через сеть при помощи SSH-транспорта,
+реализованного в шине D-Bus. Эта опция поддерживается в большинстве управляющих
+утилит systemd (systemctl, loginctl, machinectl, hostnamectl, timedatectl,
+localectl, busctl, systemd-analyze, systemd-run).}.
+
+В любом случае, надеюсь, что статья для кого-то оказалась полезной. За
+подробностями обращайтесь к документации (начать изучение темы можно со ссылок,
+приведенных в этой статье).
+
 \appendix
 
 \section{FAQ (часто задаваемые вопросы)\sfnote{Перевод статьи
@@ -4850,12 +5324,12 @@ $ psc
 \qna{Почему вы не~используете inotify для отслеживания изменений в настройках?}
 К сожалению, реализовать это весьма проблематично. За подробностями вы можете
 обратиться к обсуждению в
-\href{https://bugzilla.redhat.com/show_bug.cgi?id=615527}{bugzilla}\footnote{Прим.
+\href{https://bugzilla.redhat.com/show_bug.cgi?id=615527}{bugzilla}%
-перев.: Вкратце, суть проблемы состоит в том, что перемещение/переименование
+\footnote{\label{ftn:cons}Прим. перев.: Вкратце, суть проблемы состоит в том,
-файла не~является атомарной операцией, а состоит из удаления одного файла и
+что перемещение/переименование файла не~является атомарной операцией, а состоит
-создания другого. Эти операции могут следовать в произвольном порядке с
+из удаления одного файла и создания другого. Эти операции могут следовать в
-некоторым интервалом, что может привести к временному исчезновению службы, либо
+произвольном порядке с некоторым интервалом, что может привести к временному
-к появлению двух конфликтующих служб.}.
+исчезновению службы, либо к появлению двух конфликтующих служб.}.
 
 \qna{У моей службы есть как штатный service-файл, так и init-скрипт (с тем же
 именем). Какой из этих файлов главнее~---
@@ -4887,7 +5361,7 @@ systemd все работало!}
 Это длинная история. См. приложение~\ref{sec:networktarget}.
 
 \qna{systemd монтирует в \texttt{/tmp} \texttt{tmpfs}. Как это отключить?}
-Это тоже долгая история. См. приложения~\ref{sec:apifs}.
+Это тоже долгая история. См. приложение~\ref{sec:apifs}.
 
 \qna{Как просмотреть список работающих служб?}
 Запустите команду +systemctl+ без параметров\footnote{Прим. перев.: +systemctl+
@@ -4975,8 +5449,8 @@ $ systemd --test --system --unit=foobar.target
 
 \section{Диагностика неполадок\sfnote{Перевод статьи
 <<\href{http://freedesktop.org/wiki/Software/systemd/Debugging}{Debugging
-systemd Problems}>> с официального сайта проекта, по состоянию на 2013-12-20
+systemd Problems}>> с официального сайта проекта, по состоянию на 2017-01-29
-10:44:01 (коммит abb5a).}}
+06:18:38 (коммит 903f7).}}
 
 \subsection{Диагностика проблем с загрузкой}
 
@@ -4996,9 +5470,9 @@ Welcome to \textcolor{blue}{Fedora \emph{ВЕРСИЯ} (\emph{имя релиз
 Если у вас есть доступ к оболочке, это значительно упрощает диагностику и
 решение проблем. В том случае, когда до приглашения входа в систему дело так и
 не~доходит, попробуйте переключиться на другую виртуальную консоль, нажав
-CTRL--ALT--F<\emph{цифра}>. При проблемах, связанных с запуском X-сервера, может
+CTRL--ALT--F<\emph{цифра}>. При проблемах, связанных с запуском графического
-возникать ситуация, когда на первой консоли (+tty1+) приглашение ко входу
+сервера, может возникать ситуация, когда на первой консоли (+tty1+) приглашение
-отсутствует, но все остальные консоли при этом работают нормально.
+ко входу отсутствует, но все остальные консоли при этом работают нормально.
 
 Если ни~на одной из виртуальных консолей приглашение так и не~появилось~---
 попробуйте выждать еще \emph{не~менее 5 минут}. Только после этого можно
@@ -5050,6 +5524,14 @@ CTRL--ALT--F<\emph{цифра}>. При проблемах, связанных
 	соответствующие параметры см. в разделе~\ref{sssec:kmsg}.}:
 \begin{Verbatim}
 systemd.log_level=debug systemd.log_target=console console=ttyS0,38400
+\end{Verbatim}
+
+	Вышеприведенный способ удобен для диагностики проблем, непосредственно
+	связанных с systemd. Если же сбой происходит при запуске системных служб
+	(например, сети), целесообразно перенаправить на консоль вывод
+	системного журнала:
+\begin{Verbatim}
+systemd.journald.forward_to_console=1 console=ttyS0,38400
 \end{Verbatim}
 
 \item[Загрузка в восстановительном (rescue) или аварийном (emergency)
@@ -5094,21 +5576,18 @@ mount -o remount,rw /
 \begin{Verbatim}
 systemctl enable debug-shell.service
 \end{Verbatim}
-	
+	или укажите
-	\textbf{Совет:} Если вы используете старую версию systemd, в которой еще
-	не~реализована поддержка отладочной оболочки, вы можете загрузить
-	соответствующий файл конфигурации юнита из
-	\href{http://cgit.freedesktop.org/systemd/systemd/plain/units/debug-shell.service.in}{git-репозитария
-	systemd}. Перед использованием этого файла, замените в нем +@sushell@+
-	на +/bin/bash+.
-
-	\textbf{Совет:} Если вы не~можете воспользоваться командой +systemctl+
-	(например, загрузились с помощью другой операционной системы),
-	выполните соответствующие действия напрямую:
 \begin{Verbatim}
-cd $ПУТЬ_К_ВАШЕМУ_КОРНЮ/etc/systemd/system
+systemd.debug-shell=1
-mkdir -p sysinit.target.wants
+\end{Verbatim}
-ln -s /usr/lib/systemd/system/debug-shell.service sysinit.target.wants/
+	в строке параметров ядра при загрузке.
+	
+	\textbf{Совет:} Если вышеприведенная команда +systemctl enable+ сообщает
+	об ошибке соединения с системным менеджером (такое возможно, например,
+	если вы загрузились с помощью другой операционной системы), вы можете
+	запустить ее в <<автономном режиме>>, явно указав параметр +--root=+:
+\begin{Verbatim}
+systemctl --root=/ enable debug-shell.service
 \end{Verbatim}
 	
 	Отладочная оболочка будет запущена с правами +root+ на консоли +tty9+
@@ -5140,16 +5619,18 @@ ln -s /usr/lib/systemd/system/debug-shell.service sysinit.target.wants/
 воспользоваться ею для сбора диагностической информации. Загрузите систему со
 следующими параметрами ядра:
 \begin{Verbatim}
-systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
+systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on
 \end{Verbatim}
 В соответствии с ними, systemd будет выводить максимально подробные сообщения о
-процессе загрузки, и направлять их в кольцевой буфер ядра (последний параметр
+процессе загрузки, и направлять их в кольцевой буфер ядра (предпоследний параметр
-обеспечивает соответствующее увеличение размера буфера). Дождавшись запуска
+обеспечивает соответствующее увеличение размера буфера, последний параметр
-оболочки, сохраните полученный журнал:
+снимает ограничение на скорость вывода сообщений в буфер). Дождавшись запуска
+оболочки, вы можете просмотреть полученный журнал:
 \begin{Verbatim}
-dmesg > dmesg.txt
+journalctl -b
 \end{Verbatim}
-Отправляя отчет об ошибке, присоедините к нему полученный файл +dmesg.txt+.
+Отправляя отчет об ошибке, перенаправьте вывод этой команды в файл и
+присоедините его к отчету.
 
 Также, вы можете просмотреть список операций, чтобы выявить зависшие задачи:
 \begin{Verbatim}
@@ -5170,12 +5651,12 @@ systemctl list-jobs
 полностью, прежде всего нужно убедиться, способно ли ядро Linux выключить или
 перезагрузить систему. Для этого воспользуйтесь одной из команд:
 \begin{Verbatim}
-sync && reboot -f
+reboot -f
-sync && poweroff -f
+poweroff -f
 \end{Verbatim}
 
-Если хотя бы одна из этих команд не~сработает~--- значит, проблема не~в systemd,
+Если хотя бы одна из этих команд не~сработает~--- значит, проблема скорее всего 
-а в ядре.
+не~в systemd, а в ядре.
 
 \subsubsection{Система очень долго выключается}
 
@@ -5184,7 +5665,7 @@ sync && poweroff -f
 \begin{itemize}
 	\item Загрузите систему со следующими параметрами ядра:
 \begin{Verbatim}
-systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M enforcing=0
+systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on enforcing=0
 \end{Verbatim}
 	
 	\item Создайте файл +/usr/lib/systemd/system-shutdown/debug.sh+,
@@ -5263,15 +5744,14 @@ May 11 20:26:23 scratch foo[1329]: Failed to parse config
 
 Если вы собираетесь отправить сообщение об ошибке systemd, пожалуйста,
 включите в него диагностическую информацию, в частности, содержимое системных
-журналов. Журналы должны быть полными (без вырезок), не~заархивированными, с
+журналов. Журналы должны быть полными (без вырезок) и не~заархивированными.
-MIME-типом +text/plain+.
 
 Прежде всего, отправьте сообщение в багтрекер своего дистрибутива. Если же вы
 твердо уверены, что проблема именно в апстримном systemd, проверьте сначала
 список
-\href{https://bugs.freedesktop.org/buglist.cgi?query_format=advanced&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&product=systemd}{уже
+\href{https://github.com/systemd/systemd/issues/}{уже
 известных ошибок}. Если вы не~найдете в нем своего случая~---
-\href{https://bugs.freedesktop.org/enter_bug.cgi?product=systemd}{заводите новую
+\href{https://github.com/systemd/systemd/issues/new}{заводите новую
 запись}.
 
 \subsubsection{Что нужно включить в сообщение об ошибке}
@@ -5279,24 +5759,23 @@ MIME-типом +text/plain+.
 По возможности, пожалуйста, укажите в самом сообщении, либо присоедините к нему,
 следующую информацию:
 \begin{itemize}
-	\item Строку параметров ядра, если она отличается от значения по
+	\item Строку параметров ядра. Ее можно найти в файле конфигурации
-		умолчанию. Ее можно найти в файле конфигурации загрузчика
+		загрузчика (например, +/boot/grub2/grub.cfg+) или в специальном
-		(например, +/boot/grub2/grub.cfg+) или в специальном файле
+		файле +/proc/cmdline+.
-		+/proc/cmdline+.
+	\item Файл +journal.txt+, полученный после выполнения команды
-	\item Копию файла +/var/log/messages+.
-	\item Файл +dmesg.txt+, полученный после выполнения команды
 \begin{Verbatim}		
-dmesg > dmesg.txt
+journalctl -b > journal.txt
 \end{Verbatim}
-		Перед ее выполнением лучше загрузиться с параметрами ядра
+		Перед ее выполнением желательно загрузиться с параметрами ядра
 \begin{Verbatim}
-systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
+systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M printk.devkmsg=on
 \end{Verbatim}
 	\item Файл +systemd-dump.txt+, полученный в результате выполнения
-		команды\footnote{Прим. перев.: Начиная с systemd версии 207,
+		команды\footnote{Прим. перев.: В версиях systemd до 206
-		вместо +systemctl dump+ нужно вызывать +systemd-analyze dump+.} 
+		включительно, вместо +systemd-analyze dump+ нужно было
+		использовать +systemctl dump+.} 
 \begin{Verbatim}
-systemctl dump > systemd-dump.txt
+systemd-analyze dump > systemd-dump.txt
 \end{Verbatim}
 	\item Файл +systemd-test.txt+, полученный при помощи команды
 \begin{Verbatim}
@@ -5307,7 +5786,7 @@ systemctl dump > systemd-dump.txt
 \section{Совместимость с SysV\sfnote{Перевод статьи
 <<\href{http://www.freedesktop.org/wiki/Software/systemd/Incompatibilities}%
 {Compatibility with SysV}>> с официального сайта проекта, по
-состоянию на 2013-10-06 21:37:19 (коммит 4db1c).}}
+состоянию на 2016-06-21 15:06:36 (коммит 3b3b2).}}
 
 systemd обеспечивает высокий уровень совместимости с поведением классической
 системы инициализации SysV init, реализованной во многих дистрибутивах.  Это
@@ -5394,12 +5873,34 @@ API для скриптов. Тем не~менее, существует ряд
 		команд скрипту дополнительные параметры. Такое расширение SysV
 		не~прописано ни~в каких стандартах, и реализация его поддержки
 		была бы весьма проблематичной.
+	\item Переопределение команды +restart+ не~поддерживается. Она
+		реализована непосредственно в systemd как последовательное
+		выполнение команд +stop+ и +start+.
 	\item systemd останавливает только те службы, которые выполняются. 
 		Традиционный SysV init при завершении
 		работы системы запускает все скрипты, предписанные +K*+-ссылками
 		для текущего уровня исполнения. systemd в аналогичной ситуации 
 		действует более последовательно, и не~пытается остановить те
-		службы, которые не~были запущены.
+		службы, которые не~были запущены. 
+	\item Для уровней исполнения 0 и 6 все +S*+- и +K*+-ссылки игнорируются.
+		При завершении работы системы останавливаются все работающие
+		службы, и никаких новых SysV-служб не~запускается.
+	\item Если systemd не~знает PID главного процесса службы, он не~сможет
+		отслеживать ее работу. В частности, если этот процесс
+		<<самостоятельно>> (без сигнала от системного менеджера) завершит
+		работу, systemd не~будет знать о том, что служба остановилась.
+		Поэтому настоятельно рекомендуется указывать в init-скрипте 
+		предложенный Red Hat заголовок-комментарий +pidfile:+,
+		позволяющий systemd найти PID-файл вашей службы и получить из
+		него PID главного процесса. Из-за того, что в некоторых
+		init-скриптах запускаются дополнительные процессы, выполняющие
+		предварительную настройку для нужд службы, в общем случае
+		systemd не~должен рассматривать завершение процесса, запущенного
+		из init-скрипта, как завершение работы всей службы. Именно
+		поэтому для корректного отслеживания ее статуса systemd
+		требуется явное указание PID-файла. (Обратите внимание, что
+		заголовок +pidfile:+ можно указывать в init-скрипте не~более
+		одного раза.)
 	\item Поддержка уровней исполнения (runlevels) в systemd имеет некоторые
 		ограничения. Хотя все уровни исполнения SysV имеют
 		соответствующие им целевые состояния (target units), далеко
@@ -5433,17 +5934,44 @@ API для скриптов. Тем не~менее, существует ряд
 		+S+ в Debian и +b+ в openSUSE. Разумеется, это никак
 		не~затрагивает поддержку обычных уровней исполнения, которую мы
 		намерены сохранять еще очень долго.
-	\item По умолчанию, SysV-службы не~могут получить приоритет реального
+	\item В системах с SysV, изменение init-скриптов и любых других файлов,
-		времени, даже если располагают полными привилегиями. За
+		отвечающих за настройку процесса загрузки (например,
-		подробностями и методами решения обратитесь к
+		+/etc/fstab+), обычно вступают в силу немедленно. В то же время,
-		приложению~\ref{sec:realtime}.
+		в системах с systemd, init-скрипты и другие конфигурационные
+		файлы, влияющие на процесс загрузки, перечитываются только
+		после выполнения команды +systemctl daemon-reload+ (обратите
+		внимание, что некоторые команды, например, +systemctl enable+ и
+		+systemctl disable+, выполняют данную операцию
+		автоматически)\footnote{Прим. перев.: Стоит отметить, что на
+		самом деле все немного сложнее. В частности, даже в системе с
+		systemd изменения в исполняемом коде SysV init-скриптов должны
+		вступать в действие немедленно. В то же время, изменения в их
+		\emph{заголовках} (оформленных в виде комментариев и содержащих
+		служебную информацию, в частности, о зависимостях между
+		службами), а также сделанные <<вручную>> (командами +ln+ и +rm+)
+		изменения символьных ссылок в +/etc/rc?.d/+ действительно 
+		срабатывают только после +systemctl daemon-reload+. Это 
+		обусловлено тем, что симлинки и информация из заголовков
+		используются при генерации unit-файлов на основе
+		init-скриптов, которая осуществляется программой
+		\hreftt{https://www.freedesktop.org/software/systemd/man/systemd-sysv-generator.html}%
+		{systemd-sysv-generator(8)} в начале процесса загрузки, а 
+		также каждый раз после выполнения +systemctl daemon-reload+.
+		Аналогично и с +/etc/fstab+, на основе которого  
+		\hreftt{https://www.freedesktop.org/software/systemd/man/systemd-fstab-generator.html}%
+		{systemd-fstab-generator(8)} генерирует набор mount-юнитов.}.
+		Это сделано специально, для обеспечения консистентности вносимых
+		изменений, и позволяет избежать ситуации, когда считывание
+		происходит непосредственно в момент редактирования конфигурации
+		администратором\footnote{Прим. перев.: Пример подобной проблемы
+		рассмотрен примечании~\ref{ftn:cons}.}.
 \end{itemize}
 
 
 \section{Предсказуемые имена сетевых интерфейсов\sfnote{Перевод статьи
 <<\href{http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames}%
 {Predictable Network Interface Names}>> с официального сайта проекта, по
-состоянию на 2014-02-21 15:36:45 (коммит 5613f).}}
+состоянию на 2016-11-17 17:52:54 (коммит fe089).}}
 
 Начиная с версии 197, systemd/udev присваивает сетевым интерфейсам (Ethernet,
 WLAN, WWAN\footnote{Прим. перев.: WWAN (Wireless Wide Area Network)~---
@@ -5545,7 +6073,7 @@ systemd/udev\footnote{Прим. перев.: См. коммит
 \begin{itemize}
 	\item Имена интерфейсов остаются неизменными после перезагрузок.
 	\item Имена интерфейсов остаются неизменными при добавлении или
-		удалении устройств.
+		удалении устройств (если ваша прошивка это позволяет).
 	\item Имена интерфейсов остаются неизменными при обновлении/изменении
 		ядра и драйверов\footnote{Прим. перев.: На самом деле, не~все
 		так просто. Если, в результате обновлении ядра/драйверов, в них
@@ -5584,65 +6112,38 @@ systemd/udev\footnote{Прим. перев.: См. коммит
 \begin{enumerate}
 	\item Вы можете полностью отключить новую схему, вернувшись к
 		классическим непредсказуемым именам. Для этого достаточно
-		заблокировать (замаскировать) файл правил udev, отвечающий за
+		заблокировать (замаскировать) link-файл udev, отвечающий за
-		именование интерфейсов:
+		именование интерфейсов
 \begin{Verbatim}
-ln -s /dev/null /etc/udev/rules.d/80-net-setup-link.rules
+ln -s /dev/null /etc/systemd/network/99-default.link
 \end{Verbatim}
-		(Заметим, что в версиях systemd со 197 по 208 соответствующий
-		файл назывался +80-net-name-slot.rules+.)
 	\item Вы можете вручную назначить интерфейсам наиболее понятные для вас
-		имена (например, +internet0+, +dmz0+, +lan0+). Для этого,
+		имена (например, +internet0+, +dmz0+, +lan0+). Для этого
-		подготовьте свои собственные правила, указав в них нужные имена
+		создайте соответствующие link-файлы в каталоге
-		при помощи параметра +NAME+, после чего сохраните их в файл с
+		+/etc/systemd/network+ и укажите в них нужные вам имена (или
-		более высоким приоритетом, чем правила по умолчанию, например,
+		схемы именования) для одного, нескольких или сразу всех
-		+/etc/udev/rules.d/70-my-net-names.rules+\footnote{Прим. перев.:
+		интерфейсов\footnote{Прим. перев.: Там же можно изменить 
-		Начиная с systemd 209, существует более удобный способ настройки
+		используемую по умолчанию схему именования, скопировав файл 
-		имен и других параметров сетевых интерфейсов (MAC-адреса,
+		+/usr/lib/systemd/network/99-default.link+ и поменяв значение
-		скорости, дуплекса, MTU, состояния Wake on LAN)~--- он описан в
+		параметра
-		секции <<Network Link Configuration>> на странице руководства
+		\hreftt{https://www.freedesktop.org/software/systemd/man/systemd.link.html\#NamePolicy=}%
-		\href{http://www.freedesktop.org/software/systemd/man/udev.html#Network%20Link%20Configuration}{udev(7)}.}.
+		{NamePolicy=} на нужное значение.}. За
-		(Приоритет файлов определяется на основании алфавитной
+		подробностями вы можете обратиться к странице руководства
-		сортировки их имен.)
+		\hreftt{http://www.freedesktop.org/software/systemd/man/systemd.link.html}{systemd.link(5)}.
-	\item Вы можете скорректировать правила, используемые по умолчанию,
+	\item Вы можете указать параметр +net.ifnames=0+ в строке параметров
-		например, задействовав схему именования интерфейсов по
+		ядра (отключает использование предсказуемых имен для текущей
-		MAC-адресам. Для, этого скопируйте соответствующий
+		загрузки).
-		конфигурационный файл в каталог +/etc+
-\begin{Verbatim}
-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}%
+\href{https://github.com/systemd/systemd/blob/master/src/udev/udev-builtin-net_id.c#L20}%
 {исходном коде net\_id built-in}. Ознакомьтесь с ним, если у вас возникают
 вопросы, касающиеся расшифровки новых имен\footnote{Прим. перев.: Далее
 приводится перевод упомянутого блока комментариев. Последним коммитом,
-затронувшим данный файл, на момент перевода является 1cb5d от 11 августа
+затронувшим данный файл, на момент перевода является 8fb3f от 9 декабря
-2014 г.}.
+2016 г.}.
 
 \begin{Verbatim}
 Предсказуемые имена сетевых интерфейсов формируются на основании:
@@ -5651,6 +6152,8 @@ cp /usr/lib/systemd/network/99-default.link /etc/systemd/network/99-default.link
  - физического расположения точки подключения оборудования
  - MAC-адресов
 
+http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames
+
 Первые два символа в имени определяют тип интерфейса:
   en -- ethernet
   sl -- SLIP (IP через последовательный порт)
@@ -5658,13 +6161,16 @@ cp /usr/lib/systemd/network/99-default.link /etc/systemd/network/99-default.link
   ww -- WWAN
 
 Последующие символы определяеются используемой схемой:
-  b<number> -- для устройств, подключенных по шине BCMA
+  b<number> -- для устройств, подключенных по шине BCMA (<number> соответствует
-  ccw<number> -- для устройств, подключенных по шине CCW
+      BCMA bus core number)
-  o<index> -- для устройств, встроенных в материнскую плату
+  c<bus_id> -- для устройств, адресуемых по шине CCW, имя группы (CCW bus
-  s<slot>[f<function>][d<dev_port>] -- для hotplug-слотов
+      group name) <bus_id> указывается без ведущих нулей [s390]
+  o<index>[n<phys_port_name>|d<dev_port>] -- для устройств, встроенных 
+      в материнскую плату
+  s<slot>[f<function>][n<phys_port_name>|d<dev_port>] -- для hotplug-слотов
   x<MAC> -- при именовании по MAC-адресу
-  [P<domain>]p<bus>s<slot>[f<function>][d<dev_port>] -- на основании физического
+  [P<domain>]p<bus>s<slot>[f<function>][n<phys_port_name>|d<dev_port>]
-      расположения PCI-устройства
+      -- на основании физического расположения PCI-устройства
   [P<domain>]p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]
       -- идентификационная цепочка для USB-устройств
 
@@ -5719,14 +6225,14 @@ Multi-function PCI устройство с двумя портами:
 
 \section{Специальные файловые системы\sfnote{Перевод статьи
 <<\href{http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems}{API
-File Systems}>> с официального сайта проекта, по состоянию на 2013-05-26
+File Systems}>> с официального сайта проекта, по состоянию на 2015-02-20
-08:37:25 (коммит 6a93f).}}
+15:48:02 (коммит e2db9).}}
 \label{sec:apifs}
 
 \yousaywtfsk{Итак, вы запустили программу mount(8), и увидели в ее выводе
 множество странных файловых систем, не~указанных в /etc/fstab. У вас могут
-возникнуть вопросы: <<Как их убрать?>> или <<Как задать для них параметры
+возникнуть вопросы: <<Как от них избавиться?>> или <<Как задать для них
-монтирования?>>.}
+параметры монтирования?>>.}
 
 В Linux предусмотрено несколько способов взаимодействия программ из пространства
 пользователя с ядром. Наиболее популярными механизмами являются системные вызовы
@@ -5830,7 +6336,7 @@ systemctl mask tmp.mount
 \section{Запуск служб после появления сети\sfnote{Перевод статьи
 <<\href{http://www.freedesktop.org/wiki/Software/systemd/NetworkTarget}{Running
 Services After the Network is up}>> с официального сайта проекта, по состоянию
-на 2014-06-11 13:22:03 (коммит 0ff8f).}}
+на 2016-08-21 13:14:53 (коммит 4d5d5).}}
 \label{sec:networktarget}
 
 \yousaywtfsk{Итак, ваша служба настроена на запуск только после достижения цели