FreeBSD - что это? Преимущества FreeBSD перед Linux Windows. ОС BSD жила, живет и будет жить Bsd системы

Список файловых систем - Это список файловых систем (ФС) и сетевых протоколов, эмулирующих работу файловой системы, с небольшим описанием. Чтобы узнать более, вы можете пройти по соответствующей ссылке. Некоторые старые системы поддерживали только одну файловую систему,… … Википедия

Список операционных систем - Это список известных операционных систем. Операционные системы могут быть классифицированы по базовой технологии (UNIX подобные, пост UNIX/потомки UΝΙΧ), типу лицензии (проприетарная или открытая), развивается ли в настоящее время (устаревшие или … Википедия

BSD - У этого термина существуют и другие значения, см. BSD (значения). BSD (англ. Berkeley Software Distribution) система распространения программного обеспечения в исходных кодах, созданная для обмена опытом между учебными заведениями.… … Википедия

Список LiveCD-дистрибутивов - Это служебный список статей, созданный дл … Википедия

Список Live CD-дистрибутивов - Это служебный список статей, созданный для координации работ по развитию темы. Данное предупреждение не ус … Википедия

BSD (значения) - BSD: BSD семейство операционных систем. Лицензия BSD BSD/OS коммерческая версия BSD. Демон BSD логотип операционных систем BSD. BSD Installer компьютерная программа установщик BSD … Википедия

Список CMF - Это список CMF каркасных систем для управления содержимым (в основном, содержимым сайтов). Как правило, на основе CMF создаются CMS готовые системы управления содержимым, а те, в свою очередь, служат основой для создания полноценных… … Википедия

Список ПО для резервного копирования - … Википедия

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

Unix

Unix - на самом деле, не операционная система.Ну, и да, и нет.В конкретном применении, Unix - это операционная система, разработанная в конце шестидесятых в Bell Labs Кеном Томпсоном (Ken Thompson) и Деннисом Ричи (Dennis Ritchie). Всё последующее время она разрабатывалась и распространялась как коммерческая ОС и исследовательская ОС такими компаниями, как Bell Labs, USG, USDL, ATTIS, USL, Novell, SCO и всеми, кто мог бы выступить с акронимом.Наверное, не будет большим преувеличением сказать, что Unix оказала наибольшее влияние на современную компьютерную индустрию. Любое устройство общего применения и многие специфические устройства использует идеи и концепции и зачастую код систем из родословной Unix.Когда мы произносим слово «Unix», мы чаще всего имеем в виду «общую форму», а не конкретную ОС под названием Unix. Общая форма означает «любую операционную систему, которая дизайном, исполнением и вкусом значительно похожа на систему Unix». То есть все BSD, Linux, SunOS, Tru64, SCO, Irix, AIX, HP/UX и еще сотни и тысячи других.Мне неинтересно вступать в философские дискуссии на тему «сколько ангелов могут танцевать на секущихся концах волос». Пусть этого будет достаточно для понимания того, что когда я говорю «Unix-системы», я имею в виду именно то, о чем вы думаете, когда я произношу эту фразу.
Город Педантов → в той стороне.

Linux

Под словом Linux также кроется несколько вещей. Это ядро, изначально написанное Линусом Торвальдсом (Linus Torvalds) в студенческие годы в Финляндии. С тех пор его перетрясли, выбили, взломали, перекрутили, разогнали, разрубили, причесали, вытоптали и совершали другие манипуляции (порядок неважен, конечно) столько людей, сколько сложно себе представить.Linux - это также семейство операционных систем. В то время как в эту секунду по всему миру ведутся блестящие метафизические дискуссии (я гарантирую это) относительно того, что «Linux - это не операционная система, а просто ядро», или «Правильно говорить GNU/Linux» и так далее, я хочу отмежеваться от этой семантической помойки. Когда я говорю «Linux», я имею в виду Red Hat . Я имею в виду Slackware . Я имею в виду Mandrake . Я имею в виду Debian . Я имею в виду SuSe . Я имею в виду Gentoo . Я имею в виду каждый из 2 кадзиллионов дистрибутивов, в основе которых лежит ядро Linux c аналогичным пользовательским окружением, в большинстве своём построенном на инструментах GNU, мигрирующих по Сети.

BSD

BSD означает «Berkeley Software Distribution». Изначально, это был набор патчей и утилит для официальной Bell Unix, которые разрабатывались группой CSRG в Калифорнийском Университете в Беркли. С течением времени он развивался, заменяя и/или меняя всё больше и больше частей системы до тех пор, пока на каком-то неопределенном этапе не превратился в свою собственную ОС, просто поделившись кусками кода с Bell Unix.Конечно, это всё равно требовало наличие лицензии Bell на использование системы, хотя бы потому, что большая часть кода была написана в Bell. Весь код, написанный в Беркли, тем не менее, был выпущен под лицензией, которая впоследствии стала известна как BSD-лицензия, вольный перевод которой звучит так: «Делай с кодом всё, что тебе взбредёт в голову, просто дай нам об этом знать». Итак, путь почти всего кода BSD в конечном итоге вёл обратно в «официальные» системы Unix: в System III и System V. А обе эти ветви прокладывали свой путь к различным коммерческим форкам Unix.После того, как CSRG (в большинстве своём) распалась и разработка BSD прекратилась, несколько групп подхватили знамя. Одной из них был проект 386BSD, портировавший код BSD на платформу Intel i386. Когда проект 386BSD сошёл на нет, образовались две другие группы, которые поддержали и развили код 386BSD; одной из них был проект FreeBSD, другой - NetBSD. С течением времени некоторые внутренние разногласия внутри проекта NetBSD привели к образованию проекта OpenBSD.Когда я говорю «BSD», я имею в виду несколько вещей. Я имею в виду общий дух BSD и подход к системам. В общем смысле, под вышесказанным понимается 3 находящихся на сегодня в свободном доступе BSD системы (на 2005 год. - прим. перев. ):

• FreeBSD изначально была нацелена на достижение наилучшей возможной производительности на 386-й платформе. Позже к i386 присоединился ряд других платформ, включая Alpha и SPARC, наряду с наследниками i386: Intel Itanium и AMD Opteron. Главная цель проекта - это максимальная надежность и эффективность работы на этих платформах, как в роли сервера, так и в роли десктопа.
• NetBSD нацелена на работу на максимально возможном числе платформ. Её цель - стать самой портируемой ОС на планете, и кажется, для этого честно стараются.
• OpenBSD направлена прежде всего (кто-то скажет «исключительно») на безопасность и тому подобное. Тесная интеграция безопасности, аудита, криптографии и связанные с этим вопросы являются первичными задачами.

Все эти цели, конечно, взаимозаменяемы. Каждая BSD заботится о безопасности и работает над ней. Каждая BSD заботится о производительности и работает над ней. Каждая BSD заботится о портируемости и работает над ней. Внутри группы делятся большими кусками кода. Многие разработчики работают более чем над одной системой.Проницательный читатель заметит, что я не упомянул Mac OS X или лежащий в её основе . Хотя они и построены в большей степени на BSD, верхние слои OS X - это всё-таки чистый Apple. Работая в OS X, как пользователь, вы используете её как MacOS, а не как BSD. Поэтому, несмотря на то, что чисто академически некоторые вещи можно отнести к OS X, особой практической ценности в их понимании нет. Darwin ближе к стандартному понятию BSD, но так как большая часть его пользователей пришли из BSD, можно сказать, что это вне контекста моего эссе. Однако, большая часть общей информации, скорее всего, будет лёгкой для понимания.При обсуждении специфики в моём эссе, я, в основном, буду ссылаться на FreeBSD, потому как с ней я работаю и знаю её лучше всего. В некоторых специфичных аспектах будут существенные различия. Общие стороны, скорее всего, будут одинаковыми для всей группы. С философской точки зрения, все BSD очень похожи, в отличие от методологии Linux. Как бы то ни было, это эссе в первую очередь философское.

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

Отличия Linux и BSD. Основное отличие Linux и BSD то, что Linux по сути ядро, а BSD операционная система, которая включает в себя ядро. Ядро Linux применяется для создания дистрибутива Linux после сборки других компонентов. Ядро Linux с GNU программами и прочим это уже полноценная ОС GNU/Linux.

Талисман для Linux – , а для BSD – мультяшный демон.

Пользователям Linux предоставляется огромное количество дистрибутивов. Все они есть производными некоторых популярных дистрибутивов Linux, к примеру, Debian, Gentoo, Red Hat, Slackware и т.д. Также существует множество отдельных дистрибутивов Linux как Solus, Puppy Linux и т.д.

BSD как самостоятельная операционная система больше не существует, но она обозначает существующие производные BSD. На сегодня существуют FreeBSD, OpenBSD, NetBSD, DragonFly BSD и другие. FreeBSD рассчитан на обычных пользователей, у которых не так много опыта в области системного администрирования.

В готовом виде предоставляются пакеты для Linux. Самые популярные форматы: DEB и RPM, а чтобы их установить необходим APT/yum.

С BSD все по-другому. Для установки программ необходимо использовать порты. Их насчитывают около 25000. В отличии от пакетов они имеют открытый исходный код, который компилируется на ПК. А это не особо удобно для обычных пользователей. Но количество готовых бинарных пакетов, которые устанавливаются через pkg, неугомонно растет.

В BSD программ недостаточно много, поэтому разработчики системы контролируют ситуацию с помощью применения совместимости пакетов, чтобы запускать Linux приложения на BSD. Но BSD поддерживает популярные DE, например, KDE и GNOME, и много других.

Большое количество ОС так или иначе имеют отношение к семейству UNIX. Ранее UNIX был закрытой ОС. Потом большая часть системы была переписана на языке Си.

BSD (с закрытым исходным кодом) и ее производные являются непосредственными наследниками UNIX. Но уже FreeBSD, NetBSD и другие BSD – подобные имеют открытый код.

Как известно, ОС, которые имеют открытый исходный код, не имеют нормальный поддержки оборудования. В таком случае лидируют Windows и MacOS.

Операционные системы Linux и BSD защищены разными видами лицензий, и это также их существенное различие. GNU/Linux под GNU GPL (General Public License). ОС на BSD имеют BSD лицензию, она еще имеет название FreeBSD лицензия.

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

BSD считаются стабильными и надежными, так как они редко обновляются новыми “фишками”. Linux же наоборот старается всегда удивить пользователя новыми полезностями для работы.

Linux наиболее распространен на ПК чем FreeBSD. Потому что, чтобы работать с BSD необходимы определенные технические знания, к тому же GNU/Linux имеет намного лучшую поддержку оборудования. Важно также то, что существует поддержка сообщества Linux, которая немаловажна.

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

И BSD и Linux можно установить на наших ! Дистрибутивы LINUX 2018. Что актуально ?

8396 раз(а) 12 Сегодня просмотрено раз(а)

Источник: mindw0rk

В книге истории BSD намного больше страниц, чем в истории Linux. Беря начало в далеких семидесятых, BSD пережила эпоху UNIX-мейнфреймов и расцвета самых разнообразных UNIX-систем. Она и по сей день доказывает свою вечность и востребованность в лице современного поколения свободных, в духе opensource-времени, дистрибутивов. Этой осенью выходит новый релиз FreeBSD 5.3, первый в стабильной ветке 5 и знаменующий переход на новый качественный уровень. Не за горами релиз NetBSD 2.0, имеющий примерно такое же значение. И то и другое - безусловно, настоящее событие для всех bsd"шников. Эта статья - посвящение легендарной операционной системе.

Профессор из Беркли

Шел 1973 год. Время начала расцвета глэм-рока, вьетнамской войны и операционной системы UNIX. Той самой, первоначальной, от AT&T (Bell Labs), которая успела с момента первого релиза 1971 года (UNIX Time Sharing System First Edition, или просто UNIX System V1) дорасти до четвертой версии, выпущенной в ноябре. И в ноябре же, на симпозиуме «Принципы проектирования операционных систем» в университете Пурдью (Purdue) авторы UNIX Кен Томпсон и Деннис Ритчи выступили со свом первым докладом на тему новой ОС. На этом симпозиуме присутствовал профессор Боб Фабри из Калифорнийского университета Беркли, которого настолько поразила красота операционки, что он сразу же заказал копию дистрибутива на магнитной ленте для своего университета. О коммерческом применении UNIX тогда не было и речи, AT&T свободно раздавала исходные тексты своей системы для изучения в образовательных учреждениях.

Для установки и изучения UNIX совместными усилиями факультетов компьютерных наук, математики и статистики университет Беркли приобрел новый компьютер PDP-11/45 от DEC. И в январе 1974 года аспирант Кейт Стэндифорд уже вставлял свежеполученную ленту с UNIX System V4 в считывающий привод терминала. Как правило, в университетах, получивших копию UNIX, установку системы выполнял сам Кен Томпсон. Но в Беркли решили обойтись силами своих студентов. Через какое-то время помощь Кена все-таки понадобилась - система периодически аварийно рушилась. Вместо того, чтобы отправиться в Беркли, Томпсон позвонил Стэндифорду и указал тому соединить модем с телефоном, чтобы иметь возможность удаленно отлаживать систему. Выяснилось, что проблема была в драйвере дискового контроллера - PDP-11/45 оказалась первой в практике Томпсона машиной, имевшей два диска на одном контроллере, на что драйвер не был рассчитан. Так началось сотрудничество Bell Labs и Калифорнийского университета по совершенствованию UNIX.

Позже в университете появился еще один компьютер под управлением UNIX. Машины в Беркли, как и в других вузах того времени, работали строго по расписанию - кому-то был нужен UNIX, кому-то - RSTS, собственная операционка от DEC, ставившаяся тогда на все PDP. С 8 утра до 4 вечера на компьютере работал UNIX, а затем до полуночи - RSTS. Это очень не устраивало профессоров Юджина Вонга и Майкла Стоунбрейкера, которых настолько восхитили возможности новой ОС, что они захотели побыстрее перенести на нее разрабатываемую ими крупную базу данных INGRES. Машинного времени постоянно не хватало, и весной 1975 года в Беркли появился еще один DEC-11/40 под управлением вышедшей к тому моменту UNIX System V5. К осени INGRESS под UNIX разошлась в количестве нескольких сотен экземпляров, в результате чего Беркли получил репутацию университета, в котором рождаются действительно крупные проекты.

Интерес студентов к UNIX был поистине огромным, и осенью 1975 года Фарби со Стоунбрейкером решили приобрести новую модель PDP-11/70, которая была гораздо мощнее предыдущих. В это же время Кен Томпсон, выпускник Калифорнийского университета, решил ненадолго навестить свою альма-матер и захватил с собой самую последнюю на тот момент версию UNIX - System V6, которую установили на новую PDP-11/70.

Рождение BSD

Итак, к 1976 году в Беркли было уже несколько машин под управлением UNIX. Но о серьезной ее доработке никто не помышлял, пока системой не заинтересовались два студента, только что закончившие обучение, - Билл Джой и Чак Хэйли. Поначалу они проводили дни и ночи за PDP-11/70, работая над компилятором и языком Pascal, в итоге сделав его лучшей средой для обучения студентов программированию. Затем, после замены текстовых телетайпов на экранные терминалы, Джой обнаружил, что текстовый редактор ed, использовавшийся тогда, их уже не устраивает. И он приступил к работе над своим редактором, который назвал ex.

В 1976 году, после отъезда Кена Томпсона Джой и Хэйли стали самостоятельно ковыряться во внутренностях ядра UNIX. Результатом этого стали небольшие изменения в коде и несколько исправлений. Эти два парня стали первыми кернел-хакерами из Беркли.

В 1977 году Билл Джой, осознав, что одними исправлениями не обойтись, начал делать свой дистрибутив. Так 9 марта 1978 года появился «Berkeley Software Distribution» - первый релиз операционной системы Беркли. Он включал в себя пресловутую Pascal-систему со всеми исходными текстами и редактор ex. В течение следующего года по разным вузам разошлось 30 копий новой ОС. Затем на PDP Беркли вновь обновили устройства ввода, поставив новенькие терминалы ADM-3a, и Джой решил написать текстовый редактор, который использовал бы всю визуальную мощность новых мониторов. Так родился великий и ужасный vi (visual editor). Кроме того, Джой решил проблему совместимости вывода на терминалах разного типа, написав не менее знаменитую библиотеку termcap. Все это вошло во второй релиз ОС, «Second Berkeley Software Distribution», вышедший 10 мая 1979 года. Позже имя сократили до лаконичного 2BSD. Финальная версия второго релиза, 2.11BSD, с улучшениями и дополнениями, сделанными в результате обширного тестирования системы в нескольких университетах, была установлена на сотни PDP-11 машин по всему миру. По сути, состоялось первое серьезное клонирование классического UNIX. Весьма удачное клонирование.

В 1978 году шестнадцатибитные PDP уже не удовлетворяли многих хакеров, им на смену пришли VAX - новые мощные машины от DEC, работающие под ОС VMS. Разумеется, в Bell Labs портировали свою, уже седьмую версию UNIX на новые машины, однако их система не использовала всех преимуществ виртуальной памяти VAX. К разрешению этой проблемы привлекли кернел-хакеров из Беркли во главе с Биллом Джоем. Джой был поражен возможностями нового железа - эта система оставляла PDP-11 далеко за бортом. Так он начал портировать 2BSD на VAX.

Пока его коллеги Питер Кесслер и Кирк Маккусик портировали Паскаль, Джой переписал ex и vi, свою новую командную оболочку C shell и остальные утилиты. В итоге, в 1979 году Беркли выпустила законченную сборку 2BSD под VAX.

Одновременно с этим событием Bell Labs решила поставить UNIX на коммерческие рельсы и основала подразделение по подготовке и выпуску стабильных релизов. UNIX перестал быть исследовательским проектом, представляя теперь коммерческий продукт AT&T. Роль центра разработки UNIX, ранее принадлежавшая Bell Labs, теперь перешла к Беркли.

К 1979 году американское агентство передовых оборонных разработок DARPA (Defence Advanced Research Projects Agency) столкнулось с проблемой устаревания многих компьютеров, составляющих ее знаменитую сеть ARPANET. В случае замены потребовалось бы портировать все программное обеспечение на новые машины. Сказывалась разношерстность сети - разные машины, разные операционные системы. Было ясно, что для дальнейшего масштабирования и развития сети необходима стандартизация. Так как выбор единой аппаратной платформы для построения сети представлялся труднореализуемым, стандартизацию решили провести на уровне ОС. Разумеется, в качестве единой операционной системы был выбран UNIX, который, казалось, можно портировать на самое невообразимое железо.

Осенью 1979 года профессор Фарби прослышал про интерес DARPA к UNIX и предложил услуги своего университета. Вышедший в декабре того же года релиз 3BSD подтвердил, что новая система как нельзя лучше подходила нуждам военных, и в апреле 1980-го Беркли получила полуторагодичный контракт DARPA. Под контрактные работы была создана организация Computer System Research Group (CSRG) - отделение университета, куда входили студенты и профессора, занятые работой над BSD. Результат не заставил себя ждать - в октябре того же года выходит 4.0BSD с почтовой системой, планировщиком задач и многими другими улучшениями. DARPA осталась довольна результатом и продлила контакт, увеличив инвестиции почти в пять раз.

Следующий релиз BSD должен был, по логике, называться 5BSD. Однако в AT&T сочли, что пользователи могут спутать 5BSD c их текущим коммерческим релизом, System V (5). По этой причине Беркли решила ввести дополнительную нумерацию релизов. Так, следующими были 4.1BSD и 4.2BSD.

Продленный контракт с DARPA предусматривал создание новой быстрой файловой системы (Fast File System), чтобы эффективно использовать возможности новых жестких дисков, поддержку процессов с многогигабайтным адресным пространством, создание механизма гибкого межпроцессного взаимодействия, а также единого интегрированного стека сетевых протоколов для общения машин в ARPANET.

Джой занялся межпроцессным взаимодействием (что впоследствии получило название UNIX sockets), реализацию файловой системы взял на себя Маккусик, а Роб Гурвиц реализовал TCP/IP, которую затем включили в ядро BSD. Тогда же были написаны сетевые утилиты для взаимодействия по сети: rcp, rsh, rlogin, rwho. Получилась настолько хорошая система, что разработчики решили выпускать ее не только для DARPA.

Вслед за промежуточными релизами 4.1a и 4.1b была выпущена 4.2BSD. Популярность нового релиза оказалась ошеломляющей - за полтора года он разошелся тиражом более тысячи копий! Со своей новой файловой системой FFS и интегрированной поддержкой сети ОС из Беркли оставила UNIX System V далеко позади. И хотя потом многие возможности 4.2BSD были портированы в System V, BSD долго оставалась лидером на рынке UNIX-систем.

Весной 1982 года Джой, наверное, посчитал, что основное уже сделано, потому ушел в Sun Microsystems. Тем не менее, в системе еще многое предстояло отладить, о чем свидетельствовали тесты производительности и багрепорты. Это нормальное явление, когда ОС становится популярной. Маккусик сотоварищи остались в CSRG, занимаясь очисткой багов и подготовкой нового релиза. 4.3BSD была выпущена через долгие 4 года в июне 1986. Многие пользователи за это время возвратились к UNIX System V, успевшей приобрести поддержу сети и многие другие возможности, появившиеся в 4.2BSD. Так что новый релиз оси Беркли позволил поправить ее пошатнувшиеся позиции.

В конце восьмидесятых эра VAX подходила к концу. Предвидя это, Джой еще во время подготовки релиза 4.1 занимался разделением кода ядра на машинно-зависимые и независимые части, чтобы в дальнейшем их было проще адаптировать под новые процессоры. Сменить VAX должна была архитектура Power 6/32 от «Computer Consoles, Inc.», и в Беркли даже выпустили 4.3BSD под кодовым названием «Tahoe», закончив работу Джоя по разделению кода. Однако популярности новая платформа не снискала и вскоре умерла. Как бы то ни было, именно она стала катализатором завершения работ по созданию настоящей портируемой системы. Это впоследствии сыграло свою роль, когда BSD портировали на множество аппаратных платформ.

Сеть, BSD-лицензия и Великий Суд

Конец восьмидесятых годов - это расцвет всевозможных юниксовых ОС и сетевых технологий. К этому времени уже стало ясно, что без сети дальше никуда, поэтому основное внимание уделялось сетевым компонентам. Угадай с трех раз, у кого в те годы была лучшая реализация стека протоколов TCP/IP? Вот почему сообщество было так заинтересовано в свободном использовании исходных кодов операционки Беркли. CSRG, следуя традициям исследовательского духа, всегда выпускал свою систему вместе с исходниками, но, к сожалению, не мог предоставлять право другим организациям использовать их для применения в своих продуктах. Этого не позволяла лицензия, по которой AT&T распространяла исходники своего UNIX. А BSD, хоть и была самостоятельной системой, основывалась на коде от Bell Labs. Так что любой пользователь BSD был обязан купить лицензию на UNIX у AT&T. Но стек TCP/IP для BSD был целиком разработан в Беркли, поэтому летом 1989 года принимается решение выпустить так называемый «Networking Release 1», или 4.3BSD Net/1 - по сути, кусок операционной системы, содержащий код сетевого стека протоколов и сопутствующих утилит. Код выпустили под новой лицензией, которую так и назвали - BSD License. Согласно ей любой мог свободно загрузить исходные тексты и использовать их в своих целях, в том числе коммерческих, без каких-либо отчислений Беркли, лишь только сохранив копирайты в тексте файлов и указав в документации к своему продукту, что он основан на коде из Беркли.

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

И вскоре Беркли выпустил уже вторую версию своего сетевого релиза. В нем появились кардинальные изменения в подсистеме виртуальной памяти (код взят из проекта Mach университета Карнеги-Мелона) и новая сетевая файловая система (NFS). В обоих случаях использовались готовые наработки дружественных университетов, что показало выгоду и ценность BSD-лицензии - вместо того чтобы писать что-то с нуля, можно использовать то, что написали другие, в ответ предоставляя им свои наработки. Таким образом не было нужды изобретать велосипед, и время тратилось на новые разработки.

Новый релиз BSD должен был иметь порядковый номер 4.4, однако в Беркли решили предварительно протестировать изменения, выпустив в начале 1990 года релиз 4.3BSD-Reno.

Вскоре после этого один из разработчиков BSD Кейт Бостик вспомнил про удачный опыт с сетевым релизом и отметил, что неплохо бы выпустить и остальную часть системы под BSD-лицензией. Однако для этого потребовалось бы переписать огромное количество утилит из библиотек, пришедших в BSD из AT&T UNIX. Ведущие на тот момент разработчики Кирк Маккусик и Майк Карельс скептически восприняли идею - уж больно велик был объем работы. Но Бостик не сдавался. Он решился на эксперимент, который в какой-то степени затем был повторен Линусом Торвальдсом и стал основой развития систем с открытыми исходниками. Бостик призвал BSD-хакеров со всей сети переписать UNIX-утилиты, руководствуясь лишь инструкциями того, что те должны делать. 18 месяцев спустя практически все утилиты и библиотеки были переписаны. У Беркли теперь была действительно своя система. Оставалось переписать ядро, которое к тому времени уже в значительной мере было своим. И Маккусик, Карельс, Бостик, забросив все дела, принялись строчка за строчкой изучать файлы ядра, оставшиеся со времен AT&T UNIX. В итоге осталось всего шесть файлов, которые, по мнению разработчиков, так просто переписать бы не удалось. Их решили оставить на месте и в июне 1991 года Беркли выпустила «Networking Release 2» (4.3BSD Net/2). Теперь практически вся система (кроме шести файлов ядра) была абсолютно доступна всем желающим под самой дружественной в мире BSD-лицензией. Это и предопределило будущую вечную жизнь BSD.

В девяностых годах IBM PC окончательно захватила нишу недорогих компьютеров. Спустя полгода после второго сетевого релиза, Билл Джолиц начал портировать Net/2 на архитектуру i386, переписав недостающие 6 файлов. Он назвал свою работу 386/BSD и распространил ее по сети. Затея оказалась удачной, и вскоре группы пользователей 386/BSD занялись написанием патчей и усовершенствованием системы. Так стартовали современные проекты NetBSD и FreeBSD.

Сам Джолиц вместе с некоторыми членами CSRG ушел продвигать BSD в коммерцию, основав компанию BSDI (Berkeley Software Design, Inc.). Благо, код, выпущенный под BSD-лицензией, позволял продавать дистрибутив без исходных кодов. BSDI активно рекламировала свою новую систему BSD/OS как UNIX, и всем заинтересованным предлагалось звонить по телефону 1-800-ITS-UNIX. Однако компанию AT&T возмутил такой шаг, и она в лице Unix System Laboratories (USL), подразделения по продаже и разработке UNIX, потребовала немедленно прекратить рекламировать продукт BSDI как UNIX и убрать номер телефона. Условия были выполнены, и BSDI даже сменила рекламу своего продукта, объясняя, что это не UNIX. Однако USL этого было мало, и она подала в суд на BSDI, обвинив компанию в продаже кода, принадлежащего Bell Labs. В ответ BSDI предоставила доказательства, что ее система - это не что иное, как копия продукта, свободно распространяемого университетом Беркли плюс шесть дополнительных файлов, написанных программистами компании. За код Беркли BSDI, ясное дело, ответственности не несла, так что победа в суде была за ней.

USL не унималась и подала в суд на Калифорнийский университет в лице CSRG. По прошествии месяцев долгих разборок было решено непосредственно сверить код операционных систем, чтобы найти в BSD куски кода USL. В итоге из Net/2 были удалены 3 файла, оставшихся со времен UNIX System V5, и еще в 70 файлов были добавлены копирайты USL. Все остальное к тому времени уже было переписано хакерами из CSRG в рамках подготовки Net/2. Свободная система сохранила свободу!

По итогам судебных разбирательств окончательная версия релиза BSD вышла под названием 4.4BSD-Lite летом 1994 года, под той же лицензией, что и Net/2. Важным решением суда был тот факт, что USL не имела права судить какую-либо организацию, использующую 4.4BSD-Lite в качестве базы для своей ОС. Поэтому все разработчики, уже выпускавшие свои релизы на основе Net/2 (а к тому времени уже существовали NetBSD и FreeBSD, базировавшиеся на 386/BSD), были вынуждены переключиться на новые исходные тексты. Что они и сделали за самое короткое время.

4.4BSD-Lite2. BSD is dead, Long Live BSD!

2 июня 1995 года вышла 4.4BSD-Lite Release 2 с небольшими улучшениями и дополнениями. После этого последнего релиза группа CSRG университета Беркли объявила о своей отставке. За 20 лет BSD из клона UNIX превратилась в самостоятельную ОС, подарив миру надежную файловую систему, эталонную реализацию стека TCP/IP, систему печати LPD и, что самое главное, свободу. После роспуска CSRG BSD не думала умирать. FreeBSD к тому времени стала лидирующей unix-like ОС на intel-машинах, NetBSD портировали на множество платформ, BSD/OS предлагала отличные коммерческие решения. Беркли выполнили свою миссию, пустив UNIX в свободное плавание по сетевому океану, и плавание это будет длиться вечно.

Отличия BSD и Linux

Если ты прочитал статью, ты, наверное, сам сможешь ответить на этот вопрос. BSD - это целая операционная система с 30-летней историей, тогда как Linux - всего лишь ядро, само по себе к употреблению не пригодное. Поэтому, говоря о дистрибутивах Linux, корректнее называть их GNU/Linux - операционная система GNU с ядром Linux. GNU - это фонд программного обеспечения, который появился в 80-ые годы с целью создать свободный UNIX, распространяемый под GPL-лицензией. Отец GNU и GPL - Ричард Столлман.

Если говорить о технической стороне дела, то в BSD, в отличие от классической UNIX System, нет понятия уровня запуска (runlevels), а есть только два режима - однопользовательский (single user) и многопользовательский (multi user). Соответственно, имеется разница в расположении управляющих скриптов и в поведении некоторых утилит. Наконец, BSD имеет исторически сформированную иерархию файловой системы, набора сервисов и скриптов, тогда как в Linux все упомянутое скачет от дистрибутива к дистрибутиву, как разработчики пожелают.

По аналогии с неофициальным термином «*nix», обозначающим все UNIX-системы, существует термин «xBSD», который употребляется в случае, если речь идет не о конкретном проекте, а о семействе дистрибутивов в целом.

BSD-лицензия

BSD-лицензия, наверное, самая либеральная за всю историю. Ее требования можно сформулировать в трех пунктах:

Не утверждай, что ты написал это. Сохраняй наши копирайты в исходных текстах. Если распространяешь свой продукт только в бинарном виде - указывай в сопроводительной документации, что он использует код из Беркли.

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

Не предъявляй претензии, если что-то не заработает. Нет никаких гарантий, код предоставляется AS IS, на свой страх и риск.

Все знают, что символ BSD - симпатичный демон. Появился он в 1988 году с легкой руки Кирка Маккусика, придумавшего талисман для 4.3BSD. Разумеется, тот, первоначальный демон выглядел не совсем так, как современный, символизирующий FreeBSD. Ознакомиться с его историей в картинках можно по адресу www.mckusick.com/beastie/index.html. Эви Немет в своей классической хрестоматии «Unix System Administration Handbook» так объясняет происхождение этого талисмана: «Многие люди пугаются и думают, что демон в данном случае - это нечто сатанинское. Однако это не demon, а daemon, в греческой мифологии означающий примерно то же, что нынешний ангел-хранитель, добрый дух». Как же зовут этого милашку? Маккусик утверждает, что у демона нет имени, и это предмет его особой гордости, но если ты хочешь, можешь называть его Beastie.

Введение

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

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

Образ ядра системы содержит все необходимое для чистого bootstrapping’а. Однако выполнить его таким образом можно только с носителя без файловой системы. И потому прямой запуск ядра, насколько я знаю, используется только при загрузке с дискеты. При обычном же старте ОС с винчестера в этом деле участвует и некая внешняя сила — специальная программа, называемая загрузчиком. Она загружает ядро системы, отвечает за определение оборудования, подгрузку объектных модулей (загружаемых модулей ядра) и монтирование корневой файловой системы (в режиме «только для чтения»). Ядро же тем временем запускает системные (то есть не связанные с исполняемыми файлами) процессы, управляющие виртуальной памятью, буферами, страницами памяти и т.д., вплоть до swapper’а, а по завершении — свой и первый «обычный» (то есть ассоциированный с исполняемым файлом на диске) процесс init (/sbin/init).

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

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

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

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

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

Так что давайте проследим основные стадии загрузки и инициализации DragonFly и посмотрим, что в них подлежит настройке, а также где и как (а главное — зачем) в них можно вмешаться.

О загрузке и загрузчиках

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

На самом деле любой загрузчик включает в себя две или даже три относительно независимые части — даже если он распространяется в виде единого пакета, как Lilo или GRUB. Чтобы убедиться в этом, представим себе, как происходит запуск машины на «железном», так сказать, уровне (имеется ввиду — intel-совместимой персоналки, на иных архитектурах все обстоит несколько иначе).

Перво-наперво после включения питания запускается программа, прошитая в ПЗУ компьютера (BIOS). Она выполняет проверку железа, после чего отыскивает носитель, установленный в BIOS Setup в качестве первого загрузочного устройства (для определенности — винчестер), на нем — первый физический блок, содержащий так называемую главную загрузочную запись (MBR — Master Boot Record).

Содержимое MBR — это, во-первых, таблица дисковых разделов, тех самых четырех, в один из которых мы ранее установили DragonFly. А во-вторых — некий код, принимающий на себя управление от BIOS по окончании его работы. В стандартном MBR — том, что записан на «свежевкрученном» винчестере или восстанавливается после DOS-команды FDISK /mbr , — этот код только и может, что отыскать первый физический раздел диска (primary partition) и передать управление на его загрузочный сектор. Чего вполне достаточно для загрузки операционок вроде DOS или Windows 9X/ME с первого (или единственного) раздела. Но явно мало в любом другом случае — например, если на диске установлено несколько ОС, которые, естественно, не могут уместиться в одном разделе.

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

Подобно MBR, загрузочный сектор раздела (Boot Record — уже не Master!) содержит информацию о его разметке (Disk Label), зависящие от используемой в данной ОС ее схемы, и управляющий код, принимающий эстафету от программы, записанной в MBR. И этот код — вторая составная часть загрузчика. Правда, и ее возможности также не могут быть богатыми — ведь размер загрузочного сектора раздела составляет те же 512 Кбайт. И потому на нее возлагается одна-единственная функция — передать управление программе, лежащей за пределами загрузочного сектора. Которая, собственно, и должна опознать корневой раздел ОС и несомую им файловую систему, после чего, прямо или опосредованно, загрузить ее ядро.

Легко догадаться, что первые две составляющие загрузчика, в сущности, не имеют отношения ни к какой операционке, и не являются частями файловой системы вообще. А вот с третьей — возможны варианты. Она может входить в файловую иерархию загружаемой ОС, как Lilo, или представлять собой нечто вроде самостоятельной мини-ОС, как GRUB (не случайно его настоятельно рекомендуют устанавливать в собственный дисковый раздел, не монтируемый по умолчанию к корню любой из загружаемых им операционок). А как обстоит дело с устройством загрузчика нашей героини — DragonFlyBSD?

Стадии загрузки

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

Должен покаяться — за несколько лет общения с FreeBSD и эпизодическим знакомством с ее сестрами (OpenBSD и даже NetBSD) у меня как-то не было повода разбираться с устройством их загрузчика. Ну грузит он прекрасно родную систему — и замечательно (например, FreeBSD). Грузит также и другие BSD-системы — еще лучше. Что без напряга и Linux может загрузить — так вообще здорово. А то, что еще и на загрузку Windows способен — это уж просто бесплатное приложение…

Как и пребывал бы я в счастливом незнании, если бы как-то, в связи с установкой FreeBSD на ноутбук Toshiba, не пришлось покопаться немного с опциями BSD Loader. И тут оказалось, что это — программа с мощными интерактивными возможностями, да еще и обладающая возможностью настройки. Не сравнить с GRUB’ом, конечно, но если не экспериментировать с многочисленными операционками на многих винчестерах, — функций loader’а оказывается более чем достаточно. Что я и попытаюсь продемонстрировать ниже на примере ОС DragonFlyBSD. Однако почти все сказанное имеет силу и для всех других BSD-систем (а для FreeBSD — и без оговорки «почти»).

Основная особенность загрузчика DragonFly (хотя почти все сказанное имеет силу и для всех других BSD-систем — а для FreeBSD и без оговорки «почти»), отличающая его от Lilo и, в меньшей степени, GRUB, — то, что он не маскирует свою многокомпонентную природу, включая четыре (почти) самостоятельные программы.

Первая часть загрузчика (т.н. boot0) — это программа, записываемая при инсталляции системы в загрузочный сектор диска, с которого осуществляется загрузка машины согласно установкам BIOS. Обычно это Master на первом IDE-канале (о SCSI-дисках здесь речи не будет), но возможны варианты (например, при наличии аппаратного ATA RAID или дополнительных ATA-контроллеров). Эта программа отвечает за первую стадию этапа загрузки, а которой происходит чтение таблицы первичных дисковых разделов, вывод их списка (если разделов более одного), некоторого периода ожидания для выбора пользователем (по умолчанию загрузочным будет раздел, выбранный в предыдущем сеансе работы) и после такового (или по истечении фиксированного периода ожидания), передачи управления коду, записанному в загрузочном секторе выбранного (или умолчального) раздела. Выбор раздела осуществляется нажатием клавиш F1 —F4 ). Если дисков два, нажатие клавиши F5 просто передаст управление на загрузочный сектор второго из них — а там уж события потекут в зависимости от того, что в нем записано: читать разделы на втором физическом диске boot0 сам по себе не способен.

