diff --git a/ru_RU.KOI8-R/articles/hubs/article.sgml b/ru_RU.KOI8-R/articles/hubs/article.sgml
index c055b572da..76c93012b3 100644
--- a/ru_RU.KOI8-R/articles/hubs/article.sgml
+++ b/ru_RU.KOI8-R/articles/hubs/article.sgml
@@ -1,1160 +1,1150 @@
+<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
 <!--
      The FreeBSD Russian Documentation Project
 
-     $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/hubs/article.sgml,v 1.11 2004/07/18 14:18:49 marck Exp $
+     $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/hubs/article.sgml,v 1.15 2004/09/06 07:24:39 marck Exp $
 
-     Original revision: 1.50
+     Original revision: 1.51
 -->
 
-<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
-<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
-%man;
-<!ENTITY % authors PUBLIC "-//FreeBSD//ENTITIES DocBook Author Entities//EN">
-%authors;
-<!ENTITY % teams PUBLIC "-//FreeBSD//ENTITIES DocBook Team Entities//RU">
-%teams;
-<!ENTITY % mailing-lists PUBLIC "-//FreeBSD//ENTITIES DocBook Mailing List Entities//RU">
-%mailing-lists;
-<!ENTITY % trademarks PUBLIC "-//FreeBSD//ENTITIES DocBook Trademark Entities//RU">
-%trademarks;
-<!ENTITY % freebsd PUBLIC "-//FreeBSD//ENTITIES DocBook Miscellaneous FreeBSD Entities//EN">
-%freebsd;
+<!ENTITY % articles.ent PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Articles Entity Set//EN">
+%articles.ent;
 <!ENTITY % not.published "IGNORE">
 ]>
 
 <article lang="ru">
   <articleinfo>
     <title>Поддержка зеркал FreeBSD</title>
     <pubdate>$FreeBSD$</pubdate>
     <authorgroup>
       <author>
 	<firstname>Jun</firstname>
 	<surname>Kuriyama</surname>
 	<affiliation>
 	  <address><email>kuriyama@FreeBSD.org</email></address>
 	</affiliation>
       </author>
       <author>
 	<firstname>Valentino</firstname>
 	<surname>Vaschetto</surname>
 	<affiliation>
 	  <address><email>logo@FreeBSD.org</email></address>
 	</affiliation>
       </author>
       <author>
 	<firstname>Daniel</firstname>
 	<surname>Lang</surname>
 	<affiliation>
 	  <address><email>dl@leo.org</email></address>
 	</affiliation>
       </author>
       <author>
 	<firstname>Ken</firstname>
 	<surname>Smith</surname>
 	<affiliation>
 	  <address><email>kensmith@FreeBSD.org</email></address>
 	</affiliation>
       </author>
     </authorgroup>
 
     <legalnotice id="trademarks" role="trademarks">
       &tm-attrib.freebsd;
       &tm-attrib.cvsup;
       &tm-attrib.general;
     </legalnotice>
 
     <abstract>
       <para>Рабочий вариант статьи, описывающей процесс создания и поддержки
 	зеркала FreeBSD и адресованной администраторам зеркал.</para>
     </abstract>
   </articleinfo>
 
   <sect1 id="mirror-contact">
     <title>Контактная информация</title>
 
     <para>Координаторы системы зеркал доступны по электронной почте по адресу
       <email>mirror-admin@FreeBSD.org</email>.  Помимо этого, существует
 	&a.hubs;.</para>
   </sect1>
 
   <sect1 id="mirror-requirements">
     <title>Требования к зеркалам FreeBSD</title>
     <sect2 id="mirror-diskspace">
       <title>Дисковое пространство</title>
       <para>
 	Одним из наиболее важных требований является дисковое пространство.
 	В зависимости от набора релизов, архитектур и степени полноты зеркала
 	вам может потребоваться огромный объем диска.  Не лишним будет
 	помнить, что <emphasis>официальное</emphasis> зеркало, скорее всего,
 	должно быть полным.  Репозиторий CVS и веб-страницы всегда должны
 	зеркалироваться полностью.  Кроме того, учтите, что приводимые оценки
 	объема относятся к состоянию на момент последнего редактирования
 	данной статьи (&rel2.current;-RELEASE/&rel.current;-RELEASE).  Дальнейший процесс
 	разработки и последующие релизы только увеличат требуемый объем.
 	Кроме того, разумно будет зарезервировать некоторое (10-20%)
 	дополнительное пространство спокойствия ради.
 	Вот некоторые оценки объема:
       </para>
       <itemizedlist>
 	<listitem><para>Полное зеркало FTP: 126 GB</para></listitem>
 	<listitem><para>Репозиторий CVS: 2.7 GB</para></listitem>
 	<listitem><para>Комплект изменений CTM: 1.8 GB</para></listitem>
 	<listitem><para>Веб-страницы: 300 MB</para></listitem>
       </itemizedlist>
     </sect2>
     <sect2 id="mirror-bandwidth">
       <title>Требования к сетевой связности и пропускной способности</title>
       <para>
 	Разумеется, у вас должно быть подключение к интернет.
 	Требуемая пропускная способность ваших каналов зависит от
 	предполагаемого профиля использования вашего зеркала.
 	Если вы собираетесь копировать некоторые части FreeBSD для
 	локального использования на вашей машине или в интранете,
 	требования могут быть много мягче, чем для публичного зеркала.
 	Для официального зеркала необходимая пропускная способность
 	увеличивается еще больше.  Мы можем дать лишь очень грубые оценки:
       </para>
       <itemizedlist>
 	<listitem><para>Зеркало для локального доступа: фактически минимум не
 	  определен, но канал шириной менее 2 Mbps может сделать процесс
 	  обновления мучительно медленным.</para></listitem>
 	<listitem><para>Неофициальное публичное зеркало: 34 Mbps выглядит
 	  неплохо для начала.</para></listitem>
 	<listitem><para>Официальное зеркало: рекомендуется канал шириной более
 	  100 Mbps; кроме того, ваша машина должна стоять как можно ближе к
 	  граничным маршрутизаторам вашей сети.</para></listitem>
       </itemizedlist>
     </sect2>
     <sect2 id="mirror-system">
       <title>Системные требования, процессор и память</title>
       <para>
 	Эти требования в первую очередь определяются максимальным ожидаемым
 	количеством клиентов (устанавливается администратором сервера).
 	Также, на требуемые ресурсы влияет список сервисов, которые вы будете
 	предоставлять.  Зеркало FTP и/или HTTP не требуют особенно много
 	ресурсов; значительно больше памяти и вычислительной производительности
 	потребляют CVSup, rsync или AnonCVS.  Особенно "прожорливым" по памяти
 	является rsync; CVSup требует достаточной производительности
 	процессора.  Для предоставления доступа по AnonCVS хорошей идеей будет
 	создание виртуальной файловой системы в памяти (MFS) по крайней мере
 	300 MB размером, так что учтите это при планировании.  Вот некоторые
 	советы по конфигурации аппаратной части сервера:
       </para>
       <para>
 	Для умеренно посещаемого сайта, предоставляющего
 	<application>rsync</application>, можно использовать процессор
 	с частотой 800MHz - 1 GHz и по крайней мере 512MB памяти.
 	Скорее всего, данная конфигурация может считаться минимальной для
 	<emphasis>официального</emphasis> зеркала.
       </para>
       <para>
 	Для регулярно посещаемого сайта вам потребуется больше памяти
 	(хорошим стартом будет 2GB) и больше процессорной мощности, что может
 	означать требование многопроцессорной (SMP) платформы.
       </para>
       <para>
 	Кроме того, вам потребуется быстрая дисковая подсистема, в первую
 	очередь, для работы с репозиторием CVS (крайне рекомендуем RAID).
 	Контроллер SCSI, оборудованный собственной памятью, также может
 	ощутимо ускорить процесс, поскольку большая часть сервисов связана
 	с большим количеством дисковых запросов небольшого размера.
       </para>
     </sect2>
     <sect2 id="mirror-services">
       <title>Предоставляемые сервисы</title>
       <para>
 	Всякое зеркало должно предоставлять набор основных сервисов.
 	Помимо требуемого минимального набора, существуют дополнительные
 	сервисы, которые администратор сервера может пожелать предоставлять.
 	Этот раздел описывает, какие сервисы вы можете предоставлять, и какие
 	действия для этого потребуются от вас.
       </para>
       <sect3 id="mirror-serv-ftp">
 	<title>FTP (требуется для FTP зеркала)</title>
 	<para>
 	  Это один из наиболее базовых сервисов; его предоставление требуется
 	  для каждого зеркала, распространяющего файлы FreeBSD по FTP.
 	  Доступ по FTP должен быть анонимным, и не должны применяться
 	  какие-либо ограничения по соотношению объема передано/принято
 	  (что вообще является, на наш взгляд, странным подходом).
 	  Закачка (upload) файлов на сервер не требуется (и
 	  <emphasis>должна</emphasis> быть запрещена в разделе FreeBSD).
 	  Кроме того, архив файлов FreeBSD должен быть доступен с путем
 	  <filename>/pub/FreeBSD</filename>.
 	</para>
 	<para>
 	  Для предоставления анонимного FTP доступа может быть использован
 	  целый ряд программ (перечислены в алфавитном порядке):
 	  <itemizedlist>
 	    <listitem>
 	      <para><command>/usr/libexec/ftpd</command>: базовый
 		FTP-даемон FreeBSD.  Не забудьте прочитать &man.ftpd.8;.</para>
 	    </listitem>
 	    <listitem>
 	      <para><filename role="package">ftp/ncftpd</filename>:
 		коммерческий пакет, свободен для использования в учебных целях.
 	      </para>
 	    </listitem>
 	    <listitem>
 	      <para><filename role="package">ftp/oftpd</filename>: FTP-даемон,
 		написанный в основном с точки зрения защищенности.</para>
 	    </listitem>
 	    <listitem>
 	      <para><filename role="package">ftp/proftpd</filename>: Модульный
 		и очень гибкий FTP-даемон.</para>
 	    </listitem>
 	    <listitem>
 	      <para><filename role="package">ftp/pure-ftpd</filename>:
 		Еще один FTP-даемон, разработанный с позиций защищенности.
 	      </para>
 	    </listitem>
 	    <listitem><para><filename role="package">ftp/twoftpd</filename>:
 	      См. предыдущий пункт.</para></listitem>
 	    <listitem><para><filename role="package">ftp/vsftpd</filename>:
 	      <quote>очень защищенный</quote> (<quote>very secure</quote>)
 	      ftpd.</para></listitem>
 	    <listitem>
 	      <para><filename role="package">ftp/wu-ftpd</filename>:
 		ftpd от Вашингтонского Университета (Washington
 		University). Несколько потерял популярность из-за большого
 		количества найденных в прошлом ошибок защиты.  Если вы решите
 		использовать его, помните о необходимости отслеживания
 		обновлений.
 	      </para>
 	    </listitem>
 	  </itemizedlist>
 	  Наиболее популярными являются встроенный во FreeBSD
 	  <application>ftpd</application>, <application>proftpd</application>,
 	  <application>wu-ftpd</application> и, возможно,
 	  <application>ncftpd</application>.
 	  Прочие распространены среди существующих зеркал в существенно
 	  меньшей степени.  Дополнительным поводом для рассмотрения может
 	  являться возможность гибко ограничивать количество одновременных
 	  соединений, что поможет вам удержать в нужных рамках потребление
 	  пропускной способности ваших каналов и машинные ресурсы.
 	</para>
       </sect3>
       <sect3 id="mirror-serv-rsync">
 	<title>RSYNC (необязательный сервис для FTP зеркала)</title>
 	<para>
 	  <application>rsync</application> часто используется для
 	  предоставления доступа к FTP-области FreeBSD, чтобы другие зеркала
 	  могли синхронизироваться по вашему.  Протокол rsync во многом
 	  отличается от FTP, в частности, он гораздо гуманнее с точки зрения
 	  пропускной способности каналов, поскольку не требует передачи
 	  измененного файла целиком (передаются лишь различия). Взамен
 	  <application>rsync</application> требует значительных объемов
 	  памяти. Размер каждого процесса зависит от размера синхронизируемого
 	  модуля (в основном от количества директорий и файлов).
 	  <application>rsync</application> может использовать в качестве
 	  транспортного протокола <command>rsh</command> или
 	  <command>ssh</command> (по умолчанию); также, может использоваться
 	  внутренний протокол <application>rsync</application> (этот метод
 	  предпочтителен для публичных rsync-серверов).
 	  Поддерживается авторизация клиентов и различные ограничения.
 	  Для протокола rsync существует единственный пакет:
 	  <itemizedlist>
 	    <listitem><para><filename role="package">net/rsync</filename></para></listitem>
 	  </itemizedlist>
 	</para>
       </sect3>
       <sect3 id="mirror-serv-http">
 	<title>HTTP (требуется для веб-страниц, дополнителен для FTP зеркал)</title>
 	<para>
 	  Если вы хотите поддерживать зеркало веб-страниц FreeBSD, вам потребуется
 	  веб-сервер, или <application>httpd</application>.
 	  Дополнительно, вы можете предоставлять HTTP доступ к FTP-набору
 	  файлов FreeBSD.  Выбор веб-сервера остается на усмотрение
 	  администратора зеркала.  Некоторые из наиболее популярных
 	  веб-серверов перечислены ниже.
 
 	  <itemizedlist>
 	    <listitem>
 	      <para><filename role="package">www/apache13</filename>:
 		Apache&nbsp;&mdash; один из самых популярных веб-серверов, активно
 		используемый проектом FreeBSD.  Вы можете также использовать
 		Apache нового поколения, доступный в коллекции портов как
 		<filename role="package">www/apache2</filename>.</para>
 	    </listitem>
 
 	    <listitem>
 	      <para><filename role="package">www/thttpd</filename>:
 		Для обслуживания большого количества запросов к статическим
 		документам сервер thttpd может оказаться более эффективным, чем
 		Apache. thttpd отлично оптимизирован по производительности
 		при работе под FreeBSD.</para>
 	    </listitem>
 
 	    <listitem>
 	      <para><filename role="package">www/boa</filename>:
 		Boa&nbsp;&mdash; еще одна альтернатива thttpd и Apache.  Этот сервер
 		должен быть ощутимо более высокопроизводительным, чем Apache,
 		для полностью статических страниц.  На время написания данного
 		документа, впрочем, он не так хорошо оптимизирован под
 		FreeBSD, как thttpd.</para>
 	    </listitem>
 	  </itemizedlist>
 	</para>
       </sect3>
       <sect3 id="mirror-serv-cvsup">
 	<title>CVSup (желателен для зеркал репозитория CVS)</title>
 	<para>
 	  <application>CVSup</application> предоставляет очень эффективный
 	  механизм распространения файлов.  Он работает подобно
 	  <application>rsync</application> и был разработан специально для
 	  использования с репозиториями CVS.  Если вы планируете предоставлять
 	  доступ к репозиторию CVS FreeBSD, стоит делать это посредством
 	  <application>CVSup</application>.  Помимо этого, можно использовать
 	  <application>AnonCVS</application>, FTP, <application>Rsync</application>
 	  или HTTP, но использование <application>CVSup</application>
 	  наиболее разумно.
 	  Автором <application>CVSup</application> является &a.jdp;.
 	  <application>CVSup</application> непросто установить на платформе,
 	  отличной от FreeBSD, поскольку он написан на языке Modula-3 и
 	  требует соответствующего окружения.  Джон Полстра создал усеченную
 	  версию M3, достаточную для работы <application>CVSup</application>,
 	  которую намного проще установить. Подробности можно прочитать здесь:
 	  <ulink url="http://www.polstra.com/projects/freeware/ezm3/">Ezm3</ulink>.
 	  Относящиеся к теме пакеты:
 
 	  <itemizedlist>
 	    <listitem>
 	      <para><filename role="package">net/cvsup</filename>:
 		Порт CVSup (клиент и сервер), требующий для сборки пакет
 		<filename role="package">lang/ezm3</filename>.</para>
 	    </listitem>
 	    <listitem>
 	      <para><filename role="package">net/cvsup-mirror</filename>:
 		Набор для CVSup-зеркала, требующий
 		 <filename role="package">net/cvsup</filename>,
 		 и конфигурирующий его в процессе установки.  Возможно,
 		 некоторым администраторам потребуется другой набор установок.
 	      </para>
 	    </listitem>
 	  </itemizedlist>
 
 	  Может также оказаться полезным пакет
 	  <filename role="package">net/cvsup-without-gui</filename>.
 	  Если вы предпочитаете пакет, собранный статически, загляните по
 	  <ulink url="http://people.FreeBSD.org/~jdp/s1g/">этой</ulink>
 	  ссылке.  Эта страница все еще описывает ошибку S1G.  Возможно,
 	  в будущем Джон создаст универсальный сайт для загрузки статически
 	  собранных вариантов CVSup для различных платформ.
 	</para>
 	<para>
 	  При помощи <application>CVSup</application> можно распространять
 	  любые коллекции файлов (не только репозитории CVS), однако его
 	  конфигурация может быть непростой.  Известно, что
 	  <application>CVSup</application> потребляет ощутимое количество
 	  процессорного времени как на сервере, так и на клиенте, поскольку
 	  сравнивает большое количество файлов.
 	</para>
       </sect3>
       <sect3 id="mirror-anoncvs">
 	<title>AnonCVS (дополнителен для зеркал репозитория CVS)</title>
 	<para>
 	  Если вы копируете репозиторий CVS, можно дополнительно предоставить
 	  к нему анонимный доступ.  Для начала, предупреждение: спрос на этот
 	  сервис не так уж велик, подготовка его требует некоторого опыта, и,
 	  наконец, вы должны знать, что делаете.
 	</para>
 	<para>
 	  Существует два основных способа удаленного доступа к репозиторию
 	  CVS: через <emphasis>pserver</emphasis> и через
 	  <command>ssh</command> (доступ через <command>rsh</command> мы
 	  рассматривать не будем).  Для анонимного доступа наиболее подходит
 	  <emphasis>pserver</emphasis>; впрочем, некоторые сайты дают доступ
 	  и посредством <command>ssh</command>.  Для последнего будет полезной
 	  специальная
 	  <ulink url="ftp://ftp.FreeBSD.org/pub/FreeBSD/development/FreeBSD-CVS/anoncvs.shar">программа</ulink>,
 	  предназначенная для использования в качестве шелла для учетной
 	  записи анонимного ssh-доступа.  Она использует вызов chroot,
 	  поэтому репозиторий CVS должен располагаться внутри домашнего
 	  каталога анонимного пользователя, что приемлемо не для всех
 	  сайтов.  Данное ограничение не распространяется на доступ через
 	  <emphasis>pserver</emphasis>, однако последний вариант может быть
 	  связан с дополнительным риском с точки зрения безопасности.
 	  Никаких дополнительных программ для обеспечения анонимного
 	  CVS-доступа не потребуется, поскольку &man.cvs.1; входит в базовую
 	  поставку FreeBSD.  Вам нужно будет разрешить запуск
 	  <command>cvs</command> из <command>inetd</command>, для чего
 	  необходимо добавить в файл <filename>/etc/inetd.conf</filename>
 	  строку вида
 	  <programlisting>
 cvspserver stream tcp nowait root /usr/bin/cvs cvs -f -l -R -T /anoncvstmp --allow-root=/home/ncvs pserver
 	  </programlisting>
 	  Обратитесь к странице справочника &man.cvs.1; за дополнительной
 	  информацией по опциям.  Кроме того, страницы
 	  <emphasis>info</emphasis> по CVS описывают, как удостовериться в том,
 	  что вы предоставляете доступ только для чтения.  Рекомендуется
 	  создать непривилегированную учетную запись, желательно с именем
 	  <username>anoncvs</username>.  Потребуется также создать файл
 	  <filename>passwd</filename> в каталоге
 	  <filename>/home/ncvs/CVSROOT</filename> и установить пароль (пустой
 	  или <literal>anoncvs</literal>) для пользователя
 	  <username>anoncvs</username>.  Создание файловой системы
 	  <filename>/anoncvstmp</filename> в памяти не необходимо, но
 	  рекомендуется для ускорения работы: в ней &man.cvs.1; будет создавать
 	  временную структуру каталогов, которая не используется по завершении
 	  операции, но сильно замедляет работу, если требуются операции записи
 	  на реальный диск.  Пример описания такой файловой системы в файле
 	  <filename>/etc/fstab</filename>:
 	  <programlisting>
 /dev/da0s1b /anoncvstmp mfs rw,-s=786432,-b=4096,-f=512,-i=560,-c=3,-m=0,nosuid,nodev 0 0
 	  </programlisting>
 	  Эти установки (разумеется, тщательно подобранные) предложил
 	  &a.jdp;.
 	</para>
       </sect3>
    </sect2>
   </sect1>
   <sect1 id="mirror-howto">
     <title>Как вести зеркало FreeBSD</title>
     <para>
       Теперь вам известно, какая потребуется машина и как предоставлять
       сервисы, но не как получить их самому. :-)
       В этом разделе описывается процесс ведения зеркала и поддержания
       его в актуальном состоянии, в том числе какие инструменты
       использовать и какие сайты выбирать в качестве источников для
       синхронизации.
     </para>
     <sect2 id="mirror-ftp">
     <title>FTP</title>
       <para>
 	Файлы, доступные по FTP, составляют большую часть зеркала.
 	Они включают <emphasis>дистрибутивные наборы</emphasis>, необходимые
 	для установки по сети, <emphasis>ветви (branches)</emphasis>,
 	в которых отражено текущее состояние исходных текстов,
 	<emphasis>образы ISO</emphasis> для записи компакт-дисков с
 	дистрибутивами для установки, образами <quote>живых</quote> файловых
 	систем и пакетами, дерево портов, исходные дистрибутивы для сборки
 	портов и кучу готовых пакетов.  И, разумеется, все
 	вышеописанное&nbsp;&mdash; для разных версий FreeBSD и различных
 	архитектур.
       </para>
       <sect3 id="mirror-ftp-ftp">
 	<title>При помощи программ для FTP-зеркалирования</title>
 	<para>
 	  Для выкачивания файлов вы можете использовать программу
 	  <application>FTP-зеркалирования</application>.
 	  Существует довольно много таких, например:
 	  <itemizedlist>
 	    <listitem><para><filename role="package">ftp/mirror</filename></para></listitem>
 	    <listitem><para><filename role="package">ftp/ftpmirror</filename></para></listitem>
 	    <listitem><para><filename role="package">ftp/emirror</filename></para></listitem>
 	    <listitem><para><filename role="package">ftp/spegla</filename></para></listitem>
 	    <listitem><para><filename role="package">ftp/omi</filename></para></listitem>
 	    <listitem><para>и даже <filename role="package">ftp/wget</filename></para></listitem>
 	  </itemizedlist>
 
 	  Ранее наиболее популярным вариантом был
 	  <filename role="package">ftp/mirror</filename>, хотя из-за того, что
 	  эта программа написана на &man.perl.1;, существуют различные
 	  ограничения, в особенности при зеркалировании больших файловых
 	  структур, таких как FreeBSD.  Утверждается, впрочем, что в текущей
 	  версии последняя проблема исправлена за счет дополнительного
 	  алгоритма сравнения структуры каталогов.
 	</para>
 	<para>
 	  Вообще говоря, протокол FTP не лучшим образом подходит для поддержки
 	  зеркала.  Измененный файл передается целиком; кроме того, невозможно
 	  создание единого потока данных, который мог бы повысить
 	  эффективность передачи за счет большого TCP-окна.
 	</para>
       </sect3>
       <sect3 id="mirror-ftp-rsync">
 	<title>При помощи RSYNC</title>
 	<para>
 	  Более эффективным будет синхронизация FTP-области при помощи
 	  <application>rsync</application>.  Для этого следует установить
 	  пакет <filename role="package">net/rsync</filename>, который был
 	  описан в разделе <xref linkend="mirror-serv-rsync">.
 	  Поскольку доступ по протоколу <application>rsync</application> не
 	  является обязательным, выбранный вами сайт может его не
 	  поддерживать.  Возможно, вам придется немного поискать в сетевой
 	  окрестности зеркало, поддерживающее
 	  <application>rsync</application>.
 	  <note>
 	    <para>
 	      Поскольку от количества клиентов <application>rsync</application>
 	      ощутимо зависит загрузка сервера, большинство администраторов
 	      вводят ограничения доступа.  Для поддержания зеркала вам следует
 	      связаться с администратором сайта, с которым вы будете
 	      синхронизироваться, для уточнения локальных правил и, возможно,
 	      для внесения в них исключения для вас (поскольку вы также
 	      поддерживаете зеркало).
 	    </para>
 	  </note>
 	  Строка для синхронизации FreeBSD по rsync выглядит примерно так:
 	  <screen>&prompt.user; <userinput>rsync -vaz --delete ftp4.de.FreeBSD.org::FreeBSD/ /pub/FreeBSD/</userinput>
 	  </screen>
 	  Загляните в документацию по <application>rsync</application>,
 	  также доступную по адресу
 	  <ulink url="http://rsync.samba.org/">http://rsync.samba.org/</ulink>
 	  за дополнительной информацией по различным опциям rsync.
 	  Обратите внимание, что в случае синхронизации модуля целиком (а не
 	  отдельного каталога) необходимо явно указать результирующий каталог,
 	  потому что каталог с именем модуля (в данном случае "FreeBSD")
 	  не создается.  Для поддержания актуальности вам потребуется
 	  создать скрипт для запуска подобной команды из  &man.cron.8;.
 	</para>
       </sect3>
       <sect3 id="mirror-ftp-cvsup">
 	<title>При помощи CVSup</title>
 	<para>
 	  Немногие сайты, в первую очередь центральный
 	  <hostid role="fqdn">ftp-master.FreeBSD.org</hostid> предоставляют
 	  для синхронизации FTP-области доступ по протоколу
 	  <application>CVSup</application>.  Вам потребуется клиент
 	  <application>cvsup</application>, предпочтительно из пакета
 	  <filename role="package">net/cvsup</filename> (см. также
 	  <xref linkend="mirror-serv-cvsup">).
 	  Пример конфигурационного файла (<filename>supfile</filename>) для
 	  синхронизации с <hostid role="fqdn">ftp-master.FreeBSD.org</hostid>:
 	  <programlisting>
 #
 # FreeBSD archive supfile from master server
 #
 *default host=ftp-master.FreeBSD.org
 *default base=/usr
 *default prefix=/pub
 #*default release=all
 *default delete use-rel-suffix
 *default umask=002
 
 # If your network link is a T1 or faster, comment out the following line.
 #*default compress
 
 FreeBSD-archive release=all preserve
 	  </programlisting>
 
 	  Судя по всему, синхронизация при помощи
 	  <application>CVSup</application>&nbsp;&mdash; лучший по эффективности
 	  способ поддержки зеркала, однако он доступен лишь с небольшого числа
 	  сайтов.
 	  <note id="mirror-cvsup-s-option">
 	    <para>
 	      Прочтите документацию по <application>CVSup</application>,
 	      например, &man.cvsup.1;, и обратите внимание на опцию
 	      <option>-s</option>: она может существенно уменьшить объем
 	      работы при синхронизации.
 	    </para>
 	  </note>
 	</para>
       </sect3>
     </sect2>
     <sect2 id="mirror-cvs">
       <title>Синхронизация репозитория CVS</title>
       <para>
 	Как и в других случаях, репозиторий можно синхронизировать различными
 	способами; однако, рекомендуемым является
 	<link linkend="mirror-cvs-cvsup">CVSup</link>.
       </para>
       <sect3 id="mirror-cvs-cvsup">
 	<title>Использование CVSup</title>
 	<para>
 	  Программа <application>CVSup</application> уже была описана ранее
 	  (<xref linkend="mirror-serv-cvsup"> и
 	  <xref linkend="mirror-ftp-cvsup">).
 	</para>
 	<para>
 	  Здесь мы лишь приведем пример конфигурационного файла
 	  (<filename>supfile</filename>):
 	  <programlisting>
 #
 # FreeBSD CVS supfile from master server
 #
 *default host=cvsup-master.FreeBSD.org
 *default base=/usr
 *default prefix=/pub/FreeBSD/development/FreeBSD-CVS
 *default release=cvs
 *default delete use-rel-suffix
 *default umask=002
 
 # If your network link is a T1 or faster, comment out the following line.
 #*default compress
 
 cvs-all
 	  </programlisting>
 
 	  Кроме того, можете использовать в качестве шаблона
 	  <filename>/usr/share/examples/cvsup</filename>.
 	</para>
 	<note>
 	  <para>
 	    Не забудьте почитать полезную подсказку
 	    <link linkend="mirror-cvsup-s-option">здесь</link>.
 	  </para>
 	</note>
       </sect3>
       <sect3 id="mirror-cvs-other">
 	<title>Другие методы</title>
 	<para>
 	  Использование методов, отличных от
 	  <application>CVSup</application>, не рекомендуется.  Тем не менее,
 	  мы кратко упомянем их.  Поскольку большая часть зеркал дает доступ к
 	  репозиторию CVS в числе прочих файлов, доступных по FTP, по пути
 	  <filename>/pub/FreeBSD/development/FreeBSD-CVS</filename>,
 	  могут быть использованы:
 	  <itemizedlist>
 	    <listitem><para><application>FTP</application></para></listitem>
 	    <listitem><para><application>RSYNC</application></para></listitem>
 	    <listitem><para>и даже <application>HTTP</application></para></listitem>
 	  </itemizedlist>
 
 	  Если вы найдете сайт, поддерживающий обновления по
 	  <filename role="package">net/sup</filename>, можете использовать его.
 	  Впрочем, учитывая, что именно недостатки sup в свое время
 	  заставили Джона Полстру написать <application>CVSup</application>,
 	  данный метод никак не может быть рекомендован.
 
 	  <important>
 	    <para>
 	      Для синхронизации репозитория CVS <emphasis>не может
 	      быть</emphasis> использован AnonCVS, поскольку CVS не
 	      дает доступа к репозиторию напрямую, а лишь позволяет
 	      извлекать отдельные версии модулей.
 	    </para>
 	  </important>
 	</para>
       </sect3>
     </sect2>
     <sect2 id="mirror-www">
       <title>Зеркалирование страниц WWW</title>
       <para>
 	Лучшим способом будет извлечение (check out) из репозитория CVS модуля
 	<emphasis>www</emphasis>.  При условии наличия у вас копии
 	репозитория, все, что для этого потребуется&nbsp;&mdash; выполнить
 	один раз команду
 	<screen>&prompt.user; <userinput>cvs -d /home/ncvs co www</userinput></screen>
 	и сформировать задание для <emphasis>cron</emphasis>, которое будет
 	регулярно выполнять операцию <command>cvs up -d -P</command>,
 	например, каждый раз после обновления копии репозитория.
 	Разумеется, файлы должны находиться в иерархии, доступной для
 	публичного веб-доступа.  Мы сознательно не будем обсуждать здесь
 	процесс установки и конфигурации веб-сервера для этих целей.
       </para>
 
       <note><para>
 	Для того, чтобы страницы сайта стали доступны для просмотра,
 	необходимо выполнить команду &man.make.1; в основном каталоге модуля
 	<filename>www</filename>.  В результате будет создан комплект
 	стандартных файлов <filename>*.html</filename>, подготовленных для
 	просмотра веб-броузером.  Обращаем ваше внимание, что для этого
 	потребуется предварительно установить пакет
 	<filename role="package">textproc/docproj</filename>.</para></note>
       <para>
 	Если у вас нет локальной копии репозитория, можно использовать
 	<application>CVSup</application> для синхронизации копии веб-страниц.
 	Пример конфигурации можно найти в файле
 	<filename>/usr/share/examples/cvsup/www-supfile</filename>.
 	Приведем его здесь:
 	<programlisting>
 #
 # WWW module supfile for FreeBSD
 #
 *default host=cvsup3.de.FreeBSD.org
 *default base=/usr
 *default prefix=/usr/local
 *default release=cvs tag=.
 *default delete use-rel-suffix
 
 # If your network link is a T1 or faster, comment out the following line.
 *default compress
 
 # This collection retrieves the www/ tree of the FreeBSD repository
 www
 	</programlisting>
      </para>
      <para>
        Использование пакета <filename role="package">ftp/wget</filename> или
        иных инструментов для создания веб-зеркал не рекомендуется.
      </para>
      <sect3 id="mirror-www-doc">
        <title>Зеркала документации FreeBSD</title>
        <para>
 	 Поскольку многие веб-страницы ссылаются на документацию, хорошей идеей
 	 является поддержка зеркала документации FreeBSD совместно с прочими
 	 зеркалами.  Надо отметить, что этот процесс не столь тривиален, как
 	 поддержка зеркала веб-страниц самих по себе.
        </para>
        <para>
 	 Для начала вы должны создать копию исходных текстов документации
 	 (как и во многих других случаях, для этого предпочтителен
 	 <application>CVSup</application>). Вот пример файла конфигурации:
 	 <programlisting>
 #
 # FreeBSD documentation supfile
 #
 *default host=cvsup3.de.FreeBSD.org
 *default base=/usr
 *default prefix=/usr/share
 *default release=cvs tag=.
 *default delete use-rel-suffix
 
 # If your network link is a T1 or faster, comment out the following line.
 #*default compress
 
 # This will retrieve the entire doc branch of the FreeBSD repository.
 # This includes the handbook, FAQ, and translations thereof.
 doc-all
 	 </programlisting>
        </para>
        <para>
 	 Затем, вам потребуется несколько пакетов.  К счастью,
 	 специально для этого существует мета-порт
 	 <filename role="package">textproc/docproj</filename>.
 	 Также, необходимо установить некоторые переменные окружения,
 	 например <literal>SGML_CATALOG_FILES</literal>, и переменные
 	 в файле <filename>/etc/make.conf</filename>, главным образом
 	 переменную <literal>DOC_LANG</literal> (используйте файл
 	 <filename>/etc/defaults/make.conf</filename> как шаблон).
 	 После этого можно выдать команду <command>make</command>
 	 в главном каталоге документации (по умолчанию это
 	 <filename>/usr/share/doc</filename>).  Как и прежде, эти каталоги
 	 должны быть доступны для вашего веб-сервера (проверьте, что ссылки
 	 ведут в нужные места).
 	 <important>
 	   <para>
 	     Процесс подготовки и построения документации, а также многие
 	     сопутствующие вопросы, подробно описан в документе
 	     <ulink url="http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/fdp-primer/">fdp-primer</ulink>.
 	     Прочтите этот документ, в особенности если у вас возникли
 	     проблемы со сборкой стандартного комплекта документации
 	     FreeBSD.
 	   </para>
 	 </important>
 	 <note>
 	   <para>
 	   <!-- к чему это относится - мне непонятно [marck] -->
 	   XXX MAYBE THIS CAN BE LINKED FROM WITHIN - NOT USING AN ABSOLUTE URL XXX
 	   </para>
 	 </note>
        </para>
      </sect3>
    </sect2>
    <sect2 id="mirror-how-often">
      <title>Как часто синхронизироваться?</title>
      <para>
        Каждое зеркало должно регулярно обновляться.  Вам потребуется какой-то
        набор скриптов, выполняемых посредством &man.cron.8;.  Поскольку каждый
        администратор, как правило, пишет такие скрипты сам и на свой лад, мы
        не можем выдать конкретных указаний.  Общие же советы выглядят так:
      </para>
      <procedure>
        <step>
 	 <para>
 	   Создайте скрипт с командой, которая запустит нужное приложение для
 	   обновления зеркала.  Рекомендуем использовать скрипт на языке
 	   обычного <command>/bin/sh</command>.
 	 </para>
        </step>
        <step>
 	 <para>
 	   Добавьте команд перенаправления вывода, чтобы записать диагностику
 	   работы в файл.
 	 </para>
        </step>
        <step>
 	 <para>
 	   Попробуйте, как ваш скрипт работает.  По завершении проверьте логи.
 	 </para>
        </step>
        <step>
 	 <para>
 	   При помощи утилиты &man.crontab.1; добавьте ваш скрипт в таблицу
 	   регулярных заданий &man.crontab.5; соответствующего пользователя.
 	   Это должен быть пользователь, отличный от пользователя FTP-даемона,
 	   чтобы файлы в FTP-области без атрибута "чтение для всех" не были
 	   доступны анонимным FTP-пользователям.  Данное свойство используется
 	   для тестирования перед выходом новых релизов, для того чтобы
 	   удостовериться, что все официальные зеркала содержат все
 	   необходимые файлы к моменту официального объявления релиза.
 	 </para>
        </step>
      </procedure>
      <para>
        Некоторые рекомендуемые установки частоты обновления:
        <itemizedlist>
 	 <listitem><para>FTP-набор: раз в сутки</para></listitem>
 	 <listitem><para>репозиторий CVS: от раза в сутки до раза в час</para></listitem>
 	 <listitem><para>WWW-страницы: раз в сутки</para></listitem>
        </itemizedlist>
      </para>
    </sect2>
   </sect1>
   <sect1 id="mirror-where">
     <title>С какого сервера синхронизироваться</title>
     <para>
       Это важный вопрос, так что мы попытаемся пояснить, откуда берутся
       ответы.  Для начала повторим еще несколько раз: <emphasis>никогда
       не синхронизируйтесь с <hostid role="fqdn">ftp.FreeBSD.org</hostid>
       </emphasis>.
     </para>
     <sect2 id="mirror-where-organization">
       <title>Организация системы зеркал</title>
       <para>
 	Зеркала организуются по странам.  Имена хостов всех официальных зеркал
 	построены по принципу <hostid role="fqdn">ftpN.CC.FreeBSD.org</hostid>,
 	где <emphasis>CC</emphasis> (country code)&nbsp;&mdash; домен верхнего
 	уровня страны, где расположено зеркало,
 	<emphasis>N</emphasis>&nbsp;&mdash; номер зеркала в данной стране.
 	Этот же принцип применим к именам хостов
 	<hostid>cvsupN.CC.FreeBSD.org</hostid>,
 	<hostid>wwwN.CC.FreeBSD.org</hostid> и т.п.
 	Кроме того, есть зеркала без доменной части, обозначающей страну.
 	Все они имеют очень хорошие внешние каналы и обслуживают большое число
 	одновременных соединений.
 	Имя <hostid role="fqdn">ftp.FreeBSD.org</hostid> на самом деле
 	указывает на две машины, одна из которых в настоящее время находится
 	в Дании, а другая в США.
 	Ни одна из этих машин <emphasis>НЕ</emphasis> является основным
 	сайтом, и потому не должна использоваться для синхронизации.
 	Масса документации для <quote>живых</quote> пользователей указывает на
 	<hostid role="fqdn">ftp.FreeBSD.org</hostid>, так что автоматическим
 	системам ведения зеркал следует выбирать другие источники
 	синхронизации.
       </para>
       <para>
 	Кроме того, существует иерархия зеркал в терминах их удаленности от
 	центра, или <emphasis>слоях</emphasis>.  Основные сайты могут быть
 	описаны как <emphasis>Зеркала нулевого слоя</emphasis>.  Зеркала,
 	синхронизирующиеся по ним, считаются <emphasis>слоем 1</emphasis>,
 	следующие&nbsp;&mdash; <emphasis>слоем 2</emphasis> и т.д.  Официальные
 	сайты приглашаются на низкие слои, однако следует помнить, что чем
 	меньше номер слоя, тем выше требования к зеркалу, как было описано в
 	<xref linkend="mirror-requirements">.  Помимо того, доступ к
 	зеркалам 1 слоя может быть ограничен; безусловно ограничен доступ к
 	основным сайтам. Иерархия <emphasis>слоев</emphasis> не отражается в
 	DNS и, вообще говоря, нигде (кроме мастер-сайтов) не документирована.
 	Тем не менее, официальные зеркала с малыми (1-4, как правило) номерами
 	обычно представляют первый слой.  (Это грубая оценка, и ни в коем
 	случае не правило).
       </para>
     </sect2>
     <sect2 id="mirror-where-where">
       <title>Так откуда же мне синхронизироваться?</title>
       <para>
 	Главное&nbsp;&mdash; НЕ с <hostid role="fqdn">ftp.FreeBSD.org</hostid>.
 	Короткий ответ: с зеркала, которое расположено недалеко от вас
 	в терминах Интернет, и/или доступ к которому наилучший.
       </para>
       <sect3 id="mirror-where-simple">
 	<title>Я хочу получить копию зеркала хоть откуда-нибудь!</title>
 	<para>
 	  Если у вас нет каких-либо специальных предпочтений или требований,
 	  см. <xref linkend="mirror-where-where">.  Это означает:
 	</para>
 	<procedure>
 	  <step>
 	    <para>
 	      Посмотрите на список доступных зеркал в вашей стране.
 	      Вам может помочь
 	      <ulink url="http://mirrorlist.FreeBSD.org/">База
 	      данных зеркал FreeBSD</ulink>.
 	    </para>
 	  </step>
 	  <step>
 	    <para>
 	      Выберите те из них, с которыми вам работать быстрее всего
 	      (меньшее число промежуточных узлов и время отклика), и которые предоставляют
 	      нужные вам сервисы (такие как <application>rsync</application>
 	      или <application>CVSup</application>).
 	    </para>
 	  </step>
 	  <step>
 	    <para>
 	      Свяжитесь с администраторами выбранного сервера, опишите ваши
 	      запросы и уточните их правила.
 	    </para>
 	  </step>
 	  <step>
 	    <para>
 	      Сконфигурируйте ваше зеркало, как описывалось выше.
 	    </para>
 	  </step>
 	</procedure>
       </sect3>
       <sect3 id="mirror-where-official">
 	<title>Я поддерживаю официальное зеркало, какой сайт мне выбрать?</title>
 	<para>
 	  В основном, правила, описанные в
 	  <xref linkend="mirror-where-simple">, применимы.
 	  Дополнительно можно убедиться, что выбранный сайт принадлежит
 	  низкому слою.
 	  Другие соображения относительно <emphasis>официальных</emphasis>
 	  зеркал описаны в <xref linkend="mirror-official">.
 	</para>
       </sect3>
       <sect3 id="mirror-where-master">
 	<title>Мне нужен доступ к основным сайтам!</title>
 	<para>
 	  При наличии достаточных причин вы можете получить доступ к одному из
 	  основных сайтов.  Доступ к ним ограничен; существуют специальные
 	  правила их использования.  Наличие у вас статуса
 	  <emphasis>официального</emphasis> зеркала, безусловно, является
 	  хорошим подспорьем.  В противном случае убедитесь, что ваша
 	  страна действительно нуждается еще в одном зеркале.
 	  Если их уже три или более, сначала свяжитесь с администратором
 	  соответствующей зоны DNS (<email>hostmaster@CC.FreeBSD.org</email>)
 	  или напишите в &a.hubs;.
 	</para>
 
 	<para>
 	  Доступ к одному из мастер-сайтов или подходящему зеркалу 1 уровня
 	  вам помогут обеспечить те же, кто помогал вам получить статус
 	  <emphasis>официального</emphasis> зеркала.  В случае неудачи
 	  свяжитесь с <email>mirror-admin@FreeBSD.org</email> и попросите
 	  помощи у них.
 	</para>
 
 	<para>
 	  Существует три основных сайта для синхронизации набора файлов FTP
 	  и один для репозитория CVS.  Веб-страницы и документация хранятся
 	  в CVS, поэтому не имеют отдельных основных сайтов.
 	</para>
 	<sect4 id="mirror-where-master-ftp">
 	  <title>ftp-master.FreeBSD.org</title>
 	  <para>
 	    Это основной сервер для синхронизации FTP набора.
 	  </para>
 	  <para>
 	    <hostid>ftp-master.FreeBSD.org</hostid> поддерживает доступ по
 	    <application>rsync</application> и
 	    <application>CVSup</application>.  Использование этих протоколов
 	    описано в разделах <xref linkend="mirror-ftp-rsync"> и
 	    <xref linkend="mirror-ftp-cvsup">.
 	  </para>
 	  <para>
 	    Приветствуется предоставление зеркалами
 	    <emphasis>1 уровня</emphasis> доступа к FTP-области по протоколу
 	    <application>rsync</application>.
 	  </para>
 	</sect4>
 	<sect4 id="mirror-where-master-cvsup">
 	  <title>cvsup-master.FreeBSD.org</title>
 	  <para>
 	    Это основной сервер для синхронизации репозитория CVS.
 	  </para>
 	  <para>
 	    <hostid>cvsup-master.FreeBSD.org</hostid> обеспечивает доступ
 	    только по протоколу <application>CVSup</application>.
 	    Детали см. в <xref linkend="mirror-cvs-cvsup">.
 	  </para>
 	  <para>
 	    Для получения доступа к этому серверу вам нужно связаться с
 	    &a.cvsup-master;.  Не забудьте сначала прочитать
 	    <ulink url="http://people.FreeBSD.org/~jdp/cvsup-access/">Правила
 	    доступа к центральному CVSup серверу FreeBSD</ulink>!
 	  </para>
 	  <para>
 	    Подготовьте параметры авторизации, как описано
 	    <ulink url="http://people.FreeBSD.org/~jdp/cvpasswd/">здесь</ulink>.
 	    Не забудьте, что в качестве имени сервера команде
