CITKIT.ru - свободные мысли о свободном софте
Деловая газета CitCity.ru Библиотека CITForum.ru Форумы Курилка
Каталог софта Движение Open Source Дискуссионный клуб Дистрибутивы Окружение Приложения Заметки Разное
19.09.2019

Последние комментарии

ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)
24 December, 22:53
Kubuntu Feisty (15)
24 December, 18:42
Один на один с Windows XP (3758)
24 December, 11:46

Каталог софта

Статьи

Дискуссионный клуб
Linux в школе
Open Source и деньги
Open Source и жизнь
Windows vs Linux
Копирайт
Кто такие анонимусы
Лицензии
Нетбуки
Нужен ли русский Linux?
Пользователи
Дистрибутивы
Идеология
Выбор дистрибутива
Archlinux & CRUX
Debian
Fedora
Gentoo
LFS
LiveCD
Mandriva
OpenSolaris
Slackware
Zenwalk
Другие линуксы
BSD
MINIX
Движение Open Source
История
Классика жанра
Окружение
shell
Библиотеки UI
Графические среды
Шрифты
Приложения
Безопасность
Управление пакетами
Разное
Linuxformat. Колонки Алексея Федорчука
Заметки
Блогометки
Файловые системы
Заметки о ядре

Дистрибутивы :: BSD :: FreeBSD

... И всё начинается с рестарта.
Загрузка и инициализация системы

CITKIT.ru

Страницы: предыдущая :: 1 :: ... :: 4 :: 5 :: 6 :: 7 :: следующая

Содержание

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

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

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

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

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

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

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

# shutdown now

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

# exit

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

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

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

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

или

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

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

По умолчанию во FreeBSD — и это тоже традиция 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.

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

% grep mouse defaults/rc.conf

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

moused_nondefault_enable="YES" # Treat non-default mice as enabled unless
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_#режима. Например, при желании иметь разрешение 800x600 и 32-битную глубину цвета эта строка примет вид

allscreens_flags="MODE_277"

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

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

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

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

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

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

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

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

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

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

su
или
sudo
это отнюдь не препятствует.

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

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

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

обеспечит авторизацию в менеджере от KDE (каковая, естественно, также должна быть установлена). А вот gdm рекомендуется запускать иначе -- включением строки

gdm_enable="YES"

в файле /etc/rc.conf. Впрочем, к вопросу о способах запуска Иксов нам еще придется возвращаться в одной из последующих глав.

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

# shutdown -h now

или

# shutdown -r now

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

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

Наконец, ныне во FreeBSD нередко можно корректно завершить работу и кнопкой Power на системном блоке (но не тумблером на блоке питания!): на материнских платах ATX при наличии в системе поддержки ACPI это будет эквивалентно команде

# shutdown -p now

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

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

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

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




Страницы: предыдущая :: 1 :: ... :: 4 :: 5 :: 6 :: 7 :: следующая

Комментарии

аноним, Mon Oct 5 17:51:54 2009:
Алексей, четверг, 18 декабря 2008 г. 00:36:37:
Толи я такой нуб. Толи для таких нубов как я написано не совсем понятно. "в текстовом редакторе открывается файл /etc/rc.conf". Непонятно как открыть в редакторе,и когда это вообще делать

ee /etc/rc.conf
vi /etc/rc.conf - какой больше нравится.

"ttyv8 "/usr/local/bin/kdm -nodaemon" xterm off secure - надо "on". в ttyv8 обычно - xdm, kdm в ttyv9
Raven, Sun Dec 21 14:34:07 2008:
18.2 секунды это ровно 100 тиков.
Системные часы работают с частотой 18.2 тика в секунду. и, кстати, команда, приведенная для конфигурирования:
boot0cfg -t 30 -s 2 -v -f /boot/boot0.old ad0
задаст всего 30 тиков, а не 30 секунд ожидания.
Алексей, Thu Dec 18 00:36:37 2008:
Толи я такой нуб. Толи для таких нубов как я написано не совсем понятно. "в текстовом редакторе открывается файл /etc/rc.conf". Непонятно как открыть в редакторе,и когда это вообще делать. "ttyv8 "/usr/local/bin/kdm -nodaemon" xterm off secure
обеспечит авторизацию в менеджере от KDE " я так пологаю должно быть on вместо off? или я чего то не понимаю? И вообще что-то не совсем мне понятно как менять все эти конфиги. А так вообще очень познавательно. Надеюсь Ваш материал поможет освоить мне FreeBSD.
Алексей Федорчук, Tue Nov 4 22:21:33 2008:
2 аноним, вторник, 4 ноября 2008 г. 21:40:49:
____
Спасибо, пофиксил
аноним, Tue Nov 4 21:40:49 2008:
(hd0,1 с точки зрения GRUB, /dev/ad1s1 по Free'шному)

Опечатка, надо hd1,0.
аноним, Mon Nov 3 13:42:37 2008:
команду
# shutdown now
я заменяю на
#kill 1 1
(так короче)
И еще. less - смотрелка, а редактировать - чем-нибудь, вроде ee. Я почему упоминаю такие мелочи - начинающие могут смутиться, а FreeBSd нужно любить!
Woolfy, Fri Oct 31 12:51:56 2008:
"
Для чего каждая из них проверяется на наличие бита "чистого размонтирования" (clean byte),
"
Все таки наверное, "байт чистого размонтирования".
Хотя, уместнее будет, назвать его просто - "флагом".
Алексей Федорчук, Wed Oct 29 12:38:29 2008:
2 Александр
Ага, спасибо
Александр, Wed Oct 29 12:24:24 2008:
Опечатка:
"... ведь размер загрузочного сектора раздела составляет те же 512 Кбайт ..."
Кбайт -> байт

Комментарии заморожены.

Новости:

Все новости на CitCity.ru

Компании месяца

 
Последние комментарии
Почему школам следует использовать только свободные программы (101)
20 Декабрь, 14:51
ОСТОРОЖНО: ВИНДОФИЛИЯ! (2250)

24 Декабрь, 22:53
Linux в школе: мифы про школу и информатику (334)
24 Декабрь, 22:43
Kubuntu Feisty (15)
24 Декабрь, 18:42
Software is like sex: it's better when it's free.
©Linus Torvalds