DISKLESS(8) NetBSD System Manager's Manual DISKLESS(8)
НАЗВАНИЕ
diskless — сетевая загрузка системы
ОПИСАНИЕ
Сетевая загрузка системы подойдёт для двух систем:
diskless система не использует носитель для загрузки или запуска (напр-
имер, сеть)
dataless система с жёстким диске, где только системное и прикладное ПО,
а информация пользователя монтируется по сети с центрального сервера.
Так же это может быть в случае ремонта или смены файловой системы на ло-
кальном диске. Это предполагает зависимость от платформы, из-за поддерж-
ки системой прошивок; не все платформы поддерживаемые NetBSD, способны
загружаться по сети.
Протоколы, используемые для получения сетевого адреса (например IP адр-
ес машины), включают, но не ограничиваются:
RARP Протокол Обратного Переопределения Адреса (ARP)
DHCP Протокол Динамической Настройки Сервера
BOOTP Протокол Начальной Загрузки
Эта информация может быть получена из энергонезависимой памяти или пре-
образование сетевого интерфейса (например, Ethernet) MAC-адрес.
Протоколы для сетевой загрузки ядра NetBSD, включают, но не ограничива-
ются:
TFTP Простой Протокол Передачи Файла
NFS Сетевая Файловая Система Sun
RMP Протокол Удалённого Обслуживания HP
MOP Протокол Удалённого Обслуживания DEC
Получение имени файла вторичной программой загрузки может быть получено
путём преобразования сетевого интерфейса MAC (или другого адреса прото-
кола) или с помощью BOOTP и DHCP. Происходящее будет зависеть от платф-
ормы; см boot(8)
Ядро NetBSD не волнует как оно загружается и запускается. Протоколы для
загрузки NetBSD могут совершенно отличными, чем используемые NetBSD оп-
еративно, т.е. Можно использовать сетевую загрузку по HP RMP и тогда
ядро сможет использовать IP для соединения после первоначальной загру-
зки.
Не существует стандартного способа передать всю необходимую информацию
от загрузчика к ядру, поэтому обычно ядро NetBSD, повторять (либо ана-
логичный) сетевой протокол для обмена по полученному адресу, определе-
ния используемого сервера, и так далее. NetBSD поддерживает получение
такой информации по RARP, BOOTP, DHCP и Sun RPC «bootparams». См. jpt-
ions(4) для списка способов сборки ядра с такими методиками.
Монтирование NetBSD, Sun Network File System (NFS) осуществляемая по
сети только в корневую файловую систему. NetBSD может использовать л-
юбое запоминающее устройство как драйвер после первоначальной загруз-
ки, даже если устройство не поддерживает прошивку для загрузки систе-
мы.
Обрати внимание DHCP существенно расширяет BOOTP; В NetBSD dhcpcd(8)
может отвечать на запросы обоих протоколов.
В большинстве настроек сетевой загрузки серверов и клиентов, подклю-
ченных к одной локальной сети, клиент может быть опознан сервером по
широковещательному запросу. Специально настроенные маршрутизаторы у-
частка транслирующие из под сети в под сеть, а некоторые могут быть
настроены как ведущие, передача BOOTP в другую под сеть, через такие
маршрутизаторы, позволяет удалённой локальной сети отвечать на запро
сы клиента
ШАГИ
Сетевая загрузка состоит из трёх шагов взаимодействия между клиентом
и сервером:
1. Система прошивки (или 1 шаг загрузки) загружает программу загр-
узчик
2. Программа загрузчика получает ядро NetBSD
3. Ядро NetBSD монтирует корневую ФС на NFS
Ниже, каждый шаг описан подробнее:
1. Получение программы загрузчика
Шаг 1, система прошивки загружает программу загрузчик. Структура пр-
ошивок отличается друг от друга, поэтому этот шаг зависит от платфо-
рмы. Вот парочка примеров:
Система DEC Alpha использует BOOTP для определения IP-адреса клиента
, затем с TFTP получает вторичный загрузчик и имя файла с сервера,
указанных в ответе TFTP. Система DEC ALPHA может использовать MOP (п-
рим. Maintenance Operations Protocol) для загрузки программы и запус-
ка системы.
Система Sun использует RARP, для определения IP-адреса клиента, и пр-
еобразует в 16 строку для формирования имени файла для вторичной про-
граммы загрузчика, а затем использует TFTP для загрузки программы с
сервера, который отправит RARP ответ.
Система HP 300-серии использует HP RMP для загрузки программы загруз-
чика
Типичный ПК может загрузить программу сетевого загрузчика с дискеты
или PROM сетевого адаптера (NIC). Некоторые BIOS поддерживают загруз-
ку из сетевого интерфейса.
2. Загрузка ядра
На шаге 2, вторичный загрузчик получает ядро. Работа на этом шаге, за-
висит от структуры программы загрузки (структура загрузки описанная у
SUN и NetBSD/hp300). Программа загрузки:
1. Используя RARP, получить IP-адрес клиента.
2. Получаем имя клиента и адрес сервера, передавая запросы с IP-ад-
реса клиента RPC/BOOTPARAMS/WHOAMI
3. Получаем маршрут сервера для используемого корня клиента RPC/BO-
OTPARAMS/GETFILE запрашивают имя клиента
4. Получаем обработку запросов по маршруту сервера mountd(8) для к-
орня клиента
5. Получаем обработку файла ядра, вызывая lookup() NFS на дескрипт-
ор файла корня.
6. Загружаем ядро, используя чтение NFS вызвовшаего дескриптор фай-
ла ядра
7. Передача точки входа ядру для управления
BOOTP и/или DHCP для вторичного загрузчика будут делать следующее:
1. Запрос для загрузки клиентской программы. Ответ должен включать
IP-адрес клиента, и сервер загрузки ядра NetBSD.
2. Загрузка ядра NetBSD с сервера TFTP.
3. Передача управления точкой входа, ядру.
3. Монтирование корневой файловой системы на NFS
Шаг 3, ядро производит монтирование на NFS корневой файловой системы.
Ядро повторяет большую часть работы, проделанной программой загрузки,
т.к. нет стандартного способа для передачи собранной информации про-
граммой загрузки, ядру.
В общем, config(1) GENERIC ядра для какой-либо архитектуры во время
сборки будет определять те же протоколы, что и вторичный загрузчик
для данной архитектуры. Ядро NetBSD может быть собрано с поддержкой
BOOTP, DHCP, или Sun RPC BOOTPARAMS; см. options(4).
Обычно применяемая процедура ядра выглядит следующим образом:
1. Ядро находит сервер для загрузки, используя всё то же, что описа-
но выше для определения IP-адреса клиента, сервера NFS и т.д.
2. Ядро получает обработку файла с NFS для получения корня, по той
же схеме, что описана выше.
3. Ядро вызывает getattr() NFS, для получения времени последних из-
менений корневого каталога и использует его для проверки системного
времени.
НАСТРОЙКА СЕРВЕРА
Перед началом сетевой загрузки клиента, необходимо настроить сервер.
Каждый демон, настраивается таким образом, что бы отвечать на запро-
сы клиентов. Некоторые из них входят в службу inetd(8), как пакеты,
а некоторые могут работать независимо друг от друга, и запущены из
/etc/rc. См. Страницу руководства rc.conf(5)
Протокол Программа Запускается
RARP rarpd rc.conf(5)
DHCP dhcpd rc.conf(5)
BOOTP bootpd inetd.conf(5)
TFTP tfptd inetd.conf(5)
Sun RPC rpcbind rc.conf(5)
Sun RPC rpc.bootparamd rc.conf(5)
Sun NFS mountd rc.conf(5)
Sun NFS nfsiod rc.conf(5)
HP RMP rbootd rc.conf(5)
Обрати внимание, DHCP существенно расширенная версия BOOTP; В NetBSD
dhcpcd(8) может отвечать на запросы обоих протоколов. Так они объед-
енены в один порт UDP, и только один из них может быть запущен на с-
ервере.
В следующих примерах, имя машины клиента myclient; сервер как myser-
ver, все адреса придуманы. В примерах могут присутствовать полные д-
оменные имена (FQDN, например "myclient.mydomain.com"), при условии
последовательного применения
RARP
Для клиента использующего RARP, что бы получить свой IP-адрес, долж-
на быть запись у каждого клиента в /etc/ethers с MAC-адресом и имен-
ем машины в сети
8:0:20:7:c5:c7 myclient
Использования rarpd(8) ответов, что бы ответить на запросы клиентов.
Часто на корпусе системы клиента, печатают его Ethernet MAC, либо на
чипе материнской платы или на сетевом адаптере. Если нет, «прослуши-
вайте» сеть с tcpdump(8), при включенных клиентах можно получить E-
thernet MAC.
Каждый клиент, система, использующие RARP должны иметь свой уникаль-
ный IP-адрес. Укажите IP-адреса myclient в /etc/hosts, или главном
файле вашей зоны DNS. Для /etc/hosts, запись должна выглядеть, так:
192.197.96.12 myclient
DHCP/BOOTP
Сервер NetBSD, dhcpcd(8)был разработан консорциумом интернет прилож-
ений (ISC); http://www.isc.org/
DHCP может предоставить много информации при запросе клиента; необх-
одимые данные для загрузки клиента:
1. IP-адрес
2. Маска подсети
3. Адрес TFTP-сервера для загрузки вторичного загрузчика и ядра
NetBSD
4. Имя вторичного загрузчика
5. Адрес NFS-сервера для клиентской файловой системы
6. Путь корневого файла клиента, для монтирования NFS.
Пример для /etc/dhcpd.conf
host myclient {
hardware ethernet 8:0:20:7:c5:c7;
fixed-address myclient; # назначенные клиенту IP-адрес
filename "myclient.netboot"; # вторичный загрузчик
next-server myserver; # TFTP-сервер вторичного загрузчика
option swap-server myserver; # NFS-сервер корневой файловой системы
option root-path "/export/myclient/root";
}
Запрос машины поступает в указанную под сеть, где указываются параме-
тры для всех машин под сети, для использования DHCP, "routers" (мар-
шрут по умолчанию), "subnet-mask", "broadcast-address", "domain-name-
servers", и т. д. Подробнее в dhcpd(8). В примере myclient присутств-
ует назначенный IP-адрес
Настройки DHCP, необходимые для начальной загрузки системы, будут ме-
няться от платформы к платформе, в зависимости от системы прошивок к-
аждой из платформ. В частности, из-за того, что DHCP расширяем и нек-
оторые производители оборудования оснащают параметрами для DHCP запр-
осов клиентов, что является спецификой платформы. Более подробно смо-
трите boot(8) для вашей платформы
TFTP
При загрузке системы SUN, или других систем, которые будут использов-
ать TFTP, убедитесь, что для них inetd(8)может работать с tftpd(8).
Сервер tftpd(8) должен быть настроен для работы с каталогом /tftpboot
При загрузке системы SPARC, установите необходимую без дисковую копию
вторичного загрузчика (как /usr/mdec/boot или ofwboot.net) в каталог
/tftpboot. Сделайте ссылку таким образом, программа загрузки необход-
имого файла из 16-ричного файла IP-адреса клиента, точка и имя архит-
ектуры (всё заглавными буквами). Например:
# cd /tftpboot
# ln -s boot C0C5600C.SUN4
Для систем Sun-3 или UltraSPARC, имя файла будет простым C0C5600C (эти
системы прошивок не добавляют название архитектуры). Используемое имя
зависит от архитектуры, она должна соответствовать, необходимому имени
для распознавания программы загрузки клиента.
Если система прошивок клиента не получает необходимый файл, можно исп-
ользовать для этого tcpdump(8) при запросе. Более того, журнал провер-
ки tftpd(8) (обычно /var/log/messages) говорит, слышит ли сервер клие-
нтские машины и какое имя запрашивается.
HP RMP
При загрузке систем серии HP-300, проверьте /etc/rbootd.conf правильн-
о ли настроена программа загрузки для соединения. Запись может выгляд-
еть так:
08:00:09:01:23:E6 SYS_UBOOT # myclient
Программа вторичного загрузчика, для серии HP-300 системы SYS_UBOOT
(можно вызывать uboot.lif перед установкой) должен быть установлен в
каталог /usr/mdec/rbootd.
Смотри страницу руководства rbootd(8) для более подробной информации.
Sun RPC BOOTPARAMS
Добавьте myclient в базу данных bootparams /etc/bootparams:
myclient root=myserver:/export/myclient/root \
swap=myserver:/export/myclient/root/swap \
dump=myserver:/export/myclient/root/swap
и убедитесь, что rpc.bootparamd(8) и rpcbind(8) уже запущены. Оба
myclient и myserver должны иметь IP-адреса в DNS или /etc/hosts.
Файловая Система Без дискового Клиента
Сборка swap для клиента на сервере NFS:
# cd /export/myclient/root
# dd if=/dev/zero of=swap bs=16k count=1024
Здесь создано 16 мегабайт swap.
Наполните файловую систему myclient на сервере NFS. Как обычно, это
зависит от архитектуры клиента и версии дистрибутива NetBSD. Это м-
ожет быть просто копирование и изменение файловой системы сервера
или распаковывание бинарного NetBSD, дистрибутива для необходимой
платформы
Если сервер NFS будет поддерживать несколько различных архитектур,
(например Alpha, PowerPC, SPARC, MIPS), тогда тщательно продумайте
как их выложить файлы для внешних серверов NFS, что бы отдавать о-
бщее (например, текстовые файлы, файлы конфигурации, домашние кат-
алоги пользователей), так и отдельные, что необходимо отдельным а-
рхитекторам (например бинарные файлы, библиотеки)
NFS
Получение клиентом общих файлов на NFS-сервере в /etc/exports:
/usr -ro myclient
# for SunOS:
# /export/myclient -rw=myclient,root=myclient
# for NetBSD:
/export/myclient -maproot=root -alldirs myclient
Если клиент и сервер одной архитектуры, то клиент может совместно
использовать файловую систему /usr, как сделано выше. Если нет, вы
должны создать конкретный /usr, в другой части файловой системы с-
ервера, для работы клиента.
Если у вас сервер SPARC, а клиент SUN-3, можно создать и наполнить
/export/usr.sun3, а затем использовать строки в /etc/exports:
/export/usr.sun3 -ro myclient
/export/myclient -rw=myclient,root=myclient
Конечно, в любом случае вы будете иметь NFS-сервер работающий на
сервере.
НАСТРОЙКА КЛИЕНТА
Скопируйте и настройте, как минимум следующие файлы в /export/my-
client/root
# cd /export/myclient/root/etc
# vi fstab
# cp /etc/hosts hosts
# echo 'hostname="myclient"' >> rc.conf
# echo "inet 192.197.96.12" > ifconfig.le0
Обратите внимание, что «le0» нужно заменить именем клиентского ин-
терфейса для загрузки; имя интерфейса зависит от устройства в Net-
BSD.
Правильное монтирование необходимых точек и swap клиентов в /etc/
fstab (которые в /export/myclient/root/etc/fstab), т.е.
myserver:/export/myclient/root / nfs rw 0 0
myserver:/usr /usr nfs rw 0 0
/swap none swap sw 0 0
Обратите внимание, что указать swap /etc/fstab или он не будет ис-
пользоваться. Смотри swapctl(8)
ФАЙЛЫ
/etc/hosts Таблица указанных IP-адресов и имён машин в сети; См.
hosts(5)
/etc/ethers Таблица указанных Ethernet MAC-адресов и IP имён машин
использующих rarpd(8); См. ethers(5)
/etc/bootparams Путь к корню клиента и путь к swap; См.
bootparams(5)
/etc/exports Получение точки монтирования NFS; См. exports(5)
/etc/rbootd.conf Файл настройки для HP RMP; См. rbootd(8)
/usr/mdec/rbootd Расположение программ загрузки, использующих rbootd(8)
/tftpboot Расположение программ загрузки, использующих tftpd(8)
КРОМЕ ТОГО
bootparams(5), dhcpd.conf(5), ethers(5), exports(5), fstab(5), hosts(5),
networks(5), boot(8), dhcpd(8), mopd(8), mountd(8), nfsd(8), rarpd(8),
rbootd(8), reboot(8), rpc.bootparamd(8), tftpd(8)
Reverse Address Resolution Protocol, RFC, 903, June 1984.
Bootstrap Loading using TFTP, RFC, 906, June 1984.
Bootstrap Protocol, RFC, 951, September 1985.
The TFTP Protocol (Revision 2), RFC, 1350, July 1992.
Dynamic Host Configuration Protocol, RFC, 2131, March 1997.
DHCP Options and BOOTP Vendor Extensions, RFC, 2132, March 1997.
http://www.rfc-editor.org/
NetBSD 5.0 October 7, 2006 NetBSD 5.0