Running openSUSE in a FreeBSD jail using Bastille
Why?
Last week, when the latest version of Bastille, a jail (container) management system for FreeBSD was released, it also included experimental Linux support. Its author needed Ubuntu, so that was implemented. I prefer openSUSE, so with some ugly hacks I could get openSUSE up and running in Bastille. I was asked to document it in a blog. This topic does not fit the sudo or syslog-ng blogs, where I regularly contribute. However it involves two of my favorite operating systems: FreeBSD, which I started to use in 1994 and (open)SUSE, which I started to use in 1996. This is how my personal blog was born after years of procrastination :-)
Note. OpenSUSE in a FreeBSD jail is barely usable. The way I installed it is an ugly hack, even in my own view. But it works, and some people might find it useful…
Some preparations
First of all, you need FreeBSD and you need the latest Bastille installed. I do not know if this version is already available in FreeBSD ports, I installed it using git based on the instructions on the Bastille documentation at: https://bastille.readthedocs.io/en/latest/chapters/installation.html#git.
Before going on to play with Linux I made sure that everything works with Bastille as expected. So, I followed my blog from earlier and created a syslog-ng jail using Bastille: https://www.syslog-ng.com/community/b/blog/posts/running-syslog-ng-in-bastille-revisited Note, that /usr/local/etc/bastille/bastille.conf is not installed when installing from git. Copy /usr/local/etc/bastille/bastille.conf.sample to bastille.conf
Once I made sure that Bastille works fine with FreeBSD jails, the next step was to get Ubuntu working. Just as with FreeBSD-based jails in Bastille, first you need to bootstrap it. If Linux support is not yet enabled, Bastille can do that for you: modify configuration files and load the necessary kernel modules.
root@fb130:~ # bastille bootstrap focal
sysrc: unknown variable 'linprocfs_load'
sysrc: unknown variable 'linsysfs_load'
sysrc: unknown variable 'tmpfs_load'
linprocfs_load, linsysfs_load, tmpfs_load not enabled in /boot/loader.conf or linux_enable not active. Should I do that for you? (N|y)
y
Loading modules
kldload: can't load tmpfs: module already loaded or in kernel
Persisting modules
linux_enable: NO -> YES
linprocfs_load: -> YES
linsysfs_load: -> YES
tmpfs_load: -> YES
W: Probably required module fdescfs is not loaded
I: Retrieving InRelease
I: Retrieving Packages
I: Validating Packages
I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on http://archive.ubuntu.com/ubuntu...
I: Retrieving adduser 3.118ubuntu2
I: Validating adduser 3.118ubuntu2
I: Retrieving apt 2.0.2
[...]
Now you can create your first Linux-based jail to test that everything works as expected:
root@fb130:~ # bastille create -L ubuntu focal 10.17.89.51
Valid: (10.17.89.51).
[ubuntu]:
ubuntu: created
Fetching packages...
Selecting previously unselected package adduser.
(Reading database ... 0 files and directories currently installed.)
Preparing to unpack .../adduser_3.118ubuntu2_all.deb ...
Unpacking adduser (3.118ubuntu2) ...
[...]
Get:3 http://archive.ubuntu.com/ubuntu focal/main Translation-en [506 kB]
Fetched 1741 kB in 1s (1841 kB/s)
Reading package lists... Done
Building dependency tree... Done
All packages are up to date.
Verify that the second jail is up and running:
root@fb130:~ # jls
JID IP Address Hostname Path
2 10.17.89.50 alcatraz /usr/local/bastille/jails/alcatraz/root
3 10.17.89.51 ubuntu /usr/local/bastille/jails/ubuntu/root
root@fb130:~ #
You can now reach the console, install software and enjoy your first Linux jail in Bastille.
root@fb130:~ # bastille console ubuntu
[ubuntu]:
Welcome to Ubuntu 20.04 LTS (GNU/Linux 3.17.0 x86_64)
* Documentation: https://help.ubuntu.com
* Management: https://landscape.canonical.com
* Support: https://ubuntu.com/advantage
Last login: Sun Jul 25 19:32:28 UTC 2021 on pts/0
root@ubuntu:~# uname -a
Linux ubuntu 3.17.0 FreeBSD 13.0-RELEASE-p3 #0: Tue Jun 29 19:46:20 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
root@ubuntu:~# apt-get install python3-bs4
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following additional packages will be installed:
libxslt1.1 python3-chardet python3-html5lib python3-lxml python3-soupsieve python3-webencodings
[...]
Installing openSUSE
There is no dedicated installation method yet for openSUSE. And I am not aware of a tool similar to debootstrap for openSUSE, that could bootstrap a distribution. Instead of that I downloaded a ready to use openSUSE operating system image and replaced the content of the Ubuntu directory under /usr/local/bastille/releases/Ubuntu_2004 with the openSUSE image.
root@fb130:~ # cd /usr/local/bastille/releases/
root@fb130:/usr/local/bastille/releases # ls
13.0-RELEASE Ubuntu_2004
root@fb130:/usr/local/bastille/releases # mv Ubuntu_2004 Ubuntu_2004.orig
root@fb130:/usr/local/bastille/releases # mkdir Ubuntu_2004
root@fb130:/usr/local/bastille/releases # wget http://download.opensuse.org/distribution/leap/15.3/appliances/opensuse-leap-dnf-image.x86_64-lxc-dnf.tar.xz
--2021-07-26 22:36:42-- http://download.opensuse.org/distribution/leap/15.3/appliances/opensuse-leap-dnf-image.x86_64-lxc-dnf.tar.xz
Resolving download.opensuse.org (download.opensuse.org)... 195.135.221.134, 2001:67c:2178:8::13
Connecting to download.opensuse.org (download.opensuse.org)|195.135.221.134|:80... connected.
HTTP request sent, awaiting response... 302 Found
Location: http://downloadcontent.opensuse.org/distribution/leap/15.3/appliances/opensuse-leap-dnf-image.x86_64-15.3.0-lxc-dnf-Build9.150.tar.xz [following]
--2021-07-26 22:36:42-- http://downloadcontent.opensuse.org/distribution/leap/15.3/appliances/opensuse-leap-dnf-image.x86_64-15.3.0-lxc-dnf-Build9.150.tar.xz
Resolving downloadcontent.opensuse.org (downloadcontent.opensuse.org)... 195.135.221.157, 2001:67c:2178:8::27
Connecting to downloadcontent.opensuse.org (downloadcontent.opensuse.org)|195.135.221.157|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 45147784 (43M) [application/octet-stream]
Saving to: ‘opensuse-leap-dnf-image.x86_64-lxc-dnf.tar.xz’
opensuse-leap-dnf-image.x86_64-lxc-dnf.tar.xz 100%[=========================================================================================================================================>] 43.06M 10.7MB/s in 4.3s
2021-07-26 22:36:46 (10.1 MB/s) - ‘opensuse-leap-dnf-image.x86_64-lxc-dnf.tar.xz’ saved [45147784/45147784]
root@fb130:/usr/local/bastille/releases # cd Ubuntu_2004
root@fb130:/usr/local/bastille/releases/Ubuntu_2004 # tar xf ../opensuse-leap-dnf-image.x86_64-lxc-dnf.tar.xz
There are more images available on the openSUSE download site, but the above one seemed to be small enough and still contain package management. It is the latest stable release, Leap 15.2 is still available and Tumbleweed provides you with a cutting edge rolling-release distribution.
Next, create another jail based on the Ubuntu image, which in practice contains now openSUSE. There will be plenty of error messages, as the script tries to run Debian package management tools, but in the end there will be an openSUSE image up and running:
root@fb130:~ # bastille create -L opensuse focal 10.17.89.52
Valid: (10.17.89.52).
[opensuse]:
opensuse: created
Fetching packages...
rm: cannot remove '/var/cache/apt/archives/rsyslog*.deb': No such file or directory
/bin/bash: dpkg: command not found
/bin/bash: dpkg: command not found
/bin/bash: apt: command not found
root@fb130:~ #
You can verify that something is up and running:
root@fb130:~ # jls
JID IP Address Hostname Path
1 10.17.89.50 alcatraz /usr/local/bastille/jails/alcatraz/root
2 10.17.89.51 ubuntu /usr/local/bastille/jails/ubuntu/root
3 10.17.89.52 opensuse /usr/local/bastille/jails/opensuse/root
Unfortunately the bastille console command does not work with openSUSE. Not even after the missing dependencies are installed. You can still access the running jail using jexec. In this case the command is, where 3 is the JID:
root@fb130:~ # jexec 3 /bin/bash
opensuse:/ # uname -a
Linux opensuse 3.17.0 FreeBSD 13.0-RELEASE-p3 #0: Tue Jun 29 19:46:20 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
opensuse:/ # dnf update
openSUSE Leap 15.3 - OSS 0.0 B/s | 0 B 00:00
Errors during downloading metadata for repository 'opensuse-leap-oss':
- Curl error (6): Couldn't resolve host name for http://download.opensuse.org/distribution/leap/15.3/repo/oss/repodata/repomd.xml [Could not resolve host: download.opensuse.org]
Error: Failed to download metadata for repo 'opensuse-leap-oss': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
openSUSE Leap 15.3 - OSS - Updates 0.0 B/s | 0 B 00:00
Errors during downloading metadata for repository 'opensuse-leap-oss-update':
- Curl error (6): Couldn't resolve host name for http://download.opensuse.org/update/leap/15.3/oss/repodata/repomd.xml [Could not resolve host: download.opensuse.org]
Error: Failed to download metadata for repo 'opensuse-leap-oss-update': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
openSUSE Leap 15.3 - Updates from Backports for SUSE Linux Enterprise 0.0 B/s | 0 B 00:00
Errors during downloading metadata for repository 'opensuse-leap-sle-backports-update':
- Curl error (6): Couldn't resolve host name for http://download.opensuse.org/update/leap/15.3/backports/repodata/repomd.xml [Could not resolve host: download.opensuse.org]
Error: Failed to download metadata for repo 'opensuse-leap-sle-backports-update': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
openSUSE Leap 15.3 - Updates from SUSE Linux Enterprise 0.0 B/s | 0 B 00:00
Errors during downloading metadata for repository 'opensuse-leap-sle-update':
- Curl error (6): Couldn't resolve host name for http://download.opensuse.org/update/leap/15.3/sle/repodata/repomd.xml [Could not resolve host: download.opensuse.org]
Error: Failed to download metadata for repo 'opensuse-leap-sle-update': Cannot download repomd.xml: Cannot download repodata/repomd.xml: All mirrors were tried
Ignoring repositories: opensuse-leap-oss, opensuse-leap-oss-update, opensuse-leap-sle-backports-update, opensuse-leap-sle-update
allow_vendor_change is disabled. This option is currently not supported for downgrade and distro-sync commands
Dependencies resolved.
Nothing to do.
Complete!
As you can see, networking does not work either. It’s a missing /etc/resolve.conf, which is easy to resolve (pun intended):
root@fb130:~ # cp /etc/resolv.conf /usr/local/bastille/jails/opensuse/root/etc/
root@fb130:~ #
Now you can jexec again into the openSUSE jail, install software packages and enjoy :)
opensuse:/ # dnf install python3-beautifulsoup4
Last metadata expiration check: 0:03:34 ago on Mon Jul 26 21:02:50 2021.
allow_vendor_change is disabled. This option is currently not supported for downgrade and distro-sync commands
Dependencies resolved.
==============================================================================================================================================================================================================================================
Package Architecture Version Repository Size
==============================================================================================================================================================================================================================================
Installing:
python3-beautifulsoup4 noarch 4.8.2-1.18 opensuse-leap-oss 191 k
Installing dependencies:
python3-soupsieve noarch 1.9.5-1.17 opensuse-leap-oss 68 k
Transaction Summary
==============================================================================================================================================================================================================================================
Install 2 Packages
Total download size: 259 k
Installed size: 1.3 M
Is this ok [y/N]: y
Downloading Packages:
(1/2): python3-soupsieve-1.9.5-1.17.noarch.rpm 444 kB/s | 68 kB 00:00
(2/2): python3-beautifulsoup4-4.8.2-1.18.noarch.rpm 1.2 MB/s | 191 kB 00:00
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Total 1.5 MB/s | 259 kB 00:00
Running transaction check
Transaction check succeeded.
Running transaction test
Transaction test succeeded.
Running transaction
Preparing : 1/1
Installing : python3-soupsieve-1.9.5-1.17.noarch 1/2
Installing : python3-beautifulsoup4-4.8.2-1.18.noarch 2/2
Verifying : python3-beautifulsoup4-4.8.2-1.18.noarch 1/2
Verifying : python3-soupsieve-1.9.5-1.17.noarch 2/2
Installed:
python3-beautifulsoup4-4.8.2-1.18.noarch python3-soupsieve-1.9.5-1.17.noarch
Complete!
What is next?
I’m still not convinced how useful it is, but you can run openSUSE on FreeBSD using Bastille. You can try other openSUSE images, install more software in the jail, etc. Note, that Linux support is still experimental in Bastille, and running openSUSE is an ugly hack. But as this hack lets me run my two favorite operating systems together, I love this hack :-)
Syslog-ng 3.33: the MQTT destination
Version 3.33 of syslog-ng introduced an MQTT destination. It uses the paho-c client library to send log messages to an MQTT broker. The current implementation supports version 3.1 and 3.1.1 of the protocol over non-encrypted connections, but this is only a first step.
From this blog, you can learn how to configure and test the mqtt() destination in syslog-ng.
Before you begin
To use the MQTT destination of syslog-ng, you need to use at least syslog-ng version 3.33. It is not yet included in most Linux distributions, but luckily it is available in some 3rd-party syslog-ng repositories. You can find a list of them at https://www.syslog-ng.com/products/open-source-log-management/3rd-party-binaries.aspx MQTT support is usually included in a sub-package of syslog-ng, often called syslog-ng-mqtt. You also need an MQTT broker, where you can forward log messages using the mqtt() destination.,
For my tests, I used Fedora 34 with the Mosquitto MQTT broker and syslog-ng installed from the unofficial Copr repository.
Configuring syslog-ng
If your distribution of choice supports it, create a new configuration file under the /etc/syslog-ng/conf.d/ directory with a .conf extension. Otherwise, append the configuration below to syslog-ng.conf.
destination d_mqtt {
mqtt (
address("tcp://localhost:1883"),
topic("test/$HOST"),
fallback-topic("syslog/fallback")
template("$MESSAGE")
qos(1)
);
};
log {
source(s_sys);
destination(d_mqtt);
};
The MQTT destination has three mandatory options:
-
address() defines where to send log messages: it includes the hostname (or IP address) and the port number of the MQTT broker. These values work if the broker is running on localhost at the default port.
-
topic() defines in which topic syslog-ng stores the log message. You can also use templates here, and use, for example, the $HOST macro in the topic name hierarchy.
-
fallback-topic() is used when syslog-ng cannot post a message to the originally defined topic (which can include invalid characters coming from templates).
Optional parameters of the MQTT destination include:
-
template(), where you can configure the message template sent to the MQTT broker. By default, the template is: “$ISODATE $HOST $MSGHDR$MSG”
-
qos stands for quality of service and can take three values in the MQTT world. Its default value is 0, where there is no guarantee that the message is ever delivered. Setting it to 1 makes sure that the message is delivered at least once, while 2 ensures that a message is delivered exactly once. Obviously, 0 has the best performance, while 2 can be much slower.
The log statement connects the local log sources with the MQTT destination. Note, that the name of the source might be different, depending on syslog-ng.conf. Configurations on Fedora and RHEL call the local log source s_sys, by default.
Testing
As mentioned in the introduction, I used the Mosquitto MQTT broker for testing. There are dozens of others listed at https://mqtt.org/software/, verifying incoming messages is different for each software.
Once you reloaded syslog-ng to ensure that the configuration takes effect, you are ready for testing. We use two utilities for testing:
-
logger sends syslog messages to the local server
-
mosquitto_sub is part of the Mosquitto MQTT broker software and can subscribe to messages arriving on a broker
First start mosquitto_sub in a terminal:
mosquitto_sub -h localhost -p 1883 -t 'test/+'
This will listen to incoming messages on the broker on all subtopics under the “test” topic. “+” is a wildcard here.
Next, you can send some log messages using the logger command:
logger this is a test
And you should see the line appear in the output of mosquitto_sub:
2021-07-26T16:39:55+02:00 fedora34.localdomain root[3077]: this is a test
What is next?
This is just the first step in adding MQTT support to syslog-ng. Your feedback is very welcome about this new feature. Detailed problem reports help to make the next version more robust while positive feedback lets us know that the feature is in use and it is worth developing it further.
-
If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/syslog-ng/syslog-ng. On Twitter, I am available as @Pczanik.
Digest of YaST Development Sprints 127 & 128
It’s summer in Europe and that means vacations for most members of the YaST Team at SUSE. Although that may imply less frequent blogging, we have some news to share with you today, like:
- Taking over the development of the (open)SUSE Release Tools
- Improvements in the new
check-profilecommand - Finished migration from Travis CI to GitHub Actions
- Several interesting bug fixes
Let’s go into some details
Release Tools: YaST Team to the Rescue!
As you all know, developing and maintaining complex software distributions like openSUSE Leap, Tumbleweed or SUSE Linux Enterprise is not an easy task. Specially since we want to ensure all of them stay independent but at the same time closely related, and since they keep evolving in new directions like Kubic, MicroOS and SLE Micro.
Our beloved Open Build Service is the key component that makes all that possible. But some extra tools are needed in addition to OBS in order to manage the complexity of the (open)SUSE distributions. Those extra tools are hosted and developed in a GitHub repository simply called openSUSE-release-tools. For years, the development process of those tools has been highly unstructured (not to say “slightly chaotic”), with more than 60 contributors but no clear mid-term strategy. Although that is not necessarily bad, some sustained and directed development is needed to solve some of the challenges we have ahead of us and to fix some pitfalls in the current development process of the openSUSE and SUSE products and distributions.
The YaST Team was chosen for such a task, so we will steadily take over development and maintenance
of the tools in that repository. As first steps, we improved a lot the documenation. That includes
extending the README
file and adding new
documents like an inventory of
tools and a summary of
the processes in
which those tools are involved. We also extended and updated the automated tests and implemented
an easy new check in the factory-auto bot.
We have way more ambitious plans for the future, but we are still learning and discovering new stuff in that repository every day.
Improvements in the AutoYaST Profile Validation
As you may know, we recently introduced a YaST client to validate complex profiles that include Embedded Ruby, rules and classes and/or scripts. Generally, such a validation could be done without root permissions, but there are some situations where superuser privileges are required.
To mitigate the implications, we introduced several improvements in the check-profile tool. You
can see the details in the description of the corresponding pull
request.
From Travis CI to GitHub Actions - Migration Completed
Some months ago, we started switching the continuous integration on all YaST repositories from using Travis CI to GitHub Actions. The main reason was that GitHub Actions are directly integrated in GitHub so it is easier to use - no need for extra account, less problems with authentication or permissions…
The transition is finished now. It was easy because both services are quite similar, although
support for Docker is more straightforward in GitHub Actions. In this service, the actions are
defined in YAML files in the .github/workflows subdirectory. We created several
templates for the YaST packages.
If you want to know more, read the GitHub Actions documentation.
Interesting bug fixes
Although we spend a significant time of our sprints fixing bugs, we usually don’t blog about that part of the job because we understand is not the most exciting one. But this time we would like to highlight some pull request you may find interesting for several reasons. Including better handling of failures while analyzing the system, of variables in repository urls and of SSH authorized keys.
We keep working
As mentioned before, the YaST Team is not at full speed due to the vacation season. But we hope to keep delivering interesting stuff in many fronts and we will try to keep you all updated. Meanwhile, do as we do and have a lot of fun!
Deactivating connect.opensuse.org
Our community portal, reachable via https://connect.opensuse.org, accompanied our community now since 2010. A long, long time. Especially, if you compare it with Facebook (which started in 2006) or LinkedIn (who became an international company in 2010).
While Facebook and LinkedIn are meanwhile multi-billion dollar markets, our community portal is meanwhile mainly used to organize the openSUSE members and being a “contact point” for members, who provide their profiles to help others to contact them.
Over 20,000 actively registered users and 100 groups might give an idea about the diversity and agility of the openSUSE community. From artists to musicians over to local user groups and groups for all the different window managers and their lovers. Everyone found a place here in the openSUSE universe.
But time flies by quickly - and especially the technology sector never stands still. Today, we need to announce the final shut down of our community portal. The reason is simple: while we asked multiple times for help and someone who wants to actively maintain and administrate the service, nobody stepped up. As we can not secure the application any longer without big time investments, we decided to shut it down and let it rest in peace instead.
By doing this, we apologize for the trouble that this decision might cause to some people. We tried our best to support you over all the years by running the service as long as possible. But if nobody steps up and wants to take over the work any longer, it’s better to say ‘good bye’ instead to wait until the Hackers of the world share the data of our users.
An era comes to an end. A nice one, indeed. But it also means that there might be a new era on the horizon. Some new tools that have a maintainer and someone who takes care of them.
Look at our Forums, our Wikis, Mailing Lists or the new Matrix service. We will not stop to support you, we will do our best to keep you and your data secure.
The plan for membership management and applications to take place using Pagure.
Remember to have a lot of fun!
Lars - in the name of the openSUSE heroes -
openSUSE Tumbleweed – Review of the week 2021/29
Dear Tumbleweed users and hackers,
A new week full of Tumbleweed snapshots comes to an end. And we had one day without a new snapshot (not due to problems but there was simply nothing in the queue that would have passed staging). So, as a result, we have published 6 snapshots during this week (0715, 0716, 0717, 0718, 0720, and 0721).
The main changes included in those snapshots were:
- KDE Frameworks 5.84.0
- Mesa 21.1.5
- Mozilla Firefox 90.0 & Thunderbird 78.12.0
- Linux kernel 5.13.2
- GNOME 40.3
- libxcrypt 4.4.23: addition of CRYPT_SALT_METHOD_LEGACY
- meson 0.58.1
The things currently brewing in the staging projects are:
- Linux kernel 5.13.4
- systemd 248.5, will be followed by 249 shortly after
- meson 0.58.2
- binutils 2.37
- rpmlint 2.0
GNOME, Wireshark update in Tumbleweed
Since last Friday, five openSUSE Tumbleweed snapshots have been released.
GNOME 40, btrfs, Mesa, Wireshark and several other package updates landed this week in the rolling release.
The last snapshot posted to the openSUSE-Factory mailing list was 20210721. The snapshot contained updates for both GNOME 40 and the userspace utility to manage the btrfs file system; the btrfsprogs 5.13 package improved documentation, made some fixes and added preparations for the 5.14 Linux Kernel. GNOME 40 on the other hand had a slew of updates that focused on updating translations and bug fixing. A regression was fixed in the 40.3 gnome-maps package and the 40.3 gnome-software package fixed a crash that sometimes happened when clicking on a website button on a details page. Another crash that was fixed in gnome-terminal 3.40.3 affected the loading of the reference schema source, which failed. The 4.4.14 autoyast2 package now copies files to a correct location based on details listed at bsc#1188357. The text-sharpening package known as harfbuzz updated to version 2.8.2 and made various fixes and improvements to the subsetter. Other notable packages to update in the snapshot were yast2-users 4.4.4, text rendering package pango 1.48.7, system call tracer strace 5.13 and many others.
Just three packages were updated in snapshot 20210720. The cpupower 5.14 version included an upstream patch and made a speed select modification for Intel hardware. The other two packages to update were ibus-table-others 1.3.12, which updated some function keys, and the library openblas_pthreads 0.3.16, which had some architecture fixes and improvements for RISC-V.
Five packages updated in snapshot 20210718. Wireshark 3.4.7 fixed a Distributed Network Protocol dissector crash and a Common Vulnerability and Exposure. The mdevctl utility for managing devices updated to version 0.81 and fixed a defined aspect in the json file. A crash was fixed as well as an initialization error in the video codec library libaom 3.1.1. Both libslirp 4.6.0 and polkit-default-privs were also updated.
The 5.13.2 Linux Kernel has some bluetooth and Advanced Linux Sound Architecture fixes in snapshot 20210717. Mesa had a version bump to 21.1.5 in the snapshot, which was a minor bugfix release. The yast2 packages that were updated focused on security and the User Interface. Mozilla Firefox went CVE hunting and closed about nine vulnerabilities with its brand new 90 version; one of those was a memory safety bug. GTK2 support, which was used for a Flash plugin, was removed in the update of the browser. Mozilla also had an update of Thunderbird in the Tumbleweed snapshot. Just four CVEs were closed d in the release, which also fixed the memory safety bug that affected the release candidate for Firefox 90 and Firefox Extended Support Release 78.12.
The week started off with snapshot 20210716, which had more than a handful of Python Package Index updates; python-setuptools updated from version 44.1.1 to 57.0.0. A patch in the new major version was added to remove a dependency cycle for one simple function. There is no python2 support in the setuptools with the new version, according to the changelog. Ethernet device management tool ethtool 5.13 added some upstream features like a netlink handler for module and xwayland 21.1.2.
According to the review of week 29 systemd 249 and rpmlint 2.0 are in staging will be released soon.
Certificate Auto Enrollment from Samba

