Dear Tumbleweed users and hackers,

As I informed you in my last ‘weekly review’ (end of week 27 – so three weeks ago), I enjoyed some vacation time of my own and used it to recharge by entirely stepping away from computers. Of course, you did not notice anything, as Ana was there to steer the big Tumbleweed ship around and snapshots have been delivered constantly. for completeness, I will also include things that happened during my absence to give more continuity to the reports.

During the weeks 28 – 30, 11 snapshots could be published (0705, 0708, 0709, 0710, 0711, 0712, 0714, 0715, 0716, 0722, 0724, and 0725). There was a larger gap between 0716 and 0722, as openQA detected some issues on Mesa and sdbootutil,. As we did not want you to suffer through those problems, snapshots were held back and the issues addressed.

The most relevant changes included in those snapshots were:

• Mesa 24.1.3
• Mozilla Firefox 127.0.2 & 128.0
• KDE Gear 24.05.2
• PHP 8.3.9
• Apache 2.4.61
• cmake 3.30.0 & 3.30.1
• NetworkManager 1.48.4
• Ruby 3.3.4
• SELinux 3.7
• Linux kernel 6.9.9
• KDE Frameworks 6.4.0
• KDE Plasma 6.1.3
• LibreOffice 24.2.5.2
• trasnactional-update 4.7.0: soft-reboot feature not yet enabled, as it takes a bit more time to get QA adjusted for this during the summer break
• Agama installer medium is generated as part of the snapshot. This is not yet the default installer, but you are invited to check out progress. ISOs are published in https://download.opensuse.org/tumbleweed/appliances/iso/

The staging projects are currently nicely filled; some things are passing tests already, and others will take a bit more time. But you deserve to know what’s brewing, namely:

• gnutls 3.8.6
• Qemu 9.0.2
• Lua 5.4.7
• Systemd 256.4
• AppArmor 4.0.2
• Linux kernel 6.10.1
• cURL 8.9.0: breaks test suite of cmake
• ffmpeg-7 as system default (currently ffmpeg-6). A big bunch of packages is still stuck on ffmpeg-4.
• transactional-update: enable soft reboot; see https://microos.opensuse.org/blog/2024-06-13-soft-reboot/
• dbus-broker: some networking issue after upgrades left to work out
• GCC 14: phase 2: use gcc14 as the default compiler – lots of help needed: https://build.opensuse.org/project/show/openSUSE:Factory:Staging:Gcc7

An experimental “Pre-RC3” image for the Aeon Desktop has been published and testers are encouraged to try out the final prototype before it becomes the official Release Candidate 3 (RC3). The new image can be downloaded from the openSUSE development repository.

This prototype, which has been submitted to openSUSE Factory, introduces some significant changes and improvements. Notably, the dd backend in the tik installer has been replaced with a new systemd-repart backend. This change allows for the installation of Aeon with Full Disk Encryption that enhances the security features of the operating system.

Existing users of Aeon RC2 and earlier versions will need to perform a reinstall to take advantage of the new features destined for RC3. Due to the fundamental changes in partition layout necessary for the new encryption features, an in-place upgrade from RC2 is not feasible without risking data integrity, according to a post on the new Aeon Desktop subreddit. Users can utilize Aeon’s reinstall feature, which facilitates the backup and restoration of user data as long as a sufficiently large USB stick is used.

Users installing the prototype image may encounter some packages from the OBS devel project. These can be removed by running transactional-update --interactive dup and selecting solutions that replace devel:microos packages with official ones.

Testers are encouraged to provide feedback and report any issues encountered during the testing phase on the Aeon Desktop bug report page.

Next Steps

If the prototype is accepted into Factory and becomes RC3, the development of Aeon will be in its final stages before an official release. RC3 will serve as the basis for writing openQA tests for Aeon, which are crucial for ensuring the desktop’s stability and functionality.

There is a possibility of an RC4, which aims to streamline the installer process by embedding the full Aeon install within the installer image, potentially reducing the download size by 50 percent. If this approach is not feasible in the short term, it may be revisited post-release.

