Skip to main content

a silhouette of a person's head and shoulders, used as a default avatar

openSUSE Tumbleweed – Review of the week 2020/09

Dear Tumbleweed users and hackers,

During this week we released 4 snapshots (0220, 0222, 0224 and 0226) – an average week from that perspective, yet there have been some interesting and well-awaited updates in these snapshots:

  • zsh 5.8
  • Mesa 19.3.4 & Mesa 20.0
  • libcap 2.32
  • GNOME 3.34.4
  • KDE Plasma 5.18.1
  • LLVM 6 has been removed from the repository
  • ncurses 6.2
  • Linux kernel 5.5.5
  • Mozilla Firefox 73.0.1: it will now launch in Wayland mode inside a Wayland session
  • MariaDB 10.4.12

Despite all those things happenings, stagings are still – or again – filled up:

  • Zypper 1.14.34: beware! This version no longer supports abbreviated command line parameters (e.g zypper in --no-r is no longer accepted)
  • KDE Plasma 5.18.2
  • Qt 5.15.0 (currently betas being tested)
  • Ruby 2.7 – possibly paired with the removal of Ruby 2.6
  • GCC 10
  • Python 3.8 (unchanged, awaiting the fix for salt)
  • Removal of Python 2
  • GNU Make 4.3
  • RPM: change of database format to ndb

the avatar of Robert Riemann

Citrix Workspace on openSUSE Tumbleweed

Please find a 2021 update below and furtherdown a comment from 2024!

Some companies offer their employees to access their corporate computer work space remotely using a remote desktop connection. The company Citrix provides software for such a connection. To connect, the employees need the software Citrix Workspace on their terminal devices. The company provides on their download page also files for Linux including openSUSE. Unfortunately, their version 1912 from 12 December 2019 did not just work on my openSUSE Tumbleweed 64bit computer (and earlier versions I tried neither).

Segmentation Fault and Missing Libraries

First, I tried to install the software package from the vendor.

  1. I downloaded the SuSE Full Package (Self-Service Support) Citrix Workspace app for Linux (x86_64) in version 1912 from 12 December 2019.
  2. zypper in ICAClient-suse-19.12.0.19-0.x86_64.rpm
  3. I logged into a corporate page, open a connection configuration file (*.ica) and nothing happened. So I assumed the application may have crashed. I downloaded the file and opened it in the terminal to see more.
  4. /usr/lib64/ICAClient/wfica -icaroot /opt/Citrix/ICAClient configuration-file.ica
  5. The app opened shortly and crashed then with the error message segmentation fault (core dumped)

Then, I tried to install somebody’s own software package. Note that this requires trust or a review of the package.

  1. I downloaded the ICAClient from https://download.opensuse.org/repositories/home:/enzokiel/openSUSE_15.2_Update/x86_64/ for openSUSE 15.2 Update x86_64 (hence, not Tumbleweed).
  2. I installed the package despite the missing library libcrypto.so.1.0.0.
  3. I found the missing library openssl 1.0.0 and installed it.

Afterwards, the application did not segfault any longer. However, it produced an error due to a missing certificate from the GlobalSign Root CA.

  1. So I went to Firefox, went to the Privacy and Security tab in the Preferences, and clicked on “View Certificates”.
  2. I exported the GlobalSign Root CA certificate to e.g. /tmp. There is more than one. Look for the one in the tree GlobalSign nv-sa.
  3. Then, the certificate needs to be put into the certificate folder of Citrix Workspace. For the sofware package I use, this is /usr/lib64/ICAClient/keystore/cacerts. Navigate in the terminal to this folder and copy the certificate file in it. Then use chown root:root [file.crt] and chmod 444 [file.crt] to adapt file ownership and properties.

Afterwards, Citrix Workspace worked for me. If I have too much time, I will try to use the vendor package and see if I still get the segfault considering that I have now openssl 1.0.0 installed.

Exchanging Data between Citrix Host and Citrix Client

