Version v7.0 (2011-07-29 19:01) [AUTO]

s4a.tex

@@ -45,22 +45,23 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
 \tableofcontents%\newpage
 \sectiona{Предисловие автора}
 Многие из вас, наверное, уже знают, что
-\href{http://www.freedesktop.org/wiki/Software/systemd}{systemd}~--- это
-новая система инициализации дистрибутива Fedora, начиная с
-Fedora~14\footnote{Прим. перев.: к сожалению, разработчики Fedora приняли
-решение оставить в Fedora~14 в качестве системы инициализации по умолчанию
-upstart, однако systemd все равно будет включен в этот релиз и может быть
-использован в качестве альтернативной системы инициализации}. Помимо Fedora,
-systemd также поддерживает и другие дистрибутивы, в частности,
-\href{http://en.opensuse.org/SDB:Systemd}{OpenSUSE}.
-systemd предоставляет администраторам целый ряд новых возможностей,
-значительно упрощающих процесс обслуживания системы. Эта статья является
-первой в серии публикаций, планируемых в ближайшие месяцы. В каждой из этих
-статей я попытаюсь рассказать об очередной новой возможности systemd.
+\href{http://www.freedesktop.org/wiki/Software/systemd}{systemd}~--- это новая
+система инициализации дистрибутива Fedora, начиная с Fedora~14\footnote{Прим.
+перев.: к сожалению, разработчики Fedora приняли решение оставить в Fedora~14 в
+качестве системы инициализации по умолчанию upstart, однако systemd все равно
+включен в этот релиз и может быть использован в качестве альтернативной системы
+инициализации. Окончательный переход на systemd произошел лишь в Fedora~15.}.
+Помимо Fedora, systemd также поддерживает и другие дистрибутивы, в частности,
+\href{http://en.opensuse.org/SDB:Systemd}{OpenSUSE}\footnote{Прим. перев.:
+сейчас systemd поддерживается практически во всех популярных дистрибутивах для
+настольных систем.}.  systemd предоставляет администраторам целый ряд новых
+возможностей, значительно упрощающих процесс обслуживания системы. Эта статья
+является первой в серии публикаций, планируемых в ближайшие месяцы. В каждой из
+этих статей я попытаюсь рассказать об очередной новой возможности systemd.
 Большинство этих возможностей можно описать легко и просто, и подобные статьи
-должны быть интересны довольно широкой аудитории.  Однако, время от времени
-мы будем рассматривать ключевые новшества systemd, что может потребовать
-несколько более подробного изложения. 
+должны быть интересны довольно широкой аудитории.  Однако, время от времени мы
+будем рассматривать ключевые новшества systemd, что может потребовать несколько
+более подробного изложения. 
 \begin{flushright}
 	Lennart P\"{o}ttering, 23 августа 2010~г.
 \end{flushright}
@@ -240,7 +241,7 @@ CGI-программы, а демон cron~--- команды, предписа
 вследствие ошибок в коде и/или конфигурации программ, но и в результате злого
 умысла. Например, очень часто встречается ситуация, когда установленный на
 взломанном сервере процесс-бэкдор маскируется под нормального демона, меняя
-себе имя, скажем, на httpd}.
+себе имя, скажем, на httpd.}.
 
 systemd предлагает простой путь для решения обсуждаемой задачи. Запуская
 очередной новый процесс, systemd помещает его в отдельную контрольную группу
@@ -648,7 +649,7 @@ Bug Reporting Tool, службы, занимающейся сбором crash du
 		+MTA+ или +smtpdaemon+ (Fedora), +smtp+
 		(openSUSE), +mail-transport-agent+ (Debian и Ubuntu),
 		+mail-transfer-agent+. Таким образом, можно утверждать, что
-		стандарт LSB не~справляется с возложенной на него задачей},
+		стандарт LSB не~справляется с возложенной на него задачей.},
 		содержащий информацию о зависимостях.  systemd, базирующийся
 		на идеях socket-активации, обычно не~требует явного описания
 		зависимостей (либо требует самого минимального описания).
