Version v8.8 (2012-01-17 03:19) [AUTO]

s4a.tex

@@ -1409,7 +1409,7 @@ systemd уже подготовлен для работы внутри таки
 
 \section{Поиск виновных}
 
-Fedora~15\footnote{Величайший в истории релиз свободной ОС}
+Fedora~15\footnote{Величайший в истории релиз свободной ОС.}
 является первым релизом Fedora, использующим systemd в качестве системы
 инициализации по умолчанию. Основной нашей целью при работе над выпуском F15
 является обеспечение полной взаимной интеграции и корректной работы всех
@@ -1701,14 +1701,14 @@ shell-скриптов, разработанных для этих задач р
 	\item Автоматический запуск +getty+ на serial-консолях.
 	\item Взаимодействие с Plymouth.
 	\item Создание уникального идентификатора системы.
-	\item Установка часового пояса.
+	\item Настройка часового пояса.
 \end{itemize}
 
 В стандартной установке Fedora~15 запуск shell-скриптов требуется только для
 некоторых устаревших служб, а также для подсистемы хранения данных (поддержка
 LVM, RAID и multipath). Если они вам не~нужны, вы легко можете отключить их, и
-наслаждаться загрузкой, полностью очищенной от shell-костылей (я это сделал уже
-давно). Такая загрузка является уникальной возможностью Linux-систем.
+наслаждаться загрузкой, полностью очищенной от shell-костылей (лично я это
+сделал уже давно). Такая загрузка является уникальной возможностью Linux-систем.
 
 Большинство перечисленных выше компонентов настраиваются через конфигурационные
 файлы в каталоге +/etc+. Некоторые из этих файлов стандартизированы для всех
@@ -1717,9 +1717,9 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко
 +/etc/crypttab+, +/etc/sysctl.conf+. Однако множество других, нестандартно
 расположенных файлов и каталогов вынуждали нас добавлять в код огромное
 количество операторов +#ifdef+, чтобы обеспечить поддержку различных вариантов
-расположения конфигураций в разных дистрибутивах. Такой положение дел сильно
+расположения конфигураций в разных дистрибутивах. Такое положение дел сильно
 усложняет жизнь нам всем, и при этом ничем не~оправдано~--- все эти файлы решают
-одни и те же задачи, но делают это немного по-разному.
+одни и те же задачи, просто немного по-разному.
 
 Чтобы улучшить ситуацию и установить единый стандарт расположения базовых
 конфигурационных файлов во всех дистрибутивах, мы заставили systemd пользоваться
@@ -1748,7 +1748,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>>. Данный термин означает каталог, в который можно
 		поместить множество независимых файлов настроек, и при чтении
 		конфигурации все эти файлы будут обработаны (впрочем, часто
 		накладывается ограничение~--- обрабатываются только файлы с
@@ -1819,7 +1819,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. На
@@ -1827,7 +1827,7 @@ systemd, но уже сейчас в их число входят практич
 этом есть что-то от <<проблемы курицы и яйца>>: стандарт становится настоящим
 стандартом только тогда, когда ему начинают следовать. В будущем мы намерены
 аккуратно форсировать процесс перехода на новые конфигурационные файлы:
-поддержка старых файлов будет удалена из systemd. Разумеется, этот процесс будет
+поддержка старых файлов будет удалена из systemd. Разумеется, процесс будет
 идти медленно, шаг за шагом. Но конечной его целью является переход всех
 дистрибутивов на единый набор базовых конфигурационных файлов.
 
@@ -1866,9 +1866,9 @@ shed)~--- если первое из этих решений принимает
 \textbf{Помогите нам стандартизировать Linux! Используйте новые конфигурационные
 файлы! Поддерживайте их в апстриме, поддерживайте их во всех дистрибутивах!}
 
-Да, и если у вас возникнет такой вопрос: да, все эти файлы так или иначе
+И если у вас возникнет такой вопрос: да, все эти файлы так или иначе
 обсуждались с разными разработчиками из различных дистрибутивов. И некоторые из
-этих разработчиков планируют обеспечить поддержку новой конфигурации даже в
+разработчиков планируют обеспечить поддержку новой конфигурации даже в
 системах без systemd.
 
 \section{О судьбе /etc/sysconfig и /etc/default}
@@ -1904,15 +1904,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+ вообще-то предназначен для
@@ -1961,16 +1961,16 @@ init-скрипта, или даже сами не~являющиеся скри
 +/etc/sysconfig+ (+/etc/default+) и почему этим каталогам нет места в мире
 systemd?
 \begin{itemize}
-	\item Прежде всего, утрачены основная цель и смысл существования этих
+	\item Прежде всего, утрачены основная цель и смысл существования таких
 		каталогов: файлы конфигурации юнитов systemd не~являются
 		программами, в отличие от init-скриптов SysV. Эти файлы
 		представляют собой простые, декларативные описания конкретных
 		задач и функций, и обычно содержат не~более шести строк. Они
 		легко могут быть сгенерированы и проанализованы без
 		использования Bourne shell. Их легко читать и понимать. Кроме
-		того, их легко модифицировать: достаточно скопировать их из
+		того, их легко модифицировать: достаточно скопировать файл из
 		+/lib/systemd/system+ в +/etc/systemd/system+, после чего внести
