13 Отчет о состоянии службы и ее журнал



Pdf просмотр
страница5/12
Дата09.11.2016
Размер5.01 Kb.
Просмотров3116
Скачиваний0
1   2   3   4   5   6   7   8   9   ...   12
ольшую часть потребностей серверов:
∙ Проверка и монтирование всех файловых систем.
∙ Обновление и активация квот на всех файловых системах.
∙ Установка имени хоста.
∙ Настройка сетевого интерфейса обратной петли (lo).
∙ Подгрузка правил SELinux, обновление меток безопасности в динамических ката- логах /run и /dev.
∙ Регистрация в ядре дополнительных бинарных форматов (например, Java, Mono,
WINE) через API-файловую систему binfmt_misc.
∙ Установка системной локали.
∙ Настройка шрифта и раскладки клавиатуры в консоли.
∙ Создание, очистка, удаление временных файлов и каталогов.
34
Наш девиз — «Первой оболочкой, запускающейся при старте системы, должна быть GNOME shell».
Формулировка оставляет желать лучшего, но все же неплохо передает основную идею.
34

∙ Применение предписанных в /etc/fstab опций к смонтированным ранее API- файловым системам.
∙ Применение настроек sysctl.
∙ Поддержка технологии упреждающего чтения (read ahead), включая автоматиче- ский сбор информации.
∙ Обновление записей в utmp при включении и выключении системы.
∙ Сохранение и восстановление затравки для генерации случайных чисел (random seed).
∙ Принудительная загрузка указанных модулей ядра.
∙ Поддержка шифрованных дисков и разделов.
∙ Автоматический запуск getty на serial-консолях.
∙ Взаимодействие с Plymouth.
∙ Создание уникального идентификатора системы.
∙ Настройка часового пояса.
В стандартной установке Fedora 15 запуск shell-скриптов требуется только для неко- торых устаревших служб, а также для подсистемы хранения данных (поддержка LVM,
RAID и multipath). Если они вам не нужны, вы легко можете отключить их, и насла- ждаться загрузкой, полностью очищенной от shell-костылей (лично я это сделал уже давно). Такая загрузка является уникальной возможностью Linux-систем.
Большинство перечисленных выше компонентов настраиваются через конфигураци- онные файлы в каталоге /etc. Некоторые из этих файлов стандартизированы для всех дистрибутивов, и поэтому реализация их поддержки в наших инструментах не пред- ставляла особого труда. Например, это относится к файлам /etc/fstab, /etc/crypttab,
/etc/sysctl.conf. Однако множество других, нестандартно расположенных файлов и каталогов вынуждали нас добавлять в код огромное количество операторов #ifdef, что- бы обеспечить поддержку различных вариантов расположения конфигураций в разных дистрибутивах. Такое положение дел сильно усложняет жизнь нам всем, и при этом ничем не оправдано — все эти файлы решают одни и те же задачи, просто немного по-разному.
Чтобы улучшить ситуацию и установить единый стандарт расположения базовых конфигурационных файлов во всех дистрибутивах, мы заставили systemd пользоваться дистрибутивно-специфическими конфигурациями только в качестве резервного вариан- та — основным источником информации становится определенный нами стандартный набор конфигурационных файлов. Разумеется, там, где это возможно, мы старались не придумывать чего-то принципиально нового, а брали лучшее из решений, предложен- ных существующими дистрибутивами. Ниже приводится небольшой обзор этого нового набора конфигурационных файлов, поддерживаемых systemd во всех дистрибутивах:

/etc/hostname
: имя хоста для данной системы. Одна из наиболее простых и важ- ных системных настроек. В разных дистрибутивах оно настраивалось по-разному:
Fedora использовала /etc/sysconfig/network, OpenSUSE — /etc/HOSTNAME,
Debian — /etc/hostname. Мы остановились на варианте, предложенном Debian.

/etc/vconsole.conf
: конфигурация раскладки клавиатуры и шрифта для консо- ли.

/etc/locale.conf
: конфигурация общесистемной локали.
35


