Комментарии 14
Простите пожалуйста, не могу себя сдерживать: у нас принято вещи устанваливать не столько в один проход, сколько через него.
Всё, отправляюсь в школьный ад.
Ассоциации дело такое)
Можно поинтересоваться, что это за устройства, зачем пять разделов и почему нельзя было просто клонировать диски?
К сожалению по поводу устройств сказать не могу, их много и они все разные. 5 разделов - требования разработчиков ПО. Клонировать нельзя - это не открытое ПО (лицензия и т.п.).
А можете уточнить, что там в лицензии запрещающее клонирование? Насколько помню в астре все файлы подписаны, а их хеши необходимо сверять с эталоном на компакт-диске, так что они наоборот топят за неизменяемость.
Можно же склонировать ОС и выполнить post-install: перегенерить ключи, расширить lvm диски, если целевой диск по объему больше чем в образе, сменить hostname, в домен ввести и прочее, что выполняется скриптами.
Что не так с разделам?
Схема по виду типовая - /home чтобы пользователи все не сожрали и сервисы не встали, /var - чтобы сервисы/логи/аплоад какого-нибудь /www/ все не сожрали и система не встала.
Да, по уму надо под каждый емкий сервис свой раздел делать, /var/log - классика, /srv/pgdb (или что там в корпоративных стандартах). Но ребята делают универсальный образ.
Там ещё занятно - пакеты подписаны ключом, которого нет в initrd. Поэтому у нас так:
# Не аутентифицировнная инсталляция: в образе netinst/initrd.gz отсутствует
# публичный ключ для проверки dists/smolensk/Release.gpg
d-i debian-installer/allow_unauthenticated string true
d-i debian-installer/allow_unauthenticated_ssl boolean trueМне в своё время очень помогли наработки вот этого парня: https://github.com/stillru/astralinux-packer-template
Это при установке по сети? У нас с ключами проблем не было и
d-i debian-installer/allow_unauthenticated_ssl boolean false
d-i debian-installer/allow_unauthenticated boolean false
У нас везде false. По документации не рекомендуют ставить в true. Возможно дело в том, что мы не использовали установку по сети в чистом виде.
У вас ошибка в установке пакетов из стандартного репозитория при установке системы?
d-i на самом деле ужасен, особенно в плане разметки.
хочешь зеркалировать /boot/efi? да пошёл ты на*** парень, хочешь почитать доку? а от неё только половина, вторую ищи в сорцах и на форумах.. убунтовцы его доработали но что толку если тебе нужен именно дебиан. в этом плане пресиды opensuse и rh-подобных сильно лучше.
но вообще спасибо за статейку, есть тут пара строк которые к сожалению мы в своё время не нашли, закину парням на почитать.
А что вы будете делать если набор софта или нужные конфиги изменятся? Переписывать еще кучу флешек? Я например сейчас как раз провожу развертывание Астры по сети, основное через пресид, далее в early_command берется по фтп скрипт, после установки эникеи запускают его, ставится puppet и назначают тачке целевую группу в зависимости от назначения ПК- дальше оно само как по маслу заливает нужные конфиги, вводит машину в AD домен через sssd, ставит нужный софт,вносит еще много изменений для работы с сервисами внутри включая SSO, удаленный доступ, автомаунт и еще кучу всего. Все ПК в организации (а их более тысячи) теперь контроллируются паппетом и можно делать чего душа пожелает - главной иметь жирный сервер который от этого не ляжет))
У нас этих флешек пока немного. Есть скрипт подготовки этих флешек. При создании скрипт берёт конфиги из гита (поэтому достаточно изменить в одном месте). Если изменился софт, то просто обновляется репозиторий на сервере и всё. Вы наверное путаете процесс подготовки поставок (когда подготавливается оборудование и отправляется заказчику) и поддержки инфраструктуры.
Автоматизация автоматизации или как мы обеспечили автоустановку не только ОС Astra Linux, но и софта в один «проход»