Contents
Summary
Switch drakx and various other tools to use systemd-blessed APIs and tools to get and set various standard things. e.g. keyboards layouts, timezone etc. rather than homegrown alternatives.
Owner
- Name: Colin Guthrie
- Email: colin@mageia.org
Resources
Myself and probably Thierry to review when I do perl coding mistakes.
Current status
- Targeted release: Mageia 4
- Last updated: 2014-02-23
- Percentage of completion: 100%
polkit conversion is complete
Detailed Description
Systemd is now providing various interfaces for standard things. For example setting the clock, the system fonts and keyboard layouts in a standard, cross distro way with defined interfaces and command line tools.
In Mageia we have various methods of solving similar problems. Rather than duplicate the work of systemd and deviate from the new "standard" way of doing things we should adapt to the new interfaces.
Why it would be good for Mageia to include it
Using the standard interfaces means various command line tools shipped with systemd work the same as the wrapped up nice GUI versions we provide in Mageia Control Centre.
Test case
Each part needs to be tested independently.
Software / Packages Dependencies
Keyboard
/sbin/mageia-setup-keyboard (from x11-server-common and called via udev rules and occasionally run directly I believe) should be moved over to the localed methods (which write X11 config snippet in /etc/X11/xorg.conf.d/) and we should deprecate the Xkb values in /etc/sysconfig/keyboard
- you mean writing/reading directly /etc/X11/xorg.conf.d/00-keyboard.conf ?
- it should be coordinated with systemd mantainers; currently there is a well defined config file for
- console (and so, console keyboard) info: /etc/vconsole.conf but nothing equivalent for X11
- it seems systemd guesses X11 values from console ones; but nothing similar for X11.
- Mageia/Mandriva is better here; so it should be suggested to systemd people to define a well known name
- where all systemd distributions will write the system wide X11 keyboard info.
- also, it seems systemd is duplicating much of the X11 kb database; imho it is not the right place to have it;
- mayba a distro-independent package would be a good idea, but definitively not in the systemd core (it would be
- like having a database of printer drivers)
- srtxg
For console fonts and keyboard mapping we should already be using /etc/vconsole.conf which is also managed via localed. This should deprecate /etc/sysconfig/keyboard completely.
Date/Time
We should use the timedated methods for setting the timezone and system time etc.
Hostname
We should use the hostnamed methods for setting the hostname of the machine.
Autologin and Display Managers
This is not a systemd feature per-se but it has implications here. Rather than have a complex script for running the correct display manager, we should simply switch to dedicated systemd units for each DM (e.g. gdm.service, kdm.service etc.). Enabling one would automatically disable the others etc.
In doing this we would deprecate the DISPLAYMANAGER value in /etc/sysconfig/desktop.
Also we would no longer be able to run the autologin binary bypassing the DM. This is seen as a good thing generally as it will help fix the problem whereby this package does not properly register the user in an X11 session with logind. Any uses of the legacy autologin should be found and adapted. For live installation, of GNOME and KDE we configure the DMs in question (gdm and kdm) to do the autologin for us. The config in /etc/sysconfig/autologin is not technically used (see bug #9817).
In the case of gdm autologin, we should ensure the GNOME tools (System Settings -> User Accounts) properly identifies the user as being configured for autologin as it's quite hard to undo the configuration (likely needs adapting to dconf variables rather than gdm.conf variables)
Mageia Online Applet
In various places we parse /etc/product.id. We should instead parse /etc/os-release which is a cross distro "standard".
consolehelper/userhelper vs. polkit
It seems that these days the consolehelper approach is dated and lacks standardisation. We seem to have a mixture of authentication related things in our tools. Some ask for the user password (e.g. when applying updates), some ask for the root password. We should really standardise this with a holistic vision for what is wanted and ensure that everything uses polkit instead - granting root privileges only when appropriate.
This document describes how to convert from consolehelper to a policy kit-based solution: http://fedoraproject.org/wiki/Features/UsermodeMigration
As a simple example, this shows how to convert the drakconf wrapper to policy kit:
[root@jimmy ~]# mv /usr/bin/drakconf /usr/bin/drakconf.old [root@jimmy ~]# cat > /usr/bin/drakconf <<<EOF [root@jimmy ~]# cat > /usr/bin/drakconf <<EOF > #!/bin/sh > exec /usr/bin/pkexec /usr/sbin/drakconf.real > EOF [root@jimmy ~]# chmod a+x /usr/bin/drakconf [root@jimmy ~]# cat > /usr/share/polkit-1/actions/org.mageia.control-centre.policy <<EOF > <?xml version="1.0" encoding="UTF-8"?> > <!DOCTYPE policyconfig PUBLIC > "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN" > "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd"> > <policyconfig> > > <vendor>Mageia Control Centre</vendor> > <vendor_url>http://mageia.org/control-centre</vendor_url> > > <action id="org.mageia.control-centre.pkexec.run"> > <_description>Run Mageia Control Centre</_description> > <_message>Authentication is required to run Mageia Control Centre</_message> > <icon_name>drakconf</icon_name> > <defaults> > <allow_any>no</allow_any> > <allow_inactive>no</allow_inactive> > <allow_active>auth_admin_keep</allow_active> > </defaults> > <annotate key="org.freedesktop.policykit.exec.path">/usr/sbin/drakconf.real</annotate> > <annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate> > </action> > </policyconfig> > EOF
That's all that's needed to allow running drakconf as root. Note however that the above simple example does away with the wrapper script to check for X and run the right binary, so this isn't a complete example. Also the code currently inside /usr/sbin/drakconf.real to get itself root privs etc. needs to be stripped out and replaced with a simple error check which exits if we're not root and doesn't attempt to gain them itself.
What could disrupt development of this new feature
Not much.
Planning
Analysis of the current tools and work out which ones need to be adapted. Also work out how it would affect the installer.
Contingency
If all else fails, we just continue with the current approach.
