DragonFlyBSD: Установка и первичная настройка — Наш Блогосайт: Linux и «лирика»

Автор: Алексей Федорчук
2005.12.08

Генеральный путь для получения дистрибутива DragonFlyBSD, к сожалению (для обитателей необъятных просторов нашей Родины, в массе своей хорошим коннектом не избалованных) — один-единственный: из Сети. Правда, в утешение можно сказать, что там он доступен в нескольких вариантах.

Содержание

Получение дистрибутива
Подготовительные мероприятия
Терминологические замечания
Варианты установки
BSD Installer: установка
Интермедия: стратегия дисковой разметки
BSD Installer: конфигурирование
Дополнительные настройки
Впечатления
Ссылки

Любое знакомство с новой ОС, даже проводимое в сугубо экспериментальных целях, начинается с ее установки. А установка требует предмета оной — то есть дистрибутива. Вот с получения дистрибутива мы и начнем.

Получение дистрибутива

Первый — это официальный релиз DragonFly (текущая версия — 1.2), доступный на ftp-сервере проекта и ряде его официальных и неофициальных зеркал (список проверенных лично мною приведен в разделе ссылок.

Второй вариант — это так называемые Preview-версии, которые могут быть не вполне стабильными (но, судя по опыту, вполне пригодны для настольного использования.

Третий вариант — это текущие снапшоты проекта, предназначенные исключительно для разработчиков и тестировщиков. Отличительная из особенность — сборка с использованием библиотеки libc5 (прочие варианты основаны на libc4).

Ранее стабильная версия DragonFly собиралась посредством компилятора gcc-2.95. Однако ные повсеместно используется gcc-3.4.X.

Наконец, есть и четвертый вариант дистрибутива — в сборке от GoBSD, сайта компании, специально созданной для дистрибуции этой ОС и поддержки ее пользователей (и вообще формирования сообщества). Этот вариант носит имя GoBSD Distributions Preview и основан на одном из оригинальных стабильных снапшотов проекта, но несколько отличается комплектацией. В частности, он содержит тарбалл дерева pkgsrc, заимствованный из проекта NetBSD, и пакет bootstrap-pkgsrc, адаптирующий эту систему пакетного менеджмента для использования в DragonFly.

Надо заметить, что в текущей версии сборки от GoBSD (т.н. GoBSD Preview 2) были отмечены некоторые мелкие, но неприятные особенности, как-то: ошибки инсталлятора при разбиении диска, при некоторых условиях — некорректное завершение работы установленной системы, и так далее. Так что предпочтение все-таки следует отдать снапшотам с зеркал проекта DragonFly.

Все описанные варианты дистрибутива доступны в Сети в виде iso-образов, сжатых утилитой bzip2 или, реже, gzip. Так что по получении такого файла его следует развернуть (посредством bunzip2 или gunzip, соответственно), «сболванить» любым доступным способом — и можно приступать к установке. Но сначала —

Подготовительные мероприятия

Прежде всего желательно сверить свои возможности, то есть наличное «железо», с потребностями новой ОС. Запросы DragonFly к оборудованию — примерно те же, что и у FreeBSD, как и совместимость с оным — повторюсь, что если отличия и есть, то в лучшую сторону. То есть все более-менее стандартное «железо» поддерживается, устройства, ориентированные на применение исключительно в Windows (win-модемы и win-принтеры) — не поддерживаются, со всякого рода экзотикой — как повезет. Однако с устройствами, критичными именно для установки — дисковыми контроллерами, видеокартами и т.д., — проблем быть не должно. Подробный список заведомо поддерживаемого оборудования можно найти на одной из страниц DragonFlyBSD Wiki — Supported Hardware

Интересно, что в DragonFly уже на стадии установки поддерживаются любые USB-накопители и ряд «чуждых» файловых систем (включая все варианты FAT и ext2/ext3. То есть если заранее озаботиться этой задачей и разместить нужное на флэшку или мобильный винчестер, то можно в ходе инсталляции читать, например, документацию, в том числе и русскоязычную. А можно даже записывать свои впечатления о ходе установки…

Поскольку наша инсталляция DragonFly, скорее всего, — экспериментальная, по умолчанию предполагается наличие на диске иной операционной системы — какого-либо представителя BSD-клана, одного из дистрибутивов Linux или даже, не к ночи будь помянут, Windows. Конечно, хорошо было бы устанавливать новую систему на отдельный винчестер — но такая возможность предоставляется не всегда. Так что будем исходить из того, что на диске имеются разделы с некими данными, которую следует сохранить.

Программа установки DragonFlyBSD (BSD Installer) в современном ее виде допускает инсталляцию этой системы либо на диск целиком, либо на существующий раздел (слайс, в BSD-терминологии), имеющий идентификатор типа файловой системы 165 в десятичном исчислении (приписанный операционной системе FreeBSD). Конечно, при наличии неразбитого дискового пространства и минимум одной свободной позиции в MBR под первичный раздел (или просто существующего раздела, которым вы готовы пожертвовать на благо DragonFly) это можно обойти — и в следующей части этой статьи я расскажу, как. Однако пользователям, не имевшим ранее дела с программой fdisk от BSD-систем, лучше озаботиться созданием такого раздела заранее. Что легко сделать из Linux — если такового не установлено, то просто загрузившись с любого дистрибутива LiveCD, вызвать fdisk, создать его средствами первичный раздел и присвоить ему нужный идентификатор (в шестнадцатеричном виде, привычном пользователями Linux, он будет равен A5).

Выше я говорил о необходимости минимум одной свободной (или освобождаемой при жертвоприношении раздела) записи в MBR под первичный раздел. Это — почти обязательное требование. Теоретически, начиная со снапшотов конца 2004 г., DragonFly можно поставить и с логический раздел Extended Partition. Однако это уж точно придется делать вручную — BSD Installer такового просто не увидит…

И еще очень важно знать, какие именно первичные разделы (в том числе и объявленные как расширенные и содержащие логические тома) на диске задействованы под файловые системы Windows или Linux, иначе их очень легко будет уничтожить при разметке слайса для DragonFly.

Сколько места выделить под новую ОС — зависит опять-таки от возможностей и потребностей. Сама по себе базовая система DragonFlyBSD очень компактна, и занимает немного больше 200 Мбайт. Однако в это число не входят ни исходники системы, ни дополнительное программное обеспечение, устанавливаемое из пакетов или собираемое из портов, ни, тем более, исходники для работы последней. И потому минимальный рекомендуемый объем дискового пространства в документации определяется примерно в 6 Гбайт. А для того, чтобы в полной мере оценить прелести системы портов или pkgsrc, этих гигабайт желательно иметь по крайней мере 10. И это — не считая пользовательских данных — сколько места отвести под них, вы знаете лучше меня.

И, наконец, последнее: перед загрузкой с инсталляционного диска установите в BIOS своей машины время по Гринвичу (GMT или UTC). Даже при отсутствии постоянного подключения к Сети это даст некоторые дополнительные удобства. Ну а при наличии — вы получите в свое распоряжение личную службу точного времени.

Терминологические замечания

Пользователям, не имевшим ранее опыта общения с BSD-системами, следует до начала установки внимательно ознакомиться с правилами номенклатуры дисковых накопителей и их разделов, принятых в ОС этого семейства, а также особенностями BSD-стиля дисковой разметки. Вопросы эти подробно рассмотрены в любой книге или руководстве по FreeBSD (и в DragonFly Handbook). Так что здесь остановлюсь на них вкратце.

Дисковые накопители с ATA-интерфейсом (точнее, конечно, не накопители, а файлы соответствующих устройств, но для нас это сейчас не важно) в DragonFly (как и во FreeBSD) именуются так (табл. 1).

Таблица 1. Номенклатура дисковых накопителей

ad0	Мастер на 1-м канале
ad1	Слейв на 1-м канале
ad2	Мастер на 2-м канале
ad3	Слейв на 2-м канале

В DragonFly по умолчанию принята т.н. статическая нумерация дисковых устройств: то есть файл устройства Slave на 2-м канале будет носить имя ad3, даже если он является единственным дисков в машине.

Как известно, диск может быть разбит на 4 первичных раздела. В BSD-терминологии они обычно именуются слайсами (slices), хотя в DragonFly этот термин не проводится последовательно, тем не менее, имена соответствующих устройств будут такими (табл. 2).

Таблица 2. Номенклатура первичных разделов (слайсов)

ad0s1	1-й слайс
ad0s2	2-й слайс
ad0s3	3-й слайс
ad0s4	4-й слайс

Обращаем внимание — слайсы, в отличие от дисков, нумеруются, начиная с единицы. Нумерация слайсов определяется не порядком их создания, а номером записи в таблице разделов MBR: то есть на диске может существовать только единственный слайс ad0s4 (другое дело — зачем это нужно), прочие теоретически возможные слайсы при этом будут помечены как UNUSED (неиспользуемые).

Наконец, внутри слайса создаются разделы под собственно файловые системы BSD (partitions в терминологии FreeBSD), или подразделы (subpartitions), как они называются в DragonFly: это — некие аналоги логических разделов в Windows и Linux. В отличие от FreeBSD, в DragonFly слайс может содержать до 16 подразделов, имена соответствующих им файлов устройств маркируются литерами латинского алфавита — ad0s1a и так далее. Назначение первых трех подразделов жестко фиксировано: они предназначены для корневой файловой системы, раздела подкачки и описания слайса целиком, прочие же могут использоваться под отдельные ветви файловой системы, типа /usr, /var и так далее (табл. 3)

Таблица 3. Номенклатура подразделов (subpartitions) слайса

ad0s1a	/ — корень файловой системы
ad0s1b	раздел подкачки (swap)
ad0s1c	запись таблицы, зарезервированная за описание слайса целиком
ad0s1d … ad0s1k	подразделы для отдельных ветвей файлового древа

Слайс может быть размечен как единственный подраздел — именно так происходит при автоматической разметке соответствующей утилитой disklabel; впрочем, в ходе инсталляции пользователю, скорее всего, дела с ней иметь не придется. В этом случае к нему нужно обращаться так: ad0s1c (вот зачем нужна зарезервированная запись в таблице разделов). А может и не содержать подразделов вообще — и тогда его именем будет просто ad0s1. Именно таким образом могут выглядеть в ОС BSD-семейства разделы, несущие чуждые ей файловые системы (от Windows или Linux).

На иллюстрациях к последующим разделам статьи можно будет увидеть дисковое устройство с именем da0. В принципе, имена типа da# соответствуют винчестерам со SCSI-интерфейсом. Таковых в обычной пользовательской машине, скорее всего, нет. Однако накопители с любым интерфейсом, кроме ATA, также предстают перед системой в качестве винчестером SCSI, в том числе и столь распространенные ныне флэшки, карты памяти цифровых камер, внешние диски, подключенные к USB или FireWire (почему так — тайна сия велика есть). Так вот, для подготовки рисунков, иллюстрирующих процесс дисковой разметки, я манипулировал с самой обычной флэшкой — не на рабочем диске же было это делать? Хотя в принципе скриншоты консоли в DragonFly можно было бы сделать даже во время первичной инсталляции — и со временем я надеюсь показать, как (хотя, наверное, и не в этой статье).

И последнее, имеющее отношение к терминологии. Пользователь Linux уже давно привык к разнообразию файловых систем, поддерживаемых этой операционкой в качестве «родных» (native). Однако в DragonFly в роли нативной выступает одна-единственная файловая система — UFS, принятая также во FreeBSD (Unix File System, хотя под этим именем известны и файловые системы иных операционок, отличные по устройству от данной). Теоретически с конца 2004 года поддерживается и ее усовершенствованный, 64-разрядный, вариант — UFS2 («умолчальная» файловая система FreeBSD 5-й ветки), однако практически ею можно воспользоваться только при ручной установке — BSD Installer еще ничего не знает о ее существовании.

Варианты установки

Установочный диск DragonFly — загрузочный, несет на себе инсталлятор собственной конструкции. Кроме того, он являет собой полноценный LiveCD, что допускает выполнение всех необходимых действий, предваряющих установку. Однако начну по порядку.

На первой стадии загрузки появляется обычное для FreeBSD меню выбора режимов загрузки — «умолчального», с отключенным ACPI, в однопользовательском режиме, и так далее. Отличие только в логотипе — стрекоза вместо демона с вилами. Никаких проблем с загрузкой на подручных конфигурациях (весьма, нужно сказать, разнообразных) не возникает. В отличие, опять же, от FreeBSD, которая в «умолчальном» режиме категорически отказывалась грузиться на моей Toshiba, а при отключении ACPI грузилась через раз.

В ходе загрузки файловая система установочного CD монтируется как корневая в оперативной памяти. Для всякого рода установочных действий в ней предназначается каталог /mount.

По завершении загрузки системы поступает предложение авторизоваться. Возможных аккаунтов — два: root и installer, оба беспарольные. Выбор того или иного предопределяет дальнейшие действия — впрочем, почти в любой момент времени можно переавторизоваться.

Аккаунт root предназначен для ручной установки системы. После его регистрации появляется приглашение командной строки (полноценный tcsh), из которой и выполняются все необходимые действия, как то:

создание первичного дискового раздела для установки DragonFly (слайса, в терминологии FreeBSD) с помощью команды fdisk;
разбиение слайса на разделы под отдельные файловые системы DragonFly (корневую, для каталогов /tmp, /var, /usr и так далее, по потребности), а также выделение пространства под своппинг: все это делается посредством команды disklabel;
создание собственно файловых систем с помощью команды newfs;
создание в каталоге /mount подкаталогов — точек монтирования для новообразованных файловых систем;
собственно монтирование их командой mount куда следует — будущего корня в /mount, грядущих /tmp, /var, /usr — в /mount/tmp, /mount/var, /mount/usr, соответственно, и так далее;
перенос содержимого необходимых каталогов с установочного CD на подготовленные файловые системы винчестера — / в /mount, /var в /mount/var, и так далее; делается это не простым копированием, а специально для этого предназначенной утилитой cpdup;
постинсталляционные действия — установка требуемых прав доступа для некоторых каталогов, удаление ненужных более временных файлов, редактирование необходимых конфигурационных файлов (например, /mount/etc/fstab, /mount/etc/rc.conf, и так далее).

Все сказанное звучит несколько устрашающе, хотя ручная установка DragonFly не требует от пользователя чего-либо сверхъестественного. Тем более что весь процесс очень подробно описан в Handbook’е. Однако дело это весьма занудное — особенно разбиение диска на слайсы и создание разделов под файловые системы, связанные с вычислениями (fdisk и disklabel не являют собой идеала дружественности к пользователю) и требующие большой аккуратности.

Так что лучше по возможности использовать штатный установщик дистрибутива. Однако и при этом, как будет показано ниже, в некоторых случаях может возникнуть необходимость обращения к root-аккаунту для выполнения отдельных действий (например, выделения дискового раздела), и потому иметь представление о его возможностях не вредно.

И еще: дистрибутивный диск DragonFly являет собой настоящий LiveCD, и с помощью root-режима после установки системы можно выполнять всякого рода аварийно-спасательные работы, а также некоторые мероприятия по настройке уже установленной системы.

Второй вариант авторизации — под аккаунтом installer. Это автоматически вызывает штатный установщик DragonFly — BSD Installer, служащий также для начального конфигурирования системы. Именно он и будет предметом дальнейшего рассмотрения.

BSD Installer: установка

Как уже говорилось в предыдущей заметке, BSD Installer — программа, созданная в рамках самостоятельного проекта, и предназначенная для установки любых BSD-систем. Однако пока она оказалась востребованной именно для установки DragonFly (и еще — в LiveCD системе, FreeSBIE, где позволяет превратить ее в полноценную FreeBSD 5-й ветки). Однако именно в DragonFly эта программа показывает себя во всей красе.

В дистрибутиве DragonFly применяется BSD Installer с псевдографическим фронт-эндом, основанным на библиотеке ncurces. Он несколько напоминает по стилю традиционную sysinstall из FreeBSD, но производит впечатление более логичного и понятного, хотя и уступает (пока?) тому в функциональности. Тем не менее, как и sysinstall, BSD Installer — позволяет не только инсталлировать базовую систему, но и выполнить основные ее настройки, Причем не только во время первичной установки, но и, с некоторыми оговорками, и впоследствии.

Фактически BSD Installer выполняет все те действия, которые пользователь производит при ручной установке сам, но — в полуавтоматическом режиме, предоставляя через меню выбор из нескольких предопределенных вариантов. Что, понятно, менее гибко, но существенно легче. Кроме того, он допускает (до некоторого момента) отказ от совершенных действий и возврат на исходные позиции, позволяя избежать необратимых ошибок (например, при разметке диска).

Для начала, сразу после регистрации с аккаунтом installer, установщик предлагает следующие варианты выбора (рис. 1):

установка;
конфигурирование ранее установленной системы;
утилиты LiveCD;
выход в среду LiveCD;
перезагрузка.

Рис. 1. Начальное меню BSD Installer

На первом этапе установки интерес представляют пункты 1 и 3. В частности, посредством 3-го пункта можно было бы теоретически выполнить разбиение диска, однако в настоящее время здесь допускается только создание первичного раздела (BSD-слайса) на весь диск целиком. Как обойти эту сложность — я скажу чуть позже.

А пока обратимся к первому пункту — установке системы, следующим шагом подтвердим свой выбор — и попадаем в меню выбора диска (рис. 2).

Рис. 2. Меню выбора диска

Поскольку мы предположили, что таковой имеется в единственном экземпляре, выбирать особенно не из чего. А вот дальше предлагается создать на диске раздел под DragonFly, и здесь выбор уже есть: использовать под установку DragonFly диск целиком (entire disk) или его часть рис. 3). Так как мы не собираемся отказываться от ранее установленной системы, первый вариант нас, скорее всего, не устраивает — хотя при нем все происходит очень просто (почему я говорил о желательности отдельного диска для DragonFlyBSD. Да и второй тоже походит не во всех случаях: штатными средствами можно создать слайс только на все оставшееся неразбитым пространство.

Рис. 3. Выбор типа разбиения диска

Если, однако, мы готовы отдать все остатки диска на растерзание DragonFly, все просто: соглашаемся со вторым вариантом, и, после подтверждения уверенности в своей правоте (рис. 4), получаем BSD-слайс соответствующего размера.

Рис. 4. Запрос на подтверждение правильности выбора раздела

Перед положительным ответом на вопрос с рис. 4 неплохо еще раз подумать: все содержимое раздела, если оно имелось, будет потеряно (произойдет не просто изменение типа раздела, но и «обнуление» его начального сектора командой

$ dd if=/dev/zero of=/dev/ad#s?

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

Если же часть неразбитого пространства требуется сохранить таковым для последующего использования в каких-либо целях (и если имеется резерв записей под первичные разделы), придется действовать иначе. Благо, оказывается, что установочный LiveCD нашей системы сохраняет свои «живительные» свойства и после запуска инсталлятора. Предоставляя в расположение пользователя шесть свободных виртуальных консолей из восьми возможных (на второй запущен установщик, на первую выводятся его сообщения). И можно, перейдя в любую из них, авторизоваться там как root (по прежнему без пароля), создать нужный раздел вручную — с помощью программы fdisk. Правда, в BSD-системах этот инструмент не являет собой верх удобства, требуя (даже в интерактивном режиме) явного задания начала и конца раздела в физических (по 512 байт) блоках. И, соответственно, некоторых вычислений.

Правда — вот что LiveCD животворящий творит — и вычислитель оказывается под рукой, в лице простой в использовании утилиты bc. А поскольку лимит консолей далек от исчерпания — никто не мешает запустить его параллельно и выполнить необходимые расчеты. После чего командой

$ fdisk -i /dev/ad0

создать раздел нужного размера на неразбитом пространстве в интерактивном режиме — то есть последовательно отвечая на вопросы программы.

Сначала, после вывода информации о текущем разбиении диска, последует вопрос, а хотим ли мы изменить первый из первичных разделов. Вероятно, ответ должен быть отрицательным — ибо этот раздел, скорее всего, занят под Windows, Linux или иную BSD (впрочем, соответствующие сведения будут выведены на экран, нужно только внимательно их читать).

Затем аналогичный вопрос будет задан касаемо второго и последующих первичных разделов (как известно, более четырех их на одном диске быть не может). Отвечать также следует отрицательно — до тех пор, пока вопрос не коснется раздела, помеченного в экранном виде как UNUSED (неиспользованный) — это и будет то самое свободное дисковое пространство, не приписанное еще ни к одной ОС. Или — существующего раздела, обреченного в жертву. Тут мы соглашаемся на внесение изменений — совершаем их, отвечая на новую серию вопросов.

Первым из них будет запрос на ввод, второй- это ручное создание слайсов (при существующей уже разметке сначала будет вопрошаемо, а хотим ли мы этого — с отрицательным ответом по умолчанию). Для этого сначала запрашивается идентификатор типа файловой системы (по умолчанию стоит ID существующего раздела или 0 — для неразмеченного пространства). Тут следует руками указать его десятичное значение (165 — идентификатор FreeBSD/DragonFly). Затем запрашивается стартовый сектор — очевидно, первый сектор этого раздела, — и размер размер раздела в блоках по 512 байт — его следует вычислить посредством bc.

После этого будет предложено точно специфицировать начало и конец слайса. Если отказаться — они будут взяты из предыдущих определений, если согласиться — нужно будет указать первые и последние цилиндр, головку, сектор. Каковые и будут выведены в виде

sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
start 0, size 260000 (126 Meg), flag 0
beg: cyl 0/ head 0/ sector 1;
end: cyl 126/ head 60/ sector 32

Подтвердив свои действия положительным ответом на вопрос

Are we happy with this entry? [n] y

следует отказаться от изменений остальных записей таблицы разделов (если таковые еще остались). После чего будет задан последний вопрос — подтверждение на выполнение собственно разметки:

Do you want to change the active partition? [n]

При положительном ответе на него все сделанные изменения вступят в силу (и на ранее размеченном диске при ошибке можно будет распроститься с его содержимым). Так что следует предварительно просмотреть все ранее введенное — благо, это легко сделать пролистыванием буфера истории виртуальной консоли, перейдя в режим его просмотра, нажав клавишу ScrollLock (а сам просмотр выполняется как клавишами PageUp/PageDown — поэкранно, так и стрелками Up и Down — построчно). И при обнаружении ошибки отказаться от изменений и запустить команду fdisk по новой. Впрочем, из нее можно в любой момент выйти без последствий и стандартным образом — комбинацией клавиш Control>+C.

Необходимость в ручном разбиении диска возникнет и на «чистом» диске в том случае, если мы хотим отдать под DragonFly более одного первичного раздела (в ближайшей интермедии я расскажу, почему это может быть целесообразно). В этом случае второй слайс создается точно также, как и первый.

Порядок создания дисковых разделов средствами fdisk подробно описан на ее man-странице — благо она во время инсталляции доступна с LiveCD. А вообще-то, как я уже говорил, если поступиться принципами, проще всего создать слайс (и тем более слайсы) для DragonFly заблаговременно — средствами любого наличного LiveCD с Linux. А при наличии установленной FreeBSD это легко сделать средствами ее sysinstall.

По завершении ручной разметки слайса (или слайсов) нужно сделать его доступным для BSD Installer’а. Для чего придется вернуться в его начальное меню, выбрать в нем пункт Exit to LiveCD (см. рис. 1) и авторизоваться как installer заново.

Тем или иным способом создав первичный раздел, выбираем его в соответствующем меню для разбиения на подразделы (subpartitions). Вариант, предлагаемый по умолчанию, таков (рис. 5):

/ — 256 Мбайт
swap — 1024 Мбайт
/var — 256 Мбайт
/tmp — 256 Мбайт
/usr — 8192 Мбайт
/home — *, то есть все остальное

Рис. 5. Создание дисковых подразделов, нормальный режим

Эта схема вполне разумна, и для пользователя, ранее с BSD системами дела не имевшего, может быть принята. Если он, тем более, собирается пользовать DragonFly сугубо для экспериментальных целей. Разве что при недостатке места уменьшить раздел под /usr (вплоть до минимума в 4096 Мбайт — почему я и говорил ранее, что инсталляция DragonFly требует около 6 Гбайт дискового пространства) и swap (при памяти от 512 Мбайт он практически не задействуется).

Однако если планируется (или хотя бы допускается) применение DragonFly в качестве «боевой» платформы — к вопросу разметки подразделов нужно подойти со всей ответственность. Собственно, из рук вон плохая дисковая разметка — чуть ли не единственная причина, делающая неизбежной переустановку «с нуля» любой операционки POSIX-семейства (все другие проблемы могут быть решены терапевтическими методами), и DragonFly тут не исключение. Почему и дело это выделено в отдельное производство — этой теме посвящен специально следующий раздел.

Пока же только замечу, что кроме нормального режима разметки подразделов, проиллюстрированного на рис. 5, существует еще и т.н. «режим эксперта» (рис. 6). В котором, помимо указания размера разделов, для отдельных из них можно еще и включить или выключить режим Softupdates, а также определить индивидуально размер блока и фрагмента файловой системы. Процедура создания последней (то есть исполнение команды newfs или, в терминах DOS/Windows, форматирование) совмещена в меню BSD Installer с разметкой разделов и осуществляется в один прием с ней — по выбору Accept and Create, вызывающим последнее предупреждение, с которым «пользователь соглашается и форматирование совершается».

Рис. 6. Создание дисковых подразделов, режим эксперта

По окончании создания файловой системы (а для больших разделов он может затянуться) задается вопрос — приступить ли к переносу файлов базовой системы. В отличие от большинства дистрибутивов Linux (а также FreeBSD и прочих BSD-систем), при этом не происходит никакой распаковки архивов или развертывания пакетов. Просто файловая система LiveCD (находящаяся в этот момент, напомню, в оперативной памяти) со всем ее содержимым — каталогами, подкаталогами и отдельными файлами) копируется на соответствующие разделы ранее созданного слайса, подмонтированные в виртуальный каталог /mnt: корень — в корень, /usr — в /usr, и так далее. Правда, не обычной командой cp, а специально для того предназначенной утилитой cpdup, обеспечивающей полную идентичность файловой структуры источника и приемника (включая воспроизведение жестких и символических ссылок, файлов устройств, атрибутов доступа и принадлежности). Это важно помнить при аварийно-спасательных работах, о чем будет подробнее говориться в следующей статье.

Так вот, при согласии пользователя (а куда ему деваться — иначе никакой установки и не будет) начинается такой процесс переноса файлов. Причем, в отличие от sysinstall из FreeBSD, никакого выбора пакетов базового комплекта перед этим не предлагается. И это, конечно, минус — в результате пользователь оказывается «счастливым» обладателем, например, системы безопасности Kerberos или info-документации, возможно, на фиг ему не нужных. Да и скорости переноса файлов (должен сказать, не быстрой) это никак не способствует. Но уж что выросло — то выросло… А от ненужных частей базовой системы (как тот же Kerberos) можно будет избавиться в дальнейшем — об этом речь пойдет в следующей статье.

Под занавес начальной установки — предложение установить загрузчик, точно такой же loader, что и во FreeBSD. И установить его можно опять же в загрузочный сектор диска или слайса. В первом варианте — прописывание BSD’шного loader’а в MBR диска — он позволяет осуществить мультисистемную загрузку с любого первичного раздела (на котором собственные средства загрузки имеются, конечно). Второй же вариант потребует обеспечения загрузки DragonFly средствами Lilo или GRUB, что сделать не сложнее, чем для FreeBSD, но к теме нашего сегодняшнего разговора отношения не имеет. Тем более, что BSD Loader, не смотря на свою внешнюю простоту и непрезентабельность, успешно справляется с загрузкой своей родной операционки (еще бы!), а также Windows, Linux и любой другой BSD. При условии, что их собственные загрузчики лежат в загрузочных секторах первичных дисковых разделов — но и об этом разговор еще впереди.

Собственно установка окончена — предлагается либо перейти к конфигурированию системы, либо перезагрузиться (можно и вернуться на первую страницу инсталлятора). Нас, конечно, будет интересовать вопрос начального конфигурирования. Но сначала — обещанная

Интермедия: стратегия дисковой разметки

А вот разделить по Божьи —
Тут очень расчет нужон.
Александр Галич

У пользователя со стажем работы, например, в Linux или какой-либо BSD-системе, скорее всего, сложились уже собственные представления об идеальной схеме разметки разделов. И представления эти, с некоторыми коррективами, вполне применимы и к DragonFly. Однако позволю себе осветить свои представления по этому вопросу — во-первых, ввиду важности, а во-вторых — потому что особенности текущего состояния BSD Installer делают ошибки в дисковой разметке весьма трудноустранимыми его средствами. Ну и вообще для DragonFly этот вопрос имеет ряд специфических аспектов.

Итак — сакраментальный российский вопрос — что делать? (при разметке диска), и кто виноват? (если «опять все не получилось!» — как сказал в отчаянии хирург, кромсая большим медицинским скальпелем внутренности пациента после неудачной операции аппендикса).

Правда, на второй вопрос ответить легко: виноват, в 99 случаев из ста, сам хирург, то есть пользователь, устанавливающий систему. А вот первый — это действительно вопрос, сродни Гамлетовскому.

Существует широко известный стандарт FHS (Filesystem Hierarchy Standart), описание которого доступно в русском переводе благодаря Виктору Костромину. Хотя его конкретная реализация и не столь уж общепризнанна, как это кажется его авторам (или, скорее, как бы им хотелось), положенные в его основу принципы вполне можно взять на вооружение при определении стратегии дисковой разметки.

В основу FHS положена пара альтернатив:

противопоставление неизменяемых и изменяемых файловых систем;
обособление файловых систем неразделяемых и разделяемых.

Контент неизменяемых файловых систем создается при инсталляции ОС ее первичной настройке, и в дальнейшем не претерпевает модификации. По крайней мере, без участия администратора — а тот должен прибегать к ней лишь при наличии веских причин. Типичный пример — корневая файловая система. Такая ее ветвь, как /usr, также по хорошему должна бы быть неизменяемой, и, как мы увидим дальше, в BSD, в отличие от Linux, это легко реализовать.

Изменяемые файловые системы содержат не только пользовательские данные (постоянное модифицирование которых очевидно). Это и такие ветви, как /tmp и /var: ведь в эти каталоги запись осуществляют не столько сами пользователи, сколько запускаемые ими программы, наследующие в подавляющем большинстве случаев эффективные ID своих хозяев.

К изменяемым ветвям файлового древа можно отнести также каталоги /usr/local и, в ряде случаев, /usr/X11R6. Конечно, инсталляция дополнительного программного обеспечения (для которого и предназначен /usr/local) — обычно привилегия администратора (и это подчеркивается атрибутами доступа к этим каталогам). Однако у пользователя, ведущего активную софтверную жизнь (а таких среди истинных POSIX’ивистов — большинство) это происходит достаточно часто. Что же касается /usr/X11R6 — то теоретически, по стандарту FHS, он предназначен только для штатных компонентов оконной системы X — все X-приложения должны помещаться в каталоги /usr, /usr/local или /opt (в зависимости от используемой системы пакетного менеджмента). Однако последний в BSD-системах не используется вообще), а X-приложения, например, устанавливаемые из системы портов и коллекции пакетов FreeBSD (используемых также в DragonFly) распределяются между ветвями /usr/X11R6 и /usr/local весьма причудливым образом. В альтернативной же системе пакетного менеджмента — pkgcrs, заимствованной из NetBSD, — в число изменяемых попадают также каталоги /usr/pkgsrc (собственно дерево управления этой системой) и /usr/pkg, куда помещаются собранные бинарники, в том числе и Иксы — в подкаталог /usr/pkg/xorg (каталог /usr/X11R6 при этом не используется).

Я подробно остановился на альтернативе неизменяемости/изменяемости потому, что она важна для пользователя вообще и, как станет ясным в дальнейшем, для пользователя DragonFly в особенности. Что же касается неразделяемости/разделяемости (то есть доступа к каталогам только с локальной машины или также и с удаленных), то эта альтернатива имеет значение в основном для администратора сети, и пользователю десктопа мало интересна. Поэтому замечу только, что к неразделяемым ветвям файловой иерархии относится корень локального файлового древа, тогда как такие ветви, как /usr, /usr/X11R6, /usr/local и аналогичные — должны быть разделяемыми, для обеспечения запуска приложений с удаленных машин.

На мой взгляд, для настольного пользователя более важна третья альтернатива — каталогов восстановимых и невосстановимых. Контент первых в особо критических случаях легко (и относительно быстро) восстанавливается с дистрибутивного носителя. Полное же восстановление содержания вторых либо невозможно в принципе, как пользовательских данных (при любой практически выполнимой стратегии резервного копирования без потерь тут не обойтись, хотя минимизировать их можно), либо сопряжено с затратами времени, трафика и, в конечном счете, денег.

Специфика DragonFly (и других BSD и дистрибутивов Linux, использующих родственные системы управления пакетами — но в нашем случае она выражена ярче всего) такова, что в ней выделяется четыре градации ветвей файловой иерархии по степени восстановимости контента:

легко восстановимые с дистрибутива — корневая файловая система и каталог /usr — только туда помещаются компоненты базовой системы (то, что во FreeBSD называется Distributions);
восстановимые с затратами времени — каталоги для дополнительных программ, не входящих в базовый комплект — /usr/local, /usr/X11R6 или /usr/pkg (в зависимости от используемой системы пакетного менеджмента);
восстановимые с затратами времени и трафика — /usr/src (исходники базовой системы), /usr/ports или /usr/pkgsrc (собственно древа систем управления пакетами), а также ветви последних — /usr/ports/distfiles или /usr/pkgsrc/distfiles (исходники программ для сборки их из портов); их специфика — в том, что они а) регулярно обновляются (например, через cvs), то есть в принципе невосстановимы с дистрибутива (а в дистрибутива DragonFly их просто нет) и б) содержат личные данные (файлы конфигурации ядра, собственноручно модифицированные Make-файлы и тому подобное);
практически невосстановимые пользовательские данные (каталог /home со всеми его ответвлениями).

