In a blog post last year Simplify GPU Application Development with HMM on Leap we've described how to install CUDA using the NVIDIA open kernel driver built by SUSE. For this, we utilized driver packages from the graphics driver repository for openSUSE Leap hosted by NVIDIA. This happend to work at the time, as at the time the kernel driver version for the graphics driver happened to be the same as the one used by CUDA. This, however, is not usually the case and at present, therefore this method fails.

NVIDIA CUDA Runtime Installation on openSUSE Leap 15.6 Bare Metal

To recap, CUDA will work with the 'legacy' proprietary kernel driver that has existed for a long time as well as the open driver KMP provided with CUDA. There is also a pre-built driver KMP avaiable on openSUSE Leap (starting with version 15.5). The latter provides the additional perks:

• since it is fully pre-build it does not require an additional tool chain to complete the build during installation - which the CUDA provided drivers will install as dependencies.
  This helps to keep an installation foot print small which is desirable for HPC compute nodes or AI clusters.
• It is singed with the same key as the kernel and its components and thus will integrate seamlessly into a secure boot environment without enrolling an additional MOK - which usually requires access to the system console.

The NVIDIA open driver supports all recent GPUs, in fact, it is required for cutting edge platforms such as Grace Hopper or Blackwell, and recommended for all Turing, Ampere, Ada Lovelace, or Hopper architectures. The the proprietary driver is only still required for older GPU architectures.

The versions of the driver stacks for CUDA and for graphics frequently differ. CUDA's higher level libraries will work with any version equal or later to the one these have been released with. This means for instance, that CUDA 12.5 will run with a driver stack version greater or equal to 555.42.06. The components of the lower level stack - ie. those packages with the driver generation in their name (at the time of writing G06) - need to match the kernel driver version.
The component stack for graphics is always tightly version coupled. To accomodate versions difference for CUDA and graphics, openSUSE Leap is now providing two sets of NVIDIA Open Driver KMPs: the version targetting CUDA has the string -cuda prepended before -kmp in the package name. With this, installing CUDA using the open driver becomes quite simple.

CUDA comes with a number of meta-packages which provide an easy way to install certain aspects while still obeying required dependencies. A more detailed list of these meta packages and their purposes will follow in a future blog. To run applications built with CUDA the only components required are the runtime. If we plan to set up a minimal system - such as an HPC compute node - these are the only components to be installed. They consist of the low level driver stack as well as the CUDA libraries. In a containerized system, the libraries would reside inside the application container.

To install the runtime stack for CUDA 12.9, we would simply run:

# zypper ar https://developer.download.nvidia.com/compute/cuda/repos/opensuse15/x86_64/cuda-opensuse15.repo
# zypper --gpg-auto-import-keys refresh
# zypper -n in -y nv-prefer-signed-open-driver
# version=$(rpm -qa --queryformat '%{VERSION}\n' nv-prefer-signed-open-driver | cut -d "_" -f1 | sort -u | tail -n 1)
# zypper -n in -y --auto-agree-with-licenses \
    nvidia-compute-utils-G06 = ${version} cuda-libraries-12-9

The command above will install the SUSE-built and signed driver. Further changes to the module configuration as described in the previous blog are no longer required.

Now we can either reboot or run

# modprobe nvidia

to make sure, the driver is loaded. Once it's loaded, we ought to check if the installation has been successful by running:

nvidia-smi -q

If the driver has loaded successfully, we should see information about the GPU, the driver and CUDA version installed:

==============NVSMI LOG==============

Timestamp                                 : Mon Aug 12 09:31:57 2024
Driver Version                            : 555.42.06
CUDA Version                              : 12.5

Attached GPUs                             : 1
GPU 00000000:81:00.0
    Product Name                          : NVIDIA L4
    Product Brand                         : NVIDIA
    Product Architecture                  : Ada Lovelace
    Display Mode                          : Enabled
    Display Active                        : Disabled
    Persistence Mode                      : Disabled
    Addressing Mode                       : HMM
...

