Заметки об OpenBSD

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

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

Почему OpenBSD?

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

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

В этом цикле проблема настольного применения ОС линии BSD рассматривается на единичном примере — OpenBSD. Возникает вопрос — почему именно она? Ответить на него не сложно, если рассмотреть

Операционная система OpenBSD ответвилась от NetBSD в 1995 году. По причинам, насколько я смог понять, сугубо личным. Разрабатывается она ограниченным сообществом под главенством (если это слово уместно в данном контексте) основоположника проекта — Тео де Раадта, бывшего до этого одним из основных учатсников проекта NetBSD.

Официальный сайт проекта — http://www.openbsd.org, формальное место базирования — Канада, для преодоления законодательных ограничений США на экспорт мощных криптографических технологий. Поскольку криптография — один из краеугольных камней построения этой системы.

OpenBSD распространяется открыто (то есть в исходниках) и бесплатно (безвозмездно, то есть даром), на основе лицензии BSD. Большая часть системы может быть свободно использована как в личных, так и в коммерческих целях. При этом софт, защищаемый более жесткими лицензиями, принципиально не может быть включен в состав дистрибутива OpenBSD, что гарантирует свободу ее распространения и впредь.

Впрочем, ничего своеобразного, по сравнению с FreeBSD и NetBSD, в условиях распространения OpenBSD нет. Своеобразие это начинается дальше. Во-первых, хотя OpenBSD и ориентирована в значительной мере на Intel-совместимые машины, от NetBSD она унаследовала поддержку весьма широкого спектра аппаратных платформ: Alpha, Sparc, HP300, Motorolla 68xxx, PowerPC.

Вторая своеобразная черта — это пресловутая ориентированность на безопасность. Декларируемой целью разработчиков OpenBSD является разработка лучшей в мире с точки зрения информационной безопастности системы. Не мне судить, насколько это соответствует действительности. Однако такое мнение разделяется не только приверженцами OpenBSD, но и рядом сторонников Linux.

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

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

И все же, почему именно OpenBSD была выбрана в качестве предмета рассмотрения?

Признаюсь, решение это было принято во многом субъективно и волюнтаристически. Систему OpenBSD я полюбил давно и платонически (огласно армянскому радио, — это когда ты любишь, а Платон… эээ… пользует) — прочитав несколько лет назад замечательную статью Алексея Выскубова на эту тему. И тогда же решил, что придет время — и эта операционка будет стоять на моей машине. Что и осуществилось по прошедствии пары лет…

Дополнительным стимулом было то, что по OpenBSD не было (на тот момент времени — весну 2002 г.) практически никаких русскоязычных источников информации. Что, с одной стороны, вселяло некоторую неуверенность, с другой — желание восполнить сей досадный пробел.Конечно, по сведений о NetBSD в Рунете было еще меньше (а именно — нисколько). Однако чисто внешне она казалась мне мрачной и удручающей. И, честно говоря, личное с ней знакомство впоследствии этого впечатления не рассеяло:-).

Наличие русскоязычных источников информации я полагаю одним из необходимых условий для системы, претендующей на звание настольной. По крайней мере, для себя лично — «по ихнему я плохо читаю». Не то чтобы не понимаю вообще, немало и читал в свое время, и даже писал «по аглицки». Однако наедине с англоязычными man’ами и faq’ами чувствую себя несколько неуютно. Как, смею предположить, и многие другие пользователи, вне зависимости от степени владения языком как таковым.

Далее, в пользу OpenBSD склоняло и немалое число весьма благоприятных отзывов в печати. Причём — не от ее апологетов, а от пользователей Linux с многолетним стажем..

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

К тому есть два показания: во-первых, т.н. электронная коммерция, каковая в незащищенном компьютерном пространстве просто не может существовать. А во-вторых, развитие домашних сетей с подключением к Интернету. Третий показатель — общая обстановка, сложившаяся после известных событий 11 сентября 2001 г., но на эту тему я распространяться не буду.

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

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

Наконец, окончательный выбор OpenBSD был сделан при чтении неофициального русскоязычного FAQ про FreeBSD. Который начинался обсуждением вопроса, почему FreeBSD лучше Linux. Во-первых, как уже говорилось, саму постановку вопроса полагаю в корне неверной. Во-вторых, не могу согласиться с аргументацией. В числе коей — утверждение, что демон (daemon — символ FreeBSD) круче пингвина (на мой взгляд, крутыми бывают яйца, а пингвин — существо очень симпатичное). А в третьих, просто не приемлю никакой исключительности. И позиция разработчиков OpenBSD, отказывающихся обсуждать вопрос о превосходстве какой-либо из систем в принципе — мне показалась ближе.

Однако непосредственным поводом для общения с OpenBSD был выход под занавес ушедшего тысячелетия ее новой версии — 2.8. Обзаведясь ею таким образом, и «помолясь, как говорится, Аллаху», я приступил к установке.

Установка

Предыдущая заметка завершилась тем, что я приобрел диск с дистрибутивом OpenBSD. Диск этот, довольно непритязательно оформленный, содержал, тем не менее, полный (за некоторыми исключениями) дистрибутив системы и краткий перечень отличий текущей версии от предыдущей. А главное, вполне позволял установить с него систему.

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

Более того, и вся система вообще может быть установлена по ftp-протоколу. Все, что для этого нужно — загрузочная дискета и какое-либо (даже, говорят, модемное) подключение к Сети. Однако на тот момент этот способ был для меня неприемлемо. Да и вообще он может быть не лучшим выбором для конечного пользователя. Особенно если трафик придется оплачивать из собственного кармана…

Диск OpenBSD 2.8, как стало доброй традицией в последнее время, является загрузочным. То есть необходимости в инсталляционных дискетах нет (хотя при желании и необходимости — образы их на CD имеются). Вставляем его в соответствующий привод — и идем на перезагрузку, не забыв в процессе ее выставить соответствующую опцию в BIOS Setup.

