Home Home > 2018 > 11
Sign up | Login

Deprecation notice: openSUSE Lizards user blog platform is deprecated, and will remain read only for the time being. Learn more...

Archive for November, 2018

Highlights of YaST Development Sprint 67

November 20th, 2018 by

Time flies and another development sprint has finished for the YaST team. During it we have focused on improving the installation process, refining it and adding new features to unleash new possibilities. That includes:

  • More options to configure Kubic during installation.
  • Several improvements in the storage proposal.
  • Easing the network configuration and the usage of online repositories in openSUSE.
  • Improving installation in text mode for CJK and other languages.
  • Configuring SSH access during installation and in a running system.
  • And many other small fixes here and there!

    • Many of these features will be already available in openSUSE Tumbleweed during November (the sprint just finished November 16th and the integration process usually takes some days), others will be visible for the first time in the next SLE-15-SP1 and Leap 15.1 Alpha versions.

    New Dialogs in the openSUSE Kubic Installation

    The SUSE CaaSP and the openSUSE Kubic products got a new installation workflow some time ago. Originally they used a specific installation workflow (a single all-in-one configuration dialog), but the problem was that many openSUSE/SLE installation features were missing because the installer code was completely different.

    That has been changed some time ago to use the usual installation as in standard SLE or openSUSE products. You can read the details about the new installation workflow at the Kubic wiki page.

    However, the CaaSP or Kubic products required some more specific settings depending on the selected role. During this sprint we have added the corresponding steps to the installation.

    New installation steps for openSUSE Kubic

    Currently the extra dialog only asks for the NTP server address, but some more options can be added later.

    Improve Textmode Support for CJK and Other Languages

    YaST is able to cope with many languages even when running in textmode. When a user wants to run the installer in textmode using some specific languages -like Chinese, Japanese or Korean-, YaST will use a special terminal emulator called fbiterm which is able to display the characters which are needed in those languages.

    Now, instead of keeping two different approaches depending on the language, YaST will try to use this special terminal emulator whenever is possible for all text based installations. Unfortunately, there is a small set of languages that are not properly handled by fbiterm. In those cases, YaST will inform the user about the problem and it will fall back to English.

    YaST installing SLE-15-SP1 in Japanese

    As a side effect of this unification, the font used during the textmode installation has changed for all the languages that didn’t used fbiterm in the past. So your SUSE or openSUSE installation may now look slightly different.

    Storage proposal: playing nicely with Intel Rapid Start Technology

    Intel Rapid Start Technology (shorted as IRST) enables systems to quickly resume from deep sleep (e.g. if your battery runs out). It’s a firmware-driven technology that relies on the existence of a special partition located on a SSD (solid state device).

    But our partitioning proposal (the so-called Guided Setup) was not aware of the important role of such partition, so it sometimes proposed to delete it in order to use the freed space for installing (open)SUSE on top.

    We have improved that and now the IRST partition will only be deleted as a last resort, if deleting all other allowed partitions in the disk is still not enough to make the new system fit. Moreover, an IRST partition located in the same disk than a Windows system will only be deleted if the user explicitly allows the storage proposal to delete that Windows installation.

    Running the storage proposal on top of software RAIDs and USB devices

    But that’s not the only improvement done in the area of the partitioning guided setup. We have also broadened its usefulness by allowing it to be used on top of new kinds of devices.

    First of all, it’s now possible to execute the guided setup on top of a software MD RAID. For that, the candidate RAIDs has to fulfill one of two conditions: to contain a partition table or to be completely empty (which includes not being formatted, encrypted or used for any other purpose). That is not only another step to take advantage of the relatively recent capability of YaST to partition software RAIDs (thanks to libstorage-ng) but also a very natural way to support the usage of Dell EMC PowerEdge RAID controllers S130 and S140, which offer an hybrid solution based on software RAIDs but backed up by a firmware-driven configuration.

    Partitioning proposal on top of a software MD RAID

    Almost for the same price, we decided that it was time to offer the available USB devices as candidates for the guided setup, even when there are also non-USB candidates. Excluding, of course, the installation media (except when performing a network-based installation, in that case the USB device can be reused to install the system).

    As usual, these features will be soon available in openSUSE Tumbleweed, as well as in the next stable versions of openSUSE Leap (15.1) and SUSE Linux Enterprise (SLE-15-SP1).

    Fine-tuning the initial storage proposal

    All the described changes open new possibilities for the users to decide where to execute the storage proposal. But as our users already know, when the installer reaches the storage proposal step for first time (before the user has had the chance to run the Guided Setup or the Expert Partitioner), an initial proposal is automatically calculated and displayed. This proposal is performed without user intervention, and all necessary information is taken from the control file of the current product. For example, whether to create a separate home, or whether to enable snapshots for root, etc.

    During the previous sprint, this initial proposal was already improved to make an attempt over each individual disk instead of considering all disks together. Now we have improved this behavior to not discard the first disk so early, even if that means getting a smaller (open)SUSE system.

    For example, let’s image we have a system with a first small SSD disk of 40 GiB and a second big Hard Disk of 1 TiB, which is a relatively common configuration for laptops. Since the first disk is too small to allocate a system with the optimal partition sizes and a separate /home partition, the installer used to switch to the second disk, in which it could propose a root partition of the recommended size to use Btrfs snapshots (50 GiB) and a partition for /home bigger than the 40GiB specified as minimum for it in the product description.

    Initial storage proposal before the latest change

    Now, more attempts will be performed in the first disk before giving up and moving to the next one. So, when the proposal is not possible with the desired sizes and with all the optional devices enabled, it will try to disable some optional settings and to relax the size requirements (using the minimum sizes instead of the recommended ones). In the following screenshot you can see the result of this adjusted initial proposal.

    Initial storage proposal after the latest change

    Tumbleweed: Add Online Repositories during Installation

    We added a step in the installation workflow to enable online repositories. This means you can now get the latest packages installed immediately during installation instead of installing older versions from the installation media first and later updating them to the latest versions from the openSUSE servers.

    Also, because of disk space limitations, the installation media don’t contain all the packages that openSUSE provides and thus not all system roles; some of the less frequently used desktops, for example, had not been available in the role selection (formerly desktop selection) dialog. With online repositories, they are now available immediately during installation.

    For details, see the corresponding pull request.

    Choosing the network backend

    And more changes to the installer you will be able to enjoy very soon in openSUSE Tumbleweed and also in the upcoming openSUSE Leap 15.1. Now it’s possible to choose the network backend, wicked or NetworkManager, to be used in the final installed system from the Network proposal.

    As easy as a click on a hyperlink, as you can see in the images below.

    New shortcut to change the network backend

    Managing SSH public keys

    When you want to access to a system via SSH, it is a good practice to use public key based authentication instead of the common password-based approach. For that reason, we have added support to handle authorized SSH public keys in the user and group management module, also known as the users module.

    Configuring SSH in yast2-users

    Additionally, you will be able to set up a public key for the root user at installation time, something that can be especially handy for products like the SUSE CaaS Platform.

    And it keeps moving!

    The YaST crew keeps working hard on fixing bugs and, specially, on building new features for everybody to enjoy in the upcoming versions of all the products of the SLE and openSUSE families. So, as much as we would like to keep talking to you all about all the improvements… it’s time to go back to coding! See you again in two weeks with a new report.