There are two options to get data from your host OS to your Citrix client:

  1. Clipboard: Copy’n’paste of text from the host to the client is suppoted on Linux. It did not work for me with files.
  2. Mapping client devices: folders from the host can be mapped in the client as distinct drives. This is very useful to exchange files between host and client. To configure this option, launch from the startmenu “Citrix Receiver (configmgr)”. Alternatively, the tool can be launched from the command line with /usr/lib64/ICAClient/util/configmgr -icaroot /usr/lib64/ICAClient. In the tool, mappings are configured in the tab file access.

Update 2021

At some point, the setup broke due to an expiring SSL certificate I believe. After some time trying, I ended up with the following easy setup:

  1. deinstall the outdated version: zypper rm ICAClient
  2. go to https://www.citrix.com/downloads/workspace-app/linux/workspace-app-for-linux-latest.html and downoad the rpm. In my case it was ICAClient-suse-21.1.0.14-0.x86_64.rpm
  3. install the rpm with e.g. zypper install [your folder]/ICAClient-suse-21.1.0.14-0.x86_64.rpm
  4. try to open a file. In my case, I got a “SSL error 61” (see Citrix help)
  5. I renamed the Citrix cacert storage: mv /opt/Citrix/ICAClient/keystore/cacerts{,~}
  6. I linked in the system storage: ln -sv /etc/ssl/certs /opt/Citrix/ICAClient/keystore/cacerts

This did the trick!

References

the avatar of Ish Sookun

DRM Plugin crashes after openSUSE Tumbleweed update

A few days ago openSUSE users started complaining about DRM Plugin crashes in Firefox after running a Tumbleweed update.

Netflix requires the DRM plugin in Firefox to be able to play encrypted videos. The plugin would crash due to a bug in Firefox 73. While this bug affected not just openSUSE users, but everyone using Firefox 73, it became apparent to TW users as v73 landed in the Tumbleweed repo.

Mozilla fixed the bug in the 73.0.1 release. I tweeted about that a little more than a week ago.

Firefox 73.0.01 is now available in the Tumbleweed repo. So, a quick update should fix your Netflix. 😉

Information for package MozillaFirefox:
---------------------------------------
Repository     : openSUSE-Tumbleweed-Oss                 
Name           : MozillaFirefox                          
Version        : 73.0.1-1.1                              
Arch           : x86_64                                  
Vendor         : openSUSE                                
Installed Size : 186.7 MiB                               
Installed      : Yes                                     
Status         : out-of-date (version 73.0-1.1 installed)
Source package : MozillaFirefox-73.0.1-1.1.src           
Summary        : Mozilla Firefox Web Browser             
Description    :                                         
    Mozilla Firefox is a standalone web browser, designed for standards
    compliance and performance.  Its functionality can be enhanced via a
    plethora of extensions.
the avatar of Flavio Castelli

Semantic versioning and containers

Developers are used to express the dependencies of their programs using semantic versioning constraints.

For example a Node.js application relying on left-pad could force only certain versions of this library to be used by specifying a constraint like >= 1.1.0 < 1.2.0. This would force npm to install the latest version of the library that satisfies the constraint.

How does that translates to containers?

Imagine the following scenario: a developer deploys a containerized application that requires a Redi database. The developer deploys the latest version of the redis container (eg: redis:4.0.5), ensures his application works fine and then moves to do other things.

After some weeks a security issue/bug is found inside of Redis and a new patched release takes place. Suddenly the deployed container is outdated. How can the developer be aware a new v4 release of Redis is available? Wouldn’t be even better to have some automated tool taking care of this upgrade?

After some more weeks a new minor release of Redis is released (eg: 4.1.0). Is it safe to automatically update to a new minor release of Redis, is the developer application going to work as expected?

Some container images have special tags like v4 or v4.1 and the developer could just leverage them to kinda pinpoint the redis container to a more delimited set of versions. However using these tags reduces reproducibility and debuggability.