/etc/modules-load.d/*.conf
: каталог
35
для перечисления модулей ядра, которые нужно принудительно подгрузить при загрузке (впрочем, необходимость в этом возникает достаточно редко).

/etc/sysctl.d/*.conf
: каталог для задания параметров ядра (sysctl). Дополня- ет классический конфигурационный файл /etc/sysctl.conf.

/etc/tmpfiles.d/*.conf
: каталог для управления настройками временных фай- лов (systemd обеспечивает создание, очистку и удаление временных файлов и ка- талогов, как во время загрузки, так и во время работы системы).

/etc/binfmt.d/*.conf
: каталог для регистрации дополнительных бинарных фор- матов (например, форматов Java, Mono, WINE).

/etc/os-release
: стандарт для файла, обеспечивающего идентификацию дистри- бутива и его версии. Сейчас различные дистрибутивы используют для этого раз- ные файлы (например, /etc/fedora-release в Fedora), и поэтому для решения такой простой задачи, как вывод имени дистрибутива, необходимо использовать базу данных, содержащую перечень возможных названий файлов. Проект LSB
попытался создать такой инструмент —
lsb_release
— однако реализация столь простой функции через скрипт на Python’е является не самым оптимальным ре- шением. Чтобы исправить сложившуюся ситуацию, мы решили перейти к единому простому формату представления этой информации.

/etc/machine-id
: файл с идентификатором данного компьютера (перекрывает аналогичный идентификатор D-Bus). Гарантируется, что в любой системе, исполь- зующей systemd, этот файл будет существовать и содержать корректную инфор- мацию (если его нет, он автоматически создается при загрузке). Мы вынесли этот файл из-под эгиды D-Bus, чтобы упростить решение множества задач, требующих наличия уникального и постоянного идентификатора компьютера.

/etc/machine-info
: новый конфигурационный файл, хранящий информации о полном (описательном) имени хоста (например, «Компьютер Леннарта») и знач- ке, которым он будет обозначаться в графических оболочках, работающих с се- тью (раньше этот значок мог определяться, например, файлом /etc/favicon.png).
Данный конфигурационный файл обслуживается демоном systemd-hostnamed
Одна из важнейших для нас задач — убедить вас использовать эти новые конфигу- рационные файлы в ваших инструментах для настройки системы. Если ваши конфигу- рационные фронтенды будут использовать новые файлы, а не их старые аналоги, это значительно облегчит портирование таких фронтендов между дистрибутивами, и вы внесете свой вклад в стандартизацию Linux. В конечном счете это упростит жизнь и администраторам, и пользователям. Разумеется, на текущий момент эти файлы полно- стью поддерживаются только дистрибутивами, основанными на systemd, но уже сейчас в их число входят практически все ключевые дистрибутивы,
за исключением одного
36
В этом есть что-то от «проблемы курицы и яйца»: стандарт становится настоящим стандартом только тогда, когда ему начинают следовать. В будущем мы намерены ак- куратно форсировать процесс перехода на новые конфигурационные файлы: поддержка старых файлов будет удалена из systemd. Разумеется, процесс будет идти медленно, шаг
35
Прим. перев.: Для описания этого и трех последующих каталогов автор пользуется термином «drop- in directory». Данный термин означает каталог, в который можно поместить множество независимых файлов настроек, и при чтении конфигурации все эти файлы будут обработаны (впрочем, часто накла- дывается ограничение — обрабатываются только файлы с именами, соответствующими маске, обычно
*.conf). Такой подход позволяет значительно упростить процесс как ручного, так и автоматического конфигурирования различных компонентов — для внесения изменений в настройки уже не нужно ре- дактировать основной конфигурационный файл, достаточно лишь скопировать/переместить в нужный каталог небольшой файл с указанием специфичных параметров.
36
Прим. перев.: В конце 2010 года энтузиаст Andrew Edmunds добавил в systemd базовую поддержку
Ubuntu и подготовил соответствующие пакеты, однако его инициатива не встретила поддержки среди менеджеров Canonical. На момент написания этих строк проект остается заброшенным с декабря 2010 г.
36
за шагом. Но конечной его целью является переход всех дистрибутивов на единый набор базовых конфигурационных файлов.
Многие из этих файлов используются не только программами для настройки си- стемы, но и апстримными проектами. Например, мы предлагаем проектам Mono, Java,
WINE и другим помещать конфигурацию для регистрации своих бинарных форматов в /etc/binfmt.d/ средствами их собственной сборочной системы. Специфичные для дистрибутивов механизмы поддержки бинарных форматов больше не нужны, и ваш проект будет работать одинаково хорошо во всех дистрибутивах. Аналогичное предло- жение мы обращаем и ко всем разработчикам программ, которым требуется автома- тическое создание/очистка временных файлов и каталогов, например, в каталоге /run
(
ранее известном как /var/run). Таким проектам достаточно просто поместить соответ- ствующий конфигурационный файл в /etc/tmpfiles.d/, тоже средствами собственной сборочной системы. Помимо прочего, подобный подход позволит увеличить скорость за- грузки, так как, в отличие от SysV, не требует множества shell-скриптов, выполняющих тривиальные задачи (регистрация бинарных форматов, удаление/создание временных файлов/каталогов и т.п.). И пример того случая, когда апстримная поддержка стан- дартной конфигурации дала бы огромные преимущества — X11 (и его аналоги) могли бы устанавливать раскладку клавиатуры на основании данных из /etc/vconsole.conf.
Разумеется, я понимаю, что отнюдь не всех полностью устроят выбранные нами име- на и форматы конфигурационных файлов. Но нам все же нужно было что-то выбрать,
и мы выбрали то, что должно устроить большинство людей. Форматы конфигураци- онных файлов максимально просты, и их можно легко читать и записывать даже из shell-скриптов. Да, /etc/bikeshed.conf могло бы быть неплохим именем для файла конфигурации!
37
Помогите нам стандартизировать Linux! Используйте новые конфигура- ционные файлы! Поддерживайте их в апстриме, поддерживайте их во всех дистрибутивах!
И если у вас возникнет такой вопрос: да, все эти файлы так или иначе обсуждались с разными разработчиками из различных дистрибутивов. И некоторые из разработчиков планируют обеспечить поддержку новой конфигурации даже в системах без systemd.
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, и результате мы имеем целый зоопарк их различных реализаций в разных дистрибутивах.
37
Прим. перев.: Здесь автор намекает на
Паркинсоновский Закон Тривиальности
, который гласит, что самые жаркие споры возникают вокруг наиболее простых вопросов. В частности, в качестве примера
Паркинсон приводит обсуждение строительства атомной электростанции и гаража для велосипедов
(bike shed) — если первое из этих решений принимается довольно быстро, то вокруг второго разгорается множество дискуссий по самым разным аспектам.
37

Назначение этих каталогов определено весьма расплывчато. Абсолютное большин- ство находящихся в них файлов являются включаемыми
38
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 службы.
38
Прим. перев.: Здесь автор использует термин sourcable, происходящий от bash’овской директивы source, обеспечивающей включение в скрипт кода из внешнего файла. В классическом POSIX shell это соответствует оператору-точке «.». В отличие от прямого запуска одного скрипта из другого, вклю- чаемый код исполняется той же самой оболочкой, что и основной код, и при возвращении в основной скрипт сохраняются переменные окружения, определенные во включаемом коде. Как правило, код для включения не содержит shebang’а (#!/bin/sh в начале файла).
38

∙ Идентификатор пользователя/группы, значение 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- скриптами, ошибки при их чтении очень трудно отследить. Например, ошибка в имени переменной приведет к тому, что переменная не будет изменена, однако никакого предупреждения при этом не выводится.
39

∙ Кроме того, такая организация не исключает влияния конфигурационных пара- метров на среду исполнения: например, изменение переменных IFS и LANG может существенно повлиять на результат интерпретации init-скрипта.
∙ Интерпретация этих файлов требует запуска еще одного экземпляра оболочки, что приводит к задержкам при загрузке
39
∙ Файлы из /etc/sysconfig часто пытаются использовать в качестве суррогатной замены файлов конфигурации для тех демонов, которые не имеют встроенной поддержки конфигурационных файлов. В частности, вводятся специальные пе- ременные, позволяющие задать аргументы командной строки, используемые при запуске демона. Встроенная поддержка конфигурационных файлов является бо- лее удобной альтернативой такому подходу, ведь, глядя на ключи «-k», «-a», «-f»,
трудно догадаться об их назначении. Очень часто, из-за ограниченности словаря,
на различных демонов одни и те же ключи действуют совершенно по-разному (для одного демона ключ «-f» содержит указание демонизироваться при запуске, в то время как для другого эта опция действует прямо противоположным образом.) В
отличие от конфигурационных файлов, строка запуска не может включать полно- ценных комментариев.
∙ Некоторые из настроек, задаваемых в /etc/sysconfig, являются полностью из- быточными. Например, во многие дистрибутивах подобным методом указывается,
установлены ли аппаратные часы компьютера по Гринвичу, или по местному вре- мени. Однако эта же настройка задается третьей строкой файла /etc/adjtime,
поддерживаемого во всех дистрибутивах. Использование избыточного и не стан- дартизированного параметра конфигурации только добавляет путаницу и не несет никакой пользы.
∙ Многие файлы настроек из /etc/sysconfig позволяют отключать запуск соот- ветствующей службы. Однако эта операция уже поддерживается штатно для всех служб, через команды systemctl enable/disable (или chkconfig on/off). До- бавление дополнительного уровня настройки не приносит никакой пользы и лишь усложняет работу администратора.
∙ Что касается списка принудительно загружаемых модулей ядра — в настоящее время существуют куда более удобные пути для автоматической подгрузки моду- лей при загрузке системы. Например, многие модули автоматически подгружаются udev’ом при обнаружении соответствующего оборудования. Этот же принцип рас- пространяется на ACPI и другие высокоуровневые технологии. Одно из немногих исключений из этого правила — к сожалению, в настоящее время не поддержива- ется автоматическая загрузка модулей на основании информации о возможностях процессора, однако это будет исправлено в ближайшем будущем
40
. В случае, ес- ли нужный вам модуль ядра все же не может быть подгружен автоматически,
все равно существует гораздо более удобные методы указать его принудитель- ную подгрузку — например, путем создания соответствующего файла в каталоге
/etc/modules-load.d/
(стандартный метод настройки принудительной подгрузки модулей).
∙ И наконец, хотелось бы отметить, что каталог /etc определен как место для хране- ния системных настроек («Host-specific system configuration», согласно FHS). Нали- чие внутри него подкаталога sysconfig, который тоже содержит системную кон- фигурацию, является очевидно избыточным.
Что же можно предложить в качестве современной, совместимой с systemd альтер- нативы настройке системы через файлы в этих каталогах? Ниже приведены несколько
39
Прим. перев.: Здесь автор несколько заблуждается. Скрипты, включенные через директиву source,
исполняются тем же экземпляром оболочки, что и вызвавший их скрипт.
40
Прим. перев.: Необходимые патчи уже приняты в ядро, и соответствующая функция поддержива- ется Linux, начиная с версии 3.3.
40
рекомендаций, как лучше поступить с задаваемыми таким образом параметрами кон- фигурации:
∙ Попробуйте просто отказаться от них. Если они полностью избыточны (напри- мер, настройка аппаратных часов на Гринвич/местное время), то убрать их будет довольно легко (если не рассматривать вопросы обеспечения совместимости). Ес- ли аналогичные по смыслу опции штатно поддерживаются systemd, нет никакого смысла дублировать их где-то еще (перечень опций, которые можно задать для лю- бой службы, приведен на страницах справки systemd.exec(5)
и systemd.service(5)
.)
Если же ваша настройка просто добавляет еще один уровень отключения запуска службы — не плодите лишние сущности, откажитесь от нее.
∙ Найдите для них более подходящее место. Например, в случае с некоторыми об- щесистемными настройками (такими, как локаль или часовой пояс), мы надеемся аккуратно подтолкнуть дистрибутивы в правильном направлении (см. предыду- щую главу).
∙ Добавьте их поддержку в штатную систему настройки демона через собственные файлы конфигурации. К счастью, большинство служб, работающих в Linux, явля- ются свободным программным обеспечением, так что сделать это довольно просто.
Существует лишь одна причина поддерживать файлы /etc/sysconfig еще некото- рое время: необходимо обеспечить совместимость при обновлении. Тем не менее, как минимум в новых пакетах, от таких файлов лучше отказаться.


Поделитесь с Вашими друзьями:
1   2   3   4   5   6   7   8   9   ...   12


База данных защищена авторским правом ©nethash.ru 2019
обратиться к администрации

войти | регистрация
    Главная страница


загрузить материал