diff --git a/s4a.tex b/s4a.tex index 7daadd2..63b0357 100644 --- a/s4a.tex +++ b/s4a.tex @@ -45,22 +45,23 @@ pdfauthor={Lennart Poettering, Sergey Ptashnick}} \tableofcontents%\newpage \sectiona{Предисловие автора} Многие из вас, наверное, уже знают, что -\href{http://www.freedesktop.org/wiki/Software/systemd}{systemd}~--- это -новая система инициализации дистрибутива Fedora, начиная с -Fedora~14\footnote{Прим. перев.: к сожалению, разработчики Fedora приняли -решение оставить в Fedora~14 в качестве системы инициализации по умолчанию -upstart, однако systemd все равно будет включен в этот релиз и может быть -использован в качестве альтернативной системы инициализации}. Помимо Fedora, -systemd также поддерживает и другие дистрибутивы, в частности, -\href{http://en.opensuse.org/SDB:Systemd}{OpenSUSE}. -systemd предоставляет администраторам целый ряд новых возможностей, -значительно упрощающих процесс обслуживания системы. Эта статья является -первой в серии публикаций, планируемых в ближайшие месяцы. В каждой из этих -статей я попытаюсь рассказать об очередной новой возможности systemd. +\href{http://www.freedesktop.org/wiki/Software/systemd}{systemd}~--- это новая +система инициализации дистрибутива Fedora, начиная с Fedora~14\footnote{Прим. +перев.: к сожалению, разработчики Fedora приняли решение оставить в Fedora~14 в +качестве системы инициализации по умолчанию upstart, однако systemd все равно +включен в этот релиз и может быть использован в качестве альтернативной системы +инициализации. Окончательный переход на systemd произошел лишь в Fedora~15.}. +Помимо Fedora, systemd также поддерживает и другие дистрибутивы, в частности, +\href{http://en.opensuse.org/SDB:Systemd}{OpenSUSE}\footnote{Прим. перев.: +сейчас systemd поддерживается практически во всех популярных дистрибутивах для +настольных систем.}. systemd предоставляет администраторам целый ряд новых +возможностей, значительно упрощающих процесс обслуживания системы. Эта статья +является первой в серии публикаций, планируемых в ближайшие месяцы. В каждой из +этих статей я попытаюсь рассказать об очередной новой возможности systemd. Большинство этих возможностей можно описать легко и просто, и подобные статьи -должны быть интересны довольно широкой аудитории. Однако, время от времени -мы будем рассматривать ключевые новшества systemd, что может потребовать -несколько более подробного изложения. +должны быть интересны довольно широкой аудитории. Однако, время от времени мы +будем рассматривать ключевые новшества systemd, что может потребовать несколько +более подробного изложения. \begin{flushright} Lennart P\"{o}ttering, 23 августа 2010~г. \end{flushright} @@ -240,7 +241,7 @@ CGI-программы, а демон cron~--- команды, предписа вследствие ошибок в коде и/или конфигурации программ, но и в результате злого умысла. Например, очень часто встречается ситуация, когда установленный на взломанном сервере процесс-бэкдор маскируется под нормального демона, меняя -себе имя, скажем, на httpd}. +себе имя, скажем, на httpd.}. systemd предлагает простой путь для решения обсуждаемой задачи. Запуская очередной новый процесс, systemd помещает его в отдельную контрольную группу @@ -648,7 +649,7 @@ Bug Reporting Tool, службы, занимающейся сбором crash du +MTA+ или +smtpdaemon+ (Fedora), +smtp+ (openSUSE), +mail-transport-agent+ (Debian и Ubuntu), +mail-transfer-agent+. Таким образом, можно утверждать, что - стандарт LSB не~справляется с возложенной на него задачей}, + стандарт LSB не~справляется с возложенной на него задачей.}, содержащий информацию о зависимостях. systemd, базирующийся на идеях socket-активации, обычно не~требует явного описания зависимостей (либо требует самого минимального описания). @@ -711,7 +712,7 @@ WantedBy=multi-user.target реализации, явное указание +After=syslog.target+ будет избыточным, так как соответствующая функциональность поддерживается автоматически. Однако, эту строчку стоит все-таки указать для обеспечения совместимости с системами, -использующими устаревшие реализации демона системного лога}. Эта информация, +использующими устаревшие реализации демона системного лога.}. Эта информация, как мы помним, была указана в LSB-заголовке исходного init-скрипта. В нашем конфигурационном файле мы указываем зависимость от демона системного лога при помощи директивы +After+, указывающей на юнит +syslog.taget+. Это @@ -749,7 +750,7 @@ systemd считает службу запущенной с момента за +multi-user.target+. Это специальный юнит, примерно соответствующий роли третьего уровня исполнения классического SysV\footnote{В том контексте, в котором он используется в большинстве дистрибутивов семейства Red Hat, а -именно, многопользовательский режим без запуска графической оболочки}. +именно, многопользовательский режим без запуска графической оболочки.}. Директива +WantedBy+ никак не~влияет на уже работающую службу, но она играет важную роль при выполнении команды +systemctl enable+, задавая, в каких условиях должен активироваться устанавливаемый юнит. В нашем примере, служба @@ -759,7 +760,7 @@ abrtd будет активироваться при переходе в сос в SysV) является надстройкой над режимом многопользовательской консольной загрузки (+multi-user.target+, аналог runlevel 3 в SysV). Таким образом, все службы, запускаемые в режиме +multi-user.target+, будут -также запускаться и в режиме +graphical.target+} (к <<ненормальным>> +также запускаться и в режиме +graphical.target+.} (к <<ненормальным>> можно отнести, например, загрузки в режиме +emergency.target+, который является аналогом первого уровня исполнения в классической SysV). @@ -818,7 +819,7 @@ systemd сложнее определить, какой из порожденн воспользовались типом запуска +dbus+. Он подходит для всех служб, которые в конце процесса инициализации регистрируют свое имя на шине D-Bus\footnote{В настоящее время практически все службы дистрибутива Fedora после запуска -регистрируется на шине D-Bus}. ABRTd относится к ним. С новыми настройками, +регистрируется на шине D-Bus.}. ABRTd относится к ним. С новыми настройками, systemd запустит процесс abrtd, который уже не~будет форкаться (согласно указанным нами ключам <<+-d -s+>>), и в качестве момента окончания периода запуска данной службы systemd будет рассматривать момент регистрации имени @@ -906,7 +907,7 @@ Apache, crond, atd, которые по роду служебной деятел пользователем или службой не~создаст значительных проблем с отзывчивостью системы у других пользователей и служб. Таким образом, в качестве основной угрозы форк-бомбардировки остаются лишь возможности исчерпания памяти и -идентификаторов процессов (PID)}. +идентификаторов процессов (PID).}. В некоторый случах возникает необходимость отправить сигнал именно основному процессу службы. Например, используя +SIGHUP+, мы можем заставить демона @@ -1105,35 +1106,35 @@ systemd и на этот случай есть простое решение, и \href{http://linux.die.net/man/1/chroot}{chroot-окружениями}. Системный вызов +chroot()+ позволяет задать для определенного процесса (и его потомков) каталог, который они будут рассматривать как корневой +/+, тем самым ограничивая для них -область видимости иерархии файловой системы отдельным поддеревом. Большинство +область видимости иерархии файловой системы отдельной ветвью. Большинство применений chroot-окружений можно отнести к двум классам задач: \begin{enumerate} \item Обеспечение безопасности. Потенциально уязвимый демон chroot'ится - в отдельный каталог, и даже в случае успешной атаки, взломщик + в отдельный каталог и, даже в случае успешной атаки, взломщик увидит лишь содержимое этого каталога, а не~всю файловую систему~--- он окажется в ловушке chroot'а. \item Подготовка и управление образом операционной системы при отладке, тестировании, компиляции, установке или восстановлении. При этом вся иерархия файловых систем гостевой ОС монтируется или создается в каталоге системы-хоста, и при запуске оболочки (или - любого другого приложения) внутри этой иерархии, их корень - сдвигается в этот каталог. Система, которую <<видят>> такие - программы, может сильно отличаться от ОС хоста. Например, это - может быть другой дистрибутив, или даже другая аппаратная + любого другого приложения) внутри этой иерархии, в качестве + корня используется этот каталог. Система, которую <<видят>> + такие программы, может сильно отличаться от ОС хоста. Например, + это может быть другой дистрибутив, или даже другая аппаратная архитектура (запуск i386-гостя на x86\_64-хосте). Гостевая ОС - не~может увидеть полной иерархии ОС хоста. + не~может увидеть полного дерева каталогов ОС хоста. \end{enumerate} В системах, использующих классический SysV init, использовать chroot-окружения -сравнительно несложно. Например, чтобы запустить выбранного демона внутри -иерархии гостевой ОС, достаточно смонтировать внутри этой иерархии +/proc+, +сравнительно несложно. Например, чтобы запустить выбранного демона внутри дерева +каталогов гостевой ОС, достаточно смонтировать внутри этого дерева +/proc+, +/sys+ и остальные API ФС, воспользоваться программой +chroot(1)+ для входа в окружение, и выполнить соответствующий init-скрипт, запустив +/sbin/service+ внутри окружения. Но в системах, использующих systemd, уже не~все так просто. Одно из важнейших достоинств systemd состоит в том, что параметры среды, в которой запускаются -демоны, никак не~зависит от метода их запуска. В системах, использующих SysV +демоны, никак не~зависят от метода их запуска. В системах, использующих SysV init, многие параметры среды выполнения (в частности, лимиты на системные ресурсы, переменные окружения, и т.п.) наследуются от оболочки, из которой был запущен init-скрипт. При использовании systemd ситуация меняется радикально: @@ -1154,8 +1155,8 @@ init-подсистемой (и это, в общем, неплохо, а есл chroot-окружения в системах на основе systemd? Что ж, постараемся дать подробный и всесторонний ответ на этот вопрос. -Для начала рассмотрим первое из перечисленных выше применений chroot: изоляция в -целях безопасности. Прежде всего, стоит заметить, что защита, предоставляемая +Для начала, рассмотрим первое из перечисленных выше применений chroot: изоляция +в целях безопасности. Прежде всего, стоит заметить, что защита, предоставляемая chroot'ом, весьма эфемерна и ненадежна, так как chroot не~является <<дорогой с односторонним движением>>. Выйти из chroot-окружения сравнительно несложно, и соответствующее предупреждение даже @@ -1164,17 +1165,18 @@ chroot'ом, весьма эфемерна и ненадежна, так как методиками. В большинстве случаев, это возможно только при наличии поддержки chroot в самой программе. Прежде всего, корректное конфигурирование chroot-окружения требует глубокого понимания принципов работы программы. -Например, нужно точно знать, какие сокеты использует программа, чтобы обеспечить -bind-монтирование соответствующих каталогов. С учетом вышесказанного, -эффективная chroot-защита обеспечивается в том случае, когда она реализована в -коде самого демона. Именно разработчик лучше других знает (\emph{обязан} знать), -как правильно сконфигурировать chroot-окружение, и какой минимальный набор -файлов, каталогов и файловых систем необходим внутри него для нормальной работы -демона. Уже сейчас существуют демоны, имеющие встроенную поддержку chroot. -К сожалению, в системе Fedora, установленной с параметрами по умолчанию, таких -демонов всего два: \href{http://avahi.org/}{Avahi} и RealtimeKit. Оба они -написаны одним очень хитрым человеком ;-) (Вы можете собственноручно -убедится в этом, выполнив команду +ls -l /proc/*/root+.) +Например, нужно точно знать, какие каталоги нужно bind-монтировать из основной +системы, чтобы обеспечить все необходимые для работы программы каналы связи. С +учетом вышесказанного, эффективная chroot-защита обеспечивается в том случае, +когда она реализована в коде самого демона. Именно разработчик лучше других +знает (\emph{обязан} знать), как правильно сконфигурировать chroot-окружение, и +какой минимальный набор файлов, каталогов и файловых систем необходим внутри +него для нормальной работы демона. Уже сейчас существуют демоны, имеющие +встроенную поддержку chroot. К сожалению, в системе Fedora, установленной с +параметрами по умолчанию, таких демонов всего два: +\href{http://avahi.org/}{Avahi} и RealtimeKit. Оба они написаны одним очень +хитрым человеком ;-) (Вы можете собственноручно убедится в этом, выполнив +команду +ls -l /proc/*/root+.) Возвращаясь к тема нашего обсуждения: разумеется, systemd позволяет помещать выбранных демонов в chroot, и управлять ими точно так же, как и другими. @@ -1222,7 +1224,7 @@ RootDirectoryStartOnly=yes характерные для chroot. systemd позволяет использовать при конфигурировании юнитов некоторые возможности, предоставляемые FSNS. В частности, использование FSNS часто является гораздо более простой и удобной альтернативой созданию -полноценных chroot-окружений. Используя директивы +ReadOnlyDirectories=+, +полновесных chroot-окружений. Используя директивы +ReadOnlyDirectories=+, +InaccessibleDirectories=+, вы можете задать ограничения по использованию иерархии файловых систем для заданной службы: ее корнем будет системный корневой каталог, однако указанные в этих директивах подкаталоги будут доступны только @@ -1248,28 +1250,28 @@ Avahi и ReltimeKit в ближайшем будущем перейдут с +ch FSNS. Итак, мы рассмотрели вопросы использования chroot для обеспечения безопасности. -Переходим ко второму пункту: Подготовка и управление образом операционной +Переходим ко второму пункту: подготовка и управление образом операционной системы при отладке, тестировании, компиляции, установке или восстановлении. -chroot-окружения, по сути, весьма примитивно: они изолируют только иерархии +chroot-окружения, по сути, весьма примитивны: они изолируют только иерархии файловых систем. Даже после chroot'а в определенный подкаталог, процесс -по-прежнему имеет полный доступ к системным вызовам, может убить любой процесс -из основной системы, и т.п. Вследствие этого, запуск полноценной ОС (или ее -части) внутри chroot'а несет угрозу для хост-системы: у гостя и хоста отличаются -лишь содержимое файловой системы, все остальное у них общее. Например, если вы -обновляете дистрибутив, установленный в chroot-окружении, и пост-установочный -скрипт пакета отправляет +SIGTERM+ процессу init для его -перезапуска\footnote{Прим. перев.: Во избежание путаницы отметим, что перезапуск +по-прежнему имеет полный доступ к системным вызовам, может убивать процессы, +запущенные в основной системе, и т.п. Вследствие этого, запуск полноценной ОС +(или ее части) внутри chroot'а несет угрозу для хост-системы: у гостя и хоста +отличается лишь содержимое файловой системы, все остальное у них общее. +Например, если вы обновляете дистрибутив, установленный в chroot-окружении, и +пост-установочный скрипт пакета отправляет +SIGTERM+ процессу init для его +перезапуска\footnote{Прим. перев.: во избежание путаницы отметим, что перезапуск процесса init (PID~1) <<на лету>> при получении +SIGTERM+ поддерживается только -в systemd, в классическом SysV init такой возможности нет}, на него среагирует +в systemd, в классическом SysV init такой возможности нет.}, на него среагирует именно хост-система! Кроме того, хост и chroot'нутая система будут иметь общую разделяемую память SysV (SysV shared memory), общие сокеты из абстрактных пространств имен (abstract namespace sockets) и другие элементы IPC. Для отладки, тестирования, компиляции, установки и восстановлении ОС не~требуется -абсолютно безопасная изоляция, однако нужна защита от \emph{случайного} -воздействия на ОС хоста изнутри chroot-окружения, иначе вы можете получить целый -букет проблем, как минимум, от пост-инсталляционных скриптов при установке -пакетов в chroot-окружении. +абсолютно неуязвимая изоляция~--- нужна лишь надежная защита от +\emph{случайного} воздействия на ОС хоста изнутри chroot-окружения, иначе вы +можете получить целый букет проблем, как минимум, от пост-инсталляционных +скриптов при установке пакетов в chroot-окружении. systemd имеет целый ряд возможностей, полезных для работы с chroot-системами: @@ -1296,7 +1298,7 @@ debootstrap/febootstrap. В этом случае возможности +system +chroot(1)+~--- она не~только подменяет корневой каталог, но и создает отдельные пространства имен для дерева файловых систем (FSNS) и для идентификаторов процессов (PID NS), предоставляя легковесную реализацию системного -контейнера\footnote{Прим. перев.: Используемые в +systemd-nspawn+ механизмы +контейнера\footnote{Прим. перев.: используемые в +systemd-nspawn+ механизмы ядра Linux, такие, как FS NS и PID NS, также лежат в основе \href{http://lxc.sourceforge.net/}{LXC}, системы контейнерной изоляции для Linux, которая позиционируется как современная альтернатива классическому @@ -1363,15 +1365,15 @@ systemd уже подготовлен для работы внутри таки шаге вызывает не~+reboot()+, а просто +exit()+. Стоит отметить, что +systemd-nspawn+ все же не~является полноценной системой -контейнерной виртуализации/изоляции~--- если нужно именно это, воспользуйтесь -\href{ http://lxc.sourceforge.net/}{LXC}. Этот проект использует те же самые -механизмы ядра, но предоставляет куда более широкие возможности, включая -виртуализацию сети. Если вам угодно, +systemd-nspawn+ как реализация контейнера -похожа на GNOME~3~--- компактна и проста в использовании, опций для настройки -очень мало. В то время как LXC больше похож на KDE: опций для настройки больше, -чем строк кода. Я создал +systemd-nspawn+ специально для тестирования, отладки, -сборки, восстановления. Именно для этих задач вам стоит ее использовать~--- она -неплохо с ними справляется, куда лучше, чем +chroot(1)+. +контейнерной виртуализации/изоляции~--- если вам нужно такое решение, +воспользуйтесь \href{ http://lxc.sourceforge.net/}{LXC}. Этот проект использует +те же самые механизмы ядра, но предоставляет куда более широкие возможности, +включая виртуализацию сети. Могу предложить такую аналогию: +systemd-nspawn+ как +реализация контейнера похожа на GNOME~3~--- компактна и проста в использовании, +опций для настройки очень мало. В то время как LXC больше похож на KDE: опций +для настройки больше, чем строк кода. Я создал +systemd-nspawn+ специально для +тестирования, отладки, сборки, восстановления. Именно для этих задач вам стоит +ее использовать~--- она неплохо с ними справляется, куда лучше, чем +chroot(1)+. Что ж, пора заканчивать. Итак: \begin{enumerate} @@ -1476,7 +1478,7 @@ $ systemd-analyze blame мы можем с этим сделать? Эта служба выполняет очень простую задачу: она ожидает, пока udev завершит опрос устройств, после чего завершается. Опрос же устройств может занимать довольно много времени. Например, в нашем случае опрос устройств -занимает более 6~секунд из-за встроенного в компьютер 3G-модема, в котором +занимает более 6~секунд из-за подключенного к компьютеру 3G-модема, в котором отсутствует SIM-карта. Этот модем очень долго отвечает на запросы udev. Опрос устройств является частью схемы, обеспечивающей работу ModemManager'а и позволяющей NetworkManager'у упростить для вас настройку 3G. Казалось бы, @@ -1562,12 +1564,12 @@ cryptsetup, что снижение этого времени с 1 секунд нужно сделать так, чтобы этот каталога автоматически монтировался при загрузке, но процесс загрузки не~ожидал завершения работы +cryptsetup+, +fsck+ и +mount+ для этого раздела. Как же сделать точку монтирования доступной, не~ожидая, пока -завершится процесс монтирования? Это можно сделать, воспользовавшись магической -силой systemd~--- просто добавим опцию монтирования +comment=systemd.automount+ -в +/etc/fstab+. После этого, systemd будет создавать в +/home+ точку -автоматического монтирования, и при первом же обращении к этому каталогу, -если файловая система еще не~будет готова к работе, -systemd подготовит соответствующее устройство, проверит и смонтирует ее. +завершится процесс монтирования? Этого можно достичь, воспользовавшись +магической силой systemd~--- просто добавим опцию монтирования ++comment=systemd.automount+ в +/etc/fstab+. После этого, systemd будет создавать +в +/home+ точку автоматического монтирования, и при первом же обращении к этому +каталогу, если файловая система еще не~будет готова к работе, systemd подготовит +соответствующее устройство, проверит и смонтирует ее. После внесения изменений в +/etc/fstab+ и перезагрузки мы получаем: \begin{Verbatim} @@ -1647,7 +1649,7 @@ Fedora~15 <<из коробки>>. \section{Новые конфигурационные файлы} -Одно из наиболее масштабных нововведений +Одно из ключевых достоинств \href{http://www.freedesktop.org/wiki/Software/systemd}{systemd}~--- наличие полного набора программ, необходимых на ранних стадиях загрузки, причем эти программы написаны на простом, быстром, надежном и легко поддающемся @@ -1658,12 +1660,12 @@ shell-скриптов, разработанных для этих задач р оставляет желать лучшего, но все же неплохо передает основную идею.} увенчался полным успехом. Уже сейчас возможности предоставляемого нами инструментария покрывают практически все нужды настольных и встраиваемых систем, а также -большую часть потребностей серверных систем: +б\'{о}льшую часть потребностей серверов: \begin{itemize} \item Проверка и монтирование всех файловых систем. \item Обновление и активация квот на всех файловых системах. \item Установка имени хоста. - \item Конфигурирование интерфейса обратной петли (+lo+). + \item Настройка сетевого интерфейса обратной петли (+lo+). \item Подгрузка правил SELinux, обновление меток безопасности в динамических каталогах +/run+ и +/dev+. \item Регистрация в ядре дополнительных бинарных форматов (например, @@ -1698,11 +1700,11 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко дистрибутивов, и поэтому реализация их поддержки в наших инструментах не~представляла особого труда. Например, это относится к файлам +/etc/fstab+, +/etc/crypttab+, +/etc/sysctl.conf+. Однако множество других, нестандартно -расположенных файлов и каталогов вынуждали нас добавлять множество операторов -+#ifdef+, чтобы обеспечить поддержку различных вариантов расположения -конфигураций в разных дистрибутивах. Такой положение дел сильно усложняет -жизнь нам всем, и при этом ничем не~оправдано~--- все эти файлы решают одни и те -же задачи, но делают это немного по-разному. +расположенных файлов и каталогов вынуждали нас добавлять в код огромное +количество операторов +#ifdef+, чтобы обеспечить поддержку различных вариантов +расположения конфигураций в разных дистрибутивах. Такой положение дел сильно +усложняет жизнь нам всем, и при этом ничем не~оправдано~--- все эти файлы решают +одни и те же задачи, но делают это немного по-разному. Чтобы улучшить ситуацию и установить единый стандарт расположения базовых конфигурационных файлов во всех дистрибутивах, мы заставили systemd пользоваться @@ -1768,7 +1770,7 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко перечень возможных названий файлов. Проект LSB попытался создать такой инструмент~--- \hreftt{http://refspecs.freestandards.org/LSB_3.1.0/LSB-Core-generic/LSB-Core-generic/lsbrelease.html}{lsb\_release}~--- - однако реализация такой простой вещи через скрипт на Python'е + однако реализация столь простой функции через скрипт на Python'е является не~самым оптимальным решением. Чтобы исправить сложившуюся ситуацию, мы решили перейти к единому простому формату представления этой информации. @@ -1796,12 +1798,12 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко конфигурационные файлы в ваших инструментах для настройки системы. Если ваши конфигурационные фронтенды будут использовать новые файлы, а не~их старые аналоги, это значительно облегчит портирование таких фронтендов между -дистрибутивами, и вы внесете свой вклад в стандартизацию Linux, и в конечном -счете упростится жизнь и у администраторов, и для пользователей. Разумеется, на -текущий момент эти файлы полностью поддерживаются только дистрибутивами, -основанными на systemd, но уже сейчас в их число входят практически все ключевые -дистрибутивы, \href{http://www.ubuntu.com/}{за исключением -одного}\footnote{Прим. перев.: В конце 2010~года энтузиаст Andrew Edmunds +дистрибутивами, и вы внесете свой вклад в стандартизацию Linux. В конечном счете +это упростит жизнь и администраторам, и пользователям. Разумеется, на текущий +момент эти файлы полностью поддерживаются только дистрибутивами, основанными на +systemd, но уже сейчас в их число входят практически все ключевые дистрибутивы, +\href{http://www.ubuntu.com/}{за исключением +одного}\footnote{Прим. перев.: в конце 2010~года энтузиаст Andrew Edmunds \href{http://cgit.freedesktop.org/systemd/commit/?id=858dae181bb5461201ac1c04732d3ef4c67a0256}{добавил} в systemd базовую поддержку Ubuntu и \href{https://wiki.ubuntu.com/systemd}{подготовил} соответствующие пакеты, @@ -1822,7 +1824,7 @@ LVM, RAID и multipath). Если они вам не~нужны, вы легко дистрибутивов механизмы поддержки бинарных форматов больше не~нужны, и ваш проект будет работать одинаково хорошо во всех дистрибутивах. Аналогичное предложение мы обращаем и ко всем разработчикам программ, которым требуется -автоматическое создание/очистка временных файлов и каталогов при загрузке, +автоматическое создание/очистка временных файлов и каталогов, например, в каталоге +/run+ (\href{http://lwn.net/Articles/436012/}{ранее известном} как +/var/run+). Таким проектам достаточно просто поместить соответствующий конфигурационный файл в +/etc/tmpfiles.d/+, тоже средствами @@ -1838,8 +1840,14 @@ shell-скриптов, выполняющих тривиальные задач и форматы конфигурационных файлов. Но нам все же нужно было что-то выбрать, и мы выбрали то, что должно устроить большинство людей. Форматы конфигурационных файлов максимально просты, и их можно легко читать и записывать даже из -shell-скриптов. (Эх, а ведь +/etc/bikeshed.conf+ могло бы быть неплохим именем -для файла конфигурации!) +shell-скриптов. Да, +/etc/bikeshed.conf+ могло бы быть неплохим именем +для файла конфигурации!\footnote{Прим. перев.: здесь автор намекает на +\href{http://en.wikipedia.org/wiki/Parkinson's_Law_of_Triviality}{Паркинсоновский +Закон Тривиальности}, который гласит, что самые жаркие споры возникают вокруг +наиболее простых вопросов. В частности, в качестве примера Паркинсон приводит +обсуждение строительства атомной электростанции и гаража для велосипедов (bike +shed)~--- если первое из этих решений принимается довольно быстро, то вокруг +второго разгорается множество дискуссий по самым разным аспектам.} \textbf{Помогите нам стандартизировать Linux! Используйте новые конфигурационные файлы! Поддерживайте их в апстриме, поддерживайте их во всех дистрибутивах!}