Six weeks ago we announced D-Installer 0.7 and a lot has happened since then. The most important news is that we just released a new prototype with version 0.8, integrating several exciting new features we will go through in this post. But this prototype is not only important because of those features, but also because it will be the last D-Installer release! Fear not, we are not abandoning the project… quite the opposite.
We want to consolidate D-Installer in the following months from the experimental project it currently is into a solid alternative for installing several Linux distributions. And the name was perceived by some people as an obstacle for that. So we will change it to an already decided alternative starting with the next prototype.
Adjusting the Scope
As said, we want D-Installer to become a real alternative to install some of the future and even present (open)SUSE distributions. So the first step was to better define the list of supported distribution, called “products” in D-Installer jargon. If you grab the default flavor of the testing ISO we provide, you will see the following selection.
Take into account the YaST Team is not in charge of those distributions. D-Installer simply grabs the packages and default patterns from the corresponding repositories and installs them into your system. If you detect any inconsistency in the patterns of a distribution or any missing package, please contact the corresponding maintainers so they can fix the issue.
Support for s390x
One of the main highlights of the latest D-Installer prototype is the ability to install the mentioned distributions in s390x mainframes. That includes installing in LPAR mode, on z/VM and as a KVM guest.
That’s a bigger achievement that it may look like. Sure having YaST under the hood eased the task of handling of the nuances of installing into such a special platform. But the real challenge here was making it possible to run D-Installer itself on all kind of s390 systems. We usually execute D-Installer using an slightly modified version of a live image in which we pack D-Installer and Firefox. The point is that regular (open)SUSE live images didn’t come with full support for s390x out of the box.
Fortunately, SUSE is full of smart people that know a lot about Linux and all kind of hardware architectures. So after knocking on the appropriate doors we got a nice image that can be used to install any of the distributions supported by the D-Installer on any kind of s390x system by just following these instructions.
Advanced Storage Devices: iSCSI and DASD
Apart from its multi-architecture nature, another key aspect of the (open)SUSE installation process is its broad support for all kind of storage devices. D-Installer aims to simplify the installation experience without sacrificing those historical possibilities, like installing into network disks through iSCSI and FCoE or into disks relying on s390x technologies like DASD, XPRAM or zFCP.
The latest version of D-Installer supports configuring an iSCSI initiator and connecting to iSCSI targets during the installation process, including the configuration of both discovery and login authentication. Of course, the iSCSI configuration is transferred to the target system. If iBFT is used to configure iSCSI via firmware, D-Installer recognizes and displays the corresponding configuration and makes it possible to install the system into the remote iSCSI disk.
The iSCSI protocol is widely used in data-centers with all kind of hardware architectures. But in the mainframe world, DASD is probably the most common technology to provide storage space. DASDs need some previous configuration before they can accommodate a Linux system and now D-Installer offers the possibility to activate and format DASDs, together with other operations that have been traditionally available in YaST, like deactivation or configuration of the DIAG mode.
Interface Polishing and Reorganization
In addition to all the advanced features mentioned above, D-Installer 0.8 brings good news also for those geckos not running a full-featured data-center. First of all, we polished a bit the summary page to offer a more clear overview of the installation settings, moving configuration of authentication and network to new separate pages. See the screenshots at the corresponding pull request.
Moreover, we reorganized the sidebar that contains the advanced menu (which we fondly call “the hamburger menu). The actions are now grouped by topics and the menu offers contextual actions related to the current page, like configuration of iSCSI or DASD when the user is visiting the storage section.
In the screenshot above, you may have noticed the entry “Open terminal” in the “Diagnosis tools” sub-menu. No surprises there, it does exactly what you would expect. That is, offering a terminal embedded in the web interface that runs a shell on the very same Linux system that is executing D-Installer. Because we know our users can not resist to tweak and inspect all kind of things in the systems they run!
Kudos to the Cockpit project, relying on its infrastructure made this feature quite straightforward to implement.
Re-implemented Command-line Interface
You surely know D-Installer is way more than just a web front-end for YaST. Its architecture is designed to provide different kinds of interfaces and ways to operate. To make that more more visible than ever, D-Installer 0.8 comes with a new command-line interface rewritten from scratch (using the Rust programming language, if you are interested in those geeky details).
With the command-line interface you can drive the installation with sequences of command like:
dinstaller config set software.product=Tumbleweed dinstaller config set user.fullName="Jane Doe" user.userName="jane.doe" user.password="12345" dinstaller install
What is even better, that command-line is a crucial building block for another very relevant feature…
Preliminary Support for Unattended Installation
Many (open)SUSE users rely on AutoYaST to install their systems. D-Installer aims to also be useful in the kind of unattended and mass-deployment scenarios in which AutoYaST shines. But D-Installer will follow a slightly different path. First of all, D-Installer offers two alternative approaches.
On the one hand, the user can provide a file, known as a “profile”, with the settings to use during installation. This might sound familiar to AutoYaST users. The format and philosophy of D-Installer profiles is different from the AutoYaST ones, although there are plans to partially support AutoYaST profiles at D-Installer.
On the other hand, D-Installer can accept just a plain shell script, enabling custom installation workflows that rely on the D-Installer infrastructure and, potentially, also on other tools available in the installation media.
A more detailed explanation of both modes can be found at this document that covers several topics like the different ways to trigger an unattended installation, the format of the profile files, the mechanisms to make those profiles dynamic, etc.
Stay in Touch
The D-Installer project is heading into interesting times, starting with the rename already pointed at the beginning of this document. We also want to take some time to reflect on internal aspects like memory usage and usability topics like exposing more possibilities to configure the network or the storage layout.
All opinions and feedback are welcome. So do not hesitate to give D-Installer a try and tell us
about your experience and thoughts. You can contact us through the GitHub
project’s page or, as usual, in our
#yast channel at
Libera.chat or the YaST Development mailing