Проблема с установкой ОС Astra Linux SE 1.6 по сети, причины и решение.
02.07.2019 10:30:00
Поделиться
Проблема с установкой ОС Astra Linux SE 1.6 по
сети, причины и решение.
Инсталляция по сети для Astra – критичный и очень важный функционал,
правильная его работа крайне важна при развертывании большого количества
рабочих станций на предприятиях, особенно это необходимо при миграции,
удаленной или распределенной установке.
Ну что, приступим?
Окружение у нас будет простое – виртуальные машины на VirtualBox,
обязательное условие – создаваемые виртуалки не должны быть изолированы
друг от друга. Выберите сеть NAT, например ( не забудьте отключить встроенный
DHCP)
Готовим инсталляционный сервер согласно документации:
Устанавливаем пакеты isc-dhcp-server, tftpd-hpa, apache2 и
(или) vsftpd (инструкций по настройке много, они стандартны)
Установливаем tftpd-hpa и DHCP, cоотвествующим образом настраиваем и
тестируем:
Настройка DHCP - Файл /etc/dhcp/dhcpd.conf:
…………
option ntp-servers 10.0.0.5;
option domain-name-servers 10.0.0.5;
option routers 10.0.0.1;
subnet 10.0.0.0 netmask 255.255.255.0 {
range 10.0.0.10 10.0.0.20;
max-lease-time 86400;
filename "pxelinux.0";
next-server server.test.lan;
}
key rndc-key {
algorithm hmac-md5;
secret "APw/EXdfbhXfYk5drax9AA==";
}
zone test.lan. {
primary 127.0.0.1;
……..
*(Ключевой пункт - filename "pxelinux.0")
Настройка tftpd-hpa - файл /etc/default/tftpd-hpa:
root@server:~# cat /etc/default/tftpd-hpa
# /etc/default/tftpd-hpa
TFTP_USERNAME="tftp"
TFTP_DIRECTORY="/srv/tftp"
Докучаев Дмитрий, УКЦ ФОРС. 2019
TFTP_ADDRESS="0.0.0.0:69"
#TFTP_OPTIONS="--secure"
TFTP_OPTIONS="--ipv4 --secure --create --umask 027 --permissive"
Размещение данных для загрузки
Поднимаем веб-сервер Apache2, в его корне создаём директорию с репозиторием
astra, куда замонтирован установочный диск.
mkdir -p /var/www/html/astra
mount /dev/sr0 /var/www/html/astra
В каталог /srv/tftp помещаем содержимое каталога netinst и библиотеку
ldlinux.c32 с установочного диска:
cp /srv/ftp/astra/netinst/* /srv/tftp/
cp /srv/ftp/astra/isolinux/ldlinux.c32 /srv/tftp/
Настраиваем файл /srv/tftp/pxelinux.cfg/default:
root@server:~# cat /srv/tftp/pxelinux.cfg/default
DEFAULT astra
LABEL astra
kernel linux
append initrd=initrd.gz vga=788 auto=true priority=critical
debian-installer/locale=en_US console-keymaps-at/keymap=ru
hostname=server domain=test.lan astra-license/license=true
interface=auto netcfg/dhcp_timeout=60
TIMEOUT 5
И перезапускаем сервис tftp-hpa.
Серверная часть закончена. Идем на клиента.
Создаем новую виртуальную машины и настраиваем ее на загрузку по сети:
Запускаем ее. Она успешно получает от DHCP адрес, загружает мини-ядро, initrd
и готова к инсталляции, - то есть, к коннекту к веб или ftp серверу с
дистрибутивом.
Но не тут-то было!
Все хорошо же, должно работать… Ан нет
В чем же дело?
Давайте проанализируем ситуацию. Для начала, параллельно с попытками
клиента подсоединиться к хранилищу дистрибутива,
посмотрим на логи Apache на веб- сервере:
tail -f /var/log/apache2/access.log /var/log/apache2/error.log.
Клиентская машинка наша прекрасно видит веб-сервер,
запросы к нему идут и он ей отвечает!
Это прекрасно видно на скриншоте внизу!
(Сразу обращаем внимание на файл Release.gpg в логах)
Переключаемся на консоль клиента через Alt+F2 и в /var/log/syslog и
видим следующие сообщения:
Уже теплее, явно проблема с ключами. «No public key» (точнее он есть, но не
соответствует загруженному ядру)
Смотрим версию ядра в загруженном из netinst initrd.
Теперь смотрим версию загруженного из /netinst ядра на клиенте:
Building date: Wed Jun 20 15:52:13 UTC 2018
Видим, что, как минимум, даты не совпадают!
Смотрим на уже сервере:
root@server:~# uname -a
Linux server 4.15.3-1-generic #astra17 SMP Wed Jan 16 12:36:30
UTC 2019 x86_64 GNU/Linux
Проблема – в несоответствии файлов, которые используются для проверки
подписей, Release.gpg /var/www/html/astra/dists/smolensk/Release.gpg,
то есть, проще говоря, папочка CDROM /astra/netinst/* - не от того
дистрибутива.
А так как Astra Linux SE у нас – защищенная система,
даже пакет из неподписанного репозитория не поставишь
(что, кстати, очень правильно), то причина наших неудач становится очевидной.
даже пакет из неподписанного репозитория не поставишь
(что, кстати, очень правильно), то причина наших неудач становится очевидной.
Немного утешу вас, коллеги, сообщив, что на версии
Astra Linux SE 1.5 такой проблемы нет. О путях решения
(неочевидных, ибо, кроме правильного дистрибутива, что очевидно,
тут других не может быть) я напишу позже.
Astra Linux SE 1.5 такой проблемы нет. О путях решения
(неочевидных, ибо, кроме правильного дистрибутива, что очевидно,
тут других не может быть) я напишу позже.
И это – тоже хорошая новость!
Продолжение следует.
Поделиться
