# FreeBSD "с нуля"

Jens
Schweikhardt

    schweikh@FreeBSD.org

2002,2003,2004
Jens Schweikhardt
$FreeBSD$
&tm-attrib.freebsd; &tm-attrib.adobe; &tm-attrib.general;

В этой статье описывается мои по полностью автоматизированная установка преднастроенной компилируемой из исходных текстов, включая компиляцию всех ваших любимых портов и преднастроенной так, что она соответствует вашим представлениям о настоящей системе. Если вы полагаете, что концепция `make world` является прекрасным подходом, то &scratch.ap; расширяет это понятие до `make evenmore`.

## Введение

Вы когда-либо обновляли вашу систему при помощи `make world`? Существует одна проблема, возникающая при наличии всего лишь одной системы на диске. Если выполнение цели installworld прерывается на середине, у вас остаётся неработоспособная система, которая может даже не загружаться. Либо цель installworld отрабатывает нормально, а новое ядро не загружается. Тогда наступает момент для поиска Fixit CD и резервных копий, которые вы делали полгода назад.

Я исповедую подход сотрите данные на дисках при обновлении систем. Удаление дисков, и даже разделов, обеспечивает вам то, что нигде не остаётся никаких частей старого, то, о чём не заботятся большее число процедур обновления. Однако очистка разделов означает, что вам нужно перекомпилировать/переустановить все ваши порты и пакаджи, а также проделать все тонкие процедуры настройки. Если вы думаете, что эта задача тоже должна быть автоматизирована, то читайте дальше.

## Почему мне (не) нужна &scratch.ap;?

Это закономерный вопрос. У нас имеется утилита sysinstall и хорошо изученный способ компиляции ядра и пользовательских приложений.

Проблема с утилитой sysinstall заключается в том, что она несколько ограничена в том, что, куда и как может устанавливать.

- Обычно она использовалась для установки уже откомпилированных дистрибутивных наборов и пакаджей с некоторого носителя (CD, DVD, FTP). Она не может устанавливать результат выполнения `make buildworld`.

- Она не может устанавливать вторую систему в некоторый каталог уже работающей системы.

- Она не может выполнять установку в разделы Vinum.

- Она не может строить порты, а лишь устанавливать уже откомпилированные пакаджи.

- Создание скриптов или выполнение нестандартных действий после установки затруднено.

- И последним, но одним из самых важных факторов, является полуофициальное прекращение дальнейшей поддержки sysinstall.

Хорошо известный способ полного построения и установки системы, описанный в Руководстве, по умолчанию замещает существующую систему. При этом сохраняются только модули и ядро. Системные бинарные файлы, файлы объявлений функций и множество других файлов перезаписываются; уже ненужные файлы остаются и могут преподносить сюрпризы. Если по какой-либо причине обновление завершилось неудачно, бывает трудно и даже невозможно вернуть систему в исходное состояние.

&scratch.ap; решает все эти проблемы. Её стратегия проста: использование работающей системы для установки новой в пустое дерево каталогов, при этом новые разделы монтируются в соответствующие места этого дерева. Многие конфигурационные файлы могут быть скопированы в соответствующее место, а &man.mergemaster.8; сможет позаботиться о тех, что скопировать не удалось. Тонкая настройка новой системы может быть выполнена в старой, вплоть до момента, когда вы сможете выполнить chroot в новую систему. Другими словами, мы проходим через три этапа, при этом каждый шаг представляет собой либо запуск скрипта, либо вызов команды `make`:

1. `stage_1.sh`: Создание новой загружаемой системы в пустом каталоге и объединение либо копирование максимально большего количества необходимых файлов. Затем загрузка новой системы.

2. `stage_2.sh`: Установка требуемых портов.

3. `stage_3.mk`: Выполнение последующей настройки программного обеспечения, установленного на предыдущем этапе.

После того, как вы воспользуетесь &scratch.ap; для построения второй системы и в течение нескольких недель убедитесь, что она работает удовлетворительно, можете затем использовать её повторно для переустановки исходной системы. С этого момента, как только вы почувствуете необходимость обновления, то просто выберите разделы, которые хотите удалить и выполнить переустановку.