Вот на основе интерференции первой и третьей альтернатив можно и строить стратегию приближения к идеальной схеме разметки диска пользовательского десктопа. Повторю, только его — достижение идеала разметки на сервере потребует много чего еще.

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

Первый принцип нашей схемы разметки — вычленение за пределы корневой файловой системы всего, чего можно. Точнее, всего ненужного для работы в однопользовательском режиме. Принцип этот интуитивно понятен и общепринят на практике. Ведь чем меньше корневой раздел — тем быстрее он будет восстановлен после сбоя, что позволит перейти к «ремонту» прочих файловых систем при необходимости (ну и к прочим восстановительным работам).

То есть каталог / — первый кандидат на обособление в отдельном разделе слайса. И остаться в нем должны только ядро (/kernel) и такие ветви, как /boot, /etc, /dev, /modules, /root, /bin, /sbin - то, без чего запуск и функционирование системы окажутся невозможными.

Маленькое отступление: Внимательный читатель (и к тому же пользователь Linux по натуре) наверняка задаст вопрос: пардон, а где же здесь общесистемные библиотеки? В частности, glibc, без которой ничего не работает. Ибо в Linux предназначенный для них каталог находится непосредственно в корне файловой системы (/lib), которого в списке кандидатов на исконность корней не видно. Забегая впред, отвечу: файлы главной системной библиотеки в BSD-системах (здесь она величается просто — libc) размещаются в каталоге /usr/lib, который мы в следующем абзаце отчленим от корня и поместим на отдельный раздел.