NVIDIA CUDA Runtime Installation for containerized Workloads

Containerized workloads using CUDA have their highlevel CUDA runtime libraries installed inside the container. The low level libraries are made available when the container is run. This allows running containerized workloads relatively independent of the version of the driver stack as long as the CUDA version is not newer than the version of driver stack used. Depending on what container environment we plan to use, there are different ways to achieve this. We've learned in a previous blog, how to do this using the NVIDIA GPU Operator and a driver container. This does not require to install any NVIDIA components on the container host. The kernel drivers will be loaded from within the driver container, they do not need to be installed on the container host. However, there are other container systems and different ways to install CUDA for K8s.

Set up Container Host for podman

For podman, we require a different approach. For this, kernel driver as well as the nvidia-container-toolkit need to be installed on the container host. We need to use the container toolkit to configure podman to set up the GPU device files and the low level driver stack (libraries and tools) inside a container.

# zypper ar https://developer.download.nvidia.com/compute/cuda/repos/opensuse15/x86_64/cuda-opensuse15.repo
# zypper --gpg-auto-import-keys refresh
# zypper -n in -y nv-prefer-signed-open-driver
# version=$(rpm -qa --queryformat '%{VERSION}\n' nv-prefer-signed-open-driver | cut -d "_" -f1 | sort -u | tail -n 1)
# zypper -n in -y --auto-agree-with-licenses \
    nvidia-compute-utils-G06 = ${version} \
    nvidia-container-toolkit

Now, we can configure podman for the devices found in our system:

# nvidia-ctk cdi generate --output=/etc/cdi/nvidia.yaml

This command should show INFO as well as some WARN messages but should not return any lines marked ERROR. To run containers which use NVIDIA GPUs, we need to specify the device using the argument: --device nvidia.com/gpu=<device>. Here, <device> may be on individual GPU or - on GPUs that support Multi-Instance GPU (MIG) - an individual MIG device: ie GPU_ID or GPU_ID:MIG_ID) or all. We are also able to specify multiple devices:

$ podman run --device nvidia.com/gpu=0 \
    --device nvidia.com/gpu=1:0 \
	...

This uses GPU 0 and MIG device 1 on GPU 1.
We may find the available devices by running:

$ nvidia-ctk cdi list

Set up Container Host for K8s (RKE2)

There are different ways to set up the K8s to let containers use NVIDIA devices. One has been described in a separate blog), however the driver stack can also be installed on the container host itself while still using the GPU Operator. The disadvantage of this approach is that the driver stack needs to be installed on each container host.

# zypper ar https://developer.download.nvidia.com/compute/cuda/repos/opensuse15/x86_64/cuda-opensuse15.repo
# zypper --gpg-auto-import-keys refresh
# zypper -n in -y nv-prefer-signed-open-driver
# version=$(rpm -qa --queryformat '%{VERSION}\n' nv-prefer-signed-open-driver | cut -d "_" -f1 | sort -u | tail -n 1)
# zypper -n in -y --auto-agree-with-licenses \
    nvidia-compute-utils-G06 = ${version}

We need to perform above steps on each node (ie, server, agents) which have an NVIDIA GPU installed. How to continue depends whether we perfer to use the NVIDIA GPU Operator (without a driver container) or just use the NVIDIA Device Plugin container.

with the NVIDIA GPU Operator

Once the previous steps have been completed, we can start the GPU Operator:

OPERATOR_VERSION="v24.6.1"
DRIVER_VERSION="555.42.06"
helm repo add nvidia https://helm.ngc.nvidia.com/nvidia
helm repo update
helm install \
  -n gpu-operator --generate-name \
  --wait \
  --create-namespace \
  --version=${OPERATOR_VERSION} \
  nvidia/gpu-operator \
  --set driver.enabled=false \
  --set driver.version=${DRIVER_VERSION} \
  --set operator.defaultRuntime=containerd \
  --set toolkit.env[0].name=CONTAINERD_CONFIG \
  --set toolkit.env[0].value=/var/lib/rancher/rke2/agent/etc/containerd/config.toml \
  --set toolkit.env[1].name=CONTAINERD_SOCKET \
  --set toolkit.env[1].value=/run/k3s/containerd/containerd.sock \
  --set toolkit.env[2].name=CONTAINERD_RUNTIME_CLASS \
  --set toolkit.env[2].value=nvidia \
  --set toolkit.env[3].name=CONTAINERD_SET_AS_DEFAULT \
  --set-string toolkit.env[3].value=true