Full Disk Encryption is set up in one of two modes: Default or Fallback. Get more info about that in the Aeon Desktop Introduces Comprehensive Full Disk Encryption article.

The syslog-ng configuration starts with a version number declaration. Up until recently, if it was missing, syslog-ng did not start. With syslog-ng 4.8, this is changing.

From this blog, you can learn why version information is useful, what workaround you can use if you do not want to edit your syslog-ng configuration on each update, and what changed in version 4.8.

You can read the rest of my blog at https://www.syslog-ng.com/community/b/blog/posts/why-it-is-useful-to-set-the-version-number-in-the-syslog-ng-configuration

Last year, I picked up Kalimba and put together some beginner melodies by transcribing youtube videos. That’s been a bit too needlessly arduous, so there is a few:

Sound of silence

6 6 1’ 1’ 3’ 3’ 2’
5 5 7 7 2’ 2’ 1
1’ 1’ 3’ 3’ 5’ 5’ 6’ 6’ 5’
1’ 1’ 3’ 3’ 5’ 5’ 6’ 6’ 5’
1’ 1’ 6’
6’ 6’ 7’ 1’’
1’’ 7’ 6’ 5’
6’ 5’ 3’
1’ 1’ 1’ 5’
7 1’ 6
6 6 1’ 1’ 3’ 3’ 2’
5 5 7 7 2’ 2’ 1’
1’ 1’ 3’ 3’ 5’ 5’ 6’ 6’ 5’
1’ 1’ 3’ 3’ 5’ 5’ 6’ 6’ 5’
1’ 1’ 1’ 6’
6’ 6’ 7’ 1’’
1’’ 6’ 6’ 5’ (?)
6’ 5’ 3’
1’ 1’ 1’ 5’
7 1’ 6

Wellerman

3’ 6 666 1’ 3’ 3’ 3’
3’3’4’ 2’2’2’ 4’4’6’6’3’ 3’
3’6 7 1’ 2’ 3’ 3’ 3’ …
3’ 2’ 1’1’7 6 …..

==

6’…. 6’.. 4’5’5’3’ 3’
3’4’ 2’ 2’3’4’ 3’ 1’ 6
6’…. 6’ 5’4’5’5’3’ 3’
3’ 3’ 2’ 1’ 7 6 …..

—

56 666 1’3’ 3’3’
3’4’ 2’2’2’ 4’4’6’ 3’3’
3’6 66 1’3’ 3’3’
3’3’2’1’ 1’1’ 776

6’ 6’ 4’5’5’ 3’3’
3’4’ 2’2’ 4’4’6’ 3’3’
6’ 6’ 4’5’5’ 3’3’
3’3’ 2’1’ 76
6 66 1’3’ 3’3’
3’4’ 2’2’ 4’6’ 3’3’
3’6 66 1’3’ 3’3’
3’2’1’ 1’1’ 76

Hedwig’s Theme Harry Potter

3 6 1’7 6 3’ 2’ 7
6 1’7 5 6 3 ….
3 6 1’7 6 3’5’ 4’3’
7 3’ 2’1’ 7 1’6
1’ 3’ 1’ 3’ 1’4’ 3’2’
7 1’ 3’2’ 7 53’
1’ 3’ 1’ 3’ 1’ 5’ 4’3’
1’ 3’ 2’1’ 7 1’6

Pirates

3566 671’1’ 1’2’77 6556
3566 671’1’ 1’2’77 656 (!)
3566 61’2’2’ 2’3’4’4’ 3’2’3’6
671’1’ 2’3’6 61’77 1’67….
3566 671’1’ 1’2’77 6556
3566 671’1’ 1’2’77 656 (!)
3566 612’2’ 2’3’4’4’ 3’2’3’6
671’1’ 2’3’6 61’77 6566
71’1’2’ 3’… 1’63 …
4 … 1’64 … 3 … 6 …
74’3’3’ 3’4’3’.. (0:53)
2’2’2’ 2’3’… 3’3’3’ 4’3’… 2’1’76

