The Introduction

As usual, during this sprint we have been working on a wide range of topics. The release of the next (open)SUSE versions is approaching and we need to pay attention to important changes like the new installation media or the /usr/etc and /etc split.

Although we have been working on more stuff, we would like to highlight these topics:

• Support for the new SLE installation media.
• Proper handling of shadow suite settings.
• Mount points handling improvements.
• Help others to keep the Live Installation working.
• Proper configuration of console fonts.
• Better calculation of minimum and maximum sizes while resizing ext2/3/4 filesystems.
• Small fixes in the network module.

The New Online and Full SLE Installation Media

The upcoming Service Pack 2 of SUSE Linux Enterprise products will be released on two media types: Online and Full.

On the one hand, the Online medium does not contain any repository at all. They will be added from a registration server (SCC/SMT/RMT) after registering the selected base product. The Online medium is very small and contains only the files needed for booting the system and running the installer. On the other hand, the Full medium includes several repositories containing base products and several add-ons, which can help to save some bandwidth.

Obviously, as the installer is the same for both media types, we need to adapt it to make it work properly in all scenarios. This is an interesting challenge because the code is located in many YaST packages and at different places. Keep also in mind that the same installer needs to also work with the openSUSE Leap 15.2 product. That makes another set of scenarios which we need to support (or at least not to break).

The basic support is already there and we are now fine-tuning the details and corner cases, improving the user experience and so on.

Proper Handling of Shadow Suite Settings

A few weeks ago, we anticipated that (open)SUSE would split system’s configuration between /usr/etc and /etc directories. The former will contain vendor settings and the latter will define host-specific settings.

One of the first packages to be changed was shadow, which stores now its default configuration in /usr/etc/login.defs. The problem is that YaST was not adapted in time and it was still trying to read settings only from /etc/login.defs

During this sprint, we took the opportunity to fix this behavior and, what is more, to define a strategy to adapt the handling of other files in the future. In this case, YaST will take into account the settings from /usr/etc directory and it will write its changes to a dedicated /etc/login.defs.d/70-yast.conf file.

Missing Console Font Settings

The YaST team got a nice present this year (long before Christmas) thanks to Joaquín, who made an awesome contribution to the YaST project by refactoring the keyboard management module. Thanks a lot, Joaquín!

We owe all of you a blog entry explaining the details but, for the time being, let’s say that now the module plays nicely with systemd.

After merging those changes, our QA team detected that the console font settings were not being applied correctly. Did you ever think about the importance of having the right font in the console? The problem was that the SCR agent responsible for writing the configuration file for the virtual consoles was removed. Fortunately, bringing back the deleted agent was enough to fix the problem, so your console will work fine again.

Helping the Live Installation to Survive

Years ago, the YaST Team stopped supporting installation from the openSUSE live versions due to maintainability reasons. That has not stopped others from trying to keep the possibility open. Instead of fixing the old LiveInstallation mode of the installer, they have been adapting the live versions of openSUSE to include the regular installer and to be able to work with it.

Sometimes that reveals hidden bugs in the installer that nobody had noticed because they do not really affect the supported standard installation procedures. In this case, YaST was not always marking for installation in the target system all the packages needed by the storage stack. For example, the user could have decided to use Btrfs and still the installer would not automatically select to install the corresponding btrfsprogs package.

It happened because YaST was checking which packages were already installed and skipping them. That check makes sense when YaST is running in an already installed system and is harmless when performed in the standard installation media. But it was tricky in the live media. Now the check is skipped where it does not make sense and the live installation works reasonably well again.

A More Robust YaST Bootloader

In order to perform any operation, the bootloader module of YaST first needs to inspect the disk layout of the system to determine which devices allocate the more relevant mount points like /boot or the root filesystem. The usage of Btrfs, with all its exclusive features like subvolumes and snapshots, has expanded the possibilities about how a Linux system can look in that regard. Sometimes, that meant YaST Bootloader was not able to clearly identify the root file system and it just crashed.

Fortunately, those scenarios are reduced now to the very minimum thanks to all the adaptations and fixes introduced during this sprint regarding mount points detection. But there is still a possibility in extreme cases like unfinished rollback procedures or very unusual subvolumes organization.

So, in addition to the mentioned improvements in yast2-storage-ng, we have also instructed yast2-bootloader to better deal with those unusual Btrfs scenarios, so it will find its way to the root file system, even if it’s tricky. That means the “missing ‘/’ mount point” errors should be gone for good.

