Version v7.4 (2011-08-24 16:13) [AUTO]

s4a.tex

@@ -13,8 +13,9 @@
 % Заполняем поля PDF уже со включенной опцией unicode
 \hypersetup{pdftitle={systemd для администраторов},%
 pdfauthor={Lennart Poettering, Sergey Ptashnick}}
-% Небольшое сокращение
+% Несколько сокращений
 \newcommand{\sectiona}[1]{\section*{#1}\addcontentsline{toc}{section}{#1}}
+\newcommand{\hreftt}[2]{\href{#1}{\texttt{#2}}}
 % Настройка макета страницы
 \setlength{\hoffset}{-1.5cm}
 \addtolength{\textwidth}{2cm}
@@ -44,22 +45,23 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
 \tableofcontents%\newpage
 \sectiona{Предисловие автора}
 Многие из вас, наверное, уже знают, что
-\href{http://www.freedesktop.org/wiki/Software/systemd}{systemd}~--- это
+\href{http://www.freedesktop.org/wiki/Software/systemd}{systemd}~--- это новая
-новая система инициализации дистрибутива Fedora, начиная с
+система инициализации дистрибутива Fedora, начиная с Fedora~14\footnote{Прим.
-Fedora~14\footnote{Прим. перев.: к сожалению, разработчики Fedora приняли
+перев.: к сожалению, разработчики Fedora приняли решение оставить в Fedora~14 в
-решение оставить в Fedora~14 в качестве системы инициализации по умолчанию
+качестве системы инициализации по умолчанию upstart, однако systemd все равно
-upstart, однако systemd все равно будет включен в этот релиз и может быть
+включен в этот релиз и может быть использован в качестве альтернативной системы
-использован в качестве альтернативной системы инициализации}. Помимо Fedora,
+инициализации. Окончательный переход на systemd произошел лишь в Fedora~15.}.
-systemd также поддерживает и другие дистрибутивы, в частности,
+Помимо Fedora, systemd также поддерживает и другие дистрибутивы, в частности,
-\href{http://en.opensuse.org/SDB:Systemd}{OpenSUSE}.
+\href{http://en.opensuse.org/SDB:Systemd}{OpenSUSE}\footnote{Прим. перев.:
-systemd предоставляет администраторам целый ряд новых возможностей,
+сейчас systemd поддерживается практически во всех популярных дистрибутивах для
-значительно упрощающих процесс обслуживания системы. Эта статья является
+настольных систем.}.  systemd предоставляет администраторам целый ряд новых
-первой в серии публикаций, планируемых в ближайшие месяцы. В каждой из этих
+возможностей, значительно упрощающих процесс обслуживания системы. Эта статья
-статей я попытаюсь рассказать об очередной новой возможности systemd.
+является первой в серии публикаций, планируемых в ближайшие месяцы. В каждой из
+этих статей я попытаюсь рассказать об очередной новой возможности systemd.
 Большинство этих возможностей можно описать легко и просто, и подобные статьи
-должны быть интересны довольно широкой аудитории.  Однако, время от времени
+должны быть интересны довольно широкой аудитории.  Однако, время от времени мы
-мы будем рассматривать ключевые новшества systemd, что может потребовать
+будем рассматривать ключевые новшества systemd, что может потребовать несколько
-несколько более подробного изложения. 
+более подробного изложения. 
 \begin{flushright}
 	Lennart P\"{o}ttering, 23 августа 2010~г.
 \end{flushright}
@@ -239,7 +241,7 @@ CGI-программы, а демон cron~--- команды, предписа
 вследствие ошибок в коде и/или конфигурации программ, но и в результате злого
 умысла. Например, очень часто встречается ситуация, когда установленный на
 взломанном сервере процесс-бэкдор маскируется под нормального демона, меняя
-себе имя, скажем, на httpd}.
+себе имя, скажем, на httpd.}.
 
 systemd предлагает простой путь для решения обсуждаемой задачи. Запуская
 очередной новый процесс, systemd помещает его в отдельную контрольную группу
@@ -647,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-активации, обычно не~требует явного описания
 		зависимостей (либо требует самого минимального описания).
@@ -704,13 +706,13 @@ WantedBy=multi-user.target
 во-вторых, указание, что данный юнит рекомендуется активировать после запуска
 демона системного лога\footnote{Строго говоря, эту зависимость здесь
 указывать не~нужно~--- в системах, в которых демон системного лога активируется
-через сокет, эта зависимость является избыточной. Современные реализации
+через сокет, данная зависимость является избыточной. Современные реализации
 демона системного лога (например, rsyslog начиная с пятой версии)
 поддерживают активацию через сокет. В системах, использующих такие
 реализации, явное указание +After=syslog.target+ будет избыточным, так
 как соответствующая функциональность поддерживается автоматически. Однако,
 эту строчку стоит все-таки указать для обеспечения совместимости с системами,
-использующими устаревшие реализации демона системного лога}. Эта информация,
+использующими устаревшие реализации демона системного лога.}. Эта информация,
 как мы помним, была указана в LSB-заголовке исходного init-скрипта. В нашем
 конфигурационном файле мы указываем зависимость от демона системного лога при
 помощи директивы +After+, указывающей на юнит +syslog.taget+. Это
@@ -748,7 +750,7 @@ systemd считает службу запущенной с момента за
 +multi-user.target+. Это специальный юнит, примерно соответствующий роли
 третьего уровня исполнения классического SysV\footnote{В том контексте, в
 котором он используется в большинстве дистрибутивов семейства Red Hat, а
-именно, многопользовательский режим без запуска графической оболочки}.
+именно, многопользовательский режим без запуска графической оболочки.}.
 Директива +WantedBy+ никак не~влияет на уже работающую службу, но она
 играет важную роль при выполнении команды +systemctl enable+, задавая, в каких
 условиях должен активироваться устанавливаемый юнит. В нашем примере, служба
@@ -758,7 +760,7 @@ abrtd будет активироваться при переходе в сос
 в SysV) является надстройкой над режимом многопользовательской консольной
 загрузки (+multi-user.target+, аналог runlevel 3 в SysV). Таким
 образом, все службы, запускаемые в режиме +multi-user.target+, будут
-также запускаться и в режиме +graphical.target+} (к <<ненормальным>>
+также запускаться и в режиме +graphical.target+.} (к <<ненормальным>>
 можно отнести, например, загрузки в режиме +emergency.target+, который
 является аналогом первого уровня исполнения в классической SysV).
 
@@ -817,7 +819,7 @@ systemd сложнее определить, какой из порожденн
 воспользовались типом запуска +dbus+. Он подходит для всех служб, которые в
 конце процесса инициализации регистрируют свое имя на шине D-Bus\footnote{В
 настоящее время практически все службы дистрибутива Fedora после запуска
-регистрируется на шине D-Bus}. ABRTd относится к ним.  С новыми настройками,
+регистрируется на шине D-Bus.}. ABRTd относится к ним.  С новыми настройками,
 systemd запустит процесс abrtd, который уже не~будет форкаться (согласно
 указанным нами ключам <<+-d -s+>>), и в качестве момента окончания периода
 запуска данной службы systemd будет рассматривать момент регистрации имени