Posted in Distribution, Factory, Miscellaneous, Programming, Software Management, Systems Management, YaST | 4 Comments »

Highlights of YaST Development Sprint 66

November 7th, 2018 by

The YaST team is working hard in order to extend the installer, improve the new storage layer and get rid of some bugs. So after this sprint, there is quite some unfinished work that will be ready within two weeks.

However, we have some stuff that we would like you to check out:

  • Snapper takes the free space into account when cleaning up snapshots.
  • The partitioning proposal tries to use just a single disk first.
  • The description of those actions that are related to BCache and MD-RAID devices have been greatly improved.
  • YaST is now able to handle repository variables properly.
  • The log viewer displays a helpful message when no logs are found.
  • And last but not least, yast2-sshd got a new maintainer outside of the YaST team. Let’s celebrate!

Extended Snapshots Clean-up Mechanisms in Snapper

So far snapper would delete snapshots if the overall spaced used for them was above a given limit. Now, snapper is able to take the free space into account too, so it will delete snapshots when the free space of the filesystem drops below a given threshold.

Of course, the threshold can be adjusted by the user through the snapper configuration files.

Better Actions Descriptions in Storage-ng

When describing what actions will be performed for storage actions, we already collapsed related actions to one to make it better readable. Instead of:

- Create  partition /dev/sda1 (40.00 GiB)
- Set ID of partition /dev/sda1 to "Linux" (0x83)
- Create ext4 on /dev/sda1
- Add mount point /home for /dev/sda1
- Add entry for /dev/sda1 to /etc/fstab