-		необходимые изменения в скопированный файл (при этом можно быть
+		в созданную копию необходимые изменения (при этом можно быть
 		уверенным, что изменения не~будут затерты пакетным менеджером).
 		Изначальная причина появления обсуждаемых каталогов~---
 		необходимость разделять код и параметры конфигурации~--- больше
@@ -2065,7 +2065,7 @@ systemd?
 		настоящее время не~поддерживается автоматическая загрузка
 		модулей на основании информации о возможностях процессора,
 		однако это будет исправлено в ближайшем будущем\footnote{Прим.
-		перев.: Патчи от разработчиков systemd уже приняты в ядро, и
+		перев.: Необходимые патчи уже приняты в ядро, и
 		соответствующая функция поддерживается Linux, начиная с версии
 		3.3.}. В случае, если нужный вам модуль ядра все же не~может
 		быть подгружен автоматически, все равно существует гораздо более
@@ -2176,7 +2176,7 @@ systemd?
 
 Получив такую команду, systemd сначала пытается найти файл конфигурации юнита с
 именем, точно соответствующим запрошенному. Если такой файл найти не~удается
-(при работе с экземплярами сервисов обычно так и происходит), из имени файла
+(при работе с экземплярами служб обычно так и происходит), из имени файла
 удаляется идентификатор экземпляра, и полученное имя используется при поиске
 \emph{шаблона} конфигурации. В нашем случае, если отсутствует файл с именем
 +serial-getty@ttyUSB0.service+, используется файл-шаблон под названием
@@ -2200,7 +2200,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}{полную
 версию}.)
 
 Этот файл похож на обычный файл конфигурации юнита, с единственным отличием: в
@@ -2208,7 +2208,7 @@ RestartSec=0
 заменяет эти спецификаторы на идентификатор экземпляра службы. В нашем случае,
 при обращении к экземпляру +serial-getty@ttyUSB0.service+, они заменяются на
 <<+ttyUSB0+>>. Результат такой замены можно проверить, например, запросив
-состояние для этой службы:
+состояние для нашей службы:
 \begin{Verbatim}[commandchars=\\\{\}]
 $ systemctl status serial-getty@ttyUSB0.service
 serial-getty@ttyUSB0.service - Getty on ttyUSB0
@@ -2239,7 +2239,7 @@ systemd предоставляет простой в использовании
 
 Иногда возникает необходимость отказаться от использования общего шаблона
 для конкретного экземпляра (т.е. конфигурация данного экземпляра настолько
-сильно отличается от конфигурации остальных экземпляров данной службы, что
+сильно отличается от параметров остальных экземпляров данной службы, что
 механизм шаблонов оказывается неэффективен). Специально для таких случаев, в
 systemd и заложен предварительный поиск файла с именем, точно соответствующим
 указанному (прежде чем использовать общий шаблон). Таким образом, вы можете
@@ -2351,7 +2351,7 @@ systemd прежде всего ориентирована на локальны
 передавать запускаемой службе только один сокет, который формируется из потоков
 STDIN и STDOUT запущенного процесса. Поддержка этого механизма также
 присутствует в systemd~--- для обеспечения совместимости со множеством служб,
-поддерживающих сокет-активацию только в стиле inetd.
+у которых сокет-активация реализована только в стиле inetd.
 
 Прежде, чем мы перейдем к примерам, рассмотрим три различных схемы, использующих
 сокет-активацию:
@@ -2372,7 +2372,7 @@ STDIN и STDOUT запущенного процесса. Поддержка эт
 		действительно понадобится. Пример~--- CUPS.
 	\item \textbf{Сокет-активация для служб, запускающих по экземпляру на
 		каждое соединение:} сокеты создаются на ранней стадии загрузки,
-		и при каждом входящем соединении создается экземпляр службы,
+		и при каждом входящем соединении запускается экземпляр службы,
 		которому передается сокет соединения (слушающий сокет при этом
 		остается у суперсервера, inetd или systemd). Эта схема подходит
 		для редко используемых служб, не~критичных по производительности
@@ -2409,12 +2409,12 @@ STDIN и STDOUT запущенного процесса. Поддержка эт
 большинстве систем, где она используется, частота обращений к ней не~превышает
 одного раза в час (как правило, она \emph{значительно} меньше этой величины).
 SSH уже очень давно поддерживает сокет-активацию в стиле inetd, согласно третьей
-схеме. Так как необходимость в этой службе возникает сравнительно редко, и
+схеме. Так как необходимость в данной службе возникает сравнительно редко, и
 число одновременно работающих процессов обычно невелико, она хорошо подходит для
 использования по этой схеме. Перерасход системных ресурсов должен быть
 незначителен: большую часть времени такая служба фактически не~выполняется и
 не~тратит ресурсы. Когда кто-либо начинает сеанс удаленной работы, она
-запускается, и останавливается немедленно по завершению сеанса, освобождая
+запускается, и останавливается немедленно по завершении сеанса, освобождая
 ресурсы. Что ж, посмотрим, как в systemd можно воспользоваться режимом
 совместимости с inetd и обеспечить сокет-активацию SSH.
 
@@ -2569,17 +2569,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 должно быть достаточно для решения большинства задач, а в