—

6 6 66 6 66 6 66 1’6
6 6 66 6 66 6 66 1’6
536… 7… 1’… 2’3’ 4’3’ 4’3’ 6’
67167 6 5 6
67167 1’ 2’ 2’ 2’3’4’61’
7 6 7 6 5 61’3’
6671’67
656671’6 71’
2’ 2’ 2’3’4’61’

I make a lot of digital things and need the space to store the information. I don’t like deleting items, after all, I did make the time investment. I also don’t want to put my data in “cold storage” for me to forget about where I put the drive or lose access due to bit-rot. … Continue reading NFS and FS-Cache | Faster Performance with Distributed Storage →

The openSUSE.Asia Summit 2024 is fast approaching, and we’re excited to invite participants from all over the world to join us Nov. 2 and 3 in Tokyo, Japan.

This year promises a diverse range of sessions and activities, with an inclusive Cross-Distro Track featuring collaborations with community members from AlmaLinux, Debian and Ubuntu .

Those who want to provide a talk need to submit either long talk or short talk presentations by August 4. Those speakers needing financial assistance can use the Travel Support Program (TSP), which is aided through donations to the Geeko Foundation. The TSP helps covering travel expenses. Here’s a detailed look at important deadlines for TSP applications and speaker proposals to ensure you don’t miss out on this incredible opportunity.

Travel Support Program (TSP) Schedule

The Travel Support Program is designed to help you join us at the summit. Here’s the timeline you need to follow:

• TSP Application Open: As soon as possible. Don’t wait to apply for travel support.
• Call for Speakers Deadline: August 4. If you’re interested in sharing your knowledge and experience, submit your proposal by this date.
• TSP Application Deadline: August 20. Ensure your application for travel support is completed and submitted by this date. Visit the wiki for more information
• Call for Speakers Notification: Speakers will be notified if their proposal has been accepted toward the end of August.
• TSP Confirmation: Final confirmation of travel support will follow shortly after the speakers’ notifications. Around August 26.

Submitting Your Proposal

The openSUSE.Asia committee is looking for speakers who can bring diverse perspectives and insights related to openSUSE and other Linux distributions. Here are some guidelines and tips to help you submit a strong proposal:

• Topics: We’re interested in a wide range of topics, including but not limited to openSUSE Projects (Leap, Tumbleweed, MicroOS), desktop environments (GNOME, KDE, XFCE), office and graphic applications (LibreOffice, GIMP), cloud and virtualization (Kubernetes, Rancher), and package supply-chain security.
• Non-Technical Topics: Overviews of Open Source technologies, community management, education, and personal experience stories are also welcome.
• Session Types: You can propose long talks (30 minutes plus Q&A) or short talks (15 minutes plus Q&A). Lighting talk sessions will be announced later.

How to Submit: Proposals should be submitted through events.opensuse.org. Make sure your submission is in English, is between 130 to 250 words, and adheres to the openSUSE Conference Code of Conduct. For guidance on writing a strong proposal, refer to our proposal writing guide.

Presentation Requirements: You can present in English or Japanese, but all slides and documents must be in English. Note that pre-recorded videos or video calls are not permitted; you must be present at the venue. For more details, visit events.opensuse.org.

Hello!

It's been a long time since a news update here. Many things changed, and there are lots of exciting news which have been partially communicated in emails and meetings, but not in much detail. I try to clean up some of the news backlog gathered in a good half of a year with this post.

Data center move¶

With SUSE moving one of their datacenters (the one which hosted the majority of openSUSE infrastructure) to Prague towards the end of 2023, we got the opportunity to not only move our systems along, but also to introduce fundamental changes which would have otherwise been difficult to implement in the existing environment - both for SUSE, and for openSUSE.

SUSE graciously provided us with not only brand new hardware, but also autonomy over what we do with it. Whereas the physical infrastructure in the old location was entirely operated by SUSE, with openSUSE merely having SSH access to the virtual machines, the new setup allows the openSUSE Heroes to fully manage their hypervisors and networking stack. This freedom allows the team to implement new ideas and react to issues with virtual machines without relying on and waiting for SUSE internal support.