But in case we overlooked something and there is still an open door to reach the same situation again in the future, we also have improved YaST to display an explanation and quit instead of crashing. Although we have done our best to ensure this blog entry will be the only chance for our users to see this new error pop-up.

Improving the Detection of Mount Points

As mentioned above, improving the detection of mount points helped to prevent some problems that were affecting yast2-bootloader. However, that is not the only module that benefits from such changes.

When you run some clients like the Expert Partitioner, they automatically use the libstorage-ng library to discover all your storage devices. During that phase, libstorage-ng tries to find the mount points for all the file systems by inspecting /etc/fstab and /proc/mounts files. Normally, a file system is mounted only once, either at boot time or manually by the user. For the first case, both files /etc/fstab and /proc/mounts would contain an entry for the file system, for example:

$ cat /etc/fstab
/dev/sda1  /  ext4  defaults  0  0

$ cat /proc/mounts
/dev/sda1 / ext4 rw,relatime 0 0

In the example above, libstorage-ng associates the / mount point to the file system which is placed on the partition /dev/sda1. But, what happens when the user bind-mounts a directory? In such a situation, /proc/mounts would contain two entries for the same device:

$ mound /tmp/foo /mnt -o bind
$ cat /proc/mounts
/dev/sda1 / ext4 rw,relatime 0 0
/dev/sda1 /mnt ext4 rw,relatime 0 0

In the Expert Partitioner, that file system will appear as mounted at /mnt instead of /. So it will look like if your system did not have the root file system after all!

This issue was solved by improving the heuristic for associating mount points to the devices. Now, the /etc/fstab mount point is assigned to the device if that mount point also appears in the /proc/mounts file. That means, if a device is included in the /etc/fstab and the device is still mounted at that location, the /etc/fstab mount point takes precedence.

As a bonus, and also related to mount points handling, now the Expert Partitioner is able to detect the situation where, after performing a snapshot-based rollback, the system has not been rebooted. As a result, it will display a nice and informative message to the user.

Improved Calculation of Minimum and Maximum Sizes for ext2/3/4

If you want to resize a filesystem using YaST, it needs to find out the minimum and maximum sizes for the given filesystem. Until now, the estimation for ext2/3/4 was based on the statvfs system call and it did not work well at all.

Recently, we have improved YaST to use the value reported by resize2fs as the minimum size which is more precise. Additionally, YaST checks now the block size and whether the 64bit feature is on to calculate the maximum size.

Polishing the Network Module

As part of our recent network module refactorization, we have improved the workflow of wireless devices configuration, among other UI changes. Usually, these changes are controversial and, as a consequence, we received a few bug reports about some missing steps that are actually not needed anymore. However, checking those bugs allowed us to find some small UI glitches, like a problem with the Authentication Mode widget.

Moreover, we have used this sprint to drop the support for some deprecated device types, like Token Ring or FDDI. Below you can see how bad the device type selection looks now. But fear not! We are aware and we will give it some love during the next sprint.

Conclusions

The last sprint of the year is already in progress. This time, we are still polishing our storage and network stacks, improving the migration procedure, and fixing several miscelaneous issues. We will give you all the details in two weeks through our next sprint report. Until then, have a lot of fun!

Intro

As some may have already noticed, openSUSE MicroOS introduced a /usr/etc directory and some configuration files are already moved to this directory.

What’s behind this move? For a better understanding, let’s first look how configuration files are handled by RPM today:

RPM and Configuration Files

RPM has limited support for updating configuration files. In the end this consist of two simple choices:

• modified configuration files are moved away during upgrade and the admin has to redo the changes (.rpmsave files).
• modfied configuration files are kept and changes done by the distribution are ignored (.rpmnew files). In the end the service may not work or could even be insecure!

Both options are not really user friendly and will most likely lead to a broken or insecure service after an upgrade, which requires manual work by the admin. On desktop systems or a simple server this may be tolerable, but for big clusters this can lead to a huge amount of work.

There are several alternative solutions for this like Three-Way-Diff or doing the update interactively, but the first one does not solve the problem if conflicting changes are done, and the second one is no solution for fully automated updates.

Atomic Updates

For atomic systems another layer of complexity is added, because different states may contain different versions of a configuration file. So how can this happen? An atomic update is a kind of update that:

• Is atomic
  • The update is either fully applied or not applied at all
  • The update does not influence your running system
• Can be rolled back
  • If the update fails or if the update is not compatible, you can quickly restore the situation as it was before the update

The update will be activated by rebooting into the new state, so after an update, before the reboot, the changes done by the update are not visible. If an admin or configuration management software changes the configuration files in the runnung system during this time, this will create conflicts, and needs manual interaction again.

Goal

The goal is to provide a concept working for most packages and their configuration files, which makes automatic updates much easier and robust. For that a new way to store and manage configuration files is needed.

Requirements for a Solution

The new solution should make sure that:

• It’s visible to the admin that something got updated
• It’s visible which changes the admin made
• Package and admin changes should be merged automatically
• There should be only one directory to search for default configuration files

Solutions

As a longterm solution no package should install anything into /etc any more, this directory should only contain host specific configuration files created during installation and changes made by the system administrator. Packages are supposed to install their default configuration files to another directory instead.

For SUSE/openSUSE the decision was made to use /usr/etc as the directory for the distribution provided configuration files.

For merging the package and admin configuration files there will have to be different strategies depending on the file type; the files can be categorized as follows:

1. Configuration files for applications
2. Configuration files for the system (network, hardware, …)
3. “Databases” like files (/etc/rpc, /etc/services, /etc/protocols)
4. System and user accounts (/etc/passwd, /etc/group, /etc/shadow)

Application Configuration Files

For application configuration files there is already a good solution used by systemd, which could be adopted for most applications:

• /usr/etc/app.conf is the distribution provided configuration file.
• If it exists, /etc/app.conf replaces /usr/etc/app.conf.
• /etc/app.conf.d/*.conf contains snippets overiding single entries from /usr/etc/app.conf or /etc/app.conf.

The workflow for the application to load the configuration file would be:

• Application looks for /etc/app.conf.
• If this file does not exist, load /usr/etc/app.conf.
• Look for overides in /etc/app.conf.d and merge them.

See https://www.freedesktop.org/software/systemd/man/systemd.unit.html#Examples, “Overriding vendor settings” for more details and examples. A C library which provides a simple interface and implements above loading mechanism transparently for the application is libeconf.

Depending on the configuration file format above patterns may not work for all applications. For those applications a solution following the above guidelines as closely as possible should be found.

System Configuration Files (network, hardware, …)

As these configuration files are system specific and only created during or after installation and not provided by the distribution, these files will stay in /etc.

System Databases (rpc, services, protocols)

There are files in /etc which, strictly speaking, are no configuration files, such as /etc/rpc, /etc/services and /etc/protocols. They are changed very rarely, but sometimes new system applications or third party software need to make additions. These files will be moved to /usr/etc; /etc/nsswitch.conf has to be changed to search in /etc first and in /usr/etc second. A glibc NSS plugin usrfiles will be used for this. /etc will contain only the changes done by the admin and third party software.

/etc/passwd, /etc/group and /etc/shadow

There is no solution yet for these configuration files which would really solve the problems. Ideas are welcome!

Further Documentation

• The original, full proposal with many more ideas and background information on the reasoning behind the decisions: Atomic Updates and /etc
• The openSUSE wiki page tracking all changes: Packaging /usr/etc

Election time is here!

Two seats are open for election on the openSUSE Board. Gertjan Lettink completed his second term. Simon Lees completed his first term and thus he is eligible to run as a Board candidate again should he wish to do so.

The election schedule is as follows:

== Phase 0 ==

5 December 2019

* Announcement of the openSUSE Board election 2019-2020

* Call for Nominations and Applications for Board candidacy

* Membership drive. Become an openSUSE Member. Take the opportunity to apply for an openSUSE Membership during this phase (in order to vote or to run as a candidate).

25 December 2019

* Nominations and Applications for Board candidacy close

== Phase 1 ==

26 December 2019

* Announcement of the final list of candidates

* Campaign begins

* Membership drive continues, opportunity to apply for openSUSE Membership, but members will only be eligible to vote and not run as a candidate.

== Phase 2 ==

16 January 2020

* Ballots open: Please cast your vote during this time

* Campaign continues

31 January 2020

* Ballots close

1 February 2020

* Announcement of the results

The Election Committee is composed of Edwin Zakaria and Ish Sookun.

Only openSUSE members are eligible to run for openSUSE Board openings. Election Committee officials, however, are not eligible to run in order to avoid conflicts of interest. To stand for a position in the openSUSE Board please send an email to:

* opensuse-project@opensuse.org and * election-officials@opensuse.org

If a member would like to nominate somebody else, please inform the Election Committee and the officials will contact the nominee to ask whether s/he would like to run as a Board candidate.

The Election Committee is hereby calling for Nominations and Applications for the openSUSE Board.

Our infrastructure status page at https://status.opensue.org/ is using Cachet under the hood. While the latest update brought a couple of bugfixes it also deprecated the RSS and Atom feeds, that could be used to integrate the information easily in other applications.

While we are somehow sad to see such a feature go, we also have to admit that the decision of the developers is not really bad - as the generation of those feeds had some problems (bugs) in the old Cachet versions. Instead of fixing them, the developers decided to move on and focus on other areas. So it's understandable that they cut off something, which is not in their focus, to save resources.

As alternative, you might want to subscribe to status changes and incident updates via Email or use the API that is included in the software for your own notification system. And who knows: maybe someone provides us with a RSS feed generator that utilizes the API?

Sometimes it's a good idea to follow best practices. This is what we did by following the recommendations for "general-purpose servers with a variety of clients, recommended for almost all systems" from https://ssl-config.mozilla.org/.

With this, our services accept only TLS 1.2 connections and the latest elliptic curve ciphers. If your client or browser does not support these settings, it's definitely time for you to consider an update.

While we are looking for TLS 1.3 support, the openssl version on our systems (running currently Leap 15.1) does not support it - yet. Once there is an update, we'll let you know.

Please don't be surprised, if you visit our Etherpad instance at https://etherpad.opensuse.org/ today: the new version also comes with a new theme. All the old pads are still there and should be available under their old URL.

There were 20 openSUSE Tumbleweed snapshots released in the month of November and the snapshots brought in a large amount of updated packages to include KDE Applications 19.08.3, Frameworks 5.64.0 Plasma 5.17.2 and 5.17.3, Linux kernel 5.3.9 and 5.3.11, Mozilla Firefox 70, libvirt 5.9.0 and more. During the month, even Java 12 OpenJDK was dropped from the distribution.

One of the more amazing aspects of Tumbleweed in November, 2020, is that the last 10 snapshots of the month all produced a constant level of stable rating and the last seven had rating of 99 out of 100, according to the Tumbleweed snapshot reviewer.

Closing out the month, there were two snapshots with version upgrades and one snapshot (20191127) that produced some minor changes to a couple Advanced Linux Sound Architecture (ALSA) packages.

The first Tumbleweed snapshot for December arrived with the 20191202 snapshot. Updated were also made to ALSA with the update of the 1.2.1.1 versions of alsa-plugins, alsa-utils and asla, which dropped 25 patches and fixed regressions for the UCM parser. GNOME had several package updates for gedit, evolution and more. The 3.34.2 version of gnome-software fixed a potential threading crash when using flatpak and had an upstream fix for fwupd. An updated version of ModemManager 1.12.0, which is a DBus-activated daemon that controls mobile broadband devices and connections, had a large amount of improvements and changes to include adding support for Mobile Station Based Assisted-GPS in addition to Mobile Station Assisted Assisted-GPS. Revision control tool mercurial 5.2 made some backwards compatibility changes and added some new feature extensions with its quarterly release. The update of perl 5.30.1 triggered an issue recorded on the snapshot reviewer because the newer version and patch that came in it is problematic for embedded Perl usage. Several other packages were updated in the snapshot to include qemu 4.1.93, re2 20191101, xen and xorg-x11-server. The one major version change in the snapshot was an update to terminal multiplexer tmux 3.0a; the major release that allows its users to easily switch between several programs in one terminal offers new features like added support for the SD (scroll down) escape sequence and for underscore colors.

There were several RubyGems packages updated in snapshot 20191128, but the digital paint application Krita had the most fixes. Krita 4.2.8.2 removed the CSV export filter that had not worked in a long time and fixed the crop tool that loses a constant ratio when the handles touched the canvas edge. The 2.22.0 tuned package, which is a daemon for monitoring and adaptive tuning of system devices, fixed a bug that makes use of the self defined profile_dir argument instead of libexecdir. November’’s update of the wireguard package, which is a free and open-source software application and communication protocol for point-to-point connections, added a syncconf command and changed the wg-quick tool to only touch net.ipv4 for v4 addresses.

The 3D Graphics Library Mesa 19.2.6 arrived in snapshot 20191126 and fixed builds on PowerPC and added some stability patches. The digital audio editor and recording application audacity 2.3.3 added several improvements like splitting the equalization effect into two Filter Curve and Graphic EQ effects; the package update also fixed some crashes and the software’s refusal to export some large (4GB) files. The bind 9.14.8, package, which provides a DNS server and client utilities, set a limit on the number of concurrently served pipelined TCP queries and added support for the GeoIP2 Application Programming Interface (API) from MaxMind. The Antivirus Toolkit clamav updated to version 0.102.1 and introduced a new configure option to statically link libjson-c with libclamav and added support for HTTPS. The exo 0.12.10 for the Xfce desktop fix typeahead search regression and firewalld 0.7.2 added 15 new service definitions and provided a new option FlushAllOnReload in firewalld.conf. Improved experimental support was made for building Node.js with Python3 in the nodejs 12.13.1 long-term-support package. Python-networkx 2.4 added support for Python 3.8 and home media solution rygel 0.38.3 were also updated in the snapshot.

In an email this week, Tumbleweed Release manager Dominique Leuenberger indicated that a build fail notification for the python-numba package in openSUSE Factory has not been addressed for the past four weeks and unless somebody steps up and submits fixes, the python-numba will be removed.

This year I haven't done any drone-related travelling. The sponsorship deal fell through and Rotorama didn't participate in DCL. I admit I haven't been practicing as much as I would need to to do any better in the local races either.

So at least I got the world of FOSS to get out of the couch.

Berlin

Tobias organized yet another icon-related hackfest in Berlin earlier this year. This time we had some talented young developers help us out with the tooling. This effort to focus on the tools as well as the assets is continuing and we'll have some more exciting news to share soon.

Thessaloniki

GUADEC continues bringing awesome southern locations, which a vitamin D deprived monkey from a rainy climate can't appreciate enough. I have fallen back to my comfort zone and only given a short workflow/demo on icon design this year, mainly because Tobias has been giving great talks on focusing on design.

I still have a video to finish editing, but it ended up more of a personal one so I'm not sure I'll publicize it that much.

The Hague

And we're closing the year with another design hackfest. Big shout out to Hans de Goede and Carlos Garnacho for organizing a shell hackfest in the Netherlands, and mainly allow some designers crash the party to revive our efforts in attacking some of the downsides of the current overview design. The facilities of Revspace allowed us to meet face to face, mind map on the whiteboard, iterate on some prototypes and move forward considerably compared to the usual cycle spanning months.

Un article rapide sur l'usage des Actions Github dans le but de déployer un blog, ce qui peut être utile et faciliter votre flux de rédaction si, comme c'est le cas pour ce blog, les sources sont hébergées sur Github.

Les Actions Github sont un mécanisme permettant de construire des flux de travail assez intéressants pour de la compilation de code ou du déploiement. C'est plutôt bien documenter ici donc je ne vais tout réexpliquer mais simplement fournir un exemple de déploiement simple via Rsync.

Lorsque vous créez une action, cela se fait dans un fichier .yml situé dans un sous-dossier ".github/workflows situé dans votre dépôt. Vous pouvez nommer ce fichier comme voulez, il faut évidemment que son nom illuste le flux de travail qu'il réalise pour vous.

Voici un exemple:

name: CI_DEPLOY

on: [push]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v1
    - name: Deploy my blog
      env:
        KEY: ${{ secrets.SSH_PRIVATE_KEY }}
      run: |
        set -eu
        echo "Deploying blog files"
        SSHPATH="$HOME/.ssh"
        mkdir "$SSHPATH"
        echo "$KEY" > "$SSHPATH/key" && chmod 400 "$SSHPATH/key"
        SERVER_DEPLOY_PATH="user@ip_du_serveur:/chemin/vers/le/dossier/de_/destination"
        sh -c "rsync -arv --delete -e 'ssh -o StrictHostKeyChecking=no -i $SSHPATH/key -p 22' $GITHUB_WORKSPACE/ $SERVER_DEPLOY_PATH"

Vous noterez la variable d'environnement KEY, il s'agît d'un secret Github me permettant de me connecter via SSH à mon serveur.

Pour le reste, c'est un simple script Shell utilisant rsync. Les arguments qu'on lui passe sont à adapter à votre usage.

Tags: astuces, git