Home Home > 2009 > 01 > 08 > Integration of YaST Server Modules to YaST System Services
Sign up | Login

Integration of YaST Server Modules to YaST System Services

January 8th, 2009 by

Today, I’ve played a bit with an idea to allow starting of YaST Server module from the YaST System Services module.

YaST System Services (Runlevel) Editor

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:

YaST Firewall module invoked from YaST System Services module

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

YaST Control Center, Network Services section

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

YaST Control Center, 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?

Both comments and pings are currently closed.

3 Responses to “Integration of YaST Server Modules to YaST System Services”

  1. This is nice, I like this adding of “hyperlinks”.

    I find the idea quite useful for reducing the number of YaST modules
    It is useful even without reducing the number of modules.
    And anyway, I think that we do not want to reduce the number of modules. You probably mean to reduce the confusion created by having an overwhelming number of icons in the control center.

    On the implementation front, I imagine an entry in the LSB comment block of /etc/init.d/apache2, like # X-YaST-package: yast2-http-server where it could pull in the rpm if not installed yet, and find the module from its desktop file, or use an additional # X-YaST-module: http-server.

    • Stanislav Visnovsky

      Yes, I’ve meant number of icons in the control center. As to the implementation, /etc/init.d/apache2 is part of apache2 package, or am I missing somethig?

  2. Lukas Ocilka

    I really like the idea of starting the configuration module from the Runlevel Editor.

    What I don’t like is reducing the Control Center. It just adds another confusing level and in my opinion, users want to configure HTTP Server and FTP Server rather than edit the apache2 and vsftpd services. The configuration names tell a lot more than the runlevel service names. Some configuration modules (FTP) also allow to choose from more services to configure (either vsftpd or pure-ftpd).

    Some services don’t seem to be connected with their configuration modules or their names are confusing (package: bind, service: named, configuration: DNS Server).

    Additionally, as mentioned above, the configuration module itself makes sure that all the needed packages are installed while the service is configured. On the other hand your idea doesn’t allow to even start the configuration module before the service is installed with all its dependencies (just because it’s missing in menu).