Лекция по курсу «Сети и СПИ» для групп КТСО-2-6-17 (6 семестр) от 18.03.2020 г.

В лекции освещены следующие вопросы для подготовки к экзамену:

1. Архитектура операционной системы UNIX. Порядок загрузки, назначение
основных составляющих ОС.
2. Механизмы удаленной загрузки UNIX. Требования к оборудованию и архитектура
программного обеспечения, необходимые для загрузки Linux.
3. Конфигурирование BOOTP-сервера для удаленной загрузки UNIX. Файл
/etc/bootptab.
4. Генерация ядра Linux, пригодного для удаленной загрузки системы. Опции при
компиляции, утилита mknbi (из пакета etherboot.rpm).

Архитектура операционной системы UNIX. Порядок загрузки,

назначение основных составляющих ОС.
Существует два основных объекта операционной системы UNIX, с которыми
приходится работать пользователю — файлы и процессы. Эти объекты тесно связаны друг
с другом, и в целом способ организации работы с ними как раз и определяет архитектуру
операционной системы.
Все данные пользователя храняться в файлах; доступ к периферийным устройствам
осуществляется посредством чтения и записи специальных файлов; во время выполнения
программы операционная система считывает исполняемый код из файла в память и
передает ему управление. Принципы храниния и доступа к файлам объединяются понятием
файловой системы.
С другой стороны, вся функциональность информационной системы определяется
выполнением соответствующих процессов. Процесс — это исполняющаяся программа,
относящаяся к операционной системе или запущенная пользователем.
Самый общий взляд на архитектуру UNIX позволяет увидеть двухуровневую модель
системы, состоящую из пользовательской и системной части (ядра). Ядро непосредственно
взаимодействует с аппаратной частью компьютера, изолируя прикладные программы
(процессы в пользовательской части операционной системы) от особенностей ее
архитектуры. Ядро имеет набор услуг, предоставляемых прикладным программам
посредством системных вызовов. Таким образом, в системе можно выделить два уровня
привилегий: уровень системы (привилегии специального пользователя root) и уровень
пользователя (привилегии всех остальных пользователей).
Архитектура операционной системы UNIX

Важную часть системных программ составляют демоны. Демон — это процесс,

выполняющий опеределенную функцию в системе, который запускается при старте
системы и не связан ни с одним пользовательским терминалом. Демоны предоставляют
пользователям определенные сервисы, примерами которых могут служить системный
журнал, веб-сервер и т. п. Аналогом демонов в операционной системе Windows NT и более
поздних версиях являются системные службы.

Этапы загрузки ОС UNIX

досистемный загрузчик
Как правило, сразу после включения питания программа ПЗУ BIOS проводит
тестирование оборудования, затем запускается досистемный загрузчик.
Задача этого этапа — определить (возможно, с помощью пользователя), с какого
устройства будет идти загрузка, загрузить оттуда специальную программу-загрузчик и
запустить её. Например, выяснить, что устройство для загрузки — жесткий диск, считать
самый первый сектор этого диска и передать управление программе, которая находится в
считанной области.
загрузчик первого уровня
Загрузчик первого уровня занимает обычно не более одного сектора в самом начале
диска — в его загрузочной записи. Загрузочная запись диска (Master Boot Record) — первый
сектор диска, в котором хранится таблица разделов и код системного загрузчика.
Ядро операционной системы имеет довольно сложную структуру — а значит, и
непростой способ загрузки; оно может быть довольно большим и может располагаться в
произвольной област диска, подчиняясь законам файловой системы (например, состоять из
нескольких частей, разбросанных по диску). Учесть все это первичный загрузчик не в
состоянии, поэтому его задача — определить, где на диске находится загрузчик второго
уровня, загрузить его в память и передать ему управление.
загрузчик второго уровня
Вторичный загрузчик — уже более сложная программа с интерфейсом пользователя,
который даёт возможность выбирать операционную систему или параметры загрузки ядра.
Чтобы продолжить загрузку, необходимо иметь доступ к образу ядра, поэтому зачастую в
код загрузчика включается поддержка файловых систем. Более простые загрузчики в
процессе предварительной установки сохраняют адреса всех блоков диска, в которых
располагается файл с образом ядра.
В любом случае вторичный загрузчик читает образ ядра в определённый адрес
памяти и передаёт туда управление.
Большинство операционных систем имеют собственные загрузчики первого и
второго уровней. Однако существуют и универсальные загрузчики, не привязанные к
конкретной операционной системе, например GRUB.
инициализация ядра операционной системы
Как мы уже выяснили ранее, ядро — очень сложная программа, взаимодействующая
с различным оборудованием, поэтому прежде чем начать работу с системой, ядро
необходимо проинициализировать.
Этот этап специфичен для различных операционных систем. В UNIX-подобных
системах при этом обычно выводится информация отладочного характера о ходе загрузке
ядра.
Первым делом ядро занимается определением параметров вычислительной
подсистемы компьютера: выясняет тип и быстродействие центрального процессора, объем
оперативной памяти, объем и структуру кэш-памяти; делает предположение об архитектуре
компьютера в целом и многое другое.
На следующем шаге ядро определяет состав и архитектуру всего аппаратного
наполнения компьютера: тип и параметры шин передачи данных и устройств управления
ими (контроллеров), список внешних устройств, доступных по шинам, настройки этих
устройств — диапазон портов ввода-вывода, адрес ПЗУ, занимаемое аппаратное
прерывание, номер канала прямого доступа к памяти и т. п.
 Ядро на основании параметра, переданного ему загрузчиком, выбирает корневой