@@ -905,7 +907,7 @@ Apache, crond, atd, которые по роду служебной деятел
 пользователем или службой не~создаст значительных проблем с отзывчивостью
 системы у других пользователей и служб. Таким образом, в качестве основной
 угрозы форк-бомбардировки остаются лишь возможности исчерпания памяти и
-идентификаторов процессов (PID)}.
+идентификаторов процессов (PID).}.
 
 В некоторый случах возникает необходимость отправить сигнал именно основному
 процессу службы. Например, используя +SIGHUP+, мы можем заставить демона
@@ -1050,7 +1052,7 @@ systemd и на этот случай есть простое решение, и
 		Заметим, что systemd читает файлы конфигурации из обоих этих
 		каталогов, но файлы из +/etc+ (управляемые системным
 		администратором) имеют приоритет над файлами из +/lib+ (которые
-		управляются пакетным менеджером). Таким образом, созание
+		управляются пакетным менеджером). Таким образом, создание
 		символьной ссылки (или обычного файла)
 		+/etc/systemd/system/ntpd.service+ предотвращает чтение
 		штатного файла конфигурации +/lib/systemd/system/ntpd.service+.
@@ -1090,7 +1092,7 @@ systemd и на этот случай есть простое решение, и
 		(через механизмы sudo или PolicyKit) право на использование
 		+systemctl+, это еще не~означает, что он сможет запустить
 		заблокированную службу~--- права на выполнение +rm+ (удаление
-		блокирующей символьной ссылки) выдаются отдельно}.
+		блокирующей символьной ссылки) выдаются отдельно.}.
 \end{itemize}
 
 После прочтения изложенного выше, у читателя может возникнуть вопрос: как
@@ -1104,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 ситуация меняется радикально:
@@ -1153,8 +1155,8 @@ init-подсистемой (и это, в общем, неплохо, а есл
 chroot-окружения в системах на основе systemd? Что ж, постараемся дать подробный
 и всесторонний ответ на этот вопрос.
 
-Для начала рассмотрим первое из перечисленных выше применений chroot: изоляция в
+Для начала, рассмотрим первое из перечисленных выше применений chroot: изоляция
-целях безопасности. Прежде всего, стоит заметить, что защита, предоставляемая
+в целях безопасности. Прежде всего, стоит заметить, что защита, предоставляемая
 chroot'ом, весьма эфемерна и ненадежна, так как chroot не~является <<дорогой с
 односторонним движением>>. Выйти из chroot-окружения сравнительно несложно, и
 соответствующее предупреждение даже
@@ -1163,19 +1165,20 @@ chroot'ом, весьма эфемерна и ненадежна, так как
 методиками. В большинстве случаев, это возможно только при наличии поддержки
 chroot в самой программе. Прежде всего, корректное конфигурирование
 chroot-окружения требует глубокого понимания принципов работы программы.
-Например, нужно точно знать, какие сокеты использует программа, чтобы обеспечить
+Например, нужно точно знать, какие каталоги нужно bind-монтировать из основной
-bind-монтирование соответствующих каталогов. С учетом вышесказанного,
+системы, чтобы обеспечить все необходимые для работы программы каналы связи.  С
-эффективный chroot-защита обеспечивается в том случае, когда она реализована в
+учетом вышесказанного, эффективная chroot-защита обеспечивается в том случае,
-коде самого демона. Именно разработчик лучше других знает (\emph{обязан знать}),
+когда она реализована в коде самого демона. Именно разработчик лучше других
-как правильно сконфигурировать chroot-окружение, и какой минимальный набор
+знает (\emph{обязан} знать), как правильно сконфигурировать chroot-окружение, и
-файлов, каталогов и файловых систем необходим внутри для нормальной работы
+какой минимальный набор файлов, каталогов и файловых систем необходим внутри
-демона. Уже сейчас существуют демоны, имеющие встроенную поддержку chroot.
+него для нормальной работы демона. Уже сейчас существуют демоны, имеющие
-К сожалению, в системе Fedora, установленной с параметрами по умолчанию, таких
+встроенную поддержку chroot.  К сожалению, в системе Fedora, установленной с
-демонов всего два: \href{http://avahi.org/}{Avahi} и RealtimeKit. Оба они
+параметрами по умолчанию, таких демонов всего два:
-написаны одним очень хитрым человеком ;-) (Вы можете собственноручно
+\href{http://avahi.org/}{Avahi} и RealtimeKit. Оба они написаны одним очень
-убедится в этом, выполнив команду +ls -l /proc/*/root+.)
+хитрым человеком ;-) (Вы можете собственноручно убедиться в этом, выполнив
+команду +ls -l /proc/*/root+.)
 
-Возвращаясь к тема нашего обсуждения: разумеется, systemd позволяет помещать
+Возвращаясь к теме нашего обсуждения: разумеется, systemd позволяет помещать
 выбранных демонов в chroot, и управлять ими точно так же, как и другими.
 Достаточно лишь указать параметр +RootDirectory=+ в соответствующем
 service-файле. Например:
@@ -1212,7 +1215,7 @@ RootDirectoryStartOnly=yes
 командой +systemctl start foobar.service+. Информацию о его текущем состоянии
 можно получить с помощью команды +systemctl status foobar.service+. Команды
 управления и мониторинга службы не~зависят от того, запущена ли она в chroot'е,
-или нет. Этим systemd отличается от класического SysV init.
+или нет. Этим systemd отличается от классического SysV init.
 
 Новые ядра Linux поддерживают возможность создания независимых пространств имен
 файловых систем (в дальнейшем FSNS, от <<file system namespaces>>). По
@@ -1221,7 +1224,7 @@ RootDirectoryStartOnly=yes
 характерные для chroot. systemd позволяет использовать при конфигурировании
 юнитов некоторые возможности, предоставляемые FSNS. В частности, использование
 FSNS часто является гораздо более простой и удобной альтернативой созданию
-полноценных chroot-окружений. Используя директивы +ReadOnlyDirectories=+,
+полновесных chroot-окружений. Используя директивы +ReadOnlyDirectories=+,
 +InaccessibleDirectories=+, вы можете задать ограничения по использованию
 иерархии файловых систем для заданной службы: ее корнем будет системный корневой
 каталог, однако указанные в этих директивах подкаталоги будут доступны только 
@@ -1240,35 +1243,35 @@ InaccessibleDirectories=/home
 защитить данные пользователей от потенциальных хакеров. (Подробнее об этих
 опциях можно почитать на
 \href{http://0pointer.de/public/systemd-man/systemd.exec.html}{странице
-руководства}).
+руководства}.)
 
 Фактически, FSNS по множеству параметров превосходят +chroot()+. Скорее всего,
 Avahi и ReltimeKit в ближайшем будущем перейдут с +chroot()+ к использованию
 FSNS.
 
 Итак, мы рассмотрели вопросы использования chroot для обеспечения безопасности.
