Технология бездисковой (сетевой) загрузки
Назначение бездисковой загрузки
Бездисковая загрузка - метод, позволяющий загружать ОС РМ, не имеющих собственного жесткого диска с предустановленным дистрибутивом, и предоставлять их пользователям для подключения через компонент «Клиент».
Корневая файловая система РМ хранится удаленно и транслируется по сети, что упрощает администрирование и централизованное управление РМ.
При использовании метода исключается необходимость установки ОС на машине РМ: все они используют единый эталонный образ системы, а вносимые изменения хранятся локально в слоях, специфичных для каждой машины.
| c одного эталонного образа системы может загружаться несколько машин РМ. Например, для автономных машин это настраивается перечислением MAC-адресов машин в шаблоне РМ поставщика ресурсов (см. подраздел Шаблон РМ для автономной машины с сетевой загрузкой). |
Компоненты инфраструктуры бездисковой загрузки
Для работы бездисковой загрузки требуется выделенный сервер, предоставляющий среду для сетевой загрузки. Он состоит из трех основных служб, работающих в изолированной подсети РМ (во избежание пересечения потоков данных с трафиком управления фермы Termidesk VDI):
-
DHCP-сервер: работает в подсети машин РМ бездисковой загрузки. При загрузке выдает машинам IP-адреса и критически важные параметры, указывающие путь к следующим компонентам загрузки (TFTP и серверу Termidesk VDI);
-
TFTP-сервер: хранит и передает машинам РМ по запросу первоначальный загрузчик и сопутствующие файлы (конфигурации, сертификаты и пр.). Автономная машина получает эту информацию на основе данных, предоставленных DHCP;
-
iSCSI-сервер (транслятор блочных устройств): транслирует в сеть блочное устройство, которое воспринимается автономной машиной как локальный диск. В качестве источника выступает файл-образ (
.img), содержащий эталонную корневую файловую систему. Доступ настраивается через конфигурационный файл сервера.
Состав тестового стенда для быстрого развертывания приведен в таблице (см. таблицу Состав тестового стенда для бездисковой (сетевой) загрузки).
|
Cервер для бездисковой (сетевой) загрузки может настраиваться на уже существующем узле, но с соблюдением требований к DHCP- и DNS-сервисам:
Указанные опции передаются машинам РМ при загрузке по сети. |
| Узел | Описание |
|---|---|
Серверная часть |
|
Сервер для бездисковой (сетевой) загрузки |
Узел, предоставляющий сервисы DHCP, DNS и iSCSI. Может быть реализован на ВМ или на физическом узле. Требования:
|
Сервер Termidesk |
Узел с установленным компонентом «Универсальный диспетчер» («Портал администратора», «Портал пользователя» - могут быть установлены как на одном узле, так и на отдельных). Требования:
|
Узел подготовки образа для блочного устройства |
|
Узел с подключенным образом ОС Astra Linux Special Edition |
Узел для подготовки образа ОС на удаленном iSCSI-устройстве. В общем случае может быть как ВМ, так и физической машиной. Подготовленный образ будет использоваться при загрузке РМ. В дальнейшем узел не используется. При необходимости изменения образа узел можно сконфигурировать повторно. Требования:
|
Машина РМ |
|
ВМ или физическая машина |
Узел, являющийся РМ для подключения пользователя. Этот узел:
Требования:
|
Пользовательская часть |
|
Пользовательская рабочая станция |
Узел, использующийся пользователем для подключения к серверу Termidesk и получения доступа к РМ |
Процесс сетевой загрузки
Загрузка происходит строго по цепочке:
-
машина РМ получает по DHCP IP-адрес и адрес TFTP-сервера;
-
машина РМ загружает с TFTP-сервера начальный загрузчик;
-
загрузчик инициализируется на машине РМ и отправляет запрос к серверу Termidesk VDI, передавая свой MAC-адрес;
-
сервер Termidesk VDI идентифицирует машину РМ и отправляет ей конфигурацию с режимом загрузки;
-
загрузчик подключается к iSCSI-серверу и получает доступ к образу корневой системы. Машина РМ воспринимает этот сетевой ресурс как обычное блочное устройство и начинает с него загрузку.
Технология наслоения (Overlay FS и работа с дисками)
Централизованное хранение системы требует наличие механизма, позволяющего каждому пользователю вносить изменения, не затрагивая общий эталонный образ. Для этого используется технология Overlay и минимум два локальных диска на машине РМ.
|
У каждой машины РМ должно быть два локальных диска. Они могут быть форматированными или неформатированными и не обязаны совпадать по размеру с корневым образом ОС. |
После монтирования корневого раздела (только для чтения), поверх него накладываются слои для записи на локальных дисках машины РМ:
-
слой 1 (read-only): эталонный корневой образ ОС с iSCSI-сервера. Является самым нижним слоем. Не может изменяться пользователем;
-
слой 2 (read-write, слой установки): локальный диск. Хранит уникальную конфигурацию машины: hostname, сетевые настройки, ключи шифрования, хеши, «Агент виртуального рабочего места» и другие параметры, получаемые при первоначальной настройке;
-
слой 3 (read-write, пользовательский слой): второй локальный диск. Создается после завершения конфигурации. Служит «черновиком» для всех изменений, вносимых пользователем и ОС в процессе работы: системные и прикладные журналы, временные файлы, данные пользовательских домашних каталогов (
/home) и т.д.
|
Размер диска, выделенного под write-слой (слой 2 или 3), подбирается исходя из ожидаемого объема устанавливаемых пакетов и пользовательской работы. Общие рекомендации:
|
Жизненный цикл и режимы загрузки
Управление машиной РМ осуществляется централизованно через сервер Termidesk («Универсальный диспетчер»), который определяет, в каком режиме загружать машину.
Режим настройки (Setup) используется при первом включении или для переконфигурации машины. Процесс выглядит следующим образом:
-
загрузчик по команде с «Универсального диспетчера» монтирует cлой 1 (root) и cлой 2 (установки);
-
загружается ОС, активируется «Агент виртуального рабочего места»;
-
«Агент виртуального рабочего места» связывается с «Универсальным диспетчером», синхронизирует ключи, получает имя узла, настройки и сохраняет их на cлой 2;
-
процесс может потребовать нескольких циклов перезагрузки. «Универсальный диспетчер» будет отправлять машину в режим Setup до тех пор, пока «Агент виртуального рабочего места» не отправит сигнал о полной готовности.
Пользовательский режим (User) является рабочим режимом для конечного пользователя. Процесс выглядит следующим образом:
-
после подтверждения готовности от «Агента виртуального рабочего места» «Универсальный диспетчер» при следующей загрузке отправит загрузчику команду на создание слоя 3;
-
система загружается со всеми тремя слоями: поверх слоя установки (слой 2) накладывается пользовательский слой (слой 3). Пользователь может выполнять любые операции на машине, подключаясь к ней через ПО Termidesk Viewer. Все изменения записываются в слой 3.
Администратор может в любой момент очистить пользовательский слой 3, вернув машину в исходное состояние, или перевести ее обратно в режим Setup для изменения конфигурации слоя 2.
Настройка стека серверов для бездисковой загрузки
Установка необходимого набора пакетов
Для подготовки узла сервера для бездисковой (сетевой загрузки) выполнить:
-
обновить список репозиториев:
apt-get update
-
обновить дистрибутив ОС:
apt-get dist-upgrade -y
-
установить набор пакетов:
apt-get install -y \
isc-dhcp-server \
tftpd-hpa \
tgt \
git \
parted \
unbound \
curl \
rsyslog
После установки у пакета isc-dhcp-server имеется набор конфигурационных файлов, которые необходимо удалить, предварительно сохранив их под другим именем:
mv -v /etc/dhcp/dhcpd6.conf /etc/dhcp/dhcpd6.conf.bak
mv -v /etc/dhcp/dhcpd.conf /etc/dhcp/dhcpd.conf.bak
Настройка конфигураций
|
Для упрощения настройки примеры конфигурации будут приводиться с учетом установки всех служб на одном узле. Файлы настройки конфигурации сделаны таким образом, чтобы при изменении версии API Termidesk VDI, или изменении IP-адресации, или изменении других параметров новые значения указывались только в одном месте конфигурации и через переменные автоматически применялись к другим конфигурациям, в которых они задаются. |
DHCP (isc-dhcp-server)
Для настройки необходимо создать новый конфигурационный файл /etc/dhcp/dhcpd.conf:
cat > /etc/dhcp/dhcpd.conf <<EOF
# DHCP-опция 93 — Client System Architecture.
# Используется PXE-машинами для указания архитектуры загрузки.
#
# Примеры:
# 00:00 — BIOS / Legacy PXE
# 00:07 — UEFI x86_64
#
# По этой опции ниже выбирается загрузочный файл:
# undionly.kpxe — для Legacy BIOS
# ipxe.efi — для UEFI
option arch code 93 = unsigned integer 16;
# ------------------------------------------------------------------------------
# Пользовательские DHCP-опции для Dynamic Diskless Loader / Termidesk
# ------------------------------------------------------------------------------
# DHCP-опция 224.
# Адрес Termidesk-сервера.
option termidesk-server code 224 = text;
# DHCP-опция 225.
# Версия API Termidesk-сервера.
option termidesk-api-version code 225 = text;
# DHCP-опция 226.
# Адрес Syslog-сервера.
option syslog-server code 226 = text;
# ------------------------------------------------------------------------------
# Пространство опций iPXE
# ------------------------------------------------------------------------------
# Объявление отдельного пространства DHCP-опций для iPXE.
option space ipxe;
# iPXE-опция 176 — no-pxedhcp.
#
# Значение 1 запрещает iPXE выполнять дополнительный PXE-DHCP-запрос.
option ipxe.no-pxedhcp code 176 = unsigned integer 8;
# ------------------------------------------------------------------------------
# Общие настройки DHCP-сервера
# ------------------------------------------------------------------------------
# Время аренды IP-адреса по умолчанию.
default-lease-time 600;
# Максимальное время аренды IP-адреса.
max-lease-time 7200;
# Отключение динамических DNS-обновлений.
ddns-update-style none;
# DHCP-сервер считается авторитетным для этой сети.
authoritative;
# ------------------------------------------------------------------------------
# Подсеть 172.16.0.0/24
# ------------------------------------------------------------------------------
subnet 172.16.0.0 netmask 255.255.255.0 {
# --------------------------------------------------------------------------
# Статические DHCP-привязки
# --------------------------------------------------------------------------
# Узел iSCSI-сервера с MAC-адресом 52:54:00:74:6d:a5 всегда будет получать
# IP-адрес 172.16.0.2.
host termidesk-iscsi-server {
hardware ethernet 52:54:00:74:6d:a5;
fixed-address 172.16.0.2;
}
# --------------------------------------------------------------------------
# Основные сетевые параметры
# --------------------------------------------------------------------------
# Шлюз по умолчанию для машин этой подсети.
option routers 172.16.0.1;
# Маска подсети.
option subnet-mask 255.255.255.0;
# DNS-сервер для клиентов.
#
# Он должен уметь разрешать имена, например:
# termidesk.local
# main.local
option domain-name-servers 172.16.0.1;
# DNS-домен для машин.
#
# Например, короткое имя:
# termidesk
#
# может быть дополнено до:
# termidesk.local
option domain-name "local";
# Динамический диапазон адресов.
#
# DHCP-сервер будет выдавать машинам адреса:
# 172.16.0.10 - 172.16.0.100
range 172.16.0.10 172.16.0.100;
# MTU интерфейса.
#
# 1400 может быть полезен для туннелей, VPN, overlay-сетей
# или проблем с фрагментацией.
option interface-mtu 1400;
# Время аренды IP-адреса именно для этой подсети.
default-lease-time 600;
# Максимальное время аренды именно для этой подсети.
max-lease-time 1800;
# --------------------------------------------------------------------------
# Параметры iPXE
# --------------------------------------------------------------------------
# Отключает дополнительный PXE-DHCP-запрос со стороны iPXE.
#
# Это делает загрузку предсказуемее, если все нужные параметры
# отдаёт этот DHCP-сервер.
option ipxe.no-pxedhcp 1;
# --------------------------------------------------------------------------
# Параметры Dynamic Diskless Loader / Termidesk
# --------------------------------------------------------------------------
# Адрес Termidesk-сервера.
#
# Передаётся машине РМ через DHCP-опцию 224.
#
# Так как указано DNS-имя termidesk.local,
# машине нужен рабочий DNS-сервер 172.16.0.1.
option termidesk-server "termidesk.local";
# Версия API Termidesk.
#
# Передаётся клиенту через DHCP-опцию 225.
option termidesk-api-version "7.0";
# Адрес syslog-сервера.
#
# Вариант с DNS-именем:
# option syslog-server "main.local";
#
# Вариант с IP-адресом надёжнее на ранней стадии загрузки,
# потому что не зависит от DNS.
#option syslog-server "main.local";
option syslog-server "172.16.0.1";
# --------------------------------------------------------------------------
# Выбор загрузочного файла по архитектуре PXE-машины РМ
# --------------------------------------------------------------------------
# Если машина РМ сообщила архитектуру 00:00,
# значит это Legacy BIOS / обычный PXE.
#
# Для него отдаём undionly.kpxe.
if option arch = 00:00 {
filename "undionly.kpxe";
# Все остальные архитектуры считаем UEFI.
#
# Для UEFI отдаём ipxe.efi.
} else {
filename "ipxe.efi";
}
# --------------------------------------------------------------------------
# Список DHCP-опций, которые нужно отдать iPXE-машине РМ
# --------------------------------------------------------------------------
# Проверяем, что машина РМ уже является iPXE.
#
# Обычно первый этап:
# PXE firmware -> получает undionly.kpxe или ipxe.efi
#
# Второй этап:
# iPXE -> снова делает DHCP-запрос с user-class = "iPXE"
#
# В этом блоке явно указываем, какие DHCP-опции iPXE должен запросить
# и получить от DHCP-сервера.
#if exists user-class and option user-class = "iPXE" {
option dhcp-parameter-request-list
1, # subnet-mask
# Маска подсети.
3, # routers
# Шлюз по умолчанию.
6, # domain-name-servers
# DNS-серверы.
15, # domain-name
# DNS-домен, например local.
26, # interface-mtu
# MTU интерфейса.
66, # tftp-server-name
# Имя или IP-адрес TFTP-сервера.
67, # bootfile-name
# Имя загрузочного файла.
224, # termidesk-server
# Пользовательская опция с адресом сервера Termidesk.
225, # termidesk-api-version
# Пользовательская опция с версией API Termidesk.
226; # syslog-server
# Пользовательская опция с адресом syslog-сервера.
#}
# --------------------------------------------------------------------------
# TFTP/PXE параметры
# --------------------------------------------------------------------------
# IP-адрес next-server.
#
# Для PXE это сервер, с которого машина РМ должна забирать загрузочный файл.
# Обычно это TFTP-сервер.
next-server 172.16.0.1;
# DHCP-опция 66 — tftp-server-name.
#
# Явно сообщает машине РМ адрес TFTP-сервера.
option tftp-server-name "172.16.0.1";
}
EOF
Затем указать серверу isc-dhcp-server имя сетевого интерфейса, на котором будет активирована конфигурируемая подсеть (в примере - enp5s0):
echo 'INTERFACESv4="enp5s0"' > /etc/default/isc-dhcp-server
DNS (unbound)
Для настройки необходимо создать новый конфигурационный файл /etc/unbound/unbound.conf.d/diskless.conf:
cat > /etc/unbound/unbound.conf.d/diskless.conf <<EOF
# ------------------------------------------------------------------------------
# Основной блок настроек DNS-сервера Unbound
# ------------------------------------------------------------------------------
server:
# IP-адрес, на котором Unbound будет слушать DNS-запросы.
#
# В данном случае DNS-сервер доступен только на интерфейсе/адресе:
# 172.16.0.1
#
# Это хорошо для изолированной загрузочной сети 172.16.0.0/24.
interface: 172.16.0.1
# Порт DNS-сервера.
#
# Стандартный DNS-порт:
# 53
port: 53
# --------------------------------------------------------------------------
# Доступ к DNS-серверу
# --------------------------------------------------------------------------
# Разрешить DNS-запросы с localhost.
#
# Нужно, чтобы сам сервер мог обращаться к локальному Unbound:
# dig @127.0.0.1 termidesk.local
access-control: 127.0.0.0/8 allow
# Разрешить DNS-запросы из загрузочной сети.
#
# Машина из подсети 172.16.0.0/24 смогут использовать этот Unbound
# как DNS-сервер.
access-control: 172.16.0.0/24 allow
# --------------------------------------------------------------------------
# Защита приватных адресов
# --------------------------------------------------------------------------
# Запрещает получать приватные адреса 172.16.0.0/24 из внешнего DNS.
#
# Это защита от DNS rebinding и мусорных внешних ответов.
#
# Важно:
# private-address не запрещает локальные записи local-data.
#
# Поэтому записи ниже:
# termidesk.local -> 172.16.0.2
# main.local -> 172.16.0.1
#
# будут работать нормально.
private-address: 172.16.0.0/24
# --------------------------------------------------------------------------
# Локальная DNS-зона
# --------------------------------------------------------------------------
# Объявляет локальную DNS-зону local.
#
# Точка в конце обязательна:
# "local."
#
# Тип static означает:
# - Unbound сам отвечает за имена внутри зоны local.
# - Если имени нет в local-data, Unbound вернёт NXDOMAIN.
# - Запросы вида unknown.local не будут пересылаться наружу.
#
# Это правильно для внутренней зоны, где все нужные имена
# должны быть явно описаны.
local-zone: "local." static
# --------------------------------------------------------------------------
# Локальные DNS-записи
# --------------------------------------------------------------------------
# DNS-запись для сервера Termidesk.
#
# Полное имя:
# termidesk.local.
#
# IP-адрес:
# 172.16.0.2
#
# В DHCP это имя используется здесь:
# option termidesk-server "termidesk.local";
local-data: "termidesk.local. IN A 172.16.0.2"
# DNS-запись для основного сервера загрузочной сети.
#
# Полное имя:
# main.local.
#
# IP-адрес:
# 172.16.0.1
#
# Обычно на этом адресе находятся:
# - DHCP
# - DNS / Unbound
# - TFTP
# - iSCSI
# - syslog
local-data: "main.local. IN A 172.16.0.1"
# ------------------------------------------------------------------------------
# Пересылка внешних DNS-запросов
# ------------------------------------------------------------------------------
forward-zone:
# Зона "." означает корневую DNS-зону.
#
# То есть все запросы, которые Unbound не обслуживает локально,
# будут пересылаться на forward-addr ниже.
#
# Например:
# google.com
# debian.org
# ntp.org
name: "."
# Основной upstream DNS-сервер.
#
# В данном случае это скорее роутер или DNS-сервер
# во внешней сети 192.168.0.0/24 (это только пример).
forward-addr: 192.168.0.1
# Резервный внешний DNS-сервер.
#
# Будет использоваться, если 192.168.0.1 недоступен
# или не отвечает.
forward-addr: 8.8.8.8
EOF
Удаленный журнал (rsyslog)
Для настройки необходимо создать новый конфигурационный файл /etc/rsyslog.d/diskless.conf:
# Прием syslog по UDP/514
module(load="imudp")
input(type="imudp" port="514" ruleset="remote")
# Прием syslog по TCP/514
module(load="imtcp")
input(type="imtcp" port="514" ruleset="remote")
# Шаблон: складывать удаленные журналы по IP-адресу отправителя
template(name="RemoteByIP" type="string"
string="/var/log/remote/%FROMHOST-IP%/syslog.log")
# Правила для удаленных журналов
ruleset(name="remote") {
action(
type="omfile"
dynaFile="RemoteByIP"
createDirs="on"
dirCreateMode="0755"
fileCreateMode="0644"
)
stop
}
EOF
Сервер tftp
iPXE-загрузчик может отправлять RRQ-запрос на TFTP-сервер с параметром размера блока (blksize) в 1468 байт. Сам TFTP-сервер может отбросить запрос с ошибкой: tftp: client does not accept options.
В процессе договора между TFTP-сервером и iPXE-загрузчиком сервер отправляет OACK, а загрузчик по какой-то причине может не принимать согласование. В таком случае для решения проблемы стоит запустить TFTP-сервер с параметром --refuse blksize, который позволит передавать данные с размером блока в 512 байт:
sed -i 's/^TFTP_OPTIONS="--secure"$/TFTP_OPTIONS="--refuse blksize --secure"/' /etc/default/tftpd-hpa
В результате:
-
с
blksize: iPXE-загрузчик запросит ускоренный режим, TFTP-сервер согласится, но машина РМ не загрузится (нештатная работа); -
без
blksize: iPXE-загрузчик запросит ускоренный режим, TFTP-сервер проигнориует ускорение - произойдет обычная TFTP-передача, машина РМ загрузится (штатная работа).
Настройка сетевого интерфейса
Для настройки сетевого интерфейса выполнить:
|
В примере используются:
|
nmcli connection delete "static-enp5s0" >/dev/null 2>&1 || true
nmcli --offline connection add type ethernet \
con-name "static-enp5s0" \
ifname "enp5s0" \
ipv4.addresses "172.16.0.1/24" \
ipv4.method manual \
> "/etc/NetworkManager/system-connections/static-enp5s0.nmconnection"
chmod 600 "/etc/NetworkManager/system-connections/static-enp5s0.nmconnection"
nmcli connection reload
nmcli connection up "static-enp5s0"
Перезапуск служб
После завершения настройки необходимо выполнить перезапуск соответствующих служб:
sudo systemctl restart isc-dhcp-server
sudo systemctl restart unbound
sudo systemctl restart rsyslog
sudo systemctl restart tftpd-hpa
Проверка работы настроенных служб
Для проверки работы воспользоваться командой:
netstat -tulnp
И убедиться, что в выводе команды есть информация о PID настроенных служб.
Сборка iPXE-загрузчика
Для сборки нужно:
-
клонировать скрипт-инструмент для сборки образа из репозитория gitflic:
git clone https://gitflic.ru/project/azhirov-astralinux-ru/ipxe-tool.git /root/ipxe-tool
-
собрать образ с инструментами разработчика:
/root/ipxe-tool/ipxe.sh image build
-
собрать iPXE-загрузчик:
mkdir -pv /srv/tftp
/root/ipxe-tool/ipxe.sh build --out-dir /srv/tftp -- --efi --legacy --default --force
Для работы с iPXE-загрузчиком нужно сохранить базовую конфигурацию в /srv/tftp:
cat > /srv/tftp/boot.ipxe <<'EOF'
#!ipxe
# ------------------------------------------------------------------------------
# Определяем интерфейс, через который был получен PXE/iPXE-скрипт.
#
# Признак загрузочного интерфейса — наличие переменной filename.
# Обычно она появляется на том интерфейсе, через который DHCP/TFTP отдал
# начальный загрузочный файл.
# ------------------------------------------------------------------------------
echo Detect PXE boot interface...
# Проверяем net0.
# Если у интерфейса есть filename, считаем его загрузочным.
isset ${net0/filename} && set bootif net0 && goto bootif_found ||
# Проверяем net1.
# Если у интерфейса есть filename, считаем его загрузочным.
isset ${net1/filename} && set bootif net1 && goto bootif_found ||
# Если ни на одном интерфейсе filename не найден, значит iPXE не смог
# надёжно определить, через какой интерфейс была получена загрузка.
echo ERROR: PXE boot interface not found
# Показываем состояние всех сетевых интерфейсов для диагностики.
ifstat
# Оставляем пользователя в shell для ручной отладки.
shell
# ------------------------------------------------------------------------------
# Загрузочный интерфейс найден.
# ------------------------------------------------------------------------------
:bootif_found
echo Boot interface: ${bootif}
# Переходим в секцию настройки конкретного интерфейса:
# net0 -> :net0_setup
# net1 -> :net1_setup
goto ${bootif}_setup
# ------------------------------------------------------------------------------
# Настройка загрузки через net0.
# ------------------------------------------------------------------------------
:net0_setup
echo Use only net0
# Закрываем второй интерфейс, чтобы iPXE не пытался ходить через него.
# Это важно при нескольких сетевых картах, когда маршруты или DNS могут переехать.
ifclose net1
# Открываем net0.
ifopen net0 || goto failed
# Повторно получаем DHCP-настройки именно на net0.
# Так мы гарантируем, что IP, gateway, DNS, next-server и custom options
# относятся к нужному интерфейсу.
dhcp net0 || goto failed
# MAC-адрес загрузочного интерфейса в обычном виде.
set boot_mac ${net0/mac}
# MAC-адрес в hex/text-виде для передачи в URL.
set boot_mac_txt ${net0/mac:hex}
# IP-адрес, полученный по DHCP.
set boot_ip ${net0/ip}
# Gateway, полученный по DHCP.
set boot_gw ${net0/gateway}
# DHCP next-server, обычно адрес TFTP/boot-сервера.
set boot_next_server ${net0/next-server}
# DHCP option 226 — syslog-сервер.
# Не пишем сразу в переменную syslog, сначала сохраняем отдельно.
set syslog_server ${net0/226:string}
set termidesk_server ${net0/224:string}
set termidesk_api_version ${net0/225:string}
goto boot
# ------------------------------------------------------------------------------
# Настройка загрузки через net1.
# ------------------------------------------------------------------------------
:net1_setup
echo Use only net1
# Закрываем первый интерфейс, чтобы исключить случайную работу через net0.
ifclose net0
# Открываем net1.
ifopen net1 || goto failed
# Повторно получаем DHCP-настройки именно на net1.
dhcp net1 || goto failed
# MAC-адрес загрузочного интерфейса в обычном виде.
set boot_mac ${net1/mac}
# MAC-адрес в hex/text-виде для передачи в URL.
set boot_mac_txt ${net1/mac:hex}
# IP-адрес, полученный по DHCP.
set boot_ip ${net1/ip}
# Gateway, полученный по DHCP.
set boot_gw ${net1/gateway}
# DHCP next-server, обычно адрес TFTP/boot-сервера.
set boot_next_server ${net1/next-server}
# DHCP option 226 — syslog-сервер.
# Не пишем сразу в переменную syslog, сначала сохраняем отдельно.
set syslog_server ${net1/226:string}
set termidesk_server ${net1/224:string}
set termidesk_api_version ${net1/225:string}
goto boot
# ------------------------------------------------------------------------------
# Основная загрузка.
# ------------------------------------------------------------------------------
:boot
echo MAC: ${boot_mac}
echo IP: ${boot_ip}
echo GW: ${boot_gw}
echo Next server: ${boot_next_server}
echo Syslog DHCP option 226: ${syslog_server}
# Если DHCP option 226 не пришла, используем резервный syslog-сервер.
isset ${syslog_server} || set syslog_server 172.16.0.1
# Включаем syslog.
# После этой строки echo-сообщения должны уходить в syslog,
# если iPXE собран с поддержкой CONSOLE_SYSLOG.
set syslog ${syslog_server} || goto syslog_failed
echo Syslog enabled: ${syslog_server}
goto build_url
# ------------------------------------------------------------------------------
# Ошибка настройки syslog не должна обязательно ломать загрузку.
# Поэтому просто пишем предупреждение и продолжаем.
# ------------------------------------------------------------------------------
:syslog_failed
echo WARNING: failed to enable syslog: ${syslog_server}
goto build_url
# ------------------------------------------------------------------------------
# Формирование URL загрузочного скрипта.
# ------------------------------------------------------------------------------
:build_url
# Собираем URL запроса к Termidesk.
# MAC кодируем через uristring, чтобы символы вроде ':' корректно попали в URL.
set url http://${termidesk_server}/api/agent/v${termidesk_api_version}/boot_script?mac=${boot_mac_txt:uristring}
echo Chain: ${url}
# Загружаем следующий iPXE-скрипт с сервера.
chain ${url} || goto failed
# Если chain завершился успешно и вернулся обратно, завершаем работу.
exit
# ------------------------------------------------------------------------------
# Общая обработка ошибки загрузки.
# ------------------------------------------------------------------------------
:failed
echo ERROR: boot failed
# Показываем состояние интерфейсов.
ifstat
# Показываем таблицу маршрутизации.
route
# Оставляем shell для ручной диагностики.
shell
EOF
Настройка iSCSI (tgt)
Для настройки выполнить:
-
создать диск машины РМ для iSCSI:
mkdir -pv /var/iscsi
fallocate -v -l "25G" /var/iscsi/test-disk.img
-
создать конфигурацию:
cat > /etc/tgt/conf.d/test-disk.conf <<'EOF'
<target iqn.2026-06.local.ipxe:test-disk>
<backing-store "/var/iscsi/test-disk.img">
lun 1
allow-in-use yes
</backing-store>
</target>
EOF
-
перечитать конфигурацию tgt:
tgt-admin --update ALL
tgtadm --mode target --op show
Для последующего обслуживания диска, при необходимости изменить конфигурацию ОС на нем, используется скрипт mdisk, доступный в Интернет-репозитории Termidesk: https://repos.termidesk.ru/Addons/Scripts/.
Скрипт монтирует IMG-диск для возможности его изменения.
Для использования скрипта нужно:
-
скопировать его в файловую систему iSCSI-сервера. Для того чтобы при вызове скрипта не запрашивалось повышение прав пользователя, его можно разместить в каталоге
/usr/sbin; -
перейти в каталог размещения скрипта командой
cd; -
задать скрипту флаг выполнения:
sudo chmod +x mdisk
-
вызывать скрипт и передать ему путь к iSCSI-диску:
sudo ./mdisk -i <путь_к_диску> -t /mnt
Например:
sudo ./mdisk -i /var/iscsi/test-disk.img -t /mnt
Где:
-t /mnt - точка монтирования, в примере используется каталог /mnt
Для вызова справки по работе со скриптом выполнить:
sudo ./mdisk --help
Для ввода РМ с бездисковой загрузкой в домен установить в гостевую ОС соответствующие пакеты:
-
для домена MS AD - пакет
astra-ad-sssd-client:
sudo apt install -y astra-ad-sssd-client
-
для домена FreeIPA - пакет
astra-freeipa-client; -
для домена ALD Pro - пакеты
astra-freeipa-clientиaldpro-client.
Инструкции по настройке гостевой ОС Astra Linux Special Edition для всех типов доменов приведены в разделе Обязательная настройка гостевой ОС Astra Linux.
Подготовка образа РМ ОС Astra Linux Special Edition на удаленном iSCSI-устройстве
Предварительные требования
К узлу подготовки образа должен быть подключен Live-образ ОС Astra Linux Special Edition 1.8.4 и узел должен быть загружен с него перед выполнением последующих действий.
Общие сведения о подготовке образа
Процесс подготовки образа выполняется пакетом cdi по специализированному сценарию, ориентированному на сетевые хранилища:
-
подключение к целевому устройству: установщик инициализирует сетевое подключение к iSCSI-серверу. После успешного обнаружения целевого узла (Target) и логического тома (LUN) этот диск становится доступен для выбора в качестве основного носителя;
-
стандартная установка: все последующие этапы (разметка диска, создание разделов, форматирование, копирование системных файлов) выполняются штатными средствами установщика;
-
предварительная конфигурация: в процессе установки задаются базовые параметры системы: имя пользователя ОС и его пароль, а также уникальное сетевое имя узла (hostname) для его идентификации в инфраструктуре.
Критически важным этапом является настройка способности системы загружаться с сетевого ресурса. Поскольку корневой раздел находится удаленно, необходимо, чтобы iSCSI-подключение устанавливалось на самых ранних стадиях загрузки, до монтирования корневой файловой системы. Эту задачу решает специализированный пакет ddl (Dynamic Diskless Loader).
Интеграция пакета в образ происходит на этапе установки:
-
установщику передается пакет
ddl, уже содержащийся в пакетеcdi; -
пакет
ddlустанавливается в целевую систему, обеспечивая в дальнейшем корректную инициализацию iSCSI-соединения при каждом старте.
Весь процесс установки инициируется и контролируется штатным консольным установщиком astra-installer-console. Его работа строится на основе заранее подготовленного preseed-файла, содержащего исчерпывающий набор предустановленных параметров, ответов на запросы и инструкций, что позволяет исключить ручной ввод и выполнить развертывание в автоматическом режиме.
Результатом установки является готовая ОС Astra Linux Special Edition на iSCSI-устройстве, сконфигурированная по заданным параметрам и способная к самостоятельной загрузке с сетевого хранилища. После завершения установки рекомендуется проверить настройки автоматического подключения iSCSI в готовой ОС и убедиться в корректности конфигурации загрузчика.
Установка необходимого набора пакетов
Для установки пакета cdi нужно:
-
подключить Интернет-репозиторий Termidesk, либо скачать пакет напрямую из него: https://repos.termidesk.ru/astra/dists/1.8_x86-64/pool/non-free/vats/;
-
выполнить:
sudo apt install -y <путь_к_пакету>
-
в запросе установщика нажать экранную кнопку [Продолжить].
В процессе установки потребуется:
|
В случае неожиданного завершения работы псевдографического интерфейса установки рекомендуется уменьшить окно консольного терминала. |
-
настроить подключение к удаленному iSCSI-устройству:
-
«Адрес»: IP-адрес или доменное имя iSCSI-сервера;
-
«Порт»: порт подключения. По умолчанию 3260;
-
-
если параметры подключения были введены правильно и доступ к iSCSI-устройству есть, то на следующем шаге появится список целей (Target), доступных для дальнейшего подключения. Потребуется выбрать цель: если настройка сервера выполнялась по стандартным примерам конфигураций, то цель будет
iqn.2026-06.local.ipxe:test-disk; -
выбрать блочное устройство для установки (например,
sda). Количество блочных устройств зависит от настройки iSCSI-сервера (параметрLUN); -
настроить параметры ОС образа:
-
«Пользователь»: имя создаваемого пользователя ОС;
-
«Пароль»: пароль пользователя ОС;
-
«Имя компьютера»: имя узла (hostname);
-
-
указать используемый пакет
ddl:-
«Использовать встроенный в CDI deb-пакет DDL»: будет использоваться пакет по-умолчанию;
-
-
указать используемый пакет
termidesk-agent-
«Использовать встроенный в CDI deb-пакет Termidesk Agent»: будет использоваться пакет по-умолчанию;
-
-
настроить подключение к серверу Termidesk VDI:
-
«Адрес[:порт]»: IP-адрес или FQDN компонента «Универсальный диспетчер» («Портал администратора»);
-
«Порт Агента»: порт «Агента виртуального рабочего места», который будет использоваться для взаимодействия;
-
«Мастер ключ»: значение мастер-ключа для взаимодействия с компонентом «Универсальный диспетчер». Значение мастер-ключа можно получить в «Портале администратора», перейдя в «Системные параметры - Системные настройки - Безопасность» и скопировав значение параметра «Мастер-ключ»;
-
-
настроить конфигурацию опций DHCP (настройка сервера выполнялась ранее):
-
«DNS-домен»: имя доменной зоны;
-
«Опция Termidesk сервера»: опция, настроенная на DHCP-сервере, отвечающая за адрес сервера Termidesk VDI;
-
«Опция Termidesk API версии»: опция, настроенная на DHCP-сервере, отвечающая за версию сервера Termidesk VDI («Универсального диспетчера»);
-
«Опция Syslog сервера»: опция, настроенная на DHCP-сервере, отвечающая за адрес Syslog-сервера;
-
-
нажать экранную кнопку [Начать установку] и дождаться завершения установки и настройки образа ОС;
-
по завершению установки нажать экранную кнопку [Завершить], затем [Выйти].
На этом этапе подготовка образа завершена. Далее необходимо перейти к настройке непосредственно сервера Termidesk.
Параметры работы утилиты cdi
Для гибкой настройки версий пакетов, управляемых через cdi, предусмотрена возможность вызова утилиты с указанием параметров, перечисленных в таблице (см. таблицу Доступные параметры утилиты cdi).
Просмотр справки по утилите cdi выполняется командой:
sudo cdi --help
| Параметр | Описание |
|---|---|
|
Вывод версии утилиты |
|
Включение отладочного уровня журналирования. Подробность журналирования настраивается количеством указанных параметров (поддерживается 7 уровней): например, |
|
Путь к файлу журнала. По умолчанию: |
|
Путь к |
|
Путь к |
Настройка узла сервера Termidesk
Настройка сводится к:
-
добавлению поставщика ресурсов в зависимости от сценария использования. Поддерживаются: «Автономные машины», «Автономные машины»;
-
добавлению шаблона «Сетевая загрузка (MAC)» в выбранном поставщике ресурсов (см. подразделы Шаблон РМ для автономной машины с сетевой загрузкой, Шаблон РМ машины с сетевой загрузкой для платформы VMware vSphere);
-
созданию фонда РМ «Сетевая загрузка (MAC)» (см. подраздел Добавление фонда сетевой загрузки);
-
выполнить настройку узла «Универсального диспетчера»:
-
добавить параметр
IPXE_SCRIPT_PATHв файлopt/termidesk/share/termidesk-vdi/src/config.py:IPXE_SCRIPT_PATH=/opt/termidesk/src/private/script.ipxe -
создать файл
/opt/termidesk/src/private/script.ipxeсо следующим содержимым:-
для EFI-загрузки:
#!ipxe sanboot --filename \EFI\astra\grubx64.efi {iscsi_target_name} || reboot -
для Legacy-загрузки:
#!ipxe sanboot {iscsi_target_name} || reboot
-
-