Compare commits

...

3 Commits
v5.3 ... v6.2

Author SHA1 Message Date
nnz1024
e197fa131d Version v6.2 (2011-05-25 16:15) [AUTO] 2017-08-17 23:05:37 +03:00
nnz1024
4015fe4fa7 Version v6.1 (2011-05-24 18:02) [AUTO] 2017-08-17 23:05:37 +03:00
nnz1024
1c4dab825e Version v6.0 (2011-05-23 17:16) [AUTO] 2017-08-17 23:05:37 +03:00

207
s4a.tex
View File

@@ -13,8 +13,9 @@
% Заполняем поля PDF уже со включенной опцией unicode
\hypersetup{pdftitle={systemd для администраторов},%
pdfauthor={Lennart Poettering, Sergey Ptashnick}}
% Небольшое сокращение
% Несколько сокращений
\newcommand{\sectiona}[1]{\section*{#1}\addcontentsline{toc}{section}{#1}}
\newcommand{\hreftt}[2]{\href{#1}{\texttt{#2}}}
% Настройка макета страницы
\setlength{\hoffset}{-1.5cm}
\addtolength{\textwidth}{2cm}
@@ -1644,6 +1645,210 @@ Fedora~15 <<из коробки>>.
не~самым правильным решением.
\end{itemize}
\section{Новые конфигурационные файлы}
Одно из наиболее масштабных нововведений
\href{http://www.freedesktop.org/wiki/Software/systemd}{systemd}~--- наличие
полного набора программ, необходимых на ранних стадиях загрузки, причем эти
программы написаны на простом, быстром, надежном и легко поддающемся
распараллеливанию языке C. Теперь можно отказаться от <<простыней>>
shell-скриптов, разработанных для этих задач различными дистрибутивами. Наш
<<Проект нулевой оболочки>>\footnote{Наш девиз~--- <<Первой оболочкой,
запускающейся при старте системы, должна быть GNOME shell>>. Формулировка
оставляет желать лучшего, но все же неплохо передает основную идею.} увенчался
полным успехом. Уже сейчас возможности предоставляемого нами инструментария
покрывают практически все нужды настольных и встраиваемых систем, а также
большую часть потребностей серверных систем:
\begin{itemize}
\item Проверка и монтирование всех файловых систем.
\item Обновление и активация квот на всех файловых системах.
\item Установка имени хоста.
\item Конфигурирование интерфейса обратной петли (+lo+).
\item Подгрузка правил SELinux, обновление
меток безопасности в динамических каталогах +/run+ и +/dev+.
\item Регистрация в ядре дополнительных бинарных форматов (например,
Java, Mono, WINE) через API-файловую систему +binfmt_misc+.
\item Установка системной локали.
\item Настройка шрифта и раскладки клавиатуры в консоли.
\item Создание, очистка, удаление временных файлов и каталогов.
\item Применение предписанных в +/etc/fstab+ опций к смонтированным
ранее API-файловым системам.
\item Применение настроек +sysctl+.
\item Поддержка технологии упреждающего чтения (read ahead), включая
автоматический сбор информации.
\item Обновление записей в +utmp+ при включении и выключении системы.
\item Сохранение и восстановление затравки для генерации случайных чисел
(random seed).
\item Принудительная загрузка указанных модулей ядра.
\item Поддержка шифрованных дисков и разделов.
\item Автоматический запуск +getty+ на serial-консолях.
\item Взаимодействие с Plymouth.
\item Создание уникального идентификатора системы.
\item Установка часового пояса.
\end{itemize}
В стандартной установке Fedora~15 запуск shell-скриптов требуется только для
некоторых устаревших служб, а также для подсистемы хранения данных (поддержка
LVM, RAID и multipath). Если они вам не~нужны, вы легко можете отключить их, и
наслаждаться загрузкой, полностью очищенной от shell-костылей (я это сделал уже
давно). Такая загрузка является уникальной возможностью Linux-систем.
Большинство перечисленных выше компонентов настраиваются через конфигурационные
файлы в каталоге +/etc+. Некоторые из этих файлов стандартизированы для всех
дистрибутивов, и поэтому реализация их поддержки в наших инструментах
не~представляла особого труда. Например, это относится к файлам +/etc/fstab+,
+/etc/crypttab+, +/etc/sysctl.conf+. Однако множество других, нестандартно
расположенных файлов и каталогов вынуждали нас добавлять множество операторов
+#ifdef+, чтобы обеспечить поддержку различных вариантов расположения
конфигураций в разных дистрибутивах. Такой положение дел сильно усложняет
жизнь нам всем, и при этом ничем не~оправдано~--- все эти файлы решают одни и те
же задачи, но делают это немного по-разному.
Чтобы улучшить ситуацию и установить единый стандарт расположения базовых
конфигурационных файлов во всех дистрибутивах, мы заставили systemd пользоваться
дистрибутивно-специфическими конфигурациями только в качестве \emph{резервного}
варианта~--- основным источником информации становится определенный нами
стандартный набор конфигурационных файлов. Разумеется, там, где это возможно, мы
старались не~придумывать чего-то принципиально нового, а брали лучшее из
решений, предложенных существующими дистрибутивами. Ниже приводится небольшой
обзор этого нового набора конфигурационных файлов, поддерживаемых systemd во
всех дистрибутивах:
\begin{itemize}
\item
\hreftt{http://0pointer.de/public/systemd-man/hostname.html}{/etc/hostname}:
имя хоста для данной системы. Одна из наиболее простых и важных
системных настроек. В разных дистрибутивах оно настраивалось
по-разному: Fedora использовала +/etc/sysconfig/network+,
OpenSUSE~--- +/etc/HOSTNAME+, Debian~--- +/etc/hostname+. Мы
остановились на варианте, предложенном Debian.
\item
\hreftt{http://0pointer.de/public/systemd-man/vconsole.conf.html}{/etc/vconsole.conf}:
конфигурация раскладки клавиатуры и шрифта для консоли.
\item
\hreftt{http://0pointer.de/public/systemd-man/locale.conf.html}{/etc/locale.conf}:
конфигурация общесистемной локали.
\item
\hreftt{http://0pointer.de/public/systemd-man/modules-load.d.html}{/etc/modules-load.d/*.conf}:
каталог\footnote{Прим. перев.: для описания этого и трех
последующих каталогов автор пользуется термином <<drop-in
directory>>. Этот термин означает каталог, в который можно
поместить множество независимых файлов настроек, и при чтении
конфигурации все эти файлы будут обработаны (впрочем, часто
накладывается ограничение~--- обрабатываются только файлы с
именами, соответствующими маске, обычно +*.conf+). Такой подход
позволяет значительно упростить процесс как ручного, так и
автоматического конфигурирования различных компонентов~--- для
внесения изменений в настройки уже не~нужно редактировать
основной конфигурационный файл, достаточно лишь
скопировать/переместить в нужный каталог небольшой файл с
указанием специфичных параметров.} для перечисления модулей
ядра, которые нужно принудительно подгрузить при загрузке
(впрочем, необходимость в этом возникает достаточно редко).
\item
\hreftt{http://0pointer.de/public/systemd-man/sysctl.d.html}{/etc/sysctl.d/*.conf}:
каталог для задания параметров ядра (+sysctl+). Дополняет
классический конфигурационный файл +/etc/sysctl.conf+.
\item
\hreftt{http://0pointer.de/public/systemd-man/tmpfiles.d.html}{/etc/tmpfiles.d/*.conf}:
каталог для управления настройками временных файлов (systemd
обеспечивает создание, очистку и удаление временных файлов и
каталогов, как во время загрузки, так и во время работы
системы).
\item
\hreftt{http://0pointer.de/public/systemd-man/binfmt.d.html}{/etc/binfmt.d/*.conf}:
каталог для регистрации дополнительных бинарных форматов
(например, форматов Java, Mono, WINE).
\item
\hreftt{http://0pointer.de/public/systemd-man/os-release.html}{/etc/os-release}:
стандарт для файла, обеспечивающего идентификацию дистрибутива и
его версии. Сейчас различные дистрибутивы используют для этого
разные файлы (например, +/etc/fedora-release+ в Fedora), и
поэтому для решения такой простой задачи, как вывод имени
дистрибутива, необходимо использовать базу данных, содержащую
перечень возможных названий файлов. Проект LSB попытался создать
такой инструмент~---
\hreftt{http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/lsbrelease.html}{lsb\_release}~---
однако реализация такой простой вещи через скрипт на Python'е
является не~самым оптимальным решением. Чтобы исправить
сложившуюся ситуацию, мы решили перейти к единому простому
формату представления этой информации.
\item
\hreftt{http://0pointer.de/public/systemd-man/machine-id.html}{/etc/machine-id}:
файл с идентификатором данного компьютера (перекрывает
аналогичный идентификатор D-Bus). Гарантируется, что в любой
системе, использующей systemd, этот файл будет существовать и
содержать корректную информацию (если его нет, он автоматически
создается при загрузке). Мы вынесли этот файл из-под эгиды
D-Bus, чтобы упростить решение множества задач, требующих
наличия уникального и постоянного идентификатора компьютера.
\item
\hreftt{http://0pointer.de/public/systemd-man/machine-info.html}{/etc/machine-info}:
новый конфигурационный файл, хранящий информации о полном имени
(описательном) хоста (например, <<Компьютер Леннарта>>) и
значке, которым он будет обозначаться в графических оболочках,
работающих с сетью (раньше этот значок мог определяться,
например, файлом +/etc/favicon.png+). Данный конфигурационный
файл обслуживается демоном
\hreftt{http://www.freedesktop.org/wiki/Software/systemd/hostnamed}{systemd-hostnamed}.
\end{itemize}
Одна из важнейших для нас задач~--- убедить \emph{вас} использовать эти новые
конфигурационные файлы в ваших инструментах для настройки системы. Если ваши
конфигурационные фронтенды будут использовать новые файлы, а не~их старые
аналоги, это значительно облегчит портирование таких фронтендов между
дистрибутивами, и вы внесете свой вклад в стандартизацию Linux, и в конечном
счете упростится жизнь и у администраторов, и для пользователей. Разумеется, на
текущий момент эти файлы полностью поддерживаются только дистрибутивами,
основанными на systemd, но уже сейчас в их число входят практически все ключевые
дистрибутивы, \href{http://www.ubuntu.com/}{за исключением
одного}\footnote{Прим. перев.: В конце 2010~года энтузиаст Andrew Edmunds
\href{http://cgit.freedesktop.org/systemd/commit/?id=858dae181bb5461201ac1c04732d3ef4c67a0256}{добавил}
в systemd базовую поддержку Ubuntu и
\href{https://wiki.ubuntu.com/systemd}{подготовил} соответствующие пакеты,
однако его инициатива не~встретила поддержки среди менеджеров Canonical. На
момент написания этих строк (май 2011 года) проект остается заброшенным уже пять
месяцев (с середины декабря 2010~г.).}. В этом есть что-то от <<пролемы курицы и
яйца>>: стандарт становится начинает работать как стандарт только тогда, когда
ему начинают следовать. В будущем мы намерены аккуратно форсировать процесс
перехода на новые конфигурационные файлы: поддержка старых файлов будет удалена
из systemd. Разумеется, этот процесс будет идти медленно, шаг за шагом. Но
конечной его целью является переход всех дистрибутивов на единый набор базовых
конфигурационных файлов.
Многие из этих файлов используются не~только программами для настройки системы,
но и апстримными проектами. Например, мы предлагаем проектам Mono, Java, WINE и
другим помещать конфигурацию для регистрации своих бинарных форматов в
+/etc/binfmt.d/+ средствами их собственной сборочной системы. Специфичные для
дистрибутивов механизмы поддержки бинарных форматов больше не~нужны, и ваш
проект будет работать одинаково хорошо во всех дистрибутивах. Аналогичное
предложение мы обращаем и ко всем разработчикам программ, которым требуется
автоматическое создание/очистка временных файлов и каталогов при загрузке,
например, в каталоге +/run+ (\href{http://lwn.net/Articles/436012/}{ранее
известном} как +/var/run+). Таким проектам достаточно просто поместить
соответствующий конфигурационный файл в +/etc/tmpfiles.d/+, тоже средствами
собственной сборочной системы. Помимо прочего, подобный подход позволит
увеличить скорость загрузки, так как, в отличие от SysV, не~требует множества
shell-скриптов, выполняющих тривиальные задачи (регистрация бинарных форматов,
удаление/создание временных файлов/каталогов и т.п.). И пример того случая,
когда апстримная поддержка стандартной конфигурации дала бы огромные
преимущества~--- X11 (и его аналоги) могли бы устанавливать раскладку клавиатуры
на основании данных из +/etc/vconsole.conf+.
Разумеется, я понимаю, что отнюдь не~всех полностью устроят выбранные нами имена
и форматы конфигурационных файлов. Но нам все же нужно было что-то выбрать, и мы
выбрали то, что должно устроить большинство людей. Форматы конфигурационных
файлов максимально просты, и их можно легко читать и записывать даже из
shell-скриптов. (Эх, а ведь +/etc/bikeshed.conf+ могло бы быть неплохим именем
для файла конфигурации!)
\textbf{Помогите нам стандартизировать Linux! Используйте новые конфигурационные
файлы! Поддерживайте их в апстриме, поддерживайте их во всех дистрибутивах!}
Да, и если у вас возникнет такой вопрос: да, все эти файлы так или иначе
обсуждались с разными разработчиками из различных дистрибутивов. И некоторые из
этих разработчиков планируют обеспечить поддержку новой конфигурации даже в
системах без systemd.
\end{document}
vim:ft=tex:tw=80:spell:spelllang=ru