9. О судьбе /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, и результате мы имеем целый зоопарк их различных реализаций в разных дистрибутивах. Назначение этих каталогов определено весьма расплывчато. Абсолютное большинство находящихся в них файлов являются включаемыми shell-скриптами, содержащими, главным образом, определения переменных. Большинство файлов из этих каталогов включаются в одноименные скрипты SysV init. Данный принцип отражен в Debian Policy Manual (раздел 9.3.2) и в Fedora Packaging Guidelines, однако в обоих дистрибутивах иногда встречаются файлы, не соответствующие описанной схеме, например, не имеющие соответствующего init-скрипта, или даже сами не являющиеся скриптами. Но почему вообще появились эти каталоги? Чтобы ответить на такой вопрос, обратимся к истории развития концепции SysV init-скриптов. Исторически, сложилось так, что они располагаются в каталоге под названием /etc/rc.d/init.d (или что-то похожее). Отметим, что каталог /etc вообще-то предназначен для хранения файлов конфигурации, а не исполняемого кода (в частности, скриптов). Однако, в начале своей истории, init-скрипты рассматривались именно как файлы конфигурации, и редактирование их администратором было общепринятой практикой. Но со временем, по мере роста и усложнения этих скриптов, их стали рассматривать уже не как файлы конфигурации, а как некие программы. Чтобы упростить их настройку и обеспечить безопасность процесса обновления, настройки были вынесены в отдельные файлы, загружаемые при работе init-скриптов. Попробуем составить некоторое представление о настройках, которые можно сделать через эти файлы. Вот краткий и неполный список различных параметров, которые могут быть заданы через переменные окружения в таких файлах (составлен мною по результатам исследования соответствующих каталогов в Fedora и Debian):

* Дополнительные параметры командной строки для бинарника демона.
* Настройки локали для демона.
* Тайм-аут остановки для демона.
* Режим остановки для демона.
* Общесистемные настройки, например, системная локаль, часовой пояс, параметры клавиатуры для консоли.
* Избыточная информация о системных настройках, например, указание, установлены ли аппаратные часы по Гринвичу или по местному времени.
* Списки правил брандмауэра, не являются скриптами (!).
* Привязка к процессорным ядрам для демона.
* Настройки, не относящиеся к процессу загрузки, например, информация по установке пакетов с новыми ядрами, конфигурация nspluginwrapper, разрешение на выполнение предварительного связывания (prelinking) библиотек.
* Указание, нужно ли запускать данную службу или нет.
* Настройки сети.
* Перечень модулей ядра, которые должны быть подгружены принудительно.
* Нужно ли отключать питание компьютера при остановке системы (poweroff) или нет (halt).
* Права доступа для файлов устройств (!).
* Описание соответствующей SysV службы.
* Идентификатор пользователя/группы, значение umask для демона.
* Ограничения по ресурсам для демона.
* Приоритет OOM killer’а для демона.

А теперь давайте ответим на вопрос: что же такого неправильного в /etc/sysconfig (/etc/default) и почему этим каталогам нет места в мире systemd?

* Прежде всего, утрачены основная цель и смысл существования таких каталогов: файлы конфигурации юнитов systemd не являются программами, в отличие от init-скриптов SysV. Эти файлы представляют собой простые, декларативные описания конкретных задач и функций, и обычно содержат не более шести строк. Они легко могут быть сгенерированы и проанализованы без использования Bourne shell. Их легко читать и понимать. Кроме того, их легко модифицировать: достаточно скопировать файл из /lib/systemd/system в /etc/systemd/system, после чего внести в созданную копию необходимые изменения (при этом можно быть уверенным, что изменения не будут затерты пакетным менеджером). Изначальная причина появления обсуждаемых каталогов — необходимость разделять код и параметры конфигурации — больше не существует, так как файлы описания юнитов не являются кодом. Проще говоря, обсуждаемые каталоги являются решением проблемы, которой уже не существует.

* Обсуждаемые каталоги и файлы в них очень сильно привязаны к специфике дистрибутивов. Мы же планируем, используя systemd, способствовать стандартизации и унификации дистрибутивов. В частности, одним из факторов такой стандартизации является рекомендация распространять соответствующие файлы конфигурации юнитов сразу с апстримным продуктом, а не возлагать эту работу на создателей пакетов, как это делалась во времена SysV. Так как расположение обсуждаемых каталогов и настраиваемые через них параметры сильно отличаются от дистрибутива к дистрибутиву, пытаться поддерживать их в апстримных файлах конфигурации юнитов просто бессмысленно. Хранение параметров конфигурации в этих каталогах — один из факторов, превращающих Linux в зоопарк несовместимых решений.

* Большинство настроек, задаваемых через эти каталоги, являются избыточными в мире systemd. Например, различные службы позволяют задать таким методом параметры исполнения процесса, в частности, идентификатор пользователя/группы, ограничения ресурсов, привязки к ядрам CPU, приоритет OOM killer’а. Однако, эти настройки поддерживаются лишь некоторыми init-скриптами, причем одна и та же настройка в различных скриптах может называться по-разному. С другой стороны, в мире systemd, все эти настройки доступны для всех служб без исключения, и всегда задаются одинаково, через одни и те же параметры конфигурационных файлов.

* Файлы конфигурации юнитов имеют множество удобных и простых в использовании настроек среды исполнения процесса, гораздо больше, чем могут предоставить файлы из /etc/sysconfig.

* Необходимость в некоторых из этих настроек весьма сомнительна. Например, возьмем вышеупомянутую возможность задавать идентификатор пользователя/группы для процесса. Эту задачу должен решать разработчик ПО или дистрибутива. Вмешательство администратора в данную настройку, как правило, лишено смысла — только разработчик располагает всей информацией, позволяющей предотвратить конфликты идентификаторов и имен пользователей и групп.