We need to set OPERATOR_VERSION to the GPU Operator version we whish like to use and DRIVER_VERSION to the driver version we are running. Now, we are able to see the pods starting:

kubectl get pods -n gpu-operator

The final state should either be Running or Completed. Now, we should check the logs of the nvidia-operator-validator whether the driver has been set up successfully

# kubectl logs -n gpu-operator -l app=nvidia-operator-validator

and the nvidia-cuda-validator if CUDA workloads can be run successfully.

# kubectl logs -n gpu-operator -l app=nvidia-cuda-validator

Both commands should return that the validations have been successful.

without the NVIDIA GPU Operator

Alternatively, we can set up NVIDIA support without the help of the GPU Operator. For this, we will need to create a configuration - much like for podman - and use the NVIDIA Device Plugin. If not done already, we need to install the nvidia-container-toolkit package, for this:

# zypper -n in -y nvidia-container-toolkit

and restart RKE2:

# systemctl restart rke2-server

on the K8s server or

# systemctl restart rke2-agent

on each agent with NVIDIA hardware installed. This will make sure, the container runtime is configure appropriately.

Once the server is again up and running, we should find this entry in /var/lib/rancher/rke2/agent/etc/containerd/config.toml:

[plugins."io.containerd.grpc.v1.cri".containerd.runtimes."nvidia"]
  runtime_type = "io.containerd.runc.v2"
[plugins."io.containerd.grpc.v1.cri".containerd.runtimes."nvidia".options]
  BinaryName = "/usr/bin/nvidia-container-runtime"
  SystemdCgroup = true

Which is required to use the correct runtime for workloads requiring NVIDA harware. Next, we need to configure the NVIDIA RuntimeClass as an additional K8s runtime so that any user whose pods need access to the GPU can request them by using the runtime class nvidia:

# kubectl apply -f - <<EOF
apiVersion: node.k8s.io/v1
kind: RuntimeClass
metadata:
  name: nvidia
handler: nvidia
EOF

Since Device Plugin version 0.15 we need to set a hardware feature label telling the DaemonSet that there is a GPU on the node. This is normally set by the Node or GPU Feature Discovery daemons both deployed as part of the GPU Operator chart. Since we don't use this, we will have to set this manually for each node with a GPU:

kubectl label nodes <node_list> nvidia.com/gpu.present="true"

and install the NVIDIA Device Plugin:

# helm repo add nvdp https://nvidia.github.io/k8s-device-plugin
# helm repo update
# helm upgrade -i nvdp nvdp/nvidia-device-plugin \
  --namespace nvidia-device-plugin --create-namespace \
  --set runtimeClassName=nvidia

The pod should start up, complete the detection and tag the nodes with the number of GPUs available. To verify, we run:

# kubectl get pods -n nvidia-device-plugin
NAME                              READY   STATUS    RESTARTS   AGE
nvdp-nvidia-device-plugin-tjfcg   1/1     Running   0          7m23s
# kubectl get node `cat /etc/HOSTNAME` -o json | jq .status.capacity
{
  "cpu": "32",
  "ephemeral-storage": "32647900Ki",
  "hugepages-1Gi": "0",
  "hugepages-2Mi": "0",
  "memory": "65295804Ki",
  "nvidia.com/gpu": "1",
  "pods": "110"
}

Acknowledgements

Many ideas in this post were taken from the documentation NVIDIA GPUs in SLE Micro.

Further Documentation

NVIDIA CUDA Installation Guide for Linux

Installing the NVIDIA Container Toolkit

Support for Container Device Interface