Сообщения о ходе загрузки идут не в обычных черно-белых тонах, а белым по синему — эта цветовая гамма унаследована от NetBSD. Среди них удается разобрать, что система определяет всякие устройства — в моем случае это были плата видеозахвата на чипе BT878, звуковая карта Ensoniq1371, CD-R/RW с IDE-интерфейсом, для которого предлагается эмуляция SCSI. Не говоря уже о таких тривиальных вещах, как винчестеры и видеокарта.

Правда, по завершении загрузки фон опять становится черным. И на нем высвечивается меню установочной программы (install), предлагающее варианты выбора: инсталляция (Install), обновление (Upgrade), выход в командную среду (Shell). Последняя опция заставляет предполагать (вполне обоснованно, как станет ясным из дальнейшего), что инсталляционный CD ROM может выполнять и функции спасательного в аварийных ситуациях.

Обновлять мне нечего, спасаться — не от чего, выбираю инсталляцию. Прочитав в комментарии, что я могу в любой момент прервать ее нажатием комбинации клавиш Control+C. И если после этого решу инсталляцию продолжить, большая часть моих ответов на вопросы системы ею припомнится. Что, забегая вперед, оказалось недалеко от истины.

Инсталляция проходит в текстовом режиме, при минимальной автоматизации процесса. каковой, в сущности, сводится к

  • разметке диска,
  • выбору пакетов, их распаковке и записи на диск,
  • минимальным пост-инсталляционным настройкам.

Именно в такой последовательности и рассмотрим этот процесс, начиная с разметки дисков

Первое, что происходит после выбора инсталляции — запуск собственного варианта fdisk. Который существенно отличается от Linux’ового (не говоря уже о FDISK из MS DOS). Обнаруживая фамильное сходство с fdisk из FreeBSD, что и не удивительно из-за близости их файловых систем (даже именуемых одинаково — ffs, Fast File System). Хотя и здесь нет полного терминологического тождества. Потому остановлюсь на этой процедуре подробнее. В меру своего, несколько ограниченного, понимания, разумеется.

В отличие от Linux, в OpenBSD (как, впрочем, и во Free), разбиение диска осуществляется в два этапа и двумя разными программами. Сначала посредством собственно fdisk создаются физические разделы, partitions (slices в терминологии FreeBSD, они же primary partitions в понимании DOS и Linux). Коих, по известным архитектурным ограничениям PC, не может быть более четырех на одном винчестере.

Затем физические разделы, с помощью Disk Label Editor (точнее, программы bsdlabel, для которой этот редактор меток выступает front-end’ом), делятся на разделы логические, именуемые в русском переводе OpenBSD подразделами, хотя в оригинале и используется тот же термин partitions, что идентично FreeBSD. Это способствует окончательному запудриванию мозгов, хотя момент чрезвычайно серьезный и ответственный. Поскольку подразделы OpenBSD (буду использовать этот термина, как наиболее соответствующий сути явления) объединяют в себе как понятие расширенного раздела DOS (extended partition), так и логического тома внутри него.

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

Действительно, и в DOS, и в Linux Extended Partition — не более чем контейнер для вложенных логических дисков (томов). В Open же BSD, как и во FreeBSD, создается впечатление, что каждый из физических разделов (назови их хоть partition, хоть slice), просто делится на логические части. Однако одна их этих частей присутствует перманентно и удалена быть не может (хотя и помечена как неиспользуемая, unused). Именно она-то и выполняет роль контейнера (=extended partition) для всех остальных.

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

Возвращаемся, однако, к нашим партициям. При наличии в системе более одного винчестера, OpenBSD’шный fdisk для начала предлагает определиться, который из них будет корневым. Приводя их список: в OpenBSD физические диски маркируются как wd0 (Master на первом IDE-канале), wd1 (Slave на нем же) и так далее. Излишне говорить, что я рассматриваю случай ATA-винчестеров — со SCSI все будет несколько иначе, но, за отсутствием личного опыта, вопрос этот замнем.

Затем вопрошается, хотим ли мы отвести под систему полный диск (entire disk) или нет, причем второй ответ отмечен по умолчанию. Если, однако, ответить положительно, стадия fdisk просто проскакивается. И это может показаться самым простым решением, если не стоит задача сохранить какие-либо из имеющихся разделов или создать не-ffs разделы. Хотя итогом может стать некоторые (правда, преодолимые) сложности при сосуществовании OpenBSD с Linux (вероятно, и с Windows — тоже, но за искоренением последнего я этот вопрос не изучал).

Я в конце концов так и остановился на положительном ответе на вопрос об entire disk. Но прежде вдоволь поэкспериментировал (с переменным успехом) и при отрицательном выборе.

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

Следует отметить три обстоятельства. Во-первых, id соответствует шестнадцатиричным номерами типов файловых систем в Linux. Во-вторых, этим он отличен от нумерации таковых, принятой во FreeBSD (там используется десятичная нотация). Ну а в третьих — тип файловой системы, то есть id, — отнюдь не то же самое, что принадлежность системе операционной. Так, разделы и Free, и OpenBSD обозначаются как BSD-разделы. Однако id раздела OpenBSD — A6, тогда как раздел FreeBSD маркируется как A5.

Ниже таблицы разделов содержится указание, что посредством ввода help можно ознакомиться с доступными командами. Чем пренебрегать ни в коем случае не следует — тем более что вместо help можно (как и для всех остальных команд) ограничиться буковкой h. Потому как команды сильно отличаются от таковых в fdisk из Linux. Главное из них: если в Linux команда quit (q) означает выход из программы без сохранения изменений, то здесь, напротив, quit — это запись изменений с переходом к следующей стадии; для выхода же без записи предназначены команды exit (переход к следующей стадии без изменения существовавшей таблицы разделов) и abort (обрыв инсталляции с выпадением в командную среду).