Certificate Auto Enrollment allows devices to enroll for certificates from Active Directory Certificate Services. As of Samba 4.16, Linux clients can now auto enroll for certificates just like a Windows client.
Samba’s Certificate Auto Enrollment uses the certmonger service to keep track of certificates. It also uses the cepces plugin to certmonger. The sscep command is also used to download the trust chain.
Certificate Auto Enrollment is compatible with both Winbind and SSSD.
Certificate Auto Enrollment is initiated using Samba’s Group Policy client, samba-gpupdate. The Samba wiki has more details on how to setup Group Policy, and how to configure Certificate Auto Enrollment.
Leap Gains Maintenance Update Improvements
The recent release of openSUSE Leap 15.3 has gained some maintenance improvements from a new repository setup.
Maintenance efforts for Leap related to Closing the Leap Gap expands to having three separate repository groups instead of one.
The openSUSE specific package repositories called oss and non-oss repositories changed. While these two repositories contained all the content of Leap 15.2 and older, they now contain only the branding and related setup packages.
The shared PackageHub and openSUSE packages known as the backports repository contains all the packages not in SUSE Linux Enterprise nor in the openSUSE specific packages. Previously, PackageHub was specific to SLE, which duplicated packages between openSUSE and PackageHub; now this single project is shared between both PackageHub and openSUSE Leap 15.3. This single repository will improve the quality of delivering updates and avoid package conflicts like zypper patch for openSUSE Leap 15.3.
There is a single repository with the SLE imported packages that contain the base packages and other packages from SLE. A single channel regenerated through a script will not need to be adjusted manually and will be good for the openSUSE setup in aarch64, s390x, x86_64/i586 and ppc64le architectures.
The first method used to export the SLE imported package repository for Leap was not working well in the current repository system, which led to several dependency issues, package version overlaps and other related instabilities.
Last week, the new export method was deployed using regular SLES module technology. This resolved all the current problems and also made handling and debugging the repository easier for the coordination teams.
The topic recieved various feedback from the Leap retrospective.
PipeWire Audio Server on openSUSE Tumbleweed