Wiki » Feature:InstallerAndDrakXReview

Overview

During the Mageia 4 cycle it became obvious that we have a bit of a maintenance problem with some of our drakx tools. This page is meant to allow a review of the code and develop some plans for the future.

Note: Until other people edit this page, the 'Recommendations' are quite biased towards 'what Colin thinks'. Please help make it more diverse!

Note: We've had very good reviews about our MCC and traditional installer documentation. Creating it was a hell of a job and so was (and still is) translating it. If we want to be sure that our documentation stays good, there shouldn't be many changes in how things work and look in one Mageia release - getting new screenshots for the new looks will already be quite a task --marja 08:05, 21 April 2014 (UTC)

Resources

• Developers
• Who else?
• Docteam members who volunteer to help update or rework our official end-user documentation when there is agreement with them about what at the most changes for one release, please see also the thread on the docteam ml here: about the Installer and DrakX (tools) review

• Volunteers to document better (for developers) how the current or future tools work and work together and, in the code, add clarifying comments where needed
  • Global overview (maybe expansion of this page, or a set of pages?)
  • See to it that there are good comments where needed in the code files

History

drakx is the collective name for various bits of code that is currently maintained by Mageia. This includes the core components used to create both our installer and the Mageia Control Center suite of tools to allow you to administer your computer.

The code is all written in perl and some parts are rather complex because of how it is used: e.g. a backend which does the logic and then often two or three frontends - one stand alone app for Mageia Control Center and one for the installer (plus maybe one run from script e.g. mandriva_everytime), plus maybe non-graphical versions - e.g. ncurses both for standalone and installer.

These tools served us very well in the past but time has moved on and there are now some tools which can maybe do some of the jobs better. Some of these will be explored below.

Installer

Early Boot

We have three different bootable images: Installer, Rescue and Live. Since Mageia 4, each of these is based on a dracut initrd, however they all work differently.

• Installer: Uses the mgainstaller dracut module but never actually switches root. It always stays in the initrd and just overmounts /usr (and some select other files) and then runs the installer rather than switching to an installed system init.
• Rescue: Also uses mgainstaller dracut module and also never really switches root. It does however run a real init (systemd) with a cut down selection of units.
• Live: Uses the mgalive dracut module + overlayfs to make a normally readonly image writable. Does do a switch root to a real init.

• Recommendation: Consolidate the different methods into one which works for all cases. Likely the mgalive approach, but ideally merged with upstream dracut live cd support so as to avoid custom downstream live modules.

Installer UI

The installer UI is quite complex and provides the user with a lot of options:

• Language/Locale Selection.
• License Acceptance
• Partitioning: This uses diskdrake which in turn uses a lot of probing to get info on disks. Recommendation: Refactor diskdrake to use udev exclusively for device/partition information. (Thomas) Or use GParted. Is there anything it cannot do that diskdrake can?
• Package Selection: Let's you pick very broad "Desktop", or a more granular Category-based approach or individual packages.
• Install
• Add root + user accounts.
• Service Management + Configuration
• Install Updates
• Reboot

Now, the installer allows a lot to be done and because of this it's rather complex.

• Recommendation: We should simplify, reduce the options available and perhaps concentrate on "first boot" configuration rather than configuring during the installer itself.

Standalone

The standalone tools cover a number of different areas.

drakuser

This is the user management system. It calls out to useradd, userdel etc. to deal with users.

• Recommendation: Rebase as a DBus frontend to "accountsservice" which is the backend code which implements user management in GNOME.
• Problems: This would make usermanagement in the installer more problematic (see below for solution) as it would need to access a DBus service "inside" the install.
• Suggestion: It is nice and efficient for basic tasks: we may keep it as a standalone, in parallel to any "rebase".

drakxservices