Так что — внимание, внимание и еще раз внимание. Выход из fdisk через quit производит впечатление, что ничего не произошло. И даже ранее существовавшие разделы как бы не изменились (в чем легко убедиться, перезагрузившись в Linux и запустив евойный fdisk). Однако получить доступ к ним не удастся. По крайней мере, обычными подручными методами.

Так вот, на команду help нам выдается ряд вариантов. Во-первых, manual — вызов подробного руководства по fdisk (то есть соответствующего man‘а). Во-вторых, reinit — реинициализация диска, чем-то напомнившая мне команду DOS FDISK /mbr; реально ее результат в том, что все разделы обнуляются, кроме одного, который распространяется на весь диск и приписывается системе BSD; впрочем, это еще следует подтвердить записью (write).

Далее следует команда disk — это переопределение геометрии диска, чего при LBA-режиме (а иного у современных дисков не бывает) лучше, думается, не делать.

Вслед за ней — главная команда, edit — изменение размера и характеристик разделов. В случае ее запуска сначала предлагается ввести его номер, затем указать id (по умолчанию стоит существующий) или, введя ноль, пометить как неиспользуемый (unused — понятия удаления раздела как такового тут нет).

При этом на ввод ? (вопросительного знака) выдается список доступных id; для тех позиций, которые я помню на память, он полностью совпадает со списком, выдаваемым Linux’овым fdisk на команду l: 04 — FAT16 меньше 32M, 5 — Extended Partition DOS, 0b — FAT32, 82 — Linux Swap, 83 — Linux native, a5 — FreeBSD, a6 — OpenBSD.

Определив тип файловой системы, можно указать его размер, задав начальный (offset) и конечный (size) сектора; можно, ответив положительно на предварительный вопрос, оперировать и в терминах CHS (цилиндр/головка/сектор). Однако указать размер в человеческих единицах (Мбайт, Гбайт) на этой стадии еще не удается.

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

Завершить которые можно записью (write), переходом к следующему этапу без записи своих манипуляций (exit), таковым же, но с предварительной записью (quit), или прекращение инсталляции без всяких изменений (abort). Последнее действие доступно и с помощью комбинации Control+C.

Если же мы посредством quit перейдем к следующему этапу (или просто отведем под OpenBSD весь диск), то окажемся в Disk Label Editor, каковой для начала предложит нам свою помощь через ввод вопросительного знака. Из нее мы тут же узнаем о возможности получить список имеющихся подразделов файловой системы (то есть логических разделов) командой print.

В самом простом случае, если был создан всего один физический раздел (или просто под OpenBSD отведен весь диск, посредством выбора entire disk на предыдущей стадии), подразделов у него окажется два: a, занимающий все доступное пространство, и некий мифический подраздел c (помеченный как неиспользуемый, unused). Который, как уже говорилось, уничтожен быть не может: он выполняет функцию extended partition в DOS (и Linux).

В списке же доступных действий далее следуют: a — добавление подраздела, c — изменение размера существующего, b — переопределение отведенного для OpenBSD дискового пространства, r — пересчет свободного пространства, n — определение точки монтирования подраздела, u — отмена последней операции, w — запись произведенных изменений, q — выход с предварительной записью, x — выход без записи изменений.

Очевидно, что не все это доступно сразу. Так, при выборе entire disk невозможно добавить подраздел, потому что весь диск занят единственным физическим разделом, включающим один же существующий подраздел — a. Наряду с которым присутствует и подраздел с, однако он не может быть использован — как я уже говорил, это своего рода аналог Extended Partition из DOS или Linux.

Однако для существующего раздела a можно переопределить размер его командой с (от change), а можно через команду b (от boundary) просто обнулить его, пометив как неиспользуемый.

