Compare commits

...

3 Commits
v7.2 ... v7.5

Author SHA1 Message Date
nnz1024
adf3ff6581 Version v7.5 (2011-09-30 01:23) [AUTO] 2017-08-17 23:05:38 +03:00
nnz1024
61330d78c8 Version v7.4 (2011-08-24 16:13) [AUTO] 2017-08-17 23:05:38 +03:00
nnz1024
b853acbc75 Version v7.3 (2011-08-19 19:26) [AUTO] 2017-08-17 23:05:38 +03:00

170
s4a.tex
View File

@@ -1864,8 +1864,8 @@ shed)~--- если первое из этих решений принимает
Во многих других дистрибутивах также присутствуют каталоги похожего назначения.
Связанные с ними вопросы неоднократно появляются в дискуссиях пользователей и
разработчиков systemd. В этой статье мне хотелось бы рассказать, что я, как
разработчик systemd, думаю об этих каталогах, и пояснить, почему я считаю
необходимым от них отказаться. Стоит отметить, что это мое личное мнение, и оно
разработчик systemd, думаю об этих каталогах, и пояснить, почему, на мой взгляд,
от них лучше отказаться. Стоит отметить, что это мое личное мнение, и оно
может не~совпадать с позицией проекта Fedora или моего работодателя.
Начнем с небольшого исторического экскурса. Каталог +/etc/sysconfig+ появился в
@@ -1875,8 +1875,8 @@ shed)~--- если первое из этих решений принимает
+/etc/default+. Многие дистрибутивы используют такие каталоги, называя их
по-разному. Они имеются даже в некоторых ОС семейства Unix. (Например, в SCO.
Если эта тема вас заинтересовала~--- рекомендую обратиться к вашему знакомому
ветерану Unix, он расскажет подробнее и интереснее, чем я.) Несмотря на то,
что подобные каталоги широко используются в Linux и Unix, они совершенно
ветерану Unix, он расскажет гораздо подробнее и интереснее, чем я.) Несмотря на
то, что подобные каталоги широко используются в Linux и Unix, они совершенно
не~стандартизированы~--- ни в POSIX, ни в LSB/FHS, и результате мы имеем целый
зоопарк их различных реализаций в разных дистрибутивах.
@@ -1890,7 +1890,7 @@ shell это соответствует оператору-точке <<+.+>>.
окружения, определенные во включаемом коде. Как правило, код для включения
не~содержит shebang'а (+#!/bin/sh+ в начале файла).} shell-скриптами, содержащими,
главным образом, определения переменных. Большинство файлов из этих каталогов
включаются в одноименные скриптами SysV init. Этот принцип отражен в
включаются в одноименные скрипты 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
@@ -1899,33 +1899,33 @@ Guidelines}, однако в обоих этих дистрибутивах ин
init-скрипта, или даже сами не~являющиеся скриптами.
Но почему вообще появились эти каталоги? Чтобы ответить на этот вопрос,
обратимся к истории развития концепции SysV init-скриптов. Исторически, они
располагаются в каталоге под названием +/etc/rc.d/init.d+ (или что-то похожее).
Отметим, что каталог +/etc+ вообще-то предназначен для хранения файлов
конфигурации, а не~исполняемого кода (в частности, скриптов). Однако, в начале
своей истории, init-скрипты рассматривались именно как файлы конфигурации,
и редактирование их администратором было общепринятой практикой. Но со временем,
по мере роста и усложнения этих скриптов, их стали рассматривать уже не~как
файлы конфигурации, а как некие программы. Чтобы упростить их настройку и
обеспечить безопасность процесса обновления, настройки были вынесены в отдельные
файлы, загружаемые при работе init-скриптов.
обратимся к истории развития концепции SysV init-скриптов. Исторически,
сложилось так, что они располагаются в каталоге под названием +/etc/rc.d/init.d+
(или что-то похожее). Отметим, что каталог +/etc+ вообще-то предназначен для
хранения файлов конфигурации, а не~исполняемого кода (в частности, скриптов).
Однако, в начале своей истории, init-скрипты рассматривались именно как файлы
конфигурации, и редактирование их администратором было общепринятой практикой.
Но со временем, по мере роста и усложнения этих скриптов, их стали рассматривать
уже не~как файлы конфигурации, а как некие программы. Чтобы упростить их
настройку и обеспечить безопасность процесса обновления, настройки были вынесены
в отдельные файлы, загружаемые при работе init-скриптов.
Попробуем составить некоторое представление о настройках, которые можно сделать
через эти файлы. Вот краткий неполный список различных параметров, которые могут
быть заданы через переменные окружения в таких файлах (составлен мною по
через эти файлы. Вот краткий и неполный список различных параметров, которые
могут быть заданы через переменные окружения в таких файлах (составлен мною по
результатам исследования соответствующих каталогов в Fedora и Debian):
\begin{itemize}
\item Дополнительные параметры командной строки для бинарника демона.
\item Настройки локали для демона.
\item Тайм-аут остановки для демона.
\item Режим остановки для демона.
\item Системные настройки, например, системная локаль, часовой пояс,
\item Общесистемные настройки, например, системная локаль, часовой пояс,
параметры клавиатуры для консоли.
\item Избыточные информация о системных настройках, например, указание,
установлены ли аппаратные часы по Гринвичу или по местному
времени.
\item Списки правил брандмауэра, не~являются скриптом (!).
\item Привязки к процессорным ядрам для демона.
\item Списки правил брандмауэра, не~являются скриптами (!).
\item Привязка к процессорным ядрам для демона.
\item Настройки, не~относящиеся к процессу загрузки, например,
информация по установке пакетов с новыми ядрами, конфигурация
nspluginwrapper, разрешение на выполнение
@@ -1943,8 +1943,9 @@ init-скрипта, или даже сами не~являющиеся скри
\item Приоритет OOM killer'а для демона.
\end{itemize}
А теперь давайте ответим на вопрос: что плохого в +/etc/sysconfig+
(+/etc/default+) и почему этим каталогам нет места в мире systemd?
А теперь давайте ответим на вопрос: что же такого неправильного в
+/etc/sysconfig+ (+/etc/default+) и почему этим каталогам нет места в мире
systemd?
\begin{itemize}
\item Прежде всего, утрачены основная цель и смысл существования этих
каталогов: файлы конфигурации юнитов systemd не~являются
@@ -1955,12 +1956,12 @@ init-скрипта, или даже сами не~являющиеся скри
использования Bourne shell. Их легко читать и понимать. Кроме
того, их легко модифицировать: достаточно скопировать их из
+/lib/systemd/system+ в +/etc/systemd/system+, после чего внести
необходимые изменения в скопированный файл. При этом можно быть
уверенным, что изменения не~будут затерты пакетным менеджером.
необходимые изменения в скопированный файл (при этом можно быть
уверенным, что изменения не~будут затерты пакетным менеджером).
Изначальная причина появления обсуждаемых каталогов~---
необходимость разделять код и параметры конфигурации~--- больше
не~существует, так как файлы описания юнитов не~являются кодом.
Проще говоря, обсуждаемые каталоги пытаются решить проблему,
Проще говоря, обсуждаемые каталоги являются решением проблемы,
которой уже не~существует.
\item Обсуждаемые каталоги и файлы в них очень сильно привязаны к
специфике дистрибутивов. Мы же планируем, используя systemd,
@@ -1972,8 +1973,8 @@ init-скрипта, или даже сами не~являющиеся скри
Так как расположение обсуждаемых каталогов и настраиваемые через
них параметры сильно отличаются от дистрибутива к дистрибутиву,
пытаться поддерживать их в апстримных файлах конфигурации юнитов
просто бессмысленно. Хранение конфигурации в обсуждаемых
каталогов~--- один из факторов, превращающих Linux в зоопарк
просто бессмысленно. Хранение параметров конфигурации в этих
каталогах~--- один из факторов, превращающих Linux в зоопарк
несовместимых решений.
\item Большинство настроек, задаваемых через эти каталоги, являются
избыточными в мире systemd. Например, различные службы позволяют
@@ -1992,12 +1993,123 @@ init-скрипта, или даже сами не~являющиеся скри
Например, возьмем вышеупомянутую возможность задавать
идентификатор пользователя/группы для процесса. Эту задачу
должен решать разработчик ПО или дистрибутива. Вмешательство
администратора в эту настройку, как правило, лишено смысла~---
только разработчик располагает всей информацией,
администратора в данную настройку, как правило, лишено
смысла~--- только разработчик располагает всей информацией,
позволяющий предотвратить конфликты идентификаторов и имен
пользователей и групп.
\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