Installer/todo

Планы на будущее

Новый функционал

• инсталлятор, запускающийся из-под live-cd.
• инсталлятор с web-интерфейсом: перенос workflow-acc в пакет alterator-standalone, создание workflow-wizard.
• режим работы: сначала создать профиль автоустановки, а потом запустить установку.
• установка при помощи заранее подготовленного профиля, редактор профиля

Известные проблемы

• возможность отключения автодетекта монитора (параметр xmonitor)
• все новые профили должны provides/obsoletes предыдущие 11907 и 11906
• упрощённый переход между шагами 14456

Мысли про autoinstall

• То что сейчас существует это не какая-то отдельно сделанная технология,

это скорее побочный эффект того как работает сам alterator (достаточно посмотреть на размер пакета alterator-autoinstall)

• Я так и не понял хотим ли мы какой-то свой особенный формат или хотим формат в стиле RH/SuSE.
• Не было времени изучить все последние веяния на этом поприще (а то сделаем себе kickstart, а RH убежит вперёд) и оценить си

туацию.

• Не было заказа с пометкой "срочно, это единственный выход".
• Отдельные модули, типа vm генерят достаточно мутный набор команд и используют свой особенный дополнительный профиль.
• Надо по хорошему autoinstall сопровождать модулем по созданию autoinstall по аналогии с RH.
• Чтобы профиль был после работы инсталлятора, то по хорошему надо изменять стиль его работы, а для этого надо понять какие модули мы оставляем интерактивными ибо иначе нельзя, а какие будут просто генерить команды для kickstart.Пока мысли такие:
  • всё что идёт на третьей стадии (внутри уже установленной системы) можно переделать на kickstart
  • всё что идёт на второй стадии должно остаться интерактивным, но перенос настроек будет делаться при помощи сгенерённого kickstart.

При таком подходе есть шанс взять этот интеграл "по частям".

Общий порядок применения

• Для установки по сети необходимое и достаточное условие --- DHCP, TFTP и FTP серверы.
• Процесс не должен требовать участия человека. Включили пустой сервер, если сеть его приняла, то на выходе получился налитый. Решение о том, загружать ли по сети какой-то конкретный сервер, если он этого просит, и какой именно autoinstall-файл использовать, принимается без участия сервера. Это позволяет навсегда зафиксировать порядок загрузки на "сеть, HDD".
• Правильно подготовленного файла autoinstall должно быть достаточно, чтобы процесс проходил автоматически. Формат его роли не играет, функциональное богатство --- тоже. Главные функции, которые ожидаются от установщика --- подготовить диски, собрать RAID/LVM, создать файловые системы, установить минимальную систему. Доставить пакеты и отредактировать конфиги можно из post-install скрипта, который можно включить в autoinstall "as is". Например, установщик Fedora очень любит устанавливать изрядную часть всех пакетов, которые вообще в принципе поддаются установке. Поэтому в kickstart-файлах для серверов postinstall занимается удалением тучи пакетов.
• Об оборудовании чрезмерно заботиться не нужно, для этого есть человек. Если он забыл, например, попросить модуль для второго дискового контроллера, или из шести дисков в системе использовал только один, значит, так и нужно. Обязанности должны чётко делиться: человек готовит autoinstall-файлы, компьютер их ест. До фанатизма тоже доводить не нужно, конечно. Какой-то базовый набор модулей должен загружаться сам.