doc/documentation/content/ru/books/handbook/cutting-edge/_index.adoc
Li-Wen Hsu a9a9e66105
Use correct syntax markup for shell
Approved by:	carlavilla
2021-03-14 20:08:55 +08:00

1056 lines
111 KiB
Text
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
title: Глава 21. Обновление системы и смена версии FreeBSD
part: Часть III. Системное администрирование
prev: books/handbook/l10n
next: books/handbook/partiv
---
[[updating-upgrading]]
= Обновление системы и смена версии FreeBSD
:doctype: book
:toc: macro
:toclevels: 1
:icons: font
:sectnums:
:sectnumlevels: 6
:source-highlighter: rouge
:experimental:
:skip-front-matter:
:toc-title: Содержание
:table-caption: Таблица
:figure-caption: Рисунок
:example-caption: Пример
:xrefstyle: basic
:relfileprefix: ../
:outfilesuffix:
:sectnumoffset: 21
ifeval::["{backend}" == "html5"]
:imagesdir: ../../../images/books/handbook/cutting-edge/
endif::[]
ifeval::["{backend}" == "pdf"]
:imagesdir: ../../../../static/images/books/handbook/cutting-edge/
endif::[]
ifeval::["{backend}" == "epub3"]
:imagesdir: ../../../../static/images/books/handbook/cutting-edge/
endif::[]
include::shared/authors.adoc[]
include::shared/releases.adoc[]
include::shared/ru/mailing-lists.adoc[]
include::shared/ru/teams.adoc[]
include::shared/ru/urls.adoc[]
toc::[]
[[updating-upgrading-synopsis]]
== Краткий обзор
Между релизами над FreeBSD ведется постоянная работа. Некоторые отдают предпочтение официально выпущенным версиям, в то время как остальные предпочитают использовать последние разработки. Тем не менее, даже для официальных версий часто выходят обновления, связанные с безопасностью и другими критическими исправлениями. Независимо от используемой версии FreeBSD предоставляет все необходимые инструменты для поддержания системы в актуальном состоянии, а также позволяет легко перейти на другую версию. Эта глава описывает, как отслеживать систему в процессе её разработки, а также основные инструменты для поддержания системы FreeBSD в актуальном состоянии.
После чтения этой главы вы будете знать:
* Как поддерживать систему FreeBSD в актуальном состоянии при помощи freebsd-update, Subversion или CTM.
* Как узнать состояние установленной системы по отношению к известной нетронутой копии.
* Как поддерживать установленную документацию в актуальном состоянии при помощи Subversion или портов документации.
* Разницу между двумя ветвями разработки: FreeBSD-STABLE и FreeBSD-CURRENT.
* Как перестраивать и переустанавливать всю базовую систему.
Перед чтением этой главы вы должны:
* Правильно настроить сетевое подключение (crossref:advanced-networking[advanced-networking, Сложные вопросы работы в сети]).
* Знать, как устанавливать дополнительное стороннее программное обеспечение (crossref:ports[ports, Установка приложений. порты и пакеты]).
[NOTE]
====
В этой главе для получения и обновления исходных текстов FreeBSD используется команда `svn`. Для этого нужно сперва установить порт или пакет package:devel/subversion[].
====
[[updating-upgrading-freebsdupdate]]
== Обновление FreeBSD
Своевременное применение обновлений безопасности и переход на более новую версию операционной системы - важные аспекты системного администрирования. FreeBSD включает в себя программу `freebsd-update`, которую можно использовать для решения обеих задач.
Эта программа используется для установки распространяемых в двоичном виде обновлений безопасности и исправлений для FreeBSD без необходимости ручной компиляции и установки патчей или нового ядра. Двоичные обновления доступны для всех архитектур и версий, поддерживаемых группой безопасности. Перечень поддерживаемых версий и их ожидаемые даты окончания поддержки указаны на странице http://www.FreeBSD.org/security/[http://www.FreeBSD.org/security/].
Эта программа также используется для незначительных обновлений версии операционной системы, а также для перехода на другую ветвь выпуска релизов. Перед обновлением следует ознакомиться с объявлением о выпуске новой версии, так как там может содержаться важная информация, применимая к версии, на которую намечен переход. С соответствующими объявлениями можно ознакомиться по ссылке http://www.FreeBSD.org/releases/[http://www.FreeBSD.org/releases/].
[NOTE]
====
Если имеется задание `crontab`, запускающее man:freebsd-update[8], то перед сменой версии операционной системы его обязательно нужно выключить.
====
В этом разделе описывается конфигурационный файл `freebsd-update`, демонстрируется применение исправлений безопасности и обновление операционной системы со сменой младшей или старшей версии, а также обсуждаются некоторые соображения касаемо смены версии операционной системы.
[[freebsdupdate-config-file]]
=== Конфигурационный файл
Конфигурационный файл `freebsd-update` самодостаточен и работает по умолчанию. Некоторые пользователи могут пожелать отредактировать конфигурационный файл [.filename]#/etc/freebsd-update.conf# для лучшего контроля над процессом обновления. В комментариях описываются доступные в этом файле параметры, но для следующих из них может потребоваться дополнительное разъяснение:
[.programlisting]
....
# Components of the base system which should be kept updated.
Components world kernel
....
Данный параметр определяет, какие части FreeBSD будут обновлены. По умолчанию обновляется вся базовая система (world) и ядро (kernel). Вместо этого можно указать отдельные компоненты, такие как `src/base` или `src/sys`. Тем не менее, лучшим вариантом будет оставить всё как есть, поскольку изменение этого перечня с целью добавления особых пунктов потребует от пользователя указания подряд всех пунктов. Со временем это может привести к негативным последствиям из-за возможной рассинхронизации между исходными текстами и двоичными файлами.
[.programlisting]
....
# Paths which start with anything matching an entry in an IgnorePaths
# statement will be ignored.
IgnorePaths /boot/kernel/linker.hints
....
Добавьте сюда пути к каталогам (например, [.filename]#/bin# или [.filename]#/sbin#), которые вы бы хотели оставить нетронутыми в процессе обновления. Этот параметр можно использовать для предотвращения перезаписывания локальных изменений программой `freebsd-update`.
[.programlisting]
....
# Paths which start with anything matching an entry in an UpdateIfUnmodified
# statement will only be updated if the contents of the file have not been
# modified by the user (unless changes are merged; see below).
UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile
....
Этот параметр позволяет обновлять конфигурационные файлы в указанных каталогах, только если они не содержат изменений. При наличии каких-либо изменений со стороны пользователя автоматическое обновление таких файлов отменяется. Есть другой параметр `KeepModifiedMetadata`, который предписывает команде `freebsd-update` сохранять изменения в процессе слияния.
[.programlisting]
....
# When upgrading to a new FreeBSD release, files which match MergeChanges
# will have any local changes merged into the version from the new release.
MergeChanges /etc/ /var/named/etc/ /boot/device.hints
....
Список каталогов с конфигурационными файлами, для которых `freebsd-update` попытается выполнить слияние. Процесс слияния файла представляет собой последовательность изменений в формате man:diff[1], похожую на man:mergemaster[8], но с меньшим количеством параметров. Результат слияния принимается, открывается редактор или `freebsd-update` прекращает работу. В случае сомнений сделайте резервную копию [.filename]#/etc# и просто согласитесь со всеми изменениями. Для получения подробной информации по команде `mergemaster` смотрите <<mergemaster>>.
[.programlisting]
....
# Directory in which to store downloaded updates and temporary
# files used by FreeBSD Update.
# WorkDir /var/db/freebsd-update
....
Этот каталог предназначен для размещения патчей и временных файлов. В случае, когда пользователь выполняет обновление со сменой версии, в этом месте нужно иметь по крайней мере гигабайт свободного дискового пространства.
[.programlisting]
....
# When upgrading between releases, should the list of Components be
# read strictly (StrictComponents yes) or merely as a list of components
# which *might* be installed of which FreeBSD Update should figure out
# which actually are installed and upgrade those (StrictComponents no)?
# StrictComponents no
....
Если выставлено значение `yes`, то `freebsd-update` будет исходить из того, что список `Components` является полным, и не будет пытаться выполнить изменения за пределами этого списка. В действительности `freebsd-update` попытается обновить все файлы, которые принадлежат списку `Components`.
[[freebsdupdate-security-patches]]
=== Обновления безопасности
Процесс применения обновлений безопасности FreeBSD был упрощён, что позволяет поддерживать систему в актуальном состоянии, используя `freebsd-update`. Для получения дополнительной информации по бюллетеням безопасности FreeBSD смотрите crossref:security[security-advisories,Сообщения безопасности FreeBSD].
Обновления безопасности можно загрузить и установить с использованием следующих команд. Первая команда определяет наличие незагруженных обновлений и показывает файлы, которые будут изменены в процессе обновления. Вторая команда выполняет обновление.
[source,shell]
....
# freebsd-update fetch
# freebsd-update install
....
Если были установлены обновления ядра, то после этого нужно перезагрузить систему. Если обновление установилось для какого-либо работающего в системе двоичного файла, то следует перезапустить затронутые приложения, чтобы использовалась исправленная версия двоичного файла.
Можно настроить ежедневную автоматическую проверку наличия обновлений, добавив следующую запись в [.filename]#/etc/crontab#:
[.programlisting]
....
@daily root freebsd-update cron
....
При наличии обновлений они будут автоматически загружены. Пользователю `root` будет отправлено письмо, так что эти обновления можно будет просмотреть и установить самостоятельно командой `freebsd-update install`.
На случай, если что-то пошло не так, в `freebsd-update` предусмотрен механизм возврата последнего набора изменений с использованием следующей команды:
[source,shell]
....
# freebsd-update rollback
Uninstalling updates... done.
....
Если после завершения всех действий было изменено ядро или какой-либо из его модулей, система должна быть перезагружена, а все затронутые исполняемые файлы нужно перезапустить.
Команда `freebsd-update` позволяет автоматически обновлять только ядро [.filename]#GENERIC#. Если используется ядро с собственной конфигурацией, его понадобится пересобрать и переустановить после того, как `freebsd-update` завершит установку обновлений. Тем не менее, `freebsd-update` обнаружит и обновит ядро [.filename]#GENERIC# при наличии [.filename]#/boot/GENERIC#, даже если оно не является текущим используемым ядром в системе.
[NOTE]
====
Всегда храните копию ядра [.filename]#GENERIC# в [.filename]#/boot/GENERIC#. Оно пригодится при решении различных проблем, а также при выполнении обновления со сменой версии. Смотрите <<freebsd-update-custom-kernel-9x>> для описания получения копии ядра [.filename]#GENERIC#.
====
Если конфигурация в [.filename]#/etc/freebsd-update.conf# не изменялась, `freebsd-update` вместе с остальными обновлениями установит обновлённые исходные тексты ядра. После этого можно обычным способом выполнить перестроение и переустановку нового ядра с собственной конфигурацией.
Обновления, получаемые с помощью `freebsd-update`, не всегда затрагивают ядро. Перестроение собственного ядра не является обязательным, если исходные тексты ядра не были изменены при выполнении `freebsd-update install`. Тем не менее, `freebsd-update` всегда обновляет [.filename]#/usr/src/sys/conf/newvers.sh#. Текущий набор изменений, как указано в номере `-p` в выводе `uname -r`, получается из этого файла. Перестроение собственного ядра, даже если ничего больше не менялось, позволяет `uname` правильно сообщать текущий набор изменений в системе. Это в частности может помочь при сопровождении множества систем, поскольку позволяет быстро оценить наличие установленных обновлений в каждой из них.
[[freebsdupdate-upgrade]]
=== Обновления со сменой старшей и младшей версий
Обновление с FreeBSD 9.0 на FreeBSD 9.1, называется обновлением со сменой младшего номера версии. Смена старшего номера версии происходит, когда FreeBSD переходит с одной значительной версии на другую, как, например, при обновлении с FreeBSD 9.X на FreeBSD 10.X. Оба типа обновлений можно произвести, указав `freebsd-update` версию, на которую нужно перейти.
[NOTE]
====
Если в системе используется ядро с собственной конфигурацией, убедитесь перед началом обновления в наличии копии ядра [.filename]#GENERIC# в [.filename]#/boot/GENERIC#. Смотрите <<freebsd-update-custom-kernel-9x>> для описания получения копии ядра [.filename]#GENERIC#.
====
Следующая команда, будучи запущенной на FreeBSD 9.0, выполнит обновление до версии FreeBSD 9.1:
[source,shell]
....
# freebsd-update -r 9.1-RELEASE upgrade
....
После своего запуска `freebsd-update` анализирует содержимое конфигурационного файла и собирает необходимую для проведения обновления информацию о текущей установленной системе. На экран будет выдан перечень компонентов, которые удалось и не удалось обнаружить установленными. Например:
[source,shell]
....
Looking up update.FreeBSD.org mirrors... 1 mirrors found.
Fetching metadata signature for 9.0-RELEASE from update1.FreeBSD.org... done.
Fetching metadata index... done.
Inspecting system... done.
The following components of FreeBSD seem to be installed:
kernel/smp src/base src/bin src/contrib src/crypto src/etc src/games
src/gnu src/include src/krb5 src/lib src/libexec src/release src/rescue
src/sbin src/secure src/share src/sys src/tools src/ubin src/usbin
world/base world/info world/lib32 world/manpages
The following components of FreeBSD do not seem to be installed:
kernel/generic world/catpages world/dict world/doc world/games
world/proflibs
Does this look reasonable (y/n)? y
....
Следующим шагом `freebsd-update` попытается загрузить по сети файлы, необходимые для выполнения обновления. В некоторых случаях может потребоваться ответить на вопросы относительно того, что и как устанавливать.
Если используется ядро с собственной конфигурацией, то в этом случае появится предупреждение следующего вида:
[source,shell]
....
WARNING: This system is running a "MYKERNEL" kernel, which is not a
kernel configuration distributed as part of FreeBSD 9.0-RELEASE.
This kernel will not be updated: you MUST update the kernel manually
before running "/usr/sbin/freebsd-update install"
....
На этом этапе предупреждение можно проигнорировать. На промежуточном этапе процесса обновления будет использовано обновлённое ядро [.filename]#GENERIC#.
После того, как все изменения были загружены, они будут применены. Этот процесс может занять определённое время, в зависимости от производительности и текущей загруженности компьютера. Затем будет выполнено слияние конфигурационных файлов. Процесс слияния требует от пользователя определённого вмешательства, так как для файла можно выполнить слияние автоматически, а можно открыть текстовый редактор для слияния вручную. Результат успешного слияния будет показан на экране. Неудачное или пропущенное слияние вызовет преждевременное завершение программы. Можно подготовить резервную копию каталога [.filename]#/etc# для таких важных файлов как [.filename]#master.passwd# и [.filename]#group# и выполнить их слияние вручную позднее.
[NOTE]
====
На данном этапе система еще не модифицирована, и все изменения и слияния происходят в отдельном каталоге. Теперь, когда все изменения успешно применены, все конфигурационные файлы объединены и кажется, что процесс должен пройти плавно, изменения могут быть установлены на диск с помощью следующей команды:
[source,shell]
....
# freebsd-update install
....
====
В первую очередь изменения будут применены к ядру и его модулям. При использовании ядра с собственной конфигурацией укажите для следующей загрузки обновлённое ядро [.filename]#/boot/GENERIC# с помощью man:nextboot[8]:
[source,shell]
....
# nextboot -k GENERIC
....
[WARNING]
====
Перед перезагрузкой с ядром [.filename]#GENERIC# убедитесь, что оно содержит все необходимые драйвера для системы для корректной загрузки и подключения к сети, если машина обновляется удалённо. В частности, если в ядре содержится встроенная функциональность, которая обычно обеспечивается модулями ядра, загрузите эти драйвера с ядром [.filename]#GENERIC#, временно указав их как модули в [.filename]#/boot/loader.conf#. Рекомендуется отключить несущественные службы, а также любые локальные и сетевые диски до завершения процесса обновления.
====
Теперь компьютер должен быть перезагружен с новым ядром:
[source,shell]
....
# shutdown -r now
....
После перезагрузки нужно повторно запустить команду `freebsd-update`. Команда прочитает, на каком этапе она находится, и перейдёт к удалению старых объектных файлов и совместно используемых библиотек.
[source,shell]
....
# freebsd-update install
....
[NOTE]
====
Количество этапов установки обновлений может быть два вместо трёх и зависит от того, были ли изменены номера версий каких-либо совместно используемых библиотек.
====
На этом процесс завершён. Если было выполнено обновление со сменой старшего номера версии, переустановите все порты и пакеты в соответствии с описанием, которое предоставляет <<freebsdupdate-portsrebuild>>.
[[freebsd-update-custom-kernel-9x]]
==== Собственная конфигурация ядра в FreeBSD 9.X и более поздних версиях
Перед использованием `freebsd-update` убедитесь в наличии копии ядра [.filename]#GENERIC# в [.filename]#/boot/GENERIC#. Если ядро с собственной конфигурацией было собрано единожды, то в [.filename]#/boot/kernel.old# будет находиться ядро `GENERIC`. Просто переименуйте этот каталог в [.filename]#/boot/kernel#.
Если ядро с собственной конфигурацией было собрано более одного раза, получите копию ядра `GENERIC`, соответствующую текущей версии операционной системы. При наличии физического доступа копию ядра `GENERIC` можно установить с установочного носителя:
[source,shell]
....
# mount /cdrom
# cd /cdrom/usr/freebsd-dist
# tar -C/ -xvf kernel.txz boot/kernel/kernel
....
Иначе, ядро `GENERIC` можно собрать и установить из исходных текстов:
[source,shell]
....
# cd /usr/src
# make kernel __MAKE_CONF=/dev/null SRCCONF=/dev/null
....
Чтобы такое ядро было определено как ядро `GENERIC` программой `freebsd-update`, в файле конфигурации [.filename]#GENERIC# должны отсутствовать изменения. Также предлагается, что ядро было собрано без использования каких-либо специальных параметров.
Загрузка с [.filename]#GENERIC# не требуется, поскольку для `freebsd-update` достаточно существования [.filename]#/boot/GENERIC#.
[[freebsdupdate-portsrebuild]]
==== Обновление пакетов после смены старшей версии системы
После обновления системы со сменой младшей версии установленные приложения, в целом, продолжают работать без каких-либо проблем. Различные старшие версии используют различающиеся двоичные интерфейсы приложений (Application Binary Interface, ABI), из-за чего перестаёт работать большинство сторонних приложений. После обновления системы со сменой старшей версии все установленные пакеты и порты также нуждаются в обновлении. Пакеты можно обновить с использованием `pkg upgrade`. Для обновления установленных портов используется package:ports-mgmt/portmaster[].
Принудительное обновление все установленных пакетов приведёт к их замене на последние версии из репозитория, даже если номер версии при этом не увеличивался. Это требуется из-за смены версии ABI при обновлении на другую старшую версию FreeBSD. Принудительное обновление можно выполнить так:
[source,shell]
....
# pkg-static upgrade -f
....
Перестроение всех установленных приложений можно выполнить этой командой:
[source,shell]
....
# portmaster -af
....
Эта команда будет отображать экран выбора конфигурации для каждого приложения, в котором доступны параметры конфигурации, с ожиданием пользовательского ввода. Чтобы не использовать такое поведение и всегда выбирать параметры по умолчанию, добавьте ключ `-G` в вышеприведённую команду.
После завершения процесса обновления программного обеспечения закончите процесс обновления последним запуском `freebsd-update`, для того чтобы убедиться, что ничто не было пропущено в процессе обновления:
[source,shell]
....
# freebsd-update install
....
Если в качестве временной меры использовалось ядро [.filename]#GENERIC#, то это подходящее время для построения и установки нового ядра с собственной конфигурацией в соответствии с инструкциями в crossref:kernelconfig[kernelconfig, Настройка ядра FreeBSD].
Перезагрузите машину с новой версией FreeBSD. На этом процесс обновления завершён.
[[freebsdupdate-system-comparison]]
=== Сравнение состояния системы
С помощью команды `freebsd-update IDS` можно получить состояние установленной версии FreeBSD относительно известной доверенной копии. Эта команда проверяет текущую версию системных утилит, библиотек и конфигурационных файлов, и её можно использовать в качестве встроенной системы обнаружения вторжений (Intrusion Detection System, IDS).
[WARNING]
====
Эта команда не является заменой IDS, такой как package:security/snort[]. Поскольку `freebsd-update` сохраняет свои данные на диске, возможность подмены становится очевидной. И хотя эта возможность может быть уменьшена при использовании настройки `kern.securelevel`, а также используя для записи данных `freebsd-update` файловую систему, которая в остальное время смонтирована только на чтение, лучшим решением будет сравнить систему относительно эталона на физически защищенном носителе, таком как DVD или внешний USB диск с включённой защитой от записи.
====
Для того, чтобы начать сравнение, укажите файл для сохранения результатов:
[source,shell]
....
# freebsd-update IDS >> outfile.ids
....
Запустится проверка системы, результат которой будет записан в указанный файл в виде списка файлов вместе с их контрольными суммами в формате SHA256 - для известных файлов из релиза и текущих в системе.
Строки в списке чрезмерно длинные, но зато такой формат вывода удобен для разбора. Так, для получения списка всех отличающихся от релиза файлов достаточно выполнить такую команду:
[source,shell]
....
# cat outfile.ids | awk '{ print $1 }' | more
/etc/master.passwd
/etc/motd
/etc/passwd
/etc/pf.conf
....
Вывод специально обрезан, на самом деле файлов намного больше. Некоторые из них изменены в ходе нормальной работы: так, файл [.filename]#/etc/passwd# был изменён после заведения пользователей в системе. Модули ядра могли измениться вследствие обновления через `freebsd-update`. Для исключения из проверки конкретных файлов и каталогов укажите их в качестве значения параметра `IDSIgnorePaths` в [.filename]#/etc/freebsd-update.conf#.
[[updating-upgrading-documentation]]
== Обновление документации
Документация является неотъемлемой частью операционной системы FreeBSD. И хотя актуальная версия документации FreeBSD всегда доступна на сайте FreeBSD (link:https://www.FreeBSD.org/doc/[http://www.freebsd.org/doc/]), может быть удобно иметь под рукой актуальную локальную копию сайта FreeBSD, руководств, FAQ и статей.
В этом разделе описывается, как использовать исходный текст или Коллекцию Портов FreeBSD для организации актуальной локальной копии документации FreeBSD.
За информацией о редактировании и отправке изменений для документации обращайтесь к FreeBSD Documentation Project Primer for New Contributors (link:{fdp-primer}[FreeBSD Documentation Project Primer]).
[[updating-installed-documentation]]
=== Обновление документации из исходного кода
Для перестроения документации FreeBSD из исходного текста требуется набор инструментов, который не является частью основной системы FreeBSD. Требуемые инструменты, включая svn, можно установить из пакета или порта package:textproc/docproj[], разработанного в рамках проекта документации FreeBSD.
После установки используйте svn для получения копии исходных текстов документации:
[source,shell]
....
# svn checkout https://svn.FreeBSD.org/doc/head /usr/doc
....
Первоначальная загрузка исходных текстов документации может занять некоторое время. Дайте ей завершиться.
Последующие обновления можно получить, выполнив:
[source,shell]
....
# svn update /usr/doc
....
После того как в [.filename]#/usr/doc# была загружена актуальная копия исходных текстов, всё готово для обновления установленной документации.
Полное обновление всех доступных языковых версий можно выполнить, набрав команду:
[source,shell]
....
# cd /usr/doc
# make install clean
....
Для обновления только указанной языковой версии команду `make` можно запустить в соответствующем подкаталоге [.filename]#/usr/doc#:
[source,shell]
....
# cd /usr/doc/en_US.ISO8859-1
# make install clean
....
Альтернативный способ обновления документации заключается в запуске следующей команды из из [.filename]#/usr/doc# или подкаталога с желаемой языковой версией:
[source,shell]
....
# make update
....
Используемый при установке формат можно указать через `FORMATS`:
[source,shell]
....
# cd /usr/doc
# make FORMATS='html html-split' install clean
....
Для упрощения процесса частичного обновления документации и построения только нужных переводов имеется несколько параметров. Их можно задать как на общесистемном уровне, указав в [.filename]#/etc/make.conf#, так и непосредственно в команде `make`.
Данные параметры включают:
`DOC_LANG`::
Перечень языков и кодировок для построения и установки, например, `en_US.ISO8859-1` для англоязычной документации.
`FORMATS`::
Единый формат или набор форматов для построения. На данный момент поддерживаются `html`, `html-split`, `txt`, `ps` и `pdf`.
`DOCDIR`::
Путь для установки документации. По умолчанию [.filename]#/usr/shared/doc#.
Для получения других переменных `make`, также работающих во FreeBSD в качестве общесистемных, обратитесь к man:make.conf[5].
[[doc-ports-install-package]]
=== Обновление документации из портов
В предыдущем разделе был представлен метод обновления документации FreeBSD из исходных текстов. В этом разделе описывается альтернативный метод с использованием Коллекции Портов, который позволяет:
* Установить предварительно собранный пакет документации без необходимости локального построения чего-либо или установки инструментария документации.
* Выполнить построение исходных текстов документации через инфраструктуру портов, что несколько упрощает этапы загрузки и построения.
Данный метод обновления документации FreeBSD предоставляется портами и пакетами документации, которые ежемесячно обновляет {doceng}. Они перечислены в Коллекции Портов FreeBSD в категории docs (http://www.freshports.org/docs/[http://www.freshports.org/docs/]).
Порты документации организованы следующим образом:
* Пакет или порт package:misc/freebsd-doc-en[] устанавливает всю англоязычную документацию.
* Метапакет или порт package:misc/freebsd-doc-all[] устанавливает всю документацию на всех доступных языках.
* Имеются пакеты и порты для каждого перевода, например, package:misc/freebsd-doc-hu[] для венгерской документации.
При использовании двоичных пакетов документация FreeBSD будет установлена во всех доступных форматах для данного языка. Например, следующая команда установит последнюю версию пакета венгерской документации:
[source,shell]
....
# pkg install hu-freebsd-doc
....
[NOTE]
====
Для пакетов используется другая схема наименования, которая отличается от названия соответствующего порта: `_lang_-freebsd-doc`, где _lang_ соответствует сокращённому языковому коду, такому как `hu` для венгерского или `zh_cn` для упрощённого китайского.
====
Чтобы указать используемый формат документации, для этого вместо установки готового пакета нужно собрать порт самостоятельно. Ниже приводится пример построения и установки английской документации:
[source,shell]
....
# cd /usr/ports/misc/freebsd-doc-en
# make install clean
....
В порте имеется меню конфигурации, в котором можно указать нужный формат. По умолчанию выбирается HTML с разделителями, такой как на http://www.FreeBSD.org[http://www.FreeBSD.org], а также PDF.
Иначе, при построении порта документации можно указать параметры `make`, которые включают в себя:
`WITH_HTML`::
Документ в формате HTML на одной странице. Сформированная документация сохраняется в файле [.filename]#article.html# или [.filename]#book.html#.
`WITH_PDF`::
Сформированная документация сохраняется в файле [.filename]#article.pdf# или [.filename]#book.pdf#.
`DOCBASE`::
Указывает место размещения документации. По умолчанию [.filename]#/usr/local/shared/doc/freebsd#.
В примере ниже демонстрируется использование переменных для установки венгерской документации в PDF в указанный каталог:
[source,shell]
....
# cd /usr/ports/misc/freebsd-doc-hu
# make -DWITH_PDF DOCBASE=share/doc/freebsd/hu install clean
....
Пакеты или порты документации обновляются согласно инструкциям в crossref:ports[ports, Установка приложений. порты и пакеты]. Например, следующая команда выполняет обновление установленной документации на венгерском языке с помощью package:ports-mgmt/portmaster[] в режиме использования только готовых пакетов:
[source,shell]
....
# portmaster -PP hu-freebsd-doc
....
[[current-stable]]
== Использование ветви разработки
Во FreeBSD имеется две ветки разработки: FreeBSD-CURRENT и FreeBSD-STABLE.
В этом разделе даётся объяснение для каждой из них и их предназначение, а также рассказывается, как синхронизировать систему с любой из этих веток.
[[current]]
=== Использование FreeBSD-CURRENT
FreeBSD-CURRENT является "передним краем" разработки FreeBSD и предназначена для пользователей с высокой технической грамотностью. Менее продвинутым пользователям, также желающим отслеживать ветку разработки, следует использовать FreeBSD-STABLE.
FreeBSD-CURRENT обозначает последнюю версию исходных текстов FreeBSD и включает в себя незавершённые работы, экспериментальные изменения и переходные механизмы, которые могут отсутствовать в следующем официальном релизе. Хотя многие разработчики FreeBSD выполняют компиляцию исходных текстов FreeBSD-CURRENT ежедневно, бывают периоды, когда исходные тексты могут не компилироваться. Обычно такие проблемы решаются сразу по мере возможности, но всё же выбор точки синхронизации исходных текстов является определяющим фактором, содержит ли FreeBSD-CURRENT новую функциональность или же мину замедленного действия.
FreeBSD-CURRENT предназначена для трёх основных групп:
. Члены сообщества FreeBSD, активно работающие над некоторой частью дерева исходных текстов.
. Члены сообщества FreeBSD, которые являются активными тестерами. Они тратят свое время на исправление проблем, вносят важные предложения по изменениям и общему развитию FreeBSD, присылают патчи.
. Пользователи, которые хотят быть в курсе изменений, используют текущие исходные тексты для ознакомительных целей либо же иногда высказывают замечания или предоставляют собственный код.
FreeBSD-CURRENT _не_ должна использоваться в качестве быстрого способа получить новые возможности, не дожидаясь выпуска следующей версии, поскольку предварительная версия не является полностью проверенной и скорее всего содержит ошибки. FreeBSD-CURRENT не является быстрым способом получения исправлений, поскольку любое изменение является в равной мере источником исправления существующих ошибок и появления новых. FreeBSD-CURRENT не является "официально поддерживаемой" каким бы то ни было способом.
Чтобы отслеживать изменения во FreeBSD-CURRENT:
. Подпишитесь на списки рассылки {freebsd-current} и {svn-src-head}. Это _необходимо_ для того, чтобы получать сообщения и важные бюллетени относительно текущего состояния FreeBSD-CURRENT.
+
Список рассылки {svn-src-head} содержит записи из журнала коммитов по каждому изменению, а также сопутствующую информацию о возможных побочных эффектах.
+
Чтобы подписаться на эти списки рассылки, перейдите по ссылке {mailman-lists-url}, щёлкните на нужном списке и следуйте дальнейшим инструкциям. Для того чтобы отслеживать изменения всего дерева исходных текстов, а не только FreeBSD-CURRENT, подпишитесь на {svn-src-all}.
. Загрузите исходные тексты FreeBSD-CURRENT. Обычно для этого используется crossref:mirrors[svn,svn], с помощью которого можно загрузить исходные тексты -CURRENT из ветки `head` с одного из зеркал Subversion, перечисленных в crossref:mirrors[svn-mirrors,Сайты зеркала Subversion].
+
Пользователи с очень медленным или ограниченным подключением могут рассматривать использование CTM, который описывается в crossref:mirrors[ctm,Использование CTM], однако этот способ является менее надёжным по сравнению с рекомендуемым способом синхронизации исходных текстов посредством svn.
. Вследствие больших размеров репозитория некоторые пользователи для ознакомления или изготовления патчей выбирают частичную загрузку. Тем не менее, для компиляции операционной системы из исходных текстов требуется загрузить FreeBSD-CURRENT _полностью_, а не только лишь выбранные части.
+
Перед началом компиляции FreeBSD-CURRENT внимательно прочтите файл [.filename]#/usr/src/Makefile# и следуйте инструкциям в <<makeworld>>. {freebsd-current} и [.filename]#/usr/src/UPDATING# позволят быть в курсе прочих процедур, которые иногда бывают необходимы в процессе перехода к следующему релизу.
. Будьте активным участником! Пользователям FreeBSD-CURRENT предлагается высказывать свои соображения по улучшению или исправлению ошибок. Предложения, к которым прилагается код, всегда приветствуются!
[[stable]]
=== Использование FreeBSD-STABLE
FreeBSD-STABLE является веткой разработки, из которой выпускаются основные релизы. Изменения в этой ветке происходят с меньшей скоростью и в предположении, что они сперва были проверены во FreeBSD-CURRENT. При этом она _остаётся_ веткой разработки, и в любой момент времени исходные тексты FreeBSD-STABLE могут оказаться не готовы для обычного использования. Это просто другая ветка разработки, не предназначенная для конечных пользователей. Пользователям, у которых нет возможности заниматься тестированием, следует использовать самый последний выпуск FreeBSD.
Тем, кто заинтересован процессом разработки FreeBSD или желает поучаствовать, особенно поскольку от этого зависит следующий релиз FreeBSD, стоит отслеживать FreeBSD-STABLE.
Хотя ветка FreeBSD-STABLE должна всегда компилироваться и работать, это невозможно гарантировать. Поскольку гораздо больше людей работает с FreeBSD-STABLE, неудивительно, что в FreeBSD-STABLE иногда обнаруживаются ошибки и всплывают непредвиденные ситуации, которые не проявляли себя в FreeBSD-CURRENT. По этим причинам не рекомендуется слепо использовать FreeBSD-STABLE. Особенно важно _не_ обновлять какие-либо сервера, находящиеся в эксплуатации, до FreeBSD-STABLE без тщательного тестирования кода в среде разработки.
Чтобы отслеживать изменения во FreeBSD-STABLE:
. Подпишитесь на список рассылки {freebsd-stable}, чтобы быть в курсе о зависимостях процесса компиляции, которые могут появиться во FreeBSD-STABLE или любых других проблемах, требующих особого внимания. Также в этом списке рассылки разработчики делают объявления о спорных исправлениях или добавлениях, давая пользователям возможность высказать свое мнение о возможных тонких моментах.
+
Подпишитесь на список рассылки svn, соответствующий используемой ветви. Например, при использовании 9-STABLE следует подписаться на {svn-src-stable-9}. Этот список рассылки содержит записи из журнала коммитов по каждому изменению, а также сопутствующую информацию о возможных побочных эффектах.
+
Чтобы подписаться на эти списки рассылки, перейдите по ссылке {mailman-lists-url}, щёлкните на нужном списке, и следуйте дальнейшим инструкциям. Для того чтобы отслеживать изменения всего дерева исходных текстов, подпишитесь на {svn-src-all}.
. Чтобы установить новую систему FreeBSD-STABLE, установите самый последний релиз FreeBSD-STABLE, загрузив его с crossref:mirrors[mirrors,зеркалирующих сайтов FreeBSD] или используйте ежемесячную стандартную сборку FreeBSD-STABLE. Обратитесь к link:https://www.FreeBSD.org/snapshots/[www.freebsd.org/snapshots] для получения дополнительной информации о снэпшотах.
+
Чтобы скомпилировать новую или обновить существующую систему FreeBSD до FreeBSD-STABLE, используйте crossref:mirrors[svn,svn] для загрузки исходных текстов нужной ветки. Имена веток вида `stable/9` перечислены на странице link:https://www.FreeBSD.org/releng/[www.freebsd.org/releng]. При отсутствии надёжного Интернет-соединения можно воспользоваться CTM (crossref:mirrors[ctm,Использование CTM]).
. Перед началом компиляции или обновления до FreeBSD-STABLE внимательно прочтите файл [.filename]#/usr/src/Makefile# и следуйте инструкциям в <<makeworld>>. {freebsd-stable} и [.filename]#/usr/src/UPDATING# позволят быть в курсе прочих процедур, которые иногда бывают необходимы в процессе перехода к следующему релизу.
[[synching]]
== Синхронизация исходных текстов
Имеются различные способы синхронизации с исходными текстами FreeBSD. В этом разделе сравниваются основные из них, Subversion и CTM.
[WARNING]
====
Хотя возможно частичное обновление дерева исходных текстов, единственной поддерживаемой процедурой обновления является обновление всего дерева и перекомпиляция всех программ, работающих в контексте пользователя, например тех, что находятся в каталогах [.filename]#/bin# и [.filename]#/sbin#, а также исходных текстов ядра. Обновление только части дерева исходных текстов, только ядра или только программ часто приводит к возникновению проблем от ошибок компиляции до аварийных остановов системы или потери данных.
====
Subversion для обновления исходных текстов использует модель _pull_. Пользователь или сценарий `cron` запускают программу `svn`, которая обновляет локальную версию исходных текстов. Subversion является предпочтительным способом обновления локального дерева исходных текстов, поскольку обновления являются актуальными с точностью до минуты и пользователь управляет временем их загрузки. Загрузку определённых файлов и каталогов легко ограничить, а запрашиваемые обновления формируются на лету на стороне сервера. О том, как актуализировать исходные тексты с использованием Subversion, описано в crossref:mirrors[svn,svn].
CTM не выполняет интерактивное сравнение имеющихся исходных текстов с находящимися в главном архиве, и не выполняет их загрузку. Вместо этого несколько раз в день на главной машине CTM запускается скрипт, находящий изменения в файлах с момента своего предыдущего запуска. Все обнаруженные изменения сжимаются, помечаются последовательным номером и кодируются для передачи по электронной почте в печатном формате ASCII. После получения эти "дельта-файлы CTM" могут быть переданы утилите `ctm.rmail`, которая осуществляет автоматическое декодирование, проверку и применение изменений к пользовательской копии исходных текстов. Этот процесс более эффективен по сравнению с используемым в Subversion и требует меньше ресурсов сервера, так как он выполнен по модели _push_, а не _pull_. Инструкции по использованию CTM для синхронизации исходных текстов даны в crossref:mirrors[ctm,Использование CTM].
Если пользователь случайно уничтожил часть своего архива, Subversion обнаружит и перестроит повреждённую часть. CTM этого не делает, поэтому если пользователь удалил часть дерева исходных текстов и не имеет архивной копии, то нужно будет начать с самого начала (с последнего "базового дельта-файла"), перестроив всё с помощью CTM.
[[makeworld]]
== Пересборка мира
После того, как локальное дерево исходных текстов было синхронизировано с некоторой версией FreeBSD (FreeBSD-STABLE или FreeBSD-CURRENT), его можно использовать для перестроения системы. Этот процесс известен как перестроение мира.
еред_ перестроением мира убедитесь в выполнении следующих действий:
[.procedure]
====
*Procedure: _Перед_ тем как приступать к построению мира*
. Сохраните резервную копию всех важных данных на другую систему или съёмный носитель, проверьте её целостность и держите под рукой загрузочный носитель. Невозможно переоценить важность создания резервной копии системы _до_ начала перестроения системы. Хотя перестроение системы является простой задачей, неизбежно возникают ситуации, при которых ошибки в исходных текстах приводят к тому, что система перестаёт загружаться. Возможно, вам никогда не придётся этим воспользоваться, но, постучав по дереву, всегда лучше подстраховаться.
. Проверьте последние сообщения в списке рассылки {freebsd-stable} или {freebsd-current} (в зависимости от отслеживаемой ветки). Будьте в курсе любых известных проблем, и тех систем, которые они затрагивают. В случае возникновения подобной проблемы, дождитесь сообщения о том, что эта проблема решена. После этого повторите синхронизацию исходных текстов для получения необходимого исправления.
. Прочтите [.filename]#/usr/src/UPDATING# для получения информации о дополнительных шагах, необходимых для данной версии исходных текстов. В этом файле содержится важная информация о возможных проблемах и может быть указан порядок выполнения соответствующих команд. При большинстве обновлений требуются дополнительные шаги, например, переименование или удаление определённых файлов перед установкой нового мира. Эти шаги будут перечислены в конце файла, где в явном виде описывается текущая рекомендуемая последовательность действий при обновлении. Если содержимое [.filename]#UPDATING# противоречит каким-либо шагам в этой главе, руководствуйтесь инструкциями в файле [.filename]#UPDATING#, которые имеют больший приоритет.
====
[WARNING]
.Не используйте `make world`
====
В некоторой устаревшей документации рекомендуется использование `make world`. Эта команда пропускает некоторые важные шаги, поэтому использовать её следует лишь в том случае, если вы точно знаете, что делаете. Почти во всех случаях `make world` - это неправильный способ, вместо этого следует использовать описанную здесь процедуру.
====
[[canonical-build]]
=== Обзор процесса
Процесс построения мира подразумевает переход с более старой версии FreeBSD с использованием исходных текстов более новой версии, которые были получены согласно инструкциям в <<synching>>.
Во FreeBSD термин "world" обозначает ядро, исполняемые файлы основой системы, библиотеки, файлы для программирования и встроенный компилятор. Имеет значение порядок, при котором эти компоненты собираются и устанавливаются.
Например, из-за ошибки в старом компиляторе невозможно было бы скомпилировать новое ядре. Поскольку новое ядро должно быть собрано новым компилятором, для этого в свою очередь необходимо собрать новый компилятор, но устанавливать его перед сборкой ядра необязательно.
Новый мир может зависеть от особенностей нового ядра, поэтому новое ядро должно быть установлено до установки нового мира. Старый мир может работать неправильно на новом ядре, поэтому новый мир должен быть установлен сразу после установки нового ядра.
Перед установкой нового мира могут потребоваться изменения в конфигурации, но некоторые из изменений могут не работать со старым миром. Следовательно, используются два разных этапа обновления конфигурации. В основной части процесса обновления выполняется только замена или добавление файлов. Существующие файлы при этом не удаляются. Поскольку это может повлечь проблемы, в [.filename]#/usr/src/UPDATING# содержится информация о том, какие из файлов и на каком шаге нужно удалить вручную.
Исходя из этих соображений в следующей процедуре описана рекомендуемая последовательность обновления.
[NOTE]
====
Хорошей практикой является запись в файл вывода команды `make`. Если что-то пошло не так, копию сообщения об ошибке можно отправить в один из списков рассылки FreeBSD.
Проще всего использовать для этого `script` с параметром, задающим имя файла для сохранения всего вывода. Не сохраняйте вывод в [.filename]#/tmp#, так как этот каталог может быть очищен при следующей перезагрузке. Более подходящим местом является [.filename]#/var/tmp#. Запустите команду непосредственно перед перестроением мира, а после завершения процесса наберите `exit`:
[source,shell]
....
# script /var/tmp/mw.out
Script started, output file is /var/tmp/mw.out
....
====
[.procedure]
====
*Procedure: Обзор процесса построения мира*
Команды для построения мира должны запускаться в указанном здесь порядке. В этом разделе даётся краткое описание назначения каждой из команд.
. Если процесс построения мира уже запускался ранее на этой системе, то в [.filename]#/usr/obj# могла остаться копия предыдущей сборки. Удалите этот каталог для ускорения процесса построения нового мира и возможного сокращений работы по разрешению зависимостей.
+
[source,shell]
....
# chflags -R noschg /usr/obj/*
# rm -rf /usr/obj
....
+
. Скомпилируйте новый компилятор и несколько сопутствующих инструментов и используйте их для компиляции остальной части мира. Результаты сохраняются в [.filename]#/usr/obj#.
+
[source,shell]
....
# cd /usr/src
# make buildworld
....
+
. Для построения нового ядра используйте компилятор, расположенный в [.filename]#/usr/obj#, чтобы защититься от ошибок несоответствия между компилятором и ядром. Это необходимо, так как определённые структуры данных могут поменяться, и при использовании различных версий ядра и исходных текстов перестанут работать `ps` и `top`.
+
[source,shell]
....
# make buildkernel
....
+
. Установите новое ядро и модули, чтобы их можно было использовать для загрузки. Если используется `kern.securelevel` со значением выше `1` _и_ на файле ядра установлен `noschg` или подобный флаг, то для этого сперва придётся дополнительно перейти в однопользовательский режим. В противном случае эту команду можно без проблем запустить в многопользовательском режиме. Смотрите страницу Справочника man:init[8] для получения информации о `kern.securelevel`, а также man:chflags[1] для информации об использовании различных файловых флагов.
+
[source,shell]
....
# make installkernel
....
+
. Переведите систему в однопользовательский режим для минимизации проблем при обновлении уже работающих исполняемых файлов. Это также уменьшит вероятность возникновения проблем при работе старого мира на новом ядре.
+
[source,shell]
....
# shutdown now
....
+
После перехода в однопользовательский режим, запустите эти команды, если в системе используется UFS:
+
[source,shell]
....
# mount -u /
# mount -a -t ufs
# swapon -a
....
+
Если используется ZFS, запустите другие две команды. В данном примере zpool называется `zroot`:
+
[source,shell]
....
# zfs set readonly=off zroot
# zfs mount -a
....
+
. Дополнительно: Если желаемая картография клавиатуры отличается от используемой по умолчанию US English, её можно изменить с помощью man:kbdmap[1]:
+
[source,shell]
....
# kbdmap
....
+
. Затем, если часы CMOS установлены на местное время (это так, если вывод man:date[1] не содержит правильное время и часовой пояс), выполните:
+
[source,shell]
....
# adjkerntz -i
....
+
. Пересборка мира не включает в себя добавление или обновление конфигурационных файлов в [.filename]#/etc#, [.filename]#/var#, [.filename]#/usr# и некоторых других каталогах. Следующим шагом является выполнение первоначального обновления файлов конфигурации в [.filename]#/etc# для подготовки к новому миру. Следующая команда ограничивается сравнением файлов, необходимых для успешного выполнения цели `installworld`. В частности, на этом шаге могут быть добавлены новые пользовательские группы, служебные учётные записи и сценарии автозапуска, которые были добавлены во FreeBSD со времени последнего обновления. Это необходимо для их использования при выполнении шага `installworld`. Смотрите <<mergemaster>> для получения более подробных инструкций по этой команде:
+
[source,shell]
....
# mergemaster -p
....
+
. Установите новый мир и служебные исполняемые файлы, находящиеся в [.filename]#/usr/obj#.
+
[source,shell]
....
# cd /usr/src
# make installworld
....
+
. Обновите остальные файлы конфигурации.
+
[source,shell]
....
# mergemaster -iF
....
+
. Удалите устаревшие файлы. Это важно, так как в противном случае они могут вызвать проблемы.
+
[source,shell]
....
# make delete-old
....
+
. Теперь нужна полная перезагрузка системы для того, чтобы загрузить новое ядро и мир с использованием новых конфигурационных файлов.
+
[source,shell]
....
# reboot
....
+
. Убедитесь, что перед удалением старых версий библиотек все установленные порты были пересобраны согласно инструкциям в crossref:ports[ports-upgrading,Обновление портов]. По завершению удалите все старые библиотеки во избежание конфликтов с их новыми версиями. За подробным описанием этого шага обратитесь к <<make-delete-old>>.
+
[source,shell]
....
# make delete-old-libs
....
====
Если для системы доступно окно обслуживания, обдумайте возможность компиляции системы в однопользовательском режиме вместо использования для этого многопользовательского режима с переводом в однопользовательский режим для установки. Переустановка системы затрагивает множество важных системных файлов, все стандартные системные исполняемые файлы, библиотеки и заголовочные файлы. Замена этих файлов на работающей системе (в частности, используемых в данный момент пользователями) может привести к неприятностям.
[[src-updating]]
=== Файлы конфигурации
В процессе построения мира используется несколько файлов конфигурации.
[.filename]#Makefile#, расположенный в [.filename]#/usr/src#, описывает правила и порядок построения программ, составляющих FreeBSD.
В man:make.conf[5] описаны параметры, доступные для `make`, а также несколько общих примеров имеется в [.filename]#/usr/shared/examples/etc/make.conf#. Добавляемые в [.filename]#/etc/make.conf# параметры определяют поведение `make` при построении программ. Эти параметры действуют при каждом использовании `make`, включая компиляцию приложений из Коллекции Портов, компиляцию собственных программ на Си и построение операционной системы FreeBSD. Изменение некоторых настроек может иметь далекоидущие и порой неожиданные последствия. Прочтите комментарии в обоих местах и примите к сведению, что значения по умолчанию были выбраны как компромисс между производительностью и надёжностью.
Поведение при сборке операционной системы из исходных текстов задаётся в [.filename]#/etc/src.conf#. В отличие от [.filename]#/etc/make.conf#, содержимое [.filename]#/etc/src.conf# влияет только на сборку самой операционной системы FreeBSD. Описание многих параметров, доступных в этом файле, имеется в man:src.conf[5]. Будьте осторожны при выключении на первый взгляд ненужных модулей ядра или параметров сборки. Иногда между ними имеются неожиданные или неочевидные взаимозависимости.
[[make-buildworld]]
=== Переменные и цели выполнения
Общий формат использования `make`:
[source,shell]
....
# make -x -DVARIABLE target
....
В этом примере параметр `-_x_` передаётся `make`. Обратитесь к странице Справочника man:make[1] для получения примеров использования имеющихся параметров.
Чтобы передать переменную, укажите её имя с использованием `-D_VARIABLE_`. Поведение [.filename]#Makefile# зависит от переменных. Они могут быть заданы в [.filename]#/etc/make.conf# или указаны при использовании `make`. Например, эта переменная указывает, что библиотеки для профилирования собирать не нужно:
[source,shell]
....
# make -DNO_PROFILE target
....
Это соответствует настройке в [.filename]#/etc/make.conf#:
[.programlisting]
....
NO_PROFILE= true # Обход построения библиотек для профилирования
....
_target_ указывает программе `make` на то, что нужно сделать, а [.filename]#Makefile# определяет доступные цели. Некоторые цели используются в процессе построения для разбиения его на этапы.
Разделение опций удобно по двум причинам. Во-первых, это позволяет выполнять сборку, не затрагивая компоненты рабочей системы. По этой причине можно спокойно запустить `buildworld` на машине, работающей в многопользовательском режиме. Но цель `installworld` всё же рекомендуется запускать в однопользовательском режиме.
Во-вторых, это позволяет использовать монтирование по NFS для обновления многих машин по сети согласно описанию в <<small-lan>>.
Параметр `-j` приводит к запуску нескольких одновременно работающих процессов `make`. Поскольку процесс компиляции больше всего требователен к подсистеме ввода/вывода, а не к производительности процессора, это можно использовать и на машинах с одним процессором.
Используйте следующую команду на машине с одним CPU, чтобы иметь до 4 одновременно работающих процессов. Опубликованные в списке рассылки практические замеры показывают, что в среднем это даёт наибольший выигрыш в производительности.
[source,shell]
....
# make -j4 buildworld
....
На многопроцессорной машине попробуйте подобрать значение между `6` и `10`, и посмотрите, как это отразится на скорости работы.
[NOTE]
====
Если при выполнении команды `make buildworld` были заданы значения каких-либо переменных, то при выполнении `make installworld` нужно задать те же самые переменные. При этом `-j` _нельзя_ использовать совместно с `installworld`.
Например, если выполнялась эта команда:
[source,shell]
....
# make -DNO_PROFILE buildworld
....
то результат её выполнения должен устанавливаться командой:
[source,shell]
....
# make -DNO_PROFILE installworld
....
В противном случае вторая команда попытается установить библиотеки для профилирования, которые не компилировались на этапе выполнения команды `make buildworld`.
====
[[mergemaster]]
=== Объединение файлов конфигурации
FreeBSD предоставляет утилиту man:mergemaster[8], которая является скриптом для оболочки Боурна и предназначена для определения разницы между конфигурационными файлами в каталоге [.filename]#/etc# и конфигурационными файлами из дерева исходных текстов [.filename]#/usr/src/etc#. Это является рекомендуемым способом синхронизации системных конфигурационных файлов с теми, что размещены в дереве исходных текстов.
Перед использованием `mergemaster` рекомендуется скопировать имеющийся каталог [.filename]#/etc# в какое-нибудь безопасное место. `-R` задает выполнение рекурсивного копирования, а `-p` сохраняет даты и владельца файлов:
[source,shell]
....
# cp -Rp /etc /etc.old
....
При запуске `mergemaster` строит временное корневое окружение, начиная с [.filename]#/#, и заполняет его различными системными конфигурационными файлами. Затем эти файлы сравниваются с текущими установленными в системе. Файлы, которые имеют отличия, будут выданы в формате man:diff[1], где знак `+` означает добавленные или изменённые строки, а знак `-` означает строки, которые будут либо полностью удалены, либо заменены на новый файл. Обратитесь к страницам справочной системы по команде man:diff[1] для получения более полной информации о формате выдачи отличий в файлах.
Затем `mergemaster` выдаст каждый файл, в котором есть изменения, с вариантами действий: удалить новый файл, упоминаемый здесь как временный, установить временный файл в его неизменённом виде, объединить временный файл с установленным на данный момент, либо просмотреть результат ещё раз.
Выбор удаления временного файла укажет `mergemaster` оставить текущий файл без изменений и удалить его новую версию. Делать это не рекомендуется. Чтобы получить помощь в любое время, наберите kbd:[?] в приглашении `mergemaster`. Если пользователь выбирает пропуск файла, запрос появится снова, после того как будут обработаны все остальные файлы.
Выбор установки немодифицированного временного файла приведёт к замене текущего файла новым. Для большинства немодифицированных файлов это является подходящим вариантом.
Выбор варианта с объединением файла приведёт к вызову текстового редактора, содержащего текст обоих файлов. Файлы можно объединить, просматривая оба файла на экране и выбирая те части из обоих, которые подходят для окончательного варианта. При сравнении файлов нажатие kbd:[l] выбирает содержимое слева, нажатие kbd:[r] выбирает содержимое справа. В окончательном варианте будет файл, состоящий из обеих частей, который и будет установлен. Этот вариант обычно используется для файлов, настройки в которых изменялись пользователем.
Выбор повторного просмотра результатов выдаст разницу между файлами.
После того как утилита `mergemaster` закончит работу с системными файлами, она выдаст запрос относительно других параметров. Она может запросить перестроение файла паролей и завершится запросом на удаление оставшихся временных файлов.
[[make-delete-old]]
=== Удаление устаревших файлов и библиотек
В ходе жизненного цикла разработки FreeBSD файлы с их содержимым иногда становятся устаревшими. Это может быть вызвано тем, что функциональность реализуется в другом месте, сменился номер версии библиотеки или файл был целиком удалён из системы. Такие устаревшие файлы, библиотеки и каталоги следует удалять вместе с обновлением системы. Это не даст захламить систему старыми файлами, которые занимают место на диске и на архивных носителях. Кроме того, если в старой библиотеке имеется проблема безопасности или стабильности, такую систему следует обновить до более новой библиотеки, чтобы предотвратить крахи, вызванные работой старой версии. Файлы, каталоги и библиотеки, которые признаны устаревшими, перечислены в [.filename]#/usr/src/ObsoleteFiles.inc#. Для удаления устаревших файлов в процессе обновления системы следует пользоваться следующими инструкциями.
После выполнения `make installworld` и последующего `mergemaster` проверьте наличие устаревших файлов и библиотек:
[source,shell]
....
# cd /usr/src
# make check-old
....
Если были найдены какие-либо устаревшие файлы, их можно удалить с помощью следующей команды:
[source,shell]
....
# make delete-old
....
Перед удалением каждого устаревшего файла запрашивается подтверждение. Используйте `BATCH_DELETE_OLD_FILES`, чтобы сократить этот процесс и позволить системе удалить эти файлы автоматически:
[source,shell]
....
# make -DBATCH_DELETE_OLD_FILES delete-old
....
Аналогичного эффекта можно достичь, пропустив эти команды через `yes`:
[source,shell]
....
# yes|make delete-old
....
.Предупреждение
[WARNING]
====
Удаление устаревших файлов приведёт к нарушению работы программ, которые всё ещё зависят от этих устаревших файлов. Это особенно верно для старых библиотек. В большинстве случаев программы, порты или библиотеки, использующие такую старую библиотеку, нужно перекомпилировать перед выполнением `make delete-old-libs`.
====
Программы для проверки наличия зависимостей от совместно используемых библиотек включают в себя package:sysutils/libchk[] и package:sysutils/bsdadminscripts[].
Устаревшие совместно используемые библиотеки могут конфликтовать с более новыми библиотеками, что приводит к сообщениям следующего вида:
[source,shell]
....
/usr/bin/ld: warning: libz.so.4, needed by /usr/local/lib/libtiff.so, may conflict with libz.so.5
/usr/bin/ld: warning: librpcsvc.so.4, needed by /usr/local/lib/libXext.so, may conflict with librpcsvc.so.5
....
Для решения этих проблем выясните, какой именно порт установил данную библиотеку:
[source,shell]
....
# pkg which /usr/local/lib/libtiff.so
/usr/local/lib/libtiff.so was installed by package tiff-3.9.4
# pkg which /usr/local/lib/libXext.so
/usr/local/lib/libXext.so was installed by package libXext-1.1.1,1
....
Затем данный порт нужно удалить, пересобрать и переустановить. Для автоматизации этого процесса можно использовать package:ports-mgmt/portmaster[]. После того как все порты пересобраны и более не используют старые библиотеки, удалите эти старые библиотеки с помощью следующей команды:
[source,shell]
....
# make delete-old-libs
....
Если что-то работает неправильно, можно с лёгкостью перестроить конкретную часть системы. Например, если файл [.filename]#/etc/magic# был случайно удалён в процессе обновления или переноса [.filename]#/etc#, то команда `file` перестанет работать. В таком случае это можно исправить вот так:
[source,shell]
....
# cd /usr/src/usr.bin/file
# make all install
....
[[updating-questions]]
=== Вопросы общего характера
Нужно ли полностью перестраивать систему при каждом изменении?::
Это зависит от характера изменения. Например, если svn показывает, что с момента последнего запуска были изменены только следующие файлы:
+
[source,shell]
....
src/games/cribbage/instr.c
src/games/sail/pl_main.c
src/release/sysinstall/config.c
src/release/sysinstall/media.c
src/shared/mk/bsd.port.mk
....
+
то перестраивать всю систему возможно незачем. Вместо этого можно перейти в соответствующие подкаталоги и выдать команду `make all install`. Однако если меняется что-то важное, например, [.filename]#src/lib/libc/stdlib#, то вы должны перестроить всю систему.
+
Некоторые пользователи перестраивают систему каждые две недели, позволяя изменениям накопиться за это время. Другие перестраивают только те вещи, которые менялись, и внимательно отслеживают все зависимости. Всё это зависит от того, как часто пользователь хочет делать обновление и отслеживает ли он FreeBSD-STABLE или FreeBSD-CURRENT.
Почему прерывается компиляция с большим количеством ошибок по сигналу 11 (или с другим номером сигнала)?::
Как правило, это говорит о проблемах с оборудованием. Построение системы является эффективным стресс-тестом для оборудования, в особенности памяти. Явным указателем на это является то, что при перезапуске make процедура построения прекращается в различные моменты времени.
+
Для исправления этой ошибки попробуйте заменить комплектующие машины, начиная с оперативной памяти, для определения сбоящей компоненты.
Можно ли удалить [.filename]#/usr/obj# после окончания?::
В этом каталоге содержатся все объектные файлы, которые создаются во время фазы компиляции. Обычно одним из первых шагов в процессе `make buildworld` является удаление этого каталога, чтобы начать заново. Сохранение [.filename]#/usr/obj# после окончания имеет мало смысла, а его удаление освободит приблизительно 2 ГБ дискового пространства.
Могут ли быть продолжены прерванные процессы построения?::
Это зависит от того, насколько далеко зашел процесс построения перед тем, как была обнаружена проблема. В общем случае процесс `make buildworld` строит новые копии необходимых инструментальных средств и системные библиотеки. Затем эти средства и библиотеки устанавливаются. Новые инструментальные средства и библиотеки затем используются для перестроения самих себя и повторно устанавливаются. Система в целом теперь перестраивается с новыми системными файлами.
+
На последней стадии выполнение этих команд является достаточно безопасным, поскольку они не отменяют работу предыдущего `make buildworld`:
+
[source,shell]
....
# cd /usr/src
# make -DNO_CLEAN all
....
+
Если в выводе `make buildworld` появляется такое сообщение:
+
[source,shell]
....
--------------------------------------------------------------
Building everything..
--------------------------------------------------------------
....
+
то делать так вероятно достаточно безопасно.
+
Если такое сообщение не выводится, всегда лучше подстраховаться и запустить сборку с самого начала.
Можно ли ускорить сборку мира?::
Ускорить процесс сборки мира может несколько действий. Например, весь процесс можно выполнять в однопользовательском режиме. Однако, это не позволит пользователям иметь доступ к системе, пока этот процесс не завершится.
+
Тщательный подход к проектированию файловой системы или использование датасетов ZFS позволит почувствовать разницу. Задумайтесь о размещении [.filename]#/usr/src# и [.filename]#/usr/obj# на различных файловых системах. По возможности размещайте файловые системы на различных дисках и дисковых контроллерах. При монтировании [.filename]#/usr/src# используйте параметр `noatime`, который отключает запись информации о времени доступа к файлу. Если [.filename]#/usr/src# не расположен на собственной файловой системе, подумайте о перемонтировании [.filename]#/usr# с `noatime`.
+
Файловая система, на которой располагается [.filename]#/usr/obj#, может быть смонтирована (или перемонтирована) с параметром `async`. Это приведёт к тому, что операции записи на диск будут выполняться асинхронно. Другими словами, запись будет завершаться немедленно, но данные записываться на диск несколькими секундами позже. Это позволит объединять операции записи и приведёт к значительному приросту производительности.
+
Файловую систему с [.filename]#/usr/obj# можно смонтировать с `async` для записи на диск в асинхронном режиме. В этом случае операции записи завершаются мгновенно, а сами данные записываются на диск через несколько секунд. Это позволяет писать кластеризованно, что может дать значительный прирост производительности.
+
[WARNING]
====
Имейте в виду, что эта опция делает вашу файловую систему менее устойчивой. С этой опцией имеется больше шансов, что при перезагрузке машины после неожиданного сбоя при пропадании напряжения файловая система окажется в невосстановимом состоянии.
Если каталог [.filename]#/usr/obj# - это всё, что есть на этой файловой системе, то это не проблема. Если на той же самой файловой системе имеются какие-то важные данные, то проверьте давность ваших резервных копий перед включением этой опции.
====
+
Выключите генерацию профилирующего кода, установив "NO_PROFILE=true" в файле [.filename]#/etc/make.conf#.
+
Передайте утилите man:make[1] параметр `-j__n__` для запуска параллельно нескольких процессов. Обычно это помогает вне зависимости от того, сколько процессоров установлено в машине.
Что делать, если что-то пошло не так?::
Скрупулезно проверьте, чтобы в вашем окружении не было мешающих остатков от предыдущих построений:
+
[source,shell]
....
# chflags -R noschg /usr/obj/usr
# rm -rf /usr/obj/usr
# cd /usr/src
# make cleandir
# make cleandir
....
+
Да, команду `make cleandir` действительно нужно выполнять дважды.
+
После этого повторите весь процесс снова, начиная с `make buildworld`.
+
Если у вас всё ещё есть проблемы, пришлите текст ошибки и вывод команды `uname -a` в {freebsd-questions}. Будьте готовы ответить на другие вопросы о конфигурации вашей системы!
[[small-lan]]
== Отслеживание исходных текстов для нескольких машин
Если нужно отслеживать одно и то же дерево исходных текстов на множестве машин, то загрузка кода и полное перестроение системы на каждой из них выглядит как ненужная трата ресурсов: дискового пространства, пропускной способности сети и процессорного времени. Решением является выделение одной машины, которая выполняет основной объём работы, в то время как остальные используют результаты работы посредством NFS. В этом разделе описывается именно этот метод. Для получения информации об использовании NFS обращайтесь в crossref:network-servers[network-nfs,Network File System (NFS)].
Первым делом определите набор машин, на которых будет выполняться единый набор программ, который мы будем называть _набором для построения_. Каждая машина может иметь собственное уникальное ядро, но они будут работать с одними и теми же программами пользователя. Из этого набора выберите машину, которая будет являться _машиной построения_, на которой будут строиться ядро и всё окружение. В идеальном случае это быстрая машина с достаточно незагруженным CPU для выполнения команд `make buildworld` и `make buildkernel`.
Выберите _тестовую машину_, которая будет выполнять проверку обновлений программного обеспечения, прежде чем они пойдут в работу. Это _должна_ быть машина, которая может находиться в нерабочем состоянии достаточно долго. Это также может быть машина построения, но не обязательно.
Всем машинам в этом наборе для построения нужно смонтировать [.filename]#/usr/obj# и [.filename]#/usr/src# по NFS с машины построения. В случае нескольких наборов для построения каталог [.filename]#/usr/src# должен находиться на одной машине построения и монтироваться на остальных по NFS.
Удостоверьтесь, что [.filename]#/etc/make.conf# и [.filename]#/etc/src.conf# на всех машинах в заданном наборе для построения согласуются с машиной построения. Это означает, что машина построения должна строить все те части базовой системы, которые будут устанавливаться на каждой машине из набора для построения. Кроме того, у каждой машины построения должно быть задано имя ядра в переменной `KERNCONF` в [.filename]#/etc/make.conf#, и машина построения должна перечислить их все в переменной `KERNCONF`, причём первым должно идти имя её собственного ядра. Машина построения должна хранить конфигурационные файлы ядра каждой машины в каталоге [.filename]#/usr/src/sys/arch/conf#.
Постройте ядро и всё окружение на машине построения так, как это описано в <<make-buildworld>>, но ничего не устанавливайте на самой машине. Вместо этого, установите собранное ядро на тестовой машине. Для этого смонтируйте [.filename]#/usr/src# и [.filename]#/usr/obj# по NFS. Затем выполните команду `shutdown now` для перехода в однопользовательский режим, для того чтобы установить новое ядро и всё окружение, после чего выполните команду `mergemaster` обычным образом. После этих действий перезагрузитесь для возврата к обычному режиму работы в многопользовательском режиме.
После того, как вы убедитесь в нормальной работе всего на тестовой машине, проведите эту процедуру для установки нового программного обеспечения на каждой из оставшихся машин в наборе для построения.
Такой же подход можно использовать и для дерева портов. Сперва нужно смонтировать [.filename]#/usr/ports# по NFS на всех машинах в наборе для построения. Чтобы настроить [.filename]#/etc/make.conf# для использования общего каталога с дистрибутивными файлами, задайте переменную `DISTDIR` так, чтобы она указывала на общедоступный каталог, доступный для записи тому пользователю, который отображается в пользователя `root` для точек монтирования NFS. Каждая машина должна задавать `WRKDIRPREFIX` так, чтобы она указывала на локальный каталог, если порты будут собираться локально. Если же пакеты будут распространяться, задайте на машине построения переменную `PACKAGES`, чтобы она указывала на каталог, соответствующий `DISTDIR`.