openSUSE:ALP/Workgroups/Installation/DInstaller

ALP 安装工作组正在研究如何改进当前的 (open)SUSE 安装程序。D-Installer 是实现 YaST 演变的临时代号。

简而言之

D-Installer 旨在利用 Cockpit 作为前端，在 YaST 库之上构建一个基于 Web 的安装程序。它需要对 YaST 进行重要的架构更改，包括开发 D-Bus 接口。

使用 YaST 作为后端具有很大的优势 - 它可以轻松实现向后兼容性，并且代码和知识已经存在。以后交换组件应该更容易。在这方面，D-Installer 的 YaST 组件将不会像当前的 YaST 那样运行为单个整体进程，而是作为一组独立运行的组件，并提供自己的 D-Bus API。

您可以在下面的页面中找到更多信息

愿景

在通用操作方面，D-Installer 与 YaST 差别不大。也就是说，它是一个在正在运行的 Linux 系统（我们通常称之为 int-sys）之上运行的应用程序，它执行

一些基本的网络配置（如果需要，这也可以由底层 Linux 系统完成，无论是什么系统）
为目标系统配置存储设置（分区、LVM、加密...）
通过 `zypper --root /mnt` 或只是复制镜像的内容，将目标系统部署到该存储设置上
对系统进行一些自定义配置，以用于首次启动（引导加载程序、kdump、网络等），可能通过 chroot 进入新系统
完成！

但要真正有用，这种安装程序应该满足几个方面

如前所述，该安装程序应该可以从实时系统或类似于 SLE 中 YaST 使用的 inst-sys 的系统（希望小得多）执行。它甚至可以是在 openSUSE:ALP/Workgroups/Installation/Iguana 之上运行的（一组）容器。
由于预计客户将使用他们自己定制的 ALP 版本，因此安装程序应该支持安装不同的操作系统（vanilla ALP、客户定制的镜像...）。
在设置引导加载程序、加密、存储技术（multipath、LVM、RAID、DASD、iSCSI...）、基本网络设置、kdump/fadump... 等难以在首次启动后配置的事情方面，预计它具有与 YaST 类似的功能。
安装过程本身应该排除任何可以在首次启动后/期间通过 SCM 进行合理配置的内容。
安装程序应该提供一个安全的 API 来驱动安装过程并获取反馈。
对于交互式安装，安装程序应该提供基于上述 API 构建的几个 UI。由于这些 UI 中的每一个都只是与上述 API 交互的一种可能方式，因此理论上甚至可以在并行使用多个 UI。
这些 UI 应该比当前版本的 YaST 更简单明了（步骤和选项更少）。
- 对于本地和远程安装，现代基于 Web 的 UI 可能会很好。
- 对于 SSH 和/或串行安装，一个基于文本的替代界面（不一定在功能上等同于图形/Web 界面）会很好。
YaST 和 AutoYaST 之间的分离没有意义。交互式或无人值守安装之间的区别应该只是配置问题。一个配置参数可以指定安装程序是否应该等待用户更改设置并确认，或者安装程序是否应该尽快开始安装。
作为上述结果，仍然可以在过程的任何时候使用 Web 或基于文本的界面连接到无人值守安装，以检查进度（或中断它）。
无人值守安装应该可以在没有任何专用基础设施的情况下工作。只需使用上述配置参数运行安装程序，而无需等待用户交互即可。
说到配置，应该可以通过上述 API、通过配置文件（当前安装程序控制文件和 AutoYaST 配置文件之间的区别没有意义）、通过引导参数、通过环境变量和通过 [systemd 凭据](https://systemd.io/CREDENTIALS/) 来调整它。
因此，甚至不需要 AutoYaST 配置文件或 SCM。只需通过 PXE 启动并通过引导参数提供基本配置就足够了。安装程序应该能够弄清楚那些未在这些引导参数中明确配置的所有方面。
整个过程应该可以与 SCM（软件配置管理）系统和 SUMA（SUSE Manager）无缝集成，具有简单且可互操作的机制，既可以驱动它们，又可以提供状态反馈。请参阅 https://trello.com/c/hkR4vv5y/

这种方法存在未解决的问题

愿景指出交互式和无人值守安装之间不应存在差异。但通常在无人值守安装中需要某种逻辑。我们已经在 AutoYaST 中看到了这一点，许多用户使用预脚本、ERB 模板或规则/类动态调整过程。在所有情况下，目标都是相同的 - 根据硬件/其他条件使配置动态化。例如，用户希望在无人值守安装中选择第二大磁盘（因为最大的磁盘由自动建议选择，而用户希望使用另一个磁盘作为包含数据的最大磁盘）。

上述愿景中如何涵盖这些情况尚不清楚。