Version v6.2 (2011-05-25 16:15) [AUTO]

s4a.tex

@@ -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}
@@ -1050,7 +1051,7 @@ systemd и на этот случай есть простое решение, и
 		Заметим, что systemd читает файлы конфигурации из обоих этих
 		каталогов, но файлы из +/etc+ (управляемые системным
 		администратором) имеют приоритет над файлами из +/lib+ (которые
-		управляются пакетным менеджером). Таким образом, созание
+		управляются пакетным менеджером). Таким образом, создание
 		символьной ссылки (или обычного файла)
 		+/etc/systemd/system/ntpd.service+ предотвращает чтение
 		штатного файла конфигурации +/lib/systemd/system/ntpd.service+.
@@ -1090,7 +1091,7 @@ systemd и на этот случай есть простое решение, и
 		(через механизмы sudo или PolicyKit) право на использование
 		+systemctl+, это еще не~означает, что он сможет запустить
 		заблокированную службу~--- права на выполнение +rm+ (удаление
-		блокирующей символьной ссылки) выдаются отдельно}.
+		блокирующей символьной ссылки) выдаются отдельно.}.
 \end{itemize}
 
 После прочтения изложенного выше, у читателя может возникнуть вопрос: как
@@ -1165,10 +1166,10 @@ chroot в самой программе. Прежде всего, коррект
 chroot-окружения требует глубокого понимания принципов работы программы.
 Например, нужно точно знать, какие сокеты использует программа, чтобы обеспечить
 bind-монтирование соответствующих каталогов. С учетом вышесказанного,
-эффективный chroot-защита обеспечивается в том случае, когда она реализована в
+эффективная chroot-защита обеспечивается в том случае, когда она реализована в
-коде самого демона. Именно разработчик лучше других знает (\emph{обязан знать}),
+коде самого демона. Именно разработчик лучше других знает (\emph{обязан} знать),
 как правильно сконфигурировать chroot-окружение, и какой минимальный набор
-файлов, каталогов и файловых систем необходим внутри для нормальной работы
+файлов, каталогов и файловых систем необходим внутри него для нормальной работы
 демона. Уже сейчас существуют демоны, имеющие встроенную поддержку chroot.
 К сожалению, в системе Fedora, установленной с параметрами по умолчанию, таких
 демонов всего два: \href{http://avahi.org/}{Avahi} и RealtimeKit. Оба они
@@ -1212,7 +1213,7 @@ RootDirectoryStartOnly=yes
 командой +systemctl start foobar.service+. Информацию о его текущем состоянии
 можно получить с помощью команды +systemctl status foobar.service+. Команды
 управления и мониторинга службы не~зависят от того, запущена ли она в chroot'е,
-или нет. Этим systemd отличается от класического SysV init.
+или нет. Этим systemd отличается от классического SysV init.
 
 Новые ядра Linux поддерживают возможность создания независимых пространств имен
 файловых систем (в дальнейшем FSNS, от <<file system namespaces>>). По
@@ -1240,7 +1241,7 @@ InaccessibleDirectories=/home
 защитить данные пользователей от потенциальных хакеров. (Подробнее об этих
 опциях можно почитать на
 \href{http://0pointer.de/public/systemd-man/systemd.exec.html}{странице
-руководства}).
+руководства}.)
 
 Фактически, FSNS по множеству параметров превосходят +chroot()+. Скорее всего,
 Avahi и ReltimeKit в ближайшем будущем перейдут с +chroot()+ к использованию
@@ -1287,7 +1288,7 @@ systemd имеет целый ряд возможностей, полезных
 debootstrap/febootstrap. В этом случае возможности +systemctl+ ограничиваются
 операциями с символьными ссылками, определяющими триггеры активации юнитов, т.е.
 выполнением действий +enable+ и +disable+, не~требующих непосредственного
