Home Home
Sign up | Login

Highlights of YaST development sprint 23

August 18th, 2016 by

As already mentioned in our previous blog post, with Leap 42.2 in Alpha phase and SLE12-SP2 in Beta phase, the YaST Team is concentrating the firepower in fixing bugs in the installer. We fixed more than 40 bugs in three weeks! The dark side is that most bug fixes are not juicy enough for writing a blog post… but there is always some interesting stuff to report.

Integration of installer self-update with SCC and SMT

The installer self-update feature integrates now with SUSE Customer Center (SCC) and Subscription Management Tool (SMT) servers. Until now, there were three different mechanisms to get the URL of the installer updates repository:

  • User defined (using the `SelfUpdate` boot option).
  • Using an AutoYaST profile.
  • The default one, specified in the `control.xml` which is shipped in the media.

Now YaST2 is able to ask for the repository URL to SCC/SMT servers. The details of how the URL is determined are documented in the repository.

Fixes and enhanced usability in dialogs with timeout

As you may know, it’s possible to install (open)SUSE in an automatic, even completely unattended, basis using AutoYaST. AutoYaST can be configured to display custom configuration dialogs to the user and wait for the reply a certain amount of time before automatically selecting the default options. Until now, the only way for the user to stop that countdown was to start editing some of the fields in the dialog.

We got a bug report because that functionality was not working exactly as expected in some cases so, in addition to fixing the problem, we decided to revamp the user interface a little bit to improve usability. Now there are more user interactions that are taken into account to stop the counter, specially we added a new “stop” button displaying the remaining seconds. You can see an example of the result below.

New layout for dialogs with timeout

Following, as usual, the Boy Scout Rule we also took the opportunity to add automated tests to make that part of YaST more robust for the future.

Automatically integrating add-on repositories during installation

Sometimes you want to extend the regular installation media by adding just a few extra packages or provide a number of fixed packages along with the media.

For this purpose, the installer can automatically register an add-on repository. All you have to do is to put the repository on the installation medium and to add a file /add_on_products.xml that points to this repository.

The file looks like this:

<?xml version="1.0"?>
<add_on_products xmlns="http://www.suse.com/1.0/yast2ns"
    xmlns:config="http://www.suse.com/1.0/configns">
    <product_items config:type="list">
        <product_item>
            <name>My Add-on</name>
            <url>relurl://myaddon?alias=MyAddon</url>
            <priority config:type="integer">70</priority>
            <ask_user config:type="boolean">false</ask_user>
            <selected config:type="boolean">true</selected>
            <check_name config:type="boolean">false</check_name>
        </product_item>
    </product_items>
</add_on_products>

You can define the following elements:

  • <name> is the name of your repository
  • <url> points the the repository location; you’ll likely want to use the relurl scheme here that gives the location relative to the main installation repository
  • <priority> is the repository priority (lesser number means higher priority, the main installation repository has priority 99)
  • <ask_user>: should the user be asked about adding the repository?
  • <selected>: should the repository be automatically selected?
  • <check_name>: should the repository’s actual name be matched against the value of the <name> element?

You can of course list several repositories in this file.

If you’re too lazy to remember all this, mksusecd can do all this for you.

For example, if you have a set of new kernel packages you would like to use, do:

mksusecd --create new.iso --addon kernel-*.rpm --addon-name 'my kernel' sles12-sp2.iso

This creates a new iso based on sles12-sp2.iso that will install your new kernel packages instead.

Storage reimplementation: small steps for the code, giant leap for continuous integration

During bug squashing we managed to find some time to keep the storage stack reimplementation rolling… slow and steady. The customized Tumbleweed images (labeled as NewStorage) in the storage-ng OBS repository are already able to analyze most systems, creating a representation of the system storage devices in memory that will be used to manipulate the disks and propose a partitioning schema. Unfortunately, this representation is only visible in the YaST logs since fixing installer bugs was more urgent than representing that information in the UI.

This turned to be an important milestone, not because of the functionality itself or the value of the code (we just added a couple of lines of Ruby code), but because for the first time the dependencies in some packages were switched from libstorage to libstorage-ng. That had important implications for the code organization and for our continuous integration infrastructure, specially the Travis CI integration, which implies the generation of .deb packages. We can now say that our continuous delivery workflow (from Github to OBS, passing through Jenkins, Travis, Coveralls and Code Climate) is free of any trace of the old storage code.

In addition, we also did some good progress in LVM support in the new library, being able to recognize and manipulate in memory all kind of LVM structures.

