Version v7.5 (2011-09-30 01:23) [AUTO]

s4a.tex

@@ -1857,6 +1857,259 @@ shed)~--- если первое из этих решений принимает
 этих разработчиков планируют обеспечить поддержку новой конфигурации даже в
 системах без 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}
 
 vim:ft=tex:tw=80:spell:spelllang=ru