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 […]

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.

or how moving code around ended up on a Makefile graduation course

My Pygtk App for Setting Time Zones

As I have been traveling a lot since joining SUSE, I noticed that when I get to a new place, it is annoying to change the timezone of my laptop. Apparently the location server that GNOME used to use for this has been taken down or something.

Anyway, I wrote my own app to make it easy to select the timezone. Here it is with all time zones listed:

You can also filter to find a specfic tz:

I am thinking that next steps are to internationalize it, and also put it into a flatpak.

Code is here. I'll add a readme and license later.

Many thanks to all who participated in the Leap 16 branding workshop at the openSUSE Conference 2024. The enthusiasm and creativity is moving us forward to take the next steps with Leap 16 branding. Let’s develop some of these fantastic ideas further!

Below is a list of Leap 16 branding initiatives we aim to achieve:

1) Abstract Distribution Agnostic Wallpaper

We are looking for wallpaper designs that can be shared across any distribution. This could be a gradient, fractal or any other abstract design, which ideally incorporates the new logo. The goal is to create something visually appealing and universally adaptable as chameleons do.

2) Abstract Distribution Specific Wallpaper for Leap 16 and Tumbleweed

In addition to the agnostic wallpaper, we need specific designs for Leap 16 and Tumbleweed. These wallpapers should reflect the unique identity of each distribution while maintaining a cohesive visual theme. An adjustable design for other flavors like Slowroll, Kalpa, Aeon and others can be considered and proposed to those projects.

3) Day and Night Variant with Chameleon

We’re also seeking designs for a day and night variant featuring a beloved chameleon. These wallpapers should complement each other while representing the different times of the day in a creative and engaging way. Additionally, day/night variants for abstract designs could also be an option. While not necessary, if participants have good ideas, these will be consider further.

4) Photo Submissions of Our Mascot

We invite you to submit two photos related to our mascot, the chameleon, or anything that resembles to it. The photographer of the photo must also be the submitter; the creator of a photograph with a camera. This is a great opportunity to showcase your photography skills and contribute to our branding efforts. Please note that AI-generated images are not eligible for submission; we want to see your original photographic work.

Call for Photo Competition!

We are thrilled to announce a photo competition. Please submit your pictures for a chance to be featured in branding materials. You can submit your photos through our GitHub issue tracker. We will use a thumbs up/down mechanism to select the best entries.

Submit photos here.

Submission Guidelines

You are welcome to participate on the wallpapers collection set in our branding repository.

Photos can be submitted here under issue 18.

Deadline and Requirements

The deadline for submissions is Nov. 1, 2024. Please ensure your entries meet the following requirements:

• Must be brand-related (chameleons, chameleon-like objects, etc.)
• High-resolution photographs only (4k or preferrably 5k)
• Original work - submitted by the author of the photograph or with approval from the actual author
• Landscape orientation only

Please add a copy of your photos, including a description (where it was taken and what is in the picture), as comments into the issue. Include a link to a high-resolution variant.

We can’t wait to see your creative contributions and make Leap 16 an even more visually stunning experience for everyone in the openSUSE community!

_{^{(Image made with DALL-E)}}

Dear Tumbleweed users and hackers,

My excuse to span two weeks in this report is quite simple: last week was the openSUSE Conference in Nuremberg and I spent my time talking to all the fun people from the community instead. And I am sure you are forgiving me for this. With the conference in full swing and weekends in between, it is quite amazing that the release Team (mostly Ana these days) still managed to produce and publish 12 snapshots (0620, 0621, 0622, 0624, 0625, 0627, 0628, 0629, 0701, 0702, 0703, and 0704)

The most relevant changes from these snapshots include:

• GDB 14.2
• MariaDB 11.4.2
• Mesa: work around broken graphics on ATI/AMD chipsets, Version 24.1.2
• Shadow 4.16.0
• Wayland 1.23.0
• KDE Plasma 6.1.0, 6.1.1 & 6.1.2
• GCC 14.1.1
• Qt 6.7.2
• Linux kernel 6.9.6 (fixing connection issues with iwlwifi) & 6.9.7
• NetworkManager 1.48.2
• ClamAV 1.3.1
• GNOME 46.3
• GStreamer 1.24.5
• Perl 5.40.0
• LLVM 18.1.8
• Poppler 24.07.0
• Qemu 9.0.1
• Systemd 255.8
• Cups 2.4.10
• Samba 4.20.2
• PyTest 8.2.2
• openssh fix against CVE-2024-6387, aka RegreSSHion

Quite an impressive list in just 2 weeks I’d say. At least in the northern hemisphere, the summer holiday is starting (including my own – so no reports from me for the next two weeks! Please follow the individual snapshot release announcements on the factory@lists.opensuse.org mailing list). With many people enjoying a break, we will likely see fewer requests going to Tumbleweed.

Looking at what is currently to be found in the staging area, we can predict those changes to happen in the next few days/weeks:

• Mesa 24.1.3
• Mozilla Firefox 127.0.2
• LibreOffice: fix excessive recommends on libreoffice-qt6
• Agama packages and installer to appear. Not yet QA’ed as part of the Tumbleweed release process, but feel free to test and play with it
• KDE Gear 24.05.2
• SELinux 3.7
• cmake 3.30.0
• 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

My First OpenSUSE Bug Report

One of the first contributions one can make to an Open Source community is a bug report. Effectively, except for one wifi issue on my Tumbleweed computer that seemed to go away on its own, I haven't actually run into many bugs.

However, when using my LEAP laptop, I was constantly driven to distraction by accidentally pasting when I was trying to click. What was happening was I would click the middle part of the bottom of my track pad, and that would trigger the "past by middle click" "feature" in GNOME.

I was a bit surprised by the lack of configurability for the track pad, but I chalked that up to GNOME being GNOME. I tried to disable "tap to click" as a work around.

This didn't seem to work, so I decided to log a but report:

Notice that bug report is set to RESOLVED. This is because the person investigating the issue pointed me to gnome-tweaks, which did have the kind of configurability I was expecting.

I ended up closing the bug report after leaving some comments about how I handled it.

All in all, I had a highly positive experience reporting the issue. I am not sure that I actually helped anyone so much as got tech support from the community, but I now have my first bug report under my belt!