-	    <command>cvpasswd</command>нужно указать
-	    <hostid>freefall.FreeBSD.org</hostid>, несмотря на что, что
+	    <command>cvpasswd</command> нужно указать
+	    <hostid>freefall.FreeBSD.org</hostid>, несмотря на то, что
 	    устанавливать соединение вы будете с
 	    <hostid>cvsup-master.FreeBSD.org</hostid>.
 	  </para>
 	</sect4>
       </sect3>
     </sect2>
   </sect1>
   <sect1 id="mirror-official">
     <title>Официальные зеркала</title>
     <para>
       Официальные зеркала обладают следующим свойствами:
       <itemizedlist>
 	<listitem>
 	  <para>
 	    a) имеют запись в домене <hostid>FreeBSD.org</hostid>
 	    (обычно типа CNAME).
 	  </para>
 	</listitem>
 	<listitem>
 	  <para>
 	    b) присутствуют в списке официальных зеркал в Руководстве
 	    по FreeBSD и другой документации.
 	  </para>
 	</listitem>
       </itemizedlist>
 
       На настоящий момент это все, что отличает их от прочих зеркал.
       Официальные зеркала не обязательно принадлежат к
       <emphasis>Первому уровню</emphasis>, однако, вряд ли можно найти
       зеркало <emphasis>уровня 1</emphasis>, не являющееся официальным.
     </para>
     <sect2 id="mirror-official-requirements">
       <title>Отдельные требования к официальным зеркалам 1 уровня</title>
       <para>
 	Описать требования для всех официальных зеркал не так просто,
 	поскольку проект FreeBSD достаточно мягок в этом отношении.
 	Несколько проще указать, что требуется от <emphasis>официальных
 	зеркал уровня 1</emphasis>.  Прочие официальные зеркала должны
 	рассматривать этот список как <emphasis>настойчивые
 	пожелания</emphasis>.
 	<note>
 	  <para>
 	    Следующее относится в основном к набору файлов FTP, поскольку
 	    репозиторий CVS всегда должен зеркалироваться полностью,
 	    а веб-страницы представляют собой несколько особый случай.
 	  </para>
 	</note>
       </para>
       <para>
 	Зеркала 1 уровня должны:
 	<itemizedlist>
 	  <listitem><para>поддерживать полный список файлов</para></listitem>
 	  <listitem><para>предоставлять доступ для других зеркал</para></listitem>
 	  <listitem><para>обеспечивать доступ по протоколам
 	    <application>FTP</application> и
 	    <application>RSYNC</application>.
 	  </para></listitem>
 	</itemizedlist>
 
 	Кроме того, администратор такого зеркала должен быть подписан на &a.hubs;.
 	См. <ulink url="http://www.FreeBSD.org/doc/ru_RU.KOI8-R/books/handbook/eresources.html#ERESOURCES-MAIL">здесь</ulink>
 	  для дополнительной информации о подписке.
       </para>
       <important>
 	<para>
 	  Администраторы зеркал, в особенности 1 уровня, должны
 	  <emphasis>очень</emphasis> внимательно следить за
 	  <ulink url="http://www.FreeBSD.org/releng/">графиком релизов</ulink>.
 	  Это поможет подготовиться к крупным всплескам нагрузки на зеркало,
 	  которые всегда происходят после очередного релиза.
 	</para>
 	<para>
 	  Кроме того, важно поддерживать актуальность зеркал (в особенности
 	  зеркал уровня 1).  Если Зеркало1 не синхронизировалось в течение
 	  длительного времени, то зеркала следующего уровня будут
 	  синхронизироваться по устаревшей информации и т.д.
 	  Поддерживайте актуальность ваших зеркал!
 	</para>
       </important>
     </sect2>
     <sect2 id="mirror-official-become">
       <title>Как стать официальным зеркалом?</title>
       <para>
 	Небезынтересный вопрос, в особенности если учитывать последствия
 	становления официальным зеркалом, например, увеличившиеся счета
 	за интернет от вашего провайдера (ведь нагрузка на ваш сервер
 	неизбежно увеличится).  Статус официального зеркала может быть
 	ключевым требованием для доступа к основному сайту.
       </para>
       <para>
 	Прежде чем отправлять заявку, убедитесь в необходимости
 	дополнительного официального зеркала в вашем регионе.  Справьтесь у
 	администратора вашей зоны (<email>hostmaster@CC.FreeBSD.org</email>)
 	или, в случае, если вам не отвечают, здесь: &a.hubs;.
       </para>
       <para>Собственно процедура такова:</para>
       <procedure>
 	<step>
 	  <para>
 	    Обеспечьте работоспособность и актуальность зеркала (скорее всего,
 	    синхронизируясь не по основному сайту).
 	  </para>
 	</step>
 	<step>
 	  <para>
 	    Подпишитесь
 	    <ulink url="http://www.FreeBSD.org/doc/ru_RU.KOI8-R/books/handbook/eresources.html#ERESOURCES-MAIL">здесь</ulink>
 	    на &a.hubs;.
 	  </para>
 	</step>
 	<step>
 	  <para>
 	    После успешного завершения предыдущих пунктов, напишите
 	    администратору DNS вашего региона (страны) и попросите его создать
 	    запись в зоне для вашего сайта.  Почтовый адрес администратора
 	    <email>hostmaster@CC.FreeBSD.org</email>, где
 	    <emphasis>CC</emphasis>&nbsp;&mdash; код вашей страны (и суффикс
 	    домена верхнего уровня).  Формат вашей записи в DNS описан в
 	    <xref linkend="mirror-where-organization">.
 	  </para>
 	  <para>
 	    Если для вашей страны пока не создано поддомена, свяжитесь с
 	    <email>mirror-admin@FreeBSD.org</email> или сначала напишите
 	    в &a.hubs;.
 	  </para>
 	</step>
 	<step>
 	  <para>
 	    Персона, помогавшая вам получить статус официального зеркала,
 	    должна послать письмо <email>mirror-admin@FreeBSD.org</email>,
 	    чтобы ваш сайт был включен в список официальных зеркал в
 	    <ulink url="http://www.FreeBSD.org/doc/ru_RU.KOI8-R/books/handbook">Руководстве
 	    FreeBSD</ulink>.
 	  </para>
 	</step>
       </procedure>
       <!-- XXX Ну не писать же здесь "как-нибудь так (с) Масяня" [marck] ;-))) XXX
       <para>That is it.</para>
       -->
     </sect2>
   </sect1>
   <sect1 id="mirror-statpages">
     <title>Статистика некоторых зеркал</title>
     <para>
       Вот несколько ссылок на статистику использования зеркал
     </para>
     <sect2 id="mirror-statpagesftp">
       <title>Статистика FTP сайтов</title>
       <itemizedlist>
 	<listitem>
 	  <para>ftp2.FreeBSD.org - <email>grisha@ispol.com</email> -
 	    <ulink url="http://people.FreeBSD.org/~logo/ftp2/">(загрузка канала)</ulink>
 	  </para>
 	</listitem>
 	<listitem>
 	  <para>ftp.is.FreeBSD.org - <email>hostmaster@is.FreeBSD.org</email> -
 	    <ulink url="http://www.rhnet.is/status/draupnir/draupnir.html">
 	    (загрузка канала)</ulink> <ulink url="http://www.rhnet.is/status/ftp/ftp-notendur.html">(FTP
 	    процессы)</ulink> <ulink url="http://www.rhnet.is/status/ftp/http-notendur.html">(HTTP процессы)
 	    </ulink>
 	  </para>
 	</listitem>
 	<listitem>
 	  <para>ftp.cz.FreeBSD.org - <email>cejkar@fit.vutbr.cz</email> -
 	    <ulink url="http://www.cz.FreeBSD.org/stats/mrtg/net.html">(загрузка канала)</ulink>
 	    <ulink url="http://www.freebsd.cz/stats/mrtg/ftpd.html">(FTP процессы)</ulink>
 	    <ulink url="http://www.freebsd.cz/stats/mrtg/rsyncd.html">(Rsync процессы)</ulink>
 	  </para>
 	</listitem>
 	<listitem>
 	  <para>ftp4.de.FreeBSD.org - <email>dl@leo.org</email> -
 	    <ulink url="http://admin.leo.org/mrtg/services/ftp/ftp.html">(пользователи FTP)</ulink>
 	    <ulink url="http://admin.leo.org/mrtg/services/rsync/rsync.html">(пользователи RSYNC)</ulink>
 	  </para>
 	</listitem>
       </itemizedlist>
     </sect2>
     <sect2 id="mirror-statpagescvsup">
       <title>Статистика CVSup сайтов</title>
       <itemizedlist>
 	<listitem>
 	  <para>cvsup[23456].jp.FreeBSD.org - <email>kuriyama@FreeBSD.org</email> - <ulink
 	    url="http://home.jp.FreeBSD.org/stats/mrtg/cvsup/">(CVSup процессы)</ulink></para>
 	</listitem>
 	<listitem>
 	  <para>cvsup.cz.FreeBSD.org - <email>cejkar@fit.vutbr.cz</email> -
 	    <ulink url="http://www.freebsd.cz/stats/mrtg/cvsupd.html">(CVSup процессы)</ulink></para>
 	</listitem>
 	<listitem>
 	  <para>[cvsup3|anoncvs].de.FreeBSD.org - <email>dl@leo.org</email> -
 	    <ulink url="http://admin.leo.org/mrtg/services/cvsup/cvsup.html">(CVSup процессы)</ulink></para>
 	</listitem>
       </itemizedlist>
     </sect2>
   </sect1>
 </article>
 
 <!--
      Local Variables:
      mode: sgml
      sgml-indent-data: t
      sgml-omittag: nil
      sgml-always-quote-attributes: t
      End:
 -->