-взаимодействия с процессом init}.
+взаимодействия с процессом init.}.
 
 Однако, куда более интересные возможности предоставляет программа
 \href{http://0pointer.de/public/systemd-man/systemd-nspawn.html}{systemd-nspawn},
@@ -1305,7 +1306,7 @@ Linux, которая позиционируется как современна
 настроек и т.п., в то время как +systemd-nspawn+ является лишь более удобной и
 эффективной заменой команды +chroot(1)+, предназначенной прежде всего для
 развертывания, восстановления, сборки и тестирования операционных систем. Далее
-автор разъясняет свою точку зрения на этот вопрос}.
+автор разъясняет свою точку зрения на этот вопрос.}.
 +systemd-nspawn+ проста в использовании как +chroot(1)+, однако изоляция
 от хост-системы является более полной и безопасной. Всего одной командой
 вы можете загрузить внутри контейнера \emph{полноценную} ОС (на базе systemd
@@ -1378,7 +1379,7 @@ systemd уже подготовлен для работы внутри таки
 		наилучший результат, когда оно реализовано непосредственно в
 		коде самой программы.
 	\item +ReadOnlyDirectories=+ и +InaccessibleDirectories=+ могут быть
-		удобной альтернативой созданию полноценных chroot-окружений.
+		удобной альтернативой созданию полновесных chroot-окружений.
 	\item Если вам нужно поместить в chroot-окружение какую-либо службу,
 		воспользуйтесь опцией +RootDirectory=+.
 	\item +systemd-nspawn+~--- очень неплохая штука.
@@ -1564,10 +1565,289 @@ cryptsetup, что снижение этого времени с 1 секунд
 завершится процесс монтирования? Это можно сделать, воспользовавшись магической
 силой systemd~--- просто добавим опцию монтирования +comment=systemd.automount+
 в +/etc/fstab+. После этого, systemd будет создавать в +/home+ точку
-автоматического монтирования, и при первом же обращении к этому каталогу
+автоматического монтирования, и при первом же обращении к этому каталогу,
-systemd выполнит подготовку устройства, проверку и монтирование файловой
+если файловая система еще не~будет готова к работе,
-системы.
+systemd подготовит соответствующее устройство, проверит и смонтирует ее.
 
+После внесения изменений в +/etc/fstab+ и перезагрузки мы получаем:
+\begin{Verbatim}
+systemd[1]: Startup finished in 2s 47ms 112us (kernel) + 2s 663ms 942us (initrd)
++ 5s 540ms 522us (userspace) = 10s 251ms 576us.
+\end{Verbatim}
+
+Прекрасно! Несколькими простыми действиями мы выиграли почти семь секунд. И эти
+два изменения исправляют только две наиболее очевидные проблемы. При более
+аккуратном и детальном исследовании, обнаружится еще множество моментов, которые
+можно улучшить. Например, на другом моем компьютере, лаптопе X300 двухлетней
+давности (и даже два года назад он был не~самым быстрым на Земле), после
+небольшой доработки, время загрузки до полноценной среды GNOME
+составило около четырех секунд, и это еще не~предел совершенства.
+
++systemd-analyze blame+~--- простой и удобный инструмент для поиска медленно
+запускающихся служб, однако он обладает одним существенным недостатком: он
+не~показывает, насколько эффективно параллельный запуск снижает потерю времени
+для медленно запускающихся служб. Чтобы вы могли наглядно оценить этот фактор,
+мы подготовили команду +systemd-analyze plot+. Использовать ее очень просто:
+\begin{Verbatim}
+$ systemd-analyze plot > plot.svg
+$ eog plot.svg
+\end{Verbatim}
+
+Она создает наглядные диаграммы, показывающие моменты запуска служб и время,
+затраченное на их запуск, по отношению к другим службам. На текущий момент, она
+не~показывает явно, кто кого ожидает, но догадаться обычно несложно.
+
+Чтобы продемонстрировать эффект, порожденный двумя нашими оптимизациями,
+приведем ссылки на соответствующие графики:
+\href{http://0pointer.de/public/blame.svg}{до} и
+\href{http://0pointer.de/public/blame2.svg}{после} (для полноты описания приведем также и
+соответствующие данные +systemd-analyze blame+:
+\href{http://0pointer.de/public/blame.txt}{до} и
+\href{http://0pointer.de/public/blame2.txt}{после}).
+
+У наиболее эрудированных читателей может возникнуть вопрос: как это соотносится с
+программой \href{https://github.com/mmeeks/bootchart}{bootchart}? Действительно,
++systemd-analyze plot+ и +bootchart+ рисуют похожие графики. Однако, bootchart
+является намного более мощным инструментом~--- он детально показывает, что
+именно происходило во время загрузки, и отображает соответствующие графики
+использования процессора и ввода-вывода. +systemd-analyze plot+ оперирует более
+высокоуровневой информацией: сколько времени затратила та или иная служба во
+время запуска, и какие службы были вынуждены ее ожидать. Используя оба эти
+инструмента, вы значительно упростите себе поиск причин замедления вашей
+загрузки.
+
+Но прежде, чем вы вооружитесь описанными здесь средствами и начнете
+отправлять багрепорты авторам и сопровождающим программ, которые замедляют вашу
+загрузку, обдумайте все еще раз. Эти инструменты предоставляют вам <<сырую>>
+информацию. Постарайтесь не~ошибиться, интерпретируя ее. Например, в
+при рассмотрении приведенного выше примера я показал, что проблема была вовсе
+не~в +udev-settle.service+, и не~в опросе устройств для ModemManager'а, а в 
+неудачной реализации подсистемы хранения, требующей ожидать окончания опроса
+устройств для продолжения загрузки. Именно эту проблему и нужно исправлять.
+Поэтому постарайтесь правильно определить источник проблем. Возлагайте вину на
+тех, кто действительно виноват.
+
+Как уже говорилось выше, все три описанных здесь инструмента доступны в
+Fedora~15 <<из коробки>>.
+
+Итак, какие же выводы мы можем сделать из этой истории?
+\begin{itemize}
+	\item +systemd-analyze+~--- отличный инструмент. Фактически, это
+		встроенный профилировщик systemd.
+	\item Постарайтесь не~ошибиться, интерпретируя вывод профилировщика!
+	\item Всего два небольших изменения могут ускорить загрузку системы на
+		семь секунд.
+	\item Программное обеспечение, не~способное работать с динамически
+		меняющимся набором устройств, создает проблемы, и должно быть
+		исправлено.
+	\item Принудительное использование в стандартной установке 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}