Список разделов для выбора включает их имена в соответствии с идентификаторами типа файловой системы, например:

F1 DOS F2 Linux F3 BSD F5 Drive 1

До недавнего времени BSD Loader не мог ни опознать логические разделы внутри Extended DOS, ни загрузить с них какую-либо операционку. Однако ныне положение, видимо, изменилось: это можно заключить из сообщений о возможности установки DragonFlyBSD в расширенный раздел (единственной, насколько мне известно, из BSD-систем, на это способной). А можно ли представить себе установку системы без возможности ее загрузки штатными средствами?

В принципе наличие первой части BSD-загрузчика не является обязательным: его вполне может подменять загрузчик Linux (тот же Lilo, передающий управление на загрузочный сектор BSD-слайса «по цепочке») или мультисистемный GRUB, который напрямую способен работать с файловыми системами и загружать ядра разных операционок.

Вторая часть (boot1) размещается в загрузочном секторе первичного раздела, несущего BSD-систему (BSD-слайса). То есть и boot0 , и boot1 лежат не только за пределами файловой системы, но и, фактически, вне собственно слайса BSD. Третья же часть (boot2) лежит уже внутри слайса, но не входит в какой-либо из его логических разделов.

Вторая и третья части загрузчика — это, в сущности, единая программа, разделенная только из-за ограничений на размер загрузочного сектора раздела (512 байт). Так что в задачу boot1 входит только опознать слайс BSD, отыскать на нем boot2 и передать ему управление. А уж тот обязан, выждав некоторое время, опознать корневую файловую систему, отыскать на ней и запустить бинарный исполняемый файл — /boot/loader , образующий четвертую часть загрузчика; строго говоря, термин BSD loader только к этой программе и относится.

Таким образом, можно видеть, что первые три части BSD-загрузчика (boot0 , boot1 и boot2) лежат вне файловых систем установленной ОС BSD. В которую мы попадаем только начиная с запуска loader , обычного исполняемого файла, помещаемого в специальном каталоге /boot корневой файловой системы.

Правда, в каталоге /boot (это — «умолчальное» место размещения loader) наряду с его исполняемым файлом можно видеть также файлы с именами boot0 , boot1 и boot2 . Но они представляют собой лишь копии соответствующего кода, расположенного (и запускающегося) вне файловой системы BSD. Назначение их — восстановление возможности загрузки после аварийных ситуаций.

Задача loader ‘а — быстренько загрузить ядро и набор умолчальных модулей, после чего он выводит свое меню с логотипом проекта, на коем можно узнать стрекозу (подменяющую чертика с вилами из FreeBSD). Меню содержит следующие пункты:

1. Boot DragonFly — нормальная загрузка ядра со всеми положенными (кем и где положенными — разговор впереди) модулями, монтированием файловых систем и отработкой предписанных стартовых скриптов;
2. Boot DragonFly with ACPI disabled — то же самое, только с выключением модулей acpi , что иногда может потребоваться на некоторых ноутбуках;
3. Boot DragonFly in Safe Mode — загрузка в безопасном режиме, то есть без подключения модулей;
4. Boot DragonFly in single user mode — загрузка в однопользовательском режиме, при котором монтируется (да и то только для чтения) лишь корневая файловая система, а этап инициализации игнорируется;
5. Boot DragonFly with verbose logging — обычная загрузка, но с выводом подробных сообщений;
6. Escape to loader prompt — выход в командную строку загрузчика;
7. Reboot — ну, это мы знаем, как три пальца, только еще лучше.

Если не сделать никакого выбора — через десять секунд начнет грузиться умолчальный вариант. Для предотвращения чего (и получения дополнительного времени на размышления) достаточно нажать Spacebar — отсчет времени остановится, и загрузки не будет до выбора в явном виде.

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

Интерактивное управление процессом загрузки

Возникает вопрос — может ли пользователь повлиять на процесс загрузки? Ответ на него будет положительным. В ходе работы загрузочной системы пользователю трижды предоставляется свобода выбора: выбора загрузочного раздела на начальной стадии boot0 , выбора интерактивного управления на стадии boot2 и выбора режима загрузки сразу после запуска loader ‘а. И во всех этих случаях пользователь может вмешаться в процесс руками. Зачем? Это уже другой вопрос, и ответ на него, надеюсь, станет ясным из последующего изложения.

С выбором раздела загрузки все ясно: он позволяет загрузить одну из ОС, если на данной машине их установлено несколько. А вот на стадии работы boot2 можно прервать его исполнение, точнее — избежать запуска loader ‘а. Для этого в паузе между выбором загрузки с BSD-раздела и появлением сообщений о загрузке ядра и модулей (пауза эта знаменуется появлением на экране мигающего символа _) нужно нажать любую клавишу. В ответ последует приглашение вида:

>> BSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot:

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

Для этого нужно сконструировать путь к старому ядру по образу и подобию умолчального варианта. То есть указать:

• номер диска в машине в соответствие с понимаем BIOS (0 — первый из наличных, 1 — второй, и так далее, вне зависимости от порядка подключения);
• его интерфейс — в примере ad символизирует ATA диск (для SCSI диска было бы da , для дискеты — fd);
• номер на IDE-канале (0 — мастер, 1 — слейв);
• раздел в смысле, используемом BSD Label, то есть часть слайса, резервируемая под корневую файловую систему BSD (a ;
• имя файла образа старого ядра — /kernel.old .

Если на диске имеется несколько первичных разделов разных типов, то разделы не-BSD типа будут пропущены, и литера a (очевидно, что образ ядра может лежать только на корневой файловой системе) будет относиться к первому подразделу слайса с идентификатором 165 (даже если на диске он будет четвертым по счету).

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

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

Меню loader ‘а предлагает достаточный выбор режимов для штатных ситуаций, но все нештатные (на то они такие и есть) — явно не охватывает. В частности, вариант загрузки старого ядра в меню не предусмотрен. К счастью, предпоследний пункт меню решает эту проблему (и заодно многие другие).

Итак, выбрав пункт шестой меню — Escape to loader prompt , — мы оказываемся в среде командного интерпретатора loader ‘а. Она имеет шелл-подобный интерфейс — команды с их опциями и аргументами вводятся после приглашения, имеющего вид

С точки зрения удобства интерактивной работы — не GRUB, конечно: ни тебе автодополнения, ни истории команд, возможности редактирования ограничены клавишей Backspace . Но с главной своей ролью — вводом и исполнением встроенных команд, — loader вполне справляется.

Тем более, что команд этих довольно много: полный их список можно получить, введя знак вопроса в командной строке. Доступна и помощь — команда help выдаст краткую подсказку, help имя_команды — более подробные сведения об использовании команды-аргумента. Впрочем, синтаксис команд — также шеллоподобный, так что сложностей с этим быть не должно.

Встроенные команды loader ‘а можно разделить на три части по их назначению:

• для получения информации;
• для конфигурирования загрузчика;
• собственно для управления процессом загрузки.

Из первой группы команд отметим следующие: ls , lsdev , lsmod , show , more . Первая предназначена для просмотра корневой файловой системы и ее подкаталогов, — правда, только тех, что которые не лежат на отдельных подразделах. Но поскольку все нужные для загрузки файлы лежат в подкаталогах непосредственно корня (в /boot , /dev , /modules), это ограничение не существенно. Вариант команды ls -l выводит список файлов (и каталогов) с указанием их размера — без этой опции только литерой d помечаются каталоги.

Команда lsdev выводит список дисковых устройств, имеющихся в машине, их первичных разделов и подразделов (последние — только для разделов, размеченных по правилам BSD Label). Опция -v обеспечивает детализацию вывода.

Команда lsmod обеспечивает просмотр модулей, загруженных loader ‘ом до появления меню (или приглашения командной строки). Как и в предыдущем случае, имеется опция детализации — -v .

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

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

Команды конфигурирования позволяют определить или снять переменные загрузчика, загрузить или удалить модули ядра. Как уже говорилось, само ядро с неким предопределенным набором модулей и переменных загружается до меню loader ‘а и его командного интерпретатора. Так вот, с помощью соответствующих команд эти предопределенные наборы можно несколько скорректировать (или изменить полностью). Это может быть необходимо, если умолчальная конфигурация ядра по каким-либо причинам не грузится (частый случай — конфликт ноутбучных систем энергосбережения с системными модулями ACPI), в отладочных целях, или просто удовлетворения любопытства для.

Сначала рассмотрим команды управления модулями. Это — пара команд load и unload для загрузки и удаления модулей, соответственно. Первая используется с аргументом имя_модуля, каковое при необходимости можно подсмотреть (с помощью ls) в каталоге /modules — имя в аргументе дается без суффикса *.ko . Команда unload с аналогичным аргументом удалит указанный модуль, без аргументов — удалит все модули вообще, позволяя начать конфигурирование с чистого листа.

Действие команд load и unload распространяется также на ядро в целом. Так, посредством команды

OK unload kernel

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

OK load kernel.old

загрузить ядро старое, трудоспособное.

Пара аналогичного назначения — set и unset , — существует и для переменными окружения загрузчика. Переменные эти служат для изменения текущего дискового устройства, указания расположения корневой файловой системы, определения путей к модулям ядра, отличным от умолчального /modules , и тому подобных вещей. Делается это командой set в соответствие с синтаксисом C-shell, например:

OK set currdev="disk1s1a"

Определяет текущее дисковое устройство в терминах «диск#_слайс#_раздел».

Допустимо несколько значений для одной переменной — они разделяются точкой с запятой. Например,

OK set module_path="/;/modules;mymodule_path"

определяет расположение модулей ядра — корневой, умолчальный каталог modules и каталог /mymodule_path: очевидно, что если просто определить в этой переменной путь к собственным модулям, информация о расположении модулей умолчальных была бы утрачена. Обращаю внимание на присутствие в определении переменной значения / — этот путь необходим для загрузки ядра посредством команды load (в DragonFlyBSD ядро по умолчанию инсталлируется в корневой каталог).

Некоторые переменные просто разрешают или запрещают какие-то действия, и, соответственно, значения их булевы — YES или NO . Естественно, они нуждаются в детализирующих переменных, определяющих то, что ими было разрешено. Например, переменная

OK set userconfig_script_load="YES"

только разрешает исполнение пользовательских сценариев конфигурирования, а переменная

OK set userconfig_script_name="/boot/my.conf"

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

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

OK set boot_single

Определение переменной может отменяться командой

Unset имя_переменной

В некоторых случаях ее эквивалентом будет определение переменной с булевым значением NO или словом disable в имени.

Полный список встроенных переменных окружения загрузчика можно посмотреть на соответствующей man-странице:

$ man 8 loader

И, наконец, команды управления загрузкой. Важнейшая из них — boot , без опций и аргументов вызывающая немедленную загрузку ядра в его умолчальной или текущей (то есть с переопределенными переменными и модулями) конфигурации. /p>

Опции команды boot конкретизируют режим загрузки. Например, команда

OK boot -s

вызовет загрузку в однопользовательском режиме. Это эквивалентно тому, как если бы выполнить ту же команду без опций, предварительно установив переменную boot_single .

Аргументы команды boot могут определять имя образа ядра, исполняемого сценария загрузки, и так далее. Тот же сакраментальный пример: команда

OK boot kernel.old

приведет к загрузке старого ядра, аналогично команде boot без опций после исполнения пары

OK unload kernel OK load kernel.old

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

Здесь было рассказано не о всех возможностях интерактивного режима BSD-загрузчика — только о тех, которые мне довелось применять. Более подробные сведения можно почерпнуть не только в man (8) loader , но и непосредственно чтением файла помощи:

$ less /boot/loader.help

И совсем не обязательно в процессе управления загрузкой — лучше сделать это заблаговременно.

Конфигурирование загрузчика

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

Интуитивно ясно, что, поскольку вмешательство пользователя возможно на первом (boot0) и последнем (loader) этапах загрузки, именно они и поддаются настройке. Так оно и оказывается.

Правда, на первом этапе загрузки можно настроить не так уж и много, а именно:

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

Приведенным целям служит команда boot0cfg . Стоит помнить только, что ее использование связано с изменением Главной Загрузочной Записи (MBR), разрушение которой приводит к невозможности старта машины с диска. Вероятность запортить этой командой MBR чрезвычайно мала, да и страшных последствий не имеет. Однако (береженого бог бережет) — лучше держать под рукой инсталляционный диск DFBSD. Не для переустановки системы, конечно, но для восстановления загрузочной записи — это ведь большая спасательная дискета. А как — будет предметом следующей статьи цикла.

Итак, изменить время ожидания можно с помощью опции -t # , где # — значение в секундах (нулевое значение не допускается). С помощью опции -s # один определенный раздел диска делается загружаемым по умолчанию на веки вечные (а не тот, с которого был выполнен старт при последнем включении машины). Очевидно, что здесь допустимы значения 1-4 (по числу возможных первичных разделов) плюс 5 — передача управления на MBR второго диска. А опция -v даст нам более подробную информацию о результатах выполненной операции. Ну и, конечно, требуется аргумент — имя дискового устройства, MBR которого мы меняем. То есть команда

$ boot0cfg -t 30 -s 2 -v -f /boot/boot0.old ad0

модифицирует MBR первого IDE-диска (аргумент ad0) так, что 2-й его слайс станет умолчально-загрузочным, время на выбор раздела возрастет до 30 секунд, и выдаст отчет о результатах своей работы в виде примерно следующем:

# flag start chs type end chs offset size 1 0x00 0: 1: 1 0x83 850:254:63 63 13671252 2 0x80 851: 0: 1 0xa5 261:254:63 13671315 23438835 version=187.102 drive=0x80 mask=0xf ticks=30 options=packet,noupdate,nosetdrv default_selection=F2 (Slice 2)

Ах да, опция -f создаст копию текущей загрузочной записи в каталоге /boot ; правда, файл /boot/boot0 и представляет собой копию MBR свежеинсталлированной системы, но — для страховки еще один дубль не повредит.

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

$ $ boot0cfg -o update ad0

Ну а смысл прочих опций (и другие способы применения команды) можно уточнить у тети Мани: man (8) boot0cfg .

Вот мы и добрались до настройки собственно loader ‘а. Я как-то раньше обмолвился, что до появления меню и возможности перехода в интерактивный режим, уже успевает загрузиться ядро с неким положенным набором параметров, и обещал рассказать, где и кем эти параметры положены. Пора исполнить свое обещание.

Так вот, параметры загрузки ядра положены сценарием инициализации загрузчика — /boot/loader.rc . На самом деле это своего рода пакетный файл, из которого вызывается несколько отдельных сценариев, но для нас сейчас это не существенно. А важно то, что положены умолчальные переменные окружения загрузчика и их значения в парном сценарию конфиге — файле /boot/defaults/loader.conf . В нем описываются и пути для поиска модулей, и имя ядра по умолчанию, и текущее дисковое устройство и корневая файловая система, и время задержки перед загрузкой — все то, что можно определить в качестве переменных окружения интерактивно. А еще в нем есть список всевозможных модулей ядра (вообще говоря, всех возможных ) и указывается, следует ли их загружать автоматически при старте, или нет.

Сам по себе /boot/defaults/loader.conf для редактирования не предназначен, а лишь показывает все возможные параметры загрузки и фиксирует их значения по умолчанию. И потому собственно целям настройки loader ‘а служит не он, а файл /boot/loader.conf .

Правда, сразу после установки системы мы такого файла в системе не увидим. Его нужно создать самому, перенести в него нужные опции из файла /boot/defaults/loader.conf и должным образом изменить их значения.

В настройке любой системы обычно проще показать, как она делается, чем рассказать об этом. И потому приведу в качестве примера свой /boot/loader.conf с некоторыми комментариями. Я человек простой, к излишествам не склонный, и потому файл этот у меня очень маленький.

Autoboot_delay="5" # Время ожидания перед автозагрузкой beastie_disable="YES" # Отмена вывода меню загрузчика usb_load="YES" # Загрузка модуля поддержки шины USB ugen_load="YES" # Загрузка поддержки USB-устройств вообще ums_load="YES" # Загрузка поддержки USB-мыши # Эти строки требуются, если соответствующие функции # не встроены в ядро жестко snd_pcm_load="YES" # Загрузка модуля поддержки звука snd_ich_load="YES" # Загрузка модуля звукового устройства # В примере - чипсетное аудио от Intel ICH#

Дополнительно здесь можно включить загрузку модуля хранителей экрана вообще и, вслед за тем, конкретного модуля (соответствующие файлы расположены в каталоге /modules и имеют вид *_saver.ko):

Vesa_load="YES" screensave_load="YES" screensave_name="fire_saver"

А можно также загрузить и собственную splash-картинку (созданием коей, в формате *.bmp или *.pcx, и ее размещением в каталоге /boot следует озаботиться заблаговременно):

Splash_bmp_load="YES" bitmap_load="YES" bitmap_name="filename.bmp"

Обратим внимание на строку vesa_load , подгружающую модуль поддержки одноименного режима в консоли: она необходима для некоторых, графических, скринсейверов (например, приведенного в примере «пламени») и, конечно же, splash-картинок. Впрочем, поддержка VESA может быть встроена в ядро (см. цикла).

Приведенный пример не исчерпывает возможности по реконфигурации загрузчика — иные возможности можно почерпнуть из просмотра файла /boot/defaults/loader.conf . Нужно только иметь ввиду, что какие-то функции, обеспечиваемые подгружаемыми модулями, могут быть уже вкомпилированными в ядро — умолчальное или собственноручно собранное, — и дублировать их не нужно. То есть перед редактированием /boot/loader.rc неплохо свериться с текущей конфигурацией ядра. Для свежеустановленной системы она описана в файле /usr/src/sys/i386/conf/GENERIC , а для собственноручно собранного… впрочем, если вы уже собирали ядро, то лучше меня знаете, как называется файл его конфигурации, и что в нем вписано.

Скажу только пару слов о модулях поддержки файловых систем. Очевидно, что встраивать в ядро поддержку тех из них, что используются лишь эпизодически (типа msdos), нет никакого смысла: в этом случае для всех из них (включая и ext2fs) при компиляции ядра будут по умолчанию собраны и загружаемые модули. Однако и в загрузке этих модулей при старте необходимости нет (хотя соответствующие строки в файле /boot/defaults и имеются). При обращении к устройству с чуждой файловой системой необходимый модуль подгрузится автоматически. Это же касается и модулей поддержки таких устройств, как диски в оперативной памяти (md — Memory Disk), если, конечно, не предполагается старта системы именно с них.

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

Отыскать нужные модули легко — они содержат в своем имени компонент snd . То есть можно прибегнуть к команде типа

$ ls /modules | grep snd

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

В приведенном примере отменен вывод меню loader ‘а. Меню это описывается в файле /boot/beastie.4th , использование коего предписано в файле /boot/loader.rc строкой

Include /boot/beastie.4th

Разумеется, это не обязательно. Можно, напротив, переделать /boot/beastie.4th так, чтобы отдельные пункты меню отвечали собственным вариантам загрузки — например, с различными наборами подргужаемых модулей, для чего придется создать несколько альтернативных конфигурационных файлов для loader ‘а. Или — образов ядра, собранного с различными опциями. А если вы еще и вышивать умеете (пардон, рисовать ASCII-символами), то можно заменить украшающую меню стрекозу на что-то свое.

Задачи инициализации

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

В действительности это могут быть (и в разных системах действительно бывают) весьма разные программы. Более того, его можно подменить при интерактивном управлении процессом загрузки другой программой, например, командной оболочкой. Однако это сейчас не очень важно — рассмотрим только штатные задачи программы /sbin/init .

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

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

А следующая задача процесса init — это вызов и отработка сценариев инициализации, или стартовых скриптов, собранных в каталоге /etc и (или) его подкаталогах. Это обычные сценарии оболочки, рассчитанные на исполнение стандартным POSIX-шеллом и включают в себя последовательности команд, призванные монтировать файловые системы, активизировать область своппинга, устанавливать системные часы, запускать те или иные службы и демоны.

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

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

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

Понимание это, однако, затрудняется тем, что и сценарии инициализации, и их конфигурационные файлы реализованы в разных ОС и их дистрибутивах очень по разному. Впрочем, это многообразие можно свести к двум стилям — BSD, все вариации на тему которого очень похожи друг на друга, и System V, каждый представитель которого оригинален по своему. Первый стиль инициации используется в операционках одноименного семейства. Стиль же System V преобладает в большинстве распространенных дистрибутивов Linux. Хотя последнее время и во многих из них (CRUX, Archlinux, Gentoo) все шире применяются BSD-подобные схемы инициации.

Инициализация DragonFly

В DragonFly, как это и положено представителю BSD-семейства, принята загрузка в BSD-стиле. Основное отличие его от стиля System V — отсутствие понятия runlevels (что часто неточно переводится как уровни загрузки или даже уровни запуска ). Вместо этого существует понятие режимов загрузки, каковых всего два — однопользовательский и многопользовательский.

В однопользовательском режиме загрузка происходит а) при выборе соответствующего пункта (Boot in single user mode ) в меню начального загрузчика, б) при задании команды boot -s в командной строке загрузчика (после выбора пункта его меню Escape to loader prompt ), и в) при обнаружении серьезных (неустранимых автоматически) нарушений целостности файловой системы в ходе ее проверки на первой стадии инициализации).

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

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

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

Между однопользовательским и многопользовательским режимами не лежит непреодолимой пропасти: переход из одного режима в другой возможен не только при рестарте машины, но и в ходе одного сеанса. Для немедленного перехода в однопользовательский режим служит команда

$ shutdown now

Возврат обратно в многопользовательский режим происходит по команде

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

Загрузка в многопользовательском режиме — и это отличительная особенность BSD-стиля, — потенциально влечет за собой доступность для запуска абсолютно всех системных служб и демонов: инициализирующие их сценарии (располагающиеся в каталоге /etc/rc.d) теоретически могут быть запущены из главного стартового сценария — файла /etc/rc . А вот какие из них будут запущены реально — определяется опциями его конфигурационного файла — /etc/rc.conf . Наличие пары главного стартового сценария и его конфигурационного файла — вторая отличительная особенность DragonFly (и вообще BSD-стиля инициации).

При установке DragonFly в каталог /etc на диске записывается некий умолчальный /etc/rc.conf , строки которого имеют вид

Servicename_enable="значение"

Переменная="значение"

Значение строк первого вида = «YES» или «NO». Легко догадаться, что они разрешают (или запрещают) запуск поименованного сервиса посредством соответствующего ему (и, как правило, одноименного) сценария из каталога /etc/rc.d . Значения же строк второго вида — это параметры, передаваемые командам, входящим в скрипты инициализации.

По умолчанию в DragonFly — и это тоже традиция BSD-систем, — в файле /etc/rc.conf разрешен запуск лишь минимально необходимого для начала работы количества системных служб. Большая же их часть обычно запрещена — или явным образом, указанием значения «NO», или по умолчанию (а откуда эти умолчания берутся — мы сейчас увидим). Так что включение необходимых пользователю демонов (например, той же консольной мыши) — дело рук самого пользователя.

Стартовые умолчания берутся из файла /etc/defaults/rc.conf , в котором описаны всевозможные (и все возможные) стартовые сервисы и их параметры (помните — подобную же пару «умолчального» и рабочего конфигов мы видели для программы loader). Файл этот не предназначен для прямого редактирования (хотя оно и не запрещено атрибутами его доступа). Вместо этого полагается отыскать в нем строки, относящиеся к нужным сервисам, перенести их в /etc/rc.conf и разрешить их запуск (или, напротив, запретить, если оный разрешен по умолчанию, но в данном случае не нужен). Уточняющие опции сервисов также берутся из /etc/defaults/rc.conf , переносятся в /etc/rc.conf и им приписываются нужные значения.

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

$ less /etc/defaults/rc.conf

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

Как все это происходит практически — проще рассмотреть на нескольких примерах. В статье про установку DragonFly было показано, что для настройки консольной мыши с USB-интерфейсом достаточно активизировать демона соответствующих устройств, вписав в файл /etc/rc.conf строку

Usbd_enable="YES"

Однако для всех прочих типов мышей требуется определение некоторого количества иных переменных. Каких — определить не сложно. Отправляемся в ранее открытый файл /etc/defaults/rc.conf и отыскиваем в нем строки, имеющие отношение к мыши — в данном случае удобно воспользоваться командой типа

$ grep mouse defaults/rc.conf

— и смотрим на вывод результата поиска:

Moused_enable="NO" # Run the mouse daemon. moused_type="auto" # See man page for rc.conf(5) for available # settings. moused_port="/dev/psm0" # Set to your mouse port. moused_flags="" # Any additional flags to moused. mousechar_start="NO" # if 0xd0-0xd3 default range is occupied in your # start like mousechar_start=3, see vidcontrol(1)

Из коего, собственно, и становятся очевидными дальнейшие действия. Сначала следует разрешить запуск мышиного демона — для чего в /etc/rc.conf вносится строка

Moused_enable="YES"

Команда /usr/sbin/moused (а включить поддержку мыши можно и из командной строки, но только в данном сеансе работы — об этом будет сказано чуть позже) в общем случае требует двух опций — указания протокола (это то, что описывается строкой moused_type) и порта подключения (сериального, PS/2, USB — шинные мыши, скорее всего, из употребления уже вышли). При описании протокола строка

Moused_type="auto"

подойдет для всех, насколько мне известно, современных грызунов с разъемами PS/2, хотя его можно указать точно — ps/2 . А вот для сериальных (и тем более шинных) мышей протокол следует обязательно задать в явном виде. Каком — смотрим в man (5) rc.conf или man (8) moused (я, грешным делом, об этих существах уже забыл).

Явное указание порта также необходимо только для сериальных и шинных мышей («Вы знаете тетю Маню? — Я знаю тетю Маню. — Вы верите тете Мане? — Я верю тете Мане. — Так вот, у нее и спрашивайте за таких зверей…»). Хотя если указать

Moused_port="/dev/psm0"

для PS-пополамной животины, вреда не будет ни малейшего.

Moused_flags=""

можно задать разнообразные опции, предусмотренные для команды /usr/sbin/moused , как то: эмуляцию средней кнопки для двухклавишных моделях (на скроллирующих мышах колесико работает аналогично средней кнопке), скорость реакции, акселерацию при перемещении курсора и так далее. За подробностями — опять же к Мане, к Мане, к Мане…

Ну а о строке

Mousechar_start="NO"

разговор уже был: если в качестве кодировки вывода используется KOI8-R, а ядро не пересобиралось, или пересобиралось без опции

Options SC_MOUSE_CHAR=0x3

умолчальное NO следует заменить на 3 . В любом ином случае она просто не нужна.

Как будет показано в следующей статье , одной из целей пересборки ядра было обеспечение поддержки графической консоли. Однако включения соответствующей опции в конфиг ядра мало — соответствующий видеорежим нужно еще активизировать. Это обеспечивается сценарием /etc/rc.d/syscons , исполняющим, в частности, команду vidcontrol, отвечающую за все, что имеет отношение к настройкам экрана. А свои параметры эта команда получает опять-таки из файла /etc/rc.conf . В частности, видеорежим определяется переменной

Allscreens_flags=""

для которой нужно определить соответствующее значение в виде MODE_#режима. Например, при желании иметь разрешение 800×600 и 32-битную глубину цвета эта строка примет вид

Allscreens_flags="MODE_277"

Теперь о заключительной стадии инициации — процессе получения терминала. Она контролируется записями в файле /etc/ttys , о котором вскользь упоминалось в статье про установку системы . Наличие специального файла для конфигурирования виртуальных терминалов — третье из важных отличий BSD-систем: в Linux, вне зависимости от стиля сценариев инициализации, принятых в конкретном дистрибутиве, настройка виртуальных терминалов описывается в общем конфиге процесса init.

Содержимое файла /etc/ttys выглядит таким образом (строки, описывающие терминалы, получаемые при модемном доступе на машину, я опускаю, как неактуальные):

Console none unknown off secure # ttyv0 "/usr/libexec/getty Pc" cons25 on secure # Virtual terminals ttyv1 "/usr/libexec/getty Pc" cons25 on secure ttyv2 "/usr/libexec/getty Pc" cons25 on secure ttyv3 "/usr/libexec/getty Pc" cons25 on secure ttyv4 "/usr/libexec/getty Pc" cons25 on secure ttyv5 "/usr/libexec/getty Pc" cons25 on secure ttyv6 "/usr/libexec/getty Pc" cons25 on secure ttyv7 "/usr/libexec/getty Pc" cons25 on secure ttyv8 "/usr/X11R6/bin/xdm -nodaemon" xterm off secure

Как можно видеть, это — простая база данных, поля которой имеют следующее содержание:

1. имя терминального устройства, имеющее значения console для так называемой системной консоли, и имя виртуального терминала (ttyv# , где # — порядковый номер) — для всех остальных;
2. процесс, запускаемый на данном терминале для его активизации; на системной консоли никакого процесса не запускается, ее роль (в первую очередь — место помещения системных сообщений) исполняет первый виртуальный терминал; на прочих же, кроме последнего (о котором будет отдельный разговор) таким процессом является стандартный getty;
3. тип терминала — по умолчанию для стандартного видеорежима 80×25;
4. статус терминала, определяющий, активизирован (on) или нет (off); «отрицательное» значение по умолчанию можно видеть в двух записях — первой и последней;
5. степень защищенности терминала; умолчальное значение secure предполагает, что данный терминал физически, так сказать, недоступен для злоумышленника, и потому на нем безбоязннно можно зарегистрироваться суперпользователю; если изменить его на unsecure , то авторизация root’а с данного терминала окажется невозможной; указание значения unsecure для системной консоли повлечет за собой необходимость задания пароля суперпользователя при загрузке в однопользовательском режиме.

Что тут подлежит изменению? Во-первых, тип терминала: в случае русификации консольного режима умолчальное значение cons25 следует заменить на cons25r ; впрочем, мы ведь это проделали сразу после установки, не так ли? При использовании отличной от стандартной плотности символов тип терминала также подлежит изменению. Например, если используется режим 80×30, здесь следует подставить cons30r . Полный список допустимых значений типов терминала можно посмотреть в файле /etc/termcap .

Далее, с точки зрения безопасности не лишено резона разрешить авторизацию суперпользователя только на какой-либо одной виртуальной консоли, например, первой: все равно для практической работы она мало пригодна, так как на нее валом валятся системные сообщения. От большей их части, конечно, можно избавиться редактированием файла /etc/syslog.conf , перенаправив вывод их, описываемый строкой

*.err;kern.debug;auth.notice;mail.crit /dev/console

с системной консоли в какой-либо файл (или даже в устройство /dev/null). Однако кое-что на консоли появляться все равно будет — например, сообщения о присоединении и отсоединении устройств горячего подключения (типа USB-накопителей или PC-карт).

В принципе регистрацию администратора можно и вообще запретить: получению временных прав root-оператора командой

это отнюдь не препятствует.Разумеется, количество виртуальных терминалов, активизируемых при старте системы, можно изменить в ту или другую сторону. Понятно, что для уменьшения их числа достаточно просто удалить или закомментировать «лишние» строки, а для увеличения — вписать недостающие по образу и подобию имеющихся (не забыв переименовать файлы соответствующих устройств). Только нужно иметь ввиду, что умолчальное ядро GENERIC поддерживает 16 виртуальных терминалов, минимум один из которых должен быть зарезервирован для запуска оконной системы X — вручную или автоматически. И еще — при увеличении числа виртуальных терминалов нужно озаботиться наличием файлов соответствующих устройств (вида ttyv#) — по умолчанию в каталоге /dev их «только» 12.

К слову, об Иксах. Пользователи Linux имеют возможность обеспечить авторизацию в графическом режиме (и автоматическую загрузку Иксов) простым методом — изменением runlevel по умолчанию. А как быть пользователям BSD-систем, понятия runlevel не имеющих, — тем, кто работает преимущественно в Иксах и кому надоело набирать команду startx ? Да все столь же просто: достаточно активизировать «иксовый» виртуальный терминал, заменив в последней приведенной строке off на on . Это повлечет за собой автоматическую загрузку менеджера графического входа в систему — xdm . Каковой, естественно, можно заменить его более пролдвинутым аналогом. Например, строка

Ttyv8 "/usr/local/bin/kdm -nodaemon" xterm off secure

Оборотная сторона инициализации системы — это ее останов или рестарт, различий между этими процессами практически нет. И отвечает за него команда shutdown , которая может быть дана от лица суперпользователя или члена группы operator. С опцией -h она вызывает останов машины, с опцией -r — ее перезагрузку. И еще команде этой требуется аргумент — время, когда останов или рестарт должны произойти. Впрочем, есть способ и мгновенного останова или рестарта:

$ shutdown -h now

$ shutdown -r now

соответственно.

Кроме того, существуют также команды halt и reboot того же назначения. Однако самостоятельной роли они не играют, просто вызывая команду shutdown с опцией останова и перезагрузки, соответственно.

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

Как уже говорилось, сценарии, отвечающие за запуск стартовых сервисов, находятся в каталоге /etc/rc.d . Большинство запускаемых ими программ — это так называемые демоны (daemon — Disk And Execution MONitor), нечто вроде резидентных программ, работающих в фоновом режиме в ожидании запроса на исполнение их функции (печати, отправки почты, обращения к ftp- или http-серверу, и так далее). В соответствие с этим запускающие их сценарии устроены по принципу start — stop . И если при инициации системы выполняется первая функция, то при ее останове, как легко догадаться, вторая.

Ход процесса останова системы определяется сценарием /etc/rc.shutdown . Назначение его — выполнить функцию stop в сценариях всех сервисов, запущенных из скрипта /etc/rc в соответствие с описанием, данным в /etc/rc.conf и /etc/defaults/rc.conf .