Maintenance¶

Of course, lots of freedom comes with lots of responsibility. That makes it even more important for our infrastructure to be stable and easy to maintain - after all, the Heroes team is made of volunteers, of which there aren't many who can be motivated to spend their free time with boring maintenance tasks. Hence we now enforce automatic security updates on all machines using os-update and rebootmgr, with added logic to reduce outages by staggering the package updates on reboots of machines in high availability clusters, and to alert administrators about machines requiring updates which cannot install them on their own, or ones requiring manual reboot intervention.

Automation¶

We already use Salt as an automation and infrastructure as code solution since a long time, but increased the Salt coverage by a large margin. Whereas previously only a comparatively small amount of machine configuration was actively maintained using Salt, now the whole base system (network configuration, repositories, kernel settings, authentication, monitoring, logging, certificates, email, automatic updates) is covered, with a steadily increasing amount of the various machine specific services (not surprisingly, the large amount of services under the opensuse.org umbrella comes with a large amount of applications requiring configuration).
Using the infrastructure as code approach has multiple benefits, some of which are:

• configuration changes are tracked and documented in a Git history
• configuration is unified across all machines
• central deployment of changes is possible To fully use those benefits, it is essential to have a large coverage, and to reduce the times one needs to manually visit a machine for changes.

We encourage you to check our Git repositories if you are curious (the salt.git repository is now automatically mirrored to code.opensuse.org and GitHub!):
https://github.com/openSUSE/heroes-salt or https://code.opensuse.org/heroes/salt/tree/production
https://github.com/openSUSE/salt-formulas or https://code.opensuse.org/heroes/salt-formulas/tree/main

Monitoring¶

Monitoring already had an important role in our infrastructure before, but it was time to expand it further. The setup which had its center in our old data center, and was based on Nagios and Icinga, served us very well - but after working with it for some time, I gathered the following concerns:

• the server configuration was not managed by Salt, and there was no existing Salt formula community around it
• lots of checks are executed on machines through a central agent which runs as root
• single failure domain
• often the need for custom check scripts to cover new applications

The data center move broke the existing setup, which finally answered my question about whether to refactor or whether to build something new.
After evaluating multiple solutions, including Nagios again, Munin and Zabbix, the choice eventually fell to a stack with Prometheus at its heart. Not only do I have existing experience with Prometheus, but also did I value:

• configuration of all server and client components is either through environment variables, or YAML files - perfect for integration into a code based infrastructure without lots of custom templating
• existing Salt formulas
• each service being monitored is equipped with a dedicated metrics exporter - this for one keeps other services actively monitored if one exporter breaks, but more importantly it allows for deep privilege separation, as most monitoring checks can be performed with only a small set of permissions
• a large amount of applications, especially ones providing web services, which we run plenty of, have built-in support for serving Prometheus compatible metrics - those allow for extremely easy integration with no need to install or write custom monitoring checks or "translation" tools
• plenty of existing community supported exporters for applications which do not provide built-in Prometheus metrics - the configuration of them is usually standardized, making RPM packaging and deployment easy
• easy to add custom checks to collect metrics covered by neither of the above

Already a large amount of additional metrics from various services which were not monitored before are gathered using the new setup. For most we already implemented alerting to notice odd behavior early, and added visualization dashboards with graphs - of course because they are pretty, but also to make spotting anomalies at a glance easier.

