For what feels like "years", we have been wanting to revamp our server installation process. This starts with something as simple as systematic and consistent naming of our various installation media. It continues with the synchronization of netinstall and DVD, with changes to some configurations, and ends with a review of the software selection.
And likewise for what feels like "years", we have been failing at this. There are many reasons for this, but in particular, the build process is extremely complicated and obviously insufficiently documented, if at all. And we don't have the capacity to deal with this time-consuming exercise.
At the same time, Anaconda is currently undergoing a fundamental overhaul, which opens doors and gates to follow-up damage and requires a lot of work on our part to prevent the worst. The first serious damage has already been done. The remote interactive installation is gone. Previously, you could prepare a USB stick to start a VNC server. You didn't need a terminal, just 2 USB sticks. Now you need a connected terminal and, particularly bad, you have to edit the kernel command line with a US keyboard mapping. Anyone familiar with the conditions in many server racks knows how time-consuming it can be to get a (temporary) terminal connected. And around 80% of users are non-Americans with a local keyboard mapping. The requirement to edit the sensitive kernel command line with a wrong keyboard layout in particular is simply unreasonable.
In addition, for years we have not actually used the flexible, package-based installation that Anaconda enables. The “minimal installation" option included in the installation menu has nothing to do with Server Edition, and the add-on installation options in the right-hand column are all outdated and useless. In fact, we have been installing a fixed and unchanged set of software for years.
Furthermore, the conceptual benefits of Anaconda's functionality are questionable for Server. Our goal is to use Ansible to adapt a server to specific local requirements and tasks. A selection during installation, which is the central advantage of Anaconda, is not part of our plan. On the contrary, this tends to disrupt and complicate an Ansible-based configuration.
This raises the serious question of whether we should switch to a more efficient and less time-consuming distribution mechanism based on one (or more) file system image file(s), which we generate once for all distribution options using Kiwi (or another method, such as Image Builder or mkosi) and then use as the basis for various distribution channels by merely copying the image(s) to partition(s).
For __virtual machines__, we could largely retain the current image.
For __interactive installation on hardware__, we could use a minimal, lightweight live image that then either starts a fully automated default installation of the image(s) or, depending on optional local settings, a remote display server or a minimal graphical system in which you can edit the hard disk configuration using gparted and then start copying the image(s) using dd.
For a __fully automated network installation__, we can retain the current system based on a kickstart file and supplement it with copying images if needed.
I would like to discuss this on our upcoming meeting on May 7.
--
Peter Boy
https://fedoraproject.org/wiki/User:Pboy
PBoy(a)fedoraproject.org
Timezone: CET (UTC+1) / CEST (UTC+2)
Fedora Server Edition Working Group member
Fedora Docs team contributor and board member
Java developer and enthusiast