Может быть, вы слышали и даже пробовали использовать систему Linux From Scratch, или LFS для краткости. LFS также определяет, как построить и установить систему с нуля на пустой раздел при помощи работающей системы. LFS делает упор на выяснение роли каждого компонента системы (таких, как ядро, компилятор, устройства, командный процессор, база данных терминальных устройств и так далее) и деталей установки каждого компонента. &scratch.ap; не опускается до такого уровня детализации. Моей целью является проведение автоматизированной и полной установки, а не описание всех кровавых подробностей полного перепостроения системы. В случае, если вы хотите изучить &os; до такого уровня, начните с просмотра `/usr/src/Makefile` и следуйте действиям, которые выполняет `make buildworld`.

В подходе, который применяется в &scratch.ap;, имеются свои отрицательные стороны, которые вы должны иметь в виду.

- При компиляции портов на втором этапе систему нельзя использовать в обычном режиме. Если вы имеете дело с сервером, работающим в режиме промышленной эксплуатации, вы должны быть готовы к простою, к которому приводит выполнение второго этапа. Порты, построенные при помощи `stage_2.conf.default` ниже, требуют примерно 4 часа для построения на системе AMD1800+ со SCSI-дисками, имеющими скорость вращения 10krpm и 1 Гбайтом ОЗУ.

## Предварительные требования

Для того, чтобы воспользоваться подходом &scratch.ap;, вам нужно иметь:

- Работающую систему &os; с исходными текстами и деревом портов.

- По крайней мере один неиспользуемый раздел, куда будет устанавливаться новая система.

- Опыт работы с &man.mergemaster.8;. Или по крайней мере отсутствие страха его использовать.

- Если у вас нет подключения или слабый канал в Internet: дистрибутивные файлы для ваших любимых портов.

- Знание основ написания скриптов на языке командного процессора Bourne, &man.sh.1;.

- Наконец, вы должны уметь указывать загрузчику системы на загрузку новой системы, либо интерактивно, либо из конфигурационного файла.

## Этап первый: Установка системы

В первом варианте этой статьи на первом шаге использовался единственный скрипт, в котором вся настройка выполнялась его редактированием. После того, как пользователи высказали свои замечания, я решил разделить код и данные на уровне скриптов. Это позволяет иметь разные наборы конфигурационных данных для установки различных систем без внесения изменений в скрипты с кодом.

Скрипт с кодом для первого этапа называется `stage_1.sh`, и он запускается с единственным аргументом, например

    &prompt.root; ./stage_1.sh default

будет считывать свою конфигурацию из файла `stage_1.conf.default` и записывать протокол в файл `stage_1.log.default`.

Далее приводится мой файл `stage_1.conf.default`. Вам необходимо подправить его в различных местах для того, чтобы он соответствовал вашим представлениям об идеальной системе. Я попытался подробно прокомментировать те места, которые вы должны исправлять. Конфигурационный скрипт должен предоставлять четыре функции для оболочки, `create_file_systems`, `create_etc_fstab`, `copy_files` и `all_remaining_customization` (в случае, если это имеет смысл: именно в такой последовательности они будут вызываться из `stage_1.sh`).

Следует внимательно отнестись к следующим моментам:

- Разбиение разделов.

  Я не являюсь сторонником наличия одного большого раздела для всей системы. Мои системы, как правило, имеют по крайней мере по одному разделу для `/`, `/usr` и `/var` с каталогом `/tmp`, образованным символической ссылкой в `/var/tmp`. Вдобавок я использую файловые системы в режиме совместного доступа к `/home` (домашние каталоги пользователей), `/home/ncvs` (копия CVS-хранилища &os;), `/usr/ports` (дерево портов), `/src` (различные выгруженные из хранилища деревья исходных текстов) и `/share` (остальные совместно используемые данные, резервные копии которых не нужны, например, спул сервера телеконференций).