The alerting rules which are made of PromQL expression can be found in the previously linked repositories, under salt/files/prometheus/alerts/. Currently, we split alerts based on their severity into either IRC (#opensuse-admin-alerts - still a bit experimental), email, or dashboard receivers.

The alerting dashboard (using Karma) - currently only reachable if connected to the openSUSE Heroes VPN:
https://alerts.infra.opensuse.org/

The visualization dashboards in Grafana - accessible to everyone:
https://monitor.opensuse.org/grafana/.

Our monitoring posture is on a good track, but there is still a lot of work to do to cover more services, fine tune alerts, and to update the internal documentation and response.

Security and internal authentication¶

Previously we used a FreeIPA based LDAP setup for authentication of Heroes to internal services and machines.
We did not use the majority of features FreeIPA offered, and had noone wanting to maintain a machine not running openSUSE anymore - with Kanidm experience in the team, the decision what to migrate to was easy.

In the process, we replaced the sssd installations on all machines with kanidm-unixd, and globally enforced public key based authentications for SSH. Not only is the setup simpler and well maintained, we also found improvements with credential caching, allowing login even throughout potential network issues on a host.

VPN¶

Gateway to all of our internal openSUSE infrastructure is a OpenVPN setup. We improved its security by switching to the current best practices for compression.

Closing words¶

Of course, there have been various other changes, some of which being too small to cover here, some of which simply forgotten about. You will either find out about them in future news posts, or by inspecting our commit and ticket histories.

Have fun!

I had a need for writing an image file for FreeDOS to a floppy drive. I didn’t see any tools nor had I heard of any tools so I went to searching the great repository called the world wide web. Bottom Line up front: It’s pretty simple to write a disk image to a USB … Continue reading Write .img file to USB Floppy Drive | FreeDOS →

We have heard your suggestions and have introduced a way to filter the requests-related notifications by request state. This new filter will help you focus on what really requires your attention. Filter by Request State If you are involved in highly active projects or packages, you have probably received many notifications about accepted or declined requests at the moment you check your inbox. However, at that point, you might be more interested in those requests...

Full Disk Encryption is planned to be introduced in the forthcoming release candidate of the Aeon Desktop to enhance data security for its users. The feature is expected to be included in the upcoming Release Candidate 3 (RC3).

Full Disk Encryption is designed to protect data in cases of device loss, theft or unauthorized booting into an alternative operating system. Depending on the hardware configuration of a system, Aeon’s encryption will be set up in one of two modes: Default or Fallback.

Default Mode

The Default Mode is the preferred method of encryption provided the system has the required hardware. This mode utilizes the Trusted Platform Module(TPM) 2.0 chipset with PolicyAuthorizeNV support (TPM 2.0 version 1.38 or newer). In this mode, Aeon Desktop measures several aspects of the system’s integrity. These including:

• UEFI Firmware
• Secure Boot state (enabled or disabled)
• Partition Table
• Boot loader and drivers
• Kernel and initrd (including kernel command line parameters)

These measurements are stored in the system’s TPM. During startup, the current state is compared with the stored measurements. If these match, the system boots normally. If discrepancies are found, users are prompted to enter a Recovery Key provided during installation. This safeguard ensures that unauthorized changes or tampering attempts are flagged.

Fallback Mode

The Fallback Mode is employed when the necessary hardware for Default Mode is not detected. This mode requires users to enter a passphrase each time the system starts. While it does not check system integrity as comprehensively as Default Mode, Secure Boot is strongly recommended to ensure some level of security, confirming that the bootloader and kernel have not been tampered with.

Contrary to initial concerns, Default Mode is not less secure than Fallback Mode despite not requiring a passphrase at startup. The strong integrity checks in Default Mode protect against attacks that could bypass normal authentication methods. For example, it can detect changes to the kernel command line that could otherwise allow unauthorized access. Furthermore, it safeguards against modifications to initrd thereby preventing potential passphrase capture in Fallback Mode.

Secure Boot, while optional in Default Mode due to the comprehensive integrity checks, is critical in Fallback Mode to maintain system security. Disabling Secure Boot in Fallback Mode increases vulnerability to tampering and attacks aimed at capturing the passphrase.

Aeon’s implementation of Full Disk Encryption provides robust security options tailored to the capabilities of users’ hardware. By offering both Default and Fallback modes, Aeon ensures that all users can benefit from enhanced data protection.

The inclusion of this feature in RC3 marks a significant step forward in safeguarding user data against potential threats.

Aeon users are encouraged to read and bookmark the Aeon Encryption Guide.