Let’s imagine the redis image being deployed is redis:v4.1 and everything is working as expected. Assume after some time the developer (or some automated tool) pulls a new version of the redis:v4.1 image and suddenly the application has some issues. How can the developer understand what really changed? Wouldn’t it be great to be able to say something like “everything worked fine with redis:4.1.0 but it broke when I upgraded to redis:4.1.9”?

There are some tools that can be used to find and automatically update old container images: Watchtower and ouroboros. However none of them allows the flexibility I was looking for (in terms of checks), plus they are both tailored to work only against docker.

Because of that, during the 2020 edition of SUSE Hackweek, I spent some time working on a different solution to this use case.

Introducing fresh-container

fresh-container is a tool that can be used to see if a container can be updated to a more recent release.

fresh-container is different compared to Watchtower and ouroboros because it relies on semantic versioning to process container image tags.

Semantic versioning is used to express the version constraints a container version must satisfy. This gives more flexibility, for example take a look at the following scenarios:

  • I’m fine with any release of Redis that is part of the v4 code stream: >= 4.0.0 < 5.0.0
  • I’m fine only with patch releases of Redis that belong to the 4.1 code stream: >= 4.1.0 < 4.2.0
  • I’m don’t want any release of Redis after v6: < 6.0.0

CLI mode

fresh-container can be run as a standalone program:

$ fresh-container check --constraint ">= 1.9.0 < 1.10.0" nginx:1.9.0

The 'docker.io/library/nginx' container image can be upgraded from the '1.9.0' tag to the '1.9.15' one and still satisfy the '>= 1.9.0 < 1.10.0' constraint.

Behind the scenes fresh-container will query the container registry hosting the image to gather the list of all the available tags. The tags that do not respect semantic versioning will be ignored and finally the tool will evaluate the constraint provided by the user.

It can also generate computer parsable output by producing a JSON response:

$ fresh-container check -o json --constraint ">= 1.9.0 < 1.10.0" nginx:1.9.0

{
  "image": "docker.io/library/nginx",
  "constraint": ">= 1.9.0 < 1.10.0",
  "current_version": "1.9.0",
  "next_version": "1.9.15",
  "stale": true
}

Server mode

Querying the remote container registries to fetch all the available tags of a container image is an expensive operation. That gets even worse when multiple containers have to be inspected on a regular basis.

The fresh-container binary can operate in a server mode to alleviate this issue:

$ fresh-container server

This will start a web server offering a simple REST API that can be used to perform queries. The remote tags of the container images are cached inside of an in-memory database to speed up constraint resolution.

It’s possible to run fresh-container check against a fresh-container server to perform faster queries by using the --server <http://fresh-container-server> flag.

Kubernetes integration

fresh-container is a tool built to serve one specific use case: your provide some data as input and, as output, it will tell you if the container image can be updated to a more recent version.

It’s main goal is to be leveraged by other tools to build something bigger like fresh-container-operator.

This is a kubernetes operator that, once deployed inside of a kubernetes cluster, will look at all the kubernetes deployments running inside of it and finds the ones having stale containers.

The operator can also automatically update these outdated deployments to use the latest version of the container images that satisfy their requirements.

Usage

How does it work? First of all you have to enrich your deployment definition by adding some ad-hoc annotations.

For each container image used by the deployment you have to specify the semantic versioning constraint that has to be used to evaluate their “freshness”.

Take a look at the following example:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx-deployment
  annotations:
    fresh-container.autopilot: "false"
spec:
  selector:
    matchLabels:
      app: nginx
  replicas: 1
  template:
    metadata:
      labels:
        app: nginx
      annotations:
        fresh-container.constraint/nginx: ">= 1.9.0 < 1.10.0"
    spec:
      containers:
      - name: nginx
        image: nginx:1.9.0
        ports:
        - containerPort: 80

In this case the operator will look at the version of the nginx container in use and evaluate it against the >= 1.9.0 < 1.10.0 constraint.

Note well: deployments that do not have any fresh-container.constraint/<container name> will be ignored by the operator.

Find stale deployments

The operator adds the special label fresh-container.hasOutdatedContainers=true to all the deployments that have one or more stale containers inside of them.

