From bc028b2c47a54aa96032d24d21783ab2f55ad6d2 Mon Sep 17 00:00:00 2001 From: nnz1024 <0comffdiz@inbox.ru> Date: Tue, 17 Jan 2012 03:19:00 +0400 Subject: [PATCH] Version v8.8 (2012-01-17 03:19) [AUTO] --- s4a.tex | 89 +++++++++++++++++++++++++++++++++------------------------ 1 file changed, 51 insertions(+), 38 deletions(-) diff --git a/s4a.tex b/s4a.tex index d9000be..ba34a06 100644 --- a/s4a.tex +++ b/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{Прим. перев.: Для описания этого и трех последующих каталогов автор пользуется термином <>. Этот термин означает каталог, в который можно + 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 должно быть достаточно для решения большинства задач, а в