CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
23.09.2019

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Дистрибутивы :: BSD :: FreeBSD

Всё имеет свое начало...
2. Варианты установки

CITKIT.ru

Страницы: предыдущая :: 1 :: 2 :: 3 :: 4 :: следующая

Содержание

Индивидуализированная установка

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

  • разметкой диска;
  • установкой базовых компонентов;
  • установкой минимума абсолютно необходимых пакетов (packages), буде таковые потребуются;
  • самыми насущными из настроек.

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

Поскольку на компьютере не предполагается использование иных ОС, казалось бы, можно ограничиться одним слайсом для FreeBSD, разметив внутри него должное количество разделов. Однако возможно, что это будет не лучшим вариантом. Как мы помним из главы о базовых познаниях, максимальное количество разделов в пределах одного слайса не может превышать семи (из которых один задействуется под своппинг). А сколько разделов реально нам может потребоваться?

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

Как уже говорилось ранее, первые кандидаты на выделение за пределы корня — это каталоги /tmp, /var, /usr (о каталоге /home или /usr/home мы поговорим особо). Однако это далеко не предел. Так, внутри каталога /usr имеет смысл обособить такие его ветки, как:

  • /usr/src, хранящий исходные тексты всей базовой системы (включая ядро),
  • /usr/obj, в котором собираются временные файлы, образуемые при компиляции ядра, мира и дополнительных программ из портов,
  • /usr/local, в который все эти дополнительные программы устанавливаются (без разницы, из портов ли, или из пакетов).

Далее, не лишено резона вынести на отдельный раздел само дерево портов — /usr/ports. А внутри него выделить подкаталог /usr/ports/distfiles, предназначенный для хранения скачанных из сети исходников.

Читатель может спросить, а зачем нужна столь дробная разметка диска, если в Linux-десктопах обычно благополучно обходятся двумя-тремя разделами? Резонов к тому несколько, и подробнее они будут рассмотрены в главе про файловую иерархию. Пока же замечу, что это и

  • разнородность данных в разных каталогах, что для достижения максимальной производительности требует разных параметров форматирования и монтирования;
  • желательность разделения компонентов, легко восстановимых с дистрибутивных носителей, и компонентов, скачанных из сети, восстановление которых потребует времени и трафика;
  • наконец, просто соображения удобства, по принципу "каждому овощу — свою грядку; конечно, понятие удобства весьма субъективно, но большинство активных пользователей FreeBSD рано или поздно приходят к схеме разметки, более или менее похожей на приведённую.

Таким образом, мы уже насчитали 10 необходимых (или желательных) разделов (без учёта раздела подкачки). А ведь о разделах для пользовательских данных ещё и разговора не было. Кстати, и начнём его. Конечно, всё, что касается индивидуальных данных, предельно субъективно. Поэтому ограничусь тут изложением своих личных предпочтений — не как пример для подражания, а как точку отсчета для формирования собственных соображений.

