Home Home > Tag > YaST
Sign up | Login

Posts Tagged ‘YaST’

Let’s blog about YaST

December 15th, 2015 by

Since some months ago, the YaST Team at SUSE has been using Scrum to organize the work. Among other things, that means the whole team takes part in a review meeting every three weeks to showcase the fixed bugs and the implemented features. To support those review meetings we often create screenshots, text summaries, short videos and other material. Is it not a pity that all that content get unnoticed for curious users and potential contributors?

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!

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


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.

Mockup :: GNOME3 and YaST

April 30th, 2011 by

With the release of GNOME3 I would assume that people are interested in seeing how YaST2 (suggestion: rename it to YaST3 !!) is going to take form with GTK3. Of course this means eventually writing another application in GTK3, hopefully different from the old gnome-control-panel ‘style’ which was actually pretty confusion from the user point of view as it was far too close to gnome-control-center, thus confusing new comers.

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

Introducing snapper: A tool for managing btrfs snapshots

April 1st, 2011 by

Today we want to present the current development of snapper, a tool for managing btrfs snapshots.

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.


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

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.


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.


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.

HowTo: Regular cleanup the Tempfolders

July 19th, 2009 by

If you would like to cleanup regularly your System, we presenting the following Steps!


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 @@
@@ -45,3 +45,3 @@
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
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.

Writing first YCP program

February 13th, 2009 by

Hi folks!

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”)



$ 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


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.

Writing wrapper packages for server applications or a generic YaST module?

January 27th, 2009 by

As we get more and more PHP-, Perl- and other applications like openSIS, Koha, Moodle, … in the Education repository, the question turns up, how to package those applications “the right way”.

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 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>

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?

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?

YaST releases independent of openSUSE releases?

November 7th, 2008 by

YaST is one of the cornerstones of openSUSE. It is developed for openSUSE and is released as part of openSUSE. There never was a release of YaST independent of openSUSE. Even the versioning of YaST is tied to openSUSE – the versions are 2.X.Y, where X is increased for every openSUSE release (17 for 11.1) and Y is simply a patch level, whenever a new fix or feature is added. Even more, every YaST package has its own versioning, so the only way to ensure you have a consistent set of YaST packages is via dependencies set in the .spec file of the YaST packages.

But in principle, YaST is a tool that can be used across distributions and there are people interested in this to happen. There are technical barriers to do releases independent of openSUSE (e.g. a lot of openSUSE-specific knowledge and behavior coded in YaST) as well as procedural. During past years, a lot of these non-technical issues has been addressed as we opened up the YaST development (re-licensing the code under GPL, opening up source control system and mailing lists, etc).

But still, there is one big thing left: YaST packages are released in concert with openSUSE. Yes, it is very convenient for openSUSE, but it makes it almost impossible to track the development during for people outside of our great distribution.

If one looks at the way the YaST packages are updated during the hotphase of an openSUSE release, the core parts of YaST (yast2-devtools, yast2-core, libyui, …) are rarely updated, they get a bug fix here and there. However, the distribution specific parts (yast2-pkg-bindings, yast2 common libraries, bootloader, storage, networking, …) get a fast flow of patch-level releases, typically several between openSUSE milestones.

Thus, the way forward I like the most right now is a compromise: a core YaST system should be released independently of the openSUSE release cycle while specific modules could keep their crescendo during openSUSE hot phase. How to do that?

For core YaST packages (a list to be defined) would be released independently of openSUSE and during hot phase, they would be handled the way other FOSS parts of openSUSE are – by patching the code in the package. The rest of the YaST, current practice would stay untouched.

There are clearly advantages – the YaST developers can do a proper release management of the core code and it is much more predictable how the core part of YaST will be released. On the other hand, people would need to be aware of the split.

However, I can imagine there is a lot of I did not realize. I’m definitely interested in comments about this topic.