Если после этого избрать добавление подраздела, то таковой под литерой a будет создан заново, ему будет приписана принадлежность к OpenBSD, а размер можно задать по своему усмотрению, в том числе в мегабайтах (###m, ###M) или гигабайтах (###g, ###G) — здесь это будет воспринято нормально. Точку монтирования подраздела логично определить как /.

Второй добавленный подраздел автоматически маркируется буквой b и по умолчанию обретает статус раздела для своппинга (Swap). Рекомендуемый его размер — вдвое больше оперативной памяти. Как и FreeBSD, OpenBSD использует раздел подкачки иначе, чем Linux, скидывая туда содержимое ОЗУ не при его переполнении, а при первой же возможности. И потому большой объем swap-раздела никак не помешает.

Если есть место и желание — рекомендуется дополнительно создать подразделы /usr, /var, /usr/X11R6 (автоматом им присваиваются литеры d, e и т.д., литера c пропускается). Вообще, в руководстве для платформы Intel предложена следующая схема:

/  35 Мбайт

/usr  229 Мбайт

/var  24 Мбайт

/usr/X11R6 72 Мбайт

Мне такая схема видится весьма спорной. Во-первых, очевидно, что отдельный подраздел /var на настольной машине не нужен (ныне я полагаю, что это не так — по причинам, в обсуждение которых здесь вдаваться неуместно). Во-вторых, /usr и /usr/X11R6 — все равно части единой файловой системы (что упомянуто и в руководстве). И к тому же логичнее тогда создать подраздел /usr/local, куда по умолчанию попадают программы, установленные из портов, дополнительные пакеты и продукты компиляции непортированных исходников. В третьих, на мой взгляд, создание подраздела /home — если и не обязательно, то крайне желательно: все же некоторая дополнительная гарантия целостности пользовательских данных.

Цифры же — сугубо условны. Правда, сказано, что их лучше бы утроить. Я попробовал последовать этому совету, создав (на диске 15 Гбайт) подраздел / в 100 Мбайт, /usr — в 1 Гбайт, swap 512 Мбайт (при RAM 256 Мбайт), отведя остальное пространство под /usr/local и /home. И в результате при установке пакетов получил сообщение о нехватке дискового пространства, естественным образом оборвавшее инсталляцию…

Вероятно, отдельные подразделы (/, /usr, /home), если их не больше четырех, можно создать и на разных физических разделах, как это практикуется в Linux. Просто я, честно говоря, замучился считать сектора: простого калькулятора у меня не былот, компьютерный, естественно — недоступен, вычислять в столбик — скучно, а способность у устному счету я утратил, когда перестал играть в преферанс. Но с точки зрения сохранности данных это, исходя из общих соображений, было бы надежнее.

Завершив дискодробительные действия, следует записать их результаты (w) или выйти из Disk Label Editor с записью (q). У нас запросят подтверждения на запись (с сообщением о создании устройств — wd0a, wd0b, wd0e и так далее) и на определение точек монтирования созданных подразделов в файловой системе в форме [/point, RET, none, or done].

Набрав RET, точки монтирования можно изменить. Если это не нужно, следует набрать done. Здесь, если винчестеров больше одного, последует предложение подвергнуть тому же мучительству другой диск. А после естественного отказа спросят: действительно ли мы готовы к процессу?

Хотя на самом деле спрашивать больше не о чем: все, что могло случится, уже случилось. Хотя полной ясности, когда и куда записываются действия разметки диска, у меня не осталось. Впечатление такое, что в значительной мере они остаются там же, гле и русские слова у японца — в … оперативной памяти, так сказать. Однако там-то они безусловно присутствуют: если теперь выйти из программы инсталляции с помощью Control+C, при следующем ее запуске (даже после перезагрузки) следы всех ранее выполненных действий можно видеть воочию. Хотя, повторяю, с точки зрения некоего стороннего fdisk ранее существовавшие разделы сохранились в неприкосновенности…

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

Однако перед этим в темпе румбы происходит довольно много событий. В считанные минуты создаются файловые системы (то есть происходит собственно разбиение и форматирование), выдается сообщение о их объеме, предлагается сконфигурировать сеть (от чего я за отсутствием оной отказался), ввести пароль для root’а, спрашивается, предполагается ли использование системы X Window.

Наконец, предлагается определить источник инсталляции (ftp, http, стриммерная лента, CD ROM или локальный диск). А по выборе CD (именно этот случай я и рассматриваю) — указать относительную точку монтирования каталога с файлами для установки (по умолчанию — /2.8/i386, на CD такой и в самом деле есть). А затем — выбор компонентов, количество которых просто смешно:

  • base28.tgz
  • etc28.tgz
  • misc28.tgz
  • comp28.tgz
  • man28.tgz
  • xbase28.tgz
  • xshare28.tgz
  • xfont28.tgz
  • xserv28.tgz
  • bsd.tgz

Причем по умолчанию отмечены только два первых, последний и man. Можно, набрав done, с этим согласиться, можно отметить все (all), можно отмечать необходимые по одному:

list имя_файла

Компоненты, включенные ошибочно, можно изъять, набрав

list -имя_файла

Затем все же набирается done, отвергается предложение повторить выбор — и происходит установка.

Как можно было понять из списка файлов, компоненты для установки представляют собой простые архивы *.tgz, содержащие кроме собственно программных, библиотечных и прочих файлов, также инсталляционные скрипты, подобно тому, как это сделано в Linux Slackware. И потому установка сводится к распаковке архивов, их копированию на диск и размещению в соответствующие места.

Собственно установочная процедура осуществляется со страшной научно-фантастической силой. У меня, например, она заняла (при выборе всех компонентов, кроме игр) не более 2-3 минут, я даже время толком засечь не успел… Впрочем, как и все в этом мире, такая скорость имеет свою оборотную сторону, обнаруживаемую при первом же запуске системы.

Вот почти и все. Инсталляционная стадия закончилась, наступает пост-инсталляционное конфигурирование.

Впрочем, этап этот — еще более скомкан, чем установочный. И, в сущности, сводится к выбору часового пояса. В наших условиях это происходит в последовательности: Europe, потом Moscow, в обоих случаях команда list дает список доступных вариантов.

А затем — предложение ввести команду halt и, по останову системы, any key для перезагрузки. Шустро извлекаем инсталляционный CD (об этом нас предупредить забыли) — и ждем, что же выйдет в итоге. Что вышло у меня — расскажу в следующий раз.

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

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

И потому я по первому разу посоветовал бы поэкспериментировать с установкой OpenBSD на отдельный физический диск. В этом случае худшее, что может грозить при ошибке — принудительный выход из программы инсталляции и ее повторный запуск. Что, как я уже говорил, занимает весьма мало времени. А для общего образования совсем не вредно…

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

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

Первые впечатления, первые настройки

Итак, установка системы позади. Настало время знакомства с ней. Каковое и начинается перезагрузкой. В первый раз она у меня проходит не без приключений. Cистема эта вполне способна грузиться самыми различными способами — через такие загрузчики, как lilo или, скажем, grub. А также — и просто со второго жесткого диска, если в BIOS Setup есть соответствующая опция. Что и имело место быть в моем случае.

Загрузка происходит точно так же, как и перед исталляцией. Мелькают сообщения об обнаружении всяческого железа, дисках и прочем. И, наконец, появляется серия не очень понятных сообщений и предложение выбрать тип терминала, по умолчанию — pcvt (напомню, речь идет о версии 2.8; начинаяс 2.9, в качестве системной консоли используется wscons); поскольку не знаю, есть ли у меня на самом деле выбор (да и потому, что это — стандартная для OpenBSD система управления консолью), соглашаюсь. За что в награду получаю приглашение в виде решетки — авторизоваться. Что и проделываю — для первого раза назвавшись root’ом.

Я уже говорил, что инсталляция системы происходила фантастически быстро. И теперь становится понятно, почему: практически никаких привычных для Linux-пользователя приложений в базовом комплекте нет. После авторизации я оказываюсь один на один с системой, в окружении командной среды csh (которую практически не знаю), вооруженный лишь редактором vi (к коему так и не смог привыкнуть). Ни тебе Midnight Commander, ни человечьего редактора…

Попытке запустить Иксы успех не сопутствует — ввиду отсутствия XF86Config. Разумеется, смешно ожидать каких бы то ни было русских букв. Однако на данном этапе это — из области роскошного. Поскольку самая нынче насущная задача — освоить базовые манипуляции и создать сколько-нибудь приемлемую обстановку для работы.

До знакомства с BSD-системами я как-то не осознавал того факта, что такие привычные действия, как пролистывание экрана или переключение на виртуальные консоли — не неотъемлемое свойство системы как таковой, а зависят от консольного драйвера, принятого в данной ОС. Здесь, в OpenBSD, как уже было сказано, он опять-таки свой — pcvt. И начать следует с изучения его особенностей.

Помнится, во FreeBSD я немало времени потратил на поиски способа пролистывать экраны (оказалось, что это делается при включенном ScrollLock). Здесь, правда, экран прокручивается привычным по Linux способом — с помощью комбинации Shift+PageUp/PageDown. Но зато попытка переключиться на другую виртуальную консоль клавишами Alt+F# ни к какому результату не приводит.

Методом научного тыка, однако, можно определить, что для этой цели служит комбинация Alt+Control+F#, как в X Window. С одной стороны, логично — и в графическом, и в текстовом режиме переключатель консолей одинаков. Но, с другой стороны, использовать такую комбинацию одной рукой (если это не лапа неандертальнца) несколько затруднительно. А ведь вторая рука задействована под мышь (для выделения и вставки текстовых блоков, скажем). Впрочем, переживать по этому поводу пока не приходится: мыши в текстовом режиме также нет.

Зато есть второй способ переключения между консолями, правда, только двумя: клавишами Shift+F1/F2. При этом задействуются 5-я и 6-я виртуальные консоли (dev/ttyC4 и dev/ttyC4, соответственно), Почему именно этими — становится ясно после установки X Window: под нее по умолчанию зарезервировано dev/ttyC4, и комбинацией Shift+F1 легко перейти в графическую консоль. Впрочем, из нее на консоли текстовые можно перейти только обычным образом — с помощью Alt+Control+F#, в ответ на нажатие Shift+F2 в X Window не происходит ничего.

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

Я не имею ничего против оболочки csh. Готов даже признать, что синтаксис ее более компактен и логичен, чем в bash (и прочих POSIX shell’ах). Однако последняя — удобней в использовании — одно автодополнение команд и путей клвишей табуляции дорогого стоит. Да и привычней она, в конце концов. Кроме того, желательно иметь какой-никакой редактор, помимо vi.

Благо, установка пакетов в OpenBSD осуществляется очень просто. Даже если не прибегать к знаменитой системе портов (а я, за отсутствием сети, такой возможности не имел), а ограничиться инсталляционным CD.

Который вставляется в соответствующий привод и монтируется обычной командой

mount /dev/cd0a /mnt/cdrom/

На на диске находится каталог /mnt/cdrom/2.8/packages/i386. В нем сплошным списком, без разделения на подкаталоги, свалены многие множества приложений. Устанавливаются они той же командой pkg_add, что и во FreeBSD. Проделываю эту процедуру для bash и редактора joe. Как и во FreeBSD, команда pkg_add по умолчанию устанавливает пакеты в каталог /usr/local/.

Затем в дополнение к имеющимся в файле /etc/shells строкам

/bin/sh

/bin/csh

/bin/ksh

вписывается

/usr/local/bin/bash

Чтобы сменить командную среду, можно воспользоваться командой, например, chpass. Она вызывает системный редактор (по умолчанию — все тот же vi) и позволяет в нем напрямую редактировать учетные заиписи пользователей. Заменяем для root’а

/bin/csh

на

/usr/local/bin/bash

Теперь остается только соотвествующим образом поправить файл .profile в корневом каталоге или в каталоге /root/.profile (первый являет собой символическую ссылку на второй. У меня он вызлядит примерно так:

EDITOR=joe

export EDITOR

PS1='w->>'

alias 'ls=ls -aF'

export LESSCHARSET=latin1

Как нетрудно догадаться, строка EDITOR определяет системный редактор, строка PS1 — вид приглашения командной строки

~/articles/sterra->>

Строка alias указывает, что команда ls по умолчанию должна вызываться с опциями -aF (первый отвечает за вывод всех файлов, в том числе и скрытых, второй — за отметку каталогов знаком \, исполнимых — символом *, и так далее). А последняя строка необходима для русификации программы less, о чем будет сказано в соответствующем разделе.

Если после этого завершить сеанс (командами logout или exit) и авторизоваться заново, то оказываешься в привычном окружении. Разумеется, все эти действия были доступны от лица суперпользователя. Теперь же самое время создать пользователя обычного. Помимо того, что практически работать в качестве root’а — занятие не очень здоровое с точки зрения безопасности, в OpenBSD это еще и не удобно. На консоль суперпользователя выводится большое количество сообщений. Они представляют интерес для администратора системы, но в практической работе только мешают. Конечно, от них можно избавиться (например, перенаправив сообщения в файл). Но лучше все-таки не входить в систему как root без большой на то необходимости. А прибегать для системных манипуляций к временному получению полномочий администратора (с помощью команды su).

Создание обычного пользователя выполняется командой adduser (хотя есть и другие способы). Запущенная от имени root’а первый раз, она для начала запросит подтверждения некоторых общих пользовательских установок по умолчанию, таких, как местоположение домашних каталогов (/home) или командной среды (на выбор — любой из перечисленных в файле /etc/shells).

Ответы на эти вопросы будут сохранены в файле /etc/adduser.conf, и при следующем запуске команды повторяться они не будут. Хотя, естественно, общие пользовательские параметры могут быть изменены прямым редактирование указанного файла.

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

Вслед за этим определяется командная среда для пользователя, его цифровой индентификатор (UID — user identification descriptor) и имя группы, включающей этого пользователя (по умолчанию — совпадает с пользовательским именем).

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

Дело в том, что в OpenBSD (как, впрочем, и во FreeBSD) далеко не каждый пользователь может получить права администратора (каковым наша же скромная персона и является в случае обычной настольной машины) с помощью команды su. Для этого пользователь должен быть явным образом включен в группу wheel, имеющую идентификатор (GID — group identification descriptor) 0. Так что в ответ на указанный вопрос следует вписать wheel.

После этого предлагается ввести пароль (о правилах выбора его распространяться не буду) и повторить его. И в завершение выводится список параметров пользователя в виде:

Name:     exp

Password: ****

Fullname: al

Uid:      1002

Gid:      1002 (exp)

Groups:   exp wheel

HOME:     /home/exp

Shell:    /usr/local/bin/bash

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

Теперь можно авторизоваться в качестве обычного пользователя и настроить для него рабочую среду. Что делается редактированием файла ~/.profile, если для него была выбрана среда bash, или файла ~/.cshrc при использовании среды csh.

Однако на этом настройка среды обитания не заканчивается. И следующее действие опять потребует административных полномочий. Получив их (теперь уже нормально, командой su), отправляемся в каталог /etc и отыскиваем там файл конфигурации начальной загрузки rc.conf. Отвечающий, в частности, за запуск стартовых сервисов и демонов.

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

moused_flags="NO"

и заменить значение по умолчанию на рекомендуемое для мышей с разъемом PS/2

moused_flags="-p /dev/psm0"

или на

moused_flags="-p /dev/cua00"

для сериальной мыши. В результате после перезагрузки системы мышь начинает действовать обычным для консольного режима образом. То есть может использоваться для выделения, скажем, текстовых блоков и вставки их в позицию курсора щелчком средней клавиши. Однако как полноценное указательное устройство (для выбора пунктов меню, например) мышь в консоли работать не будет все равно: аналогов gpm, обеспечивающих это в Linux, в OpenBSD не имеется.

Полноценное манипулирование мышью возможно только в графическом режиме. Для чего необходимо настроить систему X Window — как я уже говорил, на стадии инсталляции никаких настроек такого рода не было, хотя в базовом варианте X’ы и установились.

Конфигурирование Иксов осуществляется штатными средствами этой системы, на которых я останавливаться не буду. Замечу только, что графическая версия Иксового конфигуратора (xf85cfg) может отказаться запускаться. ВУозможная причина — отсутствие свободной (то есть неактивизированной) виртуальной консоли. В этом случае следует обратиться к файлу /etc/ttys, описывающему конфигурацию виртуальных консолей. Нормальный вид его начальной части — нечто вроде следующего:

#

#       $OpenBSD: ttys,v 1.13 1998/06/28 00:48:37 art Exp $

#

# name  getty    type    status          comments

#

console "/usr/libexec/getty Pc" vt220   off secure

ttyC0   "/usr/libexec/getty Pc" vt220   on  secure

ttyC1   "/usr/libexec/getty Pc" vt220   on  secure

ttyC2   "/usr/libexec/getty Pc" vt220   on  secure

ttyC3   "/usr/libexec/getty Pc" vt220   on  secure

ttyC4   "/usr/libexec/getty Pc" vt220   off secure

ttyC5   "/usr/libexec/getty Pc" vt220   on  secure

ttyC6   "/usr/libexec/getty Pc" vt220   off secure

ttyC7   "/usr/libexec/getty Pc" vt220   off secure

Это показывает, что по умолчанию открыто восемь виратуальных консолей, то есть на каждой из них запущен процесс инициализации getty. В то же время активизировано только пять: консоли 5-я, 7-я и 8-я не задействованы для текстового режима и доступны для запуска режима графического.

Если же в файле /etc/ttys активизированы все открытые консоли — это легко исправить, заменив on на off минимум в одной из строк. Буде же возникнет желание запускать два или более сеансов X Window (иногда это полезно), следует озаботиться достаточным количеством свободных виртуальных консолей. Впрочем, конфигурация по умолчанию (как в приведенном выше фрагменте) мне представляется разумной.

Теперь, наконец, можно и заняться конфигурированием X Window. Проходит она без приключений. В моем случае она свелась к установке трехкнопочной мыши (устройство /dev/psm0, стандартное для Linux устройсвто /dev/mouse здесь не проходит), русской 105-клавишной клавиатуры, видеокарты Riva TNT2 и т.д.

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

Обзор возможностей

Я уже упоминал, что при инсталляции системы устанавливается воистину спартанский набор приложений. Однако это — отнюдь не свидетельство убожества. Смонтировав инсталляционный CD ROM и внимательно изучив каталог /mnt/cdrom/2.8/packages/i386, можно обнаружить, что штатных приложений в OpenBSD вполне достаточно, как для консоли, так и для X Window. Правда, они свалены в единую кучу, и никакими комментариями не сопровождаются. Однако в этом и плюс — можно устанавливать только заведомо известное и нужное.

Среди консольных программ — традиционная подборка текстовых редакторов: упоминавшийся ранее joe, jed, pico, emacs, elvis — можно выбрать по вкусу и потребностям. Правда, le, знакомого по FreeBSD, нет. Отсутствует и mcedit — встроенный редактор из Midnight Commander. Впрочем, и самого этого файлового менеджера нет также, на горе любителей детей командира Нортона.

Забегая вперед, отмечу, что вообще с файловыми менеджерами в штатном комплекте OpenBSD — напряженка. Что, с одной стороны, доставляет поначалу определенные неудобства. Но с другой — стимулирует пользователя к активному освоению манипуляций с файлами посредством командной среды. По себе знаю — именно за пару месяцев работы в OpenBSD я напрочь утратил потребность в mc и прочих командирских сиротах. Что намного быстрее и, при некоторых навыках, проще. Да и для здоровья полезней…

Действительно, сколько нажатий на клавиши нужно, чтобы в Norton-подобном файловом менеджере перейти из глубоко вложенного подкаталога каталога /home в столь же глубоко закопанный подкаталог каталога /usr, для примера? Предлагаю произвести этот подстчет читателю. А в командной строке для этого достаточно набрать

cd /usr/subdir1/../subdirN

— и дело в шляпе. Причем, если дело происходит в bash, набирать путь целиком нет необходимости — к нашим услугам волшебная клавиша табуляции. Экономия усилий и времени — налицо. А поскольку частое долбление по клавишам способствует всякого рода туннельным синдромам кисти — сократить его до минимума никак не вредно…

Предвижу возражение — использование чего-нибудь вроде Windows Explorer вообще нажатий на клавиши не требует. Однако тут-то проигрыш во времени, затрачиваемом на продирание сквозь баобабообразные древеса каталогов — вообще огромен. И вполне может довести до судорог в мышцах предплечия…

Однако я отвлекся. Следующее, что следует изучить — это набор оконных менеджеров и визуальных сред. Он победнее, чем в больших современных дистрибутивах Linux. Однако представляется достаточным и разумным.

Помимо классического FVWM, устанавливаемого с системой X Window по умолчанию, имеется его Win-подобный вариант FVWM95, многочисленные вариации на тему TVM, аскетичный Blackbox, сюрреалистичный Enlightenment, наследники NextStep — AfterStep и WindowMaker, предельно быстрый и компактный FLWM, замечательный также простотой настроек. Есть и еще несколько, доселе мне неизвестных.

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

Однако все же выбор визуальных сред достаточен. Я, правда, ограничился двумя — WindowMaker’ом из эстетических соображений и FLWM — из функциональных. Работа с XFce, который мне тоже очень нравится, была затруднительна еще и из-за шрифтов.

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

А можно отредактировать вручную файл /usr/X11R6/lib/X11/xinit/xinitrc, описывающий конфигурацию при запуске сценария startx. Последние строки в нем по умолчанию имеют вид

xclock -geometry 50x50-1+1 &;

xconsole &;

xterm -geometry 80x24 &;

exec fvwm || exec xterm

то есть предписывают загрузку FVWM при старте Иксов. Достаточно, закомментировав или стерев все, имеющее к нему отношение, вписать, например,

exec flwm

или

exec wmaker

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

Комментарий: все сказанное об оконных менеджерах и проч., написано 3 года назад и несколько устарело.

Перейдем теперь к приложениям графического режима. В их числе обнаруживаются: NEdit из текстовых редакторов, Bluefish и Amaya из web-редакторов, GIMP и TGif из редакторов графических, xv для простотра графических файлов. В качестве текстового процессора выступает Lyx. Все эти приложения устанавливаются без всяких затруднений — pkg_add работает безотказно.

Так, параллельно с GIMP’ом и Bluefish установились все потребные библиотеки Gtk. А попутно с Lyx инсталлировались необхождимые для его функционирования комопненты TeX. И все — без единого вопроса, как само собой разумеющееся. Что обусловлено формой хранения пакетов.

Пакеты на диске представлены в бинарном виде в формате *.tgz, подобно FreeBSD. Сходный формат используется также в Linux Slackware и ряде других менее распространенных дистрибутивов. Это в сущности обычный tar-архив, компрессированный посредством gzip. Кроме собственно файлов пакета, в пакете tgz содержатся всякого рода управляющие скрипты для проверки зависимостей, запуска инсталляции, внесения сведений о пакете в базу данных и прочего.

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

Пока речь шла о том, что в OpenBSD есть. Пришла пора сказать и о том, чего в нем нет. А нет практически ни одного нормального файлового менеджера. Про отсутствие сына любимого народом командира Нортона — Midnight Commander, — я уже упоминал. Но и для X Window удалось обнаружить лишь убогий xfm.

Конечно, отсутствие ряда привычных пакетов не фатально. Теоретически рассуждая, большинство доступных в исходниках программ, написанных для Linux или FreeBSD, должны успешно компилироваться и в OpenBSD. Программы же, распространяемые в бинарном виде (офисные пакеты, например) могут быть запущены, как говорят, под OpenBSD в своих Linux-версиях.

Короче говоря, для своих потребностей я обнаружил все критически важные приложения — NEdit для сочинения текстов, Lyx для их оформления, GIMP для работы с растровой графикой. В качестве браузера я использовал lynx, что имеет свой плюс — ведь это самый строгий цензор соответствия спецификации языка HTML. Не допускающий, в отличие Netscape или, тем более, MS Explorer, никакого либерализма.

Конечно, TGif — лишь бледное подобие настоящего векторного редактора. Однако и под Linux с ними не густо. Единственный инструмент такого рода, достойный звания векторного редактора — это рисовальный модуль из офисного комплекта Star- и OpenOffice.

Для правки конфигурационных файлов в текстовом режиме я приспособил joe. В консоли PCVT он работает прекрасно. И не обнаруживает никаких аномалий в поведении клавиш, которые встречаются в некоторых Linux-консолях.

Неожиданно легко решилась и проблема взаимодействия с Linux, как на уровне их сосуществоания и запуска, так и обмена данными.

Подчеркну в заключение, что для всего этого мне не понадобилось ни лезть в Сеть, ни прибегать к системе портов (да и возможности такой не было), ни перекомпилировать ядро. Все требуемое обнаружилось в штатной поставке на инсталляционном CD. Что вдвойне удивительно: мало того, что дистрибутив OpenBSD включает всего один диск, так и тот заполнен чуть больше чем на половину. Поневоле задаешься вопросом: чем умудряются набить 2-4 диска составители Linux-дистрибутивов монстроидального плана?

Установка программ

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

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

О системе портов у меня, за недоступностью Сети, впечателний тогда не было. Так что остановлюсь на ней лишь кратко. Тем более что она во всем подобна своему прототипу — портам FreeBSD.

Порты — система сборки программ из исходных текстов, находящихся на ftp-серверах где угодно в Сети. Адреса этих серверов прописываются в т.н. коллекции портов.

Сама по себе коллекция портов — это архив ports.tar.gz, находящийся на дистрибутивном CD в каталоге ~/2.8 (для текущей версии). Архив этот должен быть переписан на диск (иначе он отказывается распаковываться) и развернут соответствующей командой, например

tar -xzf ports,tar,gz

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

Дальнейшие действия, при наличии постоянного подключения к Сети, очень просты: выбирается нужная категория (например, editors), в ней — подкаталог, соответствующий требуемой программе, скажем, nedit, и после перехода в него дается команда

make install

Все дальнейшее — заботы системы. Она самостоятельно попробует скачать их, причем на каждый port имеется солидный список мест, где можно взять исходники. В частности, они обязательно есть на ftp://ftp.openbsd.org/pub/. Попутно будут скачаны нужные патчи и все остальное необходимое для сборки.

Затем обязательно будут проверены контрольные суммы для скачаных файлов, что позволит избежать всякого рода ошибок при передаче. Затем автоматически выполняется распаковка архивов, на них накладываются все нужные патчи, вызываются все требуемые скрипты конфигурации, команда make для сборки и все прочее, что потребуется. Далее — собственно инсталяция, приложение будет зарегистрировано в системе (в каталоге /var/db) как обычный пакет.

Если собираемый пакет зависит от других, отсутствующих в системе (например, библиотек), они также будут установлены автоматически (через тот же ports). По окончании процесса, можно избавиться от ненужных файлов (типа объектных модулей) командой make clean.

А в дальнейшем открывается неплохая возможность держать все существующие в системе приложения всегда в актуальном состоянии.

Приведенное описание способно вызвать приступ черной зависти у пользователя тогдашних (повторяю, дело происходит весной 2002 г., когда Gentoo был еще в зачаточном состоянии) Linux’ов. Однако реализовать такую систему при отутствии постоянного подключения к Сети несколько затруднительно.

Конечно, исходники можно заблаговременно скачать (по указанным в ports адресам) и разместить в каталоге /usr/ports/distfiles. Однако, согласитесь, что это уже не совсем то: при неудовлетворенных зависимостях (а это может обнаружиться только в ходе установки) потребуется скачивать и дополнительные пакеты. Если же локализация машины и выхода в Сеть разнесены в пространстве (как это имело место быть у меня), идея вообще почти теряет смысл.

Однако отчаиваться не стоит — есть выход в виде коллекции пакетов. Понятие пакета совпадает практически с принятым в Linux, особенно в таких дистрибутивах, как Slackware. Это — откомпилированные бинарные программы, собранные в виде компрессированных архивов tgz. Содержащих, кроме собственно файлов программ, также сценарии для их правильной (в соответствии со структурой каталогов OpenBSD) установки.

На инсталляционном диске пакеты расположены в каталоге /2.8/packages/i386. Правда, свалены они здесь в одну кучу, без всякой систематизации. И никак не аннотированы. Однако некую информацию о пакетах получить можно.

Для этого предназначена утилита pkg_info. Запушенная из этого каталога с аргументом в виде имени пакета (обязательно полного), она выдает краткую его (пакета) характеристику. А также, иногда, некоторые сведения о зависимости данного пакета от других. Правда, в очень общей форме, вроде того, что редактор NEdit требует библиотеки Motif.

Тем не менее, работает система пакетов весьма эффективно. Выбрав требуемый пакет, его можно установить командой

pkg_add имя_пакета

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

По умолчанию пакеты из коллекции устанавливаются в подкаталоги каталога /usr/local (/usr/local/bin, usr/local/lib и т.д.). Что, соответственно, требует прав администратора. Однако пути инсталляции можно и изменить. Для этого команда pkg_add должна быть запущена с опцией -p (prefix — путь для инсталляции пакета).

Установленный с помощью pkg_add пакет фиксируется в базе данных (в каталоге /var/db/pkg. И информация о нем может быть получена той же утилитой pkg_info по полному имени в качестве аргумента, то есть чем-то вроде

pkg_info nedit-5.1.1

Если полное имя вспомнить затруднительно, его можно выудить из того же /var/db/pkg.

При необходимости пакет может быть удален посредством pkg_delete, для чего также следует указать полное имя. Делается это автоматически и довольно чисто, не затрагивая, однако, разделяемые компоненты, необходимые для функционирования других программ. Поэтому кое-какие хвосты неизбежны. Правда, от них можно избавиться запустив pkg_delete с соответствующими опциями (каковые можно посмотреть в man pkg_delete).

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

Если и коллекции пакетов окажется недостаточно для полного счастья — всегда есть возможность прибегнуть к сборке необходимых приложений из исходников. Вероятно, в некоторых случаях это потребует каких-то правок текстов или Makefile. Однако у меня все обошлось малой кровью — те несколько приложений, которые я полагал для себя необходимыми (XNC, например, или fookb) скомпилировались без всяких проблем.

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

Библиография вопроса

Ссылки на бумажные публикации я привел потому, что а) в них обсуждается немало интересных и нетривиальных вопросов, б) они труднодоступны и в) как следствие, мало известны.

Выскубов Алексей. OpenBSD: безопасность превыше всего
Byte/Россия, 1999, 7-8 (11-12), 101-102
Та самая статья, из которой я узнал о существовании OpenBSD. В ней описывыются общие впечатления от установки системы — благоприятные.

Раадт Тео де (Theo de Raadt). OpenBSD: прошлое и будущее
Byte/Россия, 2000, 01 (17), 22-23
Интервью Алексея Выскубова с Тео де Раадтом — одним из основоположников проекта OpenBSD, немного об истории последнего и перспективах.

Дэвис Ноэль (Noel Davis). OpenBSD — хороший пример
Byte/Россия, 2000, 10 (26), 68-69
Взгляд линуксоида на OpenBSD. Обращается внимание на ее сильные, по сравнению с Linux, моменты — безопасность и т.д.