Но как же тогда будут работать бинарники из каталогов /bin и /sbin в однопользовательском режиме, когда никакие другие файловые системы, кроме корневой, не монтируются? — задаст следующий вопрос пользователь, просветленный Linux’ом. Очень просто: в DragonFly все системные утилиты из каталогов /bin и /sbin (а их содержимое — и есть системные утилиты, просто в первом лежат те, к которым иногда прибегает и простой пользователь, а утилиты из второго ему без надобности), слинкованы с libc статически, и в наличии ее не нуждаются.

Реплика в сторону: раньше (включая все версии 4-й ветки) так было и во FreeBSD, но в 5-й ветке бинарник из каталогов /bin и /sbin линкуются динамически, а статически слинкованные утилиты «на всякий пожарный случай» располагаются в каталоге /restore.

Так что от выноса на отдельный раздел неизменяемого (и легко восстановимого) каталога /usr — вреда ни малейшего. А заодно отделяем и изменяемые каталоги — /tmp и /var, ну и конечно же /home. То есть пока мы движемся в русле схемы разметки, предложенной по умолчанию. Но вот теперь пойдут разночтения. Потому что /usr в этом случае оказывается сборной солянкой неизменяемых и изменямых подкаталогов, к тому же — разной степени восстановимости. Так что с безжалостностью эсторского палача-расчленителя по прозвищу Голый Дьявол приступим к его разделу.