раздел — файловую систему, содержащую будущий каталог / и его подкаталоги (для
системной начальной загрузки важны каталоги /etc, /bin, и /sbin). Корневой раздел
монтируется в качестве /. После этого ядро запускает первый процесс — init (по умолчанию,
/sbin/init).
процесс init
С этого момента операционная система обеспечивает полноценную
функциональность всем исполняющимся процессам. В UNIX первым запускаемым
процессом является init, о котором сказано в следующем разделе.
Процесс init является обычным процессом операционной системы, однако он имеет
некоторые особенности: его PID всегда равен 1, и процесс этот выполняется всё время, пока
работает система.
В UNIX-системах init играет две важные роли:
− производит инициализацию системы — как правило, для работы запущенного ядра
не достаточно, нужно смонтировать все файловые системы, загрузить
дополнительные драйверы устройств, запустить демоны и т. п.;
− является родительским для всех процессов в системе — это является гарантией того,
что в UNIX для любого процесса в любой момент времени будет существовать
родительский процесс.
Пример иерархии процессов в UNIX
Это обеспечивается тем, что в UNIX процессы создаются с помощью
последовательного ответвления (системный вызов fork), а изначальной точкой ветвления
является init.
Как правило, процесс init запускается из исполняемого файла /sbin/init и работает с
некоторыми специфическими особенностями в различных UNIX-системах. Рассмотрим
классификацию современных версий UNIX с точки зрения инициализации системы.

Механизмы удаленной загрузки UNIX. Требования к оборудованию и

архитектура программного обеспечения, необходимые для загрузки
Linux
Схема удаленной загрузки:
1. Когда клиентский компьютер включается, он производит стандартную проверку
системы до того, как управление передается TCP/IP Bootprom или PXE Boot ROM.
2. ППЗУ удаленной загрузки посылает запрос BOOTP/DHCP, чтобы узнать
параметры IP-конфигурации. Это может быть имя файла, хранящего образ начальной
загрузки для данной станции, параметры сетевых протоколов (сетевое имя станции, сетевой
адрес и др.), а также другие параметры.
3. Если сервер узнает компьютер, пославший запрос, он посылает обратно
BOOTP/DHCP-ответ с различной информацией: IP адрес клиента, шлюз по умолчанию и
образ загрузочного диска, который нужно использовать. На рабочую станцию загружается
предварительно сформированный и хранящийся на сервере образ начальной загрузки.
Образ начальной загрузки представляет собой образ загрузочного диска.
4. После этого BootPROM скачивает загрузочный образ с сервера, используя
протокол TFTP. BootPROM организует RAM-диск в памяти станции и записывает туда образ
начальной загрузки и передает ему управление.
5. Выполнение образа начальной загрузки. В простейшем случае процесс удаленной
загрузки на этом может быть закончен, однако для получения полноценной сетевой рабочей
станции необходимо предоставить пользователю доступ к сетевым ресурсам, для чего
выполняют еще несколько шагов. Дальнейшие действия выполняются кодом,
содержащимся в образе начальной загрузки.
6. Загрузка рабочего стека протоколов, который будет использоваться для
дальнейших взаимодействий с сервером.
7. Идентификация и аутентификация пользователя. При этом могут использоваться
специальные аппаратные средства аутентификации. Запрос на вход в сеть посылается
серверу.
8. Организация доступа пользователя станции к сетевым файловым ресурсам. При
этом пользователю подключаются сетевые диски.
9. Завершение загрузки рабочей станции. На данном этапе происходит окончательная
загрузка и настройка среды работы пользователя на рабочей станции, при этом используется
уже доступные сетевые файловые ресурсы. Например, так может быть запущена
графическая оболочка, которая не может быть размещена в образе начальной загрузки, и
находится на сетевом диске.
Как видно из схемы удаленной загрузки, она состоит из трех этапов:
-начальной этап (пп. 1-4) получение параметров начальной загрузки с сервера;
-промежуточный этап (пп. 5-8) выполняется начальный загрузочный образ, происходит
аутентификация терминала и образование начального соединения с сервером.
-завершающий этап(п. 9) загрузка и запуск собственно рабочей среды пользователя.
Программа поддерживающая протоколы передачи начального загрузочного образа
прошивается в сетевую карту, область ППЗУ (программируемое постоянное запоминающее
устройство), это может быть программа поддерживающая протокол TCP/IP BootPROM или
PXE-совместимая программа (в большинстве сетевых карт поддерживается по умолчанию
PXE).
Также существует возможность «эмуляции области ППЗУ», компьютер будет
работать так, как будто у него есть в ППЗУ программа поддерживающая протоколы
передачи начального загрузочного образа.
В качестве протоколов начальной загрузки используются протоколы NCP (Netware),
RPL (Windows NT), BOOTP/DHCP/TFTP (UNIX).
Описание конфигурации:
Сервер — машина, настроенная на работу с удалёнными клиентами.
Клиентская машина — если Boot ROM, то надо его включить. Если же у вас PXE-
совместимое ППЗУ, то в BIOS нужно сменить устройство загрузки по умолчанию на
сетевую загрузку.

Конфигурирование BOOTP-сервера для удаленной загрузки UNIX.