The joy of openness: updating the SUSE Linux Enterprise documentation

An important part of our job, specially as a new release date approaches, is helping to shape the SUSE Linux Enterprise (SLE) documentation. One of the strongest points of SUSE products is the awesome SUSE’s documentation team which, as the rest of the company, have open source in their genes. Suggesting improvements and updates for the documentation is as straightforward as creating a pull request in the completely open documentation repository at Github… and anybody can do it!

The documentation team uses Docbook, but they would accept contributions in other formats (e.g. Markdown) and transform it themselves into Docbook… just because they are that cool. 🙂

Better support for ARM systems using EFI

The world is getting full of cool ARM64 devices and both SUSE and openSUSE are actively working in supporting as many of them as possible. We took another small step during this sprint improving the installer’s partitioning proposal for ARM systems that use EFI.

That’s not all, folks

As we always say, this was just the small portion of the work done that we consider exciting enough to be part of our development reports, since we don’t want to bore you with details about every single fixed bug. During this installer bug-fixing phase, this is more true than ever and the next sprint, which is already planned, will be similar to this in that regard. Nevertheless, in the next report we expect to have some interesting news about the installer self-update functionality and about the LVM support in the new storage stack. Stay tuned.

Live USB improvements

August 14th, 2016 by

Tools to create multi distribution bootable USB stick got couple of new improvements and features.

live-usb-gui now offers choice of scripts to use, depending in your need you can either use live-fat-stick with vfat partitioned stick or live-grub-stick script which works with any partition format supported by grub2 including vfat, must be used if you have iso bigger than 4G.

Read the rest of this entry »

Result of openSUSE.Asia Summit 2016 Logo Contest

August 11th, 2016 by

opensuse_asia_summit_2016_logo_winner

 

 

 

 

 

 

We are happy to announce that Ramadoni Ashudi design from Indonesia is selected as official logo for openSUSE.Asia Summit 2016 in Yogyakarta, Indonesia. As the winner Ramadoni Ashudi will receive a “magic box” from the committee.
Ramadoni Ashudi submit two designs and his design-2 selected by 28 voters. His design depicts his version of Tugu Yogyakarta, a monument built by Sultan Hamengkubuwono I, the first King of Yogyakarta in 1755.
Ana Maria Martinez from Spain also submit her version of Tugu Yogyakarta and selected by 17 voters on the 2nd place.
On the 3rd place, Shawhong Ser from Thailand submit a design that showing Arjuna character from Wayang Kulit, a traditional Javanese shadow puppet. Arjuna is the 3rd Pandava Brothers from Mahabharata. It is selected by 9 voters.

Total of voters = 65
Ramadoni Ashudi-2 = 28
Ana Maria Martinez = 17
Shawhong Ser =  9
Aris Winardi =  4
Ramadoni Ashudi-1 =  4
Kukuh Syafaat =  3
Danang Aji Bimantoro-1 =  0
Danang Aji Bimantoro-2 =  0

The complete result can be seen on the contest web page

Congratulation to Ramadoni, and many thanks and appreciation to Ana, Aris, Danang, Kukuh, Shawhong  for your participation in this contest.

Have fun.

Highlights of YaST development sprint 22

July 27th, 2016 by

openSUSE Conference’16, Hackweek 14 and the various SUSE internal workshops are over. So it’s time for the YaST team to go back to usual three-weeks-long development sprints… and with new sprints come new public reports!

With Leap 42.2 in Alpha phase and SLE12-SP2 in Beta phase our focus is on bugs fixing, so we don’t have as much fancy stuff to show in this report. Still, here you are some bits you could find interesting.

Installer memory consumption reduced

For our SLE customers we promise installations on machines with as little as 512MB of RAM. For Tumbleweed, 1GB is required – so the situation is more relaxed there.

But look at the total size of filesystem images that must be kept in memory during installation: 176MB for SLE12 (Tumbleweed: 224MB). This is leaving not much room to run programs.

The size has grown considerably over time, and we had to look for places to save space. We came up with some major areas for improvement.

The initrd and the installation system (the file system image containing the installer) share many files (mainly libraries). By removing any overlap, we were able to reduce the image size by 17MB for SLE12 (Tumbleweed: 30MB).

After the package installation starts, kernel modules and some raw libzypp cache data are no longer needed. By deleting zypp data we save another 3MB and kernel modules occupy even 29MB in SLE12 (Tumbleweed: 50MB). But we do this only on systems with less than 1GB memory.