we report:

- Create partition /dev/sda1 (40.00 GiB) with ext4 for /home

However, actions related to BCache and MD-RAID devices were not taken into account, which produced quite long (and confusing) descriptions. Fortunately, these cases are now properly handled and the description is now quite informative and concise:

Create encrypted RAID1 /dev/md0 (511.87 GiB) for /secret with xfs
from /dev/sda (512.00 GiB), /dev/sdb (512.00 GiB)

Properly Handling Repository Variables

libzypp supports variable substitution in the name and the URLs of repositories and services. So a .repo file might contain something like this (notice the $releasever variable):

[repo-oss]
name=openSUSE-Leap-$releasever
baseurl=http://download.opensuse.org/distribution/leap/$releasever/repo/oss/

libzypp will take care of injecting the correct value but the user could override those values too. So in the example above, upgrading to Leap 15.1 might be as easy as:

zypper --releasever 15.1 dup

However, YaST2 had some problems in these situations that, hopefully, have been fixed during this sprint. Now openSUSE release managers can adjust the list of online repositories in order to take advantage of such a feature. If you want to know more about variable substitution, please check libzypp documentation.

Partitioning Proposal Uses a Single Disk

Until now, the partitioning proposal that is calculated during the installation uses all available disks by default. However, according to the feedback that we have received from our users, most people simply expect the system to be installed in just one disk. So, from now on, this initial proposal will consider each candidate disk in isolation before falling back to a multi-disk approach.

A picture is worth a thousand words, so just compare the images below to see the difference on a system which has three hard disks.

Initial Multi-Disk Partitioning Proposal

Initial Single Disk Partitioning Proposal

Improve Log Viewer Usability

YaST has featured a log viewer for a long time which allows the user to inspect files under /var/log like messages, boot.log or even YaST logs (YaST2/y2log). However, we are already in the Systemd times and most of your system services will log relevant information to the Systemd journal.

For that reason, YaST2 offers a really nice log viewer for (yast2-journal) which includes interesting filtering capabilities.

The problem is that, as one of our users stated in a rather old bug report, having two different tools to check logs can be confusing. Of course, they are getting information from different places so we decided to keep both of them. However, now the old log viewer will show a hint when no information is found in those old-style logs.

Use yast2-journal instead

yast2-sshd Has a New Maintainer

We would like to finish this report announcing that yast2-sshd has a new maintainer outside of the YaST team. This module was dropped back in 2013 and it was shipped in openSUSE 12.3 for the last time.

However, YaST is open source and Caleb Woodbine has built fresh RPM packages after fixing a problem he found in the firewalld integration. So if you are interested in such a module, check out Caleb’s work.

Thanks a lot, Caleb!

Conclusions

As we mentioned at the beginning of this post, there is quite some work in progress but, sadly, you will need to wait for another two weeks to get more details 🙂

Stay tunned!

Posted in Base System, Distribution, Factory, Systems Management, YaST | Comments Off on Highlights of YaST Development Sprint 66