diff --git a/s4a.tex b/s4a.tex index 7982b5b..7331975 100644 --- a/s4a.tex +++ b/s4a.tex @@ -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,8 +1993,8 @@ init-скрипта, или даже сами не~являющиеся скри Например, возьмем вышеупомянутую возможность задавать идентификатор пользователя/группы для процесса. Эту задачу должен решать разработчик ПО или дистрибутива. Вмешательство - администратора в эту настройку, как правило, лишено смысла~--- - только разработчик располагает всей информацией, + администратора в данную настройку, как правило, лишено + смысла~--- только разработчик располагает всей информацией, позволяющий предотвратить конфликты идентификаторов и имен пользователей и групп. \item Формат файлов, используемых для сохранения настроек, плохо @@ -2004,24 +2005,24 @@ init-скрипта, или даже сами не~являющиеся скри предупреждения при этом не~выводится. \item Кроме того, такая организация не~исключает влияния конфигурационных параметров на среду исполнения: например, - изменение перменных +IFS+ и +LANG+ может существенно повлиять на - результат интерпретации init-скрипта. + изменение переменных +IFS+ и +LANG+ может существенно повлиять + на результат интерпретации init-скрипта. \item Интерпретация этих файлов требует запуска еще одного экземпляра оболочки, что приводит к задержкам при загрузке\footnote{Прим. перев.: Здесь автор несколько заблуждается. Скрипты, включенные через директиву +source+, исполняются тем же экземпляром оболочки, что и вызвавший их скрипт.}. - \item Файлы из +/etc/sysconfig+ часто пытаются использовать в качетсве + \item Файлы из +/etc/sysconfig+ часто пытаются использовать в качестве суррогатной замены файлов конфигурации для тех демонов, которые не~имеют встроенной поддержки конфигурационных файлов. В частности, вводятся специальные переменные, позволяющие задать аргументы командной строки, используемые при запуске демона. Встроенная поддержка конфигурационных файлов является более - удобной альтернативой такому подходу, ведь глядя на ключи + удобной альтернативой такому подходу, ведь, глядя на ключи <<+-k+>>, <<+-a+>>, <<+-f+>>, трудно догадаться об их назначении. Очень часто, из-за ограниченности словаря, на различных демонов одни и те же ключи действуют совершенно - по-разному. (Для одного демона ключ <<+-f+>> содержит указание + по-разному (для одного демона ключ <<+-f+>> содержит указание демонизироваться при запуске, в то время как для другого эта опция действует прямо противоположным образом.) В отличие от конфигурационных файлов, строка запуска не~может включать @@ -2040,20 +2041,20 @@ init-скрипта, или даже сами не~являющиеся скри +systemctl enable+/+disable+ (или +chkconfig on+/+off+). Добавление дополнительного уровня настройки не~приносит никакой пользы и лишь усложняет работу администратора. - \item Что списка принудительно загружаемых модулей ядра: в настоящее - время существуют куда более удобные пути для автоматической - подгрузки модулей при загрузке системы. Например, многие модули - +udev+ подгружает автоматически, при обнаружении - соответствующего оборудования. Этот же принцип распространяется - на ACPI и другие высокоуровневые технологии. Одно из немногих - ислючений из этого правила~--- к сожалению, в настоящее время - не~поддерживается автоматическая загрузка модулей на основании - информации о возможностях процессора, однако это будет - исправлено в ближайшем будущем. В случае, если нужный вам модуль - ядра все же не~может быть подгружен автоматически, все равно - существует гораздо более удобные методы указать его - принудительную подгрузку~--- например, создав соответствующий - файл в каталоге + \item Что касается списка принудительно загружаемых модулей ядра~--- в + настоящее время существуют куда более удобные пути для + автоматической подгрузки модулей при загрузке системы. Например, + многие модули автоматически подгружаются +udev+'ом при + обнаружении соответствующего оборудования. Этот же принцип + распространяется на ACPI и другие высокоуровневые технологии. + Одно из немногих исключений из этого правила~--- к сожалению, в + настоящее время не~поддерживается автоматическая загрузка + модулей на основании информации о возможностях процессора, + однако это будет исправлено в ближайшем будущем. В случае, если + нужный вам модуль ядра все же не~может быть подгружен + автоматически, все равно существует гораздо более удобные методы + указать его принудительную подгрузку~--- например, создав + соответствующий файл в каталоге \hreftt{http://0pointer.de/public/systemd-man/modules-load.d.html}{/etc/modules-load.d/} (стандартный метод настройки принудительной подгрузки модулей). \item И наконец, хотелось бы отметить, что каталог +/etc+ определен как @@ -2064,22 +2065,23 @@ init-скрипта, или даже сами не~являющиеся скри \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 Найдите для них более подходящее место. Например, в случае с некоторыми общесистемными настройками (такими, как локаль или часовой пояс), мы надеемся аккуратно подтолкнуть дистрибутивы в @@ -2091,21 +2093,22 @@ init-скрипта, или даже сами не~являющиеся скри \end{itemize} Существует лишь одна причина поддерживать эти файлы еще некоторое -время: необходимо обеспечить совместимость при обновлении. Тем не~менее, в новых -пакетах от этих файлов лучше отказаться. +время: необходимо обеспечить совместимость при обновлении. Тем не~менее, как +минимум в новых пакетах, от этих файлов лучше отказаться. -Если требование совместимости критично, вы можете задейстовать эти +Если требование совместимости критично, вы можете задействовать эти конфигурационные файлы даже в том случае, если настраиваете службы через штатные unit-файлы systemd. Если ваш файл из +sysconfig+ содержит лишь определения переменных, можно воспользоваться опцией +EnvironmentFile=-/etc/sysconfig/foobar+ (подробнее об этой опции см. \href{http://0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}), -которая позволит определить соответствующие переменные окружения, которые будут -использованы при запуске службы. Если же для задания настроек вам необходим -полноценный язык программирования, вы можете им воспользоваться. Например, -создайте в +/usr/lib//+ простой скрипт, который включает -соответствующие файлы, а затем запускает бинарник демона через +exec+. После -чего просто укажите этот скрипт в опции +ExecStart=+ вместо бинарника демона. +позволяющей прочитать из файла набор переменных окружения, который будет +установлен при запуске службы. Если же для задания настроек вам необходим +полноценный язык программирования~--- ничто не~мешает им воспользоваться. +Например, вы можете создайть в +/usr/lib//+ простой скрипт, +который включает соответствующие файлы, а затем запускает бинарник демона через ++exec+. После чего достаточно просто указать этот скрипт в опции +ExecStart=+ +вместо бинарника демона. \end{document}