NVIDIA GPU Operator

Installing the NVIDIA GPU Operator

K8s NVIDIA Device Plugin

NVIDIA GPU feature discovery

Kraft (Github) is the desktop app making it easy to create offers and invoices quickly and beautifully in small companies. It is targetted to the free desktop and runs on Linux.

This is the release announcement of the new Kraft version 1.2.2. This is a small service release that fixes a few bugs and CI issues.

Right after this release, the branch with significant changes for Kraft 2.0 will be merged to master. These changes will make Kraft ready for sharing documents across private file clouds and with that enable use cases for distributed use via internet, along with other significant feature updates.

Details about the next big release with version number 2.0 can be read on the Github Discussion page.

Any feedback and contribution is highly appreciated.

Recently I was at EuroBSDCon, where several participants recognized that I am a POWER guy. And they were right, I have been an IBM POWER Champion focusing on open source software on POWER for the past three years.

I got the usual question from people: is there anyone working on an affordable and open source friendly POWER machine? My answer was a definite yes, but also had to admit that I do not know the actual status for any of the projects. I looked around again and did not find any updates for this year. Still, I collected some pointers, as these might be interesting also outside of the BSD community.

• The OpenPOWER foundation has a PowerPI special interest group, which plans to create a small and affordable POWER computer. https://openpowerfoundation.org/
• Raptor Computing announced on Twitter that they are working on new POWER machines, Talos III and Blackbird II: https://x.com/RaptorCompSys/status/1715147706061168822

It is almost the end of the year, so I am not sure if we will see any actual hardware this year, but I hope that we will have at least a couple of announcements before the end of the year.

By the way: if you want an open source friendly POWER machine now Raptor Computing is the place to go. Even if POWER 9 energy efficiency is not the best by today’s standards, they provide fully owner controlled computing using OpenPOWER, which is something completely unique in the world of computers.

Welcome to the monthly update for Tumbleweed for September 2024! This month, the rolling-release model has kept pace with numerous important updates and bug fixes. PostgreSQL received a major update moving to 17 and text shaping engine harfbuzz had a major update to version 10. Packages like systemd, git, bash and qemu were also updated this month in the rolling release. Various packages saw CVE fixes and desktop components for GNOME and KDE were also updated. As always, remember to roll back using snapper if any issues arise.

Happy updating and tumble on!

Should readers desire more frequent information about snapshot updates, they are encouraged to subscribe to the openSUSE Factory mailing list.

New Features and Enhancements