С некоторых пор я отказался (и во FreeBSD, и в Linux'е) от вынесения на отдельный раздел каталога /home (или /usr/home) "гуртом". Вместо этого я делю его на несколько ветвей, каждая — на самостоятельном разделе:

  • /usr/home с подкаталогами username1, username2 и так далее (если нужно — обычно у меня в системе минимум два пользователя); в них не содержится ничего, кроме пользовательских dot-файлов и, возможно, пользовательских скриптов;
  • /usr/home/work, предназначенный для текущих проектов (например, файлов этой книги);
  • /usr/home/data, в который собираются всё, что относится к проектам уже выполненным;
  • /usr/home/soft — для всякого рода программ, скачанных из Сети помимо системы портов;
  • /usr/home/media, содержащий аудио- и видеофайлы (и прочую "развлекуху").

Несложный подсчёт показывает, что число разделов, таким образом, возросло до 15, что не вписывается уже и в два слайса (ввиду того, что корневой каталог в системе может быть только один, количество разделов для данных на втором и последующих слайсах сокращается до 5). Поэтому, забегая вперед, отмечу, что столь дробную схему разметки целесообразно использовать только вместе с файловой системой ZFS, которая, снимая ограничения на количество разделов, кроме того, избавляет от точного расчёта потребного для них дискового пространства. В данном же разделе мы ограничимся созданием двух слайсов, которые в сумме могут вместить в себя не более одиннадцати разделов.

Расчет дискового пространства, потребного для традиционных файловых систем (например, UFS2) сам по себе представляет нетривиальную задачу. Объём под одни ветви файлового древа (такие, как /, /usr или /usr/src) может быть оценен достаточно точно (и оставаться практически неизменным). Прочие же общесистемные ветви, зависимости от характера использования системы, могут потребовать под себя очень разные объёмы дискового пространства. К тому же потребности в месте на диске меняются от версии к версии. И вы легко догадываетесь, в какую сторону: во времена FreeBSD 4-й ветки "чистый" корень файлового древа, освобождённый от всех "боковых" ветвей, легко вписывался в 128 Мбайт, ныне же под него по умолчаниям sysinstall отводится 512 Мбайт (и даже в супер-минимальной установке, о которой мы поговорим позднее, из них оказывается занятыми примерно 250 Мбайт).

Поэтому ниже в таблице приведены оценочные объемы разделов под перечисленные выше ветви файловой системы (за исключением ветви /usr/home — с ней я предоставляю читателям разбираться самостоятельно).

Таблица. Дисковые разделы под системные ветви файлового дерева FreeBSD

№№ пп Устройство Каталог Размер
1 /dev/ad0s1a / 512 Мбайт
2 /dev/ad0s1d /tmp 128 Мбайт
3 /dev/ad0s1e /var 256 Мбайт
4 /dev/ad0s1f /usr 512 Мбайт
5 /dev/ad0s1g /usr/obj 1 Гбайт
6 /dev/ad0s1h /usr/src 512 Мбайт
7 /dev/ad0s2d /usr/local 3 Гбайт
8 /dev/ad0s2e /usr/ports 2 Гбайт
9 /dev/ad0s2f /usr/ports/distfiles 2 Гбайт
10 /dev/ad0s2g /usr/home 64 Мбайт
11 /dev/ad0s2h /usr/home/data ??

Ещё раз повторю, что приведённые в таблицы цифры должны рассматриваться как минимальные — если есть возможность, то к разделам под каталоги /usr/local, /usr/ports, /usr/ports/distfiles можно смело накинуть по гигабайту. Благо такая возможность при современных объемах дисков, как правило, имеется. Ну а принципов выделения места под пользовательские данные — три: сколько надо, сколько осталось или сколько не жалко.

Отдельно надо поговорить о двух ветвях файловой иерархии — каталогах /tmp и /obj. При современных объемах оперативной памяти под них иногда целесообразно не выделять самостоятельные дисковые разделы, а монтировать в них так называемую mfs (Memory File System — файловая система в оперативной памяти, аналог tmpfs в Linux'е). Этим достигается три цели:

  • несколько повышается быстродействие, хотя невооружённым тестами взглядом этого можно и не заметить;
  • гарантируется очистка обоих каталогов при перезагрузке;
  • экономится... даже не место на диске, нынче жалеть его не приходится, а одна или две из записей под раздел внутри слайса, которые можно задействовать для других целей.

Для каталога /tmp эти три соображения имеют силу всегда — так что при объеме памяти от 512 Мбайт и более (а меньше нынче найти нелегко) также всегда имеет смысл и монтировать в него mfs (как именно — мы узнаем в соответствующей главе). А вот с каталогом /obj всё гораздо сложнее...

Во-первых, будучи по умолчанию предназначенным для помещения промежуточных продуктов компиляции ядра и "мира", базируясь на mfs, он не может выполнять эту функцию: как мы увидим в соответствующей главе, процесс этот прерывается почти на середине перезагрузкой, во время которой содержимое файловой системы в оперативной памяти исчезает.

Во-вторых, сборка из портов по настоящему "тяжелых" приложений, вроде Openoffice.org, может потребовать просто астрономического объема памяти под временные продукты компиляции.

Ну и в третьих, получаемый при этом выигрыш в быстродействии составляет, по самым оптимистическим оценкам, не более 10%. Так что я предупредил — а дальше решайте сами, нужно оно вам или нет.

Внимательный читатель наверняка обратил внимание, что в приведённом "разблюдовнике" разделов не нашлось места для раздела подкачки. И это не случайно — тут тоже требуется учитывать множество факторов.

Давно прошли счастливые времена, когда можно было, особенно не заморачиваясь, отвести под swap-раздел удвоенный объем оперативной памяти, как это обычно рекомендуется, и забыть об этой проблеме. Однако ныне памяти этой вполне может быть и 2, и 4 Гбайт: следовательно, выполнять данную рекомендацию имеет смысл только для 64-битных вариантов FreeBSD, для убеждения в чём достаточно вернуться к главе о "железе". Это — раз.

Два — при указанных объемах памяти потребности в свопировании её содержимого во время выполнения подавляющего большинства пользовательских задач просто не возникает. Так что обычно без раздела подкачки можно вообще обойтись. Что, кстати, учтено в последних версиях sysinstall. Если раньше отказ от создания swap-раздела вызывал обрыв установки, то нынче просто выдаётся предупреждение, то таковой может произойти, если не хватит оперативной памяти. Так что для очистки совести можно ограничиться неким символическим разделом — на несколько сотен мегабайт.

Однако есть два случая, когда swap придётся задействовать по полной программе. Первый — при монтировании всё-таки mfs в каталог /usr/obj и сборке из портов "тяжёлых" приложений: тогда, во избежание переполнения соответствующей файловой системы, необходимо иметь вдоволь (а лучше — немного больше, чем вдоволь) пространства для подкачки. Второй же случай — это использование файловой системы ZFS, что будет рассмотрено в одном из ближайших разделов.

Исходя из всего, сказанного выше, пользователю не составит большого труда прикинуть примерный размер каждого из двух слайсов, на которые ему целесообразно разбить диск посредством пункта меню заказной установки Partition. Также очевидно, что вслед за этим загрузчик FreeBSD должен быть установлен в MBR — ведь это, как мы молчаливо условились, если не единственная, то — основная система на нашей машине. Ну а дальнейшее — собственно разметка слайсов, — может быть выполнена как вариация на приведённую в таблице тему через меню Label.

Покончив с дискодробительством, обращаемся к пятому пункту нашей программы — Distributions. В прошлой главе мы разобрались с ним очень легко, выбрав один из фиксированных установочных наборов, а именно X-Kern-Developer. Нынче же мы начинаем построение системы по кирпичикам, и потому выбор наш останавливается сначала на пункте Minimal (дабы не забыть о чем-то жизненно важном), а потом — на пункте Custom, для детализации (рис. 9.01).


Рис. 9.01. Выбор индивидуального набора

Раскрыв означенный пункт, мы видим, что для установки у нас отмечены компоненты base, kernels и... более ничего. В случаях, составляющих предмет следующих разделов, этим, как мы увидим, следует и ограничиться. В нынешней же ситуации жмотничать нечего — спокойно отмечаем необходимые нам чекбоксы (рис. 9.02).


Рис. 9.02. Выбор компонентов индивидуального набора

Здесь целесообразно выбрать следующие пункты:

  • doc — подборку официальной документации проекта (если ранее мы не скачивали образ соответствующего компакт-диска, содержание их идентично);
  • man — страницы встроенной документации, абсолютно необходимые во всеё дальнейшей жизни;
  • info — сходную по содержанию документацию в ином формате, если она не вызывает у вас внутреннего отторжения (как у автора этих строк);
  • ports — дерево портов, также абсолютно необходимое для установки всех дополнительных приложений;
  • src — исходники базовой системы, в том числе и ядра.

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


Рис. 9.03. Выбор компонентов индивидуального набора

Здесь проще всего, выбрав пункт All, отметить все компоненты, после чего снять галочки с ненужных. Таковыми, на мой взгляд (который я никому не навязываю), являются пункты crypto, games и krb5 — всё остальное так или иначе не будет лишним в последующем, при пересборке "мира".

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

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

Кроме того, не лишним будет и браузер для текстового режима — ведь никаких Иксов у нас нет ещё и в помине, а возможность свериться с первоисточниками в сети никогда не помешает, а сразу после перезагрузки может оказаться необходимостью. Выбор тут не богат: на установочном компакт-диске может присутствовать lynx или links. а иногда и то, и другое. Выбирать придётся первый — пакет под именем links представляет собой вторую версию этой программы и собран с поддержкой графики, то есть потянет за собой в качестве зависимостей множество компонентов, установка которых пока преждевременна. Чисто консольная сборка этой программы наличествует в виде пакета links1 — но её на установочном диске может и не быть.

Впрочем, установку необходимого минимума пакетов можно и отложить до времени после рестарта, начав с неё процесс доведения системы до ума, чем мы вскоре и займемся. Но сначала последовательно рассмотрим особенности установки FreeBSD в случаях, если предполагается использование программного RAID'а или файловой системы ZFS.




Страницы: предыдущая :: 1 :: 2 :: 3 :: 4 :: следующая

Комментарии

Страницы комментариев: 1 :: 2 :: следующая

Роман, Sun Mar 8 05:27:10 2009:
И ещё пара вопросов:
1) после предложения "Вот теперь — уже самое последнее: монтирование подкаталогов tank в реальную файловую иерархию" изображено монтирование только tank/var и tank/usr, а как быть с остальными, их, как я понимаю тоже надо монтировать ???
Если нет, то, по-моему, это надо явно прописать !!!
А если надо, то, наверное и это надо упомянуть отметив при этом хотя бы после монтирования tank/usr многоточием( "..." ), предполагающим, что далее монтируются все остальные каталоги выделенные в отдельные файловые системы по тому же принципу, что и приведённые :)))
2) Из предложения "И увидеть, что каждая из файловых систем ZFS потенциально располагает 240 примерно гигабайтами дискового пространства. Что, по мере его расходования, будет убывать пропорционально — опять же для всех." возникает вопрос о целесообразности использования ZFS !!!
Так всё-таки отгораживаются ли файловые системы друг от друга или нет ???
Ведь если каждая из выделенных якобы файловых систем располагает "примерно всеми гигабайтами дискового пространства", хотя непонятно, что значит примерно, то переполнение одной файловой системы ведёт к переполнению всех !!!
Или я чего-то не понимаю( но такое мнение у меня сложилось после прочтения данного раздела ) !!!
Роман, Sun Mar 8 05:05:50 2009:
В разделе "Установка для использования ZFS" предложение "Всё оставшееся дисковое пространство на обоих дисках определяем как BSD-слайсы — они-то и составят со временем пул ZFS" вносит некоторую неясность, а именно,
если имеется два винчестера( в предположении SATA ), то, как я понял, на первом создаётся два слайса, а на втором один слайс, при этом:
первый слайс первого диска делим на два раздела — 512 Мбайт под корень файловой иерархии(ad4s1a) и 1xRAM — под раздел подкачки(ad4s1b) и
оставшееся место первого диска отводится под второй слайс(ad4s2d), без корня и swap,
в то время как единственный слайс второго диска разбивается на 2 раздела:
1xRAM — под раздел подкачки(ad6s1b) и
оставшееся место под второй раздел(ad6s1d).
Если в чем не прав поправьте !!!
А если прав, то, мне кажется, необходимо подкорректировать текст раздела ясности ради !!!
Роман, Sun Mar 8 03:53:18 2009:
Ну и ещё один вопросик: А разумно ли помещать /usr в /tmp, даже на примере ???
:)))
Роман, Sun Mar 8 03:42:46 2009:
Ну и как мне кажется, хотя это конечно решать автору, необходимо, после фразы:
"вооружаемся утилитой ccdconfig, коей и сливаем подготовленные ранее разделы для каждой пары сливаемых партиций примерно таким образом"
добавить команду слияния swap разделов, если это вообще нужно, а судя по словам "для каждой пары сливаемых партиций", сделать это нужно.
Так вот добавка, в текст, команды слияния swap разделов необходимо не потому, что читатель сам не догадается как эту команду сформировать, а всё-таки понимания ради, что слияние swap разделов необходимо.
А если я ошибаюсь, и слияние swap разделов производить не нужно, то подкорректировать предложение "для каждой пары сливаемых партиций"
дабы внести ясность.
Роман, Sun Mar 8 03:40:29 2009:
И вновь опечатки :))
в разделе "Установка для использования softRAID":
1) Набрано в др. раскладке предложение: "(домашний каталог — j,sxyj главный пожиратель дисковод памяти)".
j,sxyj -> обычно.
2) "суммарное пространство массива нулевого уровня будет равно удвоенному объему меньшего носителя, а ИЗЛИНЕЕ место на носителе большем просто пропадёт."
3) "флаг none отменяет зеркалирование (то есть создает именно SRIPPED-массив)"
4) "придётся создавать несколько слайсов на каждом диске для их попарной конкатенации (подробнее об этом ДУЕТ говориться в соответствующей главе)."
5) Пропущен '/' перед символом '*':
"# mv /usr* /tmp/usr" -> "# mv /usr/* /tmp/usr"
Роман, Sat Mar 7 15:57:17 2009:
И снова опечатка( строка под Рис. 9.02 ):
"man — страницы встроенной документации, абсолютно необходимые во ВСЕЁ дальнейшей жизни"
Роман, Sat Mar 7 15:12:18 2009:
Перепечатока :))
"И, наконец, есть такие весьма полезные вещи, которые ЗАДЕЙСТВОВАТЬ при установке через sysinstall нельзя ЗАДЕЙСТВОВАТЬ в принципе."
mite, Wed Dec 31 18:26:33 2008:
Алексей, Вы не упомянули еще один вариант - установку по сценарию, использующую файл конфигурации. А ведь это неплохой вариант для индивидуализированной установки - достаточно в файле сценария определить параметры установки, и затем остается только подправлять необходимые под текущие нужды.
Алексей Федорчук, Wed Nov 12 21:50:54 2008:
iZEN
> Может лучше систему оставить на небольшом UFS-слайсе
___
Очень даже может быть. Попробую всё-таки сделать корень на ZFS и поглядеть, чем это чревато :)
Алексей Федорчук, Wed Nov 12 21:48:01 2008:
iZEN
> Обновить систему из исходников можно без промежуточной перезагрузки.
____
Когда-то она не требовалась. Потом в мейк-файле появилось про перезагрузку. Надо будет попробовать, как сейчас. DragonFly в этом случае обходится без перезагрузки.

Страницы комментариев: 1 :: 2 :: следующая

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds