Особенности BSD-стиля
Начнем с чистого BSD-стиля, как более простого, прямолинейного и потому более доступного пониманию начинающего пользователя (да и, по моему глубокому убеждению, более ему подходящего). Начать с того, что он предусматривает всего два режима загрузки - однопользовательский, предназначенный для аварийно-восстановительных работ и решения некоторых задач администрирования, и многопользовательский, при котором осуществляется вся нормальная деятельность пользователя.
В однопользовательском режиме загрузка происходит а) при выборе соответствующего пункта (Boot in single user mode) в меню начального загрузчика, б) при задании команды boot -s в командной строке загрузчика (после выбора пункта его меню Escape to loader prompt), и в) при обнаружении серьезных (неустранимых автоматически) нарушений целостности файловой системы в ходе ее проверки на первой стадии инициализации).
В любом случае при загрузке в однопользовательском режиме не монтируется ни одна файловая система из /etc/fstab, кроме корневой - да и та остается лишь в режиме read only, в котором она была смонтирована при старте системы, не отрабатывается ни один сценарий инициализации, и не активизируется ни один виртуальный терминал, кроме первого, исполняющего функции системной консоли, авторизация на которой по умолчанию - беспарольная, с автоматическим получением прерогатив суперпользователя (а зарегистрироваться от лица кого-либо другого, понятное дело, и невозможно). Очевидно, что никакая нормальная работа при этом невозможна, однопользовательский режим предназначен почти исключительно для аварийно-спасательных работ и потому подробнее будет рассмотрен в соответствующей интермедии.
При загрузке в многопользовательском режиме (а она осуществляется по умолчанию при нормальном включении машины или ее перезагрузке) все стадии инициации проходятся по полной программе: монтируются предназначенные к тому файловые системы из файла /etc/fstab (а корень ее ремонтируется в режиме чтения/записи), отрабатываются определённые стартовые скрипты (где и кем определенные - скоро увидим), и активизируются все описанные в файле /etc/ttys виртуальные терминалы (вплоть до графического приглашения к авторизации, если таковое определено).
Авторизация возможна как для администратора, так и для любого пользователя, но о беспарольном входе придется забыть. Короче говоря, идет нормальная цивилизованная работа...
Между однопользовательским и многопользовательским режимами не лежит непреодолимой пропасти: переход из одного режима в другой возможен не только при рестарте машины, но и в ходе одного сеанса. Для немедленного перехода в однопользовательский режим служит команда
$ dhutdown now
Возврат обратно в многопользовательский режим происходит по команде
$ exit
Такой способ широко применяется для реинициализации системы без полной ее перезагрузки после изменения каких-либо конфигурационных параметров - он протекает гораздо быстрее последней. Нужно только помнить, что при этом не все сервисы и демоны обязаны работать правильно.
Загрузка в многопользовательском режиме - и это отличительная особенность BSD-стиля, - потенциально влечет за собой доступность для запуска абсолютно всех системных служб и демонов: инициализирующие их сценарии (располагающиеся в каталоге /etc/rc.d) теоретически могут быть запущены из главного стартового сценария - файла /etc/rc. А вот какие из них будут запущены реально - определяется опциями его конфигурационного файла - /etc/rc.conf.
При установке системы, использующей BSD-стиль инициализации, в каталог /etc на диске записывается некий умолчальный /etc/rc.conf, строки имеют вид
servicename_enable="значение"
или
переменная="значение"
Значение строк первого вида = "YES" или "NO". Легко догадаться, что они разрешают (или запрещают) запуск поименованного сервиса посредством соответствующего ему (и, как правило, одноименного) сценария из каталога /etc/rc.d (для определенности я рассматриваю случай FreeBSD и DragonFlyBSD - стартовые схемы их практически идентичны, - но нечто подобное будет и в NetBSD, и в OpenBSD). Например, строка
moused_enable="YES"
разрешает запуск службы консольной мыши посредством скрипта /etc/rc.d/moused.
Значения же строк второго вида - это параметры, передаваемые командам, входящим в скрипты инициализации. Так, строки
moused_type="auto" moused_port="/dev/ums0"
определяют что значения опций -t (автоматическое определение протокола) и -p (имя файла мышиного устройства - в данном случае с USB-интерфейсом) для команды /usr/sbin/moused, запускаемой из сценария /etc/rc.d/moused.
Как правило - и это тоже традиция BSD-систем, - по умолчанию в файле /etc/rc.conf разрешен запуск лишь минимально необходимого для начала работы количества системных служб. Большая же их часть обычно запрещена - или явным образом, указанием значения "NO", или по умолчанию а откуда они берутся - мы скоро увидим). Так что включение необходимых пользователю демонов (например, той же консольной мыши) - дело рук самого пользователя.
Откуда берутся стартовые умолчания? А берутся они из файла /etc/defaults/rc.conf, в котором описаны всевозможные (и все возможные) стартовые сервисы и их параметры. Файл этот не предназначен для прямого редактирования (хотя оно и не запрещено атрибутами его доступа). Вместо этого полагается отыскать в нем строки, относящиеся к нужным сервисам, перенести их в /etc/rc.conf и разрешить их запуск (или, напротив, запретить, если оный разрешен по умолчанию, но в данном случае не нужен). Уточняющие опции сервисов также берутся из /etc/defaults/rc.conf, переносятся в /etc/rc.conf и им приписываются нужные значения.
В общем виде это делается, например, так: в одной виртуальной консоли (на которой нужно зарегистрироваться как root или получить его права командой su) в текстовом редакторе открывается файл /etc/rc.conf, в другой (на ней можно авторизоваться и обычным пользователем) дается команда
$ less /etc/defaults/rc.conf
И нужные строки из последнего просто переносятся в первый, где и модифицируются должным образом. Не вредно при этом задействовать и третью пользовательскую консоль - для чтения man (5) rc.conf. Как все это выглядит на практике - мы увидим в ближайшей интермедии.
Что же касается заключительной стадии BSD-инициации - процесса получения терминала, - то она контролируется записями в файле /etc/ttys, о котором уже говорилось в интермедии 13. Наличие специального файла для конфигурирования виртуальных терминалов - одно из важных отличий BSD-систем: в Linux, вне зависимости от стиля сценариев инициализации, принятых в конкретном дистрибутиве, настройка виртуальных терминалов описывается в общем конфиге процесса init.
Как уже говорилось, сценарии, отвечающие за запуск стартовых сервисов, находятся в каталоге /etc/rc.d (по крайней мере в современных версиях FreeBSD, а также в DragonFlyBSD это именно так). Большинство запускаемых ими программ - это так называемые демоны (daemon - Disk And Execution MONitor), нечто вроде резидентных программ, работающих в фоновом режиме в ожидании запроса на исполнение их функции (печати, отправки почты, обращения к ftp- или http-серверу, и так далее). В соответствие с этим запускающие их сценарии устроены по принципу start - stop. И если при инициации системы выполняется первая функция, то при ее останове, как легко догадаться, вторая.
Ход процесса останова системы определяется сценарием /etc/rc.shutdown. Назначение его - выполнить функцию stop в сценариях всех сервисов, запущенных из скрипта /etc/rc в соответствие с описанием, данным в /etc/rc.conf и /etc/defaults/rc.conf.
