openSUSE Leap 15.6 exited Beta and entered its Release Candidate phase with build 669.1 last week. You can get Leap 15.6 RC install images from get.opensuse.org.

This means the release is considered featurefull and contributors should focus on bug fixes and eliminating any remaining build failures.

Users who are eager to install Leap 15.6 on their machines should check the release’s known issues to see if there is any issue that prevents the use of the RC.

The release team was able to deliver a long time awaited Cockpit for both Leap and SUSE Package Hub users. Users might be familiar with Cockpit’s web-based admin interface from Leap Micro tutorials.

Users are advised not to publicly expose Port 9090 used with the admin interface; just like people shouldn’t expose their router’s web interface to the public.

`$ sudo zypper in cockpit`

`$ sudo systemctl enable --now cockpit.socket`

`$ firefox https://localhost:9090 # login as root for admin access`

Previous attempts to include Cockpit in Leap 15.5 were made, but there were several blockers. Inclusion was possible thanks to a refresh of the python311 stack, which was part of massive update effort for SUSE Linux Enterprise Server 15 Service Pack 6 along with unification branding. The team was able to build Cockpit once and provide it for both SLES and Leap users with this RC.

There is no existing SELinux policy on Leap 15.X so the SELinux part of Cockpit is not expected to be working. The release team expects to have an SELinux policy in Leap 16, so this will be working for future releases.

Happy Hacking!

Your favorite Linux distribution is X. You test everything there. However, your colleagues use distro Y, and another team distro Z. Nightmares start here: the same commands install a different set of syslog-ng features, configuration defaults and use different object names in the default configuration. I ran into these problems while working with Gábor Samu on his HPC logging blog.

From this blog you can learn about some of the main differences in packaging and configuration of syslog-ng in various Linux distributions and FreeBSD, and how to recognize these when configuring syslog-ng on a different platform.

https://www.syslog-ng.com/community/b/blog/posts/using-syslog-ng-on-multiple-platforms

Dear Tumbleweed users and hackers,

This week has been filled with 7 snapshots (0411, 0412, 0414, 0415, 0416, 0416, and 0418). From a staging perspective, things looked rather easy – which means the package maintainers have done a great job submitting things that work and have most likely been pretested. The most interesting changes during this week include:

• Apache 2.4.59
• Linux kernel 6.8.5 & 6.8.6
• Pam 1.6.1
• Kiwi 10.0.10 & 10.0.12
• KDE Gear 24.02.2
• KDE Frameworks 6.1.0
• KDE Plasma 6.0.4
• SDL3 (no consumers yet)

Staging projects are well balanced, some are in ready to accept for the next snapshots, some are building/testing and, as usual, some are failing tests. The most interesting changes currently being tested are:

• Python 3.11.9 & 3.12.3
• Linux kernel 6.8.7 & kernel-longterm 6.6.28
• util-linux 2.40
• libxml 2.12.6: a long-lasting attempt to get to 2.12.x – but the results are looking good by now. There are two packages left that are failing: VirtualBox & libqt5-qtwebengine. For both, there should be some fixes available.
• dbus-broker: no progress this week
• GCC 14: phase 2: use gcc14 as the default compiler – lots of help needed: https://build.opensuse.org/project/show/openSUSE:Factory:Staging:Gcc7

In March, the configuration for building openSUSE Factory was changed to be bit-by-bit reproducible (except for the embedded signature). Following this, the first openSUSE Tumbleweed packages were verified to be bit-by-bit reproducible.

Thank you to everyone who helped to make this happen. This was an important improvement.

It will take some time to do this verification for all packages to see how many of our packages are reproducible to this detail. Previous verifications, while ignoring some differences that this fixed, succeeded for more than 95 percent of packages.

Contribute

The effort on reproducible builds is a collaboration across many distributions. See how to contribute to reproducible builds in openSUSE.

Uses

Reproducible builds have a multitude of uses for security and quality. To further enhance their utility, reproducible builds need to be combined with other techniques such as distributed post-merge code review and capability based designs.

A recent example is that reproducible builds allow for the creation of proof, simply by rebuilding and comparing the result, that a GCC build whose source was extracted with a compromised xz was not compromised; this process was achieved without needing to reverse engineer how the compromise occurred. Similarly, reproducible builds were reported as being usefully during investigations of the xz compromise.

reproducible builds enable collaboration that otherwise would not be possible by supporting more scientifically-based arguments for security, which can be independently verified.

Check out authentication to Azure AD/Entra ID with a Windows Hello PIN on openSUSE Tumbleweed!

Here’s how to get started for yourself.

First, install the package in Tumbleweed:

sudo zypper in himmelblau nss-himmelblau pam-himmelblau

Next configure /etc/himmelblau/himmelblau.conf and set the parameter ‘domains’ to a comma separated list of allowed domains, then set ‘pam_allow_groups’ to a comma separated list of allowed users and groups. All other parameters in the himmelblau.conf are optional.

Configure pam:

sudo pam-config --add --himmelblau

You may need to do additional pam configuration. Check out the readme.

Disable nscd:

sudo systemctl stop nscd
sudo systemctl disable nscd
sudo systemctl mask nscd

Setup nss (just add ‘himmelblau’ to the end of passwd, group, and shadow):

# vim /etc/nsswitch.conf
passwd:     compat systemd himmelblau
group:      compat systemd himmelblau
shadow:     compat systemd himmelblau

Finally, start Himmelblau:

sudo systemctl enable himmelblaud himmelblaud-tasks
sudo systemctl start himmelblaud himmelblaud-tasks

You’re all set! Domain enrollment happens automatically the first time someone logs in. Each time a new user logs in, they’ll be prompted to enroll a Windows Hello PIN for the device (Hello PIN auth is introduced in Himmelblau 0.3.0). Subsequently, that user will authenticate with their Hello PIN.

Version 1.9.16 of sudo will introduce a new logging option: json_compact. This does not affect logging to syslog, only logging to files. Previously, sudo created human-readable JSON log files. With this new setting enabled, logs are no longer pretty but can be easily read by logging software.

As I am writing this blog, version 1.9.16 is not yet released, not even a beta. For now, if you want to test this feature, you will have to compile sudo yourself from source. Once 1.9.16 is released, it will be available here on the sudo website as ready to install package for major Linux and UNIX variants. And eventually it will officially become available in various operating systems, FreeBSD and rolling Linux distros first.

Read more at https://www.sudo.ws/posts/2024/04/when-it-comes-to-sudo-logging-pretty-is-not-always-better/

Version 1.9.16 of sudo will feature a new option for logging: json_compact. Why is this important? This new format can easily be read and parsed by a log management software, like syslog-ng.

Note that in this blog I am showing you a sudo feature which has not yet been released officially. You have to compile sudo yourself. By all means, if you have any other application writing JSON-formatted log messages, you can apply most of what you read here with slight modifications.

Read the rest at https://www.syslog-ng.com/community/b/blog/posts/working-with-sudo-s-json_5f00_compact-logs-in-syslog-ng