This allows quick searches against all the deployments:

$ kubectl get deployments --all-namespaces -l fresh-container.hasOutdatedContainers=true
NAMESPACE   NAME               READY   UP-TO-DATE   AVAILABLE   AGE
default     nginx-deployment   1/1     1            1           19m

Why is a deployment stale?

The details about the stale containers are added by the operator as annotations of the deployment:

kubectl describe deployments.apps nginx-deployment
Name:                   nginx-deployment
Namespace:              default
CreationTimestamp:      Thu, 27 Feb 2020 10:32:55 +0100
Labels:                 fresh-container.hasOutdatedContainers=true
Annotations:            deployment.kubernetes.io/revision: 1
                        fresh-container.autopilot: false
                        fresh-container.lastChecked: 2020-02-27T09:45:07Z
                        fresh-container.nextTag/nginx: 1.9.15

For each stale container the operator adds an annotation with fresh-container.nextTag/<container name> as key and the tag of the most recent container that satisfies the constraint as value.

In the example above you can see that the nginx container inside of the deployment can be updated to the 1.9.15 tag while still satisfying the >= 1.9.0 < 1.10.0 constraint.

Automatic upgrades

The next step is to allow fresh-container-operator to update all the deployments that have stale containers.

This is not done by default, but can be enable on a per-deployment basis by adding the fresh-container.autopilot=true annotation inside of the deployment metadata.

What comes next

As I stated in the beginning I created these projects during the 2020 edition of SUSE Hackweek. They are early prototypes that need more love.

I would be happy to hear what you think about them. Feel free to leave a comment below or open an issue on their GitHub projects:

the avatar of openSUSE News

Moving to the new News

In an effort to make contributing to openSUSE easier, openSUSE News has moved from being a Wordpress application to a Jekyll static site developed directly on Github. Now you too can write an article, or a series of articles, by sending pull requests to the openSUSE/news-o-o repository.

How to do it

The repository contains _posts directory, that’s where you will upload your own markdown formatted post, following the structure of other posts in the folder. Additionally, you can upload your images to assets/images directory, and reference them from the post.

After you pull request a post like that, the marketing team will review and, if needed, suggest improvements. A successfully reviewed post will be merged into the repository and published at the date specified by the post itself.

the avatar of openSUSE News

Leap 15.2 Enters Beta Builds Phase

openSUSE Leap 15.2 entered the Beta phase last week and has already released two snapshots with the release of build 581.2 and build 588.2. Leap has a rolling development model until it’s final build, so multiple builds will be released according to the road map until the gold master is released, which is scheduled for May 7.

There are no concrete milestones in the rolling development model. As bugs are fixed and new packages introduced or excluded, snapshots of the latest beta phase builds will be released once they pass openQA testing.

After the gold master is released, the rolling development model will stop and maintenance and security updates will then be released for the new minor version of the Leap 15 series.

The alpha phase has been ongoing for several months now and builds have been released regularly on a rolling basis. The alpha was stable enough to use for demos at FOSDEM, but testing is still needed.

Distro hoppers, hobbyists, users and tech enthusiast can download the current builds and help test the releases at software.opensuse.org/distributions/testing. People testing the beta are encouraged to

Record their Leap Beta testing effort on the following spreadsheet: https://docs.google.com/spreadsheets/d/1AGKijKpKiJCB616-bHVoNQuhWHpQLHPWCb3m1p6gXPc/edit#gid=801313279

Leap Beta testers have an option to receive a T-shirt, so make sure to fill in all the proper information and bug reports to get one.

In the email announcement notifying the community about Leap entering the beta phase, Leap’s new release manager, Luboš Kocman stated the release team is working on a 15.1 upgrade test suite to get decent upgrade test results.

“So any manual upgrade effort would be extremely valuable,” Luboš Kocman wrote.

Kocman also highlighted Windows Subsystem for Linux and said the hard work put in for WSL images has risen it to a first-class citizen in both the Open Build Service and openQA.