• Linux Kernel 6.11.0: The latest update brings reversion of the PCI ACS configurability extension to address an issue bsc#1229019. Key updates in the release include a fix to the block subsystem, resolving how the scheduler is handled in elv_iosched_local_module. A correction was made in the AMD GPU display driver to address a mistake from a previous revert related to bsc#1228093. Updates also include refreshed ALSA patches to enhance power management blacklist options. The improvements are expected to provide greater stability and performance for various hardware configurations.
• postgresql17: This major release provides key improvements like a revamped memory management system for vacuum, boosting efficiency by reducing memory usage by up to 20x along with optimized processing for high concurrency workloads. Version 17 also enhances query execution with faster processing using B-tree indexes and parallel BRIN index builds. Developers benefit from the addition of the SQL/JSON JSON_TABLE command and expanded MERGE capabilities, as well as a 2x speed improvement in data exports with the COPY command. Logical replication now simplifies major version upgrades by eliminating the need to drop replication slots, improving ease of use in high availability setups. The software package further enhances database security and operational management, with new TLS options, incremental backups, and detailed monitoring tools.
• harfbuzz 10.0.1: Significant fixes were made for the text shaping engine including support for Unicode 16.0.0. The version has a new Application Programming Interfaces that allows clients to customize glyphs when a Unicode Variation Selector isn’t supported by the font, as well as a callback for getting table tags from hb_face_t. Updates also address pair positioning lookup subtable application for compatibility and ensure subsetting fails if no glyphs are present to prevent silent errors.
• GNOME 46.5: gnome-shell now addresses issues with smartcard logins, fixes glitches when quick settings menu animations are interrupted, and resolves problems with new Wi-Fi connections for restricted users. It also ensures required animations remain enabled, fixes display of pending PAM messages on the login screen and plugs memory leaks. Un update of the gnome-software has a reduction in power usage when the main window is closed, along with translation updates..
• KDE Plasma 6.1.5: In Discover, snapType mapping is corrected, and Flatpak now properly reports extensions without errors. KWin addresses several crash scenarios, such as null dereference and input event handling from removed devices. Plasma Desktop includes fixes for keyboard navigation in Kickoff, task list alignment in RTL mode and it has proper handling of background icons and test windows. Plasma Workspace enhances touchscreen interaction, system tray tooltips and clipboard functionality. Additional fixes included targeted crashes in hotplugging and svg rendering, while SDDM KCM improves state management.
• Frameworks 6.6.0: Attica adds CI jobs for Alpine/musl, while Baloo sets up crash handling for baloo_file. New icons are introduced in Breeze. KCoreAddons improves dbus error handling and licensing, and KDeclarative adjusts rendering for better DPI positioning. KIO resolves issues with restoring trash entries and enhances service menu handling. KTextEditor receives performance optimizations and additional C++ porting for sorting and unique functionalities. Kirigami continues to improve icon handling and toolbars, while KNewStuff and KWalletf ocus on making shared actions more reliable and enhancing crash handling.
• KDE Gear 24.08.1: Akademy 2024 Videos are out, but a lot of efforts went into last month’s conference. Akonadi resolves a crash related to query cache eviction and fixes configuration file handling. Dolphin improves usability with fixes for button functionality and file list resizing, while Elisa enhances its Now Playing view and toolbar layout. Itinerary and Kalarm both receive updates for better dark mode handling and audio alarm functionality. Kdenlive addresses multiple timeline and rendering issues, optimized keyframe handling and fixes several bugs related to effects and transitions. Kate adds support for the Odin language in its formatter and Okular now sets tooltips for forms.

Key Package Updates

• git 2.46.1: A clarification has been made to git checkout --ours to inform users they need to specify paths, avoiding confusion. An issue with git add -p failing for users with diff.suppressBlankEmpty was corrected. Additionally, git notes add -m '' --allow-empty no longer improperly invokes an editor, and unnecessary re-encoding operations for tracing have been removed.
• qemu 9.1.0: The update introduces new migration capabilities, such as compression offload support via Intel In-Memory Analytics Accelerator (IAA) or User Space Accelerator Development Kit (UADK) and improved postcopy failure recovery. RISC-V architecture also sees support for several extensions, while x86 adds KVM support for AMD SEV-SNP guests and emulation for newer Intel CPU models like Ice Llake and Sapphire Rapids.
• systemd 256.6: This version no longer attempts to restart udev socket units, addressing issue bsc#1228809 where safely restarting socket-activated services and their socket units simultaneously was problematic.
• pipewire 1.2.4: The update addresses a crash during the cleanup of globals and enhances the RequestProcess dispatch mechanism. The Simple Plugin API framework now uses systemd-logind to detect new devices. Pulse-Code Modulation device handling is also improved.
• GStreamer 1.24.8: The multimedia framework package improves handling in decodebin3 and encodebin for better media decoding and smart rendering, respectively. Enhancements for proper viewport resizing when video size changes were made and audio stream enhancements were made for better compatibility with Firefox. There were some stability fixes for wayland including crash prevention and Application Binary Interface corrections.
• Mesa 24.1.7: This release continues to support OpenGL 4.6 and Vulkan 1.3, though the version reported depends on the specific driver used. Key bug fixes include resolving issues with smartcard logins, race conditions when generating enums, and artifacts in games such as Black Myth Wukong and DCS World with certain GPUs.
• GTK4 4.16.1: This GTK Scene Graph Kit layer sees speed optimizations for Vulkan operations, reduces startup time by skipping unnecessary GL and Vulkan initialization and fixes a crash related to certain Vulkan drivers. Memory format conversions in GIMP Drawing Kit are now faster. The builder-tool has also been improved for better box conversion.
• bash 5.2.37: This update has key patches to address issues such as an incorrect handling of quoted text during auto-completion and multibyte character handling in readline. The update resolves system compatibility with select and pselect availability and fixes a parsing issue in compound assignments during alias expansion. A typo in the autoconf test affecting strtold availability when compiled with GNU Compiler Collection 14 was corrected.
• vim 9.1.0718: One notable fix in the text editor resolves issues with personal Vim runtime directory recognition. The update also addresses unnecessary NULL checks in parse_command_modifiers() and corrects color name parsing errors introduced in a previous version. Other improvements include updates to syntax highlighting for various file types such as HCL, Terraform, and tmux. Performance improvements were also made to include the more efficient inserting with a count and resolving cursor position crashes.