Файл /etc/bootptab
Настройка BOOTP сервера:
В GNU/Linux есть два BOOTP сервера: CMU bootpd и ISC dhcpd (на самом деле
DHCP сервер); они находятся в пакетах bootp и dhcp.
Чтобы использовать CMU bootpd, во-первых, вы должны раскомментировать (или добавить)
соответствующую строку в /etc/inetd.conf. Для этого в Debian GNU/Linux вы можете
запустить update-inetd --enable bootps, затем /etc/init.d/inetd reload. Или же можно добавить
следующую строку вручную:
bootps dgram udp wait root /usr/sbin/bootpd bootpd -i -t 120
Теперь вы должны создать файл /etc/bootptab. Внутри он напоминает хорошо знакомый и
загадочный формат старых добрых BSD файлов printcap, termcap и disktab. Для CMU bootpd
вам нужно знать аппаратный адрес (MAC) клиента. Вот пример /etc/bootptab:
client:\
hd=/tftpboot:\
bf=tftpboot.img:\
ip=192.168.1.90:\
sm=255.255.255.0:\
sa=192.168.1.1:\
ha=0123456789AB:
Нужно изменить по крайней мере параметр «ha», который содержит аппаратный
адрес клиента. Параметр «bf» содержит файл, который клиент должен получить по TFTP.
Настройка BOOTP в ISC dhcpd очень проста, так как он считает клиента BOOTP, как
один из вариантов клиента DHCP. Некоторые архитектуры требуют сложной конфигурации
для загрузки клиентов по BOOTP. Если нет, то достаточно просто добавить директиву allow
bootp в конфигурационный блок подсети, содержащей клиента и перезапустить dhcpd
командой /etc/init.d/dhcpd restart. Если у вас один из таких случаев, тогда:
В Debian GNU/Linux настройка ISC dhcpd проделывается установкой пакета dhcp.
Вот пример конфигурационного файла (обычно /etc/dhcpd.conf):
option domain-name "example.com";
option domain-name-servers ns1.example.com;
option subnet-mask 255.255.255.0;
default-lease-time 600;
max-lease-time 7200;
server-name "servername";
subnet 192.168.1.0 netmask 255.255.255.0 {
range 192.168.1.200 192.168.1.253;
option routers 192.168.1.1;
}
host clientname {
filename "/tftpboot/tftpboot.img";
server-name "servername";
next-server servername;
hardware ethernet 01:23:45:67:89:AB;
fixed-address 192.168.1.90;
}
В этом примере определён единственный сервер servername, который работает в
качестве DHCP, TFTP серверов и шлюза сети. Опция filename должна содержать имя файла,
который нужно получить по TFTP.
После редактирования конфигурационного файла dhcpd, перезагрузите сервер
командой /etc/init.d/dhcpd restart.

Генерация ядра Linux, пригодного для удаленной загрузки системы.

