Home Home > Systems-management
Sign up | Login

Archive for the ‘Systems Management’ Category

Highlights of YaST Development Sprint 47

December 7th, 2017 by

On the night of December 5th, teams of three are sprinting through the streets of Czech towns, visiting homes: Mikuláš (the developer), čert (the scrum master), and anděl (the product owner). If you’ve been a bad kid, you will get pieces of coal or brown potatoes. Good kids, on the other hand, will get new YaST features:

  • Performance: adapting to jemalloc, a better Ruby memory allocator
  • Replaced components: s/ntpd/chrony/g s/SUSEFirewall2/firewalld/g
  • Storage: resizing partitions, resizing RAID
  • Software modules and extensions: preselecting them, resolving dependencies automatically, creating your own installation ISO with mksusecd
  • Security related: tarballs for reproducible builds, SSH keys for root
  • AutoYaST: asking for a disk

Performance

Using Jemalloc Memory Allocator in Ruby

The MRI Ruby (the original C implementation) interpreter allows using the jemalloc library for allocating the memory instead of the usual glibc default. The advantage is better memory usage (30-40% less used memory was reported here) and it has some extra debugging features.

But after enabling this feature in Ruby in openSUSE Factory and SLE15 many YaST packages failed to build. It turned out to be an issue caused by dynamically loading the library by YaST. A workaround was to directly link the YaST against libjemalloc.

Later we found out that some packages still do not build. This time the problem was caused by a warning printed by the library on the error output. That happened only when running the old YaST test suite which still uses an embedded Ruby interpreter (normal YaST usage or the new unit tests use full Ruby which does not have this problem). The fix was just to ignore that warning when checking the error output in the tests.

If you want to check whether your Ruby uses the jemalloc feature then run this command:

ruby -r rbconfig -e "puts RbConfig::CONFIG['LIBS']"

If the output includes the -ljemalloc option then your Ruby is using the jemalloc library.

Replaced Components

Switching NTP from ntpd to chrony

It was decided that it is a good time now to switch the Network Time Protocol (NTP) implementation from ntpd to chrony as it is more secure, nicer and better. So also YaST has to adapt and modify its NTP client module to work with chrony. The module also shows its age and it is a bit hairy, so we took the opportunity to do some cleaning.

The most visible change is the UI on the running system. Please note that the UI is not final yet and it is mostly just a proof of concept. But the goals are clear: The first goal is to be really client only, as previously NTP also allowed to configure an NTP server, making the UI complex and confusing for the majority of users that just want to select a server to sync against. The second goal is to focus on the majority of users who want a simple UI to configure a common NTP client, leaving fine tuning for experts who modify configuration files directly.

In the installer, chrony is now called instead of ntpdate. This change is invisible to users and it simply works the same as previously.

We also decided to drop the command-line interface (CLI) of the NTP client module as chrony itself comes which a nice CLI chronyc. Instead of duplicating the work our CLI just suggests to use chronyc.

Please also note that changes are not finished yet and more will come. One of such changes is AutoYaST support, which is currently just skipped. But let us show you some pictures to get an idea how it will look soon in Tumbleweed and explain our decisions along the way:

The first image is from the main screen. It shows three main areas:

  1. The way the time is synchronized. It allows a pure manual run, synchronizing in a given interval or using the daemon that runs always.
  2. Configuration of sources for synchronization servers. It can be dynamic or static. For static, only the ones in the servers table (see point 3) are used. For dynamic, it also adds NTP servers from the network (like ones from DHCP). So when the user uses only public servers, the static configuration works well. But when internal NTP servers are used and they can change, then using the dynamic option makes sense.
  3. A list of synchronization servers. This specifies a statically defined list of NTP servers to sync against. You can use the familiar Add/Edit/Delete buttons.

The second image is from the Edit dialog. It was also simplified to the most common options. The Test button allows a quick check if a server is reachable and there are no typos in its address. The Quick Initial Sync option is useful to synchronize time quickly when connected to network. And Starting Offline is a nice chrony feature that allows to define the server as offline during the start-up and only when connected to the network to mark it as online and synchronize. It greatly helps with boot time and is a good option for notebooks where fast boot is important and the network is managed by Network Manager.

Firewalld will be the default firewall in SLE15 (Installer adapted)

Firewalld has some nice advantages over SuSEFirewall2: it can be dynamically managed, permits more zones, has a separation between runtime and permanent configuration options, it is well maintained, and it is already supported in some applications or libraries.

These are some of the main reasons why it has been decided to replace completely SuSEFirewall2 with firewalld.

In a past sprint report we announced that yast-firewall was adapted to support firewalld, but that was mainly an adaptation of the code to supporting both backends.

During this sprint we have completely replaced SuSEFirewall2 in the installer using a new firewalld API and although the UI seems to not have changed at all, the firewall dialogs have been completely reimplemented using CWM (our object-oriented API to YaST widgets).

During next sprints we will continue adapting the firewalld API and YaST modules to complete the replacement. The next target will be supporting firewalld in AutoYaST.

Storage

Expert Partitioner: Resizing

The Expert Partitioner has regained the ability to resize partitions. A Resize button is now available in the Hard Disks view as well as in the view of either a particular disk or a specific partition. When you try to resize a partition, a new dialog is shown with three options: maximum size, minimum size and custom size.

When the Custom Size option is selected, you have to specify manually the new partition size, but do not worry, the Expert Partitioner will prevent you from entering wrong sizes. Also, it will automatically align the partitions for a better performance.

Improvements in RAID management

As with partitions, it is now also possible to resize software RAIDs, although in the case of RAIDs resizing is a completely different operation performed by adding or removing devices to it. The partitioner will ensure you have selected the minimum amount of devices necessary for the current RAID type. Take into account that resizing a Software RAID will be only possible for new RAIDs being created, that is, resize action is not allowed when the RAID exists on disk.

As you can see in that screenshot, buttons for sorting the devices within a RAID have also been added at the right of the device list during this sprint. Those buttons are available both when creating a new RAID and when resizing it.

Last but not least, now it is also possible to work with BIOS RAIDs in the same way you do with regular disks. You will find all BIOS RAIDs in the Hard Disks section of the Expert Partitioner, where you could add or remove partition to the RAID device.

Software Modules and Extensions

The SLE15 products were split into several repositories and the installation medium contains only the minimal set of packages required to boot the system. If you want to have something more then you have to either register the system or use an additional medium.

To make that easier for users the registration module now pre-selects the recommended modules or extensions. However, if you for some reason really need a minimal system you can still deselect the pre-selected items.

The list of recommended addons is maintained at the server side (SCC) so it is possible to change that without updating the YaST installer.

Adding Modules and Extensions in AutoYaST

The list of available modules and extensions for SLE15 is already quite long as the base SLE15 products have been split into several modules. That makes adding the modules from the registration server more complicated compared to SLE12.

Originally the AutoYaST registered the addons in the XML profile exactly in the specified order. And that made troubles because SCC requires the dependent modules to be registered first. Writing the modules in the correct registration order in the profile was not easy for SLE15.

To make it easier AutoYaST now automatically reorders the modules according to their dependencies and even registers the dependent modules which are missing in the profile. Obviously that works well only if the missing module does not require a registration key.

mksusecd and linuxrc Supporting the New Media Layout

Starting with SLE15 the installation media have a slightly different layout. In short: the content file that was holding information about the product and a list of checksums is gone and has been replaced by .treeinfo and CHECKSUMS. Also, the package repository is now a repomd repository.

Also, SLE15 has been split into several so-called modules. The installation medium itself contains only a minimal set of packages. You have to register during the installation process to access other modules or use a separate medium containing them.

To save you from carrying several USB sticks around, mksusecd lets you build your own customized installation medium.

First, check what is on the media. The installation iso has just the base product:

mksusecd --list-repos SLE-15-Installer.iso
Repositories:
  SLES15 [15-0]

and you need an extra image for the modules:

# mksusecd --list-repos SLE-15-Packages.iso 
Repositories:
  Basesystem-Module [15-0]
  Desktop-Productivity-Module [15-0]
  Desktop-Applications-Module [15-0]
  Development-Tools-Module [15-0]
  HA-Module [15-0]
  HPC-Module [15-0]
  Legacy-Module [15-0]
  Public-Cloud-Module [15-0]
  SAP-Applications-Module [15-0]
  Server-Applications-Module [15-0]

Then pick the modules you want to add to the installation medium:

mksusecd --create new.iso \
  --include-repos Basesystem-Module,Legacy-Module \
  SLE-15-Installer.iso SLE-15-Packages.iso
Repositories:
  SLES15 [15-0]
  Basesystem-Module [15-0]
  Legacy-Module [15-0]
assuming repo-md sources
El-Torito legacy bootable (x86_64)
El-Torito UEFI bootable (x86_64)
building: 100%
calculating sha256...

Now use new.iso to start an installation.

Security / Development

Creating Reproducible Tarballs

We automatically submit the YaST packages from the Git repositories to the OBS projects using Jenkins. We use two Jenkins instances, the public Jenkins submits to openSUSE Factory/Tumbleweed, the internal Jenkins submits the same packages to SLE15.