- Новые возможности.

  Это то, что вы хотите иметь сразу после загрузки новой системы и даже до запуска второго этапа. Причина отказа от простой установки всех моих любимых портов на первом этапе заключается в том, что теоретически и практически существуют проблемы начальной загрузки и целостности: на первом этапе работает ваше старое ядро, однако в chroot-окружении содержится новые двоичные файлы программ и файлы объявлений. Если новая система, к примеру, поддерживает новый системный вызов (согласно её заголовочным файлам), некоторый скрипт конфигурации может попытаться использовать его и завершить работу аварийно, потому что работает под старым ядром. Я наблюдал и другие проблемы при попытке построения порта `lang/perl5`.

Перед тем, как запускать `stage_1.sh`, убедитесь, что выполнили обычные действия при подготовке к `make installworld installkernel`, типа:

- отредактировали конфигурационный файл вашего ядра

- успешно выполнили `make buildworld`

- успешно выполнили `make buildkernel KERNCONF=whatever`

Когда вы запускаете `stage_1.sh` первый раз, и конфигурационный файл, скопированный с работающей системы в новую, является устаревшим по сравнению с тем, что находится в каталоге `/usr/src`, `mergemaster` будет запрашивать вас на отработку этой ситуации. Я рекомендую переносить изменения. Если вам надоело отвечать на запросы, вы можете просто обновить файлы в вашей работающей системе за раз (Если только это вам подходит. Скорее всего, вам не нужно это делать, если одна из ваших систем работает под управлением `-STABLE`, а другая с `-CURRENT`. Изменения могут оказаться несовместимыми). Последующие вызовы утилиты `mergemaster` обнаружат, что RCS-идентификаторы версий соответствуют тем, что находятся в `/usr/src`, и пропустят файл.

Скрипт `stage_1.sh` остановится на первой команде, которая завершится неудачно (возвратит ненулевой код завершения) из-за `set -e`, так что вы не пропустите ошибки. Он также остановится, если вы используете отмену значения переменной окружения, как правило, из-за опечатки. Вы должны исправить все ошибки в вашей версии `stage_1.conf.default` перед тем, как продолжить работу.

В скрипте `stage_1.sh` мы вызываем `mergemaster`. Даже если никаким файлам объединение не требуется, он выведет сообщение и в конце сделает запрос

    *** Comparison complete

    Do you wish to delete what is left of /var/tmp/temproot.stage1? [no] no

Пожалуйста, ответьте `no` или просто нажмите Enter. Причина в том, что `mergemaster` оставит несколько файлов нулевой длины в каталоге `/var/tmp/temproot.stage1`, которые позже будут скопированы в новую систему (если их здесь уже нет).

После этого будет выдан список установленных файлов при помощи утилиты постраничного вывода, по умолчанию это &man.more.1;, может быть &man.less.1;:

    *** You chose the automatic install option for files that did not
        exist on your system.  The following were installed for you:
          /newroot/etc/defaults/rc.conf
          ...
          /newroot/COPYRIGHT

    (END)

Нажмите q для того, чтобы прекратить просмотр. Затем вы будете проинформированы о `login.conf`:

    *** You installed a login.conf file, so make sure that you run
        '/usr/bin/cap_mkdb /newroot/etc/login.conf'
        to rebuild your login.conf database

        Would you like to run it now? y or n [n]

Ответ не имеет значения, так как мы будем запускать &man.cap.mkdb.1; в любом случае.

Вот авторский файл `stage_1.conf.default`, который вы должны потом модифицировать. В комментариях даётся достаточно информации о том, что необходимо изменить.

Пожалуйста, обратите на команды &man.newfs.8;. Хотя вы не можете создавать новые файловые системы на смонтированных разделах, скрипт успешно удалит все несмонтированные разделы `/dev/da0s1a`, `/dev/da0s1e` и `/dev/da2s1e`. Этого может оказаться достаточным, чтобы испортить вам день, так что подправьте имена устройств.

Сгрузите `stage_1.conf.default`.

При работе этот скрипт устанавливает систему, которая при загрузке имеет:

- Унаследованные списки пользователей и групп.