Для начала вычленяем из древа /usr его заведомо изменяемую часть — каталог /usr/obj: это то место, куда по умолчанию помещаются промежуточные продукты компиляции ядра и базовой системы, как будет показано в следующей статье, роль его весьма велика.

Теперь — умеренно восстановимые части, /usr/local и /usr/X11R6, а при использовании системы pkgsrc — также и /usr/pkg. Это обеспечит нам сохранность инсталляций дополнительных программ при переустановке базовой системы.

Правда, не до конца: для обеспечения контроля их зависимостей потребуется еще и сохранить базу данных установленных пакетов. Так что «умолчальный» ее каталог /var/db/pkg также логично было бы вынести на отдельный раздел. Хотя, если это делать не хочется (а так оно и есть — больно уж много чести для массива данных в десяток мегабайт, эту сохранность можно обеспечить иными способами (о них речь пойдет в статье про управление пакетами), не говоря уже о простом backup.

Теперь отрезаем изменяемые и трудновосстановимые части — /usr/ports и (или) /usr/pkgsrc. Лишним резоном к чему будет специфика из содержимого — очень большое число (многие десятки тысяч) очень маленьких (по несколько байт) файлов. И потому из состава этих ветвей целесообразно вытащить их менее специфичные и наиболее «затратные» (в том числе и финансово:-) компоненты — /usr/ports/disfiles (или, соответственно, /usr/pkgsrc/distfiles). На чем сердце расчленителя может успокоиться — вряд ли на индивидуальной машине имеет смысл дробить на подкаталоги /home или /var (хотя на большом сервере это, скорее всего, необходимость).

В итоге получаем максимальное целесообразное количество отдельных ветвей файловой системы — 14, что вполне укладывается в допустимый максимум слайса DragonFly (16 подразделов). Впрочем, очевидно, что все перечисленное и не понадобится: вряд ли есть смысл в использовании и системы портов, и pkgsrc. Так что реальное число ветвей сразу уменьшается на три. Ну и без отдельного раздела под /usr/X11R6 также можно обойтись в любом случае. При pkgsrc он вообще не нужен, а при использовании портов его можно оставить внутри /usr: если следить за тем, чтобы все X-приложения собирались в каталог /usr/local (как — будет рассказано в статье про управление пакетами), то /usr/X11R6 сразу станет фактически неизменяемым.

Далее, может иметь смысл помещение трудновосстановимых и невосстановимых разделов (/usr/src, /usr/ports, /usr/ports/distfiles, /home) на отдельный слайс: именно поэтому ранее я столь подробно останавливался на том, как средствами DragonFly сделать это вручную. Смысл такого действия — облегчить полную переустановку системы в случае необходимости. Правда, надеюсь, таковой не будет — в следующей статье будет говориться и о том, как избирательно восстановить с дистрибутива только нужные ветви файлового древа. Но — береженого Бог бережет…

Итак, с количеством и назначением разделов разобрались. Теперь остается только «разделить по Божьи» между ними наличное дисковое пространство. И действительно — «тут очень рассчет нужон». Причем при рассчетах следует помнить о специфике файловой системы UFS вообще: в ней быстродействие файловых операций (и так не рекордное сравнительно с Ext2fs или ReiserFS) резко падает, как только объем свободного места становится менее 10%. Так что, как говорится, запас горба не сломит (тем более на современных-то дисках).

Для начала — вычисляем корень. Тут можно спокойно согласиться с «умолчальным» предложением в 256 Мбайт. Да и того за глаза хватит — у меня, например, в данный момент в корне (того самого размера) задействовано даже менее 50 Мбайт; ну да ладно — не будем жмотничать на важнейшем каталоге.

С предлагаемым по умолчанию объемом раздела под каталог /var я, не мудрствуя лукаво, тоже согласился (правда, у меня он обычно используется едва на 15-15%). А вот от раздела под /tmp я давно отказался: при достаточном количестве памяти (начиная с 512 Мбайт — точно, а меньше — я и забыл, когда было) в этот каталог целесообразно смонтировать файловую систему в оперативной памяти (mfs — Memory Filesystem), и при финальных настройках системы (в заключительно разделе этой статьи) мы будем исходить из этого.

Остается отпрепарировать каталог /usr. Ясно, что при предложенной выше схеме разметки 8 «умолчальных» (и даже 4 допускаемых) гигабайта для него — излишне. Подсчет объема, занимаемого «родными» подкаталогами (от /usr/bin до /usr/share) в установленной системе даст около 180 Мбайт, «чистые» Иксы добавят еще сотню. То есть при использовании портов на весь /usr можно кинуть 512 Мбайт, а при pkgsrc — сократить этот объем вдвое.

Объем промежуточных продуктов компиляции базовой системы, включая ядро, помещаемых в каталог /usr/obj, составляет, в зависимости от настроек ее условий, 500-600 Мбайт. С учетом разрастания ее в будущем — отводим под это дело 1 Гбайт. Причем при тех же 512 Мбайт ОЗУ и в этот каталог можно смонтировать файловую систему mfs, что имеет как свои плюсы, так и минусы, которые подробно будут рассмотрены в следующей статье.

Труднее всего определиться с каталогом /usr/local (или его аналогом /usr/pkg для системы pkgsrc). Требуемое под него место определяется исключительно аппетитами пользователя на дополнительный софт. У меня под /usr/local отведено 2 Гбайт — и до их исчерпания (при установленных KDE и OpenOffice) еще далеко.

Теперь исходники базовой системы. Вместе с ядром в распакованном из тарбалла (доступного на некоторых ftp-зеркалах проекта) виде они занимают около 400 Мбайт. Снапшот текущего дерева, полученный через cvs, будет несколько больше. Так что под каталог /usr/src я не поскупился бы гигабайтом — с запасом на будущее.

Как ни странно, трудно определиться также с пространством под /usr/ports (или /usr/pkgsrc). Правда, объем дерева соответствующей системы вычисляется легко — в распакованном из тарбалла виде они займут около 150 Мбайт. Однако следует учесть, что по умолчанию здесь же окажутся и промежуточные продукты сборки — распакованные исходники, объектные модули и т.д., а для pkgsrc — еще и собранные бинарные пакеты. От всего этого потом можно избавиться — однако, дабы не получить в процесс сборки KDE или OpenOffice сообщения об исчерпании дискового пространства, лучше создать под эти каталоги разделы с о-очень большим запасом. Руководство к системе pkgsrc рекомендует 5 Гбайт, однако для /usr/ports, мне кажется, хватит и двух.

Относительно /usr/ports/distfiles (или /usr/pkgsrc/distfiles) можно сказать то же самое, что и о /usr/local (или /usr/pkg): выделяемое под них пространство определяется запросами пользователя. Руководство по pkgsrc определяет полный объем исходников для этой системы в 10 Гбайт. Какой процент из входящих в pkgsrc 5 тысяч приложений потребуется именно вам — предлагается рассчитать в качестве домашнего задания. Я лично под /usr/ports/distfiles ограничиваюсь 2 Гбайт.

И, наконец, с /home все ясно. Под него отводится места а) сколько нужно, б) сколько можно или в) сколько не жалко. У меня это всегда — все оставшееся дисковое пространство (собственно, так BSD Installer и предлагает по умолчанию.

В заключение — о swap-разделе, не несущем файловой системы. Рекомендуемый его объем равен удвоенному ОЗУ, и я всегда следую этому правилу. Конечно, при объеме памяти 512 Мбайт и больше можно вообще обойтись без подкачки (или ограничиться swap-файлом, на всякий случай). Однако мы ведь решили разместить на mfs (то есть в оперативной памяти) каталог /tmp, а возможно, и /usr/obj, под что физической памяти, при некоторых услвоиях, может и не хватить. И тут в дело вступит swap — ведь для системы он вместе с физическим ОЗУ предстает в виде единой виртуальной памяти.

Казалось бы, с точки зрения быстродействия, замена дискового раздела разделом подкачки — все равно что сменить шило на мыло. Однако на самом деле это не так, и механизм виртуальной памяти DragonFly обеспечит некоторый прирост производительности и в этом случае. А кроме того, перемещение этих ветвей файлового древа в mfs обеспечивает автоматическую очистку от временных файлов при рестарте системы. Что однозначно полезно для /tmp (хотя в некоторых случаях может быть лишним для /usr/obj — но это мы обсудим в следующей статье.

Свои представления об оптимальной схеме дисковой разметки для установки DragonFly я суммировал бы так (табл. 4).

Таблица 4. Схема дисковой разметки для DragonFly

##	Раздел	Mnt	Размер	Назначение
1	ad0s1a	/	256 Мбайт	Файлы и каталоги, необходимые для старта в однопользовательском режиме
2	ad0s1b	swap	1024 Мбайт	Раздел подкачки
2	mfs	/tmp	Нет	Временные файлы
3	ad0s1d	/var	256 Мбайт	Изменяемые файлы кэшей спуллингов и т.д.
4	ad0s1e	/usr	512 Мбайт	Основная часть базовой системы
5	ad0s1f	/usr/obj	1024 Мбайт	Временные продукты компиляции базовой системы
6	ad0s1g	/usr/local	2048 Мбайт	Пользовательские программы из портов и пакетов
7	ad0s1h	/usr/ports	2048 Мбайт	Дерево системы портов
8	ad0s1n	/usr/ports/disfiles	2048 Мбайт	Исходники для сборки портов
9	ad0s1p	/home	Все, что осталось	Пользовательские данные

Прошу не рассматривать приведенную схему как догму — это лишь предложение к размышлению. Разметка диска — процесс творческий, и походить к нему нужно соответственно.

Столь дробная схема разметки полезна еще и тем, что позволяет индивидуально определить размер блока и его фрагмента для каждой файловой системы — в зависимости от специфики размещаемых на ней данных. При разметке в нормальном режиме (см. рис. 5) оба эти параметра, влияющие на производительность файловых операций, эффективность использования дискового пространства и максимально возможное количество файлов, вычисляются автоматически — исходя из объема раздела. И в большинстве случаев с этим можно согласиться. Исключение — файловая система ветви /usr/ports (или /usr/pkgsrc), Как уже говорилось, обе они образованы невообразимым количеством малюсеньких файлов. И потому для них, не зависимо от объема раздела, размеры блока и фрагмента лучше сделать поменьше — например, 1024 b 512 байт соответственно.

И еще, как можно видеть из рис. 6, режим эксперта позволяет включить или выключить механизм Softupadets (по умолчанию включено для всех файловых систем, кроме корневой). Это такая интересная штука, которая волшебным образом способствует как росту быстродействия файловых операций, так и повышению надежности файловой системы. Однако она имеет альтенартиву — чисто асинхронное монтирование, при котором производительность растет еще больше, хотя и надежность резко уменьшается. Почему оно обычно и не рекомендуется к употреблению резонными людьми. Однако при вычленении из файловой иерархии частей, в надежности заведомо не нуждающихся (в нашем случае это будут /tmp и /usr/obj), к ним вполне может быть применимо — с предварительным отключением Softupadets в режиме эксперта).

О монтировании файловых систем речь пойдет в заключительной части статьи. А более полную информацию о затронутых здесь вопросах устройства файловой системы UFS вообще поищите в материалах списка ссылок.

BSD Installer: конфигурирование

Возвращаемся к нашему основному сюжету — установке DragonFly. Как уже было сказано, следующий шаг в этом направлении — начальное конфигурирование. Конечно, его можно выполнить и в дальнейшем — либо загрузившись с того же LiveCD и выбрав в меню установщика соответствующий пункт, либо — запустив BSD Installer из уже установленной системы. Однако первое — это лишние телодвижение, а второе «из коробки» можно выполнить только после установки с диска от GoBSD. В системе, установленной со снапшотов проекта DragonFly, потребуются не вполне тривиальные действия по настройке самого installer’а:-). Так что не вижу причин, почему бы благородному дону не выполнить все возможные настройки сразу по завершении базовой установки.

