Installer/todo
Материал из ALT Linux Wiki
[править] Планы на будущее
Содержание |
[править] Новый функционал
- инсталлятор, запускающийся из-под 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-файлы, компьютер их ест. До фанатизма тоже доводить не нужно, конечно. Какой-то базовый набор модулей должен загружаться сам.
