The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги ]

Изучение и оптимизация загрузки Linux сервера (fedora linux boot init speed tune grub inittab fsck mount swap)


<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>
Ключевые слова: fedora, linux, boot, init, speed, tune, grub, inittab, fsck, mount, swap,  (найти похожие документы)
From: Andrejs Spunitis <spunitis AT one.lv> Date: Sun, 16 Feb 2008 17:02:14 +0000 (UTC) Subject: Изучение и оптимизация загрузки Linux сервера Оригинал: http://www.dzti.edu.lv/isp-serv/index.php?l=6 Увеличение скорости загрузки сервера или "Потрошим загрузочные скрипты Fedora Core 4" ПОСТАНОВКА РЕШАЕМОЙ ЗАДАЧИ Максимально упростить загрузочные скрипты для 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 АНОТАЦИЯ Ознакомление начинающих 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 @menu.lst 2.1 [Загрузка ядра] В загрузчике grub реализованы необходимые функции для работы с файловыми системами, что позволяет ему в случае Linux найти файлы vmliniz и initrd.img и загрузить их /boot/vmlinux /boot/initrd.img 3. [Запуск программы init] После того как ядро запущено, запускается самая первая прогрмма, которую называют прародителем всех процессов. По умолчпнию эта программа init /sbin/init 3.1. [Чтение инструкций из файла inittab] Главной задачей init является выполенение инструкций из файла inittab /etc/inittab 3.1.1. [Инициализация системы] В файле inittab есть строка: si::sysinit:/etc/rc.d/rc.sysinit указыающая, какой скрипт должен быть запущен для инициализации системы, /etc/inittab 3.1.1.1. [Cоздание псевдо файловых систем] Создание псевдо-файловой системы: 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 [Монтирование файловых систем] Изменяем режим доступа на запись/чтение к корневой директории командой: mount -n -o remount,rw / Монтируем файловые систему которые перечислены в файле /etc/fstab командой: mount -a /etc/rc.d/rc.sysinit 3.1.1.4 [Монтирование swap] Для компьютера с небольшим количеством оперативной памяти создаем файл подкачки, команда: swapon /dev/sda2 /etc/rc.d/rc.sysinit 3.1.2. [Переход на указанный runlevel] Выполнение скриптов из директории /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 есть строки: 1:2345:respawn:/sbin/mingetty tty1 2:2345:respawn:/sbin/mingetty tty2 /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/ 3. [Запуск программы init] После того как ядро загрузилось в память запускается самая первая программа (процесс), по умолчанию это /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 ! Итогом раздела "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 )

<< Предыдущая ИНДЕКС Исправить src / Печать Следующая >>

Ваш комментарий
Имя:         
E-Mail:      
Заголовок:
Текст:





  Закладки на сайте
  Проследить за страницей
Created 1996-2017 by Maxim Chirkov  
ДобавитьРекламаВебмастеруГИД  
Hosting by Ihor