One of the primary issues preventing the last few holdouts from migrating away from SMB1 is a lack of Posix/UNIX extensions in SMB2+. SMB1 is definitely going away though in the near future.

To compensate, the community has been hard at work creating a new UNIX extension standard for SMB3. These have been in the works since as early as 2010, but have recently seen some renewed interest in completion. The Linux ksmbd server and cifs client both support SMB3 UNIX extensions. Several third party servers also offer support. Support from Samba server is nearing completion.

A critical part of implementing a new standard is documenting that standard. I, along with several other members of the Samba team, have collaborated on an open standard (not GPL), which fits neatly in with the other SMB protocol documents. The project is currently hosted on codeberg. The license is intentionally friendly to both opensource and closed source.

The details of the documentation are only now being written down, but have been hashed out over the past 12 years in various iterations. A preliminary version of the specification is available below.

If you have comments or suggested edits, please join the discussion on the samba-technical mailing list.

How to get started with syslog-ng? There are two main resources: the syslog-ng documentation and the syslog-ng blogs. You should learn the concepts and basics from the documentation. The blogs document use cases and you can use the docs as a reference.

Read the rest of my blog at: https://www.syslog-ng.com/community/b/blog/posts/syslog-ng-101-how-to-get-started-with-learning-syslog-ng

 The open build service publisher has a configuration variable in BSConfig.pm, where you can define a rsync server to publish the built repos to.

Unfortunately, the documentation apart from the actual code (in src/backend/bs_publish function sync_to_stage) seems scarce, so let's document one non-standard usage here.

"Standard" (IMO) usage, one rsync staging server:

our $stageserver = 'rsync://my-rsync/obs-repos-module';

 But now, for a transition phase, I need multiple rsync servers that are all synced to. The format for this is a perl array variable reference that contains pairs of "project name regex, array of sync servers". This also allows to sync different repositories to different rsync servers for example.

The simplest use of this is "sync all repos to multiple rsync servers" and is configured like this:

our $stageserver = ['.*', ['rsync://rsync1/module1', 'rsync://rsync2/module2', 'rsync://rsync3/module3']];

 With this configuration, bs_publish will send all repos to the three mentioned rsync URLs in turn.

All of the ALP Workgroups are working towards delivering promised September ALP prototype with the codename “Les Droites”. SUSE will continue using a mountain naming theme for all upcoming prototypes, which will be delivered on a three months basis from now.

Adaptable Linux Platform (ALP) is planned, developed, and tested in open so users can simply get images from OBS and see test results in openQA

As far as “Les Droites” goes, users can look forward to a SLE Micro like HostOS with self-healing abilities contributing to our OS-as-a-Service/ZeroTouch story. The Big Idea is that the user focuses on the application rather than the underlying host, which manages, heals, and self-optimizes itself. Both Salt (pre-installed) and Ansible will be available to simplify further management.

Users can look forward to Full Disk Encryption (FDE) with TPM support by default on x86_64. Another part of the deliverables are numerous containerized system components including yast2, podman, k3s, cockpit, Display Manager (GDM), and KVM. All of which users can experiment with, which are simply referred to as Workloads.

A seamless system integration will arrive later and may vary based on the type of workload. An example could be /usr/bin wrapper deployed via rpm, etc. An example of running a ncurses variant of a YaST workload on ALP or in fact any podman-enabled Linux system.

$ podman container runlabel run \
registry.opensuse.org/suse/alp/workloads/tumbleweed_containerfiles/suse/alp/workloads/yast-mgmt-ncurses:latest

We strongly recommend that users read the following articles for more information about ALP workloads yast-report-2022-7, yast-report-2022-8, and Cockpit_at_ALP wiki.

There is big news brewing! SUSE has reconsidered setting the minimum architecture baseline for ALP from the originally announced x86_64-v3 to x86_64-v2.

SUSE is currently looking into providing support for x86_64-v3 and perhaps even v4 through hwcaps functionality, just as it is currently being handled on other non-intel architectures.

Dimstar already announced that openSUSE Factory will lead the way and set the minimum architecture level for Intel to x86_64-v2 in upcoming weeks.

Those who have older hardware than x86_64-v2 can still install the 32bit Intel variant of openSUSE Tumbleweed. We have you covered!

Original discussion with proposal to change minimal architecture baselevel in Factory can be found here 20220728.

Dear Tumbleweed users and hackers,

During this week, openSUSE Tumbleweed was once again able to showcase the power there is in using OBS (open build service), openQA, and a dedicated team to make things happen. After six months of development, GNOME 43.0 has been released upstream on Sep 21. The openSUSE GNOME Team has been closely following progress and kept packages updated in the devel branch throughout the alpha/beta/RC phases. All the relevant package updates had been ready shortly after upstream released the tarballs and GNOME 43.0 could be shipped as part of Snapshot 20220921. This one snapshot only serves as an example of what happens in the various development areas. And this was just ONE of the snapshots published during this week. One, in a group of a total of 7, that is.

The 7 snapshots (0915…0921) released during this week brought you these changes:

• Plymouth: minor packaging change, allowing buildcompare to do its job better
• meson 0.63.2
• FFmpeg 5.1.1 (note: default FFmpeg is still version 4, but a lot of progress has happened in the last weeks towards changing this)
• grep 3.8: egrep and fgrep are deprecated. Scripts relying on this spit out warnings and should be changed to using grep -E, resp grep -F
• gawk 5.2.0
• Python 3.10.7 (CVE-2020-10735)
• Virtualbox 6.1.38
• GNOME 43.0

In the staging projects, we currently test submissions like:

• Linux kernel 5.19.10
• Mesa 22.2.0
• KDE Plasma 5.26 (5.25.90 staged, Staging:K)
• LLVM 15: breaks all versions of PostgreSQL
• fmt 9.0: Breaks ceph and zxing-cpp
• gpgme 1.18: breaks LibreOffice
• libxslt 1.1.36: breaks daps
• util-linux 2.38.1: this also brings a massive package layout change, which will probably take some time to settle. It’s part of the distro bootstrap and we have to be careful not to blow it out of proportion