Those interested in Beta testing of openSUSE Leap 15.2 WSL images can contact Kocman or the factory mailing list. For more information on WSL, visit https://en.opensuse.org/openSUSE:WSL.

a silhouette of a person's head and shoulders, used as a default avatar

openSUSE Tumbleweed – Review of the week 2020/08

Dear Tumbleweed users and hackers,

After a week of hacking on different stuff and being in the background for Tumbleweed while Oliver took on the role of Release Manager, I am back with you. And we have released three snapshots this week (0214, 0218 and 0219). The gap between 0214 and 0218 was the integration of glibc 2.31. But of course, there was more happening this week. So here comes the list:

  • glibc 2.31
  • Mozilla Firefox 73.0
  • KDE Frameworks 5.67.0
  • Linux kernel 5.5.4
  • PostgreSQL 12.2
  • MicroOS Desktops are available as part of the MicroOS DVD installer

Things you can expect come to a snapshot in the (hopefully not too far) future:

  • zsh 5.8 (Snapshot 0220+)
  • libcap 2.30 (snapshot 0221+)
  • GNOME 3.34.4
  • llvm 6 will be removed from the repository
  • Linux kernel 5.5.5
  • KDE Plasma 5.18.1
  • Ruby 2.7 – possibly paired with the removal of Ruby 2.6
  • GCC 10
  • Python 3.8 (unchanged, awaiting the fix for salt)
  • Removal of Python 2
  • GNU Make 4.3
  • RPM: change of database format to ndb

the avatar of openSUSE News

Plasma, NodeJS, pip, Grep update in Tumbleweed

Three openSUSE Tumbleweed snapshots arrived this week and the snapshots provided a few major version upgrades and several minor updates with newer features.