diff --git a/ru_RU.KOI8-R/articles/portbuild/article.sgml b/ru_RU.KOI8-R/articles/portbuild/article.sgml
index 769b32bb3d..52bb9550bf 100644
--- a/ru_RU.KOI8-R/articles/portbuild/article.sgml
+++ b/ru_RU.KOI8-R/articles/portbuild/article.sgml
@@ -1,736 +1,726 @@
+<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
 <!--
      The FreeBSD Russian Documentation Project
 
-     $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/portbuild/article.sgml,v 1.5 2004/07/26 08:33:34 den Exp $
+     $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/portbuild/article.sgml,v 1.6 2004/09/06 07:28:35 marck Exp $
 
-     Original revision: 1.5
+     Original revision: 1.6
 -->
 
-<!DOCTYPE article PUBLIC "-//FreeBSD//DTD DocBook V4.1-Based Extension//EN" [
-<!ENTITY % man PUBLIC "-//FreeBSD//ENTITIES DocBook Manual Page Entities//EN">
-%man;
-<!ENTITY % freebsd PUBLIC "-//FreeBSD//ENTITIES DocBook Miscellaneous FreeBSD Entities//EN">
-%freebsd;
-<!ENTITY % authors PUBLIC "-//FreeBSD//ENTITIES DocBook Author Entities//EN">
-%authors;
-<!ENTITY % teams PUBLIC "-//FreeBSD//ENTITIES DocBook Team Entities//RU">
-%teams;
-<!ENTITY % mailing-lists PUBLIC "-//FreeBSD//ENTITIES DocBook Mailing List Entities//RU">
-%mailing-lists;
-<!ENTITY % trademarks PUBLIC "-//FreeBSD//ENTITIES DocBook Trademark Entities//RU">
-%trademarks;
+<!ENTITY % articles.ent PUBLIC "-//FreeBSD//ENTITIES DocBook FreeBSD Articles Entity Set//EN">
+%articles.ent;
 ]>
 
 <article lang="ru">
   <articleinfo>
     <title>Процесс построения пакетов</title>
 
     <authorgroup>
       <corpauthor>Группа поддержки портов &os;</corpauthor>
     </authorgroup>
 
     <pubdate>$FreeBSD$</pubdate>
 
     <copyright>
       <year>2003</year>
       <year>2004</year>
       <holder role="mailto:portmgr@FreeBSD.org">Группа поддержки портов
 	&os;</holder>
     </copyright>
 
     <legalnotice id="trademarks" role="trademarks">
       &tm-attrib.freebsd;
       &tm-attrib.intel;
       &tm-attrib.sparc;
       &tm-attrib.general;
     </legalnotice>
   </articleinfo>
 
   <sect1 id="intro">
     <title>Введение</title>
 
     <para>Для того, чтобы подготовить предкомпилированные версии
       поддерживаемых приложений для &os;, на одном из <quote>Кластеров сборки
       пакетов</quote> регулярно производится сборка полного дерева портов.
       В настоящее время существует два таких кластера:
       <hostid role="fqdn">pointyhat.FreeBSD.org</hostid> и
       <hostid role="fqdn">dosirak.kr.FreeBSD.org</hostid>.</para>
 
     <para>Большая часть <quote>магии</quote> процесса сборки
       сосредоточена в дереве каталогов <filename>/var/portbuild</filename>.
       Если не оговаривается иное, все пути указаны относительно этого
       каталога.  <replaceable>${arch}</replaceable> используется для указания
       на архитектуру платформы сборки (&i386;, alpha, &sparc64;, ia64 или
       amd64); <replaceable>${branch}</replaceable> описывает ветвь построения
       (4, 5, 4-exp).
     </para>
   </sect1>
 
   <sect1 id="management">
     <title>Конфигурация машин-клиентов</title>
 
     <para>Клиенты архитектур &i386;, alpha, amd64 и два из &sparc64; клиентов
       загружаются по сети с <hostid>pointyhat</hostid>; прочие sparc64 клиенты
       и машины для сборки ia64 загружаются самостоятельно.  Так или иначе, все
       они в процессе загрузки подготавливаются к сборке пакетов.
     </para>
 
     <para>В серии последних обновлений была добавлена поддержка
       <replaceable>несвязанных (disconnected)</replaceable> узлов кластера.
       Несвязанный узел не монтирует мастер-машину кластера по NFS, и может,
       таким образом, быть достаточно удален от центра.  Мастер-машина копирует
       нужные данные (иерархии портов, исходных текстов системы и документации,
       архивы системы, скрипты и т.п.) при помощи rsync на этапе начальной
       конфигурации узлов.  Затем, каталог portbuild монтируется как nullfs
       для сборок пакетов.
     </para>
 
     <para>Псевдо-пользователь
       <username>ports-<replaceable>${arch}</replaceable></username>
       может выполнить команду &man.ssh.1; от имени <username>root</username>
       на любую клиентскую машину архитектуры
       <replaceable>${arch}</replaceable>.
     </para>
 
     <para>Скрипт <command>scripts/allgohans</command> используется для
       выполнения команд на всех клиентах архитектуры
       <replaceable>${arch}</replaceable>.
     </para>
 
     <para>Скрипт <command>scripts/checkmachines</command> отслеживает уровень
       загрузки узлов кластера и распределяет, какой из узлов будет строить
       очередной порт.  Этот скрипт не слишком умен и время от времени умирает.
       Лучше всего запускать его при загрузке основной машины кластера
       (<hostid>pointyhat</hostid> или <hostid>dosirak</hostid>) в цикле
       &man.while.1;.
     </para>
   </sect1>
 
   <sect1 id="setup">
     <title>Подготовка ограниченной среды сборки</title>
 
     <para>Пакеты собираются в ограниченной (<literal>chroot</literal>) среде,
       которая разворачивается скриптом <filename>portbuild</filename> из архива
       <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/tarballs/bindist.tar</filename>.
       Этот архив создается при помощи скрипта <command>mkbindist</command>,
       конфигурация которого описывается файлом
       <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/mkbindist.conf</filename>.
     </para>
 
     <para>Скрипт должен запускаться с правами пользователя
       <username>root</username> и следующими параметрами:
     </para>
 
     <screen>/var/portbuild&prompt.root; <userinput>scripts/mkbindist <replaceable>${arch}</replaceable> <replaceable>${branch}</replaceable></userinput></screen>
 
     <para>При указании в файле <filename>mkbindist.conf</filename> параметра
       <literal>ftp=1</literal> с адреса
       ftp://<replaceable>${ftpserver}</replaceable>/<replaceable>${ftpurl}</replaceable>/<replaceable>${rel}</replaceable>
       будет загружен предварительно собранный релиз.
       Если указано <literal>ftp=0</literal> и <literal>buildworld=1</literal>,
       скрипт <command>mkbindist</command> выполнит
       <command>makeworld</command> для того, чтобы собрать релиз на месте
       [<literal>XXX</literal> Эта часть в настоящее время не работает].
     </para>
 
     <para>Если оба параметра равны нулю (<literal>ftp=0</literal> и
       <literal>buildworld=0</literal>), то <command>mkbindist</command>
       будет использовать существующее на момент запуска состояние дерева
       <replaceable>${worlddir}</replaceable> для создания
       <filename>bindist.tar</filename>.  На практике это означает, что вы
       должны предварительно установить систему в ${worlddir}, что обычно
       делается при помощи скрипта <command>makeworld</command>:
     </para>
 
     <screen>/var/portbuild&prompt.root; <userinput>scripts/makeworld <replaceable>${arch}</replaceable> <replaceable>${branch}</replaceable> [-nocvs]</userinput></screen>
 
     <para>Эта команда соберет систему на базе исходных текстов в дереве
       <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/src</filename>
       и установит ее в <replaceable>${worlddir}</replaceable>.
       Исходные тексты будут обновлены, если не указан параметр
       <literal>-nocvs</literal>.
     </para>
 
     <para>Содержимое архива <filename>bindist.tar</filename> будет распаковано
       на каждом клиенте в период загрузки, а также на старте каждого прохода
       скрипта <command>dopackages</command>.
     </para>
   </sect1>
 
   <sect1 id="starting">
     <title>Запуск сборки</title>
 
     <para>Для сборки пакетов используются скрипты
       <filename>scripts/dopackages*</filename>.  Наиболее полезными являются:
     </para>
 
     <itemizedlist>
       <listitem>
 	<para><command>dopackages.5</command> - собирает пакеты для версии 5.X
 	</para>
       </listitem>
 
       <listitem>
 	<para><command>dopackages.4</command> - собирает пакеты для версии 4.X
 	</para>
       </listitem>
 
       <listitem>
 	<para><command>dopackages.4-exp</command> - производит сборку ветви
 	  для версии 4.X с экспериментальными изменениями (ветвь 4-exp)
 	</para>
       </listitem>
     </itemizedlist>
 
     <para>Все они вызывают универсальный скрипт <command>dopackages</command>,
       и являются символьными ссылками на <command>dopackages.wrapper</command>.
       Для создания скрипта для сборки пакетов новой ветви достаточно создать
       символическую ссылку <command>dopackages.${branch}</command>, указывающую
       на <command>dopackages.wrapper</command>.  Могут быть указаны
       многочисленные параметры, например:
 
     <screen><command>dopackages.5 <replaceable>${arch}</replaceable> <literal>[-options]</literal></command></screen>
 
     <para><literal>[-options]</literal> может быть произвольным набором из
       следующих опций:</para>
 
     <itemizedlist>
       <listitem>
 	<para><literal>-nofinish</literal> - Не производить пост-обработку
 	  по завершении сборки.  Полезно, если процесс сборки потребуется
 	  рестартовать.  В обычных ситуациях эту опцию следует использовать
 	  всегда.
 	</para>
       </listitem>
 
       <listitem>
 	<para><literal>-finish</literal> - Произвести пост-обработку
 	  (и только: собственно сборку не производить).
 	</para>
       </listitem>
 
       <listitem>
 	<para><literal>-restart</literal> - Рестартовать прерванный
 	  (или незавершенный, т.е. запущенный без флага
 	  <literal>-finish</literal>) процесс сборки с самого начала.
 	  При этом порты, попытка сборки которых на предыдущем проходе
 	  завершилась неудачно, будут пересобраны.
 	</para>
       </listitem>
 
       <listitem>
 	<para><literal>-continue</literal> - Продолжить прерванный
 	  (или незавершенный) процесс сборки.  Порты, не прошедшие
 	  сборку, не пересобираются.
 	</para>
       </listitem>
 
       <listitem>
 	<para><literal>-incremental</literal> - Сравнить необходимые поля
 	  в текущем файле <literal>INDEX</literal> с его предыдущим состоянием,
 	  удалить пакеты и журналы их сборки для обновившихся портов и
 	  пересобрать их.  Этот ключ позволяет существенно сократить время
 	  сборки, поскольку нет необходимости пересобирать каждый раз не изменившиеся
 	  порты. [XXX Этот фрагмент находится в процессе разработки и пока не
 	  работает так как надо.]
 	</para>
       </listitem>
 
       <listitem>
 	<para><literal>-cdrom</literal> - Текущая сборка предназначена для
 	  помещения на CD-ROM, поэтому исходные архивы и пакеты портов,
 	  помеченных <literal>NO_CDROM</literal> должны быть удалены при
 	  пост-обработке.
 	</para>
       </listitem>
 
       <listitem>
 	<para><literal>-nobuild</literal> - Произвести первоначальную
 	  подготовку, не запуская собственно процесс сборки пакетов.
 	</para>
       </listitem>
 
       <listitem>
 	<para><literal>-noindex</literal> - Не перестраивать файл
 	  <filename>INDEX</filename> в ходе препроцессинга.
 	</para>
       </listitem>
 
       <listitem>
 	<para><literal>-noduds</literal> - Не перестраивать файл
 	  <filename>duds</filename> (список портов, которые не будут строиться,
 	  например, помеченные признаками <literal>IGNORE</literal>,
 	  <literal>NO_PACKAGE</literal> и т.п.) перед процессом сборки.
 	</para>
       </listitem>
 
       <listitem>
 	<para><literal>-trybroken</literal> - Пытаться собрать порты,
 	  помеченные как <literal>BROKEN</literal> (по умолчанию выключено,
 	  поскольку кластер архитектуры &i386; довольно быстр, и при
 	  инкрементальной сборке больше времени тратится на пересборку
 	  того, что все равно не сможет собраться.
 	  С другой стороны, кластеры других архитектур достаточно медленны,
 	  так что пытаться собирать на них порты с флагом
 	  <literal>BROKEN</literal> было бы напрасной тратой времени.
 	</para>
       </listitem>
 
       <listitem>
 	<para><literal>-nocvs</literal> - Не выполнять обновление
 	  (<command>cvs update</command>) дерева исходных текстов
 	  (<literal>src</literal>) на этапе препроцессинга.
 	</para>
       </listitem>
 
       <listitem>
 	<para><literal>-noportscvs</literal> - Не обновлять
 	  (<command>cvs update</command>) дерево портов
 	  (<literal>ports</literal>) на этапе препроцессинга.
 	</para>
       </listitem>
 
       <listitem>
 	<para><literal>-nodoccvs</literal> - Не обновлять
 	  (<command>cvs update</command>) дерево документации
 	  (<literal>doc</literal>) в ходе препроцессинга.
 	</para>
       </listitem>
 
       <listitem>
 	<para><literal>-norestr</literal> - Не пытаться компилировать порты,
 	  помеченные как <literal>RESTRICTED</literal>.
 	</para>
       </listitem>
 
       <listitem>
 	<para><literal>-plistcheck</literal> - Считать ошибкой оставление
 	  лишних файлов после деинсталляции порта.
 	</para>
       </listitem>
 
       <listitem>
 	<para><literal>-distfiles</literal> - Собрать архивы исходных файлов
 	  (<literal>distfiles</literal>) для дальнейшего их переноса на
 	  <hostid>ftp-master</hostid>.  Эту опцию следует использовать изредка,
 	  поскольку она требует очень много места.  Исходные архивы следует
 	  удалить после загрузки их на <hostid>ftp-master</hostid>.
 	</para>
       </listitem>
 
       <listitem>
 	<para><literal>-fetch-original</literal> - Загружать исходные архивы
 	  с оригинальных сайтов, определенных переменными
 	  <literal>MASTER_SITES</literal>, а не с <hostid>ftp-master</hostid>.
 	</para>
       </listitem>
     </itemizedlist>
 
     <para>Убедитесь, что процесс сборки пакетов для архитектуры
       <replaceable>${arch}</replaceable> запускается от имени пользователя
       ports-<replaceable>${arch}</replaceable>; в противном случае ошибки
       неизбежны.
     </para>
 
     <note><para>Сборка пакетов производится в два идентичных прохода.  Иногда
       временные проблемы, такие как ошибки NFS или недоступность FTP-сайтов,
       могут прервать сборку.  Дублирование попыток позволяет обойти подобные
       проблемы.
     </para></note>
 
     <para>Проверьте, чтобы <filename>ports/Makefile</filename>
       не ссылался на пустые подкаталоги.  В особенности это важно для сборки
       ветви 4-exp.  Если процесс сборки обнаруживает пустой каталог, обе
       фазы сборки вскоре остановятся.  При этом в файлы
       <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/make.[0|1]</filename>
       будет записано сообщение об ошибке примерно такого вида:
     </para>
 
     <screen><literal>don't know how to make dns-all(continuing)</literal></screen>
 
     <para>Для исправления ситуации просто закомментируйте или удалите строчки
       <literal>SUBDIR</literal>, указывающие на пустые подкаталоги.
       После этого вы можете перезапустить сборку командой
       <command>dopackages</command>, добавив ей параметр
       <literal>-restart</literal>.
     </para>
   </sect1>
 
   <sect1 id="anatomy">
     <title>Процесс сборки</title>
 
     <para>Полный процесс сборки без каких-либо ключей, начинающихся с
       <literal>-no</literal>, выполняет следующую последовательность
       операций:</para>
 
     <orderedlist>
       <listitem>
 	<para>Извлечение из CVS-репозитория текущего дерева
 	  <literal>ports</literal> [*]
 	</para>
       </listitem>
 
       <listitem>
 	<para>Извлечение из CVS-репозитория текущего дерева
 	  <literal>doc</literal> [*]
 	</para>
       </listitem>
 
       <listitem>
 	<para>Извлечение из CVS-репозитория дерева
 	  <literal>src</literal> необходимой ветви [*]
 	</para>
       </listitem>
 
       <listitem>
 	<para>Проверка файлов <filename>Makefile</filename> на отсутствие
 	  строк <literal>SUBDIR</literal> [*]
 	</para>
       </listitem>
 
       <listitem>
 	<para>Создание файла <filename>duds</filename>, содержащего список
 	  портов, которые не надо пытаться собирать [*] [+]
 	</para>
       </listitem>
 
       <listitem>
 	<para>Генерация нового файла <filename>INDEX</filename> [*] [+]
 	</para>
       </listitem>
 
       <listitem>
 	<para>Начальная подготовка узлов, которые будут участвовать в сборке
 	  [*] [+]
 	</para>
       </listitem>
 
       <listitem>
 	<para>Построение списка портов ограниченного распространения
 	  (restricted) [*] [+]</para>
       </listitem>
 
       <listitem>
 	<para>Сборка пакетов (фаза 1) [++]</para>
       </listitem>
 
       <listitem>
 	<para>Повторная установка узлов сборки [+]</para>
       </listitem>
 
       <listitem>
 	<para>Сборка пакетов (фаза 2) [++]</para>
       </listitem>
     </orderedlist>
 
     <para>[*] Результаты выполнения этих шагов записываются в файл
       <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/build.log</filename>,
       а также в стандартный вывод для ошибок консоли, с которой запускался скрипт
       <command>dopackages</command>.</para>
 
     <para>[+] При неудачном завершении любого из этих шагов процесс
       прекращается.</para>
 
     <para>[++] Результаты выполнения пишутся в файл
       <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/make.[0|1]</filename>,
       где <filename>make.0</filename> соответствует первой, а
       <filename>make.1</filename> второй фазе сборки.  Журналы сборки отдельных
       портов записываются в файлы
       <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/logs</filename>,
       а журналы портов, собравшихся неудачно, в
       <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/errors</filename>.
     </para>
   </sect1>
 
   <sect1 id="interrupting">
     <title>Прерывание процесса сборки</title>
 
     <para>Для прерывания процесса сборки обычно достаточно послать сигнал
       <literal>HUP</literal> процессам <command>dopackages*</command>
       или вызванным ими процессам <command>make</command>.  Процессы,
       запущенные на узлах сборки, завершатся самостоятельно в течение
       нескольких минут (их наличие следует проверять командой
       <command>ps x</command>).  Обычно достаточно следующей команды:</para>
 
     <screen>&prompt.user; <userinput>killall -HUP sh ssh make</userinput></screen>
 
     <para>Удалите файл
       <filename><replaceable>${arch}</replaceable>/lock</filename>
       перед тем, как перезапустите сборку.
     </para>
   </sect1>
 
   <sect1 id="monitoring">
     <title>Слежение за процессом</title>
 
     <para>Команда
       <command>scripts/stats <replaceable>${branch}</replaceable></command>
       показывает количество собранных на настоящий момент пакетов.</para>
 
     <para>Команда <command>cat /var/portbuild/*/loads/*</command>
       покажет текущую загрузку клиентских машин и количество процессов сборки,
       запущенных на них.</para>
 
     <para>Выполнение
       <command>tail -f <replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/build.log</command>
       продемонстрирует общее состояние процесса сборки.</para>
 
     <para>В случае, если порт не собирается, и из логов не понятны причины
       этого, вы можете сохранить рабочий каталог сборки
       (<literal>WRKDIR</literal>) для последующего анализа.
       Для этого создайте файл <filename>.keep</filename> в каталоге порта.
       При следующей сборке порта кластером архив <literal>WRKDIR</literal>
       будет помещен в файл
       <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/wrkdirs</filename>.
     </para>
 
     <para>Следите за выводом команды &man.df.1;.  Если файловая система,
       содержащая <filename>/var/portbuild</filename>, переполнится, будет
       <trademark>Очень Плохо</trademark>.
     </para>
   </sect1>
 
   <sect1 id="release">
     <title>Сборка пакетов для релизов</title>
 
     <para>При сборке пакетов для включения в релиз может потребоваться ручное
       обновление иерархий <literal>ports</literal> и <literal>src</literal>
       до нужного тэга, а также использование опций <literal>-nocvs</literal>
       и <literal>-noportscvs</literal>.</para>
 
     <para>Для подготовки комплекта пакетов для помещения на CD-ROM используйте
       параметр <literal>-cdrom</literal> при запуске
       <command>dopackages</command>.</para>
 
     <para>Если на кластере достаточно дискового пространства, можно применить
       ключ <literal>-distfiles</literal> для выкачивания дистрибутивных
       архивов.</para>
 
     <note><para>Первая сборка должна быть произведена с параметром
       <literal>-distfiles</literal>.</para></note>
 
     <para>По завершении первого процесса сборки перезапустите его с параметрами
       <literal>-restart -distfiles -fetch-original</literal>,
       для того чтобы выкачать обновленные дистрибутивы.
       Затем, на этапе финальной обработки, соберите список файлов при помощи
       команды</para>
 
     <screen>&prompt.user; <userinput>cd <replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable></userinput>
 &prompt.user; <userinput>find distfiles > distfiles-<replaceable>${release}</replaceable></userinput></screen>
 
     <para>Этот файл обычно копируют в каталог
       <filename>i386/<replaceable>${branch}</replaceable></filename>
       главной машины кластера.</para>
 
     <para>Данная процедура помогает чистить комплект дистрибутивных архивов,
       располагающийся на <hostid>ftp-master</hostid>.  Если дисковое
       пространство заканчивается, можно сохранить архивы для свежих релизов,
       а прочие&nbsp;&mdash; удалить.</para>
 
     <para>После копирования дистрибутивов (см. ниже) надо создать окончательный
       комплект пакетов для релиза.  Для полного спокойствия, запустите скрипт
       <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/cdrom.sh</filename>
       вручную, чтобы быть уверенным, что все пакеты ограниченного
       распространения и их исходные архивы удалены.  Затем скопируйте каталог
       <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/packages</filename>
       в
       <filename><replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable>/packages-<replaceable>${release}</replaceable></filename>.
       После того, как пакеты переложены в надежное место, свяжитесь с группой
       &a.re; и сообщите им расположение финального комплекта пакетов.</para>
 
     <para>Помните о необходимости координации с группой &a.re; по поводу
       времени и статуса сборки пакетов для релизов.
     </para>
   </sect1>
 
   <sect1 id="uploading">
     <title>Загрузка пакетов для раздачи</title>
 
     <para>После завершения сборки пакеты и/или их исходные архивы
       могут быть загружены на <hostid>ftp-master</hostid> для
       раздачи по сети зеркал FTP.  Если сборка велась с ключом
       <literal>-nofinish</literal>, не забудьте произвести пост-обработку
       при помощи команды <command>dopackages -finish</command> (будут удалены
       пакеты, помеченные как <literal>RESTRICTED</literal> и
       <literal>NO_CDROM</literal>, а также пакеты, отсутствующие в файле
       <filename>INDEX</filename>, из файла <filename>INDEX</filename> будут
       удалены ссылки на не собравшиеся пакеты, и, наконец, будет создан файл
       <filename>CHECKSUM.MD5</filename> с контрольными суммами собранных
       пакетов; кроме того, эта фаза переместит исходные архивы из каталога
       <filename>distfiles/.pbtmp</filename> в <filename>distfiles/</filename>,
       а также удалит исходные архивы для портов, помеченных как
       <literal>RESTRICTED</literal> и <literal>NO_CDROM</literal>).</para>
 
     <para>Хорошей идеей является запустить вручную скрипты
       <command>restricted.sh</command> и/или
       <command>cdrom.sh</command> после завершения работы
       <command>dopackages</command> просто для собственного спокойствия.
       Скрипт <command>restricted.sh</command> запускается перед копированием
       на <hostid>ftp-master</hostid>; затем, перед подготовкой финального
       набора пакетов для релиза выполните <command>cdrom.sh</command>.
     </para>
 
     <para>Пакеты можно копировать во временную область на
       <hostid>ftp-master</hostid> примерно такой командой:</para>
 
     <screen>&prompt.root; <userinput>cd /var/portbuild/<replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable></userinput>
 &prompt.root; <userinput>tar cfv - packages/ | ssh portmgr@ftp-master tar xfC - w/ports/<replaceable>${arch}</replaceable>/tmp/<replaceable>${branch}</replaceable></userinput></screen>
 
     <para>Затем, на машине <hostid>ftp-master</hostid>, убедитесь, что набор
       пакетов скопирован корректно, удалите старый набор (из каталога
       <filename>~/w/ports/<replaceable>${arch}</replaceable></filename>),
       и переместите новый на его место.</para>
 
     <note><para>Некоторые каталоги на <hostid>ftp-master</hostid> на самом деле
       являются символьными ссылками.  Убедитесь, что вы перемещаете новый набор
       пакетов в <emphasis>реальный</emphasis> каталог, а не на место
       расположения одной из ссылок.</para></note>
 
     <para>Дистрибутивные архивы копируются при помощи команды
       <command>rsync</command>:</para>
 
     <screen>&prompt.root; <userinput>cd /var/portbuild/<replaceable>${arch}</replaceable>/<replaceable>${branch}</replaceable></userinput>
 &prompt.root; <userinput>rsync -r -v -l -p -c -n distfiles/ portmgr@ftp-master:w/ports/distfiles/ | tee log</userinput></screen>
 
     <para><emphasis>ВСЕГДА</emphasis> для начала используйте ключ
       <literal>-n</literal> команды <command>rsync</command> и проверяйте
       ее вывод.  Если все выглядит нормально, перезапустите
       <command>rsync</command> без опции <literal>-n</literal>.
     </para>
   </sect1>
 
   <sect1 id="expbuilds">
     <title>Экспериментальная сборка</title>
 
     <para>Время от времени для тестирования новых возможностей или
       исправлений общей инфраструктуры портов (<literal>bsd.port.mk</literal>),
       а также для тестирования крупных обновлений, затрагивающих существенную
       часть пакетов, проводится сборка с экспериментальными патчами. Текущей
       экспериментальной веткой является <literal>4-exp</literal> в архитектуре
       &i386;.</para>
 
     <para>В целом, экспериментальная сборка производится так же, как и обычная.
       Основное отличие: перед запуском скрипта <literal>dopackages</literal>
       нужно применить к дереву портов необходимые изменения.
       Хорошей идеей будет сохранить копии всех изменяемых файлов, а также их
       список.  К списку вы сможете вернуться перед произведением окончательного
       коммита.</para>
 
     <para>Для создания <quote>контрольного экземпляра</quote> для сравнения
       следует сначала произвести сборку той ветви архитектуры &i386;, на которой
       основана экспериментальная ветвь (в настоящее время это ветвь
       <literal>4</literal>).  Перед экспериментальной сборкой выгрузите
       деревья src и ports на момент произведения контрольной сборки.
       В этом случае вы можете быть уверены, что сравниваете яблоки с яблоками.
     </para>
 
     <note><para>Два кластера сборки могут производить контрольную и
       экспериментальную сборку одновременно.  Это может ощутимо сэкономить
       общее время сборки.</para></note>
 
     <para>По завершении сборки сравните результаты контрольной и
       экспериментальной сборок примерно такой командой (предполагается, что
       контрольной является ветка <literal>4</literal>, а
       экспериментальной&nbsp;&mdash; <literal>4-exp</literal>):</para>
 
     <screen>&prompt.user; <userinput>cd /var/portbuild/i386/4-exp/errors</userinput>
 &prompt.user; <userinput>find . -name \*.log\* | sort > /tmp/4-exp-errs</userinput>
 &prompt.user; <userinput>cd /var/portbuild/i386/4/errors</userinput>
 &prompt.user; <userinput>find . -name \*.log\* | sort > /tmp/4-errs</userinput></screen>
 
     <note><para>Если с момента завершения одной из сборок прошло достаточно
       много времени, журналы сборки могут быть автоматически архивированы
       bzip2.  В этом случае используйте
       <literal>sort | sed 's,\.bz2,,g'</literal>.</para></note>
 
     <screen>&prompt.user; <userinput>comm -3 /tmp/4-errs /tmp/4-exp-errs | less</userinput></screen>
 
     <para>Результатом работы последней команды будет отчет, состоящий из двух
       столбцов.  В первой колонке будут перечислены порты, сборка которых не
       удалась в контрольном, но не в экспериментальном случае; второй столбец
       описывает противоположную ситуацию.  Причины, по которым порт может
       оказаться в первом списке, включают:</para>
 
     <itemizedlist>
       <listitem>
 	<para>Порт был исправлен с момента последнего контрольного запуска,
 	  или обновлен до более свежей версии, которая также не собирается
 	  (порт с новой версией появится во втором столбце)
 	</para>
       </listitem>
 
       <listitem>
 	<para>Сборка порта исправлена патчами экспериментальной версии</para>
       </listitem>
 
       <listitem>
 	<para>Порт не собирается экспериментальной сборкой из-за ошибок в
 	  зависимых портах
 	</para>
       </listitem>
     </itemizedlist>
 
     <para>Во втором столбце порт может оказаться по следующим причинам:</para>
 
     <itemizedlist>
       <listitem>
 	<para>Порт не собирается с экспериментальными изменениями [1]</para>
       </listitem>
 
       <listitem>
 	<para>Порт был обновлен с момента контрольной сборки и стал
 	  несобираемым [2]
 	</para>
       </listitem>
 
       <listitem>
 	<para>Порт не собрался по причине временных ошибок (недоступный FTP
 	  сайт, ошибка ввода-вывода на клиенте и т.п.)
 	</para>
       </listitem>
     </itemizedlist>
 
     <para>Перед коммитом экспериментальных обновлений необходимо изучить
       содержимое обоих столбцов.  Чтобы отличить ситуации [1] и [2], можно
       пересобрать соответствующие пакеты в контрольной ветке:</para>
 
     <screen>&prompt.user; <userinput>cd /var/portbuild/i386/4/ports</userinput></screen>
 
     <note><para>Не забудьте обновить дерево портов до той же даты, что и дерево
       экспериментальной сборки.</para></note>
 
     <para>Для подготовки контрольной ветви используйте команду:</para>
 
     <screen>&prompt.user; <userinput>/var/portbuild/scripts/dopackages.4 -noportscvs -nobuild -nocvs -nofinish</userinput></screen>
 
     <para>Сборка должна производиться из каталога
       <literal>packages/All</literal>.  Изначально этот каталог должен быть
       пуст, за исключением символьной ссылки Makefile.  Если этой ссылки нет,
       создайте ее:</para>
 
     <screen>&prompt.user; <userinput>cd /var/portbuild/i386/4/packages/All</userinput>
 &prompt.user; <userinput>ln -sf ../../Makefile .</userinput>
 &prompt.user; <userinput>make -k -j&lt;#&gt; &lt;список пакетов для сборки&gt;</userinput></screen>
 
     <note><para>&lt;#&gt; описывает уровень параллелизма сборки.  
       Обычно, это сумма весов клиентских машин, указанных в
       <filename>/var/portbuild/i386/mlist</filename>, если у вас нет причин
       проводить более тяжелую или, наоборот, облегченную сборку.</para>
 
     <para>&lt;список пакетов для сборки&gt; представляет собой список имен
       пакетов (включая их версии) в том виде, как они представлены в файле
       <filename>INDEX</filename>.  Суффикс <literal>PKGSUFFIX</literal>
       (.tgz or .tbz) является необязательным.</para></note>
 
     <para>Будут собраны только указанные пакеты, а также их зависимые порты.
       Процесс сборки можно контролировать так же, как и стандартную сборку.
       После того, как все ошибки исправлены, вы можете произвести коммит
       комплекта исправлений. Является хорошим тоном отправить письмо
       с темой <literal>HEADS UP</literal> в списки рассылки <ulink
       url="mailto:ports@FreeBSD.org">ports@FreeBSD.org</ulink> и <ulink
       url="mailto:ports-developers@FreeBSD.org">ports-developers@FreeBSD.org</ulink>
       с информацией о внесенных изменениях.  Краткая аннотация изменений также
       должна быть добавлена в файл <filename>/usr/ports/CHANGES</filename>.
     </para>
   </sect1>
 </article>