В первом варианте этой статьи на первом шаге использовался единственный скрипт, в котором вся настройка выполнялась его редактированием. После того, как пользователи высказали свои замечания, я решил разделить код и данные на уровне скриптов. Это позволяет создавать разные наборы конфигурационных данных для установки различных систем без внесения изменений в скрипты с кодом.
Скрипт с кодом для первого этапа называется
stage_1.sh
, и он запускается с единственным
аргументом, например
#
./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-хранилища FreeBSD),
/usr/ports
(дерево портов),
/src
(различные выгруженные из хранилища деревья
исходных текстов) и /share
(остальные совместно
используемые данные, резервные копии которых не нужны, например,
спул сервера телеконференций).
Новые возможности.
Это то, что вы хотите иметь сразу после загрузки новой
системы и даже до запуска второго этапа. Причина отказа от
создания и перехода в chroot-окружение новой системы во время
первого этапа и простой установки всех моих любимых портов
заключается в том, что теоретически и практически существуют
проблемы начальной загрузки и целостности: на первом этапе работает
ваше старое ядро, однако в chroot-окружении содержатся новые
двоичные файлы программ и файлы объявлений. Если новые
программы используют новый системный вызов, то они будут
завершаться SIGSYS, Плохой системный вызов
, так
как старое ядро не поддерживает этот новый вызов. Я наблюдал
и другие проблемы при попытке построения
порта lang/perl5.8
.
Перед тем, как запускать 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
. Даже если никаким файлам объединение не
требуется, он выведет сообщение и в конце сделает запрос
no
Пожалуйста, ответьте no
или просто нажмите
Enter. Причина в том, что
mergemaster
оставит несколько файлов нулевой длины в
каталоге /var/tmp/temproot.stage1
, которые позже
будут скопированы в новую систему (в случае, если их там еще нет).
После этого mergemaster
перечислит
установленные им файлы и уточнит, стоит ли генерировать новый
login.conf
:
Ответ не имеет значения, так как stage_1.sh
будет запускать cap_mkdb(1) в любом случае.
Вот авторский файл
stage_1.conf.default
, который вы должны
потом существенно модифицировать. В комментариях даётся достаточно информации о том,
что необходимо изменить.
Скачайте
stage_1.conf.default
.
При работе этот скрипт устанавливает систему, которая при загрузке предоставит:
Унаследованные списки пользователей и групп.
Подключение к Internet по Ethernet с использованием межсетевого экрана.
Правильный временной пояс и NTP.
Другие более мелкие конфигурационные параметры, например,
/etc/ttys
и inetd
.
Другие функции готовы к настройке, но не будут работать, пока не будет завершён второй этап. Например, мы скопировали файлы для настройки печати и X11. Однако для печати, скорее всего, необходимы приложения, отсутствующие в базовом комплекте системы, например, такие как PostScript®. X11 не будет работать, пока мы не откомпилируем сервер, библиотеки и программы.
Этот, и другие документы, могут быть скачаны с http://ftp.FreeBSD.org/pub/FreeBSD/doc/.
По вопросам, связанным с FreeBSD, прочитайте
документацию прежде чем писать в
<questions@FreeBSD.org>.
По вопросам, связанным с этой документацией, пишите в рассылку
<doc@FreeBSD.org>.