- Подключение к Internet по Ethernet и PPP с использованием межсетевого экрана.

- Правильный временной пояс и NTP.

- Другие более мелкие конфигурационные параметры, например, `/etc/ttys` и `inetd`.

Другие функции готовы к настройке, но не будут работать, пока не будет завершён второй этап. Например, мы скопировали файлы для настройки печати и X11. Однако для печати, скорее всего, необходимы приложения, отсутствующие в базовом комплекте системы. X11 не будет работать, пока мы не откомпилируем сервер, библиотеки и программы.

## Этап второй: Установка портов

На этом этапе вместо компиляции портов возможна также установка (уже откомпилированных) пакаджей. В этом случае `stage_2.sh` будет представлять собой не более, чем перечень команд `pkg_add`. Я надеюсь, что вы сумеете написать такой скрипт. Здесь мы сосредоточимся на более гибком и традиционном способе с использованием портов.

Следующий скрипт `stage_2.sh` показывает, как я устанавливаю мои любимые порты. Он может быть запущен любое количество раз и будет пропускать все порты, которые уже установлены. Он поддерживает dryrun-параметр (`-n`) для только показа того, что будет выполнено. Вы запускаете его точно также, как `stage_1.sh`, с только одним аргументом, указывающим на конфигурационный файл, к примеру

    &prompt.root; ./stage_2.sh default

который будет считывать перечень портов из `stage_2.conf.default`.

Список портов состоит из строчек с двумя или большим количеством слов, разделённых пробелами: категория и порт, за которыми опционально следует команда установки, которая будет компилировать и устанавливать порт (по умолчанию: `make install`). Пустые строки и строки, начинающиеся с символа #, игнорируются. В большинстве случаев в них указывается только название категории и порт. Однако некоторые порты могут быть тонко настроены при помощи указания `make`-переменных, к примеру:

    www mozilla make WITHOUT_MAILNEWS=yes WITHOUT_CHATZILLA=yes install
    mail procmail make BATCH=yes install

На самом деле вы можете указать некоторые команды оболочки, так что не ограничены простыми вызовами `make`:

    java linux-sun-jdk13 yes | make install
    news inn-stable CONFIGURE_ARGS="--enable-uucp-rnews --enable-setgid-inews" make install

Заметьте, что строка для `news/inn-stable` является примером одновременно задания переменной оболочки `CONFIGURE_ARGS`. Файл `Makefile` порта будет использовать это как начальное значение и определит некоторые другие необходимые аргументы. Разница в задании make-переменных в командной строке по команде

    news inn-stable make CONFIGURE_ARGS="--enable-uucp-rnews --enable-setgid-inews" install

заключается в том, что в последнем случае значение будет переназначено, но не расширено. Выбор нужного метода зависит от конкретного порта.

Убедитесь в том, что ваши порты не используют интерактивный режим установки, то есть не должны пытаться читать со стандартного устройства ввода ничего кроме того, что вы им подаёте на вход. Если это всё же происходит, то они будут считывать последующие строки из вашего перечня портов, описываемого в этом документе, и будут работать некорректно. Если скрипт `stage_2.sh` неожиданно пропустил порт или прекратил работу, причина может быть в этом.

Ниже приводится `stage_2.conf.default`. Для каждого установленного им порта создаётся файл протокола `LOGDIR/category+port`.

Сгрузите `stage_2.conf.default`.

### Этап третий

На втором этапе вы установили ваши любимые порты. Некоторые их них требуют некоторой настройки. Именно для этого и предназначен третий этап, настройки. Я мог бы интегрировать эту настройку в конец скрипта `stage_2.sh`. Однако я думаю, что есть концептуальное различие между установкой порта и модификацией его начальной конфигурации, и это требует отдельного шага.

Я решил реализовать третий этап в виде файла `Makefile`, потому что это позволяет легко выбирать то, что вы хотите конфигурировать, следующим простым вызовом:

    &prompt.root; make -f stage_3.mk target