* Формат файлов, используемых для сохранения настроек, плохо подходит для данной задачи. Так как эти файлы, как правило, являются включаемыми shell-скриптами, ошибки при их чтении очень трудно отследить. Например, ошибка в имени переменной приведет к тому, что переменная не будет изменена, однако никакого предупреждения при этом не выводится.

* Кроме того, такая организация не исключает влияния конфигурационных параметров на среду исполнения: например, изменение переменных IFS и LANG может существенно повлиять на результат интерпретации init-скрипта.

* Файлы из /etc/sysconfig часто пытаются использовать в качестве суррогатной замены файлов конфигурации для тех демонов, которые не имеют встроенной поддержки конфигурационных файлов. В частности, вводятся специальные переменные, позволяющие задать аргументы командной строки, используемые при запуске демона. Встроенная поддержка конфигурационных файлов является более удобной альтернативой такому подходу, ведь, глядя на ключи «-k», «-a», «-f», трудно догадаться об их назначении. Очень часто, из-за ограниченности словаря, на различных демонов одни и те же ключи действуют совершенно по-разному (для одного демона ключ «-f» содержит указание демонизироваться при запуске, в то время как для другого эта опция действует прямо противоположным образом.) В отличие от конфигурационных файлов, строка запуска не может включать полноценных комментариев.

* Некоторые из настроек, задаваемых в /etc/sysconfig, являются полностью избыточными. Например, во многие дистрибутивах подобным методом указывается, установлены ли аппаратные часы компьютера по Гринвичу, или по местному времени. Однако эта же настройка задается третьей строкой файла /etc/adjtime, поддерживаемого во всех дистрибутивах. Использование избыточного и не стандартизированного параметра конфигурации только добавляет путаницу и не несет никакой пользы.

* Многие файлы настроек из /etc/sysconfig позволяют отключать запуск соответствующей службы. Однако эта операция уже поддерживается штатно для всех служб, через команды systemctl enable/disable (или chkconfig on/off). Добавление дополнительного уровня настройки не приносит никакой пользы и лишь усложняет работу администратора.

* Что касается списка принудительно загружаемых модулей ядра — в настоящее время существуют куда более удобные пути для автоматической подгрузки модулей при загрузке системы. Например, многие модули автоматически подгружаются udev’ом при обнаружении соответствующего оборудования. Этот же принцип распространяется на ACPI и другие высокоуровневые технологии. Одно из немногих исключений из этого правила — к сожалению, в настоящее время не поддерживается автоматическая загрузка модулей на основании информации о возможностях процессора, однако это будет исправлено в ближайшем будущем. В случае, если нужный вам модуль ядра все же не может быть подгружен автоматически, все равно существует гораздо более удобные методы указать его принудительную подгрузку — например, путем создания соответствующего файла в каталоге /etc/modules-load.d/ (стандартный метод настройки принудительной подгрузки модулей).

* И наконец, хотелось бы отметить, что каталог /etc определен как место для хранения системных настроек («Host-specific system configuration», согласно FHS). Наличие внутри него подкаталога sysconfig, который тоже содержит системную конфигурацию, является очевидно избыточным.

Что же можно предложить в качестве современной, совместимой с systemd альтернативы настройке системы через файлы в этих каталогах? Ниже приведены несколько рекомендаций, как лучше поступить с задаваемыми таким образом параметрами конфигурации:

* Попробуйте просто отказаться от них. Если они полностью избыточны (например, настройка аппаратных часов на Гринвич/местное время), то убрать их будет довольно легко (если не рассматривать вопросы обеспечения совместимости). Если аналогичные по смыслу опции штатно поддерживаются systemd, нет никакого смысла дублировать их где-то еще (перечень опций, которые можно задать для любой службы, приведен на страницах справки systemd.exec(5) и systemd.service(5).) Если же ваша настройка просто добавляет еще один уровень отключения запуска службы — не плодите лишние сущности, откажитесь от нее.

* Найдите для них более подходящее место. Например, в случае с некоторыми общесистемными настройками (такими, как локаль или часовой пояс), мы надеемся аккуратно подтолкнуть дистрибутивы в правильном направлении (см. предыдущую главу).

* Добавьте их поддержку в штатную систему настройки демона через собственные файлы конфигурации. К счастью, большинство служб, работающих в Linux, являются свободным программным обеспечением, так что сделать это довольно просто.

Существует лишь одна причина поддерживать файлы /etc/sysconfig еще некоторое время: необходимо обеспечить совместимость при обновлении. Тем не менее, как минимум в новых пакетах, от таких файлов лучше отказаться. В том случае, если требование совместимости критично, вы можете задействовать эти конфигурационные файлы даже в том случае, если настраиваете службы через штатные unit-файлы systemd. Если ваш файл из sysconfig содержит лишь определения переменных, можно воспользоваться опцией EnvironmentFile=-/etc/sysconfig foobar (подробнее об этой опции см. systemd.exec(5)), позволяющей прочитать из файла набор переменных окружения, который будет установлен при запуске службы. Если же для задания настроек вам необходим полноценный язык программирования — ничто не мешает им воспользоваться. Например, вы можете создайть в /usr/lib// простой скрипт, который включает соответствующие файлы, а затем запускает бинарник демона через exec. После чего достаточно просто указать этот скрипт в опции ExecStart= вместо бинарника демона.

Содержание
Вперед - Экземпляры служб
Назад - Новые конфигурационные файлы