@@ -705,13 +706,13 @@ WantedBy=multi-user.target
 во-вторых, указание, что данный юнит рекомендуется активировать после запуска
 демона системного лога\footnote{Строго говоря, эту зависимость здесь
 указывать не~нужно~--- в системах, в которых демон системного лога активируется
-через сокет, эта зависимость является избыточной. Современные реализации
+через сокет, данная зависимость является избыточной. Современные реализации
 демона системного лога (например, rsyslog начиная с пятой версии)
 поддерживают активацию через сокет. В системах, использующих такие
 реализации, явное указание +After=syslog.target+ будет избыточным, так
 как соответствующая функциональность поддерживается автоматически. Однако,
 эту строчку стоит все-таки указать для обеспечения совместимости с системами,
-использующими устаревшие реализации демона системного лога}. Эта информация,
+использующими устаревшие реализации демона системного лога.}. Эта информация,
 как мы помним, была указана в LSB-заголовке исходного init-скрипта. В нашем
 конфигурационном файле мы указываем зависимость от демона системного лога при
 помощи директивы +After+, указывающей на юнит +syslog.taget+. Это
@@ -749,7 +750,7 @@ systemd считает службу запущенной с момента за
 +multi-user.target+. Это специальный юнит, примерно соответствующий роли
 третьего уровня исполнения классического SysV\footnote{В том контексте, в
 котором он используется в большинстве дистрибутивов семейства Red Hat, а
-именно, многопользовательский режим без запуска графической оболочки}.
+именно, многопользовательский режим без запуска графической оболочки.}.
 Директива +WantedBy+ никак не~влияет на уже работающую службу, но она
 играет важную роль при выполнении команды +systemctl enable+, задавая, в каких
 условиях должен активироваться устанавливаемый юнит. В нашем примере, служба
@@ -759,7 +760,7 @@ abrtd будет активироваться при переходе в сос
 в SysV) является надстройкой над режимом многопользовательской консольной
 загрузки (+multi-user.target+, аналог runlevel 3 в SysV). Таким
 образом, все службы, запускаемые в режиме +multi-user.target+, будут
-также запускаться и в режиме +graphical.target+} (к <<ненормальным>>
+также запускаться и в режиме +graphical.target+.} (к <<ненормальным>>
 можно отнести, например, загрузки в режиме +emergency.target+, который
 является аналогом первого уровня исполнения в классической SysV).
 
@@ -818,7 +819,7 @@ systemd сложнее определить, какой из порожденн
 воспользовались типом запуска +dbus+. Он подходит для всех служб, которые в
 конце процесса инициализации регистрируют свое имя на шине D-Bus\footnote{В
 настоящее время практически все службы дистрибутива Fedora после запуска
-регистрируется на шине D-Bus}. ABRTd относится к ним.  С новыми настройками,
+регистрируется на шине D-Bus.}. ABRTd относится к ним.  С новыми настройками,
 systemd запустит процесс abrtd, который уже не~будет форкаться (согласно
 указанным нами ключам <<+-d -s+>>), и в качестве момента окончания периода
 запуска данной службы systemd будет рассматривать момент регистрации имени
@@ -906,7 +907,7 @@ Apache, crond, atd, которые по роду служебной деятел
 пользователем или службой не~создаст значительных проблем с отзывчивостью
 системы у других пользователей и служб. Таким образом, в качестве основной
 угрозы форк-бомбардировки остаются лишь возможности исчерпания памяти и
-идентификаторов процессов (PID)}.
+идентификаторов процессов (PID).}.
 
 В некоторый случах возникает необходимость отправить сигнал именно основному
 процессу службы. Например, используя +SIGHUP+, мы можем заставить демона
