Version v15.10 (2014-09-12 23:23) [AUTO]

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}
@@ -641,8 +642,8 @@ service-файл будет работать в любом дистрибути
 вам отправить этот файл разработчикам. Вопросы по полноценной интеграции
 демонов с systemd, с максимальным использованием всех его возможностей, будут
 рассмотрены в последующих статьях этого цикла, пока же ограничимся ссылкой на 
-\href{http://0pointer.de/public/systemd-man/daemon.html}{страницу} официальной
+\href{http://www.freedesktop.org/software/systemd/man/daemon.html}{страницу}
-документации. 
+официальной документации. 
 
 Итак, приступим. В качестве примера возьмем init-скрипт демона ABRT (Automatic
 Bug Reporting Tool, службы, занимающейся сбором crash dump'ов). Исходный
@@ -751,9 +752,9 @@ WantedBy=multi-user.target
 лога, независимо от используемой программы (например, rsyslog или syslog-ng)
 и типа активации (как обычной службы или через log-сокет). Подробнее о таких
 специальных юнитах можно почитать
-\href{http://0pointer.de/public/systemd-man/systemd.special.html}{страницу}
+\href{http://www.freedesktop.org/software/systemd/man/systemd.special.html}%
-официальной документации. Обратите внимание, что директива +After+, в
+{страницу} официальной документации. Обратите внимание, что директива +After+,
-отсутствие директивы +Requires+, задает лишь порядок загрузки, но
+в отсутствие директивы +Requires+, задает лишь порядок загрузки, но
 не~задает жесткой зависимости. То есть, если при загрузке конфигурация
 systemd будет предписывать запуск как демона системного лога, так и abrtd, то
 сначала будет запущен демон системного лога, и только потом abrtd. Если же
@@ -874,11 +875,11 @@ systemd располагает удобным методом для опреде
 
 За более подробным описанием всех опций настройки, вы можете обратиться к
 страницам руководства
-\href{http://0pointer.de/public/systemd-man/systemd.unit.html}{systemd.unit},
+\href{http://www.freedesktop.org/software/systemd/man/systemd.unit.html}{systemd.unit},
-\href{http://0pointer.de/public/systemd-man/systemd.service.html}{systemd.service},
+\href{http://www.freedesktop.org/software/systemd/man/systemd.service.html}{systemd.service},
-\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec}. Полный
+\href{http://www.freedesktop.org/software/systemd/man/systemd.exec.html}{systemd.exec}.
-список доступных страниц можно просмотреть
+Полный список доступных страниц можно просмотреть
-\href{http://0pointer.de/public/systemd-man/}{здесь}.
+\href{http://www.freedesktop.org/software/systemd/man/}{здесь}.
 
 Конечно, отнюдь не~все init-скрипты так же легко преобразовать в
 service-файлы. Но, к счастью, <<проблемных>> скриптов не~так уж и много. 
@@ -940,7 +941,10 @@ Apache, crond, atd, которые по роду служебной деятел
 лишь возможности исчерпания памяти и идентификаторов процессов (PID). Впрочем, и
 их тоже можно легко устранить: достаточно задать соответствующие лимиты в
 конфигурационном файле службы (см.
-\href{http://www.0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}).}.
+\href{http://www.freedesktop.org/software/systemd/man/systemd.exec.html}%
+{systemd.exec(5)} и
+\href{http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html}%
+{systemd.resource-control(5)}).}.
 
 В некоторых случаях возникает необходимость отправить сигнал именно основному
 процессу службы. Например, используя +SIGHUP+, мы можем заставить демона
@@ -1241,8 +1245,8 @@ RootDirectoryStartOnly=yes
 доступ к иерархии файловых систем ОС (иначе наш скрипт просто не~сможет
 выполнить bind-монтирование нужных каталогов). Более подробную информацию по
 опциям конфигурации вы можете получить на
-\href{http://0pointer.de/public/systemd-man/systemd.service.html}{страницах}
+\href{http://www.freedesktop.org/software/systemd/man/systemd.service.html}{страницах}
-\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{руководства}.
+\href{http://www.freedesktop.org/software/systemd/man/systemd.exec.html}{руководства}.
 
 Поместив приведенный выше текст примера в файл
 +/etc/systemd/system/foobar.service+, вы сможете запустить chroot'нутого демона
@@ -1276,8 +1280,8 @@ InaccessibleDirectories=/home
 единственным исключением~--- она не~будет видеть каталог +/home+, что позволит
 защитить данные пользователей от потенциальных хакеров. (Подробнее об этих
 опциях можно почитать на
-\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{странице
+\href{http://www.freedesktop.org/software/systemd/man/systemd.exec.html}%
-руководства}.)
+{странице руководства}.)
 
 Фактически, FSNS по множеству параметров превосходят +chroot()+. Скорее всего,
 Avahi и RealtimeKit в ближайшем будущем перейдут от +chroot()+ к использованию
@@ -1327,7 +1331,7 @@ debootstrap/febootstrap. В этом случае возможности +system
 взаимодействия с процессом init.}.
 
 Однако, куда более интересные возможности предоставляет программа
-\href{http://0pointer.de/public/systemd-man/systemd-nspawn.html}{systemd-nspawn},
+\href{http://www.freedesktop.org/software/systemd/man/systemd-nspawn.html}{systemd-nspawn},
 входящая в стандартный комплект поставки systemd. По сути, это улучшенный аналог
 +chroot(1)+~--- она не~только подменяет корневой каталог, но и создает отдельные
 пространства имен для дерева файловых систем (FSNS) и для идентификаторов
@@ -1635,7 +1639,12 @@ $ eog plot.svg
 
 Она создает наглядные диаграммы, показывающие моменты запуска служб и время,
 затраченное на их запуск, по отношению к другим службам. На текущий момент, она
-не~показывает явно, кто кого ожидает, но догадаться обычно несложно.
+не~показывает явно, кто кого ожидает, но догадаться обычно
+несложно\footnote{Прим. перев.: Начиная с systemd 203, добавлена поддержка
+специальной команды +systemd-analyze critical-chain+, которая выводит самую
+медленную цепочку юнитов (цепь в графе зависимостей, формируемом при
+загрузке). Время запуска всех юнитов в этой цепочке определяет итоговое время 
+загрузки системы.}.
 
 Чтобы продемонстрировать эффект, порожденный двумя нашими оптимизациями,
 приведем ссылки на соответствующие графики:
@@ -1755,20 +1764,24 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
 всех дистрибутивах:
 \begin{itemize}
 	\item
-		\hreftt{http://0pointer.de/public/systemd-man/hostname.html}{/etc/hostname}:
+		\hreftt{http://www.freedesktop.org/software/systemd/man/hostname.html}%
+		{/etc/hostname}:
 		имя хоста для данной системы. Одна из наиболее простых и важных
 		системных настроек. В разных дистрибутивах оно настраивалось
 		по-разному: Fedora использовала +/etc/sysconfig/network+,
 		OpenSUSE~--- +/etc/HOSTNAME+, Debian~--- +/etc/hostname+. Мы
 		остановились на варианте, предложенном Debian.
 	\item
-		\hreftt{http://0pointer.de/public/systemd-man/vconsole.conf.html}{/etc/vconsole.conf}:
+		\hreftt{http://www.freedesktop.org/software/systemd/man/vconsole.conf.html}%
+		{/etc/vconsole.conf}:
 		конфигурация раскладки клавиатуры и шрифта для консоли.
 	\item
-		\hreftt{http://0pointer.de/public/systemd-man/locale.conf.html}{/etc/locale.conf}:
+		\hreftt{http://www.freedesktop.org/software/systemd/man/locale.conf.html}%
+		{/etc/locale.conf}:
 		конфигурация общесистемной локали.
 	\item
-		\hreftt{http://0pointer.de/public/systemd-man/modules-load.d.html}{/etc/modules-load.d/*.conf}:
+		\hreftt{http://www.freedesktop.org/software/systemd/man/modules-load.d.html}%
+		{/etc/modules-load.d/*.conf}:
 		каталог\footnote{Прим. перев.: Для описания этого и трех
 		последующих каталогов автор пользуется термином <<drop-in
 		directory>>. Данный термин означает каталог, в который можно
@@ -1785,21 +1798,25 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
 		ядра, которые нужно принудительно подгрузить при загрузке
 		(впрочем, необходимость в этом возникает достаточно редко).
 	\item
-		\hreftt{http://0pointer.de/public/systemd-man/sysctl.d.html}{/etc/sysctl.d/*.conf}:
+		\hreftt{http://www.freedesktop.org/software/systemd/man/sysctl.d.html}%
+		{/etc/sysctl.d/*.conf}:
 		каталог для задания параметров ядра (+sysctl+). Дополняет
 		классический конфигурационный файл +/etc/sysctl.conf+.
 	\item
-		\hreftt{http://0pointer.de/public/systemd-man/tmpfiles.d.html}{/etc/tmpfiles.d/*.conf}:
+		\hreftt{http://www.freedesktop.org/software/systemd/man/tmpfiles.d.html}%
+		{/etc/tmpfiles.d/*.conf}:
 		каталог для управления настройками временных файлов (systemd
 		обеспечивает создание, очистку и удаление временных файлов и
 		каталогов, как во время загрузки, так и во время работы
 		системы).
 	\item
-		\hreftt{http://0pointer.de/public/systemd-man/binfmt.d.html}{/etc/binfmt.d/*.conf}:
+		\hreftt{http://www.freedesktop.org/software/systemd/man/binfmt.d.html}%
+		{/etc/binfmt.d/*.conf}:
 		каталог для регистрации дополнительных бинарных форматов
 		(например, форматов Java, Mono, WINE).
 	\item
-		\hreftt{http://0pointer.de/public/systemd-man/os-release.html}{/etc/os-release}:
+		\hreftt{http://www.freedesktop.org/software/systemd/man/os-release.html}%
+		{/etc/os-release}:
 		стандарт для файла, обеспечивающего идентификацию дистрибутива и
 		его версии. Сейчас различные дистрибутивы используют для этого
 		разные файлы (например, +/etc/fedora-release+ в Fedora), и
@@ -1813,7 +1830,8 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
 		сложившуюся ситуацию, мы решили перейти к единому простому
 		формату представления этой информации.
 	\item
-		\hreftt{http://0pointer.de/public/systemd-man/machine-id.html}{/etc/machine-id}:
+		\hreftt{http://www.freedesktop.org/software/systemd/man/machine-id.html}%
+		{/etc/machine-id}:
 		файл с идентификатором данного компьютера (перекрывает
 		аналогичный идентификатор D-Bus). Гарантируется, что в любой
 		системе, использующей systemd, этот файл будет существовать и
@@ -1822,7 +1840,8 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
 		D-Bus, чтобы упростить решение множества задач, требующих
 		наличия уникального и постоянного идентификатора компьютера.
 	\item
-		\hreftt{http://0pointer.de/public/systemd-man/machine-info.html}{/etc/machine-info}:
+		\hreftt{http://www.freedesktop.org/software/systemd/man/machine-info.html}%
+		{/etc/machine-info}:
 		новый конфигурационный файл, хранящий информации о полном 
 		(описательном) имени хоста (например, <<Компьютер Леннарта>>) и
 		значке, которым он будет обозначаться в графических оболочках,
@@ -2094,8 +2113,9 @@ systemd?
 		быть подгружен автоматически, все равно существует гораздо более
 		удобные методы указать его принудительную подгрузку~---
 		например, путем создания соответствующего файла в каталоге
-		\hreftt{http://0pointer.de/public/systemd-man/modules-load.d.html}{/etc/modules-load.d/}
+		\hreftt{http://www.freedesktop.org/software/systemd/man/modules-load.d.html}%
-		(стандартный метод настройки принудительной подгрузки модулей).
+		{/etc/modules-load.d/} (стандартный метод настройки
+		принудительной подгрузки модулей).
 	\item И наконец, хотелось бы отметить, что каталог +/etc+ определен как
 		место для хранения системных настроек (<<Host-specific system
 		configuration>>, согласно FHS). Наличие внутри него подкаталога
@@ -2115,9 +2135,10 @@ systemd?
 		штатно поддерживаются systemd, нет никакого смысла дублировать
 		их где-то еще (перечень опций, которые можно задать для любой
 		службы, приведен на страницах справки
-		\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}
+		\href{http://www.freedesktop.org/software/systemd/man/systemd.exec.html}%
-		и
+		{systemd.exec(5)} и
-		\href{http://0pointer.de/public/systemd-man/systemd.service.html}{systemd.service(5)}.)
+		\href{http://www.freedesktop.org/software/systemd/man/systemd.service.html}%
+		{systemd.service(5)}.)
 		Если же ваша настройка просто добавляет еще один уровень
 		отключения запуска службы~--- не~плодите лишние сущности,
 		откажитесь от нее.
@@ -2140,7 +2161,7 @@ systemd?
 штатные unit-файлы systemd. Если ваш файл из +sysconfig+ содержит лишь
 определения переменных, можно воспользоваться опцией
 +EnvironmentFile=-/etc/sysconfig/foobar+ (подробнее об этой опции см.
-\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}),
+\href{http://www.freedesktop.org/software/systemd/man/systemd.exec.html}{systemd.exec(5)}),
 позволяющей прочитать из файла набор переменных окружения, который будет
 установлен при запуске службы. Если же для задания настроек вам необходим
 полноценный язык программирования~--- ничто не~мешает им воспользоваться.
@@ -2179,16 +2200,18 @@ systemd?
 +/lib/systemd/system+ (а также, возможно, и в других\footnote{Прим. перев.:
 Перечень каталогов, в которых выполняется поиск общесистемных юнит-файлов,
 приведен на странице руководства 
-\href{http://www.0pointer.de/public/systemd-man/systemd.html}{systemd(1)}
+\href{http://www.freedesktop.org/software/systemd/man/systemd.html}{systemd(1)}
 (раздел <<System unit directories>>). Указанные выше каталоги
 +/etc/systemd/systemd+ и +/lib/systemd/system+ соответствуют значениям по
 умолчанию для упомянутых там переменных pkg-config +systemdsystemconfdir+ и
-+systemdsystemunitdir+ соответственно.}). Для служб, работающих в нескольких
++systemdsystemunitdir+ соответственно. Начиная с systemd версии 198, данный
-экземплярах, эта схема становится немного сложнее:
+перечень, в более точной и развернутой форме, присутствует на странице
-\emph{foobar}+@+\emph{quux}+.service+, где \emph{foobar}~--- имя службы, общее
+\href{http://www.freedesktop.org/software/systemd/man/systemd.unit.html}%
-для всех экземпляров, а \emph{quux}~--- идентификатор конкретного экземпляра.
+{systemd.unit(5)}.}). Для служб, работающих в нескольких экземплярах, эта схема
-Например, +serial-gett@ttyS2.service+~--- это служба getty для COM-порта,
+становится немного сложнее: \emph{foobar}+@+\emph{quux}+.service+, где
-запущенная на +ttyS2+.
+\emph{foobar}~--- имя службы, общее для всех экземпляров, а \emph{quux}~---
+идентификатор конкретного экземпляра.  Например, +serial-gett@ttyS2.service+~---
+это служба getty для COM-порта, запущенная на +ttyS2+.
 
 При необходимости, экземпляры служб можно легко создать динамически. Скажем, вы
 можете, безо всяких дополнительных настроек, запустить новый экземпляр getty на
@@ -2324,9 +2347,9 @@ serial-getty@serial-by\x2dpath-pci\x2d0000:00:1d.0\x2dusb\x2d0:1.4:1.1\x2dport0.
 (Небольшое замечание: помимо +%i+ и +%I+, существует еще несколько
 спецификаторов, и большинство из них доступно и в обычных файлах конфигурации
 юнитов, а не~только в шаблонах. Подробности можно посмотреть на
-\href{http://0pointer.de/public/systemd-man/systemd.unit.html}{странице
+\href{http://www.freedesktop.org/software/systemd/man/systemd.unit.html}%
-руководства}, содержащей полный перечень этих спецификаторов с краткими
+{странице руководства}, содержащей полный перечень этих спецификаторов с
-пояснениями.)
+краткими пояснениями.)
 
 \section{Службы с активацией в стиле inetd}
 \label{sec:inetd}
@@ -2369,7 +2392,8 @@ systemd прежде всего ориентирована на локальны
 быть использован службами для обеспечения сокет-активации. В основе этого
 \href{http://0pointer.de/blog/projects/socket-activation.html}{простого и
 минималистичного} механизма лежит функция
-\hreftt{http://0pointer.de/public/systemd-man/sd_listen_fds.html}{sd\_listen\_fds()}.
+\hreftt{http://www.freedesktop.org/software/systemd/man/sd_listen_fds.html}%
+{sd\_listen\_fds()}.
 Однако, интерфейс, традиционно используемый в inetd, еще проще. Он позволяет
 передавать запускаемой службе только один сокет, который формируется из потоков
 STDIN и STDOUT запущенного процесса. Поддержка этого механизма также
@@ -2506,17 +2530,17 @@ StandardInput=socket
 собственно, и включает для данной службы режим совместимости с inetd-активацией.
 Опция +StandardInput=+ позволяет указать, куда будет подключен поток STDIN
 процесса данной службы (подробности см.
-\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{на странице
+\href{http://www.freedesktop.org/software/systemd/man/systemd.exec.html}%
-руководства}). Задав для нее значение +socket+, мы обеспечиваем подключение
+{на странице руководства}). Задав для нее значение +socket+, мы обеспечиваем
-этого потока к сокету соединения, как того и требует механизм inetd-активации.
+подключение этого потока к сокету соединения, как того и требует механизм
-Заметим, что явно указывать опцию +StandardOutput=+ в данном случае
+inetd-активации. Заметим, что явно указывать опцию +StandardOutput=+ в данном
-необязательно~--- она автоматически устанавливается в то же значение, что и
+случае необязательно~--- она автоматически устанавливается в то же значение, что
-+StandardInput+, если явно не~указано что-то другое. Кроме того, можно отметить
+и +StandardInput+, если явно не~указано что-то другое. Кроме того, можно
-наличие <<+-+>> перед именем бинарного файла sshd. Таким образом мы указываем
+отметить наличие <<+-+>> перед именем бинарного файла sshd. Таким образом мы
-systemd игнорировать код выхода процесса sshd. По умолчанию, systemd сохраняет
+указываем systemd игнорировать код выхода процесса sshd. По умолчанию, systemd
-коды выхода для всех экземпляров службы, завершившихся с ошибкой (сбросить эту
+сохраняет коды выхода для всех экземпляров службы, завершившихся с ошибкой
-информацию можно командой +systemctl reset-failed+). SSH
+(сбросить эту информацию можно командой +systemctl reset-failed+). SSH довольно
-довольно часто завершается с ненулевым кодом выхода, и мы разрешаем systemd
+часто завершается с ненулевым кодом выхода, и мы разрешаем systemd
 не~регистрировать подобные <<ошибки>>.
 
 Служба +sshd@.service+ предназначена для работы в виде независимых экземпляров
@@ -2616,15 +2640,15 @@ Linux подсистема ipset гораздо лучше подходит дл
 стороны, systemd тоже предоставляет ряд возможностей, отсутствующих в xinetd, в
 частности, индивидуальный контроль над каждым экземпляром службы (см.  выше), и
 внушительный
-\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{набор настроек}
+\href{http://www.freedesktop.org/software/systemd/man/systemd.exec.html}{набор
-для контроля окружения, в котором запускаются экземпляры. Я надеюсь, что
+настроек} для контроля окружения, в котором запускаются экземпляры. Я надеюсь,
-возможностей systemd должно быть достаточно для решения большинства задач, а в
+что возможностей systemd должно быть достаточно для решения большинства задач, а
-тех редких случаях, когда вам потребуются специфические опции xinetd~--- ничто
+в тех редких случаях, когда вам потребуются специфические опции xinetd~--- ничто
 не~мешает вам запустить его в дополнение к systemd. Таким образом, уже сейчас в
 большинстве случаев xinetd можно выкинуть из числа обязательных системных
 компонентов. Можно сказать, что systemd не~просто возвращает функциональность
-классического юниксового inetd, но еще и восстанавливает ее ключевую
+классического юниксового inetd, но еще и восстанавливает ее ключевую роль в
-роль в Linux-системах.
+Linux-системах.
 
 Теперь, вооруженные этими знаниями, вы можете портировать свои службы с inetd на
 systemd. Но, конечно, будет лучше, если этим займутся разработчики из апстрима
@@ -2675,11 +2699,14 @@ systemd 187.}:
 \end{itemize}
 
 Все эти опции описаны в man-страницах systemd, главным образом, в
-\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}%
+\href{http://www.freedesktop.org/software/systemd/man/systemd.exec.html}{systemd.exec(5)}%
 \footnote{Прим. перев.: Начиная с systemd версии 206, значительная часть
-обсуждаемых здесь настроек вынесена в отдельную страницу
+обсуждаемых здесь настроек вынесена на отдельную страницу
-\href{http://0pointer.de/public/systemd-man/systemd.cgroup.html}{systemd.cgroup(5)}%
+\href{http://www.freedesktop.org/software/systemd/man/systemd.cgroup.html}%
-.}. Если вам потребуется дополнительная информация, вы можете обратиться к ним.
+{systemd.cgroup(5)}. Начиная с systemd 208, эта страница переименована в
+\href{http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html}%
+{systemd.resource-control(5)}.}. Если вам потребуется дополнительная информация,
+вы можете обратиться к ним.
 
 Все эти опции доступны на системах с systemd, вне зависимости от использования
 SELinux или любой другой реализации MAC.
@@ -2771,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
@@ -3270,7 +3304,7 @@ URI, ссылающиеся на документацию, формируютс
 отмонтирует файловые системы и выполняет принудительную перезагрузку (в
 результате, перезагрузка происходит быстрее, чем обычно, но файловые системы
 остаются неповрежденными). И наконец, +reboot-immediate+ даже не~пытается отдать
-дань вежливости (убить процессы и отмонтировать файловый системы)~--- оно
+дань вежливости (убить процессы и отмонтировать файловые системы)~--- оно
 немедленно выполняет жесткую перезагрузку системы (это поведение практически
 аналогично срабатыванию аппаратного сторожевого таймера). Все перечисленный
 настройки подробно описаны на странице руководства
@@ -3501,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), так как
+systemd (до 209 включительно), так как в файле +serial-getty@.service+
-разработчики забыли включить в файл +serial-getty@.service+ секцию +[Install]+,
+отсутствовала секция +[Install]+, в результате чего попытка выполнения
-в результате чего попытка выполнения +systemctl enable+ для экземпляра
++systemctl enable+ для экземпляра соответствующей службы приводила к
-соответствующей службы ведет к закономерной ошибке. Впрочем, исправить это
+закономерной ошибке. Данная проблема была устранена только в systemd 210. 
-несложно: достаточно скопировать данный файл в +/etc/systemd/system/+, после
+В~случае использования более старых версий, исправить ее можно и самостоятельно:
-чего дописать в него секцию +[Install]+ с параметром +WantedBy=getty.target+, а
+достаточно скопировать указанный файл из +/usr/lib/systemd/system/+ в
-затем выполнить +systemctl daemon-reload+.}:
++/etc/systemd/system/+, после чего дописать в него секцию +[Install]+,
+содержащую параметр +WantedBy=getty.target+, и затем выполнить 
++systemctl daemon-reload+.}:
 \begin{Verbatim}
 # systemctl enable serial-getty@ttyS2.service
 # systemctl start serial-getty@ttyS2.service
@@ -3550,8 +3586,9 @@ daemon-reload}.}\footnote{\label{ftn:enableserial}Прим. перев.: На с
 а также сообщения, которые процессы служб выводят на STDOUT и STDERR. Полученная
 информация индексируется и предоставляется пользователю по запросу. Journal
 может работать одновременно с традиционными демоном syslog (например, rsyslog
-или syslog-ng), либо полностью его заменять. Более подробно см. в
+или syslog-ng), либо полностью его заменять. За подробностями стоит 
-\href{http://0pointer.de/blog/projects/the-journal.html}{первом анонсе}.
+обратиться к \href{http://0pointer.de/blog/projects/the-journal.html}{первому
+анонсу}.
 
 Journal был включен в Fedora начиная с F17. В Fedora~18 journal вырос в мощный и
 удобный механизм работы с системным журналом. Однако, и в~F17, и в~F18 journal
@@ -3966,16 +4003,16 @@ systemd предоставляет ряд высокоуровневых нас
 несколькими рабочими процессами получит такую же долю процессорного времени,
 как и Apache, даже если тот запустил 1000 CGI-процессов. Разумеется, такое
 поведение при необходимости можно легко отключить~--- см. опцию
-\hreftt{http://0pointer.de/public/systemd-man/systemd.conf.html}{DefaultControllers=}
+\hreftt{http://www.freedesktop.org/software/systemd/man/systemd-system.conf.html}%
-в файле +/etc/systemd/system.conf+.
+{DefaultControllers=} в файле +/etc/systemd/system.conf+.
 
 Если \emph{равномерное} распределение процессорного времени между службами вас
 не~устраивает, и вы хотите выделить определенным службам больше или меньше
 времени~--- используйте опцию
-\hreftt{http://0pointer.de/public/systemd-man/systemd.exec.html}{CPUShares=} в
+\hreftt{http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html}%
-конфигурационном файле службы. По умолчанию это значение равно 1024. Увеличивая
+{CPUShares=} в конфигурационном файле службы. По умолчанию это значение равно
-это число, вы даете службе больше процессорного времени, уменьшая~---
+1024. Увеличивая это число, вы даете службе больше процессорного времени,
-соответственно, меньше.
+уменьшая~--- соответственно, меньше.
 
 Рассмотрим небольшой практический пример. Допустим, вам нужно увеличить
 для службы Apache относительную долю потребления процессора до 1500. Для этого
@@ -4061,8 +4098,12 @@ systemd создавать соответствующие группы, доба
 Второй из этих пределов превышать нельзя, независимо от наличия свободной
 памяти. Подробнее см. раздел <<Soft limits>> в
 \href{http://www.kernel.org/doc/Documentation/cgroups/memory.txt}{файле
-документации}.}. При этом поддерживаются суффиксы K, M, G и T, обозначающие
+документации}. Отметим, что из-за планируемого прекращения поддержки параметра
-соответственно, килобайт, мегабайт, гигабайт и терабайт (по основанию 1024).
++memory.soft_limit_in_bytes+ на уровне ядра, опция +MemorySoftLimit=+ была
+\href{http://cgit.freedesktop.org/systemd/systemd/commit/?id=ddca82aca08712a302cfabdbe59f73ee9ed3f73a}%
+{удалена} из systemd, начиная с версии 208.}. При этом поддерживаются суффиксы
+K, M, G и T, обозначающие соответственно, килобайт, мегабайт, гигабайт и
+терабайт (по основанию 1024).
 \begin{Verbatim}
 .include /usr/lib/systemd/system/httpd.service
 
@@ -4150,7 +4191,16 @@ BlockIOReadBandwith=/var/log 5M
 присутствовал в systemd до 204 версии включительно. Начиная с версии 205, он был
 удален по требованию разработчиков cgroups. Также были удалены возможности
 напрямую задавать для юнита контрольную группу (+ControlGroup=+) и устанавливать
-права доступа для управления группами (+ControlGroupModify=+).}. Рассмотрим,
+права доступа для управления группами (+ControlGroupModify=+). Взамен,
+разработчики systemd планируют значительно расширить поддержку высокоуровневых
+настроек для параметров cgroups~--- сразу после того, как разработчики
+cgroups определятся, какие именно параметры они будут поддерживать. Наличие
+некоторого хаоса в этой области обусловлено происходящей сейчас полной
+переработкой реализации контрольных групп на уровне ядра и механизмов работы с
+ними из пространства пользователя.  Техническая сторона данного вопроса раскрыта
+в статье
+\href{http://www.freedesktop.org/wiki/Software/systemd/ControlGroupInterface}%
+{The New Control Group Interfaces} (пока не~переведена).}.  Рассмотрим,
 например, задание для службы параметра \emph{swappiness} (относительная
 интенсивность использования подкачки для процессов службы). В systemd нет
 высокоуровневой настройки для этого значения.  Однако вы можете задать его,
@@ -4182,8 +4232,8 @@ ControlGroupAttribute=memory.swappiness 70
 
 Для углубленного изучения темы, затронутой в этой статье, вы можете обратиться к
 документации по
-\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{поддерживаемым
+\href{http://www.freedesktop.org/software/systemd/man/systemd.resource-control.html}%
-настройкам юнитов}, а также по контроллерам 
+{поддерживаемым настройкам юнитов}, а также по контроллерам 
 \href{http://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt}{cpu},
 \href{http://www.kernel.org/doc/Documentation/cgroups/memory.txt}{memory} и
 \href{http://www.kernel.org/doc/Documentation/cgroups/blkio-controller.txt}{blkio}.
@@ -4377,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]{экземплярами служб} позволяет  подготовить
 универсальные шаблоны конфигурации служб, и в соответствии с ними для каждого
 сайта будет запускаться свой экземпляр службы. Кроме того, не~стоит забывать,
@@ -4506,14 +4560,22 @@ ListenStream=23
 слушать 23-й TCP-порт хоста. В примере выбран именной 23-й, потому что 22-й
 скорее всего окажется занят SSH-сервером самого хоста. nspawn виртуализует
 списки процессов и точек монтирования, но не~сетевые стеки, поэтому порты хоста
-и гостей не~должны конфликтовать\footnote{Прим. перев.: Ограниченные возможности
+и гостей не~должны конфликтовать\footnote{Прим. перев.: До выхода 209 версии
-виртуализации сети в +systemd-nspawn+ значительно затрудняют использование
+systemd, возможности по виртуализации сети в +systemd-nspawn+ были весьма
-описываемой технологии. Ее практическое применение будет иметь смысл 
+ограниченными (поддерживалась только полная изоляция сети от хоста), что весьма
-либо в lxc-libvirt, либо после расширения возможностей nspawn. Впрочем, опытные
+затрудняло использование описываемой технологии. Впрочем, опытные администраторы
-администраторы легко могут найти обходные пути, например: присваивание хосту
+легко могли найти обходные пути, например: присваивание хосту дополнительного
-дополнительного IP-адреса (безо всякой виртуализации, командой +ip addr add+) и
+IP-адреса (безо всякой виртуализации, командой +ip addr add+) и привязка
-привязка слушающих сокетов к конкретным адресам (в параметре +ListenStream=+
+слушающих сокетов к конкретным адресам (в параметре +ListenStream=+ сокет-файлов
-сокет-файлов и/или в директиве +ListenAddress+ файла +sshd_config+ хоста).}. 
+и/или в директиве +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 хоста. Если вы попробуете подключиться к
@@ -4737,9 +4799,8 @@ systemd 198, необязательно копировать файл целик
 Чтобы обеспечить автоматически запуск getty на этом порту при каждой загрузке,
 нужно поместить соответствующую символьную ссылку в каталог
 +getty.target.wants/+\footnote{Прим. перев.: Приведенная в оригинале команда
-+systemctl enable serial-getty@ttyS2.service+ работать не~будет (по крайней
++systemctl enable serial-getty@ttyS2.service+ в systemd версии 209 и ниже 
-мере, в версиях до 206 включительно). Подробнее 
+работать не~будет. Подробнее см.~примечание~\ref{ftn:enableserial}.}:
-см.~примечание~\ref{ftn:enableserial}.}:
 \begin{Verbatim}
 # ln -s /usr/lib/systemd/system/serial-getty@.service \
 > /etc/systemd/system/getty.target.wants/serial-getty@ttyS2.service
@@ -4914,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
+systemd Problems}>> с официального сайта проекта, по состоянию на 2013-12-20
-08:34:30 (коммит 10ae3).}}
+10:44:01 (коммит abb5a).}}
 
 \subsection{Диагностика проблем с загрузкой}
 
@@ -5047,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+
@@ -5126,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 /
@@ -5232,7 +5293,8 @@ dmesg > dmesg.txt
 systemd.log_level=debug systemd.log_target=kmsg log_buf_len=1M
 \end{Verbatim}
 	\item Файл +systemd-dump.txt+, полученный в результате выполнения
-		команды 
+		команды\footnote{Прим. перев.: Начиная с systemd версии 207,
+		вместо +systemctl dump+ нужно вызывать +systemd-analyze dump+.} 
 \begin{Verbatim}
 systemctl dump > systemd-dump.txt
 \end{Verbatim}
@@ -5245,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, реализованной во многих дистрибутивах.  Это
@@ -5381,7 +5443,7 @@ API для скриптов. Тем не~менее, существует ряд
 \section{Предсказуемые имена сетевых интерфейсов\sfnote{Перевод статьи
 <<\href{http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames}%
 {Predictable Network Interface Names}>> с официального сайта проекта, по
-состоянию на 2013-05-22 08:55:30 (коммит dc0a2).}}
+состоянию на 2014-02-21 15:36:45 (коммит 5613f).}}
 
 Начиная с версии 197, systemd/udev присваивает сетевым интерфейсам (Ethernet,
 WLAN, WWAN\footnote{Прим. перев.: WWAN (Wireless Wide Area Network)~---
@@ -5522,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 июля
+затронувшим данный файл, на момент перевода является 1cb5d от 11 августа
-2013 г.}.
+2014 г.}.
 
 \begin{Verbatim}
 Предсказуемые имена сетевых интерфейсов формируются на основании:
@@ -5566,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
+  sl -- SLIP (IP через последовательный порт)
-  ww -- wwan
+  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-устройств
@@ -5611,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
@@ -5740,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{Итак, ваша служба настроена на запуск только после достижения цели
@@ -5748,12 +5838,15 @@ network.target, однако, несмотря на это, она все рав
 сети. У вас возникают вопросы: <<Почему так происходит?>> и <<Как это
 исправить?>>.}
 
-Цель +network.target+ является systemd-шным аналогом LSB-сущности (facility)
+В некоторых LSB-совместимых скриптах инициализации, при описания зависимостей 
-\verb+$network+. Определение этой сущности в стандарте
+используется сущность (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 Все имеющиеся физические сетевые интерфейсы, на которых
@@ -5796,15 +5889,15 @@ network.target, однако, несмотря на это, она все рав
 такое реагирование в коде демона, на самом деле, не~так уж и сложно. Существует
 множество хорошо известных сетевых служб, которые уже давно поддерживают такую
 возможность. Подобные службы можно запускать в любой момент, они устойчивы к
-сбоям, и в любой ситуации работают корректно.
+сбоям, и работают корректно во всех возможных ситуациях.
 
-+network.target+ предназначена для поддержки программ, созданных в
+\verb+$network+ предназначена для поддержки программ, созданных в
 предположении, что сеть доступна постоянно (т.е. написанных не~очень аккуратно).
 Конкретные требования таких программ могут сильно отличаться. Например,
 IMAP-серверу будет достаточно наличия IP-адреса, на котором можно слушать. В то
 время как для клиентов сетевых файловых систем требуется требуется доступность и
 работоспособность сервера, а также, опционально, наличие работоспособного DNS.
-Таким образом, конкретные требования к +network.target+ сильно зависят от
+Таким образом, конкретные требования к \verb+$network+ сильно зависят от
 решаемой задачи.
 
 По соображениям надежности, загрузка системы не~должна зависеть от второстепенных
@@ -5812,6 +5905,12 @@ IMAP-серверу будет достаточно наличия IP-адрес
 процесс загрузки системы (за исключением ситуаций, когда сетевое соединение
 действительно необходимо для работы системы, например, при загрузке по сети).
 
+\begin{comment}
+% Настоящий фрагмент документации применим к systemd версий 212 и ниже.
+% Начиная с 11.06.2014 он удален из официальной документации. 
+% Пока остается здесь в виде комментария, для особо дотошных пользователей
+% старых версий systemd.
+
 По умолчанию, +network.target+ не~несет какой-либо сакральной смысловой
 нагрузки. Сама по себе настройка службы на запуск после достижения этой цели
 не~дает видимого эффекта. Наполнить +network.target+ смыслом должен сам
@@ -5857,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+, а о том, как можно исправить
@@ -5876,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}%