The OBS compares the SLE15 packages with the openSUSE version to make sure the same packages are built in both projects. But this check compares only the file checksums, not the archive content.

The problem was that the internal and external Jenkins created a tarball with different checksum although the files inside were exactly same. If you run simple tar cfjv archive.tar.bz2 files you will find out that the tarball checksum is different for each run. So how to create a tarball in a reproducible way?

To build a reproducible tarball we use these tar options:

  • --owner=root --group=root – to make sure the file owner and the group is always the same, it does not matter who builds the tarball or who owns the files on the system
  • --mtime=<timestamp> – to have constant file time stamps, it does not matter when you downloaded the source files. Having fixed time stamps (like 0) is not a good idea as you do not know how the files are old actually, but using the current time makes the tarball not reproducible. So we use the date of the last commit in the Git repository (git show -s --format=%ci), it is stable across multiple runs and still describes how old the files are.
  • --format=gnu – use the GNU tar format, the default POSIX format contains some archive time stamps
  • --null --files-from - – this tells tar to read the file names from standard input, we use this options together with find ... -print0 | LC_ALL=C sort -z to sort the files to always have the very same file order.

Note: it also depends which compression method you use for compressing the tarball. For example gzip by default also adds some time stamps to the archive, bzip2 does not. If you want to use gzip then use the -n option.

See the tarball Rake task for the implementation details.

AutoYaST supports root SSH Authorized Keys deployment

From a security point of view, it is recommended to use SSH for logging into a remote machine instead of user and password in plain text format. But having to memorize the user and password specially if you try to use a strong non predictable password is also hard and hard to maintain.

For that reason SSH provides authentication based on public key cryptography and AutoYaST supports the deployment of SSH Authorized keys for normal users since SLE-12-SP2 but it was not working for the root user.

We have fixed this issue in SLES-12-SP3 allowing to deploy the SSH authorized keys also for the root user and exporting them into the cloned system profile.

AutoYaST keeps improving