This is a service management system. It calls out chkconfig and systemctl to get an idea of service state and available services. It does not update itself dynamically (e.g. if a service fails while it's open).

• Recommendation: Factor out chkconfig (by migrating the remaining sysvinit scripts) and rely exclusively on systemd via DBus for service management. This would allow us to dynamically react to service state changes and simplify the code.
• Problems: Again this complicates its use within the installer (see below for solution) as it would need to access a DBus service "inside" the install.

drakkeyboard

Allows you to configure your keyboard layout.

• Recommendation: Refactor as a DBus frontend to systemd-localed (it controls system locale and both console and X11 keymaps and will control Wayland related locale stuff too).
• Problems: As above.

draklocale

Allows setting the system locale.

• Recommendation: Refactor as a DBus frontend to systemd-localed (it controls system locale and both console and X11 keymaps and will control Wayland related locale stuff too).
• Problems: As above.

drakclock

Allows configuration of time and NTP config.

• Recommendation: Refactor as a DBus frontend to systemd-datetimed (it allows all features with the exception of specific server config).

drakmouse

Allows configuring the mouse. It's quite low level and doesn't really let you configure anything interesting about your mouse, e.g. speed acceleration etc.

• Recommendation: Do we really need this now. Can it be dropped?

draklog

Parses /var/log/* files (decompressing and providing search functionality).

• Recommendation: Refactor as a client to the systemd-journal instead.

drak3d

Allows configuration of 3D Effects.

• Recommendaton: Kill it. It's not needed these days and will be needed even less in a Wayland world.

drakdm

Lets you pick a Display Manager.

• Recommendation: Drop our patched in prefdm/lookupdm stuff and switch to systemd units for individual DMs. It would ultimately just be a client of systemd also to list the DM units available and let you pick one (perhaps with a fixed list, or urpmq query too look up potential DMs that are not installed.

draknetcenter

Allows configuration of wired and wireless networks as well as more exotic PPP connections.

• Recommendation: Refactor as a frontend to Network/Modem Manager. While there is some uncertaintaiy as to the long term future of Network config stuff. NM is the current point where integration is made. All major desktops integrate with this and provide their own tools.

draknetprofile

Allows configuration of "Network Profiles" - i.e. collections of services which are based on network location.

• Recommendation: Kill it. It's based on sysvinit and is basically broken right now anyway. Creation of systemd targets for different profiles could be done as a replacement, but unless someone steps up...

draksound

Allows selection of PulseAudio or not (no longer allows selection of driver)

drakrpm

Allows installation of packages and updates.

• Recommendation: (slightly radical) Rebase as a frontend to Package Kit + ensure urpmi backend for package kit is awesome!

drakboot

Allows to add entry and boot parameters into bootloaders. Works nicely.

drakroam

Allows to pick-up access points for wifi connection, called by draknetcenter. It is a good standalone.

• Suggestion: Keep it as it is.

drakx11

Allows interactive configuration of X server, nice under X, and works under the console. How many times it saved us when only console login was available?

• Suggestion: Keep it

Standalone UI

Currently we have some tools which work with both graphical display and via a text console. These UIs are not universal however and require specific coding to cope with both modes (I think). Some work has been done to rebase some of the tools on a different UI toolkit libyui which offers a standard code but renders to GTK, Qt and ncurses. This approach could allow us to write tools once but get a native feel to them, which would seem like a approach.

More Info Feature:UiAbstraction4mcc

Overview of Recommendations

In short, whenver there is a good backend currently in active use (i.e. datetimed, localed, hostnamed, accountsservice, Network Manager, systemd, journald) we should try to drop all custom code that pokes at config files and use the DBus services exclusively.

If we decide that the installer should still allow access to some of these configuration items, then the following structure could be used:

1. After package install, the image is "booted" in a container. Only the bare minimum of services will be started (thanks to a custom target unit specified when starting the container). 2. DBus will be started inside the container. 3. Any configuration will talk via dbus to the daemon inside the container which, in turn, will bus-activate the necessary daemons inside the container which will, in turn, do the needed configuration. 4. Once configured, the container will be shut down and we reboot.

More Radical: Do we need standalone tools?

Nowadays, desktop environments themselves offer utilities to do much of what our tools once offered the only sane way to manage. A modern GNOME desktop lets you control user accounts (add/remove users, set passwords, set profile pictures (including from webcam) etc., control the date and time and set NTP, and automatic timezone detection based on location, set the hostname, connect to wired and wireless networks etc. All of these features are added as frontends to system-provided dbus services.

Now, not all desktops allow this level of integration, so there is still an argument to provide generic tools that work for those other desktops. If they are also frontends, just like GNOME, then it doesn't matter what interface you happen to use, the same underlying configuration changes will be made and switching desktops should be seamless.

Of course while we can promote our own tools, as they may duplicate functionality of a given desktop, we should be prepared to defer to the DE integrated tools when appropriate to do so for the most optimal user experience.

The Case for Less Radical: the small window managers (by Eatdirt)

Mageia is currently supporting a lot of small window managers: openbox, windowmaker, fvwm2, razorqt, e; etc... Small window managers, as opposed to Desktop Environments, only aims at providing simplest, fastest and more efficient ways to deal with graphics, at the expanse of not providing Desktop Integration and Candyness. Some of them are designed to minimize memory ressources to remain efficient for small systems. As such, it would be a "crime" to defaulting some small standalone tools to heavier DE daemons. As an example, even the running of dbus is of no usage for some of those and rendering some "heavier" settings compulsory would completely kill the purpose of having small WM on Mageia (I would be surprised if someone were using them for their appearence!). It does not seem realistic to ask users of WM to use GNOME/KDE desktop tools to mount a drive, add/remove users or set password. Therefore, either we do no longer support these WM (to be discussed?) or we still maintain (at least some of) our tools for small WM (in addition to standard command line ones. That last comment has been added to prevent any Integrist view that might propose to replace command line programs with DE tools...).

If we accept to maintain these WM (Eatdirt's point of view), we should keep an eye on not polluting them with inadequate tools and some efforts should be made into confining DE's daemons into what they are designed for: Desktops. (In fact, some minimal settings of systemd running services should also be implemented I guess, but that's another issue).

More Radical: Simplify Installer

As mentioned above, the installer is very flexible. But perhaps radical simplification should be considered. We could perhaps make use of btrfs subvolumes to create a series of unmodified images which we can simply "image" to the installed filesystem. This is very similar to live CDs but because subvolumes are used they are "clean". We can also provide desktops on top. so we could have a subvolume for a minimal install, a server install (build on top of minimal), a KDE desktop (built on top of minimal) a GNOME desktop (built on top of minimal). Due to the underlying filesystem the space is generally used efficiently. We could even use compression to allow efficient use of space.

These pre-created images would be installed super quickly after partitioning and first boot could allow for user account creation etc. (much like live).