Как и в случае с `stage_2.sh`, убедитесь, что файл `stage_3.mk` после загрузки новой системы есть в наличии, поместив его на совместно используемый раздел либо скопировав его куда-нибудь в новую систему.

#### Ограничения

Автоматизированная установка порта может оказаться затруднена, если он является интерактивным и не поддерживает команду `make BATCH=YES install`. Для нескольких портов интерактивность означает не более, чем ввод `yes` в ответ на вопрос о принятии некоторого лицензионного соглашения. Если такой ввод считывается со стандартного устройства ввода, мы просто направляем соответствующие ответы на вход установочной команды (обычно `make install`; именно так я работал с `java/linux-sun-jdk14` в `stage_2.conf.default`).

Такой подход, например, не работает с `editors/staroffice52`, который требует работы X11. Процедура установки включает достаточно большое количество нажатий мыши и набор, так что она не может быть автоматизирована так, как другие порты. Однако для меня сработал следующий трюк: сначала я создал пакадж staroffice на старой системе при помощи команды

    &prompt.root; cd /usr/ports/editors/staroffice52
    &prompt.root; make package
    ===>  Building package for staroffice-5.2_1
    Creating package /usr/ports/editors/staroffice52/staroffice-5.2_1.tbz
    Registering depends:.
    Creating bzip'd tar ball in '/usr/ports/editors/staroffice52/staroffice-5.2_1.tbz'

и на втором этапе я просто использовал следующее:

    &prompt.root; pkg_add /usr/ports/editors/staroffice52/staroffice-5.2_1.tbz

Вы должны также принять во внимание вопросы обновления конфигурационных файлов. Вообще говоря, вы не знаете, когда и сменился ли вообще формат или содержимое конфигурационного файла. В файл `/etc/group` может быть добавлена новая группа, или в `/etc/passwd` может добавиться дополнительное поле. Всё это уже происходило в прошлом. Простое копирование конфигурационного файла из старой в новую систему может в большинстве случаев оказаться достаточным, но в этих случаях это не так. Если вы обновляете систему каноническим способом (путём перезаписывания старых файлов), вы должны использовать утилиту `mergemaster` для работы с изменениями, если вы хотите эффективно объединить вашу локальные настройки с потенциально новыми возможностями. К сожалению, `mergemaster` работает только с файлами базового комплекта системы, а не с любыми файлами, устанавливаемыми портами. Похоже, что стороннее программное обеспечение специально проектируется для того, чтобы я не дремал, и меняет конфигурационные файлы по два раза в месяц. Всё, что вы можете здесь сделать, это быть предупреждёнными, особенно при изменении старшего номера версии. В прошлом я переписывал или перенастраивал файлы для Web-серверов, серверов телеконференций и программ для их чтения. Любое активно разрабатываемое программное обеспечение является первым кандидатом на получение проблем с конфигурационными файлами.

Я использовал систему &scratch.ap; несколько раз для обновления `5-CURRENT` до `5-CURRENT`, то есть я никогда не пытался установить `5-CURRENT` из системы `4-STABLE` и наоборот. Из-за количества изменений между релизами с разными старшими номерами я ожидаю, что этот процесс будет несколько более сложным. Использование &scratch.ap; для обновления внутри `4-STABLE` должно проходить безболезненно (хотя я ещё этого не пробовал делать.) Пользователи ветки `4-STABLE` могут иметь в виду следующее:

Если вы не используете файловую систему устройств, &man.devfs.5;, то можете создать устройства для некоторого вашего оборудования командой &man.MAKEDEV.8; в процессе `all_remaining_customization`.

#### Файлы

Вот три файла, которые вам нужны кроме тех конфигурационных, что уже показаны выше.

Это скрипт `stage_1.sh`, который вы не должны модифицировать.

Сгрузите `stage_1.sh`.

Это скрипт `stage_2.sh`. Вам может понадобиться изменить переменные в самом начале файла.

Сгрузите `stage_2.sh`.

Это мой файл `stage_3.mk`, который даст вам идею о том, как автоматизировать всю повторную конфигурацию.

Сгрузите `stage_3.mk`.