Меню начального конфигурирования (рис. 7) позволяет выполнить следующее:

установить часовой пояс;
установить (или скорректировать) дату и время;
задать пароль администратора;
создать обычного пользователя;
настроить сетевые интерфейсы;
установить имя машины и домена;
настроить параметры консоли — экранные шрифты, раскладки клавиатуры, карты соответствия;
установить дополнительные пакеты.

Рис. 7. BSD Installer: главное меню конфигурирования

Большинство этих действий сводятся к ответам на вполне тривиальные вопросы — остановлюсь только на наиболее важных и интересных моментах.

При определении часового пояса (Select timezone) перво-наперво спаршивается, установлены ли «железные» часы на время по Гринчиу (UTC). И если вы последовали моему совету из вводной части, и сделали это перед инсталляцией — соглашайтесь, не пожалеете. Ну а потом остается только выбрать континент и город на нем, например, Europe -> Moscow, или Asia -> Kamchatka (это, оказывается, город такой:-)).

Процедура коррекции даты и времени очевидна, с паролем root’а также проблем нет — в DragonFly на него не накладывается никаких ограничений по минимальной длине или максимальной простоте. А вот от создания пользовательского аккаунта (Add a user) на данном этапе я бы воздержался. Как известно, наиболее простой способ локализации во FreeBSD — это задание специального атрибута пользователя, именуемого class (в нашем случае его значением будет, например, russian. И DragonFly унаследовала это понятие. Но вот задать класс пользователя на стадии установки не получится (такое поле просто не предусмотрено). Так что лучше заняться этим делом потом — с помощью одной из специальных утилит управления учетными записями (adduser или pw).

Тем не менее, если есть желание создать пользовательский аккаунт, сделать это просто: нужно только заполнить соответствующие поля (рис. 8). Нужно только иметь ввиду несколько моментов. В качестве пользовательской оболочки (login shell) по умолчанию предлагается /bin/tcsh — опять-таки соглашайтесь, альтернативой на данном этапе может быть только весьма убогая (с точки зрения интерактивности) /bin/sh. И еще — не забыть в поле Other Group Memebership вписать группу wheel — без этого новому пользователю не получить прав администратора командой su. Не повредит и членство в группе operator — оно позволит от лица обычного пользователя выполнять некоторые обыденные действия, обычно доступные только root’у (например, завершить работу системы).

Рис. 8. Создание пользовательского аккаунта

Как это в обычае для систем BSD-клана, настройка сети в DragonFly (пункт Configure network interface) выполняется не просто, а предельно просто — проще даже (если такое возможно), чем у ее матушки FreeBSD.

Для начала предлагается список настраиваемых сетевых интерфейсов (рис. 9). Первым в нем стоит тот, который соответствует наличной сетевой карте — он, собственно, и подлежит сейчас настройке. В моем случае (чипсетная сеть от ICH4) имя его fxp0, другие сетевые устройства будут иметь иное название. Например, сетевые карты неизвестного генезиса обычно определяются как ne0. При сомнении можно перейти в другую виртуальную консоль (опять вспомним, что пред нами — LiveCD) и уточнить имя требуемого интерфейса командой ifconfig.

Рис. 9. Настройка сетевых интерфейсов

Так что выбираем первый пункт списка и жмем Enter. Нас запрашивают — использовать ли DHCP-сервер или настроить сетевые параметры вручную. Если дело происходит в локальной сети предприятия, использующей DHCP (а в большинстве случаев так оно и есть), или в сети нормального «домашнего» провайдера — выбор первого очевиден (кстати, он и отмечен по умолчанию). Система автоматически отыскивает машину, выполняющую функции DHCP-сервера нашей сети, и через некоторое время выдает сетевые параметры, включая динамически присвоенный нашему хосту IP-адрес в виде, подобном такому: inet 19X.XXX.X.XXX). На чем процедура настройки первого сетевого интерфейса и заканчивается — можно выходить из данного подменю и посмотреть на прочие. Каковыми будут:

lp0 — соединение по параллельному порту;
lo0 — имитация сетевого соединения внутри локальной машины (т.н. loopback-интерфейс);
ppp0 — обычное модемное соединение через последовательный порт по одноименному протоколу (Point-to Point);
sl0 — также последовательное соединение, но по протоколу SLIP;
fait0 — интерфейс между сетями с IP-протоколами версий 6 и 4.

Интерфейсы lp0 и sl0 ныне практического значения, скорее всего, не имеют, IPv6 мало кем еще поддерживается, а ppp0 — это отдельная тема, которую я затрагивать не буду. Что же касается loopback-интерфейса, то он в принципе весьма важен — например, для запуска web-сервера на локальной машине. Однако именно он корректно настроен по умолчанию — это легко проверяется командой

$ ping localhost

в ответ на что последует серия сообщений вида

64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.029 ms

Так что можно спокойно переходить к пункту Configure hostname and domain. Действия в котором сводятся к тому, чтобы вписать в соответствующие поля имя своей машины (произвольное или по согласованию с админом — например, mydragonfle) и домена (типа mydomain.ru. Это — в сети предприятия (да и то не всегда). В сети «домашнего» провайдера никакого имени хоста и домена не потребуется.

Настройка консоли позволяет установить раскладки клавиатуры (Set keyboard map, рис. 10), экранные шрифты (Set console font, рис. 11) и, при необходимости, карты соответствия (Set screen map, рис. 12). То есть — выполнить, например, полную русификацию системы. Причем — в любых вариантах: и в традиционном для Unix’ов сочетании KOI-ввода и CP866-вывода (с требуемой картой соответствия), и просто установив шрифты и раскладки для KOI8-R (необходимость в карте соответствия при этом отпадает). Имеются в комплекте даже шрифты и раскладки для чуждой нам кодировки CP1251.

Рис. 10. Установка консольного шрифта для вывода

Шрифты, содержащих символы кириллицы, в комплекте представлены для кодировок: cp866, koi8-r и koi8-u, cp1251 и iso5 (кодировка для Sparc’ов). Для каждой кодировки имеются вариатны с матрицами от 8×8 до 8×16, а для кодировок cp866 и koi8-r имеется еще и три гарнитуры (если так можно выразиться). Что выбрать — дело вкуса и потребностей. Я последнее время остановился на шрифте koi8-r-8x16. Тем более, что, как будет показано в следующей статье, загрузка шрифта при старте — мера временная.

Рис. 11. Установка расклаки клавиатуры

Русских раскладок клавиатуры — также несколько, для кодировкок cp866 и iso5, а также две для koi8-r: весьма странная ru.koi8-r и привычная по старым (до-Windows’ным) временам ru.koi8-r.shift. Тем не менее, нынче ни с одной из этих раскладок работать неудобно, потому в дальнейшем их придется менять.

Рис. 12. Установка карты соответствия кодировок ввода и вывода

Установка карты соответствия рнужна только при различии кодировок для клавиатурного ввода и экранного вывода. Поскольку первая будет скорее всего koi8-r, а вторая может оказаться cp866, то именно koi-r2cp866 и нужно ставить. Тем более, что другой-то и нет: если вам позарез требуется cp1251 для ввода, то нужно ставить или экранный шрифт для нее же (благо, он есть, но вид программ с псевдографикой будет безобразным), либо искать карту соответствия (или сделать ее самому). Очевидно, что при сипользовании «сквозной» koi8-r карта соответствия также не понадобится.

Сразу после выполнения русификации меню (точнее, смены экранного шрифта) меню BSD Installer примет вид… скажем так, несколько странный. Это — из-за того, что тип терминала перестал соответствовать загруженному. Не беда, такое безобразие мы исправим в следующем же разделе.

И еще, забегая вперед, отмечу, что DragonFly содержит полный набор русских локалей, в том числе даже ru_RU.UTF-8. А вот чего в ней не обнаружилось — так это команды locale — список их приходится смотреть визуально — в каталоге /usr/share/locale.

И, наконец, дополнительные пакеты (Install extra software packages). Список их не велик — cdrtoosl, cvsup (собранный без поддержки GUI) и еще пара-тройка, имеющих отношение к BSD Installer и его front-end’у (рис. 13). Хотя эти пакеты как бы входят в базовую систему, устанавливаются они в подкаталоги ветви /usr/local и фиксируются в базе данных, расположенной в /var/db/pkg.

Рис. 13. Установка дополнительных пакетов

Следует заметить, что запрос на установку дполнительных пакетов следует только при инсталляции со снапшотов проекта. При использовании сборки GoBSD — допллнительные пакеты установятся сами по себе — хотя и в урезанном составе (без cdrtoosl и cvsup). Но зато, как я уже упоминал, BSD Installer будет сразу готов к работе.

Теперь, казалось бы можно и перезагрузится, не правда ли? Можно. Но есть еще одна возможность — воспользоваться «живительными» свойствами установочного диска и довести настройки до логического конца, уже вручную.

Дополнительные настройки

Вообще-то тема настройки DragonFly — совершенно особая, и со временем ей будет посвящена специальная статья. Здесь же я просто дам несколько рецептов, направленных на получение, после перезагрузки, базовой системы, готовой к употреблению на все 100% — по выходе из BSD Installer степень готовности можно определить в 99%.

Чтобы перейти к ручным настройкам, нужно вернуться в начальное меню BSD Installer и выбрать в нем пункт Exit to Live CD (см. рис. 1), или просто авторизоваться как root на любой свободной виртуальной консоли. В результате чего в нашем распоряжении оказываются два важнейших инструмента конфигурирования — командная оболочка (полноценный tcsh) и текстовый редактор (ee — не богатый возможностями, но для наших целей достаточный и простой в использовании).

Теперьт определяемся с объектами конфигурирования. В первую очередь нам нужно а) довести до ума русификацию, б) обеспечить монтирование всех необходимых файловых систем, и в) создать комфортные условия для работы в консоли. Все три цели достигаются редактированием трех файлов — /etc/ttys, /etc/fstab и /etc/rc.conf.