-Переходим ко второму пункту: Подготовка и управление образом операционной
+Переходим ко второму пункту: подготовка и управление образом операционной
 системы при отладке, тестировании, компиляции, установке или восстановлении.
 
-chroot-окружения, по сути, весьма примитивно: они изолируют только иерархии
+chroot-окружения, по сути, весьма примитивны: они изолируют только иерархии
 файловых систем. Даже после chroot'а в определенный подкаталог, процесс
-по-прежнему имеет полный доступ к системным вызовам, может убить любой процесс
+по-прежнему имеет полный доступ к системным вызовам, может убивать процессы,
-из основной системы, и т.п. Вследствие этого, запуск полноценной ОС (или ее
+запущенные в основной системе, и т.п. Вследствие этого, запуск полноценной ОС
-части) внутри chroot'а несет угрозу для хост-системы: у гостя и хоста отличаются
+(или ее части) внутри chroot'а несет угрозу для хост-системы: у гостя и хоста
-лишь содержимое файловой системы, все остальное у них общее. Например, если вы
+отличается лишь содержимое файловой системы, все остальное у них общее.
-обновляете дистрибутив, установленный в chroot-окружении, и пост-установочный
+Например, если вы обновляете дистрибутив, установленный в chroot-окружении, и
-скрипт пакета отправляет +SIGTERM+ процессу init для его
+пост-установочный скрипт пакета отправляет +SIGTERM+ процессу init для его
-перезапуска\footnote{Прим. перев.: Во избежание путаницы отметим, что перезапуск
+перезапуска\footnote{Прим. перев.: во избежание путаницы отметим, что перезапуск
 процесса init (PID~1) <<на лету>> при получении +SIGTERM+ поддерживается только
-в systemd, в классическом SysV init такой возможности нет}, на него среагирует
+в systemd, в классическом SysV init такой возможности нет.}, на него среагирует
 именно хост-система! Кроме того, хост и chroot'нутая система будут иметь общую
 разделяемую память SysV (SysV shared memory), общие сокеты из абстрактных
 пространств имен (abstract namespace sockets) и другие элементы IPC. Для
 отладки, тестирования, компиляции, установки и восстановлении ОС не~требуется
-абсолютно безопасная изоляция, однако нужна защита от \emph{случайного}
+абсолютно неуязвимая изоляция~--- нужна лишь надежная защита от
-воздействия на ОС хоста изнутри chroot-окружения, иначе вы можете получить целый
+\emph{случайного} воздействия на ОС хоста изнутри chroot-окружения, иначе вы
-букет проблем, как минимум, от пост-инсталляционных скриптов при установке
+можете получить целый букет проблем, как минимум, от пост-инсталляционных
-пакетов в chroot-окружении.
+скриптов при установке пакетов в chroot-окружении.
 
 systemd имеет целый ряд возможностей, полезных для работы с chroot-системами:
 
@@ -1287,7 +1290,7 @@ systemd имеет целый ряд возможностей, полезных
 debootstrap/febootstrap. В этом случае возможности +systemctl+ ограничиваются
 операциями с символьными ссылками, определяющими триггеры активации юнитов, т.е.
 выполнением действий +enable+ и +disable+, не~требующих непосредственного
