Библиотека сайта rus-linux.net
Увеличение скорости загрузки сервера
или
"Потрошим загрузочные скрипты Fedora Core 4"
ДАТА: 27 февраля,
2006 г. | АВТОР: Andrejs Spunitis | EMAIL: spunitis AT
one.lv
KEYWORDS:
grub, init, inittab,
rc.sysinit, fcsk, mount, swapon, mingetty
ПОСТАНОВКА
РЕШАЕМОЙ ЗАДАЧИ
- Максимально упростить загрузочные скрипты для Fedora Core;
- Детально разобраться с этапами загрузки системы, от включения питания до командного shell;
Сокращение времени загрузки ISP-serv; в моем случае время загрузки сократилось с 16сек. (сервисы: syslogd,sshd,network,crond,gpm) до 7сек, для P4-2.8GHz.
Полезные ресурсы интернета:
http://www.opennet.ru/docs/RUS/FromPowerUpToBash/
http://www.phrack.org/show.php?p=63&a=10
http://sentinelsecurity.net/whitepapers/diskcloning.pdf
http://unixforums.org.ru/index.php?t=2
http://www.comptechdoc.org/os/linux/startupman/linux_surcsysinit.html
http://wiki.kryukov.biz/wiki/
АНОТАЦИЯ
Ознакомление начинающих Linux администраторов с загрузочными скриптами и их упрощения применительно к серверу (ISP-serv).
ВВЕДЕНИЕ
В начале освоения Linux, каждый из нас прочитывал строки описывающие загрузку Linux системы, и в курсе, что сначала грузится загрузчик операционной системы (как правило в современных дистрибутивах это grub), затем ядро с каким-то не совсем понятным initrd.img, затем запуск прародителя всех процессов init, который использует файл inittab, затем rc.sysinit и переход в уровень выполнения (runlevel) указанный в файле inittab. Кажется все ясным?! Тогда попробуйте проверить полученные знания на практике, например снесите себе директорию где располагаются образ ядра и initrd.img (директория /boot) и проверьте себя, а заодно и полноту изложенного материала:). Ну а если Вы не сторонник радикальных мер, то попробуйте вначале разобраться с /etc/rc.sysinit, в качестве затравки, rc.sysinit для ISP-serv можно сократить до размера нескольких строк, например:
#!/bin/bash mount -n -t proc none /proc fsck -T -A -a mount -n -o remount,rw / mount -a swapon /dev/sda2
а затем, на дисерт разберитесь с скриптом /etc/rc.d/initd/network, который можно заменить тремя строками:
modprobe 8139too ifconfig eth0 xx.xx.xx.xx netmask 255.255.255.0 up route add default gw xx.xx.xx.gw
Подытожив, не побоюсь заявить,
дистрибутивы Linux-а буквально тонут в скриптах написанных лет 10
обратно, превращая изначально простую систему во что то cложное и
непонятное. Во всех сриптах куча проверок, на существование всяких
файлов конфигурации, udev - как правило подвисает на пару секунд, в
натугах найти звуковую карту там, где ее нет, а в случае ISP-serv ещё
ругается на какой-то там md (raid). Конечно в случае Linux-десктопа
это оправдано (оправдано незнанием всезнаек), но абсолютно раздражает
когда Вы используете собственно настроенный сервер. Честно говоря я
также не вижу толка в красочных выводах сообщений от redhata об
успешном или неудачном запуске сервисов. Моя цель проста и ясна:
"сделать используемые системой скрипты простыми и ясными".
В
поисках истины, у Вас может появиться искушение собрать свой Linux,
но и там есть могучие скрипты, заставляющие новичков ощутить свою
неполноценность, к тому же в самопальных (LFS) Linux Вас буквально
заставляют собрать кучу всяких програмных пакетов, только для того
что бы вы смогли скомпилировать необходимые Linux програмные пакеты
shadow, util-linux, coreutils, sysVinit, bash и так далее.
Источником знаний, излагаемых в этой статье, на первых порах
стала статья "От включения питания до приглашения
Bash":
http://www.opennet.ru/docs/RUS/FromPowerUpToBash/
Согласно
указанной статье, для понятности ниже приведена простенькая таблица,
с кратким описанием этапов загрузки системы
|
Параграф |
Этап |
Выполняемое действие |
Файл |
|
|
1. |
[Включение кнопки] |
|
|
|
|
2. |
GRUB выводит меню где пользователь выбирает Операционную Систему (Как правило Linux или Windows) |
/boot/grub/grub.conf |
||
|
2.1 |
В загрузчике grub реализованы необходимые функции для работы с файловыми системами, что позволяет ему в случае Linux найти файлы vmliniz и initrd.img и загрузить их |
/boot/vmlinux |
||
|
3. |
После того как ядро запущено, запускается самая первая прогрмма, которую называют прародителем всех процессов. По умолчпнию эта программа init |
/sbin/init |
||
|
3.1. |
Главной задачей init является выполенение инструкций из файла inittab |
/etc/inittab |
||
|
3.1.1. |
В файле inittab есть строка: si::sysinit:/etc/rc.d/rc.sysinit указыающая, какой скрипт должен быть запущен для инициализации системы, |
/etc/inittab |
||
|
3.1.1.1. |
Создание псевдо-файловой системы: mount -n -t proc /proc /proc хранящей информацию о запущенных процессах, используемой памяти и т.д. |
/etc/rc.d/rc.sysinit |
||
|
3.1.1.2. |
Прежде чем изменить доступ к корневой директории с режима чтения на запись, необходимо проверить файловую систему командой: fsck -T -A -a |
/etc/rc.d/rc.sysinit |
||
|
3.1.1.3 |
Изменяем режим доступа на запись/чтение к корневой директории
командой: |
/etc/rc.d/rc.sysinit |
||
|
3.1.1.4 |
Для компьютера с небольшим количеством оперативной памяти создаем файл подкачки, команда: swapon /dev/sda2 |
/etc/rc.d/rc.sysinit |
||
|
3.1.2. |
Выполнение скриптов из директории /etc/rc.d/rc.X.d, где X - номер уровня выполнения (runlevel), runlevel запускаемый по умолчанию определяется строкой id:3:initdefault: из файла /etc/inittab. |
/etc/inittab |
||
|
3.1.3. |
После того как все сервисы, на которые указывают ссылки из
директории /etc/rc.d/rc.X.d
выполнились, пользователю дается возможность ввести свой
login/pasword и командная оболочка, для этих целей необходимо
чтобы программа /sbin/mingetty
постоянно работала, на терминалах (tty). Для выполнения этих
требований в конце файла /etc/inittab
есть строки: |
/etc/inittab |
Из
таблицы наглядно видно, почему init называют прародителем всех
процессов.
Рассмотрим поподробнее перечисленные этапы в
таблице
2. [Загрузчик] grub
Начну описание загрузчика с одного из эпизодов:
Чтение
эпизодов можно пропустить, их цель придать статье большую
реалистичность и немного детективного жанра.
Эпизод
1: снес партицию boot, в которой располагалось все хозяйтсво grub
и kernel.
PS:
для достоверности воспроизведения тех далеких событий я прямо сейчас
удалил диреткорию /boot, и для полной нирваны, востановил загрузчик
Windows-XP.
Для удаления
mbr & востановления загрузчика Windows-XP
вставьте загрузочный CD-rom (WinXP), выберете Recovery Console и
введите следующие две команды: fixboot
и fixmbr
после чего перезагрузите компьютер. Ваш Windows сразу начнет
грузится, не оставив малейших признаков о том что был установлен
Linux :).
Ниже
описана хронография событий с использованием спасательного диска
rescue для Fedora Core 4 (неудачная попытка)
Загрузился с
rescue для Fedora Core 4, во время загрузки набрал rescue:
boot:
rescue
В конце концов, появилась табличка, извещающая о
том, что "безголовый" пингвин лежит по адресу
/mnt/sysimage, и если возникло желание оживить его, то в консоле
наберите:
# chroot /mnt/sysimage
Тем самым текущей корневой
директорией станет /mnt/sysimage
Выполнив chroot
/mnt/sysimage я решил для удобства запустить mc (midnight
commander) Fedor-ино горе затряслось, но через секунд 10 решило уйти
в глубокий нокдаун, перестартовав машину.
Сдаватся не
хотелось, поэтому создал директорию boot:
# mkdir
/mnt/sysimage/boot
И запланировал скопировать в созданную
директорию необходимые загрузчику файлы (stage1,e2fs_stage1_5,
stage2), но к сожалению найти их на спасательном диске от Fedora не
удалось (# find * |grep stage не дали результатов), быстрым выходом
было переустановить пакеты grub и kernel, для этого необходимо
скачать их с интернета.
Поднял сетевой интерфейс командами:
#
ifconfig eth0 192.168.10.X netmask 255.255.255.0 up
# route add
default gw 192.168.10.Y
# echo “nameserver 159.148.60.20”
>> /etc/resolv.conf
При попытке проверить работу
интернета, сделал ping. ping пошел, однако остановить его обычной
комбинацией клавиш Ctrl+C не удалось, пришлось перейти во вторую
консоль (Alt+F2) и выполнить команду # killall ping
После чего
начал скачивать в директорию /mnt/sysimage/boot
# cd
/mnt/sysimage/boot
необходимые пакеты grub и kernel:
# wget
http://mirrors.playboy.com/fedora/4/i386/os/Fedora/RPMS/grub-0.95-13.i386.rpm
#
wget
http://mirrors.playboy.com/fedora/4/i386/os/Fedora/RPMS/kernel-2.6.11-1.1369_FC4.i686.rpm
Затем
сменил корневую директорию (наученный горьким опытом на этот раз уже
не запускал mc):
# chroot /mnt/sysimage
# cd /boot
#
rpm -е kernel --nodeps
Выдалось сообщение об ошибке:
error:
%preun(kernel-2.6.11-1.1369_FC4.i686) scriplet failed, exit status
255
При попытке переустановить командами:
# rpm -ivh
kernel*.rpm --allfiles
# rpm -Fvh kernel*.rpm --allfiles
Выдало
предупреждение:
warning: kernel-2.6.11-1.1369_FC4.i686.rpm: Header
V3 DSA signature: NOKEY, keyID 4f2a6fd2
Поигравшись вдоволь с
разными опциями rpm я пришел в ярость, так как при установке ядра
всегда выдавалась какая-то ошибка и необходимые системе файлы
System.map, initrd.img, vmlinuz не установливались!
Подводя
итог работы с rescue Fedora Core 4, посоветую вам иметь с собой не
спасательное Fedor-ино горе, а что то зубастое, как например
Kanotix!
Теперь
опишу хронографию действий по поднятию Fedora с помощью Kanotix
(удачная попытка).
Вставил, запустился, выбрал консольный
режим.
Запустил mc
# mc
Подмонтировал раздел, где
лежит обезглавленный пингвин
# mount /dev/sda3
/mnt/sda3
Установил в качестве корневой директории /mnt/sda3
#
chroot /mnt/sda3
Перешел в /boot
# cd /boot
После
чего для надежности удалил kernel и grub:
# rpm -e kernel
--nodeps
# rpm -e grub --nodeps
Поскольку в rpm файл можно
залезть с помощю mc и вытащить оттуда файлы, залез в kernel-*.rpm, но
к сожалению там не обнаружил необходимого для загрузки Linux файла
initrd.img. Забегая вперед, этот initrd.img очень
важный для системы файлик.
В initrd.img
находятся модули которые ядро во время загрузки может подключить.
Здесь уместно обратить внимание на то, что в grub реализована
поддержка многих файловых систем (чтобы убедится в этом, посмотрите
директорию /boot/grub) в принципе он этим и отличается от LILO. grub
использует встроенные в него функции работы с файловыми системами
что дает ему возможность найти и загрузить в память файлы: vmlinuz и
initrd.img
После чего проинсталировал ядро
# rpm -ivh
kernel*.rpm
вот как раз во время инсталяции ядра и создается
initrd.img содержащий в себе необходимые для ядра модули, в
зависимости от конфигруции железа компьютера (поэтому если Вы
попытаетесь стянуть с другой машины initrd.img ваша попытка будет
скорее всего обречена на неудачу).
Отмечу, что во время установки
ядра вывелось предупреждение связанное как впоследствие окажется с
LABEL:
mount: could not open /proc/partitions, so UUID
conversion cannot be done.
Проинсталировал grub:
#
rpm -ivh grub*.rpm
# grub-install /dev/sda3
grub-install выдал
сообщение что устройства /dev/sda3 нету:
/dev/sda: Not found or
not a block device.
Несмотря на это необходимые файлы для
работы grub c файловыми системами скопировались в директорию
/boot/grub.
Для до-установки grub вернулся в Kanotix:
#
exit
что бы с его помощью закончить установку grub:
#
grub
grub> root (hd0,2)
grub> kernel
/boot/vmlinuz-2.6.11-1.1369_FC4
grub> initrd
/boot/initrd-2.6.11-1.1369_FC4
grub> setup (hd0)
grub>
quit
#
Приведенные команды хорошо описаны в статье
"Самодостаточный
GRUB":
http://www.linuxshare.ru/docs/software/grubbest.html
Перезапустил
компьютер, и увидел любимое приглашение grub-а:
grub>
После
вводил следующие команды:
grub> root (hd0,2)
grub> kernel
/boot/vmlinuz-2.6.11-1.1369_FC4
grub> initrd
/boot/initrd-2.6.11-1.1369_FC4.img
grub> boot
Началась
загрузка Linux, но на каком то этапе на экран вывелась куча
сообщений, однако сообщение на которое стоило бы обратить внимание
появилось всего на пару секунд, приведу его ниже:
Mounting
root file system
mount: error 6 mounting ext3
Switching to new
root
ERROR opening /dev/console
далее последовало
множество сообщений об ошибках и система не загрузилась!
Но
для растройства не было причин, вспомнив о сообщение
(которое было во время установки ядра) стало ясно что дело именно в
нем! По умолчанию ядру передается параметр root=LABEL=/ который
указывает метку (LABEL) партиции корневого раздела Linux.
Корневой
раздел Linux может быть совсем не тот раздел который указан при
команде:
grub> root (hd0,2)
Почему то в
статьях которые мне попадались, авторы поленились об этом написать!
Посмотрите стандартный конфигурационный файл grub-а
/boot/grub/grub.conf и увидите строку вида:
kernel
/boot/vmlinuz-2.6.14-1.1653_FC4 ro root=LABEL=/ rhgb quiet
Мне,
и многим другим, кажется такой подход крайне неудобным, при установке
на компьютер нескольких Linux систем в различные партиции диска,
поскольку метка партиции должна быть уникальной.
Поэтому
пришлось перезагрузится, и при загрузке ядра явно указать корневую
партицию, передав параметр root=/dev/sda3, например:
grub>
grub>
root (hd0,2)
grub> kernel /boot/vmlinuz-2.6.11-1.1369_FC4
root=/dev/sda3
grub> initrd
/boot/initrd-2.6.11-1.1369_FC4.img
grub> boot
Все
загрузилось удачно!
Чтобы каждый раз при загрузке не вводить в
grub команды, существует файл конфигурации grub-a:
/boot/grub/grub.conf
При загрузке grub, для взаимодествия с
пользователем grub выводит в виде меню содержимое файла grub.conf:
default=1
timeout=5
title Fedora Core (2.6.11-1.1369_FC4)
root (hd0,0)
kernel /boot/vmlinuz-2.6.11-1.1369_FC4 init=/sbin/init 4 ro root=/dev/sda3 quiet
initrd /boot/initrd-2.6.11-1.1369_FC4.img
title Windows XP
rootnoverify (hd0,0)
chainloader +1
Однако после перезагрузки меню выбора ОС не будет если не была
создана ссылка menu.lst на grub.conf, ссылка создается командой:
#
cd /boot/grub
# ln -s grub.conf menu.lst
Рассмотрим
подробнее строки из приведенного примера файла grub.conf:
root
(hd0,2) указывает что файы kernel и initrd.img расположены
в 3-й партиции первого жесткого жиска
kernel
/boot/vmlinuz-2.6.11-1.1369_FC4 ядро (kernel) есть файл
/boot/vmlinuz-2.6.11-1.1369_FC4
ro
root=/dev/sda3 -- корневая файловая система расположена в
3-й партиции первого жесткого диска /dev/sda3 и не доступна для
записи
init=/sbin/init
указывает что после загрузки ядра запустится программа иницализации
/sbin/init и ей передается параметр :
цифра 3
которая задает 3-й runlevel
quiet
- уменьшает вывод сообщений которые выводятся на дисплей во время
загрузки ядра, тем самым тратится меньше времени
initrd
/boot/initrd-2.6.11-1.1369_FC4.img файл грузящися в
оперативную память и содержащий необходимые модули используемые ядром
Забегая вперед, уровень выполнения задается в файле
/etc/inittab, однако мне больше нравится указывать уровень выполнения
непосредсвенно при загрузке ядра. Это удобно когда необходимо
загрузится в однопользовательский режим (runlevel=2) тогда достаточно
при загрузке grub нажать клавишу "e" для редактирования
параметров передаваемых ядру.
Подводя итоги:
- Копируете в надежное место vmlinuz и initrd.img!
- Если Linux не грузится, проверьте передаваемый ядру параметр root=/dev/ХХХ
Если при загрузке не появляется меню, то проверьте наличие файла grub.conf и ссылки menu.lst на него
Поскольку сейчас мы немного разобрались на примере из Эпизода 1 с часто возникаемыми проблемеми связанными с загрузчиком grub, рассмотрим подробнее этапы загрузки grub
Источником информации (для выяснения как грузится grub) для меня послужила статья Hacking Grub for fun and profit:
http://www.phrack.org/show.php?p=63&a=10
[включение питания]
|
+---->[boot сектор, загрузка программы из MBR]
|
Y
+----< grub нету в MBR >----[переход на активную партицию]---+
| |
Y Y
+----< grub есть в MBR >--------->---+---<-------------------+
|
Y
+---------+----------+
| загрузка stage-1 |
+---------+----------+
Y
+-----< stage-1.5 отконфигурирована >-----+
| |
Y |
+-----+-------------------+ |
| загрузка stage-1.5 | |
| (load embedded sectors )| |
+-----+-------------------+ |
| |
Y Y
+-----< stage-1.5 не настроена >----------+
|
Y
+-----+--------------+
| загрузка stage-2 |
+-----+--------------+
|
+----------------------+
|
Y
+-----------+-----------+
| загрузка grub.conf |
| отображение boot меню |
+-----------+-----------+
|
Y
+-----------+-----------+
| Выбор пользователкм |
| загружаемой системы |
+-----------+-----------+
|
Y
+-----------+-----------+
| загрузка |
| vmlinuz & initrd.img |
+-----------------------+
stage1 занимает 512Байт, stage1 может быть
установлен или в MBR, или в boot сектор. Поскольку stage1
устанавливается или в MBR или в boot сектор, то после установки grub
файл /boot/grub/stage1 можно удалить. Как правило при установке в MBR
grub c бOльшей вероятностью можно сказать что будет
сконфигурирован/установлен stage1.5. По сути дела в stage1.5 нет
большой необходимости, может быть именно поэтому с 2-ой версии grub в
stage1.5 полностью пропадет необходимость. Как бы там не было,
основной задачей stage1 является загрузка stage2. В stage1.5 был
реализован доступ к файлу stage2 на уровне файловой системе, а если
stage1.5 не был установлен, то месторасположение файла stage2 во
время установки grub задавалась как номер сектора (поэтому при
неустановленном stage1.5 можно было переименовать файл stage2 и иметь
работоспособный grub). Следует отметить что в stage2 реализована
поддержка файловых систем. По всей видимости в новых дистрибутивах
будет устанавливаться grub2.
Надеюсь что теперь у читателя
сформировалось законченное представление о загрузчике grub и Вы
будете в состояние определить причины возможных ошибок связанных с
началом загрузки grub и дальнейшей загрузки Linux (vmlinuz и
initrd.img).
2.1. [Загрузка ядра]
Грузится оно себе в память, при
этом может выводить кучу всякой информации на дисплей, которую как
правило никто не читает, поэтому и передают при загрузке ядра
параметр quiet чтобы на дисплей не
выводились эти сообщения о загрузки ядра
Ради интереса, можете
оценить размер ядра и модулей, по сути дела это есть минмально
возможный размер занимаемый Linux на жестком диске.
Ядро: # ls -lh
/boot/
Модули: # du -skh /lib/modules/2.6.11-1.1369_FC4/
После того как ядро загрузилось в
память запускается самая первая программа (процесс), по умолчанию это
/sbin/init, при желание эту программу можно переопределить, указав
ядру параметр init=/path/to/init.
Программа /sbin/init
поставляется с програмным пакетом SysVinit, об этом можно
узнать выполнив команду:
# rpm -qf /sbin/init
Главной
задачей /sbin/init является выполнение инструкций содержащихся в
файле /etc/inittab
3.1. [Чтение инструкций из файла inittab]
Выведите содержимое /etc/inittab
на экран, например командой:
# cat /etc/inittab
в моем
(упрощенном) случае будет:
si::sysinit:/etc/rc.d/rc.sysinit l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6 1:2345:respawn:/sbin/mingetty tty1 2:2345:respawn:/sbin/mingetty tty2
Ваш файл /etc/inittab можно упростить, ограничив количесво
виртуальных терминалов двумя:
1:2345:respawn:/sbin/mingetty
tty1
2:2345:respawn:/sbin/mingetty tty2
respawn
-- указвает init запускать программу mingetty в случае если по
какой либо из причин она не работает.
Так же из стандартного
inittab убраана строка id:3:initdefault:
поскольку легче указывать runlevel как параметр передаваемый ядру (
это описано в разделе 2. [Загрузчик] )
Для инициализации
системы Linux, init запускает скрипт инициализации который
указан в файле inittab в строке:
si::sysinit:/etc/rc.d/rc.sysinit
3.1.1. [Инициализация системы]
Когда говорят
об уменьшение времени загрузки ОС почемуто не упоминают о скриптах,
хотя именно их выполнение и занимает много времени.
Эпизод
2: Упростим /etc/rc.d/rc.sysinit до минимума, который проверяет
целостность файловой системы и перемонтирует корневую партицию
для возможности изменения/записи на неё (вспомните, что при
загрузке ядра передавался параметр ro
root=/dev/sda3 делающий корневую партицию доступной только для
чтения). По всей видимости логика здесь следующая, сначала загрузить
систему только на чтение данных из корневого раздела, после чего
проверить целостность файловой системы, и только в случае её
целостности разрешить запись на неё.
минимальным файл
/etc/rc.d/rc.sysinit:
#!/bin/bash fsck -T -A -a mount -n -o remount,rw /
после чего перезапустил Linux... и Linux
запустился!
Пока сознательно закроем глаза на вывод
сообщений связанных с отсутсвием псевдо файловой системы /proc
!
Обратите внимание что
сокращение оригинального файла /etc/rc.d/rc.sysinit
содержащего в моем случае 664 строки (подсчитать кол-во строк можно
командой: # cat /etc/rc.d/rc.sysinit.orig |wc -l) не привело к краху
системы.
Отмечу отдельно тот факт, что сервис sshd работает,
позволяя мне камфортно набирать текст статьи в WindowsXP.
Одной
из самых распространенной ошибкой обучения является начало изучения
материала на сложных примерах, в нашем случае объект изучения состоит
их 3-х строк, разберем их:
самая первая строка файла
/etc/rc.d/rc.sysinit:
#!/bin/bash
сообщает системе что обработка содержимого
файла будет производится программой /bin/bash (той самой командой,
которая называется command shell).
fsck
-T -A -a для проверки файловой
системы, fsck позволяет поправить файловую систему, например для
случая, когда запись данных на диск была прервана внезапным в
ыключением из сети компьютера, рассмотирм передаваемые параметры:
-A
fcsk пытается проверить файловые системы
перечисленные в /etc/fstab (этот файл мы далее расмотрим
подробнее)
-a
избавляет нас от необходимости подтверждать запрос fsck на
исправление ошибок, тем самым найденные ошибки исправляются
автоматически.
-T
при запуске fsck на экран не выводится ненужная информация о запуске
fcsk.
Осталась последняя строка:
mount
-n -o remount,rw /
перемонтирование корневой файловой системы в режим чтения/записи,
рассмотирм передаваемые параметры:
-n
результаты монтирования не будут записаны в
файл /etc/mtab
-o
указывает что далее последуют опции (в нашем примере это remount,rw)
remount,rw
непосредственно переводит уже подмонтированную корневую файловую
систему в режим чтения/записи
Эпизод 3: (можно
сказать продолжение Эпизода 2) удалил все ссылки из директории
/etc/rc.d/rc3.d и написал свой скрипт
запуска сети и sshd.
После того как выполнены инструкции из
файла /etc/rc.d/rc.sysinit
осуществляется запуск скриптов, ссылки на которые содержатся в
директории /etc/rc.d/rcX.d
, где Х - номер runlevel (для расматриваемого примера это 3,
директория /etc/rc.d/rc3.d ).
Прежде чем думать на тему, какие
скрипты из тех что перечислены в директории /etc/rc.d/rc3.d
нам нужные, а какие нет, сформируем свое требование: иметь
удаленный доступ к системе, через ssh.
Сказано -- сделано,
все что было в директории /etc/rc.d/rc3.d удалено, командой:
# rm
-f *
Теперь пришло время, написать свой скрипт назовем его
/etc/rc.d/rc.minFC, который поднимает
сетевой интерфейс (задание TCP/IP - параметров) и запустит демон
удаленного администрирования (sshd):
#!/bin/sh modprobe 8139too ifconfig eth0 192.168.10.101 netmask 255.255.255.0 up route add default gw 192.168.10.5 /usr/sbin/sshd
теперь создадим в диреткории /etc/rc3.d/
символьную ссылку на него:
# cd /etc/rc.d/rc3.d
# ln -s
../rc.minFC S76minFC
После чего перезапустил Linux... и Linux
запустился!
однако зайти удаленно оказалось не
возможным, после ввода пароля вывелось сообщение:
Server
refused to allocate pty
Это означает что не было создано
устройства /dev/pts, все логично, ведь если посмотреть на схему
загрузки Linux мы опустили монтирование файловых систем
перечисленных в файле /etc/fstab, в котором есть строка:
/dev/devpts
/dev/pts devpts
gid=5,mode=620 0 0
Поэтому
сократил файл /etc/fstab до одной выше приведенной строки.
И
для обработки интсрукций содержащихся в файле /etc/fstab в конец
файла /etc/rc.d/rc.sysinit добавил строку:
mount
-a
монтирования файловых систем из файла /etc/fstab,
файл /etc/rc.d/rc.sysinit станет:
#!/bin/bash fsck -T -A -a mount -n -o remount,rw / mount -a
Все в порядке, Linux запустился!
и есть удаленный доступ через ssh
Резюме для Эпизод-2
и Эпизод-3:
- Linux пишет информацию о событиях в системе в лог-файлы, для
рассмотренных эпизодов лог-файлы остануться не измененным. Это легко
проверить обнулив файлы: /var/log/messages и /var/log/dmesg
командами:
# > /var/log/messages
# > /var/log/dmesg
И убедится, что после перезапуска Linux, они останутся пустыми. При желание можно вывести информацию выводимую при загрузке ядра на экран можно командой:
# dmesg |less
- команды top, ps не работают,
выдавая при из старте сообщение:
/proc is not mounted, required for output data
Связанное с тем, что псевдо файловая система proc не была смонтирована.
Решением данной проблемы служить добавление в файл /etc/rc.d/rc.sysinit строки:
mount -n -t proc /proc /proc
При малом количестве опреативной памяти, существует опасность падения системы, так как файл подкачки (swap) не включен, для этого необходимо добавить в файл /etc/rc.d/rc.sysinit строку:
swapon /dev/sda2
В итоге, минимальным скриптом иницализации системы станет файл: /etc/rc.d/rc.sysinit:
#!/bin/bash mount -n -t proc /proc /proc fsck -T -A -a mount -n -o remount,rw / mount -a swapon /dev/sda2
Единственной попыткой описания содержимого rc.sysinit на момент
написания этого материала была сатья "Linux rc.sysinit
script" по
адресу:
http://www.comptechdoc.org/os/linux/startupman/linux_surcsysinit.html
но
к сожалению в ней не достаточно подробно освещены некоторые моменты,
в связи с чем много советов типа "смотри man". Из этой
"Linux rc.sysinit script" я узнал, что значения многих
используемых переменных в /etc/rc.d/rc.sysinit
устанавливаются в файле /etc/rc.d/init.d/functions
!
После написания этой статьи, появилась хорошая статья
описывающая аналог rc.sysinit для Slackware: "Система
инициализации Slackware Linux "
http://wiki.kryukov.biz/wiki/
Итогом раздела "3.1.1. [Инициализация системы]"
можно считать
- Cократившееся приблизительно в два раза время загрузки системы, в моем случае с 16сек. (сервисы: syslogd,sshd,network,crond,gpm) оно сократилось до 7сек. для P4-2.8GHz., для более слабых компьютеров разница будет большей.
Простой и понятный скрипт инициализации системы /etc/rc.d/rc.sysinit
Поскольку многие моменты были изложены немного сумбурно в Эпизодах 2 и 3 то далее продолжим изложение матреиала, согласно приведенной вначале статьи схемой.
3.1.1.1. [Cоздание псевдо файловых систем]
файловая
система proc является pseudo-системой,
содержащей информацию о процессах, памяти и так далее. Данные из этой
псевдо-файловой системы активно используются системой и такими
популярными программами как top и ps.
Монтирование
псевдо-файловой системы proc выполняется командой:
mount
-n -t proc /proc /proc
где параметр:
-n
сообщает не записывать информацию о смонтированной
системы в файл /etc/mtab ;
-t
указывает тип файловой системы, в нашем случае это
proc ;
/proc
/proc определяет, что подмонтированное
устройство (device) /proc будет закрепленно за директорией
/proc;
Ознакомление с /proc крайне полезно, ради интереса
выполните ниже приведенные команды:
# cat /proc/cpuinfo
#
cat /proc/meminfo
# cat /proc/1/cmdline
3.1.1.2. [Проверка файловой системы]
При запуске системы, корневая директория монтируется с доступом
только на чтение, это можно узнать по передаваемому ядру параметру:
ro
root=/dev/sda3
где ro
указвает что третья партиция /dev/sda3
доступна только для чтения данных.
Именно в таком режиме
доступа (только чтение) утилита fsck проверяет на целостность
данных файловую систему. Нецелостность файловой системы как правило
вызвана некорректным выключением компьютера из сети, в результате
чего часть физически записанной информации на диск останется
неучтенной файловой системой.
Для проверки фаловой системы, в
скрипте /etc/rc.d/rc.sysinit имеется
строка:
fsck -T -A -a
Где
параметры определяют действия выполняемые fsck:
-A
fsck пытается проверить файловые системы
перечисленные в /etc/fstab (этот файл будет расмотрен в
дальнейшем)
-a
избавляет нас от необходимости подтверждать запрос fsck на
исправление ошибок, тем самым найденные ошибки исправляются
автоматически.
-T
при запуске fsck на экран не выводится ненужная информация о запуске
fcsk.
3.1.1.3. [Монтирование файловых систем]
В системе Linux существует специальный файл /etc/fstab содержащий список устройств, доступ к данным которых может быть получен. Синтаксис /etc/fstab следующий:
[filesystem] [mount-point] [fs-type] [options] [dump] [fsck-order]
Например:
/dev/pts /dev/pts devpts gid=5,mode=620 0 0 /dev/shm /dev/shm tmpfs defaults 0 0
При конфигурации ядра
(файл конфигурации ядра можете посмотреть
здесь
) была отмечена опция "Virtual memory file system support
(former shm fs)" которая повышает быстродействие системы.
Повышение быстродествия достигается засчет создания файловой
системы по сути дела в оперативной памяти.
если Вы хотите
использовать "Virtual memory file system" то в файл
/etc/fstab необходимо добавить строку
(сервер ISP-serv может работать и без этого):
/dev/shm
/dev/shm tmpfs
defaults 0 0
Так
же на опыте из Эпизода 3 для
полноценной работы с терминалом необходимо подмонтировать устройство
/dev/pts, для чего в файле /etc/fstab
должна быть строка:
/dev/devpts
/dev/pts devpts gid=5,mode=620
0 0
Для выполнения
монтирования устройств, перечисленных в файле /etc/fstab,
в файле /etc/rc.d/rc.sysinit необходимо
иметь следующую строку:
mount -a
Которая монтирует файловые системы указаные в файле /etc/fstab
3.1.1.4. [Монтирование swap]
В Linux, так же
как и в Windows, существует понятие виртуальной памяти. Использование
виртуальной памяти позволяет отводить процессам больше памяти, чем
реально установлено оперативной памяти в компьютере.
Такая
возможность достигается засчет использования swap раздела, в который
"скидываются" данные из оперативной памяти принадлежащие
малоактивным процессам.
Класическим примером использования
swap, является команда:
# swapon -a
где параметр: -a
указывает что для swap будет использоваться устройство у которого в
файле /etc/fstab название точки
монтирования есть swap,
например:
/dev/sda2
swap swap defaults
0 0
Однако мне больше нравится явно
передавать команде swapon
параметр указывающий какой раздел жесткого диска является swap,
поэтому в моем /etc/rc.d/rc.sysinit есть
строка :
swapon /dev/sda2
Для
вывода текущей информации об использование swap выполните команду:
#
cat /proc/swaps
3.1.2. [Переход на указанный runlevel]
На тему уровней много написано,
например все в той же статье "От включения питания до
приглашения
Bash":
http://www.opennet.ru/docs/RUS/FromPowerUpToBash/#s6
В
самом начале стандартного файла /etc/inittab
Вы наверняка найдете описание уровней работы Linux:
# Default runlevel. The runlevels used by RHS are: # 0 - halt (Do NOT set initdefault to this) # 1 - Single user mode # 2 - Multiuser, without NFS (The same as 3, if you do not have networking) # 3 - Full multiuser mode # 4 - unused # 5 - X11 # 6 - reboot (Do NOT set initdefault to this)
Обычно для Linux десктопа используют 5-й уровень, а для сервера 3-й
который можно назвать консольным уровнем, поскольку в нем есть только
текстовый режим дисплея. Отмечу что так принято, Вы же можете
радикально изменить сложившиеся установки.
Что вам для этого надо?
Только разместить в каталоге /etc/rc.d/rcX.d
(Х - номер runlevel) ссылки на те cкрипты запуска сервисов, которые
вы хотите использовать.
Поскольку в Linux можно переходить с
одного runlevel на другой, например команда:
#
init 5 , где 5 -- runlevel
то необходимо
сначала останавливать сервисы того runlevel с которого уходишь и
запускать те сервисы runlevel на который осуществляется переход. Для
этого линки/ссылки на стартующие скрипты имеют названия начинающие с
"S" после которого идет порядковый номер, аналогично для
ссылок на те скрипты сервисов которые надо остановить. Посмотрите
какие линки есть для 3 runlevel, командой:
# ls -l
/etc/rc.d/rc3.d/
Отмечу, что Вас никто не органичивает так же
сменить директорию где распложены ссылки на запускаемые скрипты
сервисов, для этого надо изменить в файле /etc/inittab
строки:
l0:0:wait:/etc/rc.d/rc 0 l1:1:wait:/etc/rc.d/rc 1 l2:2:wait:/etc/rc.d/rc 2 l3:3:wait:/etc/rc.d/rc 3 l4:4:wait:/etc/rc.d/rc 4 l5:5:wait:/etc/rc.d/rc 5 l6:6:wait:/etc/rc.d/rc 6
Как правило для сервера
достаточно запуска следующих сервисов:
syslogd,sshd,network,crond
3.1.3. [Запуск виртуального терминала]
Виртуальный
терминалом можно назвать консоль, где мы вводим команды, и
переключаемся меду ними Alt+F1,Alt+F2,Alt+F3 или Alt+F4
respawn:/sbin/mingetty tty1 указывает
программе /sbin/init в случае прекращения процесса связанного с
программой /sbin/mingetty снова запустить пограммму
/sbin/mingetty.
Для авторизации mingetty вызывает программу
login, после ввода правильного login/password пользователь получает
доступ к командному интерпретатору системы (command shell).
Заключительная настройка скриптов загрузки для ISP-serv
Поскольку основные моменты загрузки
системы уже разобраны, то не буду многословным, а просто приведу
листинги используемых скриптов:
/etc/rc.d/rc.ISP
#!/bin/bash /sbin/syslogd ifconfig lo 127.0.0.1 ifconfig eth0 xx.xx.xx.ip up ifconfig eth1 192.168.0.1 up route add default gw xx.xx.xx.gw /usr/sbin/named -u named -t /var/named/chroot /usr/sbin/sshd /usr/sbin/crond chmod 777 /dev/null cd /ISP-serv ./nat-firewall ./mark-isp.sh ./traffic-isp.sh
/etc/rc.d/rc.sysinit
#!/bin/bash hostname ISP mount -n -t proc /proc /proc fsck -T -A -a mount -n -o remount,rw / mount -a swapon /dev/hda2
/etc/fstab
/dev/pts /dev/pts devpts gid=5,mode=620 0 0 /dev/shm /dev/shm tmpfs defaults 0 0
Прокоментируем отельные строки из приведенных
скриптов:
chmod 777 /dev/null
для того, что бы не было сообщений:
-bash:
/dev/null: Permission denied
/usr/sbin/named
-u named -t /var/named/chroot запуск
DNS сервера
/usr/sbin/crond
запуск планировщика задач
ifconfig
lo 127.0.0.1 поднятие loopback
интрефейса (ip: 127.0.0.1) поскольку в файле /etc/resolv.conf
в качестве dns-сервера указан: 127.0.0.1 ( nameserver 127.0.0.1 )
обсуждение в
форуме
http://www.opennet.ru/opennews/art.shtml?num=7025
Andrejs Spunitis: spunitis AT one.lv
ДАТА: 27
февраля, 2006 г.