The latest snapshot was 20200218. This snapshot updated a subpackage for btrfsprogs to version 5.4.1 and fixes the docbook5 builds. The Linux Kernel updated to 5.5.4 and had a few changes for KVM on arm64. The update of glibc 2.31 now supports a feature test macro [_ISOC2X_SOURCE](https://gitlab.com/freedesktop-sdk/mirrors/sourceware/glibc/-/commit/777d75fbc07b98115f4868c3290eb8a5d1f3a5b2) to enable features from the draft ISO C2X standard. Command line utility grep 3.4 fixed some performance bugs and adds a new –no-ignore-case option that causes grep to observe case distinctions, overriding any previous -i (–ignore-case) option. The DBus-activated daemon controlling mobile devices and connections, ModemManager fixed the handling of hexadecimal 0x00 bytes at the end of GSM encoded strings in version 1.12.6. There were several other packages updated in the snapshot. Among the packages to be updated were flatpak 1.6.2, GNOME’s web browser epiphany 3.34.4, email client mutt 1.13.4, strace 5.5, sudo 1.8.31 and whois 5.5.5. With less than a week to go until a rating is finalized, a rating of 92 was initially released for the snapshot, according to the snapshot reviewer.

Snapshot 20200214 updated both Mozilla Firefox and Thunderbird to versions 73.0 and 68.5 respectively. The new major version of the browser addressed six Common Vulnerabilities and Exposures (CVE) that included one bug fix that affected the memory. The new release includes new features that help users view and read website content more easily by enhancing the page zoom feature. The version also added NextDNS as an alternative option for DNS over HTTPS. The Thunderbird email client addressed seven CVEs and added support for client Identity IMAP/SMTP Service Extension and for OAuth 2.0 authentication for POP3 accounts. KDE users had multiple package updates from Plasma Framework 5.67.0; Kirigami removed the header top margin from private ScrollView and properly expanded the fillWidth items in mobile mode. The KTextEditor fixed the drag and copy function, and the framework’s package also fixed a crash in the variable expansion with the use of external tools. The package for the JavaScript runtime environment, nodejs12 updated to version 12.16.0 added a new core module for a WebAssebly System Interface as an experimental feature. The NodeJS version also added Hash.prototype.copy making it possible to clone an internal state of Hash object. Text editor nano 4.8 improved the handling of lock files on start-up. Two other major version updates in the snapshot were python-packaging 20.1 and python-pip 20.0.2;  the new pip version switches to a dedicated command-line interface tool for vendoring dependencies and the changelog points out that the wheel cache is not retro-compatible with previous versions and that pip will continue to take advantage of existing legacy cache entries until pip 21.0 is released. Version control tool mercurial 5.3 fixed some bugs and added a new Large File Storage experimental feature. The utilities package for controlling TCP / IP networking and traffic control in Linux, iproute2, updated to version 5.5.0, which added four patches and a new timestamp format. Other packages that updated in the snapshot were babl 0.1.74, ccache 3.7.7 and gegl 0.4.20. The snapshot is currently trending moderately stable at a rating of 80, according to the Tumbleweed snapshot reviewer.

A little more than half a dozen packages were updated in snapshot 20200213. The interactive Python accessibility explorer package accerciser 3.34.4 updated translations and documented a new python-xlib dependency. The update elfutils 0.178 package fixed variable references in specfile and added a RISC-V disassembler. Windows Server 2019 support was added with the update of vm-install 0.10.08. The snapshot recorded a moderately stable rating of 75, according to the Tumbleweed snapshot reviewer.

The previous week’s 20200211 snapshot recorded a rating of 71 and brought KDE’s plasma5-desktop 5.18.0, which will be the version in openSUSE Leap 15.2 when it’s released. The new Plasma 5.18 Long Term Support (LTS) is even more user-friendly and filled with more features. The new Emoji Selector is just two keystrokes away. Hold down the Meta key and press the period (.) and it will pop up. The version also provides a new Night Color feature to relax users eyesight. KDE Applications was also updated in the snapshot. The 19.12.2 version update provided a big release of KDevelop 5.5, which is the Integrated Development Environment (IDE) that makes writing programs in C++, Python and PHP easier. . PHP gets PHP 7.4’s typed properties and support was added for array of type and class constant visibility. In Python, support was added for Python 3.8.

the avatar of Will Stephenson

It is time for a war on tabs

5 different tab bar UIs, 4 of which are KDE

We (as a UI shell project) see the limits of our territory as the window, when there is the assumption nowadays that MDI tabbed interfaces are where most significant user activity takes place. Yet interacting with different views/documents within those windows is not standardised, so the user has to remember which app they are using, then select the appropriate actions to:

  • recognise the current tab
  • switch tabs
  • move tabs in the current window or between windows
  • notice which tab is being switched to (different switcher UIs, not shown)
  • open/close tabs
  • be warned when closing a window with multiple tabs
  • use keyboard shortcuts to switch tabs
  • persist tabs between logins
  • share sets of tabs between devices
All this causes additional cognitive load/dissonance when using your computing device.

I'm not saying Plasma needs to become a tabbed window manager, but we can do better, and it is definitely time to declare war on the mess above.

the avatar of Ish Sookun

oSLO Conference 🐧

oSLO is short for openSUSE + LibreOffice.

The two projects are celebrating their 15ᵗʰ and 10ᵗʰ anniversary respectively in 2020. To mark the occasion, openSUSE and LibreOffice projects are organizing a joint conference from 13ᵗʰ to 16ᵗʰ October 2020 in Nuremberg, Germany. The conference will take place at Z-bau (Frankenstraße 200). It is the same location where last year's openSUSE Conference was held.

openSUSE and LibreOffice conferences are meant to bring like minded people together to discuss about topics relative to the projects. People can learn, teach and share their passion about the projects.

Last September, openSUSE announced a logo design competition for this co-conference with LibreOffice. Early this month the winner of the competition was announced. Kukuh Syafaat from Indonesia won the hearts of the co-conference organizing team.

Logo design by Kukuh Syafaat for oSLO Conference, Nuremberg.

The conference is free to attend. Mark you calendar & join the fun!

Call for Papers

The organizing team is currently accepting proposals for sessions. The deadline for submission is 21 July 2020.