Bug Fixes

• curl 8.10.0:
  • CVE-2024-8096 may have incorrectly validated certificates using Online Certificate Status Protocol stapling, ignoring certain errors like ‘unauthorized’.
• OpenSSL:
  • CVE-2024-41996 was fixed, which could have allowed remote attackers to trigger costly server-side DHE calculations via public key order validation in Diffie-Hellman.
• postgresql17
  • CVE-2024-7348 fixes a race condition that could allow attackers to execute arbitrary SQL as the user running pg_dump.
• python311: This package fixed a few CVE’s. Here are a couple of fixes
  • CVE-2024-4030 had a fix to ensure Unix “700” permissions are applied to secure the directory.
• tiff 4.7.0:
  • CVE-2023-52356 had a segmentation fault allowing remote attackers to trigger a heap-buffer overflow that could cause a denial of service.
  • CVE-2024-7006 had a null pointer dereference in that could trigger application crashes and cause denial of service.
• LibreOffice 24.8.1.2
  • CVE-2024-5261 was fixed that disabled TLS certificate verification, allowing improper certificate validation during document processing in third-party components.
• Mozilla Firefox 130.0.1:
  • This release fixes several CVEs. One of the most critical fixes involves CVE-2024-8385, where a WASM type confusion issue could lead to exploitable vulnerabilities. Another significant fix is for CVE-2024-8381, which could trigger a type confusion vulnerability when looking up property names within a “with” block. CVE-2024-8388 fixed an issue where fullscreen notifications could be hidden on Android devices, potentially leading to UI spoofing attacks. Two memory safety bugs, CVE-2024-8387 and CVE-2024-8389, were also patched.
• apr 1.7.5:
  • CVE-2023-49582 had shared memory permissions that could expose sensitive data to local users.

Conclusion

September 2024 brings important updates for Tumbleweed users. Security fixes across packages like PostgreSQL, libtiff, and LibreOffice ensure stability and security. Significant improvements were made in tools like systemd, git, and qemu, enhancing performance and compatibility. Noteworthy updates in PostgreSQL 17 and Harfbuzz 10 also bring major enhancements, contributing to a more robust and refined rolling release environment.

Stay updated with the latest snapshots by subscribing to the openSUSE Factory mailing list. For those Tumbleweed users who want to contribute or want to engage with detailed technological discussions, subscribe to the openSUSE Factory mailing list . The openSUSE team encourages users to continue participating through bug reports, feature suggestions and discussions.

Contributing to openSUSE Tumbleweed

Your contributions and feedback make openSUSE Tumbleweed better with every update. Whether reporting bugs, suggesting features, or participating in community discussions, your involvement is highly valued.

Dear Tumbleweed users and hackers,

This week looked pretty normal for Tumbleweed: we could publish 5 snapshots (0919, 0920, 0922, 0923, and 0924). 0925 was tested but needed to be discarded, as the cURL 8.10.1 update caused issues with libostree/flatpak. The issue could be resolved for Snapshot 0926, which is currently in QA and will likely be shipped over the weekend.

The most relevant changes during this week are:

• libeconf 0.7.3
• bind 9.20.2
• Linux kernel 6.10.11
• Mozilla Firefox 130.0.1
• git 2.46.1
• PostgreSQL 17 as new default (currently shipping PostgreSQL 17 RC1)
• Meson 1.5.2
• perl=Bootloader was renamed to update-bootloader

Staging projects and QA are currently working on – and testing – these changes

• Bash 5.2.37
• cURL 8.10.1 – libostree 2024.8 to address the identified crashes in flatpak
• fwupd 1.9.25
• GStreamer 1.24.8
• GTK 4.16.2
• Linux kernel 6.11.0
• openSSH 9.9p1
• systemd 256.6
• TCL 8.6.15
• PostgreSQL 17.0
• LLVM 19
• Mesa 24.2.x
• Plasma 6.2 (beta)
• timezone 2024b: postgresql test suites fixed
• Audit 4.0
• grub2 change: Introduces a new package, grub2-x86_64-efi-bls; some scenarios do not install the proper branding package
• Change of the default LSM (opted in at installation) to SELinux. AppArmor is still an option, just not the default. This change only impacts new installations
• GNOME 47

EuroBSDCon was fantastic, as always :-) I talked to many interesting people during the four days about sudo and syslog-ng, and of course also about many other topics. I gave a sudo tutorial, and it went well, with some “students” already planning which features to implement at home. There were many good talks, including one from Dr. Marshall Kirk McKusick, who was with the FreeBSD project right from the beginning, and worked on BSD even earlier. The weather was also good to us, so I could look around in Dublin for a bit.

sudo

The first two days of the conference were tutorials. I gave a sudo tutorial, which was well received: https://events.eurobsdcon.org/2024/talk/FLCHU3/. Luckily my audience was very active: I got many good questions. They did not really know most of the advanced sudo features. As usual, I also received feature requests while giving my sudo tutorial. I forwarded those to Todd Miller, maintainer of sudo.

At the end of my tutorial I asked my audience, which sudo features they plan to implement on their network, when they get back to the office. These were the top 3:

• sub-command logging
• central session recording
• using the Audit API from Python

During the conference I received many questions asking why I delivered a sudo tutorial if I was wearing a syslog-ng shirt :-) In short: Todd Miller, maintainer of sudo, was my colleague for a couple of years. I quickly learned that sudo is a lot more than just a prefix, and started writing and talking about it: https://peter.czanik.hu/posts/on_teaching_sudo/

Another returning question was comparing sudo with sudo replacements. The reason is quite simple: most people are not aware of the features sudo provides. As soon as I mention some of the enterprise focused features, like session recording, central management through LDAP, plugin support, and others, suddenly they understand the difference. Replacements are good in single user environments, however only sudo includes features for enterprise environments.

syslog-ng

During the conference I wore syslog-ng t-shirts. First of all: I do not have any sudo t-shirts, but dozens of syslog-ng t-shirts :-) And also, because I work on syslog-ng both as my job, and as the maintainer of the syslog-ng port in FreeBSD. I handed out many syslog-ng stickers too. There are many active syslog-ng users among FreeBSD users and developers. They use syslog-ng on FreeBSD in very diverse environments: collecting jail logs, in various appliances, bank security, telecommunications, and others. I am always happy to hear some positive feedback, and here I received many!

Sometimes I even felt, as if I was a kind of celebrity. People knew my name, and came to me to talk a bit after following me on Twitter / LinkedIn / Mastodon for years. They were very happy to learn that MacOS / FreeBSD receives now some extra care (see: https://www.syslog-ng.com/community/b/blog/posts/version-4-8-0-of-syslog-ng-improves-freebsd-and-macos-support)

During the conference I also received a feature request for syslog-ng: a new source to collect FreeBSD audit logs. This is how I learned that FreeBSD also has audit logs :-) Implementing something in C would be time consuming, and there is no ETA for that right now. Luckily syslog-ng also has a program() source. For that I could put together a working configuration over the lunch break of the conference. Of course it still has some rough edges, like ugly error messages, unnecessary quotation marks, etc, but it’s a good start. Here is a sample output:

