Version v9.2 (2012-01-30 02:30) [AUTO]

s4a.tex

@@ -6,17 +6,21 @@
 \usepackage[T1,T2A]{fontenc}
 \usepackage{indentfirst} % Отступ в первом абзаце главы 
 \usepackage{fancyvrb} % Продвинутые листинги и in-line commands
-% listings для данной ситуации, имхо, избыточен
+% listings в данной ситуации, IMHO, избыточен
 \usepackage{pdflscape} % Внимание! При выводе в DVI выборочный
 % поворот страниц работать не будет, хотя текст будет повернут.
 \usepackage[colorlinks,unicode,urlcolor=blue]{hyperref}
 % Заполняем поля PDF уже со включенной опцией unicode
 \hypersetup{pdftitle={systemd для администраторов},%
 pdfauthor={Lennart Poettering, Sergey Ptashnick}}
+% Не засоряем оглавление подразделами
+\setcounter{tocdepth}{1}
 % Несколько сокращений
 \newcommand{\sectiona}[1]{\section*{#1}\addcontentsline{toc}{section}{#1}}
 \newcommand{\hreftt}[2]{\href{#1}{\texttt{#2}}}
 \newcommand{\tbs}{\textbackslash}
+\newenvironment{caveat}[1][]{\smallskip\par\textbf{Предупреждение#1: }}%
+	{\smallskip\par}
 % Примерный аналог символа \testSFii (присутствует в листингах),
 % но без использования пакета pmboxdraw, средствами graphicx
 \newcommand{\mytextSFii}{\raisebox{0pt}[0pt][\depth]{%
@@ -46,7 +50,8 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}}
 доступна на личной странице переводчика:
 \url{http://www2.kangran.su/~nnz/pub/s4a/}}\\%
 \small Данный документ доступен на условиях лицензии
-\href{http://creativecommons.org/licenses/by-sa/3.0/legalcode}{CC-BY-SA}}
+\href{http://creativecommons.org/licenses/by-sa/3.0/legalcode}{CC-BY-SA 3.0
+Unported}}
 \maketitle
 \tableofcontents%\newpage
 \sectiona{Предисловие автора}
@@ -88,7 +93,7 @@ systemd эти сообщения будут пробегать все быст
 запуска служб бывает очень важна, а просматривать ее все тяжелее. systemd
 предлагает выход из этой ситуации: он отслеживает и запоминает факты успешного
 или неудачного запуска служб на этапе загрузки, а также сбои служб во время
-работы. К таким случая относятся выходы с ненулевым кодом, ошибки
+работы. К таким случаям относятся выходы с ненулевым кодом, ошибки
 сегментирования и т.п. Введя +systemctl status+ в своей командной оболочке, вы
 можете ознакомиться с состоянием всех служб, как <<родных>> (native) для
 systemd, так и классических SysV/LSB служб, поддерживаемых в целях
@@ -252,7 +257,7 @@ CGI-программы, а демон cron~--- команды, предписа
 себе имя, скажем, на httpd.}.
 
 systemd предлагает простой путь для решения обсуждаемой задачи. Запуская
-очередной новый процесс, systemd помещает его в отдельную контрольную группу
+новый процесс, systemd помещает его в отдельную контрольную группу
 с соответствующим именем. Контрольные группы Linux предоставляют очень
 удобный инструмент для иерархической структуризации процессов: когда
 какой-либо процесс порождает потомка, этот потомок автоматически включается в
@@ -400,7 +405,7 @@ $ ps xawf -eo pid,user,cgroup,args
 \end{landscape}
 
 Обратите внимание на третий столбец, показывающий имя контрольной группы,
-которое systemd присваивает каждому процессу. Например, процесс +udev+
+в которую systemd поместил данный процесс. Например, процесс +udev+
 находится в группе +name=systemd:/systemd-1/sysinit.service+. В эту группу
 входят процессы, порожденные службой +sysinit.service+, которая запускается
 на ранней стадии загрузки.
@@ -594,7 +599,7 @@ systemd именует группы в соответствии с назван
 Эти скрипты пишутся на языке Bourne Shell (+/bin/sh+), располагаются в
 специальном каталоге (обычно +/etc/rc.d/init.d/+) и вызываются с одним из
 стандартных параметров (+start+, +stop+, +reload+ и т.п.)~--- таким образом
-указывается действие, которое необходимо прозвести над службой (запустить,
+указывается действие, которое необходимо произвести над службой (запустить,
 остановить, заставить перечитать конфигурацию). При запуске службы такой
 скрипт, как правило, вызывает бинарник демона, который, в свою очередь,
 форкается, порождая фоновый процесс (т.е. демонизируется). Заметим, что
@@ -624,7 +629,7 @@ service-файл будет работать в любом дистрибути
 \href{http://0pointer.de/public/systemd-man/daemon.html}{страницу} официальной
 документации. 
 
-Итак, приступим. В качестве пример возьмем init-скрипт демона ABRT (Automatic
+Итак, приступим. В качестве примера возьмем init-скрипт демона ABRT (Automatic
 Bug Reporting Tool, службы, занимающейся сбором crash dump'ов). Исходный
 скрипт (в варианте для дистрибутива Fedora) можно загрузить
 \href{http://0pointer.de/public/abrtd}{здесь}.
@@ -640,7 +645,7 @@ Bug Reporting Tool, службы, занимающейся сбором crash du
 	\item Строка описания службы: <<Daemon to detect crashing apps>>. Как
 		нетрудно заметить, комментарии в заголовке скрипта весьма
 		пространны и описывают не~сколько саму службу, сколько
-		скрипт, ее запускающий. service-файлы systemd также включают
+		скрипт, ее запускающий. service-файлы systemd тоже содержат
 		описание, но оно относится исключительно к службе, а не~к
 		service-файлу. 
 	\item LSB-заголовок\footnote{LSB-заголовок~--- определенная в
@@ -722,7 +727,7 @@ WantedBy=multi-user.target
 поддерживают активацию через сокет. В системах, использующих такие
 реализации, явное указание +After=syslog.target+ будет избыточным, так
 как соответствующая функциональность поддерживается автоматически. Однако,
-эту строчку стоит все-таки указать для обеспечения совместимости с системами,
+эту строчку все-таки стоит указать для обеспечения совместимости с системами,
 использующими устаревшие реализации демона системного лога.}. Эта информация,
 как мы помним, была указана в LSB-заголовке исходного init-скрипта. В нашем
 конфигурационном файле мы указываем зависимость от демона системного лога при
@@ -807,37 +812,37 @@ WantedBy=multi-user.target
 \end{Verbatim}
 
 Чем же новый вариант отличается от предыдущего? Ну, прежде всего, мы уточнили
-описание службы. Однако, ключевым изменением является замена значения +Type+ с +forking+
-на +dbus+ и связанные с ней изменения: добавление имени службы в шине D-Bus
-(директива +BusName+) и задание дополнительных аргументов abrtd <<+-d -s+>>. Но
-зачем вообще нужна эта замена? Каков ее практический смысл? Чтобы ответить на
-этот вопрос, мы снова возвращаемся к демонизации. В ходе этой операции процесс
-дважды форкается и отключается от всех терминалов. Это очень удобно при запуске
-демона через скрипт, но в случае использования таких продвинутых систем
-инициализации, как systemd, подобное поведение не~дает никаких преимуществ, но
-вызывает неоправданные задержки. Даже если мы оставим в стороне вопрос скорости
-загрузки, останется такой важный аспект, как отслеживание состояния служб.
-systemd решает и эту задачу, контролируя работу службы и при необходимости
-реагируя на различные события. Например, при неожиданном падении основного
-процесса службы, systemd должен зарегистрировать идентификатор и код выхода
-процесса, также, в зависимости от настроек, он может попытаться перезапустить
-службу, либо активировать какой-либо заранее заданный юнит. Операция
-демонизации несколько затрудняет решение этих задач, так как обычно довольно
-сложно найти связь демонизированного процесса с исходным (собственно, смысл
-демонизации как раз и сводится к уничтожению этой связи) и, соответственно, для
-systemd сложнее определить, какой из порожденных в рамках данной службы
-процессов является основным. Чтобы упростить для него решение этой задачи, мы и
-воспользовались типом запуска +dbus+. Он подходит для всех служб, которые в
-конце процесса инициализации регистрируют свое имя на шине D-Bus\footnote{В
-настоящее время практически все службы дистрибутива Fedora после запуска
-регистрируется на шине D-Bus.}. ABRTd относится к ним.  С новыми настройками,
-systemd запустит процесс abrtd, который уже не~будет форкаться (согласно
-указанным нами ключам <<+-d -s+>>), и в качестве момента окончания периода
-запуска данной службы systemd будет рассматривать момент регистрации имени
-+com.redhat.abrt+ на шине D-Bus. В этом случае основным для данной службы будет
-считаться процесс, непосредственно порожденный systemd.  Таким образом, systemd
-располагает удобным методом для определения момента окончания запуска службы, а
-также может легко отслеживать ее состояние. 
+описание службы. Однако, ключевым изменением является замена значения +Type+ с
++forking+ на +dbus+ и связанные с ней изменения: добавление имени службы в шине
+D-Bus (директива +BusName+) и задание дополнительных аргументов abrtd
+<<+-d -s+>>. Но зачем вообще нужна эта замена? Каков ее практический смысл?
+Чтобы ответить на этот вопрос, мы снова возвращаемся к демонизации. В ходе
+данной операции процесс дважды форкается и отключается от всех терминалов. Это
+очень удобно при запуске демона через скрипт, но в случае использования таких
+продвинутых систем инициализации, как systemd, подобное поведение не~дает
+никаких преимуществ, но вызывает неоправданные задержки. Даже если мы оставим в
+стороне вопрос скорости загрузки, останется такой важный аспект, как
+отслеживание состояния служб.  systemd решает и эту задачу, контролируя работу
+службы и при необходимости реагируя на различные события. Например, при
+неожиданном падении основного процесса службы, systemd должен зарегистрировать
+идентификатор и код выхода процесса, также, в зависимости от настроек, он может
+попытаться перезапустить службу, либо активировать какой-либо заранее заданный
+юнит. Операция демонизации несколько затрудняет решение этих задач, так как
+обычно довольно сложно найти связь демонизированного процесса с исходным
+(собственно, смысл демонизации как раз и сводится к уничтожению этой связи) и,
+соответственно, для systemd сложнее определить, какой из порожденных в рамках
+данной службы процессов является основным. Чтобы упростить для него решение этой
+задачи, мы и воспользовались типом запуска +dbus+. Он подходит для всех служб,
+которые в конце процесса инициализации регистрируют свое имя на шине
+D-Bus\footnote{В настоящее время практически все службы дистрибутива Fedora
+после запуска регистрируется на шине D-Bus.}. ABRTd относится к ним.  С новыми
+настройками, systemd запустит процесс abrtd, который уже не~будет форкаться
+(согласно указанным нами ключам <<+-d -s+>>), и в качестве момента окончания
+периода запуска данной службы systemd будет рассматривать момент регистрации
+имени +com.redhat.abrt+ на шине D-Bus. В этом случае основным для данной службы
+будет считаться процесс, непосредственно порожденный systemd.  Таким образом,
+systemd располагает удобным методом для определения момента окончания запуска
+службы, а также может легко отслеживать ее состояние. 
 
 Собственно, это все, что нужно было сделать. Мы получили простой
 конфигурационный файл, в 10 строчках которого содержится больше полезной
@@ -853,7 +858,7 @@ systemd запустит процесс abrtd, который уже не~буд
 для процессов, активно использующих CPU. 
 
 За более подробным описанием всех опций настройки, вы можете обратиться к
-страницам рукводства
+страницам руководства
 \href{http://0pointer.de/public/systemd-man/systemd.unit.html}{systemd.unit},
 \href{http://0pointer.de/public/systemd-man/systemd.service.html}{systemd.service},
 \href{http://0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec}. Полный
@@ -922,13 +927,13 @@ Apache, crond, atd, которые по роду служебной деятел
 конфигурационном файле службы (см.
 \href{http://www.0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}).}.
 
-В некоторый случах возникает необходимость отправить сигнал именно основному
+В некоторых случаях возникает необходимость отправить сигнал именно основному
 процессу службы. Например, используя +SIGHUP+, мы можем заставить демона
-перечитать файлы конфигурации. Разумеется, передавать HUP вспомогательным процессам
-в этом случае совершенно необязательно. Для решения подобной
-задачи неплохо подойдет и классический метод с pid-файлом, однако у
-systemd и на этот случай есть простое решение, избавляющее вас от
-необходимости искать нужный файл: 
+перечитать файлы конфигурации. Разумеется, передавать HUP вспомогательным
+процессам в этом случае совершенно необязательно. Для решения подобной задачи
+неплохо подойдет и классический метод с pid-файлом, однако у systemd и на этот
+случай есть простое решение, избавляющее вас от необходимости искать нужный
+файл: 
 
 \begin{Verbatim}
 # systemctl kill -s HUP --kill-who=main crond.service
@@ -1130,7 +1135,7 @@ systemd и на этот случай есть простое решение, и
 		вся иерархия файловых систем гостевой ОС монтируется или
 		создается в каталоге системы-хоста, и при запуске оболочки (или
 		любого другого приложения) внутри этой иерархии, в качестве
-		корня используется этот каталог. Система, которую <<видят>>
+		корня используется данный каталог. Система, которую <<видят>>
 		такие программы, может сильно отличаться от ОС хоста. Например,
 		это может быть другой дистрибутив, или даже другая аппаратная
 		архитектура (запуск i386-гостя на x86\_64-хосте). Гостевая ОС
@@ -1363,10 +1368,10 @@ Linux, которая позиционируется как современна
 
 Итак, что же такого хорошего в +systemd-nspawn+?
 \begin{enumerate}
-	\item Использовать эту утилиту очень просто. Вам даже не~нужно вручную монтировать
-		внутри окружения +/proc+ и +/sys+~--- она сделает это за вас, а
-		ядро автоматически отмонтирует их, когда последний процесс
-		контейнера завершится.
+	\item Использовать эту утилиту очень просто. Вам даже не~нужно вручную
+		монтировать внутри окружения +/proc+ и +/sys+~--- она сделает
+		это за вас, а ядро автоматически отмонтирует их, когда последний
+		процесс контейнера завершится.
 	\item Обеспечивается надежная изоляция, предотвращающая случайные
 		изменения параметров ОС хоста изнутри контейнера.
 	\item Теперь вы можете загрузить внутри контейнера полноценную ОС, а
@@ -1408,7 +1413,7 @@ systemd уже подготовлен для работы внутри таки
 
 \section{Поиск виновных}
 
-Fedora~15\footnote{Величайший в истории релиз свободной ОС}
+Fedora~15\footnote{Величайший в истории релиз свободной ОС.}
 является первым релизом Fedora, использующим systemd в качестве системы
 инициализации по умолчанию. Основной нашей целью при работе над выпуском F15
 является обеспечение полной взаимной интеграции и корректной работы всех
@@ -1490,21 +1495,21 @@ $ systemd-analyze blame
 
 Рассмотрим повнимательнее первого осквернителя нашей загрузки: службу
 +udev-settle.service+. Почему ей требуется так много времени для запуска, и что
-мы можем с этим сделать? Эта служба выполняет очень простую задачу: она ожидает,
-пока udev завершит опрос устройств, после чего завершается. Опрос же устройств
-может занимать довольно много времени. Например, в нашем случае опрос устройств
-занимает более 6~секунд из-за подключенного к компьютеру 3G-модема, в котором
-отсутствует SIM-карта. Этот модем очень долго отвечает на запросы udev. Опрос
-устройств является частью схемы, обеспечивающей работу ModemManager'а и
+мы можем с этим сделать? Данная служба выполняет очень простую функцию: она
+ожидает, пока udev завершит опрос устройств, после чего завершается. Опрос же
+устройств может занимать довольно много времени. Например, в нашем случае опрос
+устройств длится более 6~секунд из-за подключенного к компьютеру 3G-модема, в
+котором отсутствует SIM-карта. Этот модем очень долго отвечает на запросы udev.
+Опрос устройств является частью схемы, обеспечивающей работу ModemManager'а и
 позволяющей NetworkManager'у упростить для вас настройку 3G. Казалось бы,
 очевидно, что виновником задержки является именно ModemManager, так как опрос
 устройств для него занимает слишком много времени. Но такое обвинение будет
-заведомо ошибочным. Дело в том, что опрос устройств очень часто оказывается довольно
-длительной процедурой. Медленный опрос 3G-устройств для ModemManager является
-частным случаем, отражающим это общее правило. Хорошая система опроса устройств
-обязательно должна учитывать тот факт, что операция опроса любого из устройств
-может затянуться надолго. Истинной причиной наших проблем является необходимость
-ожидать завершения опроса устройств, т.е., наличие службы
+заведомо ошибочным. Дело в том, что опрос устройств очень часто оказывается
+довольно длительной процедурой. Медленный опрос 3G-устройств для ModemManager
+является частным случаем, отражающим это общее правило. Хорошая система опроса
+устройств обязательно должна учитывать тот факт, что операция опроса любого из
+устройств может затянуться надолго. Истинной причиной наших проблем является
+необходимость ожидать завершения опроса, т.е., наличие службы
 +udev-settle.service+ как обязательной части нашего процесса загрузки.
 
 Но почему эта служба вообще присутствует в нашем процессе загрузки? На самом
@@ -1628,7 +1633,7 @@ $ eog plot.svg
 именно происходило во время загрузки, и отображает соответствующие графики
 использования процессора и ввода-вывода. +systemd-analyze plot+ оперирует более
 высокоуровневой информацией: сколько времени затратила та или иная служба во
-время запуска, и какие службы были вынуждены ее ожидать. Используя оба эти
+время запуска, и какие службы были вынуждены ее ожидать. Используя оба этих
 инструмента, вы значительно упростите себе поиск причин замедления вашей
 загрузки.
 
@@ -1700,14 +1705,14 @@ shell-скриптов, разработанных для этих задач р
 	\item Автоматический запуск +getty+ на serial-консолях.
 	\item Взаимодействие с Plymouth.
 	\item Создание уникального идентификатора системы.
-	\item Установка часового пояса.
+	\item Настройка часового пояса.
 \end{itemize}
 
 В стандартной установке Fedora~15 запуск shell-скриптов требуется только для
 некоторых устаревших служб, а также для подсистемы хранения данных (поддержка
 LVM, RAID и multipath). Если они вам не~нужны, вы легко можете отключить их, и
-наслаждаться загрузкой, полностью очищенной от shell-костылей (я это сделал уже
-давно). Такая загрузка является уникальной возможностью Linux-систем.
+наслаждаться загрузкой, полностью очищенной от shell-костылей (лично я это
+сделал уже давно). Такая загрузка является уникальной возможностью Linux-систем.
 
 Большинство перечисленных выше компонентов настраиваются через конфигурационные
 файлы в каталоге +/etc+. Некоторые из этих файлов стандартизированы для всех
@@ -1716,9 +1721,9 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
 +/etc/crypttab+, +/etc/sysctl.conf+. Однако множество других, нестандартно
 расположенных файлов и каталогов вынуждали нас добавлять в код огромное
 количество операторов +#ifdef+, чтобы обеспечить поддержку различных вариантов
-расположения конфигураций в разных дистрибутивах. Такой положение дел сильно
+расположения конфигураций в разных дистрибутивах. Такое положение дел сильно
 усложняет жизнь нам всем, и при этом ничем не~оправдано~--- все эти файлы решают
-одни и те же задачи, но делают это немного по-разному.
+одни и те же задачи, просто немного по-разному.
 
 Чтобы улучшить ситуацию и установить единый стандарт расположения базовых
 конфигурационных файлов во всех дистрибутивах, мы заставили systemd пользоваться
@@ -1747,7 +1752,7 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
 		\hreftt{http://0pointer.de/public/systemd-man/modules-load.d.html}{/etc/modules-load.d/*.conf}:
 		каталог\footnote{Прим. перев.: Для описания этого и трех
 		последующих каталогов автор пользуется термином <<drop-in
-		directory>>. Этот термин означает каталог, в который можно
+		directory>>. Данный термин означает каталог, в который можно
 		поместить множество независимых файлов настроек, и при чтении
 		конфигурации все эти файлы будут обработаны (впрочем, часто
 		накладывается ограничение~--- обрабатываются только файлы с
@@ -1818,7 +1823,7 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
 systemd, но уже сейчас в их число входят практически все ключевые дистрибутивы,
 \href{http://www.ubuntu.com/}{за исключением
 одного}\footnote{Прим. перев.: В конце 2010~года энтузиаст Andrew Edmunds
-\href{http://cgit.freedesktop.org/systemd/commit/?id=858dae181bb5461201ac1c04732d3ef4c67a0256}{добавил}
+\href{http://cgit.freedesktop.org/systemd/systemd/commit/?id=858dae181bb5461201ac1c04732d3ef4c67a0256}{добавил}
 в systemd базовую поддержку Ubuntu и
 \href{https://wiki.ubuntu.com/systemd}{подготовил} соответствующие пакеты,
 однако его инициатива не~встретила поддержки среди менеджеров Canonical. На
@@ -1826,7 +1831,7 @@ systemd, но уже сейчас в их число входят практич
 этом есть что-то от <<проблемы курицы и яйца>>: стандарт становится настоящим
 стандартом только тогда, когда ему начинают следовать. В будущем мы намерены
 аккуратно форсировать процесс перехода на новые конфигурационные файлы:
-поддержка старых файлов будет удалена из systemd. Разумеется, этот процесс будет
+поддержка старых файлов будет удалена из systemd. Разумеется, процесс будет
 идти медленно, шаг за шагом. Но конечной его целью является переход всех
 дистрибутивов на единый набор базовых конфигурационных файлов.
 
@@ -1865,9 +1870,9 @@ shed)~--- если первое из этих решений принимает
 \textbf{Помогите нам стандартизировать Linux! Используйте новые конфигурационные
 файлы! Поддерживайте их в апстриме, поддерживайте их во всех дистрибутивах!}
 
-Да, и если у вас возникнет такой вопрос: да, все эти файлы так или иначе
+И если у вас возникнет такой вопрос: да, все эти файлы так или иначе
 обсуждались с разными разработчиками из различных дистрибутивов. И некоторые из
-этих разработчиков планируют обеспечить поддержку новой конфигурации даже в
+разработчиков планируют обеспечить поддержку новой конфигурации даже в
 системах без systemd.
 
 \section{О судьбе /etc/sysconfig и /etc/default}
@@ -1903,15 +1908,15 @@ shell это соответствует оператору-точке <<+.+>>.
 окружения, определенные во включаемом коде. Как правило, код для включения
 не~содержит shebang'а (+#!/bin/sh+ в начале файла).} shell-скриптами, содержащими,
 главным образом, определения переменных. Большинство файлов из этих каталогов
-включаются в одноименные скрипты SysV init. Этот принцип отражен в
+включаются в одноименные скрипты SysV init. Данный принцип отражен в
 \href{http://www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit}{Debian
 Policy Manual (раздел 9.3.2)} и в
 \href{http://fedoraproject.org/wiki/Packaging:SysVInitScript}{Fedora Packaging
-Guidelines}, однако в обоих этих дистрибутивах иногда встречаются файлы,
-не~соответствующие такой схеме, например, не~имеющие соответствующего
+Guidelines}, однако в обоих дистрибутивах иногда встречаются файлы,
+не~соответствующие описанной схеме, например, не~имеющие соответствующего
 init-скрипта, или даже сами не~являющиеся скриптами.
 
-Но почему вообще появились эти каталоги? Чтобы ответить на этот вопрос,
+Но почему вообще появились эти каталоги? Чтобы ответить на такой вопрос,
 обратимся к истории развития концепции SysV init-скриптов. Исторически,
 сложилось так, что они располагаются в каталоге под названием +/etc/rc.d/init.d+
 (или что-то похожее).  Отметим, что каталог +/etc+ вообще-то предназначен для
@@ -1960,16 +1965,16 @@ init-скрипта, или даже сами не~являющиеся скри
 +/etc/sysconfig+ (+/etc/default+) и почему этим каталогам нет места в мире
 systemd?
 \begin{itemize}
-	\item Прежде всего, утрачены основная цель и смысл существования этих
+	\item Прежде всего, утрачены основная цель и смысл существования таких
 		каталогов: файлы конфигурации юнитов systemd не~являются
 		программами, в отличие от init-скриптов SysV. Эти файлы
 		представляют собой простые, декларативные описания конкретных
 		задач и функций, и обычно содержат не~более шести строк. Они
 		легко могут быть сгенерированы и проанализованы без
 		использования Bourne shell. Их легко читать и понимать. Кроме
-		того, их легко модифицировать: достаточно скопировать их из
+		того, их легко модифицировать: достаточно скопировать файл из
 		+/lib/systemd/system+ в +/etc/systemd/system+, после чего внести
-		необходимые изменения в скопированный файл (при этом можно быть
+		в созданную копию необходимые изменения (при этом можно быть
 		уверенным, что изменения не~будут затерты пакетным менеджером).
 		Изначальная причина появления обсуждаемых каталогов~---
 		необходимость разделять код и параметры конфигурации~--- больше
@@ -2064,7 +2069,7 @@ systemd?
 		настоящее время не~поддерживается автоматическая загрузка
 		модулей на основании информации о возможностях процессора,
 		однако это будет исправлено в ближайшем будущем\footnote{Прим.
-		перев.: Патчи от разработчиков systemd уже приняты в ядро, и
+		перев.: Необходимые патчи уже приняты в ядро, и
 		соответствующая функция поддерживается Linux, начиная с версии
 		3.3.}. В случае, если нужный вам модуль ядра все же не~может
 		быть подгружен автоматически, все равно существует гораздо более
@@ -2175,7 +2180,7 @@ systemd?
 
 Получив такую команду, systemd сначала пытается найти файл конфигурации юнита с
 именем, точно соответствующим запрошенному. Если такой файл найти не~удается
-(при работе с экземплярами сервисов обычно так и происходит), из имени файла
+(при работе с экземплярами служб обычно так и происходит), из имени файла
 удаляется идентификатор экземпляра, и полученное имя используется при поиске
 \emph{шаблона} конфигурации. В нашем случае, если отсутствует файл с именем
 +serial-getty@ttyUSB0.service+, используется файл-шаблон под названием
@@ -2199,7 +2204,7 @@ RestartSec=0
 параметры конфигурации, обеспечивающие совместимость с SysV, очистку экрана и
 удаление предыдущих пользователей с текущего TTY. Если вам интересно, можете
 посмотреть
-\href{http://cgit.freedesktop.org/systemd/plain/units/serial-getty@.service.m4}{полную
+\href{http://cgit.freedesktop.org/systemd/systemd/plain/units/serial-getty@.service.m4}{полную
 версию}.)
 
 Этот файл похож на обычный файл конфигурации юнита, с единственным отличием: в
@@ -2207,7 +2212,7 @@ RestartSec=0
 заменяет эти спецификаторы на идентификатор экземпляра службы. В нашем случае,
 при обращении к экземпляру +serial-getty@ttyUSB0.service+, они заменяются на
 <<+ttyUSB0+>>. Результат такой замены можно проверить, например, запросив
-состояние для этой службы:
+состояние для нашей службы:
 \begin{Verbatim}[commandchars=\\\{\}]
 $ systemctl status serial-getty@ttyUSB0.service
 serial-getty@ttyUSB0.service - Getty on ttyUSB0
@@ -2238,7 +2243,7 @@ systemd предоставляет простой в использовании
 
 Иногда возникает необходимость отказаться от использования общего шаблона
 для конкретного экземпляра (т.е. конфигурация данного экземпляра настолько
-сильно отличается от конфигурации остальных экземпляров данной службы, что
+сильно отличается от параметров остальных экземпляров данной службы, что
 механизм шаблонов оказывается неэффективен). Специально для таких случаев, в
 systemd и заложен предварительный поиск файла с именем, точно соответствующим
 указанному (прежде чем использовать общий шаблон). Таким образом, вы можете
@@ -2350,7 +2355,7 @@ systemd прежде всего ориентирована на локальны
 передавать запускаемой службе только один сокет, который формируется из потоков
 STDIN и STDOUT запущенного процесса. Поддержка этого механизма также
 присутствует в systemd~--- для обеспечения совместимости со множеством служб,
-поддерживающих сокет-активацию только в стиле inetd.
+у которых сокет-активация реализована только в стиле inetd.
 
 Прежде, чем мы перейдем к примерам, рассмотрим три различных схемы, использующих
 сокет-активацию:
@@ -2371,7 +2376,7 @@ STDIN и STDOUT запущенного процесса. Поддержка эт
 		действительно понадобится. Пример~--- CUPS.
 	\item \textbf{Сокет-активация для служб, запускающих по экземпляру на
 		каждое соединение:} сокеты создаются на ранней стадии загрузки,
-		и при каждом входящем соединении создается экземпляр службы,
+		и при каждом входящем соединении запускается экземпляр службы,
 		которому передается сокет соединения (слушающий сокет при этом
 		остается у суперсервера, inetd или systemd). Эта схема подходит
 		для редко используемых служб, не~критичных по производительности
@@ -2408,12 +2413,12 @@ STDIN и STDOUT запущенного процесса. Поддержка эт
 большинстве систем, где она используется, частота обращений к ней не~превышает
 одного раза в час (как правило, она \emph{значительно} меньше этой величины).
 SSH уже очень давно поддерживает сокет-активацию в стиле inetd, согласно третьей
-схеме. Так как необходимость в этой службе возникает сравнительно редко, и
+схеме. Так как необходимость в данной службе возникает сравнительно редко, и
 число одновременно работающих процессов обычно невелико, она хорошо подходит для
 использования по этой схеме. Перерасход системных ресурсов должен быть
 незначителен: большую часть времени такая служба фактически не~выполняется и
 не~тратит ресурсы. Когда кто-либо начинает сеанс удаленной работы, она
-запускается, и останавливается немедленно по завершению сеанса, освобождая
+запускается, и останавливается немедленно по завершении сеанса, освобождая
 ресурсы. Что ж, посмотрим, как в systemd можно воспользоваться режимом
 совместимости с inetd и обеспечить сокет-активацию SSH.
 
@@ -2568,17 +2573,30 @@ sshd.socket                                   loaded active listening     SSH So
 xinetd, вы заметите, что далеко не~все эти опции доступны в systemd. Например, в
 systemd нет и никогда не~будет встроенных служб +echo+, +time+, +daytime+,
 +discard+ и т.д. Кроме того, systemd не~поддерживает TCPMUX и RPC. Впрочем,
-большинство этих опций уже не~актуальны в наше время. Подавляющее большинство
-inetd-служб не~используют эти опции (в частности, ни~одна из имеющихся в Fedora
-xinetd-служб не~требует поддержки перечисленных опций). Стоит отметить, что
-xinetd имеет некоторые интересные возможности, отсутствующие в systemd,
-например, списки контроля доступа для IP-адресов (IP ACL). Однако, большинство
-администраторов, скорее всего, согласятся, что настройка барндмауэра является
-более эффективным решением подобных задач, а для ценителей устаревших технологий
-systemd предлагает поддержку tcpwrap.  С другой стороны, systemd тоже
-предоставляет ряд возможностей, отсутствующих в xinetd, в частности,
-индивидуальный контроль над каждым экземпляром службы (см.  выше), и куда более
-полный
+б\'{о}льшая часть этих опций уже не~актуальна в наше время. Подавляющее
+большинство inetd-служб не~используют эти опции (в частности, ни~одна из
+имеющихся в Fedora xinetd-служб не~требует поддержки перечисленных опций). Стоит
+отметить, что xinetd имеет некоторые интересные возможности, отсутствующие в
+systemd, например, списки контроля доступа для IP-адресов (IP ACL). Однако,
+большинство администраторов, скорее всего, согласятся, что настройка брандмауэра
+является более эффективным решением подобных задач\footnote{Прим. перев.: Стоит
+отметить, что приведенный пример является не~единственным случаем, когда
+возможности брандмауэра  Linux дублируются опциями xinetd. Например, количество
+соединений с каждого хоста может быть ограничено критерием connlimit, а
+скорость поступления входящих соединений можно контролировать сочетанием
+критериев limit и conntrack (+ctstate NEW+). Критерий recent позволяет создать
+аналог простейшей IDS/IPS, реализованной механизмом SENSORS в xinetd. Кроме
+того, в ряде случаев возможности брандмауэра значительно превосходят
+функциональность xinetd. Например, критерий hashlimit, опять-таки в сочетании с
+conntrack, позволяет ограничить скорость поступления входящих соединений с
+каждого хоста (не~путать с критерием connlimit, ограничивающим количество
+одновременно открытых соединений). Также стоит отметить, что интегрированная в
+Linux подсистема ipset гораздо лучше подходит для работы с большими списками
+разрешенных/запрещенных адресов, нежели встроенные механизмы xinetd.}, а для
+ценителей устаревших технологий systemd предлагает поддержку tcpwrap.  С другой
+стороны, systemd тоже предоставляет ряд возможностей, отсутствующих в xinetd, в
+частности, индивидуальный контроль над каждым экземпляром службы (см.  выше), и
+куда более полный
 \href{http://0pointer.de/public/systemd-man/systemd.exec.html}{список настроек}
 для контроля окружения, в котором запускаются экземпляры. Я надеюсь, что
 возможностей systemd должно быть достаточно для решения большинства задач, а в
@@ -2593,6 +2611,321 @@ systemd предлагает поддержку tcpwrap.  С другой сто
 systemd. Но, конечно, будет лучше, если этим займутся разработчики из апстрима
 приложения, или сопровождающие вашего дистрибутива.
 
+\section{К вопросу о безопасности}
+
+Одно из важнейших достоинств Unix-систем~--- концепция разделения привилегий
+между различными компонентами ОС. В частности, службы обычно работают от имени
+специальных системных пользователей, имеющих ограниченные полномочия, что
+позволяет уменьшить ущерб для системы в случае взлома этих служб.
+
+Однако, такой подход предоставляет лишь самую минимальную защиту, так как
+системные службы, хотя уже и не~получают полномочий администратора (root), все
+равно имеют практически те же права, что и обычные пользователи. Чтобы
+обеспечить более эффективную защиту, нужно поставить более жесткие ограничения,
+отняв у служб некоторые привилегии, присущие обычным пользователям.
+
+Такая возможность предоставляется системами мандатного контроля доступа (далее
+MAC, от Mandatory Access Control), например, SELinux. Если вам нужно обеспечить
+высокий уровень безопасности на своем сервере, то вам определенно стоит обратить
+свое внимание на SELinux. Что же касается systemd, то он предоставляет
+разработчикам и администраторам целый арсенал возможностей по ограничению
+локальных служб, и эти механизмы работают независимо от систем MAC.  Таким
+образом, вне зависимости от того, смогли ли вы разобраться с SELinux~--- у вас
+появляется еще несколько инструментов, позволяющих повысить уровень
+безопасности.
+
+В этой главе мы рассмотрим несколько таких опций, предоставляемых systemd, и
+обсудим вопросы их практического применения. Реализация этих опций основана на
+использовании ряда уникальных технологий безопасности, интегрированных в ядро
+Linux уже очень давно, но при этом практически неизвестных для большинства
+разработчиков. Мы постарались сделать соответствующие опции systemd максимально
+простыми в использовании, чтобы заинтересовать администраторов и апстримных
+разработчиков. Вот краткий перечень наиболее интересных возможностей:
+\begin{itemize}
+	\item Изолирование служб от сети
+	\item Предоставление службам независимых каталогов +/tmp+
+	\item Ограничение доступа служб к отдельным каталогам
+	\item Принудительное отключение полномочий (capabilities) для служб
+	\item Запрет форка, ограничение на создание файлов
+	\item Контроль доступа служб к файлам устройств
+\end{itemize}
+
+Все эти опции описаны в man-страницах systemd, главным образом, в
+\href{http://0pointer.de/public/systemd-man/systemd.exec.html}{systemd.exec(5)}.
+Если вам потребуются какие-либо уточнения, пожалуйста, обратитесь к этим
+страницам.
+
+Все эти опции доступны на системах с systemd, вне зависимости от использования
+SELinux или любой другой реализации MAC.
+
+Все эти опции не~так уж и обременительны, и поэтому их разумнее будет
+использовать даже в тех случаях, когда явная необходимость в них, казалось бы,
+отсутствует. Например: даже если вы полагаете, что ваша служба никогда не~пишет
+в каталог +/tmp+, и поэтому использование +PrivateTmp=yes+ (см. ниже) вроде бы и
+не~обязательно~--- лучше включить эту опцию, просто потому, что вы не~можете
+знать наверняка, как будут вести себя используемые вами сторонние библиотеки (и
+плагины для них). В частности, вы никогда не~узнаете, какие модули NSS могут
+быть включены в каждой конкретной системе, и пользуются ли они каталогом +/tmp+.
+
+Мы надеемся, что перечисленные опции окажутся полезными как для администраторов,
+защищающих свои системы, так и для апстримных разработчиков, желающих сделать
+свои службы безопасными <<из коробки>>. Мы настоятельно рекомендуем
+разработчикам использовать такие опции по умолчанию в апстримных
+service-файлах~--- это сравнительно несложно, но дает значительные преимущества
+в плане безопасности.
+
+\subsection{Изолирование служб от сети}
+
+Простая, но мощная опция, которой вы можете воспользоваться при настройке
+службы~--- +PrivateNetwork=+:
+\begin{Verbatim}
+...
+[Service]
+ExecStart=...
+PrivateNetwork=yes
+...
+\end{Verbatim}
+Добавление этой строчки обеспечивает полную изоляцию от сети всех процессов
+данной службы. Они будут видеть лишь интерфейс обратной петли (+lo+), причем
+полностью изолированный от обратной петли основной системы.  Чрезвычайно
+эффективная защита против сетевых атак.
+
+\begin{caveat}
+Некоторым службам сеть необходима для нормальной работы. Разумеется, никто и
+не~говорит о том, чтобы применять +PrivateNetwork=yes+ к сетевым службам, таким,
+как Apache. Однако даже те службы, которые не~ориентированы на сетевое
+взаимодействие, могут нуждаться в сети для нормального функционирования, и порой
+эта потребность не~вполне очевидна. Например, если ваша система хранит
+учетные записи пользователей в базе LDAP, для выполнения системных вызовов
+наподобие +getpwnam()+ может потребоваться обращение к сети.  Впрочем, даже в
+такой ситуации, как правило, можно использовать +PrivateNetwork=yes+, за
+исключением случаев, когда службе может потребоваться информация о пользователях
+с UID~$\geq1000$.
+\end{caveat}
+
+Если вас интересуют технические подробности: эта возможность реализована с
+использованием технологии сетевых пространств имен (network namespaces). При
+задействовании данной опции, для службы создается новое пространство имен, в
+котором настраивается только интерфейс обратной петли.
+
+\subsection{Предоставление службам независимых каталогов \texttt{/tmp}}
+
+Еще одна простая, но мощная опция настройки служб~--- +PrivateTmp=+:
+\begin{Verbatim}
+...
+[Service]
+ExecStart=...
+PrivateTmp=yes
+...
+\end{Verbatim}
+При задействовании этой опции, служба получит свой собственный каталог +/tmp+,
+полностью изолированный от общесистемного +/tmp+. По давно сложившейся традиции,
+в Unix-системах каталог +/tmp+ является общедоступным для всех локальных служб и
+пользователей. За все эти годы, он стал источником огромного количества проблем
+безопасности. Чаще всего встречаются атаки с использованием символьных ссылок
+(symlink attacks) и атаки на отказ в обслуживании (DoS attacks). Использование 
+независимой версии данного каталога для каждой службы делает подобные уязвимости
+практически бесполезными.
+
+Для релиза Fedora~17
+\href{https://fedoraproject.org/wiki/Features/ServicesPrivateTmp}{утверждена}
+инициатива, направленная на включение этой опции по умолчанию для большинства
+системных служб.
+
+\begin{caveat}
+Некоторые службы используют +/tmp+ не~по назначению,
+помещая туда сокеты IPC и другие подобные элементы, что само по себе уже
+является уязвимостью (хотя бы потому, что используемые при передаче информации
+файлы и каталоги должны иметь предсказуемые имена, что делает подобные службы
+уязвимыми к атакам через символьные ссылки и атакам на отказ в обслуживании).
+Подобные объекты лучше помещать в каталог +/run+, так как в нем присутствует
+строгое разделение доступа. В качестве примера такого некорректного
+использования +/tmp+ можно привести X11, размещающий там свои коммуникационные
+сокеты (впрочем, в данном конкретном случае некоторые меры безопасности все же
+присутствуют: сокеты размещаются в защищенном подкаталоге, который создается на
+ранних стадиях загрузки). Разумеется, для служб, использующих +/tmp+ в целях
+коммуникации, включение опции +PrivateTmp=yes+ недопустимо. К счастью, таких
+служб сейчас уже не~так уж и много.
+\end{caveat}
+
+Эта опция использует технологию пространств имен файловых систем (filesystem
+namespaces), реализованную в Linux. При включении данной опции, для службы
+создается новое пространство имен, отличающееся от иерархии каталогов основной
+системы только каталогом +/tmp+.
+
+\subsection{Ограничение доступа служб к отдельным каталогам}
+
+Используя опции +ReadOnlyDirectories=+ и +InaccessibleDirectories=+, вы можете
+ограничить доступ службы к указанным каталогам только чтением, либо вообще
+запретить его:
+\begin{Verbatim}
+...
+[Service]
+ExecStart=...
+InaccessibleDirectories=/home
+ReadOnlyDirectories=/var
+...
+\end{Verbatim}
+Добавление этих двух строчек в файл конфигурации, приводит к тому, что служба
+полностью утрачивает доступ к содержимому каталога +/home+ (она видит лишь
+пустой каталог с правами доступа 000), а также не~может писать внутрь каталога
++/var+.
+
+\begin{caveat}
+К сожалений, в настоящее время опция +ReadOnlyDirectories=+ не~применяется
+рекурсивно к точкам монтирования, расположенным в поддереве указанного каталога
+(т.е. файловые систем, смонтированные в подкаталогах +/var+, по-прежнему
+останутся доступными на запись, если, конечно, не~перечислить их все поименно).
+Мы собираемся исправить это в ближайшее время.
+\end{caveat}
+
+Механизм работы этой опции тоже реализован с использованием пространств имен
+файловых систем.
+
+\subsection{Принудительное отключение полномочий (capabilities) для служб}
+
+Еще одна чрезвычайно эффективная опция~--- +CapabilityBoundingSet=+, позволяющая
+контролировать список capabilities, которые смогут получить процессы службы:
+\begin{Verbatim}
+...
+[Service]
+ExecStart=...
+CapabilityBoundingSet=CAP_CHOWN CAP_KILL
+...
+\end{Verbatim}
+В нашем примере, служба может иметь лишь полномочия +CAP_CHOWN+ и +CAP_KILL+.
+Попытки какого-либо из процессов службы получить любые другие полномочия, даже с
+использованием suid-бинарников, будут пресекаться. Список возможных полномочий
+приведен на странице документации
+\href{http://linux.die.net/man/7/capabilities}{capabilities(7)}. К сожалению,
+некоторые из них являются слишком общими (разрешают очень многое), например,
++CAP_SYS_ADMIN+, однако выборочное делегирование полномочий все же является
+неплохой альтернативой запуску службы с полными административными (рутовыми)
+привилегиями.
+
+Как правило, определение списка полномочий, необходимых для работы конкретной
+службы, является довольно трудоемким процессом, требующим ряда проверок. Чтобы
+немного упростить эту задачу, мы добавили возможность создания <<черного
+списка>> привилегий, как альтернативы описанному выше механизму <<белого
+списка>>. Вместо того, чтобы указывать, какие привилегии можно оставить, вы
+можете перечислить, какие из них оставлять точно нельзя. Например: привилегия
++CAP_SYS_PTRACE+, предназначенная для отладчиков, дает очень широкие полномочия
+в отношении всех процессов системы. Очевидно, что такие службы, как Apache,
+не~занимаются отладкой чужих процессов, и поэтому мы можем спокойно отнять у них
+данную привилегию:
+\begin{Verbatim}
+...
+[Service]
+ExecStart=...
+CapabilityBoundingSet=~CAP_SYS_PTRACE
+...
+\end{Verbatim}
+Наличие символа +~+ после знака равенства инвертирует принцип работы опции:
+следующий за ним перечень привилегий рассматривается уже не~как белый, а как
+черный список.
+
+\begin{caveat}
+Некоторые службы, при отсутствии определенных привилегий, могут вести себя
+некорректно. Как уже говорилось выше, формирование списка необходимых полномочий
+для каждой конкретной службы может оказаться довольно трудной задачей, и лучше
+всего будет обратиться с соответствующим запросом к разработчикам службы.
+\end{caveat}
+
+\begin{caveat}[~2]
+\href{https://forums.grsecurity.net/viewtopic.php?f=7&t=2522}{Привилегии~---
+отнюдь не~лекарство от всех бед.} Чтобы они работали действительно эффективно,
+возможно, придется дополнить их другими методиками защиты.
+\end{caveat}
+
+Чтобы проверить, какие именно привилегии имеют сейчас ваши процессы, вы можете
+воспользоваться программой +pscap+ из комплекта +libcap-ng-utils+.
+
+Применение опции +CapabilityBoundingSet=+ является простой, прозрачной и удобной
+альтернативой введению аналогичных ограничений через модификацию исходного кода
+всех системных служб.
+
+\subsection{Запрет форка, ограничение на создание файлов}
+
+Некоторые меры безопасности можно ввести при помощи механизма ограничения
+ресурсов. Как следует из его названия, этот механизм предназначен прежде всего
+для контроля использования ресурсов, а не~для контроля доступа. Однако, две его
+настройки могут быть использованы для запрета определенных действий:
+с помощью +RLIMIT_NPROC+ можно запретить службе форкаться (запускать
+дополнительные процессы), а +RLIMIT_FSIZE+ позволяет блокировать запись в файлы
+ненулевого размера:
+\begin{Verbatim}
+...
+[Service]
+ExecStart=...
+LimitNPROC=1
+LimitFSIZE=0
+...
+\end{Verbatim}
+Обратите внимание, что эти ограничения будут эффективно работать только в том
+случае, если служба будет работать от имени простого пользователя (не~root) и
+без привилегии +CAP_SYS_RESOURCE+ (блокирование этой привилегии можно
+обеспечить, например, описанной выше опцией +CapabilityBoundingSet=+). В
+противном случае, ничто не~мешает процессу поменять соответствующие ограничения.
+
+\begin{caveat}
++LimitFSIZE=+ действует очень жестко. Если процесс пытается записать файл
+ненулевого размера, он немедленно получает сигнал +SIGXFSZ+, который, как
+правило, прекращает работу процесса (в случае, если не~назначен обработчик
+сигнала). Кроме того, стоит отметить, что эта опция не~запрещает создание файлов
+нулевого размера.
+\end{caveat}
+
+Подробности об этих и других опциях ограничения ресурсов можно уточнить на
+странице документации \href{http://linux.die.net/man/2/setrlimit}{setrlimit(2)}.
+
+\subsection{Контроль доступа служб к файлам устройств}
+
+Файлы устройств предоставляют приложениям интерфейс для доступа к ядру и
+драйверам. Причем драйверы, как правило менее тщательно тестируются и не~так
+аккуратно проверяются на предмет наличия уязвимостей, по сравнению с основными
+компонентами ядра. Именно поэтому драйверы часто становятся объектами атаки
+злоумышленников. systemd позволяет контролировать доступ к устройствам
+индивидуально для каждой службы:
+\begin{Verbatim}
+...
+[Service]
+ExecStart=...
+DeviceAllow=/dev/null rw
+...
+\end{Verbatim}
+Приведенная конфигурация разрешит службе доступ только к файлу +/dev/null+,
+запретив доступ ко всем остальным файлам устройств.
+
+Реализация данной опции построена на использовании cgroups-контроллера
++devices+.
+
+\subsection{Прочие настройки}
+
+Помимо приведенных выше, простых и удобных в использовании опций, существует и
+ряд других других настроек, позволяющих повысить уровень безопасности. Но
+для их использования, как правило, уже требуются определенные изменения в
+исходном коде службы, и поэтому такие настройки представляют интерес прежде
+всего для апстримных разработчиков. В частности, сюда относится опция
++RootDirectory=+ (позволяющая запустить службу +chroot()+-окружении), а также
+параметры +User=+ и +Group=+, определяющие пользователя и группу, от имени
+которых работает служба.  Использование этих опций значительно упрощает
+написание демонов, так как работа по понижению привилегий ложится на плечи
+systemd.
+
+Возможно, у вас возникнет вопрос, почему описанные выше опции не~включены по
+умолчанию.  Отвечаем: чтобы не~нарушать совместимость. Многие из них несколько
+отступают от традиций, принятых в Unix. Например, исторически сложилось, так что
++/tmp+ является общим для всех процессов и пользователей. Существуют программы,
+использующие этот каталог для IPC, и включение по умолчанию режима изоляции для
++/tmp+ нарушит работу таких программ.
+
+И несколько слов в заключение. Если вы занимаетесь сопровождением unit-файлов
+в апстримном проекте или в дистрибутиве, пожалуйста, подумайте о том, чтобы
+воспользоваться приведенными выше настройками. Если сопровождаемая вами служба
+станет более защищенной в конфигурации по умолчанию (<<из коробки>>), от этого
+выиграют не~только ваши пользователи, но и все мы, потому что Интернет станет
+чуть более безопасным.
+
 \end{document}
 
 vim:ft=tex:tw=80:spell:spelllang=ru