So, compared to the available 512MB, these savings are quite substantial and will hopefully keep us going for a while…

Storage reimplementation: another step to an installable system

It’s time for our reimplementation of the storage layer to prove it can do the real work. Thus, we have integrated the new code in a set of modified Tumbleweed ISO images automatically generated in OBS. They cannot still be used to install a system, but the installer is already able to boot and reach the language selection screen (the first milestone we were aiming for).

We already had code that works in a simulated test environment (unit tests) and now we have a way to use that code in a real installer. Stay tuned for exciting news!

Make many extensions fit on the screen properly

For SUSE Linux Enterprise we offer so many optional modules that their listing did not fit on lower resolution screens. Below you can see how the screen looked before the fix – checkbox widgets and their labels do not fit so their bottoms are cropped.

Old interface with cropped extensions

We have to make sure YaST works across different interfaces, including text-based ncurses. That limits the set of widgets we can use when designing interfaces, so finding a solution to that kind of problems is not always easy. We also took the opportunity to add a filter for beta extensions, as you can see in the following screenshot.

The beta extensions filter in action

And finally you can see how it looks like with all the extensions, including beta ones. Instead of cropping elements we now have a scroll-bar in the right.

The new extensions UI in all its glory

Storage reimplementation: LVM unit testing

The next step in the storage layer reimplementation is adding support for LVM, since right now only regular partitions are supported. We always write a lot of unit tests to make sure the different pieces work in isolation before integrating everything together into the installer. During this sprint we created all the infrastructure for testing LVM at such level. Armed with that, we can start writing reliable code to handle LVM (something we have already started to do).

Improved patterns handling for system roles

We recently introduced the concept of system roles during installation. The chosen role affects the selection of package patterns. But we realized that the roles were not completely overriding the default selection of packages. Before the fix introduced in this sprint, desktop related patterns were included for a KVM server role and, thus, the systemd target was graphical.

The KVM Server role before the fix

Now, only the 3 patterns explicitly intended for the KVM role are selected, with no desktop related patterns. Accordingly, the system boots to text mode.

Fixed KVM Server role

Storage reimplementation: the future of booting

We have explained in several previous posts how we are collaborating with Grub and hardware architecture experts to make sure the new storage layer makes always sensible partitioning proposals. For that purpose RSpec has proven to be an excellent tool. It does not only allow us to have full unit test coverage or our code, but also the generated output has become the perfect base to discuss the expected behavior of the system in every possible scenario.

During this sprint, we spent quite some time together with SUSE’s Grub genius Michael Chang defining the best possible partitioning schema in x86 architectures. Once we had a human-readable and non-ambiguous specification, we modified our code to make sure the associated RSpec tests generated exactly the same specification as output. This way we make sure that our code works and that it fits 100% the experts expectations.

Kudos to Michael for his infinite patience with our questions and for coming up with an innovative way of using Grub2 that will allow us to boot in many tricky scenarios, eliminating the need of introducing a separate /boot in almost all cases.

Conclusion

As said, most of the sprint was invested in chasing bugs… and we don’t expect next sprint to be different in that regard. Even though, we hope this post to contain enough new stuff to keep you entertained and informed about what is going on in the YaST trenches.

See you in three weeks!

Tally ERP 9 on Linux

July 21st, 2016 by

Recently we implemented Tally ERP 9 solution for Antico Pumps. That itself is not interesting, the interesting part is they are using LTSP Fat client system on openSUSE. They have only one server from which all their client computers boot over the network, the clients do not have hard disk, client OS with all softwares they need including wine(Tally is Windows only software), as well as users’ data resides on the server. Once the client boots all the local resources are used so single low power server can be used to serve many clients.

Tally multiuser is served from a Samba share  on a NAS device, Tally folder is copied to samba share and path to Tally Data is changed so that it points there. Everything they need including printing and export(CSV) works from all clients. Same way Tally can be run on standalone computers. Neither Tally, Wine or openSUSE are modified for getting it working as it would under Windows environment.

Uninstall a patch using zypper

July 11th, 2016 by

Maintenance and security updates for the stable openSUSE Leap releases are automatically tested using OpenQA, and also receive community testing prior to release. In addition, many updates to openSUSE Leap are inherited from SUSE’s enterprise products, where they already receive thorough review, and automated as well as manual testing.

Should anything go wrong, here is how to “uninstall” an online update using zypper.

zypper in --oldpackage ` \
zypper info -t patch --conflicts openSUSE-2016-XXX | \
grep " < " | while read NAME C VERSION; do \
rpm --quiet -q --queryformat "%{name}\n" $NAME && echo "${NAME}<${VERSION}"; \
done`

Replace openSUSE-2016-XXX with the update in question. All involved packages are installed in a prior version. This, of course, is an alternative to using Btrfs snapshots. Note that the update will be offered again.

If you want to help review proposed online updates, just check the “untested updates” repo in YaST or add one of the -test repositories to receive updates early.

Future of Li-f-e: Linux for Education distribution

July 4th, 2016 by

We have come a long way since the first Li-f-e live media based on openSUSE was created, the current release is based on openSUSE Leap 42.1. Deployments by Indonesia’s education system is a shining example of openSUSE Education project’s accomplishment.

The openSUSE project has stopped producing live medias for Leap and also live-installer is dropped from live medias created for the Tumbleweed distribution. As Li-f-e is primarily a live distribution we would not be able to create any more medias without live-installer. So unless this situation changes we may not have Li-f-e based on Leap 42.2.

In the meantime I’ve had a look at Ubuntu to create Li-f-e based on the latest LTS release of Ubuntu-Mate, check it out here. Software selection available is kept identical to the Li-f-e based on openSUSE, however there is always a room for improvement, suggestions to enhance it are always welcome.

Highlights of YaST development sprint 21

June 23rd, 2016 by

Installation Video Mode

If you need to make screenshots of the installation it is useful to influence their size. You could press F3 in the boot menu and choose from a menu, but that is not well suited for scripts such as openQA.

The installer now obeys an option from the boot command line: xvideo.

xvideo=[WIDTHxHEIGHT][,DPI]
xvideo=1024x768
xvideo=1024x768,100
xvideo=,100