{
  "fbaudit": {
    "record": {
      "text": "\"successful login root\"",
      "subject": {
        "_uidit-uid": "root",
        "_tiddt-uid": "46906172.16.167.1",
        "_siddt-uid": "909",
        "_ruidt-uid": "root",
        "_rgidt-uid": "wheel",
        "_piddt-uid": "909",
        "_gidit-uid": "wheel",
        "_audit-uid": "root"
      },
      "return": {
        "_retval": "0",
        "_errval": "success"
      },
      "_version": "11",
      "_timefier": "\"Sun Sep 22 15:36:46 2024\"",
      "_msecfier": "\" + 770 msec\"",
      "_modifier": "0",
      "_eventon": "\"OpenSSH login\""
    }
  },
  "TRANSPORT": "local+program",
  "SOURCE": "s_fbaudit_xml",
  "PRIORITY": "notice",
  "MSGFORMAT": "raw",
  "MESSAGE": "<record version=\"11\" event=\"OpenSSH login\" modifier=\"0\" time=\"Sun Sep 22 15:36:46 2024\" msec=\" + 770 msec\" ><subject audit-uid=\"root\" uid=\"root\" gid=\"wheel\" ruid=\"root\" rgid=\"wheel\" pid=\"909\" sid=\"909\" tid=\"46906172.16.167.1\" /><text>successful login root</text><return errval=\"success\" retval=\"0\" /></record>",
  "HOST_FROM": "fb14",
  "HOST": "fb14",
  "FACILITY": "user",
  "DATE": "Sep 22 17:45:39"
}

The conference

The conference was intense. Two days of tutorials co-located with the FreeBSD developer summit, and two days of talks. I delivered my sudo tutorial on the first day, and went back to my hotel quickly to rest a bit. I was completely exhausted from talking three hours straight. Then met up with some fellow Hungarians and FreeBSD developers for a beer that night. The next day I participated the developer summit, where I listened to interesting talks and discussions. In the late afternoon I walked around in Dublin.

The “real” conference happened on the third and fourth days. There were three parallel tracks, sometimes it was really difficult to choose where to go :-) There was a coffee break before each talk, which ensured that no matter how tired we were, we stayed awake :-) And of course it also gave us the possibility of networking. Lots of good discussions. It is difficult to pick highlights from the talks, all were great. My absolute favorite was given by Dr. Marshall Kirk McKusick: FreeBSD at 30 Years: Its Secrets to Success. It looked back at the history of the FreeBSD project and also shared some interesting statistics. I also learned about WifiBox, the latest news about FreeBSD RC scripts, or how to build an AI powered house. For a complete list of talks and tutorials, check the schedule.

Summary

I hope to see you next year in Zagreb at EuroBSDCon 2025 :-)

Last week I wrote about a campaign that we started to resolve issues on GitHub. Some of the fixes are coming from our enthusiastic community. Thanks to this, there is a new syslog-ng-devel port in MacPorts, where you can enable almost all syslog-ng features even for older MacOS versions and PowerPC hardware. Some of the freshly enabled modules include support for Kafka, GeoIP or OpenTelemetry. From this blog entry, you can learn how to install a legacy or an up-to-date syslog-ng version from MacPorts.

Read the rest of my blog at https://www.syslog-ng.com/community/b/blog/posts/huge-improvements-for-syslog-ng-in-macports

Last week I wrote about a campaign that we started to resolve issues on GitHub. Some of the fixes are coming from our enthusiastic community. Thanks to this, there is a new syslog-ng-devel port in MacPorts, where you can enable almost all syslog-ng features even for older MacOS versions and PowerPC hardware. Some of the freshly enabled modules include support for Kafka, GeoIP or OpenTelemetry. From this blog entry, you can learn how to install a legacy or an up-to-date syslog-ng version from MacPorts.

Read the rest of my blog at https://www.syslog-ng.com/community/b/blog/posts/huge-improvements-for-syslog-ng-in-macports