@@ -1105,35 +1106,35 @@ systemd и на этот случай есть простое решение, и
 \href{http://linux.die.net/man/1/chroot}{chroot-окружениями}. Системный вызов
 +chroot()+ позволяет задать для определенного процесса (и его потомков) каталог,
 который они будут рассматривать как корневой +/+, тем самым ограничивая для них
-область видимости иерархии файловой системы отдельным поддеревом. Большинство
+область видимости иерархии файловой системы отдельной ветвью. Большинство
 применений chroot-окружений можно отнести к двум классам задач:
 \begin{enumerate}
 	\item Обеспечение безопасности. Потенциально уязвимый демон chroot'ится
-		в отдельный каталог, и даже в случае успешной атаки, взломщик
+		в отдельный каталог и, даже в случае успешной атаки, взломщик
 		увидит лишь содержимое этого каталога, а не~всю файловую
 		систему~--- он окажется в ловушке chroot'а.
 	\item Подготовка и управление образом операционной системы при отладке,
 		тестировании, компиляции, установке или восстановлении. При этом
 		вся иерархия файловых систем гостевой ОС монтируется или
 		создается в каталоге системы-хоста, и при запуске оболочки (или
-		любого другого приложения) внутри этой иерархии, их корень
-		сдвигается в этот каталог. Система, которую <<видят>> такие
-		программы, может сильно отличаться от ОС хоста. Например, это
-		может быть другой дистрибутив, или даже другая аппаратная
+		любого другого приложения) внутри этой иерархии, в качестве
+		корня используется этот каталог. Система, которую <<видят>>
+		такие программы, может сильно отличаться от ОС хоста. Например,
+		это может быть другой дистрибутив, или даже другая аппаратная
 		архитектура (запуск i386-гостя на x86\_64-хосте). Гостевая ОС
-		не~может увидеть полной иерархии ОС хоста.
+		не~может увидеть полного дерева каталогов ОС хоста.
 \end{enumerate}
 
 В системах, использующих классический SysV init, использовать chroot-окружения
-сравнительно несложно. Например, чтобы запустить выбранного демона внутри
-иерархии гостевой ОС, достаточно смонтировать внутри этой иерархии +/proc+,
+сравнительно несложно. Например, чтобы запустить выбранного демона внутри дерева
+каталогов гостевой ОС, достаточно смонтировать внутри этого дерева +/proc+,
 +/sys+ и остальные API ФС, воспользоваться программой +chroot(1)+ для входа в
 окружение, и выполнить соответствующий init-скрипт, запустив +/sbin/service+
 внутри окружения.
 
 Но в системах, использующих systemd, уже не~все так просто. Одно из важнейших
 достоинств systemd состоит в том, что параметры среды, в которой запускаются
-демоны, никак не~зависит от метода их запуска. В системах, использующих SysV
+демоны, никак не~зависят от метода их запуска. В системах, использующих SysV
 init, многие параметры среды выполнения (в частности, лимиты на системные
 ресурсы, переменные окружения, и т.п.) наследуются от оболочки, из которой был
 запущен init-скрипт. При использовании systemd ситуация меняется радикально:
@@ -1154,8 +1155,8 @@ init-подсистемой (и это, в общем, неплохо, а есл
 chroot-окружения в системах на основе systemd? Что ж, постараемся дать подробный
 и всесторонний ответ на этот вопрос.
 
-Для начала рассмотрим первое из перечисленных выше применений chroot: изоляция в
-целях безопасности. Прежде всего, стоит заметить, что защита, предоставляемая
+Для начала, рассмотрим первое из перечисленных выше применений chroot: изоляция
+в целях безопасности. Прежде всего, стоит заметить, что защита, предоставляемая
 chroot'ом, весьма эфемерна и ненадежна, так как chroot не~является <<дорогой с
 односторонним движением>>. Выйти из chroot-окружения сравнительно несложно, и
 соответствующее предупреждение даже
@@ -1164,19 +1165,20 @@ chroot'ом, весьма эфемерна и ненадежна, так как
 методиками. В большинстве случаев, это возможно только при наличии поддержки
 chroot в самой программе. Прежде всего, корректное конфигурирование
 chroot-окружения требует глубокого понимания принципов работы программы.
-Например, нужно точно знать, какие сокеты использует программа, чтобы обеспечить
-bind-монтирование соответствующих каталогов. С учетом вышесказанного,
-эффективная chroot-защита обеспечивается в том случае, когда она реализована в
-коде самого демона. Именно разработчик лучше других знает (\emph{обязан} знать),
-как правильно сконфигурировать chroot-окружение, и какой минимальный набор
-файлов, каталогов и файловых систем необходим внутри него для нормальной работы
-демона. Уже сейчас существуют демоны, имеющие встроенную поддержку chroot.
-К сожалению, в системе Fedora, установленной с параметрами по умолчанию, таких
-демонов всего два: \href{http://avahi.org/}{Avahi} и RealtimeKit. Оба они
-написаны одним очень хитрым человеком ;-) (Вы можете собственноручно
-убедится в этом, выполнив команду +ls -l /proc/*/root+.)
+Например, нужно точно знать, какие каталоги нужно bind-монтировать из основной
+системы, чтобы обеспечить все необходимые для работы программы каналы связи.  С
+учетом вышесказанного, эффективная chroot-защита обеспечивается в том случае,
+когда она реализована в коде самого демона. Именно разработчик лучше других
+знает (\emph{обязан} знать), как правильно сконфигурировать chroot-окружение, и
+какой минимальный набор файлов, каталогов и файловых систем необходим внутри
+него для нормальной работы демона. Уже сейчас существуют демоны, имеющие
+встроенную поддержку chroot.  К сожалению, в системе Fedora, установленной с
+параметрами по умолчанию, таких демонов всего два:
+\href{http://avahi.org/}{Avahi} и RealtimeKit. Оба они написаны одним очень
+хитрым человеком ;-) (Вы можете собственноручно убедиться в этом, выполнив
+команду +ls -l /proc/*/root+.)
 
-Возвращаясь к тема нашего обсуждения: разумеется, systemd позволяет помещать
+Возвращаясь к теме нашего обсуждения: разумеется, systemd позволяет помещать
 выбранных демонов в chroot, и управлять ими точно так же, как и другими.
 Достаточно лишь указать параметр +RootDirectory=+ в соответствующем
 service-файле. Например:
@@ -1222,7 +1224,7 @@ RootDirectoryStartOnly=yes
 характерные для chroot. systemd позволяет использовать при конфигурировании
 юнитов некоторые возможности, предоставляемые FSNS. В частности, использование
 FSNS часто является гораздо более простой и удобной альтернативой созданию
-полноценных chroot-окружений. Используя директивы +ReadOnlyDirectories=+,
+полновесных chroot-окружений. Используя директивы +ReadOnlyDirectories=+,
 +InaccessibleDirectories=+, вы можете задать ограничения по использованию
 иерархии файловых систем для заданной службы: ее корнем будет системный корневой
 каталог, однако указанные в этих директивах подкаталоги будут доступны только 
@@ -1248,28 +1250,28 @@ Avahi и ReltimeKit в ближайшем будущем перейдут с +ch
 FSNS.
 
 Итак, мы рассмотрели вопросы использования chroot для обеспечения безопасности.
-Переходим ко второму пункту: Подготовка и управление образом операционной
+Переходим ко второму пункту: подготовка и управление образом операционной
 системы при отладке, тестировании, компиляции, установке или восстановлении.
 
-chroot-окружения, по сути, весьма примитивно: они изолируют только иерархии
+chroot-окружения, по сути, весьма примитивны: они изолируют только иерархии
 файловых систем. Даже после chroot'а в определенный подкаталог, процесс
-по-прежнему имеет полный доступ к системным вызовам, может убить любой процесс
-из основной системы, и т.п. Вследствие этого, запуск полноценной ОС (или ее
-части) внутри chroot'а несет угрозу для хост-системы: у гостя и хоста отличаются
-лишь содержимое файловой системы, все остальное у них общее. Например, если вы
-обновляете дистрибутив, установленный в chroot-окружении, и пост-установочный
-скрипт пакета отправляет +SIGTERM+ процессу init для его
-перезапуска\footnote{Прим. перев.: Во избежание путаницы отметим, что перезапуск
+по-прежнему имеет полный доступ к системным вызовам, может убивать процессы,
+запущенные в основной системе, и т.п. Вследствие этого, запуск полноценной ОС
+(или ее части) внутри chroot'а несет угрозу для хост-системы: у гостя и хоста
+отличается лишь содержимое файловой системы, все остальное у них общее.
+Например, если вы обновляете дистрибутив, установленный в chroot-окружении, и
+пост-установочный скрипт пакета отправляет +SIGTERM+ процессу init для его
+перезапуска\footnote{Прим. перев.: во избежание путаницы отметим, что перезапуск
 процесса init (PID~1) <<на лету>> при получении +SIGTERM+ поддерживается только
-в systemd, в классическом SysV init такой возможности нет}, на него среагирует
+в systemd, в классическом SysV init такой возможности нет.}, на него среагирует
 именно хост-система! Кроме того, хост и chroot'нутая система будут иметь общую
 разделяемую память SysV (SysV shared memory), общие сокеты из абстрактных
 пространств имен (abstract namespace sockets) и другие элементы IPC. Для
 отладки, тестирования, компиляции, установки и восстановлении ОС не~требуется
-абсолютно безопасная изоляция, однако нужна защита от \emph{случайного}
-воздействия на ОС хоста изнутри chroot-окружения, иначе вы можете получить целый
-букет проблем, как минимум, от пост-инсталляционных скриптов при установке
-пакетов в chroot-окружении.
+абсолютно неуязвимая изоляция~--- нужна лишь надежная защита от
+\emph{случайного} воздействия на ОС хоста изнутри chroot-окружения, иначе вы
+можете получить целый букет проблем, как минимум, от пост-инсталляционных
+скриптов при установке пакетов в chroot-окружении.
 
 systemd имеет целый ряд возможностей, полезных для работы с chroot-системами:
 
@@ -1296,7 +1298,7 @@ debootstrap/febootstrap. В этом случае возможности +system
 +chroot(1)+~--- она не~только подменяет корневой каталог, но и создает отдельные
 пространства имен для дерева файловых систем (FSNS) и для идентификаторов
 процессов (PID NS), предоставляя легковесную реализацию системного
-контейнера\footnote{Прим. перев.: Используемые в +systemd-nspawn+ механизмы 
+контейнера\footnote{Прим. перев.: используемые в +systemd-nspawn+ механизмы 
 ядра Linux, такие, как FS NS и PID NS, также лежат в основе
 \href{http://lxc.sourceforge.net/}{LXC}, системы контейнерной изоляции для
 Linux, которая позиционируется как современная альтернатива классическому
@@ -1363,15 +1365,15 @@ systemd уже подготовлен для работы внутри таки
 шаге вызывает не~+reboot()+, а просто +exit()+.
 
 Стоит отметить, что +systemd-nspawn+ все же не~является полноценной системой
-контейнерной виртуализации/изоляции~--- если нужно именно это, воспользуйтесь
-\href{ http://lxc.sourceforge.net/}{LXC}. Этот проект использует те же самые
-механизмы ядра, но предоставляет куда более широкие возможности, включая
-виртуализацию сети. Если вам угодно, +systemd-nspawn+ как реализация контейнера
-похожа на GNOME~3~--- компактна и проста в использовании, опций для настройки
-очень мало. В то время как LXC больше похож на KDE: опций для настройки больше,
-чем строк кода. Я создал +systemd-nspawn+ специально для тестирования, отладки,
-сборки, восстановления. Именно для этих задач вам стоит ее использовать~--- она
-неплохо с ними справляется, куда лучше, чем +chroot(1)+.
+контейнерной виртуализации/изоляции~--- если вам нужно такое решение,
+воспользуйтесь \href{ http://lxc.sourceforge.net/}{LXC}. Этот проект использует
+те же самые механизмы ядра, но предоставляет куда более широкие возможности,
+включая виртуализацию сети. Могу предложить такую аналогию: +systemd-nspawn+ как
+реализация контейнера похожа на GNOME~3~--- компактна и проста в использовании,
+опций для настройки очень мало. В то время как LXC больше похож на KDE: опций
+для настройки больше, чем строк кода. Я создал +systemd-nspawn+ специально для
+тестирования, отладки, сборки, восстановления. Именно для этих задач вам стоит
+ее использовать~--- она неплохо с ними справляется, куда лучше, чем +chroot(1)+.
 
 Что ж, пора заканчивать. Итак:
 \begin{enumerate}
@@ -1476,7 +1478,7 @@ $ systemd-analyze blame
 мы можем с этим сделать? Эта служба выполняет очень простую задачу: она ожидает,
 пока udev завершит опрос устройств, после чего завершается. Опрос же устройств
 может занимать довольно много времени. Например, в нашем случае опрос устройств
-занимает более 6~секунд из-за встроенного в компьютер 3G-модема, в котором
+занимает более 6~секунд из-за подключенного к компьютеру 3G-модема, в котором
 отсутствует SIM-карта. Этот модем очень долго отвечает на запросы udev. Опрос
 устройств является частью схемы, обеспечивающей работу ModemManager'а и
 позволяющей NetworkManager'у упростить для вас настройку 3G. Казалось бы,
@@ -1562,12 +1564,12 @@ cryptsetup, что снижение этого времени с 1 секунд
 нужно сделать так, чтобы этот каталога автоматически монтировался при загрузке,
 но процесс загрузки не~ожидал завершения работы +cryptsetup+, +fsck+ и +mount+
 для этого раздела. Как же сделать точку монтирования доступной, не~ожидая, пока
-завершится процесс монтирования? Это можно сделать, воспользовавшись магической
-силой systemd~--- просто добавим опцию монтирования +comment=systemd.automount+
-в +/etc/fstab+. После этого, systemd будет создавать в +/home+ точку
-автоматического монтирования, и при первом же обращении к этому каталогу,
-если файловая система еще не~будет готова к работе,
-systemd подготовит соответствующее устройство, проверит и смонтирует ее.
+завершится процесс монтирования? Этого можно достичь, воспользовавшись
+магической силой systemd~--- просто добавим опцию монтирования
++comment=systemd.automount+ в +/etc/fstab+. После этого, systemd будет создавать
+в +/home+ точку автоматического монтирования, и при первом же обращении к этому
+каталогу, если файловая система еще не~будет готова к работе, systemd подготовит
+соответствующее устройство, проверит и смонтирует ее.
 
 После внесения изменений в +/etc/fstab+ и перезагрузки мы получаем:
 \begin{Verbatim}
@@ -1647,7 +1649,7 @@ Fedora~15 <<из коробки>>.
 
 \section{Новые конфигурационные файлы}
 
-Одно из наиболее масштабных нововведений
+Одно из ключевых достоинств
 \href{http://www.freedesktop.org/wiki/Software/systemd}{systemd}~--- наличие
 полного набора программ, необходимых на ранних стадиях загрузки, причем эти
 программы написаны на простом, быстром, надежном и легко поддающемся
@@ -1658,12 +1660,12 @@ shell-скриптов, разработанных для этих задач р
 оставляет желать лучшего, но все же неплохо передает основную идею.} увенчался
 полным успехом. Уже сейчас возможности предоставляемого нами инструментария
 покрывают практически все нужды настольных и встраиваемых систем, а также
-большую часть потребностей серверных систем:
+б\'{о}льшую часть потребностей серверов:
 \begin{itemize}
 	\item Проверка и монтирование всех файловых систем.
 	\item Обновление и активация квот на всех файловых системах.
 	\item Установка имени хоста.
-	\item Конфигурирование интерфейса обратной петли (+lo+).
+	\item Настройка сетевого интерфейса обратной петли (+lo+).
 	\item Подгрузка правил SELinux, обновление
 		меток безопасности в динамических каталогах +/run+ и +/dev+.
 	\item Регистрация в ядре дополнительных бинарных форматов (например,
@@ -1698,11 +1700,11 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
 дистрибутивов, и поэтому реализация их поддержки в наших инструментах
 не~представляла особого труда. Например, это относится к файлам +/etc/fstab+,
 +/etc/crypttab+, +/etc/sysctl.conf+. Однако множество других, нестандартно
-расположенных файлов и каталогов вынуждали нас добавлять множество операторов
-+#ifdef+, чтобы обеспечить поддержку различных вариантов расположения
-конфигураций в разных дистрибутивах. Такой положение дел сильно усложняет
-жизнь нам всем, и при этом ничем не~оправдано~--- все эти файлы решают одни и те
-же задачи, но делают это немного по-разному.
+расположенных файлов и каталогов вынуждали нас добавлять в код огромное
+количество операторов +#ifdef+, чтобы обеспечить поддержку различных вариантов
+расположения конфигураций в разных дистрибутивах. Такой положение дел сильно
+усложняет жизнь нам всем, и при этом ничем не~оправдано~--- все эти файлы решают
+одни и те же задачи, но делают это немного по-разному.
 
 Чтобы улучшить ситуацию и установить единый стандарт расположения базовых
 конфигурационных файлов во всех дистрибутивах, мы заставили systemd пользоваться
@@ -1768,7 +1770,7 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
 		перечень возможных названий файлов. Проект LSB попытался создать
 		такой инструмент~---
 		\hreftt{http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/lsbrelease.html}{lsb\_release}~---
-		однако реализация такой простой вещи через скрипт на Python'е
+		однако реализация столь простой функции через скрипт на Python'е
 		является не~самым оптимальным решением. Чтобы исправить
 		сложившуюся ситуацию, мы решили перейти к единому простому
 		формату представления этой информации.
@@ -1796,12 +1798,12 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
 конфигурационные файлы в ваших инструментах для настройки системы. Если ваши
 конфигурационные фронтенды будут использовать новые файлы, а не~их старые
 аналоги, это значительно облегчит портирование таких фронтендов между
-дистрибутивами, и вы внесете свой вклад в стандартизацию Linux, и в конечном
-счете упростится жизнь и у администраторов, и для пользователей. Разумеется, на
-текущий момент эти файлы полностью поддерживаются только дистрибутивами,
-основанными на systemd, но уже сейчас в их число входят практически все ключевые
-дистрибутивы, \href{http://www.ubuntu.com/}{за исключением
-одного}\footnote{Прим. перев.: В конце 2010~года энтузиаст Andrew Edmunds
+дистрибутивами, и вы внесете свой вклад в стандартизацию Linux. В конечном счете
+это упростит жизнь и администраторам, и пользователям. Разумеется, на текущий
+момент эти файлы полностью поддерживаются только дистрибутивами, основанными на
+systemd, но уже сейчас в их число входят практически все ключевые дистрибутивы,
+\href{http://www.ubuntu.com/}{за исключением
+одного}\footnote{Прим. перев.: в конце 2010~года энтузиаст Andrew Edmunds
 \href{http://cgit.freedesktop.org/systemd/commit/?id=858dae181bb5461201ac1c04732d3ef4c67a0256}{добавил}
 в systemd базовую поддержку Ubuntu и
 \href{https://wiki.ubuntu.com/systemd}{подготовил} соответствующие пакеты,
@@ -1822,7 +1824,7 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
 дистрибутивов механизмы поддержки бинарных форматов больше не~нужны, и ваш
 проект будет работать одинаково хорошо во всех дистрибутивах. Аналогичное
 предложение мы обращаем и ко всем разработчикам программ, которым требуется
-автоматическое создание/очистка временных файлов и каталогов при загрузке,
+автоматическое создание/очистка временных файлов и каталогов,
 например, в каталоге +/run+ (\href{http://lwn.net/Articles/436012/}{ранее
 известном} как +/var/run+). Таким проектам достаточно просто поместить
 соответствующий конфигурационный файл в +/etc/tmpfiles.d/+, тоже средствами
@@ -1838,8 +1840,14 @@ shell-скриптов, выполняющих тривиальные задач
 и форматы конфигурационных файлов. Но нам все же нужно было что-то выбрать, и мы
 выбрали то, что должно устроить большинство людей. Форматы конфигурационных
 файлов максимально просты, и их можно легко читать и записывать даже из
-shell-скриптов. (Эх, а ведь +/etc/bikeshed.conf+ могло бы быть неплохим именем
-для файла конфигурации!)
+shell-скриптов. Да, +/etc/bikeshed.conf+ могло бы быть неплохим именем
+для файла конфигурации!\footnote{Прим. перев.: здесь автор намекает на
+\href{http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality}{Паркинсоновский
+Закон Тривиальности}, который гласит, что самые жаркие споры возникают вокруг
+наиболее простых вопросов. В частности, в качестве примера Паркинсон приводит
+обсуждение строительства атомной электростанции и гаража для велосипедов (bike
+shed)~--- если первое из этих решений принимается довольно быстро, то вокруг
+второго разгорается множество дискуссий по самым разным аспектам.}
 
 \textbf{Помогите нам стандартизировать Linux! Используйте новые конфигурационные
 файлы! Поддерживайте их в апстриме, поддерживайте их во всех дистрибутивах!}
@@ -1849,6 +1857,40 @@ shell-скриптов. (Эх, а ведь +/etc/bikeshed.conf+ могло бы
 этих разработчиков планируют обеспечить поддержку новой конфигурации даже в
 системах без systemd.
 
+\section{О судьбе /etc/sysconfig и /etc/default}
+
+В дистрибутивах, основанных на Red Hat и SUSE, это каталог называется
++/etc/sysconfig+. В дистрибутивах на базе Debian, его зовут +/etc/default+.
+Во многих других дистрибутивах также присутствуют каталоги похожего назначения.
+Связанные с ними вопросы неоднократно появляются в дискуссиях пользователей и
+разработчиков systemd. В этой статье мне хотелось бы рассказать, что я, как
+разработчик systemd, думаю об этих каталогах, и пояснить, почему я считаю
+необходимым от них отказаться. Стоит отметить, что это мое личное мнение, и оно
+может не~совпадать с позицией проекта Fedora или моего работодателя.
+
+Начнем с небольшого исторического экскурса. Каталог +/etc/sysconfig+ появился в
+дистрибутивах Red Hat и SUSE задолго до того, как я присоединился к этим
+проектам, так что можно смело утверждать, что это было очень давно. 
+Через некоторое время, в Debian появился аналогичный по смыслу каталог
++/etc/default+. Многие дистрибутивы используют такие каталоги, называя их
+по-разному. Они имеются даже в некоторых ОС семейства Unix. (Например, в SCO.
+Если эта тема вас заинтересовала~--- рекомендую обратиться к вашему знакомому
+ветерану Unix, он расскажет куда подробнее и интереснее, чем я.) Несмотря на то,
+что подобные каталоги широко используются в Linux и Unix, они совершенно
+не~стандартизированы~--- ни в POSIX, ни в LSB/FHS, и результате мы имеем целый
+зоопарк их различных реализаций в разных дистрибутивах.
+
+Назначение этих каталогов определено весьма расплывчато. Абсолютное большинство
+находящихся в них файлов являются включаемыми\footnote{Прим. перев.: здесь автор
+использует термин sourcable, происходящий от bash'овской директивы +source+,
+обеспечивающей включение в скрипт кода из внешнего файла. В классическом POSIX
+shell это соответствует оператору-точке <<+.+>>. В отличие от прямого запуска
+одного скрипта из другого, включаемый код исполняется той же самой оболочкой,
+что и основной код, и при возвращении в основной скрипт сохраняются переменные
+окружения, определенные во включаемом коде. Как правило, код для включения
+не~содержит shebang'а (+#!/bin/sh+ в начале файла).} shell-скриптами, содержащими,
+главным образом, определения переменных.
+
 \end{document}
 
 vim:ft=tex:tw=80:spell:spelllang=ru