-взаимодействия с процессом init}.
+взаимодействия с процессом init.}.
 
 Однако, куда более интересные возможности предоставляет программа
 \href{http://0pointer.de/public/systemd-man/systemd-nspawn.html}{systemd-nspawn},
@@ -1295,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, которая позиционируется как современная альтернатива классическому
@@ -1305,7 +1308,7 @@ Linux, которая позиционируется как современна
 настроек и т.п., в то время как +systemd-nspawn+ является лишь более удобной и
 эффективной заменой команды +chroot(1)+, предназначенной прежде всего для
 развертывания, восстановления, сборки и тестирования операционных систем. Далее
-автор разъясняет свою точку зрения на этот вопрос}.
+автор разъясняет свою точку зрения на этот вопрос.}.
 +systemd-nspawn+ проста в использовании как +chroot(1)+, однако изоляция
 от хост-системы является более полной и безопасной. Всего одной командой
 вы можете загрузить внутри контейнера \emph{полноценную} ОС (на базе systemd
@@ -1362,15 +1365,15 @@ systemd уже подготовлен для работы внутри таки
 шаге вызывает не~+reboot()+, а просто +exit()+.
 
 Стоит отметить, что +systemd-nspawn+ все же не~является полноценной системой
-контейнерной виртуализации/изоляции~--- если нужно именно это, воспользуйтесь
+контейнерной виртуализации/изоляции~--- если вам нужно такое решение,
-\href{ http://lxc.sourceforge.net/}{LXC}. Этот проект использует те же самые
+воспользуйтесь \href{ http://lxc.sourceforge.net/}{LXC}. Этот проект использует
-механизмы ядра, но предоставляет куда более широкие возможности, включая
+те же самые механизмы ядра, но предоставляет куда более широкие возможности,
-виртуализацию сети. Если вам угодно, +systemd-nspawn+ как реализация контейнера
+включая виртуализацию сети. Могу предложить такую аналогию: +systemd-nspawn+ как
-похожа на GNOME~3~--- компактна и проста в использовании, опций для настройки
+реализация контейнера похожа на GNOME~3~--- компактна и проста в использовании,
-очень мало. В то время как LXC больше похож на KDE: опций для настройки больше,
+опций для настройки очень мало. В то время как LXC больше похож на KDE: опций
-чем строк кода. Я создал +systemd-nspawn+ специально для тестирования, отладки,
+для настройки больше, чем строк кода. Я создал +systemd-nspawn+ специально для
-сборки, восстановления. Именно для этих задач вам стоит ее использовать~--- она
+тестирования, отладки, сборки, восстановления. Именно для этих задач вам стоит
-неплохо с ними справляется, куда лучше, чем +chroot(1)+.
+ее использовать~--- она неплохо с ними справляется, куда лучше, чем +chroot(1)+.
 
 Что ж, пора заканчивать. Итак:
 \begin{enumerate}
@@ -1378,7 +1381,7 @@ systemd уже подготовлен для работы внутри таки
 		наилучший результат, когда оно реализовано непосредственно в
 		коде самой программы.
 	\item +ReadOnlyDirectories=+ и +InaccessibleDirectories=+ могут быть
-		удобной альтернативой созданию полноценных chroot-окружений.
+		удобной альтернативой созданию полновесных chroot-окружений.
 	\item Если вам нужно поместить в chroot-окружение какую-либо службу,
 		воспользуйтесь опцией +RootDirectory=+.
 	\item +systemd-nspawn+~--- очень неплохая штука.
@@ -1475,7 +1478,7 @@ $ systemd-analyze blame
 мы можем с этим сделать? Эта служба выполняет очень простую задачу: она ожидает,
 пока udev завершит опрос устройств, после чего завершается. Опрос же устройств
 может занимать довольно много времени. Например, в нашем случае опрос устройств
-занимает более 6~секунд из-за встроенного в компьютер 3G-модема, в котором
+занимает более 6~секунд из-за подключенного к компьютеру 3G-модема, в котором
 отсутствует SIM-карта. Этот модем очень долго отвечает на запросы udev. Опрос
 устройств является частью схемы, обеспечивающей работу ModemManager'а и
 позволяющей NetworkManager'у упростить для вас настройку 3G. Казалось бы,
@@ -1561,13 +1564,548 @@ cryptsetup, что снижение этого времени с 1 секунд
 нужно сделать так, чтобы этот каталога автоматически монтировался при загрузке,
 но процесс загрузки не~ожидал завершения работы +cryptsetup+, +fsck+ и +mount+
 для этого раздела. Как же сделать точку монтирования доступной, не~ожидая, пока
-завершится процесс монтирования? Это можно сделать, воспользовавшись магической
+завершится процесс монтирования? Этого можно достичь, воспользовавшись
-силой systemd~--- просто добавим опцию монтирования +comment=systemd.automount+
+магической силой systemd~--- просто добавим опцию монтирования
-в +/etc/fstab+. После этого, systemd будет создавать в +/home+ точку
++comment=systemd.automount+ в +/etc/fstab+. После этого, systemd будет создавать
-автоматического монтирования, и при первом же обращении к этому каталогу
+в +/home+ точку автоматического монтирования, и при первом же обращении к этому
-systemd выполнит подготовку устройства, проверку и монтирование файловой
+каталогу, если файловая система еще не~будет готова к работе, systemd подготовит
-системы.
+соответствующее устройство, проверит и смонтирует ее.
 
+После внесения изменений в +/etc/fstab+ и перезагрузки мы получаем:
+\begin{Verbatim}
+systemd[1]: Startup finished in 2s 47ms 112us (kernel) + 2s 663ms 942us (initrd)
++ 5s 540ms 522us (userspace) = 10s 251ms 576us.
+\end{Verbatim}
+
+Прекрасно! Несколькими простыми действиями мы выиграли почти семь секунд. И эти
+два изменения исправляют только две наиболее очевидные проблемы. При более
+аккуратном и детальном исследовании, обнаружится еще множество моментов, которые
+можно улучшить. Например, на другом моем компьютере, лаптопе X300 двухлетней
+давности (и даже два года назад он был не~самым быстрым на Земле), после
+небольшой доработки, время загрузки до полноценной среды GNOME
+составило около четырех секунд, и это еще не~предел совершенства.
+
++systemd-analyze blame+~--- простой и удобный инструмент для поиска медленно
+запускающихся служб, однако он обладает одним существенным недостатком: он
+не~показывает, насколько эффективно параллельный запуск снижает потерю времени
+для медленно запускающихся служб. Чтобы вы могли наглядно оценить этот фактор,
+мы подготовили команду +systemd-analyze plot+. Использовать ее очень просто:
+\begin{Verbatim}
+$ systemd-analyze plot > plot.svg
+$ eog plot.svg
+\end{Verbatim}
+
+Она создает наглядные диаграммы, показывающие моменты запуска служб и время,
+затраченное на их запуск, по отношению к другим службам. На текущий момент, она
+не~показывает явно, кто кого ожидает, но догадаться обычно несложно.
+
+Чтобы продемонстрировать эффект, порожденный двумя нашими оптимизациями,
+приведем ссылки на соответствующие графики:
+\href{http://0pointer.de/public/blame.svg}{до} и
+\href{http://0pointer.de/public/blame2.svg}{после} (для полноты описания приведем также и
+соответствующие данные +systemd-analyze blame+:
+\href{http://0pointer.de/public/blame.txt}{до} и
+\href{http://0pointer.de/public/blame2.txt}{после}).
+
+У наиболее эрудированных читателей может возникнуть вопрос: как это соотносится с
+программой \href{https://github.com/mmeeks/bootchart}{bootchart}? Действительно,
++systemd-analyze plot+ и +bootchart+ рисуют похожие графики. Однако, bootchart
+является намного более мощным инструментом~--- он детально показывает, что
+именно происходило во время загрузки, и отображает соответствующие графики
+использования процессора и ввода-вывода. +systemd-analyze plot+ оперирует более
+высокоуровневой информацией: сколько времени затратила та или иная служба во
+время запуска, и какие службы были вынуждены ее ожидать. Используя оба эти
+инструмента, вы значительно упростите себе поиск причин замедления вашей
+загрузки.
+
+Но прежде, чем вы вооружитесь описанными здесь средствами и начнете
+отправлять багрепорты авторам и сопровождающим программ, которые замедляют вашу
+загрузку, обдумайте все еще раз. Эти инструменты предоставляют вам <<сырую>>
+информацию. Постарайтесь не~ошибиться, интерпретируя ее. Например, в
+при рассмотрении приведенного выше примера я показал, что проблема была вовсе
+не~в +udev-settle.service+, и не~в опросе устройств для ModemManager'а, а в 
+неудачной реализации подсистемы хранения, требующей ожидать окончания опроса
+устройств для продолжения загрузки. Именно эту проблему и нужно исправлять.
+Поэтому постарайтесь правильно определить источник проблем. Возлагайте вину на
+тех, кто действительно виноват.
+
+Как уже говорилось выше, все три описанных здесь инструмента доступны в
+Fedora~15 <<из коробки>>.
+
+Итак, какие же выводы мы можем сделать из этой истории?
+\begin{itemize}
+	\item +systemd-analyze+~--- отличный инструмент. Фактически, это
+		встроенный профилировщик systemd.
+	\item Постарайтесь не~ошибиться, интерпретируя вывод профилировщика!
+	\item Всего два небольших изменения могут ускорить загрузку системы на
+		семь секунд.
+	\item Программное обеспечение, не~способное работать с динамически
+		меняющимся набором устройств, создает проблемы, и должно быть
+		исправлено.
+	\item Принудительное использование в стандартной установке Fedora~15
+		промышленной реализации подсистем хранения, возможно, является
+		не~самым правильным решением.
+\end{itemize}
+
+\section{Новые конфигурационные файлы}
+
+Одно из ключевых достоинств
+\href{http://www.freedesktop.org/wiki/Software/systemd}{systemd}~--- наличие
+полного набора программ, необходимых на ранних стадиях загрузки, причем эти
+программы написаны на простом, быстром, надежном и легко поддающемся
+распараллеливанию языке C. Теперь можно отказаться от <<простыней>>
+shell-скриптов, разработанных для этих задач различными дистрибутивами. Наш
+<<Проект нулевой оболочки>>\footnote{Наш девиз~--- <<Первой оболочкой,
+запускающейся при старте системы, должна быть GNOME shell>>. Формулировка
+оставляет желать лучшего, но все же неплохо передает основную идею.} увенчался
+полным успехом. Уже сейчас возможности предоставляемого нами инструментария
+покрывают практически все нужды настольных и встраиваемых систем, а также
+б\'{о}льшую часть потребностей серверов:
+\begin{itemize}
+	\item Проверка и монтирование всех файловых систем.
+	\item Обновление и активация квот на всех файловых системах.
+	\item Установка имени хоста.
+	\item Настройка сетевого интерфейса обратной петли (+lo+).
+	\item Подгрузка правил SELinux, обновление
+		меток безопасности в динамических каталогах +/run+ и +/dev+.
+	\item Регистрация в ядре дополнительных бинарных форматов (например,
+		Java, Mono, WINE) через API-файловую систему +binfmt_misc+.
+	\item Установка системной локали.
+	\item Настройка шрифта и раскладки клавиатуры в консоли.
+	\item Создание, очистка, удаление временных файлов и каталогов.
+	\item Применение предписанных в +/etc/fstab+ опций к смонтированным
+		ранее API-файловым системам.
+	\item Применение настроек +sysctl+.
+	\item Поддержка технологии упреждающего чтения (read ahead), включая
+		автоматический сбор информации.
+	\item Обновление записей в +utmp+ при включении и выключении системы.
+	\item Сохранение и восстановление затравки для генерации случайных чисел
+		(random seed).
+	\item Принудительная загрузка указанных модулей ядра.
+	\item Поддержка шифрованных дисков и разделов.
+	\item Автоматический запуск +getty+ на serial-консолях.
+	\item Взаимодействие с Plymouth.
+	\item Создание уникального идентификатора системы.
+	\item Установка часового пояса.
+\end{itemize}
+
+В стандартной установке Fedora~15 запуск shell-скриптов требуется только для
+некоторых устаревших служб, а также для подсистемы хранения данных (поддержка
+LVM, RAID и multipath). Если они вам не~нужны, вы легко можете отключить их, и
+наслаждаться загрузкой, полностью очищенной от shell-костылей (я это сделал уже
+давно). Такая загрузка является уникальной возможностью Linux-систем.
+
+Большинство перечисленных выше компонентов настраиваются через конфигурационные
+файлы в каталоге +/etc+. Некоторые из этих файлов стандартизированы для всех
+дистрибутивов, и поэтому реализация их поддержки в наших инструментах
+не~представляла особого труда. Например, это относится к файлам +/etc/fstab+,
++/etc/crypttab+, +/etc/sysctl.conf+. Однако множество других, нестандартно
+расположенных файлов и каталогов вынуждали нас добавлять в код огромное
+количество операторов +#ifdef+, чтобы обеспечить поддержку различных вариантов
+расположения конфигураций в разных дистрибутивах. Такой положение дел сильно
+усложняет жизнь нам всем, и при этом ничем не~оправдано~--- все эти файлы решают
+одни и те же задачи, но делают это немного по-разному.
+
+Чтобы улучшить ситуацию и установить единый стандарт расположения базовых
+конфигурационных файлов во всех дистрибутивах, мы заставили systemd пользоваться
+дистрибутивно-специфическими конфигурациями только в качестве \emph{резервного}
+варианта~--- основным источником информации становится определенный нами
+стандартный набор конфигурационных файлов. Разумеется, там, где это возможно, мы
+старались не~придумывать чего-то принципиально нового, а брали лучшее из
+решений, предложенных существующими дистрибутивами. Ниже приводится небольшой
+обзор этого нового набора конфигурационных файлов, поддерживаемых systemd во
+всех дистрибутивах:
+\begin{itemize}
+	\item
+		\hreftt{http://0pointer.de/public/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}:
+		конфигурация раскладки клавиатуры и шрифта для консоли.
+	\item
+		\hreftt{http://0pointer.de/public/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}:
+		каталог\footnote{Прим. перев.: для описания этого и трех
+		последующих каталогов автор пользуется термином <<drop-in
+		directory>>. Этот термин означает каталог, в который можно
+		поместить множество независимых файлов настроек, и при чтении
+		конфигурации все эти файлы будут обработаны (впрочем, часто
+		накладывается ограничение~--- обрабатываются только файлы с
+		именами, соответствующими маске, обычно +*.conf+). Такой подход
+		позволяет значительно упростить процесс как ручного, так и
+		автоматического конфигурирования различных компонентов~--- для
+		внесения изменений в настройки уже не~нужно редактировать
+		основной конфигурационный файл, достаточно лишь
+		скопировать/переместить в нужный каталог небольшой файл с
+		указанием специфичных параметров.} для перечисления модулей
+		ядра, которые нужно принудительно подгрузить при загрузке
+		(впрочем, необходимость в этом возникает достаточно редко).
+	\item
+		\hreftt{http://0pointer.de/public/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}:
+		каталог для управления настройками временных файлов (systemd
+		обеспечивает создание, очистку и удаление временных файлов и
+		каталогов, как во время загрузки, так и во время работы
+		системы).
+	\item
+		\hreftt{http://0pointer.de/public/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}:
+		стандарт для файла, обеспечивающего идентификацию дистрибутива и
+		его версии. Сейчас различные дистрибутивы используют для этого
+		разные файлы (например, +/etc/fedora-release+ в Fedora), и
+		поэтому для решения такой простой задачи, как вывод имени
+		дистрибутива, необходимо использовать базу данных, содержащую
+		перечень возможных названий файлов. Проект LSB попытался создать
+		такой инструмент~---
+		\hreftt{http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/lsbrelease.html}{lsb\_release}~---
+		однако реализация столь простой функции через скрипт на Python'е
+		является не~самым оптимальным решением. Чтобы исправить
+		сложившуюся ситуацию, мы решили перейти к единому простому
+		формату представления этой информации.
+	\item
+		\hreftt{http://0pointer.de/public/systemd-man/machine-id.html}{/etc/machine-id}:
+		файл с идентификатором данного компьютера (перекрывает
+		аналогичный идентификатор D-Bus). Гарантируется, что в любой
+		системе, использующей systemd, этот файл будет существовать и
+		содержать корректную информацию (если его нет, он автоматически
+		создается при загрузке). Мы вынесли этот файл из-под эгиды
+		D-Bus, чтобы упростить решение множества задач, требующих
+		наличия уникального и постоянного идентификатора компьютера.
+	\item
+		\hreftt{http://0pointer.de/public/systemd-man/machine-info.html}{/etc/machine-info}:
+		новый конфигурационный файл, хранящий информации о полном имени
+		(описательном) хоста (например, <<Компьютер Леннарта>>) и
+		значке, которым он будет обозначаться в графических оболочках,
+		работающих с сетью (раньше этот значок мог определяться,
+		например, файлом +/etc/favicon.png+). Данный конфигурационный
+		файл обслуживается демоном
+		\hreftt{http://www.freedesktop.org/wiki/Software/systemd/hostnamed}{systemd-hostnamed}.
+\end{itemize}
+
+Одна из важнейших для нас задач~--- убедить \emph{вас} использовать эти новые
+конфигурационные файлы в ваших инструментах для настройки системы. Если ваши
+конфигурационные фронтенды будут использовать новые файлы, а не~их старые
+аналоги, это значительно облегчит портирование таких фронтендов между
+дистрибутивами, и вы внесете свой вклад в стандартизацию 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}{подготовил} соответствующие пакеты,
+однако его инициатива не~встретила поддержки среди менеджеров Canonical. На
+момент написания этих строк (май 2011 года) проект остается заброшенным уже пять
+месяцев (с середины декабря 2010~г.).}. В этом есть что-то от <<пролемы курицы и
+яйца>>: стандарт становится начинает работать как стандарт только тогда, когда
+ему начинают следовать. В будущем мы намерены аккуратно форсировать процесс
+перехода на новые конфигурационные файлы: поддержка старых файлов будет удалена
+из systemd. Разумеется, этот процесс будет идти медленно, шаг за шагом. Но
+конечной его целью является переход всех дистрибутивов на единый набор базовых
+конфигурационных файлов.
+
+Многие из этих файлов используются не~только программами для настройки системы,
+но и апстримными проектами. Например, мы предлагаем проектам Mono, Java, WINE и
+другим помещать конфигурацию для регистрации своих бинарных форматов в
++/etc/binfmt.d/+ средствами их собственной сборочной системы. Специфичные для
+дистрибутивов механизмы поддержки бинарных форматов больше не~нужны, и ваш
+проект будет работать одинаково хорошо во всех дистрибутивах. Аналогичное
+предложение мы обращаем и ко всем разработчикам программ, которым требуется
+автоматическое создание/очистка временных файлов и каталогов,
+например, в каталоге +/run+ (\href{http://lwn.net/Articles/436012/}{ранее
+известном} как +/var/run+). Таким проектам достаточно просто поместить
+соответствующий конфигурационный файл в +/etc/tmpfiles.d/+, тоже средствами
+собственной сборочной системы. Помимо прочего, подобный подход позволит
+увеличить скорость загрузки, так как, в отличие от SysV, не~требует множества
+shell-скриптов, выполняющих тривиальные задачи (регистрация бинарных форматов,
+удаление/создание временных файлов/каталогов и т.п.). И пример того случая,
+когда апстримная поддержка стандартной конфигурации дала бы огромные
+преимущества~--- X11 (и его аналоги) могли бы устанавливать раскладку клавиатуры
+на основании данных из +/etc/vconsole.conf+.
+
+Разумеется, я понимаю, что отнюдь не~всех полностью устроят выбранные нами имена
+и форматы конфигурационных файлов. Но нам все же нужно было что-то выбрать, и мы
+выбрали то, что должно устроить большинство людей. Форматы конфигурационных
+файлов максимально просты, и их можно легко читать и записывать даже из
+shell-скриптов. Да, +/etc/bikeshed.conf+ могло бы быть неплохим именем
+для файла конфигурации!\footnote{Прим. перев.: здесь автор намекает на
+\href{http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality}{Паркинсоновский
+Закон Тривиальности}, который гласит, что самые жаркие споры возникают вокруг
+наиболее простых вопросов. В частности, в качестве примера Паркинсон приводит
+обсуждение строительства атомной электростанции и гаража для велосипедов (bike
+shed)~--- если первое из этих решений принимается довольно быстро, то вокруг
+второго разгорается множество дискуссий по самым разным аспектам.}
+
+\textbf{Помогите нам стандартизировать Linux! Используйте новые конфигурационные
+файлы! Поддерживайте их в апстриме, поддерживайте их во всех дистрибутивах!}
+
+Да, и если у вас возникнет такой вопрос: да, все эти файлы так или иначе
+обсуждались с разными разработчиками из различных дистрибутивов. И некоторые из
+этих разработчиков планируют обеспечить поддержку новой конфигурации даже в
+системах без 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-скриптами, содержащими,
+главным образом, определения переменных. Большинство файлов из этих каталогов
+включаются в одноименные скриптами SysV init. Этот принцип отражен в
+\href{http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit}{Debian
+Policy Manual (раздел 9.3.2)} и в
+\href{http://fedoraproject.org/wiki/Packaging:SysVInitScript}{Fedora Packaging
+Guidelines}, однако в обоих этих дистрибутивах иногда встречаются файлы,
+не~соответствующие такой схеме, например, не~имеющие соответствующего
+init-скрипта, или даже сами не~являющиеся скриптами.
+
+Но почему вообще появились эти каталоги? Чтобы ответить на этот вопрос,
+обратимся к истории развития концепции SysV init-скриптов. Исторически, они
+располагаются в каталоге под названием +/etc/rc.d/init.d+ (или что-то похожее).
+Отметим, что каталог +/etc+ вообще-то предназначен для хранения файлов
+конфигурации, а не~исполняемого кода (в частности, скриптов). Однако, в начале
+своей истории, init-скрипты рассматривались именно как файлы конфигурации,
+и редактирование их администратором было общепринятой практикой. Но со временем,
+по мере роста и усложнения этих скриптов, их стали рассматривать уже не~как
+файлы конфигурации, а как некие программы. Чтобы упростить их настройку и
+обеспечить безопасность процесса обновления, настройки были вынесены в отдельные
+файлы, загружаемые при работе init-скриптов.
+
+Попробуем составить некоторое представление о настройках, которые можно сделать
+через эти файлы. Вот краткий неполный список различных параметров, которые могут
+быть заданы через переменные окружения в таких файлах (составлен мною по
+результатам исследования соответствующих каталогов в Fedora и Debian):
+\begin{itemize}
+	\item Дополнительные параметры командной строки для бинарника демона.
+	\item Настройки локали для демона.
+	\item Тайм-аут остановки для демона.
+	\item Режим остановки для демона.
+	\item Системные настройки, например, системная локаль, часовой пояс,
+		параметры клавиатуры для консоли.
+	\item Избыточные информация о системных настройках, например, указание,
+		установлены ли аппаратные часы по Гринвичу или по местному
+		времени.
+	\item Списки правил брандмауэра, не~являются скриптом (!).
+	\item Привязки к процессорным ядрам для демона.
+	\item Настройки, не~относящиеся к процессу загрузки, например,
+		информация по установке пакетов с новыми ядрами, конфигурация
+		nspluginwrapper, разрешение на выполнение
+		предварительного связывания (prelinking) библиотек.
+	\item Указание, нужно ли запускать данную службу или нет.
+	\item Настройки сети.
+	\item Перечень модулей ядра, которые должны быть подгружены
+		принудительно.
+	\item Нужно ли отключать питание компьютера при остановке системы
+		(+poweroff+) или нет (+halt+).
+	\item Права доступа для файлов устройств (!).
+	\item Описание соответствующей SysV службы.
+	\item Идентификатор пользователя/группы, значение umask для демона.
+	\item Ограничения по ресурсам для демона.
+	\item Приоритет OOM killer'а для демона.
+\end{itemize}
+
+А теперь давайте ответим на вопрос: что плохого в +/etc/sysconfig+
+(+/etc/default+) и почему этим каталогам нет места в мире systemd?
+\begin{itemize}
+	\item Прежде всего, утрачены основная цель и смысл существования этих
+		каталогов: файлы конфигурации юнитов systemd не~являются
+		программами, в отличие от init-скриптов SysV. Эти файлы
+		представляют собой простые, декларативные описания конкретных
+		задач и функций, и обычно содержат не~более шести строк. Они
+		легко могут быть сгенерированы и проанализованы без
+		использования Bourne shell. Их легко читать и понимать. Кроме
+		того, их легко модифицировать: достаточно скопировать их из
+		+/lib/systemd/system+ в +/etc/systemd/system+, после чего внести
+		необходимые изменения в скопированный файл. При этом можно быть
+		уверенным, что изменения не~будут затерты пакетным менеджером.
+		Изначальная причина появления обсуждаемых каталогов~---
+		необходимость разделять код и параметры конфигурации~--- больше
+		не~существует, так как файлы описания юнитов не~являются кодом.
+		Проще говоря, обсуждаемые каталоги пытаются решить проблему,
+		которой уже не~существует.
+	\item Обсуждаемые каталоги и файлы в них очень сильно привязаны к
+		специфике дистрибутивов. Мы же планируем, используя systemd,
+		способствовать стандартизации и унификации дистрибутивов. В
+		частности, одним из факторов такой стандартизации является
+		рекомендация распространять соответствующие файлы конфигурации
+		юнитов сразу с апстримным продуктом, а не~возлагать эту работу
+		на создателей пакетов, как это делалась во времена SysV.
+		Так как расположение обсуждаемых каталогов и настраиваемые через
+		них параметры сильно отличаются от дистрибутива к дистрибутиву,
+		пытаться поддерживать их в апстримных файлах конфигурации юнитов
+		просто бессмысленно. Хранение конфигурации в обсуждаемых
+		каталогов~--- один из факторов, превращающих Linux в зоопарк
+		несовместимых решений.
+	\item Большинство настроек, задаваемых через эти каталоги, являются
+		избыточными в мире systemd. Например, различные службы позволяют
+		задать таким методом параметры исполнения процесса, в частности,
+		идентификатор пользователя/группы, ограничения ресурсов,
+		привязки к ядрам CPU, приоритет OOM killer'а. Однако, эти
+		настройки поддерживаются лишь некоторыми init-скриптами, причем
+		одна и та же настройка в различных скриптах может называться
+		по-разному. С другой стороны, в мире systemd, все эти настройки
+		доступны для всех служб без исключения, и всегда задаются
+		одинаково, через одни и те же параметры конфигурационных файлов.
+	\item Файлы конфигурации юнитов имеют множество удобных и простых в
+		использовании настроек среды исполнения процесса, гораздо
+		больше, чем могут предоставить файлы из +/etc/sysconfig+.
+	\item Необходимость в некоторых из этих настроек весьма сомнительна.
+		Например, возьмем вышеупомянутую возможность задавать
+		идентификатор пользователя/группы для процесса. Эту задачу
+		должен решать разработчик ПО или дистрибутива. Вмешательство
+		администратора в эту настройку, как правило, лишено смысла~---
+		только разработчик располагает всей информацией,
+		позволяющий предотвратить конфликты идентификаторов и имен
+		пользователей и групп.
+	\item Формат файлов, используемых для сохранения настроек, плохо
+		подходит для данной задачи. Так как эти файлы, как правило,
+		являются включаемыми shell-скриптами, ошибки при их чтении очень
+		трудно отследить. Например, ошибка в имени переменной приведет к
+		тому, что переменная не~будет изменена, однако никакого
+		предупреждения при этом не~выводится.
+	\item Кроме того, такая организация не~исключает влияния
+		конфигурационных параметров на среду исполнения: например,
+		изменение перменных +IFS+ и +LANG+ может существенно повлиять на
+		результат интерпретации init-скрипта.
+	\item Интерпретация этих файлов требует запуска еще одного экземпляра
+		оболочки, что приводит к задержкам при загрузке\footnote{Прим.
+		перев.: Здесь автор несколько заблуждается. Скрипты, включенные
+		через директиву +source+, исполняются тем же экземпляром
+		оболочки, что и вызвавший их скрипт.}.
+	\item Файлы из +/etc/sysconfig+ часто пытаются использовать в качетсве
+		суррогатной замены файлов конфигурации для тех демонов, которые
+		не~имеют встроенной поддержки конфигурационных файлов. В
+		частности, вводятся специальные переменные, позволяющие задать
+		аргументы командной строки, используемые при запуске демона.
+		Встроенная поддержка конфигурационных файлов является более
+		удобной альтернативой такому подходу, ведь глядя на ключи
+		<<+-k+>>, <<+-a+>>, <<+-f+>>, трудно догадаться об их
+		назначении. Очень часто, из-за ограниченности словаря, на
+		различных демонов одни и те же ключи действуют совершенно
+		по-разному. (Для одного демона ключ <<+-f+>> содержит указание
+		демонизироваться при запуске, в то время как для другого эта
+		опция действует прямо противоположным образом.) В отличие от
+		конфигурационных файлов, строка запуска не~может включать
+		полноценных комментариев.
+	\item Некоторые из настроек, задаваемых в +/etc/sysconfig+, являются
+		полностью избыточными. Например, во многие дистрибутивах
+		подобным методом указывается, установлены ли аппаратные часы
+		компьютера по Гринвичу, или по местному времени. Однако эта же
+		настройка задается третьей строкой файла +/etc/adjtime+,
+		поддерживаемого во всех дистрибутивах. Использование
+		избыточного и не~стандартизированного параметра конфигурации
+		только добавляет путаницу и не~несет никакой пользы.
+	\item Многие файлы настроек из +/etc/sysconfig+ позволяют отключать
+		запуск соответствующей службы. Однако эта операция уже
+		поддерживается штатно для всех служб, через команды
+		+systemctl enable+/+disable+ (или +chkconfig on+/+off+).
+		Добавление дополнительного уровня настройки не~приносит никакой
+		пользы и лишь усложняет работу администратора.
+	\item Что списка принудительно загружаемых модулей ядра: в настоящее
+		время существуют куда более удобные пути для автоматической
+		подгрузки модулей при загрузке системы. Например, многие модули
+		+udev+ подгружает автоматически, при обнаружении
+		соответствующего оборудования. Этот же принцип распространяется
+		на ACPI и другие высокоуровневые технологии. Одно из немногих
+		ислючений из этого правила~--- к сожалению, в настоящее время
+		не~поддерживается автоматическая загрузка модулей на основании
+		информации о возможностях процессора, однако это будет
+		исправлено в ближайшем будущем. В случае, если нужный вам модуль
+		ядра все же не~может быть подгружен автоматически, все равно 
+		существует гораздо более удобные методы указать его
+		принудительную подгрузку~--- например, создав соответствующий
+		файл в каталоге
+		\hreftt{http://0pointer.de/public/systemd-man/modules-load.d.html}{/etc/modules-load.d/}
+		(стандартный метод настройки принудительной подгрузки модулей).
+	\item И наконец, хотелось бы отметить, что каталог +/etc+ определен как
+		место для хранения системных настроек (<<Host-specific system
+		configuration>>, согласно FHS). Наличие внутри него подкаталога
+		+sysconfig+, который тоже содержит системную конфигурацию,
+		является очевидно избыточным.
+\end{itemize}
+
+Что же можно предложить в качестве современной, совместимой с systemd
+альтернативы этим каталогам? Ниже приведен список советов, как поступить с тем
+или иным параметром конфигурации:
+\begin{itemize}
+	\item Попробуйте просто отказаться от них. Если они полностью избыточны (например,
+		настройка аппаратных часов на Гринвич/местное время), то убрать
+		их будет довольно легко (если не~рассматривать вопросы
+		обеспечения совместимости). Если аналогичные по смыслу опции
+		штатно поддерживаются systemd, нет никакого смысла дублировать
+		их где-то еще. (Перечень опций, которые можно задать для любой
+		службы, приведен на страницах справки
+		\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}
+		и
+		\href{http://0pointer.de/public/systemd-man/systemd.service.html}{systemd.service(5)}.)
+		Если же ваша настройка просто добавляет еще один уровень
+		отключения запуска службы, откажитесь от нее, чтобы не~плодить
+		лишние сущности.
+	\item Найдите для них более подходящее место. Например, в случае с
+		некоторыми общесистемными настройками (такими, как локаль или
+		часовой пояс), мы надеемся аккуратно подтолкнуть дистрибутивы в
+		правильно направлении (см. предыдущий эпизод).
+	\item Добавьте их поддержку в штатную систему настройки демона через
+		собственные файлы конфигурации. К счастью, большинство служб,
+		работающих в Linux, являются свободным программным обеспечением,
+		так что сделать это довольно просто.
+\end{itemize}
+
+Существует лишь одна причина поддерживать эти файлы еще некоторое
+время: необходимо обеспечить совместимость при обновлении. Тем не~менее, в новых
+пакетах от этих файлов лучше отказаться.
+
+Если требование совместимости критично, вы можете задейстовать эти
+конфигурационные файлы даже в том случае, если настраиваете службы через
+штатные unit-файлы systemd. Если ваш файл из +sysconfig+ содержит лишь
+определения переменных, можно воспользоваться опцией
++EnvironmentFile=-/etc/sysconfig/foobar+ (подробнее об этой опции см.
+\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}),
+которая позволит определить соответствующие переменные окружения, которые будут
+использованы при запуске службы. Если же для задания настроек вам необходим
+полноценный язык программирования, вы можете им воспользоваться. Например,
+создайте в +/usr/lib/<your package>/+ простой скрипт, который включает
+соответствующие файлы, а затем запускает бинарник демона через +exec+. После
+чего просто укажите этот скрипт в опции +ExecStart=+ вместо бинарника демона.
 
 \end{document}