Version v10.0 (2012-06-03 02:30) [AUTO]
This commit is contained in:
nnz1024
73
s4a.tex
73
s4a.tex
@@ -2568,7 +2568,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 +2596,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~--- ничто
|
||||
@@ -2881,7 +2881,7 @@ LimitFSIZE=0
|
||||
\subsection{Контроль доступа служб к файлам устройств}
|
||||
|
||||
Файлы устройств предоставляют приложениям интерфейс для доступа к ядру и
|
||||
драйверам. Причем драйверы, как правило менее тщательно тестируются и не~так
|
||||
драйверам. Причем драйверы, как правило, менее тщательно тестируются и не~так
|
||||
аккуратно проверяются на предмет наличия уязвимостей, по сравнению с основными
|
||||
компонентами ядра. Именно поэтому драйверы часто становятся объектами атаки
|
||||
злоумышленников. systemd позволяет контролировать доступ к устройствам
|
||||
@@ -2926,6 +2926,71 @@ 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 лет назад.
|
||||
|
||||
\end{document}
|
||||
|
||||
vim:ft=tex:tw=80:spell:spelllang=ru
|
||||
|
||||
Reference in New Issue
Block a user