Compare commits
3 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
|
4539170bae | ||
|
|
6a698b3e9a | ||
|
|
e71d20b589 |
233
s4a.tex
233
s4a.tex
@@ -19,12 +19,17 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
|
||||
\newcommand{\sectiona}[1]{\section*{#1}\addcontentsline{toc}{section}{#1}}
|
||||
\newcommand{\hreftt}[2]{\href{#1}{\texttt{#2}}}
|
||||
\newcommand{\tbs}{\textbackslash}
|
||||
\newcommand{\hrf}[2]{\href{#1}{#2}}
|
||||
\newenvironment{caveat}[1][]{\smallskip\par\textbf{Предупреждение#1: }}%
|
||||
{\smallskip\par}
|
||||
% Примерный аналог символа \testSFii (присутствует в листингах),
|
||||
% но без использования пакета pmboxdraw, средствами graphicx
|
||||
\newcommand{\mytextSFii}{\raisebox{0pt}[0pt][\depth]{%
|
||||
\reflectbox{\rotatebox[origin=t]{270}{$\neg$}}}}
|
||||
% Из-за бага в пакете fancyvrb, в окружениях Verbatim нельзя использовать URL,
|
||||
% содержащие дефисы. Поэтому их определение приходится выносить за пределы
|
||||
% окружения
|
||||
\newcommand{\defhref}[2]{\newcommand{\tmphref}{\href{#1}{#2}}}
|
||||
% Настройка макета страницы
|
||||
\setlength{\hoffset}{-1.5cm}
|
||||
\addtolength{\textwidth}{2cm}
|
||||
@@ -44,7 +49,7 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
|
||||
\begin{document}
|
||||
\sloppy
|
||||
\title{systemd для администраторов}
|
||||
\author{Lennart P\"{o}ttering (автор)\thanks{Первоисточник (на английском
|
||||
\author{Lennart Poettering (автор)\thanks{Первоисточник (на английском
|
||||
языке) опубликован на сайте автора: \url{http://0pointer.de/blog/projects}}\\%
|
||||
Сергей Пташник (русский перевод)\thanks{Актуальная версия перевода
|
||||
доступна на личной странице переводчика:
|
||||
@@ -74,7 +79,7 @@ Unported}}
|
||||
будем рассматривать ключевые новшества systemd, что может потребовать несколько
|
||||
более подробного изложения.
|
||||
\begin{flushright}
|
||||
Lennart P\"{o}ttering, 23 августа 2010~г.
|
||||
Lennart Poettering, 23 августа 2010~г.
|
||||
\end{flushright}
|
||||
|
||||
\section{Контроль процесса загрузки}
|
||||
@@ -2282,11 +2287,10 @@ systemd и заложен предварительный поиск файла
|
||||
одноименному устройству). В то время как +%I+ удобно использовать в командной
|
||||
строке (+ExecStart+) и для формирования читабельных строк описания. Рассмотрим
|
||||
работу этих принципов на примере нашего юнит-файла\footnote{Прим. перев.: как
|
||||
видно из нижеприведенного примера, в командной строке +systemctl+ необходимо
|
||||
указывать экранированное имя юнита, что создает определенные трудности даже при
|
||||
наличии в оболочке <<умного>> автодополнения. Однако, на момент написания этих
|
||||
строк, в TODO проекта содержится пункт о добавлении в systemctl поддержки
|
||||
неэкранированных имен юнитов.}:
|
||||
видно из нижеприведенного примера, в командной строке +systemctl+ используется
|
||||
экранированное имя юнита, что создает определенные трудности даже при
|
||||
наличии в оболочке <<умного>> автодополнения. Однако, начиная с systemd v186,
|
||||
при работе с +systemctl+ можно указывать неэкранированные имена юнитов.}:
|
||||
\begin{landscape}
|
||||
\begin{Verbatim}[fontsize=\small,commandchars=|\{\}]
|
||||
# systemctl start 'serial-getty@serial-by\x2dpath-pci\x2d0000:00:1d.0\x2dusb\x2d0:1.4:1.1\x2dport0.service'
|
||||
@@ -2446,7 +2450,7 @@ service ssh {
|
||||
Подобный подход был некогда весьма популярен в Unix, но сейчас он уже постепенно
|
||||
выходит из моды, и поэтому в современных версиях xinetd поддерживается возможность
|
||||
явного указания номера порта. Одна из наиболее интересных настроек названа
|
||||
не~очень очевидно~--- +nowait+ (+wait=no+). Она определяет, будет ли служба
|
||||
не~вполне очевидно~--- +nowait+ (+wait=no+). Она определяет, будет ли служба
|
||||
работать по второй (+wait+) или третьей (+nowait+) схеме. И наконец, ключ +-i+
|
||||
активирует inetd-режим в SSH-сервере (без этого ключа он работает в независимом
|
||||
режиме).
|
||||
@@ -2568,7 +2572,7 @@ sshd.socket loaded active listening SSH So
|
||||
В завершение нашей дискуссии, сравним возможности xinetd и systemd, и выясним,
|
||||
может ли systemd полностью заменить xinetd, или нет. Вкратце: systemd
|
||||
поддерживает далеко не~все возможности xinetd и поэтому отнюдь не~является его
|
||||
полноценной заменой на все случаи жизни. В частности, если вы загляните в
|
||||
полноценной заменой на все случаи жизни. В частности, если вы заглянете в
|
||||
\href{http://linux.die.net/man/5/xinetd.conf}{список параметров конфигурации}
|
||||
xinetd, вы заметите, что далеко не~все эти опции доступны в systemd. Например, в
|
||||
systemd нет и никогда не~будет встроенных служб +echo+, +time+, +daytime+,
|
||||
@@ -2596,8 +2600,8 @@ Linux подсистема ipset гораздо лучше подходит дл
|
||||
ценителей устаревших технологий systemd предлагает поддержку tcpwrap. С другой
|
||||
стороны, systemd тоже предоставляет ряд возможностей, отсутствующих в xinetd, в
|
||||
частности, индивидуальный контроль над каждым экземпляром службы (см. выше), и
|
||||
куда более полный
|
||||
\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{список настроек}
|
||||
внушительный
|
||||
\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{набор настроек}
|
||||
для контроля окружения, в котором запускаются экземпляры. Я надеюсь, что
|
||||
возможностей systemd должно быть достаточно для решения большинства задач, а в
|
||||
тех редких случаях, когда вам потребуются специфические опции xinetd~--- ничто
|
||||
@@ -2772,9 +2776,9 @@ ReadOnlyDirectories=/var
|
||||
+/var+.
|
||||
|
||||
\begin{caveat}
|
||||
К сожалений, в настоящее время опция +ReadOnlyDirectories=+ не~применяется
|
||||
К сожалению, в настоящее время опция +ReadOnlyDirectories=+ не~применяется
|
||||
рекурсивно к точкам монтирования, расположенным в поддереве указанного каталога
|
||||
(т.е. файловые систем, смонтированные в подкаталогах +/var+, по-прежнему
|
||||
(т.е. файловые системы, смонтированные в подкаталогах +/var+, по-прежнему
|
||||
останутся доступными на запись, если, конечно, не~перечислить их все поименно).
|
||||
Мы собираемся исправить это в ближайшее время.
|
||||
\end{caveat}
|
||||
@@ -2881,7 +2885,7 @@ LimitFSIZE=0
|
||||
\subsection{Контроль доступа служб к файлам устройств}
|
||||
|
||||
Файлы устройств предоставляют приложениям интерфейс для доступа к ядру и
|
||||
драйверам. Причем драйверы, как правило менее тщательно тестируются и не~так
|
||||
драйверам. Причем драйверы, как правило, менее тщательно тестируются и не~так
|
||||
аккуратно проверяются на предмет наличия уязвимостей, по сравнению с основными
|
||||
компонентами ядра. Именно поэтому драйверы часто становятся объектами атаки
|
||||
злоумышленников. systemd позволяет контролировать доступ к устройствам
|
||||
@@ -2926,6 +2930,207 @@ systemd.
|
||||
выиграют не~только ваши пользователи, но и все мы, потому что Интернет станет
|
||||
чуть более безопасным.
|
||||
|
||||
\section{Отчет о состоянии службы и ее журнал}
|
||||
|
||||
При работе с системами, использующими systemd, одной из наиболее важных и часто
|
||||
используемых команд является +systemctl status+. Она выводит отчет о состоянии
|
||||
службы (или другого юнита). В таком отчете приводится статус службы (работает
|
||||
она или нет), список ее процессов и другая полезная информация.
|
||||
|
||||
В Fedora~17 мы ввели
|
||||
\href{http://0pointer.de/blog/projects/the-journal.html}{Journal}, новую
|
||||
реализацию системного журнала, обеспечивающую структурированное, индексированное
|
||||
и надежное журналирование, при сохранении совместимости с классическими
|
||||
реализациями syslog. Собственно, мы начали работу над~Journal только потому, что
|
||||
хотели добавить одну, казалось бы, простую, возможность: включить в вывод
|
||||
+systemctl status+ последние 10 сообщений, поступивших от службы в системный
|
||||
журнал. Но на практике оказалось, что в рамках классических механизмов syslog,
|
||||
реализация этой возможности чрезвычайно сложна и малоэффективна. С другой
|
||||
стороны, сообщения службы в системный журнал несут очень важную информацию о ее
|
||||
состоянии, и такая возможность действительно была бы очень полезной, особенно
|
||||
при диагностике нештатных ситуаций.
|
||||
|
||||
Итак, мы интегрировали Journal в systemd, и научили +systemctl+ работать с ним.
|
||||
Результат выглядит примерно так:
|
||||
\begin{Verbatim}[fontsize=\small,commandchars=\\\{\}]
|
||||
$ systemctl status avahi-daemon.service
|
||||
avahi-daemon.service - Avahi mDNS/DNS-SD Stack
|
||||
Loaded: loaded (/usr/lib/systemd/system/avahi-daemon.service; enabled)
|
||||
Active: active (running) since Fri, 18 May 2012 12:27:37 +0200; 14s ago
|
||||
Main PID: 8216 (avahi-daemon)
|
||||
Status: "avahi-daemon 0.6.30 starting up."
|
||||
CGroup: name=systemd:/system/avahi-daemon.service
|
||||
\mytextSFii{} 8216 avahi-daemon: running [omega.local]
|
||||
\mytextSFii{} 8217 avahi-daemon: chroot helper
|
||||
|
||||
May 18 12:27:37 omega avahi-daemon[8216]: Joining mDNS multicast group on interface eth1.IPv4 with address 172.31.0.52.
|
||||
May 18 12:27:37 omega avahi-daemon[8216]: New relevant interface eth1.IPv4 for mDNS.
|
||||
May 18 12:27:37 omega avahi-daemon[8216]: Network interface enumeration completed.
|
||||
May 18 12:27:37 omega avahi-daemon[8216]: Registering new address record for 192.168.122.1 on virbr0.IPv4.
|
||||
May 18 12:27:37 omega avahi-daemon[8216]: Registering new address record for fd00::e269:95ff:fe87:e282 on eth1.*.
|
||||
May 18 12:27:37 omega avahi-daemon[8216]: Registering new address record for 172.31.0.52 on eth1.IPv4.
|
||||
May 18 12:27:37 omega avahi-daemon[8216]: Registering HINFO record with values 'X86_64'/'LINUX'.
|
||||
May 18 12:27:38 omega avahi-daemon[8216]: Server startup complete. Host name is omega.local. Local service cookie is 3555095952.
|
||||
May 18 12:27:38 omega avahi-daemon[8216]: Service "omega" (/services/ssh.service) successfully established.
|
||||
May 18 12:27:38 omega avahi-daemon[8216]: Service "omega" (/services/sftp-ssh.service) successfully established.
|
||||
\end{Verbatim}
|
||||
Очевидно, это отчет о состоянии всеми любимого демона mDNS/DNS-SD, причем после
|
||||
списка процессов, как мы и обещали, приведены сообщения этого демона в системный
|
||||
журнал. Миссия выполнена!
|
||||
|
||||
Команда +systemctl status+ поддерживает ряд опций, позволяющих настроить вывод
|
||||
информации в соответствии с вашими пожеланиями. Отметим две наиболее интересные
|
||||
из них: ключ +-f+ позволяет в реальном времени отслеживать обновление сведений
|
||||
(по аналогии с +tail -f+), а ключ +-n+ задает количество выводимых журнальных
|
||||
записей (как нетрудно догадаться, по аналогии с +tail -n+).
|
||||
|
||||
Журнальные записи собираются из трех различных источников. Во-первых, это
|
||||
сообщения службы в системный журнал, отправленные через функцию libc
|
||||
+syslog()+. Во-вторых, это сообщения, отправленные через штатный API системы
|
||||
Journal. И наконец, это весь текст, выводимый демоном в STDOUT и STDERR. Проще
|
||||
говоря, все, что демон считает нужным сказать администратору, собирается,
|
||||
упорядочивается и отображается в одинаковом формате.
|
||||
|
||||
Добавленная нами возможность, при всей своей простоте, может оказаться
|
||||
чрезвычайно полезной практически любому администратору. По-хорошему, ее стоило
|
||||
реализовать еще 15 лет назад.
|
||||
|
||||
\section{Самодокументированный процесс загрузки}
|
||||
|
||||
Нам часто приходится слышать жалобы, что процесс загрузки при использовании
|
||||
systemd очень сложен для понимания. Не~могу с этим согласиться. Более того, я
|
||||
берусь даже утверждать обратное: по сравнению с тем, что мы имели раньше (когда
|
||||
для того, чтобы разобраться в загрузке, нужно было иметь хорошие навыки
|
||||
программирования на языке Bourne Shell\footnote{Чья привлекательность очень
|
||||
коварна и обманчива.}), процесс загрузки стал более простым и прозрачным. Но
|
||||
определенная доля истины в этом критическом замечании все же есть: даже опытному
|
||||
Unix-администратору при переходе на systemd нужно изучить некоторые новые для
|
||||
себя вещи. Мы, разработчики systemd, обязаны максимально упростить такое
|
||||
обучение. Решая данную задачу, мы подготовили для вас некоторые приятные
|
||||
сюрпризы, и предоставили хорошую документацию даже там, где это казалось
|
||||
невозможным.
|
||||
|
||||
Уже сейчас systemd располагает довольно обширной документацией, включая
|
||||
\href{http://www.freedesktop.org/software/systemd/man/}{страницы руководства}
|
||||
(на данный момент, их около сотни),
|
||||
\href{http://www.freedesktop.org/wiki/Software/systemd}{wiki-сайт проекта}, а
|
||||
также ряд статей в моем блоге. Тем не~менее, большое количество документации еще
|
||||
не~гарантирует простоты понимания. Огромные груды руководств выглядят пугающе, и
|
||||
неподготовленный читатель не~может понять, с какого места ему начинать читать,
|
||||
если он хочет просто понять общую концепцию.
|
||||
|
||||
Чтобы решить данную проблему, мы добавили в systemd небольшую, но очень изящную
|
||||
возможность: самодокументированный\footnote{Прим. перев.: В оригинале
|
||||
использован термин <<self-explanatory>>, который также можно перевести как
|
||||
<<само-объясняющий>>, <<самоочевидный>>.} процесс загрузки. Что мы под этим
|
||||
подразумеваем? То, что для каждого элемента процесса загрузки теперь имеется
|
||||
документация, прозрачно привязанная к данному элементу, так что ее поиск
|
||||
не~представляет трудности.
|
||||
|
||||
Иными словами, все штатные юниты systemd (которые, собственно, и формируют
|
||||
процесс загрузки, вызывая соответствующие программы) включают ссылки на страницы
|
||||
документации, описывающие назначение юнита/программы, используемые ими
|
||||
конфигурационные файлы и т.д. Если пользователь хочет узнать, для чего
|
||||
предназначен какой-либо юнит, какова его роль в процессе загрузки и как его
|
||||
можно настроить, может получить ссылки на соответствующую документацию, просто
|
||||
воспользовавшись давно известной командой +systemctl status+. Возьмем для
|
||||
примера +systemd-logind.service+:
|
||||
\defhref{http://www.freedesktop.org/software/systemd/man/systemd-logind.service.html}%
|
||||
{man:systemd-logind.service(7)}
|
||||
\begin{Verbatim}[fontsize=\small,commandchars=\\\{\}]
|
||||
$ systemctl status systemd-logind.service
|
||||
systemd-logind.service - Login Service
|
||||
Loaded: loaded (/usr/lib/systemd/system/systemd-logind.service; static)
|
||||
Active: active (running) since Mon, 25 Jun 2012 22:39:24 +0200; 1 day and 18h ago
|
||||
Docs: \tmphref{}
|
||||
\href{http://www.freedesktop.org/software/systemd/man/logind.conf.html}{man:logind.conf(5)}
|
||||
\url{http://www.freedesktop.org/wiki/Software/systemd/multiseat}
|
||||
Main PID: 562 (systemd-logind)
|
||||
CGroup: name=systemd:/system/systemd-logind.service
|
||||
\mytextSFii{} 562 /usr/lib/systemd/systemd-logind
|
||||
|
||||
Jun 25 22:39:24 epsilon systemd-logind[562]: Watching system buttons on /dev/input/event2 (Power Button)
|
||||
Jun 25 22:39:24 epsilon systemd-logind[562]: Watching system buttons on /dev/input/event6 (Video Bus)
|
||||
Jun 25 22:39:24 epsilon systemd-logind[562]: Watching system buttons on /dev/input/event0 (Lid Switch)
|
||||
Jun 25 22:39:24 epsilon systemd-logind[562]: Watching system buttons on /dev/input/event1 (Sleep Button)
|
||||
Jun 25 22:39:24 epsilon systemd-logind[562]: Watching system buttons on /dev/input/event7 (ThinkPad Extra Buttons)
|
||||
Jun 25 22:39:25 epsilon systemd-logind[562]: New session 1 of user gdm.
|
||||
Jun 25 22:39:25 epsilon systemd-logind[562]: Linked /tmp/.X11-unix/X0 to /run/user/42/X11-display.
|
||||
Jun 25 22:39:32 epsilon systemd-logind[562]: New session 2 of user lennart.
|
||||
Jun 25 22:39:32 epsilon systemd-logind[562]: Linked /tmp/.X11-unix/X0 to /run/user/500/X11-display.
|
||||
Jun 25 22:39:54 epsilon systemd-logind[562]: Removed session 1.
|
||||
\end{Verbatim}
|
||||
|
||||
На первый взгляд, в выводе этой команды почти ничего не~изменилось. Но если вы
|
||||
вглядитесь повнимательнее, то заметите новое поле +Docs+, в котором приведены
|
||||
ссылки на документацию по данной службе. В нашем случае случае это два URI,
|
||||
ссылающихся на man-страницы, и один URL, указывающий на веб-страницу.
|
||||
man-страницы описывают соответственно предназначение службы и ее настройки, а
|
||||
веб-страница~--- базовые концепции, которые реализуются этой службой.
|
||||
|
||||
Тем, кто использует современные графические эмуляторы терминала, чтобы открыть
|
||||
соответствующую страницу документации, достаточно щелкнуть мышью по
|
||||
URI\footnote{Для нормальной работы данной функции, в эмуляторе терминала должен
|
||||
быть исправлена \href{https://bugzilla.gnome.org/show_bug.cgi?id=676452}{эта
|
||||
ошибка}, а в программе просмотра страниц помощи~---
|
||||
\href{https://bugzilla.gnome.org/show_bug.cgi?id=676482}{вот эта}.}. Иными
|
||||
словами, доступ к документации компонентов загрузки становится предельно
|
||||
простым: достаточно вызвать +systemctl status+, после чего щелкнуть по
|
||||
полученным ссылкам.
|
||||
|
||||
Если же вы используете не~графический эмулятор терминала (где можно просто
|
||||
щелкнуть по URI), а настоящий терминал, наличие URI где-то в середине вывода
|
||||
+systemctl status+ вряд ли покажется вам удобным. Чтобы упростить обращение к
|
||||
соответствующим страницам документации без использования мыши и
|
||||
копирования/вставки, мы ввели новую команду
|
||||
\begin{Verbatim}
|
||||
systemctl help systemd-logind.service
|
||||
\end{Verbatim}
|
||||
которая просто откроет в вашем терминале соответствующие man-страницы.
|
||||
|
||||
URI, ссылающиеся на документацию, формируются в соответствии со страницей
|
||||
руководства
|
||||
\href{https://www.kernel.org/doc/man-pages/online/pages/man7/url.7.html}{uri(7)}.
|
||||
Поддерживаются схемы +http+/+https+ (URL для веб-страниц) и +man+/+info+
|
||||
(локальные страницы руководства).
|
||||
|
||||
Разумеется, добавленная нами возможность не~обеспечивает полной очевидности
|
||||
абсолютно всего, хотя бы потому, что пользователь должен как минимум знать про
|
||||
команду +systemctl status+ (а также вообще про программу +systemctl+ и про то,
|
||||
что такое юнит). Но при наличии этих базовых знаний, пользователю уже
|
||||
не~составит труда получить информацию по интересующим его вопросам.
|
||||
|
||||
Мы надеемся, что добавленный нами механизм для связи работающего кода и
|
||||
соответствующей документации станет значительным шагом к полностью прозрачному и
|
||||
предельно простому для понимания процессу загрузки.
|
||||
|
||||
Соответствующая функциональность частично присутствует в Fedora~17, а в полном
|
||||
объеме она будет представлена в Fedora~18.
|
||||
|
||||
В завершение, стоит отметить, что использованная нами идея не~является такой уж
|
||||
новой: в SMF, системе инициализации Solaris, уже используется практика
|
||||
добавления ссылок на документацию в описании службы. Однако, в Linux такой
|
||||
подход является принципиально новым, и systemd сейчас является наиболее
|
||||
документированной и прозрачной системой загрузки для данной платформы.
|
||||
|
||||
Если вы занимаетесь разработкой или сопровождением пакетов и создаете файл
|
||||
конфигурации юнита, пожалуйста, включите в него ссылки на документацию. Это
|
||||
очень просто: достаточно добавить в секции +[Unit]+ поле +Documentation=+ и
|
||||
перечислить в нем соответствующие URI. Подробнее об этом поле см. на странице
|
||||
руководства
|
||||
\href{http://www.freedesktop.org/software/systemd/man/systemd.unit.html}{systemd.unit(5)}.
|
||||
Чем больше будет документированных юнитов, тем проще станет работа системного
|
||||
администратора. (В частности, я уже направил в FPC
|
||||
\href{https://fedorahosted.org/fpc/ticket/192}{предложение} внести
|
||||
соответствующие пожелания в нормативные документы, регулирующие подготовку
|
||||
пакетов для Fedora.)
|
||||
|
||||
Да, кстати: если вас интересует общий обзор процесса загрузки systemd, то вам
|
||||
стоит обратить внимание на
|
||||
\href{http://www.freedesktop.org/software/systemd/man/bootup.html}{новую
|
||||
страницу руководства}, где представлена псевгдорафическая потоковая диаграмма,
|
||||
описывающая процесс загрузки и роль ключевых юнитов.
|
||||
|
||||
\end{document}
|
||||
|
||||
vim:ft=tex:tw=80:spell:spelllang=ru
|
||||
|
||||
Reference in New Issue
Block a user