It’s quite some time since we created the current GTK based UI for Anaconda: the OS installer for Fedora, RHEL, CentOS. For a long time we (the Anaconda team) were looking for possibilities to modernize and improve the user experience. In this post, we would like to explain what we are working on, and—most of all—inform you about what you can expect in the future.
First, we need to express that we decided to share this information pretty early. We are currently at the stage where we have made the decisions. We have a ‘working prototype’ of the solution already available but don’t expect screenshots and demos yet!
What you can expect?
We will rewrite the new UI as a web browser-based UI using existing Cockpit technology. We are taking this approach because Cockpit is a mature solution with great support for the backend (Anaconda DBus). The Cockpit team is also providing us with great support and they have significant knowledge which we could use. We thank them for helping us a lot with the prototype and creating a foundation for the future development.
We also decided for this step to be consistent with the rest of the system. More and more projects have support in Cockpit. By this step we should make the system more consistent between different applications. The great UX improvement should be easier remote installations compared to the current VNC solution. You can expect a lot of other improvements but let’s wait and see :).
Furthermore, we are building the new UI on top of the Anaconda modularization effort which we are implementing quite some time now. It’s great to see the fruits of our work which helps us now with the creation of the new UI. That also means that users of Fedora shouldn’t be much impacted by the changes during development of the new UI. A big part of Anaconda is now Anaconda modules with DBus APIs and we are reusing that API. We haven’t yet decided the approach for upstream development. We will tell you more about this in the future.
At the current state, we cannot communicate yet the expected day of the new UI or the minimum viable product availability. However, we will make sure to keep you informed about our progress from time to time, ensuring you know what to expect
We are thrilled about this new change and hopefully you are too! We look forward to give you something to play with!
I’ll admit that I bounced of from Anaconda, so I may not fully understand the current state, but what I would like to do in future is to be able to plug in extra steps during installation without rebuilding the whole installer. Is switching to Cockpit also involves thinking about some extra API that will provide such capability?
Does that mean that now Fedora installation will bootstrap Chrome OS so that one could have a browser to access Anaconda UI?
Jokes aside, it would be interesting to see something lightweight like Cage and Firefox in kiosk mode.
Even current Anaconda can be extended with addons, which can add extra screens as well as handle custom kickstart data. The expectation is that this capability will be in place with the Web UI as well.
As for where to run the Web via locally - this turned out to be rather simple and straightforward!
Basically, the Cockpit project had to solve the same issue and created the cockpit-desktop tool:
https://cockpit-project.org/guide/latest/cockpit-desktop.1
This is what will mostly likely by used to run the new Web UI locally and it pretty much ticks all the boxes. Furthermore, its just a simple Python wrapper over Webkit and as we both already have Python and Webkit (used to show help pages in the current GUI) on the media, it does not really make the installation image any larger, even with the existing GTK3 GUI still in place!
I think it makes sense to get closer to a single GUI.
However, I also think that we should be making Linux systems more declarative and reprovisionable by default - that’s the emphasis with CoreOS for example, and interactive GUI changes cut against that.
In particular, I never understood why Anaconda didn’t at least have a button somewhere that let you type in a URL for e.g. a partial kickstart file (which are generally declarative except for the giant gaping exception of
%post. That would make it easier to do things like use the GUI for disk setup, but otherwise use kickstart for other things).Does this mean there will also be (in the long run) a new installer for RHEL?
It’s been a long time since I actually used this for work, but, when I did… while there’s no GUI for it, it actually does do exactly this, and if you provide one on the boot command line (at $previousjob, we had it in our PXE configuration) it will skip everything it can get from the Kickstart file.
Hash of the kickstart file, and then Fedora can fetch it from decentralized content addressable network. Like IPFS.
Yes, I know that. But you have to do it before starting anaconda at all, in an unfriendly environment. If you typo the URL, you have to restart the whole thing. You can’t interactively edit it. etc.