Version v8.6 (2012-01-02 16:44) [AUTO]

s4a.tex

@@ -666,9 +666,11 @@ Bug Reporting Tool, службы, занимающейся сбором crash du
 		socket-активацию, рассмотрены в статье
 		\href{http://0pointer.de/blog/projects/systemd.html}{Rethinking
 		PID~1}, в которой systemd был впервые представлен широкой
-		публике. Ее русский перевод можно прочитать здесь:
+		публике\footnote{Прим. перев.: Ее русский перевод (сделанный
+		совершенно независимо от данного документа, совсем другим
+		человеком) можно прочитать здесь:
 		\href{http://tux-the-penguin.blogspot.com/2010/09/systemd.html}{часть~1},
-		\href{http://tux-the-penguin.blogspot.com/2010/09/systemd-ii.html}{часть~2}.
+		\href{http://tux-the-penguin.blogspot.com/2010/09/systemd-ii.html}{часть~2}.}.
 		Возвращаясь к нашему примеру: в данном случае ценной
 		информацией о зависимостях является только строка
 		+Required-Start: $syslog+, сообщающая, что для работы
@@ -764,14 +766,14 @@ systemd считает службу запущенной с момента за
 играет важную роль при выполнении команды +systemctl enable+, задавая, в каких
 условиях должен активироваться устанавливаемый юнит. В нашем примере, служба
 abrtd будет активироваться при переходе в состояние +multi-user.target+,
-т.е., при каждой нормальной загрузке\footnote{Обратите внимание, что режим
-графической загрузки в systemd (+graphical.target+, аналог runlevel 5
-в SysV) является надстройкой над режимом многопользовательской консольной
-загрузки (+multi-user.target+, аналог runlevel 3 в SysV). Таким
-образом, все службы, запускаемые в режиме +multi-user.target+, будут
-также запускаться и в режиме +graphical.target+.} (к <<ненормальным>>
-можно отнести, например, загрузки в режиме +emergency.target+, который
-является аналогом первого уровня исполнения в классической SysV).
+т.е., при каждой нормальной\footnote{Прим. перев.: К <<ненормальным>> загрузкам
+можно отнести, например, загрузки в режимах +emergency.target+ или
++rescue.target+ (является аналогом первого уровня исполнения в классической
+SysV).} загрузке\footnote{Обратите внимание, что режим графической загрузки в
+systemd (+graphical.target+, аналог runlevel 5 в SysV) является надстройкой над
+режимом многопользовательской консольной загрузки (+multi-user.target+, аналог
+runlevel 3 в SysV). Таким образом, все службы, запускаемые в режиме
++multi-user.target+, будут также запускаться и в режиме +graphical.target+.}.
 
 Вот и все. Мы получили минимальный рабочий service-файл systemd. Чтобы
 проверить его работоспособность, скопируем его в
@@ -1347,17 +1349,17 @@ Linux, которая позиционируется как современна
 полноценной ОС, функционирующей в контейнере. Изнутри контейнера невозможно
 увидеть процессы, которые находятся вне его. Контейнер сможет пользоваться сетью
 хоста\footnote{Прим. перев.: Впоследствии в +systemd-nspawn+ была добавлена
-опция +--private-network+, изолирующая систему внутри контейнера от сети хоста:
-такая система будет видеть только свой собственный интерфейс обратной петли.},
-однако не~имеет возможности изменить ее настройки (это может привести к серии
-ошибок в процессе загрузки гостевой ОС, но ни~одна из этих ошибок не~должна быть
-критической). Контейнер получает доступ к +/sys+ и +/proc/sys+, однако, во
-избежание вмешательства контейнера в конфигурацию ядра и аппаратного обеспечения
-хоста, эти каталоги будут смонтированы только для чтения. Обратите внимание, что
-эта защита блокирует лишь \emph{случайные}, \emph{непредвиденные} попытки
-изменения параметров. При необходимости, процесс внутри контейнера, обладающий
-достаточными полномочиями, сможет перемонтировать эти файловые системы в режиме
-чтения-записи.
+опция +--private-network+, позволяющая изолировать систему внутри контейнера от
+сети хоста: такая система будет видеть только свой собственный интерфейс
+обратной петли.}, однако не~имеет возможности изменить ее настройки (это может
+привести к серии ошибок в процессе загрузки гостевой ОС, но ни~одна из этих
+ошибок не~должна быть критической). Контейнер получает доступ к +/sys+ и
++/proc/sys+, однако, во избежание вмешательства контейнера в конфигурацию ядра и
+аппаратного обеспечения хоста, эти каталоги будут смонтированы только для
+чтения. Обратите внимание, что эта защита блокирует лишь \emph{случайные},
+\emph{непредвиденные} попытки изменения параметров. При необходимости, процесс
+внутри контейнера, обладающий достаточными полномочиями, сможет перемонтировать
+эти файловые системы в режиме чтения-записи.
 
 Итак, что же такого хорошего в +systemd-nspawn+?
 \begin{enumerate}
@@ -1820,14 +1822,13 @@ systemd, но уже сейчас в их число входят практич
 в systemd базовую поддержку Ubuntu и
 \href{https://wiki.ubuntu.com/systemd}{подготовил} соответствующие пакеты,
 однако его инициатива не~встретила поддержки среди менеджеров Canonical. На
-момент написания этих строк (май 2011 года) проект остается заброшенным уже пять
-месяцев (с середины декабря 2010~г.).}. В этом есть что-то от <<проблемы курицы
-и яйца>>: стандарт становится настоящим стандартом только тогда, когда ему
-начинают следовать. В будущем мы намерены аккуратно форсировать процесс перехода
-на новые конфигурационные файлы: поддержка старых файлов будет удалена из
-systemd. Разумеется, этот процесс будет идти медленно, шаг за шагом. Но конечной
-его целью является переход всех дистрибутивов на единый набор базовых
-конфигурационных файлов.
+момент написания этих строк проект остается заброшенным с декабря 2010~г.}.  В
+этом есть что-то от <<проблемы курицы и яйца>>: стандарт становится настоящим
+стандартом только тогда, когда ему начинают следовать. В будущем мы намерены
+аккуратно форсировать процесс перехода на новые конфигурационные файлы:
+поддержка старых файлов будет удалена из systemd. Разумеется, этот процесс будет
+идти медленно, шаг за шагом. Но конечной его целью является переход всех
+дистрибутивов на единый набор базовых конфигурационных файлов.
 
 Многие из этих файлов используются не~только программами для настройки системы,
 но и апстримными проектами. Например, мы предлагаем проектам Mono, Java, WINE и
@@ -2151,20 +2152,19 @@ systemd?
 \emph{foobar}~--- строка, идентифицирующая службу (проще говоря, ее имя), а
 +.service+~--- суффикс, присутствующий в именах всех файлов конфигурации служб.
 Сами эти файлы могут находиться в каталогах +/etc/systemd/systemd+ и
-+/lib/systemd/system+ (а также, возможно, и в других\footnote{Прим. перев.: В
-качестве <<других>> каталогов, в которых выполняется поиск юнит-файлов, можно
-упомянуть +/run/systemd/system+, в который помещаются временные файлы
-конфигурации, созданные администратором или программами-генераторами и
-действующие только текущем сеансе, и +/usr/lib/systemd/system+, в котором
-находятся юнит-файлы для обычных служб, запускаемых на поздних стадиях загрузки
-(то время, как в упомянутом каталоге +/lib/systemd/system+ находятся файлы
-конфигурации ключевых системных юнитов, которые требуются на раннем этапе
-загрузки, до монтирования +/usr+).}). Для служб, работающих в
-нескольких экземплярах, эта схема становится немного сложнее:
-\emph{foobar}+@+\emph{quux}+.service+, где \emph{foobar}~--- имя службы,
-общее для всех экземпляров, а \emph{quux}~--- идентификатор конкретного
-экземпляра. Например, +serial-gett@ttyS2.service+~--- это служба getty для
-COM-порта, запущенная на +ttyS2+.
++/lib/systemd/system+ (а также, возможно, и в других\footnote{Прим. перев.:
+Перечень каталогов, в которых выполняется поиск общесистемных юнит-файлов,
+приведен на странице руководства 
+\href{http://www.0pointer.de/public/systemd-man/systemd.html}{systemd(1)}
+(раздел <<System unit directories>>).  Указанные выше каталоги
++/etc/systemd/systemd+ и +/lib/systemd/system+ соответствуют значениям по
+умолчанию для упомянутых там переменных pkg-config +systemdsystemconfdir+ и
++systemdsystemunitdir+ соответственно.}). Для служб, работающих в нескольких
+экземплярах, эта схема становится немного сложнее:
+\emph{foobar}+@+\emph{quux}+.service+, где \emph{foobar}~--- имя службы, общее
+для всех экземпляров, а \emph{quux}~--- идентификатор конкретного экземпляра.
+Например, +serial-gett@ttyS2.service+~--- это служба getty для COM-порта,
+запущенная на +ttyS2+.
 
 При необходимости, экземпляры служб можно легко создать динамически. Скажем, вы
 можете, безо всяких дополнительных настроек, запустить новый экземпляр getty на
@@ -2478,10 +2478,10 @@ StandardInput=socket
 \end{Verbatim}
 
 Большинство представленных здесь опций, как всегда, понятны интуитивно. Особое
-внимание стоит обратить лишь на +StandardInput=socket+, которая, собственно, и
-включает для данной службы режим совместимости с inetd-активацией. Опция
-+StandardInput=+ позволяет указать, куда будет подключен поток STDIN процесса
-данной службы (подробности см.
+внимание стоит обратить лишь на строчку +StandardInput=socket+, которая,
+собственно, и включает для данной службы режим совместимости с inetd-активацией.
+Опция +StandardInput=+ позволяет указать, куда будет подключен поток STDIN
+процесса данной службы (подробности см.
 \href{http://0pointer.de/public/systemd-man/systemd.exec.html}{на странице
 руководства}). Задав для нее значение +socket+, мы обеспечиваем подключение
 этого потока к сокету соединения, как того и требует механизм inetd-активации.