From aaa2ec62eb4c5133d25666016fcd5343c02b99fd Mon Sep 17 00:00:00 2001 From: nnz1024 <0comffdiz@inbox.ru> Date: Mon, 2 Jan 2012 16:44:00 +0400 Subject: [PATCH] Version v8.6 (2012-01-02 16:44) [AUTO] --- s4a.tex | 94 ++++++++++++++++++++++++++++----------------------------- 1 file changed, 47 insertions(+), 47 deletions(-) diff --git a/s4a.tex b/s4a.tex index 2c5d5b1..6feb91e 100644 --- a/s4a.tex +++ b/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)} +(раздел <>). Указанные выше каталоги ++/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-активации.