Unifying the Console Keyboard Layouts for SLE and openSUSE

The way of managing internationalization in Linux systems has changed through the years, as well as the technologies used to represent the different alphabets and characters used in every language. YaST tries to offer a centralized way of managing the system-wide settings in that regard. An apparently simple action like changing the language in the YaST interface implies many aspects like setting the font and the keyboard map to be used in the text-based consoles, doing the same for the graphical X11 environment and keeping those fonts and keyboard maps in sync, ensuring the compatibility between all the pieces.

For that purpose, YaST maintains a list with all the correspondences between keyboard layouts and its corresponding "keymap" files living under /usr/share/kbd/keymaps. Some time ago the content of that list diverged between openSUSE and SLE-based products. During this sprint we took the opportunity to analyze the situation and try to unify criteria in that regard.

We analyzed the status and origin of all the keymap files used in both families of distributions (you can see a rather comprehensive research starting in comment #18 of bug#1124921) and we came to the conclusions that:

• The openSUSE list needed some minor adjustments.
• Leaving that aside, the keymaps used in openSUSE were in general a better option because they are more modern and aligned with current upstream development.

So we decided to unify all systems to adopt the openSUSE approach. That will have basically no impact for our openSUSE users but may have some implications for users installing the upcoming SLE-15-SP2. In any case, we hope that change will be for the better in most cases. Time will tell.

Exporting User Defined Repositories to AutoYaST Configuration File.

With the call yast clone_system an AutoYaST configuration file will be generated which reflects the state of the running system. Up to now only SUSE Add-Ons have been defined in the AutoYaST configration module. Now also user defined repositories will be exported in an own subsection <add_on_others> of the <add-on> section.

<add-on>
  <add_on_others config:type="list">
    <listentry>
      <alias>yast_head</alias>
      <media_url>https://download.opensuse.org/repositories/YaST:/Head/openSUSE_Leap_15.1/</media_url>
      <name>Yast head</name>
      <priority config:type="integer">99</priority>
      <product_dir>/</product_dir>
    </listentry>
  </add_on_others>
  <add_on_products config:type="list">
    <listentry>
      <media_url>dvd:/?devices=/dev/sr1</media_url>
      <product>sle-module-desktop-applications</product>
      <product_dir>/Module-Desktop-Applications</product_dir>
    </listentry>
    <listentry>
      <media_url>dvd:/?devices=/dev/sr1</media_url>
      <product>sle-module-basesystem</product>
      <product_dir>/Module-Basesystem</product_dir>
    </listentry>
  </add_on_products>
</add-on>

The format of the <add_on_others> section is the same as the <add_on_products> section.

Better Handling of Broken Bootloader Setups during Upgrade

With the current versions of SLE and openSUSE, using the installation media to upgrade a system which contains a badly broken GRUB2 configuration (e.g. contains references to udev links that do not longer exist) can result in an ugly internal error during the process.

The first possible problem could arise in the summary screen. Like shown in this screenshot.

If the error didn’t pop-up or if the user managed to recover from it, it was possible to reach the final phase of the upgrade process. But then the same internal error could still pop up in a different place:

Those errors will be fixed in the upcoming releases of SLE-12-SP5 and SLE-15-SP2 and, of course, in the corresponding openSUSE Leap version and in Tumbleweed. Now if such a broken setup is detected in the summary screen, a proper warning is displayed, including the technical details and a tip on what to do to fix the problem.

The user can ignore the problem or click on "booting" to fix it. In the latter case, the usual pop-up with instructions will appear.

If the final stage of the upgrade process is reached without fixing the error, the wild internal error is now replaced by an informative message that does not interrupt the process.

Hopefully most of our users will never see these improvements. But users with a broken system will likely appreciate the extra guidance.

Old Storage, New Features

If you are an usual reader of this blog, most likely you already know that YaST has a completely re-implemented Storage stack (a.k.a. storage-ng). That new storage code did its debut with the SLE 15 (and openSUSE Leap 15.0) family. And thanks to this revamped code, our beloved users can enjoy today some new great features in YaST like Bcache, partitionable Software RAIDs or multi-device Btrfs file system (just to mention a few examples). But SLE 12 (openSUSE 42) products are still alive and getting improvements with every maintenance update! Of course, the old Storage stack is not an exception, and now on a new installation scenario is supported.

Thanks to a bug report, we realized that Snapper could not be configured in some cases. More specifically, the reporter was trying to install with AutoYaST over a directly formatted Software RAID by using Btrfs for root and enabling snapper. The installation was perfectly performed, but it turned out that snapper was not correctly enabled in the installed system. After having a deeper look into the problem, we discovered that this was not a bug exactly but a completely missing feature. But no problems, YaST got down to work and now it is nicely supported.

In order to give the SUSE and openSUSE communities an opportunity to lurk into those review meetings, we have decided to create this team blog and post here the highlights after every meeting. Not all the fixes and features will be covered, but we’ll try to blog about the most exciting or relevant changes.

Obviously, many of those posts will be more exciting for developers and Tumbleweed users than for users of the stable release (bugfixes tend to be unexciting). But, as some kind of bonus track, Leap 42.1 users can always revisit the summary of what the recent release brought to the YaST (and friends) world.

The current sprint ends right before Christmas, so stay tuned!

With current YaST, plenty of tasks that system administrator could image are doable using understandable UI: creating users, bootloader configuration, network setup and even Apache configuration. However, it has its drabacks. While being do-it-all tool, it comes with large package dependency even for only simple tasks. It is largely written in an outdated language which has its roots in last century and only few people in the world know it. It lacks the testing abilities of modern languages. It is SUSE specific and lacks larger developer community.

So last year, we (actually, Josef) came with the idea for YaST++: new configuration library that could be a common layer for configuration tools in SUSE (and beyond). Such library should provide simple and understandable API for all tools around. Written in up-to-date language many people know and like, so they can join the development (spoiler: we chose Ruby). Offering bindings  to various other languages, so different tools could benefit from it,

Now, this “YaST++” does not actually mean to be replacement of current YaST (with its Qt/GTK/ncurses UI), but it could replace the lower layer of YaST, which is doing the real system configuration. And it would be open for other library users as well: the obvious targets for now are WebYaST and SUSE Studio, but we’d like to see if other tools are interested: even from non-SUSE world.

From architecture point, YaST++ is itself divided into two layers, we call them YLib and config agents. YLib is the high-level library, providing the API (like ‘create user’, ‘set new time zone’ etc.). Config agents form the lower layer, that is actually touching the system. This low level consits of D-BUS services, which are running as a root (thus have the full access to the system) but are started only for users with proper permissions (we are using polkit for policies definition). So YaST++ offers role based access management, where specific users can be allowed to do specific sets of actions. For more, check our architecture document (still WIP).

We’ve started to work on several modules (none of them is finished, though). Let’s look at example in module for users configuration (packages yast++lib-users and config_agent-passwd). Look at example code in ‘users_read’ script of examples subdirectory. With simple ruby call of

YLib::Users::read({})

you get the list of current users. If the script gets additional parameters, it can list e.g. all data about selected user, or only specific information about all:

> ./users_read root
{“gid”=>”0”, “name”=>”root”, “uid”=>”0”, “shell”=>”/bin/bash”, “password”=>”x”, “home”=>”/root”}

> ./users_read only name
{“result”=>[“Batch jobs daemon”, “User for Avahi”, “bin”, “Daemon”, “dnsmasq”, “FTP account”, “Games account”, “User for haldaemon”, “User for OpenLDAP”, “LightDM daemon”, “Printing daemon”, “Mailer daemon”, “Manual pages viewer”, “User for D-Bus”, “MySQL database admin”, “News system”, “user for nginx”, “nobody”, “NTP daemon”, “User for build service backend”, “openslp daemon”, “PolicyKit”, “Postfix Daemon”, “PulseAudio daemon”, “qemu user”, “Router ADVertisement Daemon for”, “root”, “RealtimeKit”, “Smart Card Reader”, “user for smolt”, “SSH daemon”, “NFS statd daemon”, “Novell Customer Center User”, “TFTP account”, “usbmuxd daemon”, “Unix-to-Unix CoPy system”, “WWW daemon apache”, “User for YaST-Webservice”, “LXDE Display Manager daemon”]}

YaST++ developement is in its early stage (even the name is not final), but we already have something to offer.

Check the code and documentation at github project. There’s already a simple tutorial for those who want to try writing new parts.

Download packages from Build Service project.

Comment/propose/oppose in public YaST mailing list.

My suggestion (unaware if it’s possible or not) was probably to explore GNOME3 features to serve YaST integrated already with GNOME3. This could be an interesting approach as it would offer integration and some advantages:

* Better integration with GNOME3 without having to write(/maintain another application;
* Take advantage of YaST2 modular structure;
* Present YaST in a prime space in GNOME3, thus offering a openSUSE differentiation point;
* No conflicts with possible KDE existing front-ends for YaST2;
* Improve users experience.

My proposal would be something like (maybe to be served as an extension for gnome-shell). Please neglect my ‘lame’ photo manipulation skills:

Mockup: YaST2 on GNOME3

For years we had the request to provide rollbacks for YaST and zypper but things never got far due to various technical problems. With the rise of btrfs snapshots we finally saw the possibility for a usable solution. The basic idea is to create a snapshot before and after running YaST or zypper, compare the two snapshots and finally provide a tool to revert the differences between the two snapshots. That was the birth of snapper. Soon the idea was extended to create hourly snapshots as a backup system against general user mistakes.

The tool is now in a state where you can play with it. On the other hand there is still room and time for modifications and new features.

Overview

We provide a command line tool and a YaST UI module. Here is a brief tour:

First we manually create a snapshot:

# snapper create --description "initial"

Running YaST automatically creates two snapshots:

# yast2 users

Now we can list our snapshots:

# snapper list
Type   | # | Pre # | Date                     | Cleanup  | Description
-------+---+-------+--------------------------+----------+-------------
single | 0 |       |                          |          | current
single | 1 |       | Wed Mar 30 14:52:17 2011 |          | initial
pre    | 2 |       | Wed Mar 30 14:57:10 2011 | number   | yast users
post   | 3 | 2     | Wed Mar 30 14:57:35 2011 | number   |
single | 4 |       | Wed Mar 30 15:00:01 2011 | timeline | timeline

Snapshot #0 always refers to the current system. Snapshot #2 and #3 were created by YaST. Snapshot #4 was created by an hourly cronjob.

Getting the list of modified files between to snapshots is easy:

# snapper diff 2 3
c... /etc/group
c... /etc/group.YaST2save
c... /etc/passwd
c... /etc/passwd.YaST2save
c... /etc/shadow
c... /etc/shadow.YaST2save
c... /etc/sysconfig/displaymanager
c... /var/tmp/kdecache-linux/icon-cache.kcache
c... /var/tmp/kdecache-linux/plasma_theme_openSUSEdefault.kcache

You can also compare a single file between two snapshots:

# snapper diff --file /etc/passwd 2 3
--- /snapshots/2/snapshot/etc/passwd    2011-03-30 14:41:45.943000001 +0200
+++ /snapshots/3/snapshot/etc/passwd    2011-03-30 14:57:33.916000003 +0200
@@ -22,3 +22,4 @@
 uucp:x:10:14:Unix-to-Unix CoPy system:/etc/uucp:/bin/bash
 wwwrun:x:30:8:WWW daemon apache:/var/lib/wwwrun:/bin/false
 linux:x:1000:100:linux:/home/linux:/bin/bash
+tux:x:1001:100:tux:/home/tux:/bin/bash

The main feature of course is to revert the changes between two snapshots:

# snapper rollback 2 3

Finally yast2-snapper provides a YaST UI for snapper.

Testing

Playing with snapper should only be done on test machines. Both btrfs and snapper are not finished and included known bugs. Here is a step-by-step manual for installing and configuring snapper for openSUSE 11.4.

Feedback

We would like to get feedback, esp. about general problems and further ideas. There are also tasks everybody can work on, e.g. the snapper wiki page or a man-page for snapper.

For the time being there is no dedicated mailing-list so just use opensuse-factory@opensuse.org.

Launch YaST:
Choose Category “System”, then “Editor for /etc/sysconfig Files”.

Then open “System” and after that open “Cron”.

Here you find the following Entrys:

CLEAR_TMP_DIRS_AT_BOOTUP = “no”
Change to: “yes”
That means: enable or disable the Cleanup Function global.
Default: “no” (=off!)

TMP_DIRS_TO_CLEAR = “/tmp”
That you can leave.
That means: First List from Folders, that can be deleted.
Default: /tmp

MAX_DAYS_IN_TMP = 0
Change to: “1” (=deletes all Files who are older than 24h)
Means: Max. File Lifetime in days. That is for the Files, defined in TMP_DIRS_TO_CLEAR.
Default: 0 (=disabled)

Close the Editor. You see all changes and you can close the Editor.

Close “YAST”
In the next Systemstart cron cleans up your /tmp.

You can define an second List:

LONG_TMP_DIRS_TO_CLEAR = “”
Means: second Folderlist who can be deleted.
Default: “”
Possible Option: “/var/tmp”

MAX_DAYS_IN_LONG_TMP = 0
Means: Max File Lifetime in days, for all Files who are defined in LONG_TMP_DIRS_TO_CLEAR.
Default: 0 (= disabled)
Possible Option: “28″

Based on Reinhard Haase’s HowTo on: http://tiefenwirkung.wordpress.com/2009/07/19/temporare-dateien-unter-linux/

Martin and Stano created some concept and added new logging functions y2usernote and y2useritem. These log to the new log file, /var/log/YaST2/y2changes (or $HOME/.y2changes).

The question which is still not resolved is how should we use these functions? Which events our modules produce should provide description as “note” and which should provide “items”? What level of complexity should be presented to user? Should we log the real actions, just like commands passed to system agent or rather the explanations of the actions taken? Or both?

Let’s go to the example. The changes are already in FACTORY version of yast2-users packages (yast2-perl-bindings needed as well), so you may even try yourself.

At first, I started logging actions done in Write function. I deleted one user and renamed another. See:

2009-02-05 15:15:55 <item> rivendell User and Group Management module started
2009-02-05 15:16:12 <note> rivendell File written: ‘/etc/group’
2009-02-05 15:16:12 <note> rivendell User pre-deletion script called: ‘/usr/sbin/userdel-pre.local cc 1003 100 /local/home/cc’
2009-02-05 15:16:12 <note> rivendell File written: ‘/etc/passwd’
2009-02-05 15:16:12 <note> rivendell User ‘aa’ renamed to ‘bb’
2009-02-05 15:16:12 <note> rivendell Home directory moved: ‘/bin/mv /local/home/aa /local/home/bb’
2009-02-05 15:16:12 <note> rivendell File written: ‘/etc/shadow’
2009-02-05 15:16:12 <note> rivendell nscd cache invalidated: ‘/usr/sbin/nscd -i passwd’
2009-02-05 15:16:12 <note> rivendell nscd cache invalidated: ‘/usr/sbin/nscd -i group’
2009-02-05 15:16:12 <note> rivendell Group ‘dialout’ modified
2009-02-05 15:16:12 <note> rivendell Group ‘video’ modified
2009-02-05 15:16:12 <note> rivendell Home directory removed: ‘/bin/rm -rf /local/home/cc’
2009-02-05 15:16:12 <note> rivendell User post-deletion script called: ‘/usr/sbin/userdel-post.local cc 1003 100 /local/home/cc’
2009-02-05 15:16:13 <item> rivendell User and Group Management module finished

Now, it is not bad, but the item “File written: ‘/etc/group'” doesn’t give much detailed info about what was done to that file. Stano proposed printing the diffs of the original and modified one, it could look this way:

2009-02-09 10:05:50 <item> rivendell User and Group Management module started
2009-02-09 11:05:49 <note> rivendell Backup created: ‘/bin/cp /etc/group /etc/group.YaST2save’
2009-02-09 11:05:49 <note> rivendell File written: ‘/etc/group’
2009-02-09 11:05:49 <note> rivendell Comparing original and new version:
— /etc/group.YaST2save    2009-02-09 11:05:49.000000000 +0100
+++ /etc/group    2009-02-09 11:05:49.000000000 +0100
@@ -8,3 +8,3 @@
daemon:x:2:
-dialout:x:16:bb,hh,linux,zz
+dialout:x:16:aa,hh,linux
disk:x:6:
@@ -45,3 +45,3 @@
vboxusers:!:113:jsuchome
-video:x:33:bb,hh,linux,zz
+video:x:33:aa,hh,linux
wheel:x:10:
`
2009-02-09 11:05:49 <note> rivendell User pre-deletion script called: ‘/usr/sbin/userdel-pre.local zz 1003 100 /local/home/zz’
2009-02-09 11:05:49 <note> rivendell Backup created: ‘/bin/cp /etc/passwd /etc/passwd.YaST2save’
2009-02-09 11:05:49 <note> rivendell File written: ‘/etc/passwd’
2009-02-09 11:05:49 <note> rivendell Comparing original and new version:
— /etc/passwd.YaST2save    2009-02-09 11:05:49.000000000 +0100
+++ /etc/passwd    2009-02-09 11:05:49.000000000 +0100
@@ -28,6 +28,5 @@
wwwrun:x:30:8:WWW daemon apache:/var/lib/wwwrun:/bin/false
-bb:x:1002:100:AAA:/local/home/bb:/bin/bash
+aa:x:1002:100:AAA:/local/home/aa:/bin/bash
hh:x:1000:100:hhh:/local/home/hh:/bin/bash
linux:x:1001:100:linux:/local/home/linux:/bin/bash
-zz:x:1003:100:zz:/local/home/zz:/bin/bash
+::::::
`
2009-02-09 11:05:49 <note> rivendell User ‘bb’ renamed to ‘aa’
2009-02-09 11:05:49 <note> rivendell Home directory moved: ‘/bin/mv /local/home/bb /local/home/aa’
2009-02-09 11:05:49 <note> rivendell Backup created: ‘/bin/cp /etc/shadow /etc/shadow.YaST2save’
2009-02-09 11:05:49 <note> rivendell File written: ‘/etc/shadow’
2009-02-09 11:05:49 <note> rivendell nscd cache invalidated: ‘/usr/sbin/nscd -i passwd’
2009-02-09 11:05:49 <note> rivendell nscd cache invalidated: ‘/usr/sbin/nscd -i group’
2009-02-09 11:05:49 <note> rivendell Group ‘dialout’ modified
2009-02-09 11:05:49 <note> rivendell Group ‘video’ modified
2009-02-09 11:05:49 <note> rivendell Home directory removed: ‘/bin/rm -rf /local/home/zz’
2009-02-09 11:05:49 <note> rivendell User post-deletion script called: ‘/usr/sbin/userdel-post.local zz 1003 100 /local/home/zz’
2009-02-09 11:05:50 <item> rivendell User and Group Management module finished

Here, the user knows more about the real changes, but the log file is getting a bit less readable again… still I think I’d prefer it.

You could see on examples that I don’t really use the advantage of having 2 logging functions. AFAIK Martin’s original proposal was to use items to tell what actions are we going to perform and notes to log the details of such action. This is hardly achievable in yast2-users module (may be better with
others), since at the time of writing we don’t know the “user actions” taken, this is the info which is known when user is clicking in the UI (*). So another idea is to log directly when users is using UI and not at the time of write. See the last example (this is not a full log this time, just part of it):

2009-02-06 15:54:02 <item> rivendell User and Group Management module started
2009-02-06 15:54:11 <note> rivendell (UI info) User ‘bb’ removed from group ‘dialout’
2009-02-06 15:54:11 <note> rivendell (UI info) User ‘aa’ added to group ‘dialout’
2009-02-06 15:54:11 <note> rivendell (UI info) User ‘bb’ removed from group ‘video’
2009-02-06 15:54:11 <note> rivendell (UI info) User ‘aa’ added to group ‘video’
2009-02-06 15:54:11 <note> rivendell (UI info) User ‘bb’ renamed to ‘aa’
2009-02-06 15:54:11 <item> rivendell (UI info) User modified: ‘aa’
2009-02-06 16:03:10 <item> rivendell User and Group Management module finished

I think the last method is getting more talkative and actually is not more helpful.

So – comments? Proposals?

(*) Actually it would need to be cached during the UI-clicking and logged at the time of writing only if user doesn’t cancel the actions.

It was a long time since my last blog.

Today, i will show you my first program, it`s a simple test program which shows basic functions of YCP

Let`s start!!

first of all, you need all core development YaST and QT packages

(All mentioned bottom steps, can be made with normal user )

second , you must create a  symlink to /usr/lib/YaST2/bin/y2base

$ ln -s <destination> <linkname>

(In my case name of symlink is y2base.)

third , you need two console`s , one for program writing and one for monitoring .y2log (where you can see all debug messages)

if you wish more detailed debug output during root session, than type in console following :

$ su

$ export Y2DEBUG=1

$ exit

(switching back to normal user)

Ok, lets see the code of PushButton.ycp !

{
// Build a dialog with one button and two labels.
// Wait until that button is clicked,
// then close the dialog and terminate.

UI::OpenDialog( `VBox(
`Label(`opt(`boldFont),”PushButton TEST!!!!!!!!”),
`PushButton( “&OK” ),
`Label(`opt(`boldFont),”JUST SIMPLE TEST”)
)
);

UI::UserInput();
UI::CloseDialog();
}

Than:

$ chmod 765 PushButton.ycp

After you have written the program  , type in the console:

$ ./y2base ./PushButton.ycp qt

You will get following window:

What is amazing at YCP, that this code can be interpreted into ncurses

Try following command:

$ ./y2base ./PushButton.ycp ncurses

Result:

You have written only one code , which can be used in two different gui environments graphical and  text mode!

In my next blog i will write about creating own SCR Agent.

A normal user, who wants to use one of these apps, might just choose to install the package and has the problem how to proceed afterwards. openSUSE sadly has no “post config” scripts like Debian based distributions – even the SuSEconfig scripts are deprecated. So all a packager can currently do is:

1. write a README.SuSE (which is already the case for many packages) and place it in /usr/share/doc/packages/<packagename>/README.SuSE explaning how to proceed
2. sugget what the user always wants to do and do it via %post-script after the installation of the RPM
3. combine 1&2 and point the user to a script in the README.SuSE
4. write a YaST module which can be started during installation or afterwards
5. any other option I missed (please inform me!)

For the Education project, I’m currently thinking about two ways to make the life of the admins easier.

First: think about “wrapper packages” around the normal packages. I’ll take moodle as example. The normal moodle package installs the php-scripts, an apache configuration and some other config stuff – but will not setup the complete moodle instance. So the user has to install the mysql database himself. An additional wrapper package can do this for him. This package comes with a SQL-Dump of the current moodle version (therefore requires the exact moodle version), and uses a stored mysql-root password to create a new database and insert the database-dump. If needed (for example: the user enables the “user LDAP-Auth wherever possible” checkbox in a (to be written) yast-edu module), additional tasks can be triggered by the wrapper package.

We can also think about calling a “generic” YaST module after installation of such a “needs postconfiguring” package. If we define a place (say: /var/adm/YaST/postinstall/) where packages can place a file containing some important questions to configure the application, and someone writes a YaST module which can be started, this would perhaps be “very cool”. If the user has entered his values, the YaST module can start one or more scripts (coming with the package) and feeds it with the entered values. The biggest questions for this solution:

1. When should this YaST module be started? IMO it could be enough to let the user start it manually and select the package he wants to configure. => No adaptions of the current workflows is needed. But perhaps there are other options (like calling it via “SuSEconfig”)?
2. Who can write such a module?
3. Who defines the config syntax?

Think about a file like this:

<package name=”moodle”>
<questionpack type=”string” action=”/usr/share/moodle/scripts/install_database”>
<question arg=”1″ type=”string”>What’s the database password?</question>
<question arg=”2″ type=”string”>What should be the name of the new database (suggest: moodle)?</question>
<question arg=”3″ type=”string”>What’s the username of the new database user?</question>
<question arg=”4″ type=”string”>What’s the password of the new database user?</question>
</questionpack>

<questionpack action=”/use/share/moodle/scripts/configure_auth_backend” type=”selectbox”>
<question arg=”1″>What auth-backend should be used?</question>
<answer value=”1″>ldap</answer>
<answer value=”2″>mail</answer>
<answer value=”3″>passwd</answer>
</questionpack>
</package>

I think, there’s room for many enhancements in this area – what do you think ?

Should/Could we produce something like a “Windows-Installer” for openSUSE? Or is it enough to provide special “wrapper packages”? Or is “what was hard to write, should be hard to install” still a valid answer?

The only visible difference is the additional “Configure…’ button at the bottom of the dialog. This button would be active only if there is a YaST module associated with the entry. After clicking it, the respective YaST module would be started:

With this simple principle, the YaST control center ‘Network Services’ section would be reduced to:

And all those YaST modules would be available from ‘System’ section:

This approach could be used even further. You can see that the ‘Network Services’ section contents do not really match the section name anymore. In fact, most of the items could be moved to other modules as well. E.g. introducing a module for authentication/authorization, which would cover Kerberos client, LDAP client, etc. The NFS client is in fact a part of the new Disk Partitioning module already. So, the section could vaporize completely.

However, there are drawbacks. The biggest one I see is a ‘starting point’ problem. Just imagine you want to have a Apache2 running in your system. Until now, the YaST HTTP module is installed and can be used to bootstrap your configuration – it will install the packages and help to set up the basics. But with the new approach, the apache2 package is not installed, therefore System Services module would not see the apache2 service (init script) and does not show it at all! I’m not sure how to address this. Maybe the best would be to attach the YaST  module to apache2 package or HTTP server pattern and the Software Management module would become such starting point. Would it be better? I don’t know.

Then, there is an issue of a quick access – if you are moderately experienced user, you know what you are looking for and you start a proper module right away. But to figure out what is the configuration starting point if it’s hidden in another module, that might be a blocker.

I’m sure there are more problems. Anyway, I find the idea quite useful for reducing the number of YaST modules. What do you think?