(Available in yast2-installation-3.1.195 + yast2-x11-3.1.5. bsc#974821)

How to Install with a Self-Signed Certificate

You can now install from a repository served with HTTPS that has a self-signed certificate. Use a ssl_certs=0 boot option.

(Available in yast2-packager-3.1.104. bsc#982727)

Installation: Local SMT Servers are Pre-filled

Last sprint (S#20) we improved the registration UI. Now we’ve made one more improvement: pre-filling the Register System via local SMT Server field.

Before, the widget was a single text field and a little helpful smt.example.com was always shown (no matter what your actual domain was). local-smt-server-1-before

Now, if your local SMT servers are advertised via SLP they will be offered as choices. (Here acme.com stands for your domain) local-smt-server-2-after

(Available in yast2-registration-3.1.176. bsc#981633.)

New Storage: ISO

We have started building an installation ISO image with the new storage library. The first build contains all the pieces but they don’t work together yet.

New Storage: Boot Scenarios

We have documented the supported scenarios regarding booting in the new storage layer.

(Tooling note: We made this with a Markdown formatter for RSpec invoked like this.)

Network Settings are Less Eager to Restart

If you opened Network Settings to review something, made no changes, and closed the dialog with OK, the network would be restarted. That may be undesirable if you have an Important Application running. We originally thought that everyone would close the dialog with Cancel, but we were proven wrong.

Now the module properly checks whether you have made changes to the settings, and omits the restart if appropriate.

(Available in yast2-network-3.1.155. FATE#318787)

Network in AutoYaST

Due to a problem in the AutoYaST version shipped with SLE 12 SP1 and openSUSE Leap 42.1, the network configuration used during the first stage was always copied to the installed system regardless the value of keep_install_network.

Upcoming SLE 12 SP2 and Leap 42.2 behaves as expected and keep_install_network will be set to true by default.

(Available in yast2-network-3.1.157 + autoyast2-3.1.133. Fixes bsc#984146.)

Highlights of YaST development sprint 20

June 7th, 2016 by

The latest Scrum sprint of the YaST team was shorter than the average three weeks and also a little bit “under-powered” with more people on vacation or sick leave than usual. The bright side of shorter sprints is that you don’t have to wait three full weeks to get an update on the status. Here you have it!

Debugger in the installer

Until now debugging the YaST installation was usually done by checking the logs. If you needed more details you would add more log calls. This is inconvenient and takes too much time but, as every Ruby developer know, there is a better way.

Being a fully interpreted and highly introspective language, Ruby offers the possibility of simply intercept the execution of the program and open a interpreter in which is not only possible to inspect the status of the execution, but to take full control of it.

From now on, you can access those unbeatable debugging capabilities during the installation. All you have to do is boot the installer with Y2DEBUGGER=1.

Debugger during installation

Moreover the same mechanism is also available when running YaST in a installed system. Just make sure the rubygem-byebug package is installed and start the YaST module like this:

Y2DEBUGGER=1 yast2 <client>

For more details see the brand new documentation. You can also see several examples and screenshots of the debugger running in text mode, through the network and in other scenarios in the description of the corresponding pull request.

Interface improvements for SSH host keys importing

Most software enthusiasts and developers, specially free software lovers, will know the mantra “release early, release often“. The earlier you allow your users and contributors to put their eyes and hands on your software, the better feedback you will get in return. And that proved to be true one more time with YaST and the awesome openSUSE community.

In the previous post we introduced a new functionality being added to YaST2 – more explicit and interactive importing of SSH host keys. Some users quickly spotted some usability problems, right in time for the fixes to be planned for this sprint.

In the description of this pull request you can see several screenshots of the new interface in several situations, with the new main dialog looking like this.

New dialog for SSH keys importing

Iterative development rocks when you have involved users. Keep the constructive criticism!

AutoYaST support for SSH host keys importing

The user interface was not the only aspect of SSH host keys importing that got improved. For every feature we add to the interactive installer, we always take care of making it accessible from AutoYaST as well. Thus, an AutoYaST profile file can now contain a section like this to control the behavior of the new functionality.

<ssh_import>
  <import config:type="boolean">true</import>
  <copy_config config:type="boolean">true</copy_config>
  <device>/dev/sda2</device>
</ssh_import>

Firewalld support in YaST2-Firewall

Another success story about collaboration in the YaST world. In the report about sprint 18 we mentioned we had received some contributions in order to add Firewalld support to YaST2-Firewall and that we were collaborating with the authors of those patches to get the whole thing merged in Tumbleweed. After a couple of sprints allocating some time to keep that ball rolling, we can happily announce that YaST2-Firewall in Tumbleweed already supports the “classic” SUSEFirewall2 backend and the brand new Firewalld one!

Support for vncmanager 3

SUSE’s VNC guru Michal Srb has been working lately in improving the ability to share and reconnect to VNC sessions. Until now, YaST always created a new separate VNC session for every client and closed the session when the client disconnected. There was no simple way to share the session with additional clients or to keep it running after disconnecting.

Now, thanks to Michal, the remote module can be set up in three different VNC modes: disabled, xinetd and vncmanager. Check the definition of each mode in the description of the pull request.

New registration UI

Six sprints ago, the “Local User” screen got some love and the UI was greatly improved. During this sprint, and according to bug #974626, we have improved the registration UI to make it consistent with the “Local User” screen.

The old interface, displayed below, was pretty confusing. Although it was not obvious at first sight, it offered three options:

  1. Register the system using scc.suse.com by introducing an e-mail and a registration code.
  2. Register the system using a local SMT server (no e-mail or registration code are used).
  3. Skip the registration step.

Old registration UI

Options 1 and 2 are mutually exclusive but, if you look at the interface, that fact is not clear. Moreover, we wanted this dialog to be consistent with the new “Local User” one.

The new dialog looks like this, with the three mutually exclusive options being directly presented to the user.

New Registration UI

As always, redesigning a UI in YaST implies making sure it works nicely in the NCurses interface with screens with a resolution of 80 columns and 25 lines of text. Doesn’t it look nice (provided the reader has a geeky aesthetic sense)?

Text-based Registration UI

Progress in the new storage layer

As usual, progress goes steady in the rewrite of the storage layer. In this sprint we invested some time into the partitioning proposal, which is now able to propose a good layout in some very complex scenarios with highly fragmented disks with limited partition schemas.

In addition, preliminary support for LVM was added although is still far from being complete and full-featured.

Will be back… very soon

We always finish our reports saying something like “this was just a sample of all the work done, stay tuned for another report in three weeks”. But the weeks ahead will be a little bit unusual. This week a SUSE internal workshop is taking place. That means that many YaST developers are focusing on stuff different from their daily duty. In addition, openSUSE Conference’16 and Hackweek 14 are both round the corner. As a result of all those “distractions”, next sprint will be shorter than usual (just one week) and will not start immediately. Expect next report at some point close to the start of openSUSE Conference. By the way… see you there!

Highlights of YaST development sprint 19

May 18th, 2016 by

Here we are after another Scrum sprint with our usual report about the activity in YaST development.

Trusted boot

YaST bootloader module got a new option, Trusted Boot (FATE#316553). It installs TrustedGRUB2 instead of the regular GRUB2. Trusted Boot means measuring the integrity of the boot process, with the help from the hardware (a TPM, Trusted Platform Module, chip).

It enables some interesting things which we unfortunately haven’t provided out of the box. We give you a bootloader which measures the boot integrity and places the results in Platform Configuration Registers (PCRs).

First you need to make sure Trusted Boot is enabled in the BIOS setup (the setting is named Security / Security Chip on Thinkpads, for example). Then you can enable the new YaST Bootloader option that will install TrustedGRUB2.

Trusted boot in YaST Bootloader

In the description of this pull request you can find a more detailed explanation including some commands and hexadecimal dumps to check the result. Geek pr0n!

SSH keys importing… and a glance at a YaST Developer’s life

When looking at any software project, it’s common to find some feature or piece of code that is there due to the so-called “historical reasons”. YaST2 code-base has been around since 1999, adapting to changes and new requirements in a (almost literally) daily basis since then. That leads to a new level of heritage – the “prehistoric reasons”. Working in the YaST Team implies coding, debugging, testing… and archaeological research.

We got a bug report about the installer “stealing” some SSH host keys (but not all of them) from previously installed systems. It was actually the effect of a little-known YaST feature that can look surprising (not to say weird) at first sight. Ten years ago, somebody decided that when installing SUSE in a networked environment, where people use SSH to log in, it was better to import SSH keys from a previously installed Linux than to get that “ssh host key changed” for everybody who tries to connect. The rational was that forcing everybody to change the ~/.ssh/known_hosts file often could become a security breach, since people could get used to ignore the security warnings. Welcome to the world of historical reasons. 🙂 Moreover, it was decided that the operation should be performed without showing any information to the users, in order to not confuse them.

More or less at the same time (we are still talking about 2006), it was decided to introduce importing of users from an existing system, this time with user interaction. The YaST developers decided that it would be fine to share some mechanisms in the implementation of both features. Another step into the historical reasons void.

Fast forward to the present. After several fate entries, bug reports and redesigns over the years, we decided to make the importing of SSH host keys more visible and usable, to make both functionalities (SSH import and users import) more independent and more clean and to take the first step to clean up the insanity introduced through the years (see fate#320873 for details).

The installer does not longer silently just import the SSH host keys from the most recent Linux installation on the disk (remember, you might have several distributions installed), it has now become a part of the installation proposal dialog:

SSH host keys proposal

And from there you can change it:

SSH host keys selection

Notice that one of the options is “none”, so copying of previous keys is not longer enforced. In addition, now is also possible to import the rest of the SSH configuration in addition to the keys.

Disabling local repositories

When installing from a local media, like a CD/DVD or an USB stick, those sources were still enabled after the installation. It potentially could cause problems during software installation, upgrade, migration, etc. because an old or obsolete installation source is still there. On the other hand, if the source is physically removed (for instance, ejecting the CD/DVD), zypper will complain about that source not being available.

Fortunately, this behavior will change in future SUSE/openSUSE versions. Now, at the end of the installation, YaST will check every local source disabling those whose products are available also through a remote repository (so they’re not needed at all).

Smart bonding with NPAR and SR-IOV interfaces

Support for bonding interfaces with NPar or SR-IOV capabilities has also been improved during this sprint. Too many weird words in one sentence? Don’t worry, we actually love to explain things.

Bonding is a way to combine multiple network connections to increase the throughput and bandwidth and to provide redundancy. On the other hand, NPAR and SR-IOV are technologies that provide the capability to create multiple virtual devices from the same physical or ethernet port.

Until this sprint, YaST offered no way to know whether two interfaces with these capabilities were sharing the same physical port. As a result, users could bond them without realizing that they were not getting the desired effect in terms of redundancy.

Information about the physical port ID has been added to all the relevant dialogs for all devices supporting it, like it’s shown in the following screenshots.

Physical ports

More physical ports

Additionally, the user will be alerted when trying to bond devices sharing the same physical port.

Bonding warning

Last but not least, following the Boy Scout Rule (also known as opportunistic refactoring), we took the opportunity to fix some small quirks in YaST Network, like the counter-intuitive sorting of devices in some lists.

Paying our debts: much better cleanup rules in Snapper

Somebody said once “a promise made is a debt unpaid“. In the previous post we promised you all an article on Snapper.io detailing the new space-aware cleanup introduced in Snapper. Here you are!

That’s all folks

Enough for a blog post. That’s of course not all we did during the last sprint (to the contrary, it’s just around 20% of the finished work according to the story points count) but, you know, we need to go back to hacking!