Home Home
Sign up | Login

Author Archive

YaST++: next step in system management

February 15th, 2012 by

All of you probably know YaST, the installation and system configuration tool for openSUSE.

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.

Your own OEM configuration: YaST Firstboot

May 13th, 2010 by

Have you ever thought how users should configure their systems, deployed by AutoYaST or kiwi? One of possible answers is called YaST Firstboot.

The YaST firstboot utility is a special kind of configuration workflow that can be run after the basic system is installed. It is started on the first boot of the system and guides a user through a series of steps that allow for easier configuration of their desktops. YaST firstboot does not run by default and has to be configured to run by the user or the system administrator. It is useful for image deployments where the system in the image is already configured (read: AutoYaST, SUSE_Studio, KIWI), and end-user should do only the last few steps, like setting the root password.

Enabling Firstboot

To enable running firstboot configuration sequence on the machine, it is necessary to:

  • Have yast2-firstboot package installed. Depending on your installation method, this means adding the package to the list of packages to be installed (e.g. for AutoYaST) or that are part of installation image.
  • Create the empty file /var/lib/YaST2/reconfig_system. If this file is present on system boot, firstboot configuration sequence is started. YaST Firstboot removes the file when the configuration is done.

Customizing YaST Firstboot

There are two files that control the behavior of Firstboot: the firstboot control file (firstboot.xml) and the sysconfig file /etc/sysconfig/firstboot. The control file defines the steps that should be part of your configuration sequence, in the sysconfig file it is possible to define custom messages and paths to various files.

Customized Messages

Most important texts configurable in sysconfig file is the text shown in the License Agreement screens. For license texts, there are sysconfig variables FIRSTBOOT_LICENSE_DIR and FIRSTBOOT_NOVELL_LICENSE_DIR.

The license text is read from the file ‘license.txt’ or from ‘license_<locale>.txt’. The license texts of the Novell base product are by default installed to the directory /etc/YaST2/licenses/base/ — you can set different value to FIRSTBOOT_NOVELL_LICENSE_DIR if they are elsewhere. Use FIRSTBOOT_LICENSE_DIR to indicate a path to directory containing vendor licence texts; it is preferred to put these license texts into another subdirectory of /etc/YaST2/licenses/.

To show two license texts in one dialog (typically the one from vendor and one from Novell), use ‘firstboot_license_novell’ step in your firstboot.xml file. This client will use the license texts specified by both FIRSTBOOT_LICENSE_DIR and FIRSTBOOT_NOVELL_LICENSE_DIR.

Customized Workflow

The default firstboot workflow can be controled using one single file which uses the same syntax as the control.xml file used to control the complete installation. The firstboot control file consists of workflow and proposal configurations and can be used to add or remove configuration screens depending on the end configuration of the system. The file firstboot.xml is installed with the yast2-firstboot package and can be found at the following location: /etc/YaST2/firstboot.xml.

This file can be modified to match the post installation requirements of the product in question. In addition to the default and pre-installed components, custom screens can be added to enable maximal flexiblity during post installation. Look into the example firstboot.xml file coming with your yast2-firstboot package for more available steps.

Custom Scripts

Not everything can be achieved with already prepared steps, and it is usually not necessary to write your own ycp dialogs.

You can add schell scripts to be executed at the end of the firstboot configuration. Scripts should be placed in /usr/share/firstboot/scripts or in a custom location that can be set using the variable SCRIPT_DIR of /etc/sysconfig/firstboot configuration file. The scripts are executed in alphabetical order of their names.

AutoYaST Support

It is possible to configure the firstboot process as a part of autoinstallation, so the system can be installed with most of the default values set via AutoYaST profile, leaving the rest to the end user during the firstboot sequence.

As a part of autoinstallation configuration, you need to provide all the changes mentioned above:

  • Customize /etc/sysconfig/firstboot: it can be done e.g. via Sysconfig Editor in System section of AutoYaST configuration module.
  • Provide customized firstboot.xml file and point to its location in FIRSTBOOT_CONTROL_FILE value of /etc/sysconfig/firstboot.
  • Enable Firstboot: do it via GUI in Misc/Firstboot section of AutoYaST configuration module or manually by adding the section
<firstboot>
   <firstboot_enabled config:type="boolean">true</firstboot_enabled>
</firstboot>

to your AutoYaST profile.

This is the shortened version of the article published at http://en.opensuse.org/YaST_Firstboot

User readable logging of YaST modules

April 6th, 2009 by

For quite some time, we had user requests (fate #100386) to provide the logging that would be readable to users (= not only YaST developers). Such logs should provide the information what certain YaST action is really doing to the system and exclude all the internal debug info our y2logs are full of.

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.