Citkit, 8 ноября 2007 г
Получив в свое распоряжение смонтированные и практически безразмерные файловые системы, остается только залить их содержимым, дабы приступить к работе. Это можно сделать разными способами. Канонический путь правоверного «фришника» — запасшись пивом, скачать дерево исходников системы, переконфигурировать ядро, пересобрать ядро и мир, скачать и развернуть тарболл дерева портов, установить из портов все нужные приложения... Правда, пива для выполнения всех этих процедур потребуется немало. Так что мы пойдем другим путем, обратившись к нелюбимой многими утилите sysinstall — заодно и оценим ее мощь.
Итак, после перезагрузки системы, которой мы завершили, спокойствия ради, разборки с ZFS, авторизуемся root'ом и из командной строки вызываем
$ sysinstall
и в главном ее меню выбираем пункт Configure.
Для начала посредством подменю Distributions следует доустановить компоненты базовой системы — ведь теперь мы, смонтировав в каталог /usr отдельную файловую систему ZFS, не ограничены в дисковом пространстве. Какие именно? Ну, вопрос о нужности игр, info-документации и тому подобных излишеств каждый решает для себя сам. А вот что заведомо понадобится — это исходники системы - src (рано или поздно обновлять ее придется, и лучше это делать, скачивая через cvs-up обновления, а не все дерево гуртом), дерево портов — ports (без него по хорошему также не обойтись) и Иксы — X.Org (даже самым стойким приверженцам консоли нынче без них не житьё).
По завершении выбора нам предложат указать источник инсталляции. Здесь возможны варианты. При из рук вон плохом коннекте (или его отсутствии вообще) безальтернативной будет установка с CD/DVD, того самого, с которого мы осуществляли начальную инсталляцию. По ряду причин вариант этот — не лучший, и обращаться к нему следует только при полной безвыходности.
Если же коннект все-таки имеет место быть, то есть три варианта:
- FTP просто;
- FTP в пассивном режиме (из-за файрволла);
- HTTP (из-за прокси сервера).
Если вы знаете свой тип соединения, выбор будет очевиден. Если нет — придется прибегнуть к методу ползучего эмпиризма, и перепробовать все три варианта — какой-то да заработает.
В принципе, к доустановке по сети можно прибегнуть и при модемном соединении. Как его настроить — было предметом отдельной заметки. Правда, длиться она будет медленно и печально, да и возможные обрывы связи жизнь не скрасят. Так что не говорите, что вас не предупреждали...
Установка пакетов через sysinstall хороша тем, что пакеты в ней предстают в виде наглядного списка. Причем в нем в столь же наглядной форме предстают не только непосредственно выбранные пакеты, но и пакеты, установка которых необходима для разрешения зависимостей.
Однако если вы точно знаете имена нужных пакетов, то вполне можно обойтись и средствами командной строки, а именно утилитой pkg_add. Данная в форме
$ pkg_add -r pkg_name
она автоматически скачает, развернет и установит не только заказанный пакет (имя которого задается без указания версии), но и все пакеты, от которых он зависит. По умолчанию пакеты будут вытягиваться с главного ftp-сервера проекта FreeBSD. Если это нежелательно (а это скорее всего нежелательно), то следует определить переменную PACKAGESITE, значением которой будет полный URL репозитория пакетов более подходящего зеркала — например, российского. Хотя лично я непатриотично предпочитаю зеркала норвежские — в моих условиях они оказываются наиболее быстрыми (это не значит, что они будут таковыми же и у вас, это придется определять методом ползучего эмпиризма).
Переменную PACKAGESITE резонно определить раз и навсегда — в оболочке того пользователя, от имени которого пакеты будут устанавливаться. Нетрудно догадаться, что им будет пользователь root (да другого пока и нет). Так что если его пользовательский шелл (/bin/csh) по умолчанию не менялся, то в файл /root/.cshrc нужно дописать строку
setenv PACKAGESITE URL
Последний - в указанной выше форме, то есть с указанием полного пути до Latest.
Итак, тем или иным способом устанавливаем все необходимые пакеты. После чего возникает психологический момент создать обычный пользовательский аккаунт. Почему именно сейчас? Да потому, что в ходе установки пакетов мы ведь не забыли инсталлировать наш любимый пользовательский шелл (интерактивная работа с умолчальным /bin/sh — занятие достаточно удручающее), текстовый редактор, десктоп или менеджер окон. Хотя на стадии создания аккаунта достаточно иметь только первый — остальное сконфигурируется потом.
Создать аккаунт можно двояко: или через sysinstall, или одной из многочисленных во FreeBSD утилит командной строки. В первом случае переходим в соответствующий пункт меню и заполняем поля предложенной формы. Единственное, что тут требует внимание — в поле Login shell не забыть вписать вместо умолчального /bin/sh свою любимую (и ранее установленную) оболочку, например, /usr/local/bin/zsh (или, по желанию, /usr/local/bin/bash).
Из командной строки проще всего воспользоваться утилитой adduser, которая потребует вполне очевидных ответов на несколько не менее тривиальных вопросов.
В любом случае мы получаем учетную запись обычного пользователя, от лица которого в дальнейшем и будем в основном действовать. Обращаясь к аккаунту root'а только тогда, когда это действительно необходимо. Правда, настройка нашей системы пока не закончена, и необходимость эта будет возникать нередко. Так что запоминаем три пути получения административных полномочий:
- Авторизоваться root'ом;
- Получить права администратора посредством команды su;
- Получить возможность выполнить единичную команду с привилегиями администратора посредством команды sudo.
Все эти способы описывались бессчетно, и потому останавливаться на них я не буду — желающие легко отыщут соответствующие материалы (в том числе и на этом сайте), особенно если запомнят, что ни авторизация root'ом, ни команда su, ни настройка доступа с помощью команды sudo ничем не различаются ни в любой BSD-системе, ни в Linux'е.
Дальнейшую настройку системы целесообразно начать с доведения до ума консоли — то есть установить более приличные консольные шрифты, возможно, поменять локаль и переопределить кодировку ввода-вывода. Эти процедуры многократно описывались, я на них останавливаться не буду. Напомню только, что из-за восьмибитности внутреннего представления символов в syscons использовать в консоли FreeBSD UTF-8 по прежнему не удастся. Но, если имеется настоятельная потребность в таковой (а ныне она возникает все чаще и чаще), то соответствующие настройки можно выполнить для Иксов.
Кстати, настройка Иксов вообще заслуживает чуть более подробного рассмотрения. Начиная где-то с версии 6.X, соответствующий пункт был изъят из меню конфигурирования sysinstall, и потому ее придется произвести в полуавтоматическом режиме с последующей ручной доводкой (правда, небольшой).
Итак, для начала обращаемся к автоматике посредством команды
$ X -configure
которая, данная от имени администратора, создаст в каталоге /root файл xorg.conf.new. Копируем его, куда следует
$ cp /root/xorg.conf.new /etc/X11/xorg.conf
и смотрим, что же получилось, внося посредством любимого редактора необходимую правку.
Секция "Files", описывающая, в частности, пути к доступным системе шрифтам, богатством содержания не радует: мы не найдем в ней ни одной из свободных TTF-гарнитур, которые стали уже привычными пользователям Linux'а. Да и в соответствующем каталоге /usr/X11R6/lib/X11/fonts/ можно обнаружить только подкаталог с семейством шрифтов bitstream-vera. Более того, ни в портах, ни в пакетах нам не встретятся ни шрифты DejaVu, ставшие стандартом для современных Иксов, ни новые шрифты Libertine. Так что их придется скачивать самостоятельно (с http://dejavu.sourceforge.net/ и http://linuxlibertine.sourceforge.net/, соответственно), развернуть их в указанном выше каталоге и прописать пути к ним в xorg.conf.
Далее — клавиатура, описываемая первой по порядку секцией для устройств ввода,
Section "InputDevice"
Автоматика скажет нам только то, что она имеет идентификатор
Identifier "Keyboard0"
И управляется драйвером
Driver "kbd"
Что ничуть не способствует ее, скажем, русификации. Так что дописываем строки
Option "XkbRules" "xorg"
Option "XkbModel" "pc104"
Option "XkbLayout" "us,ru(winkeys)"
Option "XkbOptions" "grp:caps_toggle,grp_led:scroll"
определяющие правила, модель, раскладки и переключатель оных. Последний в примере - по CapsLock, но, сверившись с документацией или многочисленными статьями на эту тему, можно установить практические любой желаемый. Нужно заметить, что в качестве модели можно указать любую разрешенную и разумную (например, pc105). А вот XkbLayout лучше задать именно так, как я указал - вариант с
Option "XkbLayout" "us,ru"
Option "XkbVariant" "winkeys"
Который в Linux'е обычно альтернативен, во FreeBSD почему-то не проходит.
Вторая секция
Section "InputDevice"
В коррективах, скорее всего, не нуждается — там будет все, что требуется и для скроллирования, и для использования колёсика в качестве средней кнопки.
А вот что могло бы быть предметом разборки — так это секция
Section "Device"
Точнее, та ее часть, которая идентифицирует видеочип. Да. Сразу оговорюсь, все описанное ниже относится к интегрированному видео от Nvidia - 6150 (впрочем, оснований, что с бывшим ATI, а ныне AMD, будет лучше, немного).
Так вот, автомат сообщил мне, что у меня имеются
Driver "vesa"
BusID "ISA"
Ну, первая строка понятна: если не знаешь, что делать, делай, что приказано. То есть — не определилась видеокарта, считаем ее за последний приказ (пардон, общепринятый стандарт). А вот откуда взялась ISA — тайна сия велика есть
Что самое смешное, Иксы, в ответ на команду
$ startx
запустились. Причем в совершенно немыслимом режиме - 1440x1050, или что-то в этом роде. Физическое разрешение LCD-матрицы моего среднего 17-дюймового монитора, как легко догадаться, было 1280x1024.
Ну, это правится легко — вычеркиваем все ненужные нам глубины цвета (а многим ли нынче жизненно необходимо иметь глубину цвета в 1, 2... даже сэм-восэм, или сколько то там еще бит, за исключением 24-х?). Да и вписать
DefaultDepth 24
тоже религия вроде не запрещает. После чего Иксы рестартуют по прежнему благополучно. Только вот экран оказывается чуток скособоченным, и видео на нем смотреть... Ну извините, это все, что угодно, но только не видео.
Как известно, всех, кому не надо отправлять Тукса на отлов рыбы, застрявшей на обледенелых склонах, в таких случаях завсегда спасал драйвер nv, составная часть X-сервера. Не тут-то было. С этим драйвером Иксы во FreeBSD вообще стартовать отказались.
Такие вещи в Linux'е исправляются (часто, но не всегда) установкой фирменного драйвера (известного под партийным псевдонимом nvidia). Возможно, этот номер прошел бы и во FreeBSD — но увы, только в 32-битной версии. Потому что гранаты для 64-битной ее версии фирма-производитель пока не заготовила...
Так что — увы, но остаемся на двайвере vesa. Жить можно, работать можно, но от излишеств пока приходится отказываться (впрочем, на предмет излишеств Linux имеется, а там, глядишь, ситуация с видеодрайверами рассосется).
Теперь вспоминаем, что системная локаль по умолчанию у нас — KOI8-R (или там CP1251, если угодно). А ведь за последние годы стали мы людьми прогрессивными, и привыкли к локали UTF-8. Так вот, в Иксах можно обеспечить ее поддержку и во FreeBSD. Для этого только и требуется, что создать файлик ~/.xinitrc со следующими строками:
export LANG='ru_RU.UTF-8'
export LC_ALL='ru_RU.UTF-8'
exec startkde
Разумеется, запуск KDE можно (и нужно) заменить стартом своего любимого десктопа или менеджера окон. Тут только нужно помнить, что если у KDE, GNOME или XFce внутреннее представление символов действительно в UTF-8, вне зависимости от системной локали, то с остальными оконными менеджерами могут возникнуть проблемы в эмуляторах терминалов. Впрочем, кое-какие проблемы, например, со всенародно любимым mc, они и так возникнут — разрешением их мы здесь заниматься не будем, ибо оно также описано.
И последнее. Если после настройки Иксов вы уверены, что все работает как надо, можно включить авторизацию в графическом режиме, через тот или иной desktop manager. Если в этой роли выступает стандартный Иксовый xdm, то в файле /etc/ttys достаточно в строке
ttyv8 "/usr/local/bin/xdm -nodaemon" xterm off secure
заменить значение off (в предпоследнем поле) на on — в отличие от Linux'а, ни с какими runlevels здесь разбираться не нужно.
Да, для перестраховки не вредно заменить значение последнего поля — secure, на unsecure. Это запретит вход в сеанс Иксов от лица администратора. Что, кроме потенциальной опасности, еще и абсолютно бессмысленно.
Если же требуются более продвинутые возможности kdm (из KDE) или gdm (используемого в GNOME или XFce по умолчанию), то второе поле указанной записи надо скорректировать:
ttyv8 "/usr/local/bin/kdm -nodaemon" xterm on unsecure
для KDE или
ttyv8 "/usr/local/bin/gdm -nodaemon" xterm on unsecure
для GNOME/XFce. Впрочем, и забывать о том, что любой из десктоп-менеджеров может загружать любой десктоп или менеджер окон — тоже не след. Впрочем, это тема отдельной истории.
Сообщения
