АРХИВ СТАТЕЙ ЖУРНАЛА «МОЙ КОМПЬЮТЕР» ЗА 2003 ГОД

Открывай ворота!

• Все журналы \ Номер 43/266 `2003 от 27.10.2003 \ Открывай ворота!

Сергей А.ЯРЕМЧУК grinder@ua.fm

Окончание, начало см. в МК № 41-42 (264-265).

Настроив и немного поизучив систему, можно переходить к самому интересному этапу — пересборке всей системы. Хотя у новичков, пришедших из Windows, словосочетание «компиляция ядра» вызывают трепет, в их понимании это что-то из области шаманства и Вуду, но ничего в этом сложного и тем более таинственного на самом деле нет. Это обязательная для серверов и обычная для пользователя часть работы с системой, распространяющейся в открытом коде. Во всех *BSD-системах ситуация значительно облегчается тем, что они не имеют модульной структуры, присущей Linux'у, в котором необходимо обновлять отдельно ядро и отдельно каждую утилиту, входящую в состав дистрибутива. Все *BSD — это законченные системы, к тому же поддерживаемые одним составом разработчиков; поэтому все обновления как правило проходят без осложнений и требуют минимум усилий. Вы спросите, зачем это нужно — все и так ведь работает. Вот именно, что и так, но не хорошо. Во-первых, система собрана под i386-архитектуру, а это не оптимально. Хотя справедливости ради хочется отметить, что выше i686 архитектуры тоже не удастся прыгнуть. А все потому, что...

Как видите, в комплект входит еще старичок GCC 2.95.3, но это не свидетельствует об отсталости. Защита превыше всего, помните об этом — видимо, современные версии не подходят к требованиям разработчиков. К тому же в системный компилятор интегрирована технология защиты стека ProPolice. А так как переполнение стека — любимая лазейка хакера, есть надежда, что враг все-таки не пройдет. Кроме оптимизации, необходимо выкинуть весь ненужный багаж, присутствующий в исходном ядре, по умолчанию содержащем поддержку всех устройств, которые могут встретиться на компьютере, и позволяющем использовать систему на самых разных конфигурациях (опять же справедливости ради хочется отметить, что, используя config с параметрами -e, -u и -о, можно отключить неиспользуемые устройства на работающей системе). Ну скажите, зачем это вам? Кроме того, после выключения всех ненужностей система грузится и работает значительно быстрее. Вторая причина заключается в том, что развитие системы не стоит на месте, она постоянно обновляется и совершенствуется, на все обнаруженные баги и уязвимости появляются заплаты. Кроме того, чтобы получить могучий русский язык в консоли или настроить старую звуковую карту, ядро также необходимо перекомпилировать. Если заинтересовались, поехали дальше.

Обновление системы напрямую связано с тремя понятиями: Release, Stable и Сurrent. В чем их отличие? Release — это та система, которая появляется каждые шесть месяцев на CD-ROM; в настоящее время это 3.3. Stable — это то, что получается из Release в процессе его технического сопровождения, то есть латания обнаруженных дыр в безопасности и исправления ошибок. Сurrent представляет собой самую современную (читай: нестабильную) версию кода и предназначен скорее для разработчиков и для тех, кому срочно нужны новые функции. На основании Сurrent через некоторое время появляется очередной Release. Текущую Stable можно получить из «снимков» СVS или на ftp-серверах, немного устаревшую — на CD-ROM. При этом нам понадобятся два архива —sys.tar.gz (содержит исходные тексты ядра, 13.3 Мб) и src.tar.gz (вся остальная часть системы, 76.6 Мб); гурманы могут скачать еще исходники XFree последней версии, заточенной хакерами специально под OpenBSD —XF4.tar.gz, 61.5 Мб. Процедура обновления запускается следующим образом:

Это для получения Сurrent (при использовании оболочки ksh замените setenv на export). Для stable это будет выглядеть приблизительно так:

Если архив с системными сырцами был скачан по FTP, необходимо его распаковать:

Аналогично поступаем с исходниками ядра:

Во всех *BSD-системах нет графической утилиты, с помощью которой можно отконфигурировать ядро, — все шаманство происходит путем комментирования строк, соответствующих ненужным устройствам, прямо в файле, открытом в текстовом редакторе. Конечно, интерактивность make xconfig упрощает эту процедуру, к тому же в ней доступна подсказка по каждому пункту. Но если необходимо поддерживать сразу несколько разных конфигураций, то, сравнивая разные файлы при помощи утилит grep и diff, можно автоматизировать эту нудную работу. К тому же в текстовом файле сразу видны все опции, и их можно просто удалить (а кто сказал, что их нужно только комментировать?) Конфигурационные файлы ядра находятся в каталоге /usr/src/sys/arch/i386/conf, здесь есть и файлы, заготовленные в расчете на разные ситуации. Нас же интересует файл GENERIC, содержащий все опции, — его изменять не рекомендуется, поэтому просто создаем копию.

Теперь открываем его на редактирование.

В файле содержится более пятисот строк, поэтому вопрос, что отключать, стоит на первом месте. Всего, конечно, рассказать не получится, но пару советов дам (некоторые подробности можно найти в man config и man options). Так, в начале файла содержится набор инструкций вида:

Там же, в начале, удаляем лишние записи option *_CPU, оставляем только 686. Следующая, option GPL_MATH_EMULATE, указывает на эмуляцию математического сопроцессора — не нужно это нам, он уже имеется в аппаратном варианте. Также имеется ряд опций option COMPAT_*, включающий бинарную поддержку некоторых Unix-систем — я оставляю только Linux. Хочется отметить, что опция maxusers 32 означает не максимальное число пользователей, как кажется поначалу. Эта переменная отвечает за более тонкие настройки — например, максимальное число процессов, которое вычисляется по формуле, включающей и число maxusers. Далее идут записи о поддержке тех или иных устройств. Для того чтобы определить, что реально имеется в системе, в другой консоли, куда переходим по Ctrl+Alt+F# (да, здесь в консоли для перехода используется именно три клавиши, как и в Х-Window, что несколько непривычно), вводим:

И сверяемся с этой информацией. Особое внимание надо обратить на сообщения not found, означающие, что в «умолчательном» ядре это устройство не поддерживается.

Так, например, строкам из dmesg, указывающим на найденную звуковую карту —

— соответствуют такие строки в конфигурационном файле:

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

Например, найденному устройству MTRR (Memory Type Range Register), определяющему тип кэширования участков памяти и позволяющему ускорить вывод видео —

— в файле соответствует такая строка:

Так что лучше не выключать то, о чем не имеете понятия. Но если точно знаете, что у вас нет SCSI-, PCMCIA- или ISA-шины, то почему бы не поотключать их? И еще маленький совет: лучше всего поначалу отключать не все сразу, а постепенно, проверяясь после каждого этапа при помощи утилиты config, которая производит синтаксический анализ файла и создает затем каталог с заголовочными файлами и правилом сборки ядра. Ее аргументом является имя созданного конфигурационного файла. Но перед этим для оптимизации кода (на всякий случай) в файле /usr/src/sys/arch/i386/conf/Makefile.i386 заменяем строку CMACHFLAGS= -march=i486 на CMACHFLAGS= -march=i686.

Теперь можно конфигурировать:

Если утилита отработала молча и не выдала ошибок, переходим в созданный каталог с именем будущего ядра:

или просто

Удаляем временные файлы, создаем зависимости и, наконец, компилируем ядро:

На случай, если не удастся загрузиться с новым ядром, сохраняем старое:

А теперь копируем новое ядро на свое законное место:

Перезагружаемся:

Если загрузка с новым ядром не удалась из-за возникшей ошибки, то не паникуем — старое ядро ведь сохранено; просто вводим в строке приглашения:

И повторяем все сначала, устранив возникшую ошибку. От себя хочу добавить: если в Linux'e я насмотрелся достаточно на Kernel Panic в новых ядрах, то несколько раз пересобрав ядро как во FreeBSD, так и в OpenBSD я НИ РАЗУ не видел этого сообщения (конечно, если внимательно подходить к процессу конфигурирования). Может, конечно, просто повезло.

Раз новое ядро уже собрано и работает вовсю, теперь необходимо для закрепления успеха пересобрать всю систему. Это нужно сделать еще и потому, что иногда происходит рассогласование версий библиотек с новым kernel'oм, в результате чего некоторые утилиты, такие как ps, top, who, просто откажутся работать. Но пересобрать систему еще проще. Просто заходим в каталог с исходниками:

Удаляем временные объектные файлы:

И собираем систему:

Дополнительно можно убрать некоторые ненужные в домашнем хозяйстве функции, на которые можно указать в уже упоминавшемся /etc/mk.conf. Например:

Процесс перекомпиляции системы займет времени намного больше, чем перекомпиляция ядра, но в итоге мы получим оптимизированный дистрибутив, заточенный под собственные нужды. На этом, честно говоря, я хотел закончить статью, но вдруг меня осенило: ну да, в итоге получилась самая безопасная система, потому как на ее целостность никто не будет посягать — выхода в Интернет-то ведь пока еще нет! А так как этот вопрос наверняка заинтересует читателя после установки системы, стоит сказать пару слов о том, как его настроить. Если у вас выделенная линия, то для настройки соединения хватит ответов на те вопросы, которые вам задавали во время установки системы, но для столь популярного в народе модемного соединения придется совершить еще пару действий. Во всех *BSD системах протокол РРР (Point to Point Protocol) реализован двумя способами: в виде pppd — демона, встроенного в ядро системы, и демона ppp, который запускается как пользовательская программа. Пользовательскую программу настроить легче, но она использует туннельное устройство tun, позволяющее пользовательским программам самостоятельно обрабатывать соответствующие пакеты, отчего этот метод несколько снижает скорость работы. Настройку пользовательского ррр мы и рассмотрим. Для этого нам должна быть известна следующая информация: телефонный номер провайдера, адрес сервера имен, шлюз, используемый по умолчанию (IP-провайдера), логин и пароль. Некоторые из этих параметров уже занесены в соответствующие файлы во время установки, но мы все равно проверим, на месте ли они. Для начала необходимо убедиться, что в файле при конфигурации ядра содержится такая строка (в «умолчательном» ядре это устройство имеется):

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

Теперь необходимо убедиться в наличии /dev/tun0:

Если его нет, создаем его:

Для начальных установок параметров user PPP используется файл /etc/ppp/ppp.conf, который получается на основе шаблонного /etc/ppp/ppp.conf.sample, довольно подробно комментированного:

Файл состоит из двух основных секций default, инструкции которых отрабатываются всегда по умолчанию, и секции(й), описывающей(их) конкретного провайдера.

Примерно так:

Иногда бывает полезным зафиксировать параметр MTU (Maximum Transfer Unit), указывающий на максимальный размер пакета. Если на маршрутизатор приходит пакет большего размера, он разделяется (фрагментируется) на несколько мелких частей, для выполнения требований данной физической сети. Соответственно, тратится время, и это приводит к падению скорости. Возможен и обратный процесс (дефрагментация), но он обычно не реализуется — хотя бы потому что пакеты гуляют по разным каналам. Для Ethernet его значение не превышает 1500, для РРР может быть и меньше (до 500), все зависит от настроек сервера провайдера. В общем, для фиксации MTU после директивы ifaddr прописываем set mtu 1500 или set mtu max 1492 для установления максимального размера блока данных.

Чтобы узнать число MTU, достаточно запустить утилиту ping примерно в таком виде:

Т.е. установлен размер блока данных в 1492 байта (+8 байт служебной информации = максимально возможные 1500 байт); -М hint устанавливает флаг DF (Don't Fragmetation), указывающий на запрет фрагментирования пакета; -v, как и в большинтсве Unix-утилит, выдает дополнительную информацию. Если пакет прошел, значит, MTU равно 1500, а если получено сообщение о недоступности узла, размер MTU и данных следует уменьшить и повторять так до победного. Пингуемый хост должен находиться сразу за сервером провайдера (например, его www- или ftp-сервер) — его можно определить при необходимости с помощью traseroute. Немного отвлеклись. Впрочем, маленькая оптимизация еще никому не вредила.

Чтобы пользователь мог запускать ррр, необходимо ему разрешить это в файле.

Для конкретного пользователя:

Или для всех сразу:

Еще один вариант — создать специального пользователя, входящего в группу network, от имени которого и будет устанавливаться соединение. В общем, сами разберетесь при необходимости.

Теперь добавляем в файл /etc/resolv.conf адрес DNS-сервера провайдера (желательно не менее двух, но и не более трех):

И для журналирования процессов — ррр в файл /etc/syslog.conf:

Все, теперь можно запускать. Программа имеет два основных режима работы: постоянное соединение -ddial, которое поддерживается 24 часа в сутки и при обрыве восстанавливается, и соединение по требованию -auto, устанавливаемое только при попытке выхода в Интернет и обрываемое в течение set timeout при бездействии. Вызывается программа с именем секции файла /etc/ppp/ppp.conf, описывающей провайдера. Например:

или

Теперь можно спокойно гулять по Интернету. Для этого, правда, из web-браузеров в комплекте имеется только lynx, но можно найти и dillo, и Mozilla, и Opera, и два Netscape (один работает через эмулятор BSDi, второй — Linux), выбирать есть из чего. Если вдруг возникли проблемы, то проверьте правильность соединения при помощи утилиты cu:

после чего выполняем команду ATZ. Если ОК, то при помощи ifconfig -a проверьте правильность установок.

При установке и обрыве соединения могут выполняться некоторые директивы, описанные в файлах /etc/ppp/ppp.linkup и /etc/ppp/ppp.linkdown, которые также имеют шаблоны с префиксом sample. Во FreeBSD используется аналогичная схема, только шаблонные файлы там хранятся в /usr/share/examples/ppp/.

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

Viva OpenSource!

Идёт загрузка...

Данную страницу никто не комментировал. Вы можете стать первым.

Ваше имя:
Ваша почта:
Комментарий:
Введите символы или вычислите пример: * Обновить