Редактирование /etc/ttys понадобится для ликвидации упомянутого выше безобразия с внешностью псевдографических программ. Для чего в строках, описывающих виртуальные консоли и имеющих вид вроде

# name  getty                           type    status          comments
#
ttyv0   "/usr/libexec/getty Pc"         cons25 on  secure

достаточно заменить тип терминала по умолчанию (cons25) на cons25r.Файл /etc/fstab формируется автоматически при создании разделов и файловых систем на них. Однако если мы решили монтировать в каталог /tmp и (или) /usr/obj файловую систему mfs (как это было предложено ранее), то об этом нужно позаботиться самостоятельно, дописав в /etc/fstab такие строки:

swap /tmp mfs rw,async,noatime 0 0
swap /usr/obj mfs rw,noauto,async,noatime 0 0

Обращаем внимание на опции монтирования: async предписывает тот самый асинхронный режим, о котором я упоминал в прошлом разделе, а noatime запрещает обновление времени последнего доступа, что несколько способствует быстродействию. Для каталога /usr/obj добавляется еще и опция noauto — этот каталог нужен только при пересборке ядра и базовой системы, и держать его смонтированным постоянно нет никакого резона.

Файл /etc/rc.conf — главный конфиг для стартовых скриптов при загрузке в BSD-стиле, и со временем мы его изучим во всех деталях. Пака же нам важно включить службу консольной мыши, обеспечить нормальную реакцию клавиатуры и правильный вывод русского текста (последнее — только в случае koi8-r как кодировки экранного вывода.

Мышь с USB-интерфейсом включить проще всего: для этого достаточно отыскать в /etc/rc.conf строку

usbd_enable="NO"

и заменить умолчальное значение на YES.

Мышь с разъемом PS/2 (или, скажем, ноутбучный тачпад — интерфейс у него, скорее всего, тот же) потребует уже нескольких строк:

moused_enable="YES"
moused_type="auto"
moused_port="/dev/psm0"

Скорость реакции клавиатуры — дело вкуса, конечно, но мне та, что по умолчанию, кажется удручающе медленной. Поэтому я всегда вписываю строку

keyrate="fast"

И еще мне очень полезной кажется опция вида курсора — так называемого деструктивного, позволяющего легко отличать позицию его от выделения мышью одиночного символа. Это обеспечивается строкой

cursor="destructive"

Наконец, последнее действие. Если у вас есть под рукой русский текст на носителе, который можно смонтировать в DragonFly (если нет — прошу поверить на слово), и вы после русификации консоли в «сквозной» кодировке koi8-r попробуете его посмотреть, то будете весьма удручены: некоторые русские буквы исчезнут с экрана (слаба Богу, что не из файла:-) при первом же движении курсора мыши. В причины этого пока вдаваться не будем, а скорее исправим это безобразие строкой

mousechar_start="3"

Это опять-таки временная мера — в следующей статье мы научимся обходиться без этого.

Да, чуть не забыл — еще хорошо бы создать обычный пользовательский аккаунт — это легко сделать утилитой adduser в интерактивном режиме, ответив на несколько вполне очевидных вопросов. Не забыв только, что на вопрос о классе пользователя нужно отвечать russian — это автоматически установит одноименную локаль (точнее — локаль ru_RU.KOI8-R). Если же аккаунт был создан посредством BSD Installer, то этот класс требуется для него определить, что проще всего сделать так:

$ pw -L russianВот теперь действительно все. Можно перезагружаться и смотреть, что же мы получили в итоге.

Впечатления

А получили мы базовую, но вполне систему — правда, без Иксов и практически без всяких приложений, но с полным набором Unix-утилит, список которых устанавливается просмотром содержимого каталогов /bin, /sbin, /usr/bin и /usr/sbin. Что немаловажно — полностью и корректно русифицированную, с работающей консольной мышью.

Умолчальное ядро DragonFly (т.н. GENERIC) собрано с модульной поддержкой максимально широкого круга оборудования. Во всяком случае, почти все наличествующее у меня «железо» никаких проблем не вызвало: вполне справно функционировали «из коробки» и тачпад моего ноутбука в параллели с USB-мышью, и чипсетный звук от Intel (ICH4) вкупе с чипсетной же сетевушкой, и USB-накопители (флэш-драйвы и мобильный винчестер Fujitsu Handy Drive).

Правда, в DragonFly не используется файловая система устройств (devfs) — файлы устройств именуются статически. С чем связаны некоторые, вполне понятные, неудобства при монтировании USB-накопителей: в зависимости от очередности их втыкания они оказываются то устройством /dev/da0, то — /dev/da1, и так далее, однако с этим легко примириться. Тем более, что, по информации с сайта проекта, в дальнейшем в DragonFly планируется поддержка демона devd — некоего аналога механизма udev в Linux.

Что меня весьма порадовало — в DragonFly по умолчанию включена поддержка Линуксовой файловой системы ext2fs — во FreeBSD для этого требуется перекомпиляция ядра. Проблем с монтированием журналируемого ее варианта ext3fs) также не возникает (правда, естественно, без журналирования). И еще одна приятная мелочь: ext2fs при перезагрузке или останове системы (командами reboot и halt, соответственно) размонтируется корректно, с установкой clean byte. Это заслуживает похвалы, так как во FreeBSD по сию пору раздел ext2fs, не размонтированный перед рестартом руками, бита чистого размонтирования не получает, и повторное его монтирование, без проверки утилитой fsck (разумеется, Linux’овой же, установленной из портов, ни в коем случае не от FreeBSD), оказывается невозможным.

Конечно, для полного счастья в DragonFly не хватает очень многих приложений. И возникает вопрос, откуда их брать. Частичный ответ на это был дан в первой заметке: из прекомпилированных пакетов на соответствующих сайтах, портов FreeBSD, pkgsrc проекта NetBSD и, в некотором количестве, из собственного дерева dfports. Да и ручную сборку пока никто не отменил. Ну а подробнее мы поговорим на эту тему, когда речь дойдет до пакетного менеджмента.

Ссылки

Получение дистрибутива:
ftp-сервер проекта
список зеркал
сборка GoBSD

DragonFly BSD Handbook.
Главный источник сведений об установке.

A Quick Start on DragonFly
Быстрое вхождение в тему (для опытных и нетерпеливых).