The storage-ng based AutoYaST version has received a couple of improvements like, for instance, an improved resizing handling (supporting logical volumes) or multipath support. Additionally, we’ve squashed some bugs, like setting size=max for LVs (bsc#1070131) or some problems when not defining any partition (bsc#1070790 and bsc#1065061).

But even more interesting is the fact that we have brought back a hidden (and undocumented) feature. Did you know that if you set the <device/> element to ask, AutoYaST will ask you about which device to use for installation? Cool, right? This feature will continue working in (open)SUSE 15 and now it is documented!

Conclusion

My colleagues are telling me that practicing Scrum may be getting just ever so slightly on my nerves because I have several bugs in my description of the St. Nicholas tradition. Surely they are wrong. Stay tuned for the next report from a new and improved Scrum team: Ježíšek, Santa, und das Christkind.

Highlights of YaST Development Sprint 46

November 10th, 2017 by

It’s Hack Week time at SUSE! But before we dive into all kind of crazyinnovative experiments, let’s take a look to what we achieved during the latest development sprint.

User-friendly error messages in AutoYaST

During recent weeks, the AutoYaST version for the upcoming SLE 15 family has received quite some love regarding the integration with the new storage layer, from fixing bugs to adding some missing (and even some new) features. So let’s have a look at what we have done so far.

First of all, a new error reporting mechanism will debut in the upcoming AutoYaST version. Until now, when a problem occurred during partitioning, you got a message like “Error while configuring partitions. Try again.“. It does not help at all, right? At that point, you were on your own to find out the problem.

Now AutoYaST is able to identify and report different problems to the user in a convenient way. What is more, in many situations it is even able to point to the offending section of the AutoYaST profile.

The error reporting mechanism can distinguish between two different kind of issues: warnings and errors. When a warning is detected, a message is shown to the user but the installation will not be stopped (it honors the settings in the <reporting> section). Errors, on the other hand, will block the installation entirely.

Please, bear in mind that this error reporting mechanism is only available for the <partitioning> section. Maybe it could be extended in the future to cover other parts of the auto-installation process.

Bringing back skip lists to AutoYaST partitioning

When defining a partitioning schema, you can let AutoYaST decide which device should be used for installation. Thanks to that, you can use the same profile to install machines with, for instance, different storage devices kernel names (like /dev/sda and /dev/vda).

Needless to say that, in such a situation, we might want to influence the decision process. For example, we would like to avoid considering USB devices for installation. AutoYaST offers a feature known as skip lists which allow the user to filter out devices using properties like name, driver, size, etc.

Unfortunately, skip lists support in SLE 15 Beta1 is rather limited. But these days we have extended yast2-storage-ng to offer additional hardware information and now AutoYaST is able to use it to filter devices.

As a side effect, the ayast_probe client has been fixed to show (again) which keys you can use in your skip lists.

More on AutoYaST

Apart of adding or bringing back features, we have fixed several bugs. You can check the recent entries in the yast2-storage-ng changes file if you are interested in the details.

We know that a few features are still missing and more bugs should be addressed sooner or later, but hopefully AutoYaST must work in most use cases.

SLE15 media based upgrade for unregistered system

This sprint we also continued implementing the upgrade from SUSE Linux Enterprise (SLE) 12 products to the version 15. Particularly we solved the upgrade of unregistered systems.

In that case you need the “SLE15 Installer” medium and additionally also the “SLE 15 Packages” medium. The installer medium contains only the minimal packages for installing just a very minimal system. The rest is available either via the registration server or via the extra medium. Obviously for unregistered systems only the second option makes sense.

In this sprint we were focused on making all pieces to work together. You can see the result in the following screencast.

Upgrading an unregistered system

Fixed an installer crash in systems with 512MB RAM

We got a bug report that the beta version of the upcoming SUSE Linux Enterprise Server 15 was sometimes crashing during installation on a system with 512MB RAM. That’s bad, the 512MB is a required limit which should be enough to install a minimal system in text mode.

At first we thought that the crash was caused by insufficient memory, but the reported memory usage was OK, there was still enough free memory.

It turned out that the problem was in the pkg-bindings which tried to evaluate undefined callback function. The fix was quite simple, however, the question was why that happened only in systems with 512MB RAM and not when there was more memory.

Later we found out that the difference was caused by the extra inst-sys cleanup (mentioned in the Sprint 22 report) which YaST runs when there is low memory. In that case YaST removed the libzypp raw repository metadata cache. The assumption was that when the data is already parsed and cached in the binary solv cache the original files are not needed anymore. However, libzypp still might use some raw files later.

So we changed the inst-sys cleanup algorithm to remove only the files which we know are not needed later and keep the rest untouched.

Expert partitioner: the some boys are back in town

Several features have been brought back to the expert partitioner during this sprint.

  • Allow to create and delete logical volumes.
  • Allow to delete MD RAIDs.
  • Allow to work with multipath devices.

Now you can create logical volumes using the expert partitioner. When you go to the LVM overview or visit a specific volume group, a button for adding a logical volume is available. Clicking on it, you will be taken through a wizard for the creation of a logical volume. Note that although the logical volume type can be selected in the first wizard step, only normal volumes can be created. Thin logical volumes and thin pools will come soon. And apart of creating logical volumes, now there is also a button for deleting them.

LVM management in the reimplemented partitioner

Creating an LVM LV in the reimplemented partitioner

Deleting an LVM LV in the reimplemented partitioner

Delete action has been also implemented for MD RAIDs. For that reason, you have a delete button in the RAID overview and also when you access to a specific MD RAID. And of course, you will be asked for confirmation before removing the device.

Deleting an MD RAID in the reimplemented partitioner

Additionally, another important feature recovered during this sprint is the possibility to work with multipath devices. Now, multipaths are listed together with other disks in the tree view of the expert partitioner, allowing you to manage them as regular disks. For example, you can create or remove partitions over them. Moreover, when a multipath device is selected, a new tab is showed to list the so-called “wires” that belong to the multipath.

Multipath devices in the reimplemented partitioner

Improving the product upgrade workflow

Although the possibility to offer an upgrade option from openSUSE Leap to SLE is on both SUSE and openSUSE radars for the future, the reality is that it has been, and still is, an unsupported scenario.

But with previous versions of SUSE Linux Enterprise, you could take a SLES DVD, boot it in the Upgrade mode, and select to upgrade an openSUSE partition. YaST would let you proceed several screens before telling you that it actually will not let you upgrade from openSUSE to SLES.

Starting with recent SLE15 pre-releases, the incompatible products are filtered out in the partition selector already (overridable with a Show All Partitions checkbox), letting you know earlier whether you will be able to upgrade your system to the new SLES.

Fix of a registration issue during installation process

In SLE 15 Installer, there is a product selection dialog at the very beginning of the installation. After that, you can register the selected product but you cannot change the product later as unregistering the product and registering another one is not supported. Our awesome QA squad found out that when the installation was aborted and then started again from Linuxrc without rebooting, the installer thought that the product had been already selected and did not offer any product for installation. A little fix made it work again – now we always execute the following SUSEConnect command at the start of the installer.

SUSEConnect --cleanup

That removes all traces of previous registration attempts from the Installer. This also means that you might still want to unregister directly at SUSE Customer Center if needed.

Improving help texts in the registration process

As you have seen so far, we have been working hard to polish the registration experience in many aspects and scenarios. That also includes a better communication with the user. Thus, the help text in the registration module has been improved to also include the description of the check box states. This is especially important for the “auto selected” state which is specific to this dialog and is not used anywhere else.

The help texts in YaST use an HTML subset which allows also including images. In this case we included the check box images directly from the UI stylesheet. But in the text mode we have to use text replacement instead of the images. That means the help text content must be created dynamically depending on the current UI.

Here you can see examples of both interfaces.

The graphical version of the new registration message

Text-based version of the new registration message

Twisting the storage proposal: this time for real

In our report of sprint 42 (to be precise, in the section titled “Twisting the storage proposal”) we presented our plans to make the software proposal more customizable in a per-product basis and the draft document of the new format for control.xml that would allow release managers to define the installer behavior in that regard.

Now this goes further than a mere specification and the new format is actually being used to define the partitioning proposal of both the KVM/Xen role of SUSE Linux Enterprise 15 and the upcoming SLE15-based CaaSP.

In the following screenshot you can see the corresponding step of the guided setup for the mentioned KVM/Xen role, in which the classical controls for the /home and Swap partitions have been replaced by more goal-specific volumes defined in the section of the control file describing the role.

Partitioning configuration for the KVM/Xen role

And, as you can see below, the installer now honors those settings to propose a reasonable partition layout.

Storage proposal for the KVM/Xen role

The new format and the corresponding implementation of both the logic and the UI are flexible enough to empower the release managers to define all kind of products and to make possible for everybody to create a more customized derivative of openSUSE without renouncing to the power of the automatic proposal. See another example below (not corresponding to any product or derivative planned in the short term) with more possibilities and note how the wording was automatically adapted to talk about LVM volumes instead of partitions, based on the user choice in a previous step.

LVM-based example of the new proposal

Replacing ntpd with Chrony in yast2 ntp client

Chrony will replace the classical ntpd as default NTP client starting with SLE15 and openSUSE Leap 15. That will offer several advantages to system administrators and other users, as can be seen in this comparison. In order to make this replacement possible, we started a research to find out what is supported in Chrony and how to allow our users to configure it through YaST.

The research phase is now complete and we have already a plan to proceed with the adaptation of the existing yast2-ntp-client module. Also a few bits of code, which allows to set the NTP service during installation, are now in a feature branch (so not yet in Tumbleweed).

The next step will be a huge improvement (and simplification) of the YaST module, which will go further than adapting a list of options. In the screenshot below you can see the not yet finished prototype in action.

Configuring the keyboard in the installer via systemd

Originally the keyboard configuration was written directly by YaST in the corresponding Systemd-related configuration files. But we got a bug report that YaST should not touch the config directly and rather call the localectl tool for changing it. (See the details in the localectl man page).

However, this works only in the installed system, it does not work in the system installation as it needs a running Systemd that is not available during the installation process. Changing the setting for a not running system must be done using the systemd-firstboot command.

But this did not supported modifying the keyboard settings. Fortunately one of the SUSE developer helped us and implemented this feature to Systemd (pull request). Currently the feature is available in (open)SUSE packages but later it will be available in the upstream release for others.

Another related change was that YaST not only set the console keyboard but also constructed the keyboard settings for X11 (GUI). But this is actually a duplicated functionality, localectl itself includes this feature. So we have removed it from YaST and let the localectl tool to set both keyboard setting automatically.

And now for something completely different

Hack Week 0x10 (that is, the 16th edition) is starting just right now. Which means most developers of the YaST team will spend a week working on topics that may or may not have a direct and visible impact in our beloved users in the short term. But hey, maybe we will build a robot or a space rocket!

After that week, we will restart our Scrum activity. So if nothing goes wrong, you will have another update about the YaST development in approximately four weeks. Meanwhile, join us at Hack Week and let’s have a lot of fun together!

Highlights of YaST Development Sprint 45

October 25th, 2017 by

The wait is over: finally a new YaST team report, with news about our 45th sprint!
Our team is still focused on the development of the upcoming SUSE Linux Enterprise (SLE) 15 products family and openSUSE Leap 15, which in this sprint resulted in new dialogs to select modules and extensions, changes for the multi-product medium, and fixes for issues that have been found during our development phase. So let’s check out the most interesting things that came out of our last sprint.

New Modules/Extensions Selection

SLE has a specific dialog that allows the user to select additional modules or extensions. When we first introduced this selection dialog, the extensions could have only a single dependency, which resulted in a maximum of only two levels of dependency. During this last sprint, we implemented changes to allow a chain of dependencies. You can check on the image below this new selection dialog in action:

Reliable Self Update for Multi Product medium

Until now, the self-update URL depends on the product which is ship in the medium. However, as you may know, SLE 15 product family will be shipped in a multi-product installation medium. For that reason, sometimes self-update was failing as only a single product is defined in SCC.
Now we have fixed this issue by a defining self-update identifier that is used instead of a product name, which allows the self-update feature to work in a reliable way.

Welcome screen adapted for upgrading

Some sprints ago we announced the addition of product selection to the initial screen for LeanOS installer.

The welcome dialog is shared between different workflows like between installation and upgrading. The problem is that for upgrading we need to find the target system or root partition before selecting the product to migrate. Now it does not require any selection if there are no products to select, so it will work when upgrading. Besides that, we have polished some presentation details like the dialog title and the product selector caption.

Check out the screenshots below to see the final result:

LeanOS:

Tumbleweed:

Unavailable Packages in AutoYaST

AutoYaST needs to make sure that, after rebooting into the 2nd stage (when needed), the user can access to the installation process using the same tools that he/she used during the 1st installation stage. Apart AutoYaST packages it self, it may need to install other additional tools like VNC, SSH or the X.org system.

Unfortunately, as SLE 15 is split into modules, it’s not guaranteed that the VNC, SSH or X.org packages can be installed, which resulted in AutoYaST failing when trying to install those packages.

We have improved the package handling and now YaST displays a warning that the packages are missing and the system (and later the installer) could not be accessed as expected. However, the AutoYaST installation can still proceed although you cannot watch AutoYaST running during 2nd stage.

Improved Handling of Multi-repository Media

We got some bug reports about the new multi-repository media handling in YaST (mentioned in the sprint 43 report). Some of the problems were delegated to the underlying libzypp library, but we got our share of real YaST issues.

One of those problems was, for instance, the inconsistent styling of the MultiSelectionBox widget used in that dialog, which was pretty confusing. Fortunately, the issue has been fixed and now it looks the same than any standard checkbox widget.

More to come

The 46th sprint has already started and has many new items planned to be developed, especially for the SLE15 and openSUSE Leap 15 installer. We are looking forward to bring these planned features to life and tell you about all the details of this sprint. Meanwhile, have fun and stay tuned!

Highlights of YaST Development Sprint 42

September 7th, 2017 by

Kids started school in Prague, and we’re energized to bring you news from the YaST team.

This sprint we made progress in:

  • selecting one of several products to present on a DVD
  • adapting to the switch to the rpm-md package metadata format, regarding licenses and the Beta notice
  • notifying about not being able to support ReiserFS also in the case of an upgrade via AutoYaST
  • not reporting missing optional patterns

As always, the new storage stack deserves a separate section.

  • Expert partitioner has a better initial summary and it handles Btrfs subvolumes better.
  • Snapper can create and restore snapshots now.
  • A more flexible installation proposal is being developed.
  • It has landed in SLE15/Leap15 already.

Selecting the base product in the first screen

As we reported three sprints ago, YaST will support having multiple products on the same installation medium. This feature will allow to ship several SUSE products on the same DVD asking the user which one to install.

But, as an (open)SUSE user, you may know that the first screen of the installer allows you to select the language/keyboard and, additionally, it shows the product’s license. But which license should we show for multi-product media?

After asking our UX expert, we decided to allow the selection of the product in the welcome screen as you can see in the image below.

Obviously, this behavior applies only to multi-product medias. When using a single product one, the license is shown directly in the welcome screen.

Finally, as developers, we would like to highlight that we mainly re-implemented the welcome screen using modern YaST techniques (like our object-oriented API to YaST widgets), improving test coverage and code quality.

Getting licenses from repositories

In the sprint 40 report, we announced that YaST was dropping support for SUSE tags because the plan is to use RPM metadata and packages to store all that information (licenses, release notes, etc.).

During this sprint (and the previous one) we focused on improving how base product licenses are handled. Until now, licenses lived in a tarball which was included in the installation media. But that is not the case anymore: now YaST relies on (the awesome) libzypp to get products licenses directly from the repositories. There are still some rough edges: for instance, multi-language support should be improved, but we will tackle them pretty soon.

Finally, bear in mind that only base product licenses have been adapted, but we plan to do basically the same for modules, extensions and add-ons.

Updated README.BETA Support

The YaST installer supports displaying the README.BETA file from the installation medium. This file is added during Beta phase so the users know this is not the final release. This is also useful after the final product is released if you by mistake boot the old medium.

Unfortunately the original YaST code supported only the so called SUSE-Tags repository format which was used for the CD/DVD media. However, the new SUSE Linux Enterprise media will use the RPM-MD format which is something completely different.

In this sprint we have added the support for the RPM-MD format and additionally we display the Beta warning popup also in the AutoYaST installations. Of course, blocking AutoYaST with a popup would be a bad idea so in the AutoYaST mode the popup is automatically closed after a timeout. (The default is 10 seconds but can be configured in the XML profile.)

Drop support for ReiserFS autoupgrade

The drop of ReiserFS support for manual installation was announced in our last post, and now is the turn to autoupgrades.

With SUSE Linux Enterprise 15 the autoupgrade will be blocked in case of ReiserFS presence were detected suggesting a manual conversion to another filesystem.

Software proposal does not report missing optional patterns

YaST guides you through the installation process of your system making you a proposal based on the different selections like the product, addons, system role, desktop etc.

This proposal contains some software patterns that are mandatory and some that are optional but only the mandatory ones will be reported when the proposal is shown.

During this sprint we solved a bug which reported not only missing mandatory patterns but also optional ones.

The Storage Stack (storage-ng)

Storage reimplementation: Expert Partitioner

As you probably already know, in the YaST team we are rewriting our powerful expert partitioner tool from scratch to adapt it to the new storage layer. Sprint by sprint we are bringing back some of the many great features the expert partitioner offers, and this time it will not be different.

Now, when entering to the expert partitioner, all available storage devices are presented in an initial summary. Moreover, in this first screen you could find an option to rescan your devices, which allows the expert partitioner to be aware about the changes in your system, for example when you plug in a USB stick.

The management of Btrfs subvolumes was also improved during this sprint. Now, you will be alerted when a new subvolume is shadowed by an existing mount point. Moreover, some subvolumes could be automatically deleted or created when a mount point changes in the system.

Snapper can snap again

We reintroduced one of the most important features about using Btrfs: Being able to create snapshots, so you can go back to a previous state of the system if anything went wrong during a package upgrade or when you changed anything about your system configuration. This means we are now again setting up and configuring snapper correctly, installing everything into a subvolume and creating an initial snapshot when the installation is complete.

Why install into a subvolume in the first place? When snapshots are made in the future (e.g., during package upgrade or installation) and at some point you decide to roll back to one of those snapshots, you might want to delete previous snapshots to save disk space. If we didn’t install into a subvolume, the initial files would always be left over and consume disk space, so there would be a considerable resource leak.

Twisting the storage proposal

As you should know, one important part of the rewritten storage stack is the partitioning proposal. The old one was designed with a rather narrow scope in mind. Targeting desktops and old-school servers, it always proposes a root file-system, a swap volume and an optional separate /home. That’s not the most useful schema for new innovative products with a different focus like SUSE CaaS Platform, openSUSE Kubic, SUSE Manager, etc.

As we remind quite often, all the products supported by YaST (SLES, SLED, Leap, Tumbleweed, Kubic, CaaSP, SUSE Manager, SLES4SAP, you name it) share an identical installer. That installer is fully configurable using the file control.xml that is included in the media and that allows to define the sequence of installer steps, the default values and much more.

One of the goals of the new storage proposal is to give product creators and release managers more freedom and flexibility configuring the behavior of the guided setup. And for that we need a better format for control.xml, so they can express themselves with fewer limitations.

Of course, that new format is not something for the YaST team do decide on its own, but something being designed openly in collaboration with all the involved parties. To make easier for anyone to jump into the subject we have prepared this detailed document which includes all the present and historical information to understand the topic, as well as an explanation of the new format with several examples based on existing or hypothetical use cases.

As everything in YaST, that document is alive and expected to continue changing and evolving based on everybody’s feedback and contributions. So feel free to take a look and suggest improvements or future use cases we may have overlooked.

The storage stack is dead, long live the storage stack

In our previous sprint report we told you we were working to integrate the new storage stack into the future SLE15 and openSUSE Leap 15 codebase. Now the submission process is over and the preliminary images of both future distributions are fully based on libstorage-ng. For openSUSE Tumbleweed, that is the Staging:E project. That means we now have many more eyes looking into it, finding bugs, pointing what is missing and providing feedback about the new behavior. Of course, every couple of eyes comes with a little bit more of pressure for the YaST Team to get things done as soon as possible, but also with a pair of hands to help us getting there.

Highlights of YaST development sprint 41

August 24th, 2017 by

We all know that everything slows down in summertime and software development is not an exception. But heat is not enough to stop the YaST team from turning the Scrum wheel and delivering the corresponding sprint reports. Let’s take a look to what we have been doing the last two weeks.

The storage reimplementation gets on the launchpad

As already anticipated in the previous report, one of the goals of this sprint was to merge the new storage stack into the codebase of SUSE Linux Enterprise 15 and openSUSE Leap 15. That implies submitting everything to Factory first and making sure the result looks harmless and good enough there. Thanks to the awesome openSUSE tools and processes, that kind of experiments can be isolated in a dedicated staging project allowing us to reach useful conclusions without risking the stability and features of Tumbleweed.

So we submitted two new source packages libstorage-ng and yast2-storage-ng to Factory, together with new versions of all the affected packages (already adapted to use the new system, instead of the old yast2-storage) and a modified version of the list of packages to be used during installation.

Everything was mixed and cooked in the Staging:E project and… guess what! We got brand new Factory ISOs with storage-ng, successfully building and verified to work by openQA, as you can see in this screenshot of the Staging Dashboard.

Storage-NG in the Staging Dashboard

Yes, we know there are two failing tests in that dashboard, but that was fully expected since those tests use the expert partitioner to configure an installation of openSUSE on top of a MD RAID system and the reimplemented partitioner still lacks some controls to configure MD RAID arrays.

The new stack will live in Factory:Staging:E (or any other staging project the Tumbleweed crew decides) for quite some time, until it’s feature-pair with the old storage layer and, thus, can progress further in its travel to Tumbleweed. But Factory was just the first stop, the ultimate goal of this sprint was getting into the preliminary versions of the next SLE and openSUSE Leap.

That second integration is taking a little bit longer because it has coincided on time with other important changes in the installer and the base system… and the fact that August is the typical European vacation period is not exactly helping to iron all the details out. But since the new storage system works for Factory, we are certain it will do it for SUSE Linux and Leap.

As readers familiar with the Tumbleweed development process may have noticed already, having all those packages in Staging:E implies that newer versions of them will only reach Tumbleweed all at once, when yast2-storage-ng is considered mature enough for that. Somehow, that will block us from delivering new features for the packages you see in the list in the mentioned image of the dashboard. But don’t worry, if something serious happens and a critical update is needed we will not let our beloved Tumbleweed users down.

But there is much more happening in YaSTland beyond the storage reimplementation. Let’s take a look to the improvements in other areas.

Installation without Grub packages

Sometimes, users have already Linux installed in their system and they do not want to install Grub in MBR again with a new Linux distribution since the installed Linux can manage the bootloader. For this case, the user may decide to not install grub packages at all in the system. However, until now the user was obligated to install this package otherwise an error message would appear, as the image below shows.

YaST2-bootloader wrongly reporting about grub2 installation

For some specific scenarios, as you may find here, even other packages are required, and when the user decided for not installing the bootloader, these packages were still required for the installation.

We changed this behavior in Tumbleweed and SLE 15, and now the users will be able to install the system without the packages that are not required, in case they decide to manage bootloader through another operational system.

But that’s not the only improvement introduced in the bootloader management during this sprint.

Improve how YaST finds disk to install Grub in MBR

In Leap 42.3 and SLE 12.3, we found out that, in some very specific cases (check the bug report for more details), YaST was not finding the correct disk to install Grub in MBR. When it happened, an error message appeared at the end of the installation, showing that Grub could not be installed in /dev/btrfs disk.

Error during bootloader installation

We improved our approach to finding the correct MBR device, by adding a specific search for the disk where the partition /boot or / (in case /boot does not exist) is located.

Such a change will be released as maintenance update and self-update, and it affects only Leap 42.3 and SLE 12.3, since SLE 15 will use the new storage layer, which does not need this double check for the correct disk.

And talking about the new storage system…

Remove support for ReiserFS

The support of new installations with ReiserFS was removed from YaST in SUSE Linux Enterprise 12 and openSUSE Leap 42 but upgrades were still supported.

With SUSE Linux Enterprise 15 and Leap 15 the support of ReiserFS will be completely removed from YaST and the installer will block the upgrade of systems formatted with ReiserFS.

If some of the entries in the /etc/fstab file of the system to be upgraded is using ReiserFS, the installer will suggest to convert them to another filesystem type before migrating the system to SUSE Linux Enterprise 15 or openSUSE Leap 15.

Preexisting /opt formatted as ReiserFS

A similar blocking error will be reported for ReiserFS root partitions.

Updating a ReiserFS root system

Another Ruby 2.4 fix

This may be interesting for Ruby developers in general. We got a bug report about crashing YaST which in the end turned out to be caused by upgrade to Ruby 2.4. The tricky part was that YaST crashed randomly and it was difficult to reproduce the problem.

It turned out that the crash happened when Ruby wanted to print a warning on the error output, which in some situations failed. We did not fix the race condition, as it likely would be too difficult to debug the Ruby internals, but we at least fixed the code to not produce the warnings anymore.

So if you are a Ruby developer take this free advise from your YaST fellows – if your code crashes randomly with Ruby 2.4 then check for the Ruby warnings first.

A heads-up about network devices names

Two sprints ago we told you about the new possibility of configuring the network with AutoYaST already in the first stage, avoiding an extra restart of the system in most cases.

During this sprint we spent some time trying to test old AutoYaST profiles (with complex network configurations) with the upcoming version of SUSE Linux Enterprise Server, using our suite of automatic AutoYaST Integration Tests. But we found some issues caused by the current architecture of our test suite that may be of interest for some of our readers.

Let’s see some technical background first.

Tumbleweed has been using ‘predictable network interface names’ for some time now and it fits most regular use cases. Inspired or following the scheme idea introduced by ‘biosdevname’, Predictable Network Interface Names was adopted in systemd/udev v197 trying to solve an historical problem with the non deterministic classic naming scheme for network interfaces (eth0, eth1, eth2 …)

Basically it will assign fixed names based on firmware, topology, and location information making them stable between system reboots, hardware additions or removals and also between kernel or drivers updates.

For the upcoming SLE15, we are giving predictable network interface names a try (they are disabled in SLE12 and openSUSE Leap 42.x). For us that turned to be a problem because our AutoYaST testsuite dynamically creates new virtual machines on every system reboot (instead of really rebooting the virtual machine created in the previous step). So from the point of view of the operating system being tested, all the network devices are replaced by new ones in every reboot and that drives the network settings nuts.

That was only our case (arguably “our fault”), but there might be other situations in which going back to the old naming scheme (with names like ‘eth0’) would be more convenient than adapting the preexisting AutoYaST profiles to the new one. In such cases you still can use the old scheme (not fully predictable but very well known by Linux veterans) by just booting the SLE15 installation with this parameters.

biosdevname=0 net.ifnames=0

Disabling predictable network names in SLE15

More to come

In addition to everything reported in this post, we have been working hard to get some new cool features to the upcoming SLE15 and to get the storage reimplementation full-featured enough to substitute the old one in all possible situations.

So, although it would still be summertime (in Europe), stay tuned for more news in two weeks.

Highlights of YaST development sprint 40

August 10th, 2017 by

Doubtlessly, these are pretty exciting times for the YaST team. The merge of the new storage layer into the main codebase is around the corner and we are working on other features that will debut on the next open(SUSE) major release. So let’s summarize what happened during the last sprint.

New storage layer is coming

As you may already know, the YaST team has invested a lot of time and effort preparing our storage layer for the future and we have started to merge the new layer into the main code base during the current sprint. But that’s something for our next report, right? By now, we will just focus on the stuff that got added and fixed during the last two weeks.

Storage reimplementation: BIOS RAID support

libstorage-ng, the low level library in which our new storage layer relies on, got support for BIOS RAID (handled in Linux via MD devices). Now, YaST could take advantage of such a feature to allow the installation of open(SUSE) systems on this kind of devices, including the bootloader.

BIOS RAID support

Storage reimplementation: managing BtrFS subvolumes in new Expert Partitioner

The new Expert Partitioner is getting a lot of attention these days and, during sprint 40, it got initial support for Btrfs subvolumes management.

Btrfs subvolumes list

Now, when you select the BtrFS section in the general menu placed on the left, all BtrFS filesystems are presented allowing you to edit its subvolumes through a dialog which contains the list of subvolumes that belongs to the filesystem. Apart from the usual stuff, like adding and deleting subvolumes, it is also possible to set the noCoW property when you are creating a new one.

Adding/Removing Btrfs subvolumes

However, some features are still missing. For instance the partitioner will not prevent you to create a subvolume which is shadowed by an already existing mount point. Consider the current implementation as the first step towards a really cool Btrfs subvolume handling.

Dropping SUSE tags support

During installation, YaST uses a mechanism known as SUSE tags as source of information for media handling. For instance, a /content file contains information about the product, languages, etc. Additionally, information like release notes or the slide-show texts are stored in the installation media.

Some time ago, SUSE decided to drop SUSE tags and use RPM metadata and packages to store all that information. To make it possible, the installation media would use REPOMD repositories.

Obviously, YaST needs some adaptation. As a first step, support for the /content has been dropped, cleaning up some old and even unused code.

In the upcoming sprints, YaST will be adapted to retrieve licensing, release notes, etc. from RPM repositories and packages, which is also an opportunity to do some refactoring and to improve test coverage.

AutoYaST support for add-on products on same installation media

Nowadays YaST supports having add-on products on the same media than the base product. The problem is that the EULA for those products is displayed too early, even before AutoYaST had been initialized at all.

To solve this issue, now the EULA acceptance of included add-ons is performed at the same time than other add-ons which are not included in the installation media. As a side effect, now the user needs to define those add-ons on the AutoYaST profile in order to handle the EULA acceptance.

Bug squashing and 80×24 terminals

As developers, we enjoy working on new features and, of course, we are committed to fix critical bugs as fast as possible. But there are many small (and annoying) bugs out there that deserve our attention. Additionally, there are several bug reports that are no longer valid (the bug was fixed, it is not reproducible, it is a duplicate, the affected product is not supported anymore, etc.). In order to reduce the list of open issues, the team decided some sprints ago to reserve one day to do some bug squashing.

Among the bugs we closed during this sprint, we would like to highlight a usability problem in YaST services manager. Bear in mind that, along with the graphical interface, YaST ships a text based one which is supposed to fit in good old-fashioned 80×24 terminals. That’s an interesting constraint when you are designing interfaces for YaST.

Needlessly to say that, from time to time, we get a bug report about some element that just do not fit. In this case, YaST services manager had a problem when the service name was too long as you can see in the screenshot below.

Too long service name

Now, if there is not enough space, the name will be truncated and the rest of the information will be shown in an proper way.

Truncating a too long service name

Do not miss the next report!

As you may have noticed, a lot of interesting things are currently happening in the YaST world and more cool stuff is about to come. So you should not miss our next sprint report.

By now, enjoy openSUSE 42.3 (you already upgraded your system, right?) and see you in two weeks.

Highlights of YaST development sprint 39

July 31st, 2017 by

openSUSE 42.3 is out! Do you need some reading material while you wait for the download of the new release to finish? Don’t worry, we have the solution right here – another YaST team report. 😉

Several products in one installation medium

Obviously, we stopped adding new features to SLE12-SP3 and Leap 42.3 some days ago, because everything needed to be tested properly before the release. So now we are mainly looking into the future. And one of the plans for that future regarding SUSE Linux Enterprise (SLE) is offering several products packed in a single installation medium.

SUSE offers several mission-specific products based on SLE and, so far, every product needs to be installed from its own medium (usually a DVD or a virtual image). So if you use SLE Server, SLE Desktop and SLE Server for SAP, you have to have three DVDs which is a bit cumbersome.

After some discussions about the technical implementation details, we created a first prototype of the installer with an extra dialog that allows to select one of the detected products and continues the installation from there according to the installation workflow of the chosen product. It is still a proof of concept, but we can at least share screenshots showing how it looks for the time being.

The new product selection screen

So far, there are no plans to use the new feature in openSUSE, mainly because the project does not deliver separate mission-specific products in the same way than SUSE does with SUSE Linux Enterprise.

Storage reimplementation: numbers after repatriating the Expert Partitioner

In the Sprint 36 report we presented the rewrite of the YaST Partitioner and we have been informing about its evolution in subsequent reports. We told you back then that we decided to split it in a separate yast2-partitioner package. But time has proved that decision to have too many drawbacks so we decided to bring the Partitioner back home, to yast2-storage-ng. As part of the process, we got rid of an old previous prototype of the Partitioner that was still lying in the yast2-storage-ng repository and some code that was there just to support that old prototype.

You may be asking why is all that relevant. It is because that means the repository (and thus the package) is finally approaching the final structure it will have when released into Tumbleweed. And that implies that all the systems we use to automatically measure the quality and reliability of our repositories are now providing trustworthy results… as trustworthy as automatic quality evaluations can be.

And according to those tools:

  • 93% of the code in yast2-storage-ng is covered with automated unit tests in addition to openQA (this number is expected to raise in close future as we polish the new Partitioner),
  • Code Climate reports a code quality GPA of 3.91 out of a possible maximum of 4
  • and 76% of all the classes, modules and functions, including the internal ones, are properly documented (with that developer documentation being available here, by the way).

If you wonder about the numbers for the old codebase we want to replace, its code quality is 0.94 and only a 31% of it is covered by unit tests. A perfect example of legacy code.

Storage reimplementation: Btrfs subvolumes in AutoYaST

As reported in previous posts, the new storage stack can already process AutoYaST profiles including partitions, LVM and MD arrays, but some details are still missing. The first of those details we wanted to address was the definition and creation of subvolumes in a Btrfs file-system.

Now it works according to the official documentation – both syntaxes for the <subvolumes> section are supported, it never creates subvolumes that would be shadowed by any other mounted file-system and it uses the list in control.xml as fallback for the root partition if Btrfs is used but subvolumes are not specified.

All that, as usual in the re-implemented stack, with fully tested and documented code.

Btrfs subvolumes support in AutoYaST

Storage reimplementation: handle multipath I/O in the proposal

In the previous report we showed you how the support for Multipath I/O looked at the library level, which usually means just geeky graphs. During this sprint, we have taught the installer to use that new library feature, so we now have real screenshots to show!

During the installation, now multipath hardware is detected and the user is asked for activation.

Popup for activating Multipath I/O

If the user agrees, the installer will never use the individual disk devices to propose a partitioning layout and it will not offer them as an option during the guided setup. The installer always works on the final (compound) multipath device, proposing the correct names for the partitions and so on (which, being a devicemapper device, follows a
different pattern when compared to raw devices).

Suggested partitioning with multipath

The resulting system is still not fully bootable because yast2-bootloader has still not been adapted to this scenario. Very likely, something for the upcoming sprint, so stay tuned.

Support for Ruby 2.4

The world changes every day and we are always adapting YaST to remain shiny. The 2.4 version of Ruby is about to land in openSUSE Tumbleweed and is expected to be the default Ruby for SUSE Linux Enterprise 15 and openSUSE Leap 15. We found that some of the YaST packages were not fully ready for this new Ruby, so it was time for some tweaking.

After dealing with quite some details too technical and boring for this blog (but feel free to ask if you want the gory bits), YaST is shining again in Factory, which means we are no longer blocking the adoption of Ruby 2.4 in Tumbleweed.

Add-on Creator and Product Creator

As our team keeps always developing new features, solving bugs, and receiving feedback, we always evaluate our priorities and product. Sometimes, during this evaluation, we see that some YaST modules do not bring enough value or do not shine enough as part of our standard package.

After some evaluation, we come to announce that the modules Add-on Creator and Product Creator will no longer be part of YaST. These packages use Kiwi as backend and we have high competition on UI sides – SUSE Studio and Open Build Service. So it no longer makes sense to have these packages and we recommend for users of these modules to use one of the alternatives or Kiwi directly if you already have an XML definition file for Kiwi.

Adapting YaST to accept 12 digits Service Request Number

As Service Request Numbers can be now composed of 11 or 12 digits, instead of only 11 digits as before, we had to adapt YaST to handle this change. YaST module Support can now accept 11 or 12 digit service request numbers. We implemented such a change for all products dating back from SLE 10 SP3 until the most recent SUSE Linux versions. Updates with this change will be soon released.

Network Setup in the 1st Stage of Autoinstallation

The YaST installation used to have two stages, separated by a reboot. Starting with SLE 12 and openSUSE Leap 42.1 we have eliminated the
second stage. But it was still needed for AutoYaST, controlled by the setting

<profile><general><mode><second_stage>true | false</...>

We have fixed those parts of the networking setup and now you can explicitly set AutoYaST to not use a second stage anymore.

User settings in AutoYaST

An issue that we have found out is that GDM has problems with the system when different users have the same UIDs. If it happens, GDM does not start properly. As a solution, we decided that either UIDs will be defined in the AutoYaST configuration file for ALL users or this tag will not be used at all for ALL users since a mix of both can result into duplicate UIDs.

And we just keep YaSTing!

We hope you liked our report as much as we loved to build all of that. We’ll continue YaSTing so we can reach you again in two weeks with much more cool stuff to show.

By now, enjoy your openSUSE 42.3 and all the cool features that came with it!

Highlights of YaST development sprint 38

July 14th, 2017 by

Here we go again with a new report from the YaST trenches. This time with the storage reimplementation as the clear star of the show.

Storage reimplementation: the proposal adapts, you succeed

As we have announced in our previous sprints and as you probably already know, the YaST team is working hard to rewrite the whole storage stack on time for SLE15 and openSUSE Leap 15. As part of this reimplementation we have designed a brand new storage proposal that automagically offers the user the best combination of partitions and LVM volumes based on the current configuration of the system and the user preferences.

The storage proposal in action

When we are working with very small disks or with special technologies like DASD (which doesn’t accept more than three partitions by device), the storage proposal might not be able to generate a valid initial proposal honoring the initial requirements of the product (e.g. creating a separate home partition and enabling btrfs snapshots for the root partition in the openSUSE Leap case). Now the proposal is not limited to fail when it is not possible to satisfy the default product requirements. Before giving up, the new system looks for alternatives, like discarding the separate home partition or disabling snapshots. Moreover, now the proposal is able to automatically adjust the size requirements not only for root, but also for swap and home. And, of course, the guided setup continues there for fine tuning the proposal settings.

Desktop selection improvements

As our usual readers also know, we recently introduced a more fair desktop selection screen for openSUSE, both Leap 42.3 and Tumbleweed. We used part of the latest sprint to implement some feedback we gathered about the wording and behavior of that dialog.

Revamped desktop selection screen

That feedback gathering included some discussions on how to make user experience nicer after selecting one of the user interfaces available through the “custom” option. As a result, the awesome openSUSE crew created a new mechanism for selecting the default window manager on each graphical login, so YaST can delegate the details to the maintainers of those alternative interfaces.

How everything works now? Glad you asked. 🙂

If the user select KDE or GNOME in the YaST dialog, /etc/sysconfig/windowmanager is configured to point to that desktop by default. If the “custom” option is selected, then YaST does not enforce any interface in that file and the new mechanism comes into play. It relies in the default.desktop file, which defines the default window manager and can be managed by the common update-alternatives workflow. Meaning it can be easily tweaked by the package maintainers and by the users, specially since YaST includes a nice module for managing alternatives.

Storage reimplementation: improvements in the expert partitioner

Although, as explained above, we keep improving the storage automatic proposal to support more and more situations, we cannot ignore that flexibility and adaptability have always been two of the flagships of (open)SUSE. And one of the most prominent examples is the YaST Expert Partitioner.

As detailed in our report of the sprint 36, we have been rewriting that powerful Swiss Army knife using the new storage stack but keeping the same user interface and functionality. So far, the new implementation was only able to display information about the existing partitions, LVM systems and MD RAIDs. But now we added many options to create, edit and delete partitions.

Using the expert partitioner during installation

It is still a work in progress because the number of possibilities offered by the YaST Partitioner is sometimes overwhelming and implementing them all takes time, but it’s progressing nicely.

Beside the improvements in the Partitioner itself, we also worked on its integration in the installation workflow. Now the Expert Partitioner can be used to refine the schema automatically proposed by the installer. As a bonus, the behavior of the “abort” and “finish” buttons has been improved in relation to the Expert Partitioner currently available in (open)SUSE, which historically shows a usability inconsistency there compared to the rest of the installation process.

Fixed Automatic Patch Installation

In both SLE and openSUSE Leap, the online updates can be installed either manually or automatically at some regular intervals. For the automatic installation we provide the yast2-online-update-configuration package which provides a cron job script and an YaST module for configuring it (hint: it is not installed by default, you might give it a try, maybe it is something “new” for you).

Configuring online updates via YaST

You can configure how often the patches should be installed or filter the patch categories in the YaST module, but we got a bug report saying that when multiple patch categories are selected only one is actually used.

It turned out to be a trivial mistake in the cron job and we fixed it for SLE12-SP2 and Leap 42.2, as well as for the upcoming SLE12-SP3 and Leap 42.3. So if you use this module and want to use the category filter then it’s recommended to upgrade the package.

Storage reimplementation: many steps forward in the AutoYaST integration

And going back to our new storage stack, we keep working to integrate it better with other parts of YaST, specially AutoYaST. During this sprint we polished some rough edges and we added support for MD RAID. With all that, now is possible to automatically setup a system based on an AutoYaST profile containing any combination of partitions, LVM systems and MD arrays, including encryption at any of the levels.

AutoYaST summary of actions on partitions, MD RAID and  LVM

But the relation of AutoYaST with the system works in both directions. Apart from being able to install a system based on an AutoYaST profile, it also offers the interface to export the current system configuration, including the storage layout, to a profile in order to reproduce the system later. During this sprint we also ported that logic to rely on the new storage layer.

It was harder than it sounds, due to the need of keeping the backwards-compatibility with several behaviors that have been introduced along the AutoYaST history to adapt to several specific situations. On the bright side, the new code is easier to follow, includes behavior-driven automated tests (RSpec) and contains information about the rationale of each decision… which in some cases required some archaeology.

Storage reimplementation: fixed bootloader proposal in S/390 and PowerPC

Another part of YaST we are constantly working to integrate better with the new storage stack is yast2-bootloader. Although the new storage system was already able to correctly setup a valid disk layout for most situations and architectures (each one with it’s own requirements for booting), our bootloader module is still not fully compatible with the new system in all those scenarios.

During this sprint, we adapted it to ensure all the combinations suggested by the new storage stack (partitions, LVM, encryption and so on) are correctly covered by YaST2-Bootloader. As a result, we can already say that our testing ISO images are fully installable in any x86_64, PowerPC and S/390 system by just clicking “next” a few times. And we have automated integration tests (a separate openQA instance) to ensure the resulting system boots just fine.

UDEV device id on PowerPC

We know some of our readers enjoy our more technical posts and like to lurk into the kitchen to see how we deal with all kind of surprises maintaining a complex tool like YaST. Today’s chapter in that regard started with a bug report about the bootloader being installed in the wrong device name (/dev/vda instead of /dev/vdb) in an emulated PowerPC machine in openQA.

After a lot of investigation and with help from our PowerPC expert, we found the culprit, that turned out to be an emulator quirk. The next couple of paragraphs may be interesting or daunting, depending how much virtualization and PowerPC jargon you know. Be warned.

On POWER, the PReP partition containing the bootloader has no unique identifier other than the serial number of the disk on which it created. QEMU virtualization does not provide any disk serial number when the user does not explicitly specify one. This means that the PReP partition in QEMU installation does not have any unique identification and the partition name may change when a disk is added or removed from the virtual machine or the storage configuration otherwise changes. This may lead to system errors related to bootloader installation and updates.

It is recommended to assign a unique serial number to each disk in a QEMU virtual machine on POWER when it is expected the storage configuration of the virtual machine may change. Otherwise, there is nothing YaST or any other tool running within the virtual machine can do to avoid the problems. So this time we only did the investigation part, with the fix coming from the openQA side, which was improved to explicitly set serial numbers when needed.

Storage reimplementation: better support for advanced scenarios

As exposed above, our StorageNG testing image already works in all the supported architectures and in scenarios combining plain partitions, LVM, RAID and encryption in any way. But there are even more situations and technologies currently supported by YaST that we need to incorporate into the new stack.

First of all, we used this sprint to add Multipath I/O support to the new libstorage. Now it can also be combined with all the other mentioned technologies (like having an LVM system on top of an encrypted multipath device), although the storage proposal still needs to be adapted to play nicely with preexisting multipath setups.

As usual with the library stuff, the best “screenshot” we have to offer is one of its geeky autogenerated graphs.

A multipath layout in libstorage-ng

Another scenario that goes beyond the most regular use cases is installing the system into a network storage device, instead of a local hard disk. Now, the new storage system can report whether a root filesystem via a network is used. When that happens, YaST sets the network interfaces with the start mode nfsroot, which is used to avoid interface shutdown and, therefore, the unavailability of the system.

That’s all, folks!

Once again, we omitted the boring parts about bugfixing (with yast2-ntp-client being the star in that regard) and similar stuff. We hope you enjoyed the report and we hope to reach you again in two weeks. Meanwhile…

Have a lot of fun testing the Leap 42.3 pre-releases and reporting bugs!

Highlights of YaST development sprint 37

July 3rd, 2017 by

Since we announced in the latest report, we decided to shorten our development sprints from three to only two weeks. As a natural consequence, this is the first report of a series of shorter ones. But shorter doesn’t have to mean less juicy! Keep reading and enjoy.

Displaying very long changelog

We got a bug report about YaST not responding when a very long package changelog was displaying in the package manager. It turned out that some packages have a huge change log history with several thousands entries (almost 5000 for the kernel-default package). That produces a very long table which takes long time to parse and display in the UI.

The solution is to limit the maximum number of displayed items in the UI. You cannot easily read that very long text anyway, for such a long text you would need some search functionality which the YaST UI does not provide.

Finding the limit, that magic number, was not easy as we want to be backward compatible and display as much as possible but still avoid that pathological cases with a huge list.

In the end we decided to go for a limit of 512 change entries. The vast majority of packages have way fewer entries, so you should not notice this clipping functionality. When the limit is reached a command to display the full log is displayed at the end so you can easily see the missing part when needed. (Hint: the widget supports the usual copy&paste functionality, you can copy (with Ctrl+C) the displayed command and paste it into a terminal window directly.)

Clipping the kernel changelog

Storage reimplementation: MD RAID support in the rewritten partitioner

In the previous report we told you we are rewriting the YaST partitioner to use the new storage stack and modern reusable CWM widgets under the hood while retaining exactly the same behavior and look&feel on the surface. We are reimplementing one feature at a time, and this sprint it was the MD RAID’s turn.

Now the partitioner displays current RAIDs, with details about them and the devices used to construct each RAID. If a picture is worth a thousand words, here you have 3,000 words:

RAID list in the rewritten partitioner

Devices in a given RAID in the rewritten partitioner

RAID details in the rewritten partitioner

No, you can’t have a separate partition for /var/lib/docker for CaaSP – so here you have it

Our brand new containers-oriented solutions, SUSE CaaSP and its openSUSE counterpart Kubic, need to have /var/lib/docker as a separate partition for several reasons. It was a separate Btrfs subvolume already, but that wasn't quite separate enough. 🙂

The problem was just that the automated storage proposal in the old YaST storage subsystem is not prepared for anything like this; it can deal with root, swap and optionally a separate home partition (or volume if using LVM). That's it. Extending the current syntax of the control.xml file to be able to specify arbitrary partitions and adapting the code of the old proposal to understand and handle this new specification was unfortunately almost impossible. Sadly, we have to admit the old code is hardly maintainable these days and not flexible enough to accommodate this kind of changes in a safe way.

This is one (out of many) reasons why we are currently in the process of rewriting that entire YaST storage subsystem, as you already know from many previous posts in this blog. But, as you also know, the new system will debut in SLES15 and openSUSE Leap 15.0, too late for the current SUSE CaaSP and openSUSE Kubic.

We decided we'd introduce a hack based in the old proposal, well knowing that hacks accumulated in code can develop their own life just like Dust Puppy. But we plan to kill that hack immediately once StorageNG arrives.

So the hack was to simply use the logic for the separate home partition and repurpose it, keeping all the respective parameters in control.xml and introducing yet another one called home_path where the actual mount point for that partition can be specified — in this case /var/lib/docker. The tradeoff is that there can be no separate /home anymore in parallel to that.

That "feature" should not be used outside of that very specific use case in CaaSP and we even considered the possibility of not documenting it too publicly to avoid misuse. But we are living the open source spirit and whatever we do, we do in public. Even if it's the (quite embarrassing) fact that we consider changes to certain parts of our own code too risky. But again, that's why we are pushing the storage layer reimplementation (Storage-NG) so hard: we want to regain control over that part.

Storage reimplementation: custom partitioning with AutoYaST

And talking about the new storage layer and our previous posts, you already know we are working hard to integrate it with AutoYaST. For the time being, custom partitioning layouts are supported, but only using plain partitions and LVM. Other features, like RAID or Btrfs subvolumes support, are still missing.

A nice thing about the new code is that it relies as much as possible on the new storage layer. On older versions, AutoYaST implemented some logic on its own and that caused some unexpected troubles. Fortunately, that is not the case anymore, and the new code looks way easier to extend and maintain.

YaST does not write directly in /etc/vconsole.conf anymore

When configuring the system keyboard, YaST used to write the keyboard map configuration directly in the /etc/vconsole.conf file. However, this approach is no longer appropriated since it may cause undesired effects to other tools. Now YaST uses the Systemd tool localectl to set the keyboard map in /etc/vconsole.conf, instead of writing in it directly. Another step to make YaST a good citizen of the Systemd world.

Storage reimplementation: named RAID arrays

If you use MD RAID arrays you probably know there are two ways of identifying them – by number or assigning a meaningful name to them. Named arrays use device names like /dev/md/<name> instead of /dev/md<number>.

During this sprint, we taught the new libstorage how to create and manage named RAID array, in addition to the already supported numbered ones. If the user decides so, the MD RAID name is used in fstab instead of the UUID (which was the only option with the old libstorage). We also made sure to improve the behavior in several scenarios, so we consider some bugs of the old storage to be fixed (or obsoleted, if you prefer) with storage-ng.

Linux also supports names of the form /dev/md_<name>. The new library is also able to handle this format, but the feature is intentionally disabled and documented to be unsupported because other parts of the system could not be 100% verified to work in that scenario. And we take quality assurance very seriously before labeling a feature as “supported”.

If you are not happy enough with the screenshots showing the RAID support in the partitioner, here you have more pictures. But, as usual with stuff implemented in the library, here “pictures” doesn’t mean screenshots, but fancy automatically generated graphs.

Stay tuned

Of course there are a lot of other things we did during the last two weeks, although some of them were considered not interesting enough for this report or were not finished on time. We are already working in finishing the unfinished stuff and implementing new exciting improvements. And the bright side is that you only have to wait two weeks to know more… so stay tuned.

Highlights of YaST development sprint 36

June 16th, 2017 by

We are still digesting all the great content and conversations from openSUSE Conference 2017, but the development machine never stops, so here we are with the report of our post-conference sprint.

Storage reimplementation: expert partitioner

You have been reading for months about the new stack for managing storage devices and the new features and improvements it will bring to the installation. But so far there was no way to view and fine-tune the details of those devices. During this sprint we have implemented a first prototype of the new version of the YaST2 Expert Partitioner, that awesome tool you can invoke with yast2 storage.

To make the transition easier and to be able to submit it to Tumbleweed as soon as possible (hopefully in a couple of months, together with the rest of the new stack) we decided to postpone any UI redesign. So this first incarnation of the new expert partitioner looks and behaves exactly like the one available in current versions of (open)SUSE.

To try it out (on a scratch machine!), add a repository and remove the current storage library, as described in yast-storage-ng: Trying on Running System and then run zypper install yast2-partitioner. As you may have noticed, we split the partitioner in a separate package, unlike the current version that was part of the basic yast2-storage.

The new expert partitioner will only give you a read-only view of things similar to the following screenshots, not being able to modify anything yet.

New expert partitioner - hard disks list

As you can see in your own system or in the screenshots, the following items are already functional

  • Hard disks and their partitions
  • Volume Groups, Logical Volumes, and Physical Volumes of the Logical Volume Manager (LVM)

The other kinds of devices that you can see in the navigation tree are so far only stubs.

New Expert Partitioner - logical volume overview

You may feel a bit underwhelmed by this, and that’s OK, because most of the effort that we spent on this is actually hidden in a set of nice UI classes which we use to reconstruct the legacy procedural UI code. So the new expert partitioner not only relies on the revamped storage stack, but also on a powerful and reusable set of shiny UI components. If you ever need to code a user interface for YaST, the next section is for you.

New Expert Partitioner - list of physical volumes

New CWM Widgets

This section may be a little bit too developer-oriented, so feel free to skip it if you don’t care about the YaST implementation details. If, to the contrary, you want to have a glance at the new YaST widgets, go ahead.

Before diving into the new widgets, let us introduce what CWM is. It stands for Common Widget Manipulation and it is an old procedural YaST module which puts together a widget, its help and its callbacks. These callbacks are used to initialize, validate and store the content of the widget. This organization allows easier re-usability of widgets, which are then put together into a dialog. We also made an object-oriented version of CWM, which uses the old one under the hood, but is based on classes. So the contents and callbacks all live in their own class which is then used in dialogs. It is already used e.g. in the bootloader module.

As part of the Expert Partitioner rewrite, we created new types of reusable widgets, like Table or Tree, that are now available for its usage in any YaST module.

We also realized that it would be cool to be able to construct full dialogs out of smaller “bricks”, because the partitioner dialogs usually have rather complex structures in which some parts are shared by several dialogs. For this purpose we added new kinds of widgets – a Page which represents a part of a dialog that contains other widgets, and a Pager which allows switching of pages. So far there are two different pagers. The first one is Tabs which shows a set of tabs and allows switching among them and the second one is TreePager which allows switching pages according the item selected in a tree.

As you can see in the screenshots from the Expert Partitioner, there is a tree on the left side, which decides which page is shown on the right side. That right side sometimes contains a set of tabs, which decides what is displayed for every single tab.

Building blocks for the win!

Added support for allocation of memory high into YaST Kdump Command-line

A new option to allocate memory high during enable of Kdump was already implemented in YaST interface but unavailable through command-line. From the next Service Pack (i.e. SLES 12 SP3, Leap 42.3, and Tumbleweed), the user will be able also to use this option in command-line and scripts. In order to do that you can just use the command yast2 kdump enable alloc_mem=low,high, where low sets Kdump Low Memory and high sets Kdump High Memory.

For current users of Kdump command line, the old command to enable kdump yast2 kdump enable alloc_mem=$mem will still work as before, keeping its compatibility.

Handle optional filesystem packages correctly

During installation, when YaST detects in the system a particular filesystem or technology for which the installer would need additional packages to deal with, it alerts the user and tries to install those packages. A very visible case are the ntfs-3g and ntfsprogs packages, installed when a MS Windows partition is found in the system.

But, what happens if those packages are simply not available for installation? That’s the case of SLE12-SP3, which doesn’t include ntfs-3g. Should the installer block the installation of SLE12-SP3 alongside an existing MS Windows just because of that?

Fortunately we have solved that problem for the upcoming SLE12-SP3… and also created the code infrastructure to avoid similar problems in the future. Now we have a separate list for packages that would be nice to have installed in order to deal with a particular technology but that are not 100% mandatory to the point of blocking the installation process if they are not available. So we don’t bother the user about things that cannot be solved anyway.

Issues solved in YaST Remote command-line

But apart from looking into the future, we keep taking care of the existing YaST modules and its supported scenarios. During this sprint, we also addressed some issues related to YaST Remote, when using the command line.

The command yast2 remote list was installing required packages for YaST Remote and also restarting the display manager. However, as this command is expected to be a read-only operation, it shouldn’t change anything in the system. Such a problem was solved and now this command just lists the status of remote options.

Another issue was in the command yast2 remote allow=yes, which was opening a pop-up interface to alert the user about the changes in the system. Such a pop-up was impeding the use of this command in scripts. Therefore, we removed it when executing YaST Remote in command-line and, instead, we now just show a warning message on the console.

Both fixes were submitted as a maintenance update to all the supported versions of SLE and openSUSE and will reach our user as soon as they pass all the extra security checks performed by the respective maintenance teams. Of course, both fixes will also be included in future releases.

Storage reimplementation: simplified actions summary

The Expert Partitioner was not the only thing we did related to the new storage stack during this sprint. We also tried to improve how the information is presented to the user everywhere.

Having a huge amount of information at a glance might be useful in certain cases… as long as that amount can be handled by a human brain! Since we don’t expect all our users to be androids, we decided to improve our storage actions summary. Now is much easier to understand what is going to happen in the disks after pressing the confirmation button.

They say a picture is worth a thousand words. So let’s compare the ultra-detailed list offered before this sprint…

Summarized actions: before

…with the new digested one.

Summarized actions: after

As you can see, the new summary carries the essential information in a clear and legible way. Delete actions are highlighted in bold and, moreover, the set of actions related to btrfs subvolumes are grouped in a collapsible list.

Summarized actions: extended view

Integration of AutoYaST with the new storage has also received our attention during this sprint. Now, the summary dialog in AutoYaST shows the list of storage actions in the new compact way. Currently it is not possible to edit partitions from this AutoYaST dialog, but stay tuned for more information in upcoming sprints.

Summarized actions: AutoYaST

AutoYaST: warn the user when creating smaller partitions

You already know how powerful can AutoYaST be in terms of automating complex installations based on flexible profiles, even trying its best if the profile contains parts that are challenging to implement in the target system.

One of those adjustments that AutoYaST can perform is reducing the size of some of the partitions specified in the provided profile if the target disk is not big enough, to make sure the installation doesn’t get blocked just by some missing space.

The mechanism works very well but that kind of automatic adjustments can be unexpected and can produce undesired results. That’s why we have added the following warning message.

AutoYaST: alert user about adjusted partititions

Of course, this new warning uses the usual AutoYaST reporting mechanisms, so even if the users are not in front of the screen (something very common when performing an unattended installation) they will be notified about the special circumstance.

Docker, Docker everywhere!

And now, another dose of technical content for those of you that love to lurk into the kitchen.

In the report of the sprint 30 we already described how we adopted Docker to power up our continuous integration process in the master branch of our repositories (the one in which we develop Tumbleweed and upcoming products). As also reported, we adopted the same solution for Libyui in the next sprint. And now it was the turn the branches of YaST that we use to maintain already released version of our products. Not a trivial task taking into account the many repositories YaST is divided in and the many products we provide maintenance for.

If you want to refresh your memory about the whole topic of using Docker for the continuous integration infrastructure, here you can watch the talk Ladislav offered about the topic a few days ago in the openSUSE Conference 2017.

Storage reimplementation: full support for DASD devices

If you don’t have a S/390 mainframe laying around, maybe you are not familiar with the concept of DASD (direct-access storage devices). DASDs are used in mainframe basically as regular disks… just that they are not.

DASDs are special disks in various aspects – they have a different partition table type allowing only three partitions with a restricted set of partition ids, they must be managed by a different set of partitioning tools, they have their own specific alignment logic and requirements…

But thanks to YaST and libstorage, in (open)SUSE you don’t have to care about most of those details. The expert partitioner and the installer allow you to treat DASDs almost as regular disks.

During this sprint we adjusted the new libstorage, i.e. the library C++ based layer of the stack, to be able to deal with DASD. As usual with new features implemented in the library, the only “screenshot” we have to show is one of the graphs generated by the library. Enjoy.

DASD support: the example graph

More to come… very soon

We want to have a shorter and more agile feedback loop regarding our development efforts. To achieve that, we have decided to shorten our Scrum sprints from the current three weeks to just two. So you will have more news from us in half a month.

But a feedback loop works in both ways, so we also expect to have more news from you. 🙂 See you soon!