Опции при компиляции, утилита mknbi (из пакета etherboot.rpm)
Скачиваем исходники ядра Linux. Исходники последней версии ядра для Linux
можно найти на ftp://ftp.kernel.org (или на каком-нибудь зеркале). Там ядра лежат в
/pub/linux/. Загружаем ядро на хард и помещаем его в каталог /usr/src. Там-же создем каталог
для файлов и каталогов ядра (обычно создают что-то типа linux-2.X.X, где 2.X.X - версия
нового ядра) командой mkdir linux-2.X.X. После этого создаем связь с каталогом linux (ln -s
linux-2.X.X linux). Если каталог linux-2.X.X уже существует, то его предварительно надо
удалить.
Подготовим древо каталогов для файлов исходных кодов ядра. Синтаксис команды
для восстановления древа зависит от формата скаченного файла. В нашем случае это могут
быть файлы linux-2.X.X.tar.gz и linux-2.X.X.tar.bz2. Для каждого из файлов используется
определенный набор команд. Для linux-2.X.X.tar.gz: tar xzvf linux-2.X.X.tar.gz Для linux-
2.X.X.tar.bz2: bzcat linux-2.X.X.tar.bz2 | tar xv При выполнении этих команд содержимое
файлов развернется в каталог, определенный связью linux. После этого командой cd
перейдем в каталог linux (cd linux). Этот каталог называется каталогом верхнего уровня
исходного древа. В нем много каталогов, одним из которых является Documentation, в
котором хранится дополнительная информация по ядру. Для начала компиляции нового
ядра выполним команду: make mrproper Ядро скомпилировано. Теперь его необходимо
настроить для удаленной загрузки.
Конфигурирование ядра. На этом этапе придется выбрать опции, которые будут
использоваться в новом ядре. Существуют три метода создания файла конфигурации,
используемого при сборке нового ядра: make config, make menuconfig, make xconfig, make
gconfig, make oldconfig.
make config - это наиболее простой пошаговый сценарий. make menuconfig - это
более удобный метод (требует наличие ncurses). make xconfig - это графическая утилита для
настройки ядра. Перед тем, как ей воспользоваться необходимо перейти в среду X Window.
make gconfig - то же что в первом случае, только для графичекой среды GNOME, make
oldconfig — этот вариант очень полезен если у нас уже есть сформированный файл настроек
.config (можно использовать файл настроек от старого ядра). В этом варианте задаются
только вопросы по возможностям, которые появились с той версии ядра, для которой сделан
файл настроек.
После выполнения этой команды сначала скомпилируются необходимые элементы,
затем появится диалоговое окно. Для каждой из представленных опций есть 3 установочных
параметра: y,m,n. y(yes) - Включает или встраивает опцию в ядро. m(module) - Создает для
выбранной опции загружаемый в динамическом режиме модуль (без reboot'a). Существует
не для всех опций. n(no) - Отключает поддержку опции. Для использования конфигуратора
на базе X в системе должны буть установлены библиотеки TCL/TK. Приготовим ядро для
удаленной загрузки системы, для этого когда будем конфигурировать ядро, добавим
поддержку сетевых карт, поддержку чипсетов, протокола TCP, NFS и т.д. Дополнительно,
необходимо включить следующие настройки:
CONFIG_BLK_DEV_LOOP (Включение этого режима позволит нам монтировать
обычный файл как файловую систему)
CONFIG_BLK_DEV_NBD (NBD (Network Block Device) — устройства с файлом
виртуального диска. После этого NBD-устройство можно монтировать как обычный диск
или loopback-устройство.)
CONFIG_BLK_DEV_RAM (только при подключении корневой файловой системы с RAM
диска)
CONFIG_BLK_DEV_RAM_SIZE = 30720 (только при подключении корневой файловой
системы с RAM диска)
CONFIG_BLK_DEV_INITRD (только при подключении корневой файловой системы с
RAM диска)
CONFIG_PACKET (Эта опция необходима для приложений, работающих непосредственно
с сетевыми устройствами.)
CONFIG_FILTER (Эта опция необходима нам для работы DHCP клиента.)
CONFIG_IP_PNP (Поддержка айпи адреса на уровне ядра.)
CONFIG_IP_PNP_DHCP (Клиент DHCP на уровне ядра.)
CONFIG_NFS_FS (Поддержка монтирования файловой системы NFS.)
CONFIG_NFS_V3 (Для подключения файловой системы NFS.)
CONFIG_ROOT_NFS (только при подключении корневой файловой системы через NFS.)
Компиляция ядра и установка модулей. В свою очередь этот этап делится на шаги:
Подготовка make dep, make clean. Непосредственно сборка ядра make bzImage|bzdisk|bzlilo.
Сборка и установка модулей make modules , make modules_install. После выполнения make
dep создаются файлы зависимостей (.depend), которые располаются в каждом из
подкаталогов древа исходных кодов. Если нет нарушений в расположении компонентов
древа, то процесс пройдет спокойно. Далее используется команда make clean, которая удалит
все лишние (вспомогательные) файлы, созданные от предыдущих процессов компиляции.
Далее идет шаг, при котором необходимо непосредственно собрать ядро. Для сборки ядра
придется выбрать одну из 3-х команд: make bzImage, make bzdisk или make bzlilo. (Обратим
внимание, что возможна компиляция командой make bImage, в этом случае, в отличие от
команды make bzImage, скомпилированное ядро будет несжатым.) Каждая из команд
выполняет фактически одну и ту-же операцию, только две последние выполняют одно
дополнительное действие. Рассмотрим подробнее каждую из команд: make bzImage —
стандартная операция, при которой будет только скомпилировано ядро. Если все прошло
без проблем, то созданное в результате компиляции ядро будет расположено в каталоге
/usr/src/linux/arch/i386/boot. В этом случае ядру присваивается имя bzImage. make bzdisk —
этот метод позволяет выполнить практически туже задачу, что и bzImage, но после
завершения компиляции будет автоматически выполнено копирование нового ядра на
дискету. В дальнейшем эту дискету можно будет использовать для загрузки системы. make
bzlilo — это рекомендуемый метод формирования и инсталляции нового ядра, требующий
предварительной подготовки lilo. При использовании этого метода map-файл ядра не
перемещается в другой каталог. Более того новое ядро может быть записано поверх уже
существующего, причем записано с ошибками, поэтому его использование не
рекомендуется. Этот метод очень похож на bzImage и отличается только наличием
дополнительной операцией, которая выполняется после совершения компиляции ядра.
После компиляции ядра происходит копирование файлов созданного ядра в каталог / в
качестве vmlinuz (при этом сохраняется резервная копия файла vmlinuz), затем выполняется
команда lilo, в результате чего происходит переустановка диспетчера загрузки (и
распознавание нового ядра). Третим шагом является сборка и установка модулей ядра. Этот
процесс выполняется с помощью 2-х команд make modules и make modules_install. Команда
make modules производит сборку модулей, которые соответствуют ядру, созданному на
предыдущем этапе. Команда make modules_install, в сою очередь, перемещает созданные
модули из исходного древа ядра в каталог /lib/modules/<kernel-version>/kernel/<module-
type>. В качестве типа модуля (<module-type>) используется имя категории, к которой
относятся созданные модули (Например: block, misk, net, pcmcia, etc...).
Подготовка ядра для удаленной загрузки. Чтобы ядро можно было загружать через
сеть, оно должно быть специальным образом подготовлено. Для этого служит программа
mknbi, входящая в пакет mknbi (ранее входил в пакет etherboot.rpm). Программа имеет
несколько параметров, из которых мы рассмотрим четыре: --format=format указывает
формат выходного файла, --target=target указывает тип целевого двоичного кода, --
rootdir=rootdir задает имя каталога, из которого будет подмонтирована корневая файловая
система, --ip=string позволяет задать IP адреса клиента, сервера, шлюза и маску подсети.
Также возможно указать dhcp или bootp для автоматической настройки с помощью этих
протоколов. Создадим каталог, в котором будет располагаться ядро для удаленной загрузки:
mkdir /exports. Дальнейшие действия зависят от того, каким образом мы будем подключать
коревую файловую систему. Для подключения через NFS необходимо выполнить команду
(предполагается, что корневая файловая система будет располагаться в каталоге
/exports/node01) ./mknbi --format=elf --target=linux --rootdir=/exports/node01 --ip=dhcp
/usr/src/kernel-source-2.4.18/arch/i386/boot/bzImage > /exports/net_boot_kernel Для варианта с
RAM диском команда выглядит несколько иначе: ./mknbi --format=elf --target=linux --
rootdir=/dev/ram0 --ip=dhcp /usr/src/kernel-source-2.4.18/arch/i386/boot/bzImage
/initrd/initrd.gz > /exports/net_boot_kernel.
По окончании этого этапа клиентский компьютер уже может загружать ядро.

Конфигурирование корневой файловой системы Linux. Структура

директории /tftpboot
Для конфигурирования корневой файловой системы Linux необходимо чётко знать
основные положения стандарта FHS.
Корневой каталог. Стандарт FHS предлагает создать в корневом каталоге следующие
подкаталоги
bin Файлы основных команд (утилит), которые необходимы, когда никакая
другая файловая система еще не смонтирована (например, в
однопользовательском режиме).
boot Неизменяемые файлы, необходимые для загрузки системы

dev Файлы устройств

etc Файлы конфигурации системы на данном компьютере

home Домашние каталоги пользователей

lib Основные разделяемые библиотеки и модули ядра

lib Основные разделяемые библиотеки для альтернативных форматов

исполняемых файлов
mnt Точка монтирования для временно подключаемых файловых систем

root Домашний каталог суперпользователя root

opt Дополнительные пакеты программного обеспечения

sbin Основные системные исполняемые файлы

tmp Временные файлы

usr Иерархия второго уровня

var Переменные данные

Это не означает, что все содержимое перечисленных каталогов должно размещаться

в корневой файловой системе. Указанные каталоги могут являться просто точками
монтирования для других файловых систем или ссылками на такие системы. Более того, в
стандарте явно рекомендуется размещать в каталогах /usr, /opt и /var такие файлы, которые
могут располагаться в других разделах диска или в других файловых системах.
В соответствии с требованиями стандарта приложения не должны создавать файлов
и каталогов или требовать наличия каких-то специальных файлов и каталогов (кроме
перечисленных выше) в корневой директории. Существует несколько причин, по которым
это запрещено:
• размер корневой файловой системы желательно сохранять по возможности малым из
соображений безопасности и удобства использования;
• если придерживаться данного соглашения, проще решаются проблемы
монтирования других файловых систем, расположенных на других устройствах;
• и, наконец, стандарт FHS обеспечивает достаточную гибкость и удобство
размещения файлов, не попавших в корневую систему, в других файловых системах
и подкаталогах.
Обратите внимание на то, что некоторые подкаталоги корневого каталога помечены
значком (optional). Это означает, что стандарт не требует обязательного наличия таких
каталогов в системе. Но уж если они существуют, то должны размещаться в корневом
каталоге (но не обязательно в корневой файловой системе).
А теперь последовательно рассмотрим назначение каждого из основных
подкаталогов корневого каталога.
Каталог /bin. В каталоге /bin не должно быть подкаталогов. Каталог /bin содержит
команды, которые могут использоваться как системным администратором, так и рядовыми
пользователями.
Каталог /boot. Этот каталог содержит все, что необходимо в процессе загрузки,
исключая конфигурационные файлы и установщик карты загрузки (the map installer). Здесь
же находятся резервные сохраненные копии главной загрузочной записи (master boot
sectors) и другие данные, которые не подлежат прямому редактированию. Ядро
операционной системы должно быть расположено либо в корневом каталоге /, либо в /boot.
Программы, необходимые загрузчику для организации загрузки файлов, должны быть
расположены в /sbin. Конфигурационные файлы загрузчика должны размещаться в /etc.
Каталог /dev - это место расположения специальных файлов устройств. На случай,
если потребуется создавать файлы устройств вручную, каталог /dev должен содержать
команду MAKEDEV, которая может создать файл устройства в случае необходимости.
Каталог /etc содержит конфигурационные файлы и каталоги, специфичные для
данной конкретной системы. В каталоге /etc не должно быть бинарных файлов. В
соответствии со стандартом FHS этот каталог в обязательном порядке должен содержать
подкаталог /opt, в котором должны размещаться подкаталоги с конфигурационными
файлами отдельных пакетов и приложений. Для каждого установленного пакета <package>
должен создаваться конфигурационный каталог /etc/opt/package. Надо отметить, что не все
дистрибутивы следуют этому правилу: часто конфигурационные каталоги пакетов
размещаются непосредственно в /etc.
Каталог /home. В небольших системах каждый домашний каталог пользователя
является одним из непосредственных подкаталогов каталога /home, таких как /home/smith,
/home/torvalds, /home/operator и так далее. В больших системах (особенно когда каталоги
/home являются разделяемыми между многими хостами посредством NFS) полезно
объединить домашние каталоги в группы, введя подкаталоги групп такие как /home/staff,
/home/guests, /home/students и так далее. Но как бы то ни было, структура домашних
каталогов различается от хоста к хосту. Следовательно, никакая программа не должна
полагаться на какие-то предположения о структуре домашних каталогов.
Каталог /lib содержит те разделяемые библиотеки, которые необходимы для загрузки
системы и запуска команд, расположенных в каталогах /bin и /sbin.
Более одного варианта каталога /lib может существовать в системах,
поддерживающих более одного формата исполняемых файлов (например, 32-х и 64-х
разрядные форматы), при этом для каждого формата требуется свой отдельный вариант
разделяемых библиотек (которые могут называться /lib32 и /lib64).
Каталог /mnt. Эта директория предназначена для того, чтобы системный
администратор мог временно монтировать файловые системы по мере необходимости.
Содержимое этого каталога индивидуально для каждой системы и не должно никаким
образом влиять на работу запускаемых программ.
Каталог /opt. Стандарт FHS резервирует каталог /opt для установки дополнительных
пакетов программного обеспечения. Предполагается, что любой пакет, который
устанавливается в каталог /opt, должен размещать свои статические файлы в отдельной
каталоговой структуре /opt/<package>, где <package> - название соответствующего пакета
программного обеспечения.
Каталог /root — это домашний каталог суперпользователя. Он может быть задан
разработчиком или определен при инсталляции системы, но рекомендуемое место его
расположения по умолчанию – корневая файловая система.
Каталог /sbin. Утилиты для выполнения задач системного администрирования (и
другие команды, используемые только пользователем root) размещаются в /sbin, /usr/sbin и
/usr/local/sbin. Каталог /sbin содержит исполняемые файлы, необходимые для загрузки
системы и ее восстановления в различных ситуациях (restoring, recovering, and/or repairing
the system), не попавшие в каталог /bin.
Единственная команда, которая обязательно должна присутствовать в /sbin, это
команда shutdown - команда остановки системы.
Каталог /tmp предназначен для хранения временных файлов, создаваемых в процессе
работы различных программ. При этом программы не должны предполагать, что какой-либо
файл в каталоге /tmp сохранится при следующем запуске программы.
Каталог /usr — это второй по важности раздел файловой системы. /usr содержит
разделяемые данные, предназначенные только для чтения. Это означает, что /usr может быть
доступен с различных FHS-совместимых хостов и права записи в него не должно быть.
Любая информация, которая является специфичной для конкретного хоста или может
изменяться со временем, должна записываться в другое место.
/usr/local: Каталог для локального ПО. Следующие каталоги или символические
ссылки на каталоги должны иметься в /usr/local: bin - Локальные исполняемые файлы, games
- Локально установленные игровые приложения, include - Локальные заголовочные файлы
для C, lib - Локальные библиотеки, man - Локальные онлайновые руководства, sbin -
Локальные системные исполняемые файлы, share - Архитектурно-независимые структура
каталогов для локального ПО, src - Локально установленные исходные коды.
Структура каталогов /usr/share предназначена для всех файлов, которые
предназначены только для чтения и не зависят от архитектуры. Так, например, компьютеры
на платформах i386, Alpha и PPC могут поддерживать один общий каталог /usr/share,
который монтируется на остальных компьютерах. Заметим, однако, что /usr/share обычно
рассчитан на одну версию ОС и не предназначен для того, чтобы быть разделяемым
различными операционными системами или различными версиями одной и той же ОС.
Примерами файлов, которые размещаются в этом каталоге, могут служить файлы
документации (man, doc) или базы данных (dict, terminfo, zoneinfo). Любая программа или
пакет, который содержит или требует данных, не подлежащих модификации, должны
хранить эти данные в каталоге /usr/share (или /usr/local/share, если пакет установлен
локально). Рекомендуется использовать для этих целей подкаталоги каталога /usr/share.
Данные игровых программ, сохраняемые в /usr/share/games, должны быть чисто
статическими данными. Любые модифицируемые файлы, такие как файлы с результатами
игр, протоколы игр и так далее, должны размещаться в каталоге /var/games.
/usr/share/dict : Словари
/usr/share/man : Страницы руководства man
/usr/share/misc : Различные архитектурно-независимые данные
Каталог /var содержит файлы с изменяющимися данными. В их число входят
каталоги и файлы спулинга, данные об администрировании и логировании, временные
файлы.
Каталог /var/cache предназначен для кэширования данных приложениями.
Каталог /var/cache/fonts должен использоваться для хранения динамически
создаваемых шрифтов.
/var/crash : Дампы памяти при крахе системы.
/var/lock : Файлы блокирования. Файлы блокирования устройств и других ресурсов,
используемые многими приложениями.
/var/log : Каталоги и файлы протоколов. Эта директория содержит разнообразные
файлы протоколов. Большая часть протоколов должна записываться в этот каталог или
соответствующий подкаталог.
/var/mail : Почтовые ящики пользователей.
/var/opt : Переменные данные для /opt.
Переменные данные для пакетов, установленных в /opt, должны размещаться в
/var/opt/<package>, где <package> - это название структуры каталогов в /opt, в которой
хранятся статические данные дополнительного пакета ПО, исключая те случаи, когда
размещение явно указано в каком-либо файле из /etc. На внутреннюю структуру каталога
/var/opt/<package> никаких ограничений не накладывается.
/var/run : Переменные данные времени выполнения. Этот каталог содержит данные,
описывающие состояние системы с того момента, как она была загружена Файлы в этом
каталоге должны очищаться (удаляться или урезаться соответствующим образом) в начале
процесса загрузки системы. Программы могут иметь подкаталоги в каталоге /var/run; это
приветствуется для программ, которые используют более одного файла времени
выполнения.
 /var/spool : Очереди данных для приложений. Каталог /var/spool содержит данные,
которые ожидают какой-то последующей обработки (программой, пользователем или
администратором); обычно после обработки эти данные удаляются.
/var/tmp : Временные файлы, сохраняемые между перезапусками системы. Каталог
/var/tmp сделан доступным для программ, которым требуется временные файлы или
каталоги, которые должны сохраняться между перезагрузками системы. Следовательно,
данные, хранящиеся в /var/tmp, являются более постоянными, чем данные в /tmp.
/tftpboot – Этот каталог будет являться корневым (/) для клиентов при получении
запросов. Если выбранный каталог не существует, он должен быть создан с помощью
команды mkdir. Команда для нашего примера /tftpboot следующая: mkdir /tftpboot.
В /tftpboot у нас уже лежит файл сетефой загрузчик (например pxelinux.0 из архива
syslinux) и наше ядро для бездисковых станций (например bzImage).
Последняя по порядку, но не по важности вещь в каталоге /tftpboot – папка
/tftpboot/pxelinux.cfg/, где будет располагаться конфигурационный файл с именем
“айпишник клиента”. Для каждого клиента создается файл /tftpboot/pxelinux.cfg/XXXX, где
имя XXXX файла – это IP-адрес клиента в шестнадцатеричной форме. Т.е. для клиента с
адресом 192.0.2.91 это будет конфиг /tftpboot/pxelinux/C000025B. Наконец, если ни один из
конфигов не подойдет, то pxelinux читает /tftpboot/pxelinux/default.
Корневую файловую систему, монтируемую по сети, которую мы будем
экспортировать клиентам, мы решили создать в /home/nfsroot. За основу можно взять
существующую файловую систему, скопировав в /home/nfsroot следующие каталоги: bin,
dev, etc, lib, proc, root, sbin, tmp, usr, var, home. Замечу, что dev и proc нужно просто создать
руками как пустые директории. Также необходимо скопировать каталог /etc, но в нём
изменению подвергается fstab:
192.168.1.1:/home/nfsroot / nfs defaults 0 0
proc /proc proc defaults 0 0

Возможные конфигурации работы X Windows System на сетевых

компьютерах
Понятия X-терминала, X-сервера, сервера шрифтов, Windows-менеджера, X-приложения
Сетевой компьютер — компьютер, являющийся компонентом архитектуры
компьютер-сеть[источник не указан 30 дней] и имеющий упрощённую структуру
(небольшой объём памяти, возможно отсутствие дисковода и т. п.).
X Window System — оконная система, обеспечивающая стандартные инструменты и
протоколы для построения графического интерфейса пользователя. Используется в UNIX-
подобных ОС.
X Window System обеспечивает базовые функции графической среды: отрисовку и
перемещение окон на экране, взаимодействие с мышью и клавиатурой. X Window System не
определяет деталей интерфейса пользователя — этим занимаются менеджеры окон,
которых разработано множество. По этой причине внешний вид программ в среде X Window
System может очень сильно различаться в зависимости от возможностей и настроек
конкретного оконного менеджера.
X-терминал — это выделенное аппаратное обеспечение, на котором выполняется X-
сервер и которое служит в качестве тонкого клиента.
X-сервер может быть:
 • системной программой, контролирующей вывод видео на
персональном компьютере;
• приложением, отображающим графику в окно какой-то другой
дисплейной системы;
• выделенным компонентом аппаратного обеспечения.

В этом примере X-сервер принимает ввод с клавиатуры и мыши

и производит вывод на экран. На пользовательской рабочей станции
выполняются веб-браузер и эмулятор терминала. Программа
обновления системы работает на удалённом сервере, но управляется с
машины пользователя. Обратите внимание, что удалённое приложение
работает так же, как если бы оно выполнялось локально.
Сервер шрифтов — это сетевой сервис с простым протоколом, предоставляющий
X11 набор шрифтов. Он предоставляет как список шрифтов, так и изображение.
Менеджер окон X Window System — приложение, работающее «поверх» X Window
System и определяющее интерфейс и взаимодействие с пользователем.
X-приложения — оконные приложения работающие в оконной системе X Window
System.
Конфигурации работы X Window System на сетевых компьютерах на примере файла
конфигурации xorg.conf.
Конфигурационный файл Xorg называется xorg.conf и находится в папке /etc/X11. В
пакет Xorg-X11 входит его пример под названием /etc/X11/xorg.conf.example, который
можно использовать при создании своей собственной конфигурации. Он подробно
прокомментирован, но если вы нуждаетесь в подробном описании синтаксиса, не
стесняйтесь обратиться к страницам справки:
man 5 xorg.conf
Автоматическая генерация xorg.conf. Xorg способен самостоятельно подобрать
большинство параметров за вас. Скорее всего, вам потребуется всего лишь изменить
несколько строк, чтобы установить желаемое разрешение экрана. Если вы заинтересованы
в более глубокой настройке, обязательно просмотрите ресурсы, указанные в конце этой
главы. Но сначала создадим конфигурационный файл Xorg.
Xorg - configure. Обязательно прочтите последние строки, выводимые после
завершения опроса оборудования Xorg. Если вы увидите, что где-то Xorg не удалось
правильно опознать устройства, то вам придётся править файл xorg.conf вручную. Если же
всё прошло гладко, Xorg должен сообщить вам, что создан файл и готов для тестирования
файл /root/xorg.conf.new. Протестируем его.
X - config /root/xorg.conf.new. Если всё в порядке, вы увидите чёрно-белый узор.
Проверьте, работает ли мышь, и подходит ли разрешение экрана. Вряд-ли удастся точно
угадать разрешение, но всё-же оно, вероятно, будет слишком низкое. Выйти можно в любой
момент, нажав комбинацию клавиш Ctrl+Alt+Backspace.
Полуавтоматическая генерация xorg.conf. В Xorg есть утилита xorgconfig, задающая
различные вопросы о вашей системе (о графическом адаптере, клавиатуре и т.п.).
Основываясь на ваших ответах, она создаст файл xorg.conf. Xorgconfig. Другая утилита,
также входящая в пакет Xorg — xorgcfg, которая сначала пытается выполнить Xorg -
configure, а затем запускает X-сервер для более тонкой настройки. Xorgcfg, если X даст
сбой, или настройка завершится неудачей, попробуйте: xorgcfg -textmode.
 Копирование в xorg.conf. Теперь скопируем xorg.conf.new в /etc/X11/xorg.conf, чтобы
не приходилось постоянно запускать Xorg -config: набирать просто X или startx гораздо
проще. cp /root/xorg.conf.new /etc/X11/xorg.conf
Использование startx. Теперь попробуем ввести startx, чтобы запустить свой X-
сервер. startx — это сценарий, запускающий сеанс X, то есть серверы X, а поверх них —
некоторые графические приложения. Он решает, какие приложения запустить, исходя из
следующей логики:
• если в домашнем каталоге есть файл с именем .xinitrc, то выполняются команды,
перечисленные в нём
• в противном случае считывается значение переменной XSESSION и запускается
один из указанных в /etc/X11/Sessions/ сеансов (указать значение XSESSION по
умолчанию, для всех пользователей системы, можно в файле /etc/rc.conf)
• если вышеуказанное завершилось неудачей, производится откат к простейшему
диспетчеру окон, обычно twm.
startx
Если вы увидели уродливый, устаревший диспетчер окон, то это, скорее всего, twm.
Чтобы завершить сеанс twm, наберите exit или нажмите Ctrl-D в одном из терминалов xterm.
«убить» сеанс X также можно, нажав комбинацию клавиш Ctrl+Alt+Backspace.
Установка разрешения экрана. Если вы чувствуете, что разрешение экрана
неподходящее, вам потребуется проверить два раздела конфигурации. Прежде всего, в
разделе Screen, где перечисляются варианты разрешения экрана, с которыми может
запускаться X-сервер. По умолчанию в этом разделе может вообще не быть никаких строк
о разрешении экрана. В таком случае Xorg оценивает допустимое разрешение на основе
данных из другого раздела: Monitor.
При этом Xorg для вычисления правильных вариантов разрешения использует
значения HorizSync (частота строк) и VertRefresh (частота кадров) из раздела Monitor. Пока
что оставьте эти параметры как есть. Лишь в том случае, когда изменения в разделе Screen
(которые мы опишем чуть ниже) не помогают, вам придется заглянуть в технические
характеристики своего монитора и указать правильные значения. Также можно
воспользоваться программой, определяющей технические характеристики вашего
монитора, например, sys-apps/ddcxinfo-knoppix.
Теперь поменяем значения разрешения. В следующем примере, взятом из
/etc/X11/xorg.conf, мы добавим строчки Modes (режимы) и DefaultDepth (цветность), чтобы
X-сервер по умолчанию запускался в режиме 24 бит при 1024x768 разрешении экрана.
Особо не обращаем внимания на значения — это просто пример и, скорее всего, они будут
отличаться от настроек вашей системы.
Section "Screen"
Identifier "Default Screen"
Device "S3 Inc. ProSavage KN133 [Twister K]"
Monitor "Generic Monitor"
DefaultDepth 24
# несколько строк пропущены для наглядности
SubSection "Display"
Depth 24
 Modes "1024x768"
EndSubSection
EndSection
Запустите X (startx), чтобы обнаружить, что сервер использует желаемое
разрешение.
Настройка клавиатуры. Чтобы настроить X на использование национальных
раскладок, найдите раздел InputDevice (устройство ввода), определяющий настройки
клавиатуры, и добавьте параметр XkbLayout с указанием необходимой раскладки. Для
примера, покажем, как добавить бельгийскую раскладку. Просто измените код страны на
свой:
Section "InputDevice"
Identifier "Generic Keyboard"
Driver "keyboard"
Option "CoreKeyboard"
Option "XkbRules" "xorg"
Option "XkbModel" "pc105"
Option "XkbLayout" "be"
EndSection
Настройка мыши. Если ваша мышь не работает, сначала придётся выяснить,
обнаружена ли она вообще ядром. Мыши (в качестве устройств) выглядят как
/dev/input/mouse0 (или /dev/input/mice, если вы хотите использовать несколько мышек). В
некоторых случаях используется название /dev/psaux. В любом случае, вы можете
убедиться, что устройство соответствует вашей мыши, просмотрев вывод
соответствующего файла устройства, одновременно передвигая мышь. В большинстве
случаев на экране должна появиться бессмыслица. Для остановки вывода нажимайте Ctrl-
C.
cat /dev/input/mouse0
(не забудьте нажать Ctrl-C для завершения)
Если ваша мышь не обнаружена, проверьте, все ли необходимые модули загружены.
Если же ваша мышь найдена, впишите устройства в соответствующий раздел
InputDevice. В следующем примере видно, как мы устанавливаем еще два параметра:
Protocol (определяет протокол, используемый мышью; у большинства пользователей —
PS/2 или IMPS/2) и ZAxisMapping (позволяющий задействовать колесико, если есть).
Section "InputDevice"
Identifier "TouchPad Mouse"
Driver "mouse"
Option "CorePointer"
Option "Device" "/dev/input/mouse0"
Option "Protocol" "IMPS/2"
Option "ZAxisMapping" "4 5"
EndSection
Запустите startx и убедитесь в корректности результата.