Fedora is a Trademark of Red Hat, Inc, an operating system built by volunteers around the world. This page is provided so that independent volunteers can showcase our contributions to Fedora and Free Software in general. Official Fedora Download page.

We Make Fedora

October 14, 2024

Josh Bressers Episode 450 – What’s Wrong With WordPress
Josh and Kurt talk about the current WordPress / WP Engine mess. In what is certainly a supply chain attack, the Advanced Custom Fields forking. This whole saga is weird and filled with chaos and stupidity. We have no idea how it will end, but we do know that the blog platform you use shouldn’t be this exciting. The bad sort of exciting.
https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_450_Whats_Wrong_With_Wordpress.mp3
Show Notes

October 13, 2024

Fedora Community Blog Fedora Operations Report
Happy October folks! In this post you’ll find some information on our F41 and F42 releases, plus a few lines on a couple of topics happening around the project lately. Read on to find out more!

Fedora Linux 41

We are nearing the end of the Fedora Linux 41 release cycle! Our Go/No-Go meeting will happen next Thursday 17th October @ 1700 UTC. To join, you can find the information on the fedocal calendar entry.

There are still some proposed blockers for F41 too, so if you can help resolve some of these bus, please check out our blocker bugs app, or for a more condensed summary, please read out blocker bug report email.

Fedora Linux 42

Fedora Linux 42 is currently in development, and for the most recent set of changes planned in this rel;ease, please refer to our change set page. Our release schedule is also live, and a reminder of some key dates are below:
- December 18th – Changes requiring infrastructure changes
- December 24th – Changes requiring mass rebuild
- December 24th – System Wide changes
- January 14th – Self Contained changes
- February 4th – Changes need to be Testable
- February 4th – Branching
- February 18th – Changes need to be Complete
The changes that are currently in our community feedback period are :
- Ansible11
- ZlibNG-2.2
Hot Topics

For all the latest on boot-c, check out the bootc post on discourse!

Our Git Forge evaluation is taking shape. We have an instance of both Forgejo and GitLab CE available to try out in the Communshift app. Details of how to get access can be found on this discussion thread, and we are encouraging folks to try out each instance and report their feedback, preferably against the user stories collected, on this discussion thread. Directly linked to the git forge evaluation, following Wednesdays council meeting, we have decided to extend the report comparing both Forgejo and GitLab CE to be due by December 5th to allow our QA team, and other teams impacted by the F41 release, time to properly validate their use cases against each forge option. This means the council decision may not happen until early January, but we do hope to proceed with a decision as early as possible so the CPE team can help create a migration plan for affected workflows that can be shared and agreed to in good time to allow minimal disruption to the project as a whole as possible.

There is still time to share feedback on the proposal to amend the Editions Promotion policy. You can read the current policy, and what the council would like to change, in this discussion thread.

FOSDEM 2025 returns on Saturday 1st and Sunday 2nd February! The call for devrooms has passed, but the call for stands is still open until November 7th.

A new episode of The Fedora Podcast is now available! Details of episode 38 and how to listen can be found on the discussion post and by visiting the audio post for the latest, and all episodes.

The post Fedora Operations Report appeared first on Fedora Community Blog.

October 12, 2024

Kiwi TCMS Kiwi TCMS 13.6
We're happy to announce Kiwi TCMS version 13.6!

IMPORTANT: this release includes security related updates, several small improvements and important bug fixes.

Recommended upgrade path:
```
13.5 -> 13.6
```
You can explore everything at https://public.tenant.kiwitcms.org!

---
Upstream container images (x86_64):
```
kiwitcms/kiwi   latest  b560bb4d3744    693MB
```
IMPORTANT: version tagged and multi-arch container images are available only to subscribers!
Changes since Kiwi TCMS 13.5
Security
- Update Django from 5.0.8 to 5.0.9, addressing multiple potential security vulnerabilities, which do not seem to affect Kiwi TCMS directly however this is not 100% guaranteed
Improvements
- Update markdown from 3.6 to 3.7
- Update psycopg from 3.2.1 to 3.2.3
- Update pygithub from 2.3.0 to 2.4.0
- Update python-bugzilla from 3.2.0 to 3.3.0
- Update python-gitlab from 4.9.0 to 4.13.0
- Update tzdata from 2024.1 to 2024.2
- Update uwsgi from 2.0.26 to 2.0.27
- Update node_modules/pdfmake from 0.2.10 to 0.2.14
- Specify large_client_header_buffers for NGINX proxy configuration example to match the configuration of Kiwi TCMS
- Set uWSGI configuration max-requests to 1024
Settings
- Explicitly set DATA_UPLOAD_MAX_NUMBER_FIELDS to 1024, default is 1000
Bug fixes
- Increase uWSGI configuration buffer-size to 20k to allows the creation of a TestRun with 1000 test cases! Fixes Issue #3387, Issue #3800
Refactoring and testing
- Update black from 24.8.0 to 24.10.0
- Update pylint-django from 2.5.5 to 2.6.1
- Update selenium from 4.23.1 to 4.25.0
- Update sphinx from 8.0.2 to 8.1.1
- Update node_modules/webpack from 5.93.0 to 5.95.0
- Update node_modules/eslint from 8.57.0 to 8.57.1
- Update node_modules/eslint-plugin-import from 2.29.1 to 2.31.0
- Assert that password reset email contains username reminder
- Update translation source strings
Kiwi TCMS Enterprise v13.6-mt
- Based on Kiwi TCMS v13.6
- Update django-ses from 4.1.0 to 4.2.0
- Update kiwitcms-tenants from 3.1.0 to 3.2.1
- Update sentry-sdk from 2.12.0 to 2.16.0
- Update value for Content-Security-Policy header to match upstream Kiwi TCMS
Private container images
```
quay.io/kiwitcms/version            13.6 (aarch64)          14f4599db480    12 Oct 2024     705MB
quay.io/kiwitcms/version            13.6 (x86_64)           2d925723ab4e    12 Oct 2024     693MB
quay.io/kiwitcms/enterprise         13.6-mt (aarch64)       27a5de45d8dc    12 Oct 2024     1.07GB
quay.io/kiwitcms/enterprise         13.6-mt (x86_64)        f2ba176b5e0f    12 Oct 2024     1.05GB
```
IMPORTANT: version tagged, multi-arch and Enterprise container images are available only to subscribers!
How to upgrade

Backup first! Then follow the Upgrading instructions from our documentation.

Happy testing!

---

If you like what we're doing and how Kiwi TCMS supports various communities please help us grow!
- Give â� on GitHub;
- Give ğŸ‘� on GitLab;
- Join our newsletter and follow all project news;
- Become a contributor and an awesome open source hacker;
- Become a subscriber and help us sustain development
Adam Young Algebra VS Music Theory

Think of the algebraic formula:

Y=5X+19

Y and X are variables, but 5 and 19 are numbers. The numbers don’t change.

In Algebra, we use letters as variables, and think of digit based numbers as the actual numbers.
Here are the first four chords of a standard jazz tune

Fm7 | Bb-7 | Eb7 | Abmaj7 |

Suppose your singer can’t reach the low notes, and wants to transpose it up a full step. You end up with:

Gm7 | C-7 | F7 | Bbmaj7 |

This works because the relationship between the chords is the same in both keys. To represent this relationship, we represent the chord using roman numerals. If we assume the first version is in the key of Ab, and the second in the key of Bb, we say the last chord of the sequence is the root, and refer to it using the roman numeral I, and will call it “the One”. We use lowercase letters to refer to minor chords. So the sequence becomes:

vi-7 | ii -7 | V7 | Imaj7

Thus, the letter version is the “actual” chords, whereas the numeric version is the variable.

October 11, 2024

Richard Hughes Making it easy to generate fwupd device emulation data

We’re trying to increase the fwupd coverage score, so we can mercilessly refactor and improve code upstream without risks of regressions. To do this we run thousands of unit tests for each part of the libfwupd public API and libfwupdplugin private API. This gets us a long way, but what we really want to do is emulate the end-to-end firmware update of every real device we support.

It’s not trivial (or quick) connecting hundreds of devices to a specific CI machine, and so for some time we’ve supported recording USB device enumeration, re-plug, firmware write, re–re-plug and re-enumeration. For fwupd 2.0.0 we added support for all sysfs-based devices too, which allows us emulate a real world NVMe disk doing actual ioctls() and reads() in every submitted CI job. We’re now going to ask vendors to record emulations for existing plugins of the firmware update so we can run those in CI too.

The device emulation docs are complicated and there’s lots of things that the user can do wrong. What I really wanted was a “click, click, save-as, click” user experience that doesn’t need to use the command line. The tl;dr: is that we’ve now added the needed async API in fwupd 2.0.1 (probably going to be released on Monday) and added the click, click UI to gnome-firmware:

There’s a slight niggle when the user starts recording the first “internal” device (e.g. a NVMe disk) that we need to ask the user to restart the daemon or the computer. This is because we can’t just hotplug the internal non-removable device, and need to “start recording” then “enumerate device(s)” rather than the other way around. Recording all the device enumeration isn’t free in CPU or RAM (and is possibly a security problem too), and so we don’t turn it on by default. All the emulation is also all controlled using polkit now, so you need the root password to do anything remotely interesting.

Some of the strings are a bit unhelpful, and some a bit clunky, so if you see anything that doesn’t look awesome or is hard to translate please tell us and we can fix it up. Of course, even better would be a merge request with a better string.

If you want to try it out there’s a COPR with all the right bits for Fedora 41. It’ll might also work on Fedora 40 if you remove gnome-software. I’ll probably switch the Flathub build to 48.alpha when fwupd 2.0.1 is released too. Feedback welcome.
Fedora Community Blog Infra and RelEng Update – Week 41 2024
This is a weekly report from the I&R (Infrastructure & Release Engineering) Team. It also contains updates for CPE (Community Platform Engineering) Team as the CPE initiatives are in most cases tied to I&R work.

We provide you both infographic and text version of the weekly report. If you just want to quickly look at what we did, just look at the infographic. If you are interested in more in depth details look below the infographic.

Week: 7th October – 10th October 2024

Infrastructure & Release Engineering

The purpose of this team is to take care of day to day business regarding CentOS and Fedora Infrastructure and Fedora release engineering work.
Itâ€™s responsible for services running in Fedora and CentOS infrastructure and preparing things for the new Fedora release (mirrors, mass branching, new namespaces etc.).
List of planned/in-progress issues

Fedora Infra
- In progress:
- Done:
CentOS Infra including CentOS CI
- In progress:
  - Investigate how MBS relies on fedmsg and its implications on us when fedmsg disappears
  - Release Improvements
- Done:
  - Upgrade zabbix infra
  - Upgrade koji to 1.34.3
Release Engineering
- In progress:
- Done:
List of new releases of apps maintained by CPE
- Minor update of FASJSON client from 1.0.8 to 1.1.0 on 2024-10-09: https://github.com/fedora-infra/fasjson-client/releases/tag/v1.1.0
If you have any questions or feedback, please respond to this report or contact us on #redhat-cpe channel on matrix.

NOTE: There are currently internal changes happening in CPE Team (we will see if the name even remains), which caused that the last week update didn’t came out (it was also caused by the login issue in community blog, but that was just a coincidence) and caused change in the content (some sections are currently missing). We apologize for that and we see how the format will look in the future.

The post Infra and RelEng Update – Week 41 2024 appeared first on Fedora Community Blog.
Remi Collet PHP version 8.2.25RC1 and 8.3.13RC1
Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for a parallel installation, the perfect solution for such tests, and also as base packages.

RPMs of PHP version 8.3.13RC1 are available
- as base packages in the remi-modular-test for Fedora 39-41 and Enterprise Linux ≥ 8
- as SCL in remi-test repository
RPMs of PHP version 8.2.25RC1 are available
- as base packages in the remi-modular-test for Fedora 39-41 and Enterprise Linux ≥ 8
- as SCL in remi-test repository
The packages are available for x86_64 and aarch64.

PHP version 8.1 is now in security mode only, so no more RC will be released.

Installation: follow the wizard instructions.

Announcements:
- PHP 8.3.13RC1 available for testing
- PHP 8.2.25RC1 available for testing
Parallel installation of version 8.3 as Software Collection:
```
yum --enablerepo=remi-test install php83
```
Parallel installation of version 8.2 as Software Collection:
```
yum --enablerepo=remi-test install php82
```
Update of system version 8.3:
```
dnf module switch-to php:remi-8.3
dnf --enablerepo=remi-modular-test update php\*
```
Update of system version 8.2:
```
dnf module switch-to php:remi-8.2
dnf --enablerepo=remi-modular-test update php\*
```
Notice:
- version 8.4.0RC2 is also available in the repository
- EL-9 packages are built using RHEL-9.4
- EL-8 packages are built using RHEL-8.10
- oci8 extension uses the RPM of the Oracle Instant Client version 23.5 on x86_64 or 19.24 on aarch64
- intl extension uses libicu 74.2
- RC version is usually the same as the final version (no change accepted after RC, exception for security fix).
- versions 8.2.25 and 8.3.13 are planed for October 24th, in 2 weeks.
Software Collections (php82, php83)

Base packages (php)

October 10, 2024

Peter Czanik The syslog-ng Insider 2024-10: 4.8.0 release; version number; Debian Stable
Dear syslog-ng users,

This is the 124th issue of syslog-ng Insider, a monthly newsletter that brings you syslog-ng-related news.

NEWS

Version 4.8.0 of syslog-ng improves FreeBSD and MacOS support

Recently One Identity released version 4.8.0 of its open-source log management application. Learn about some of the new features and bug fixes: why upgrade to the latest syslog-ng version, not only on FreeBSD :-)

https://www.syslog-ng.com/community/b/blog/posts/version-4-8-0-of-syslog-ng-improves-freebsd-and-macos-support

Why it is useful to set the version number in the syslog-ng configuration

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.

https://www.syslog-ng.com/community/b/blog/posts/why-it-is-useful-to-set-the-version-number-in-the-syslog-ng-configuration

We are switching syslog-ng containers from Debian Testing to Stable

For many years, the official syslog-ng container and development containers were based on Debian Testing. We are switching to Debian Stable now. Learn about the history and the reasons for the change now.

https://www.syslog-ng.com/community/b/blog/posts/we-are-switching-syslog-ng-containers-from-debian-testing-to-stable

WEBINARS
- New webcast: “Log management superpowers: a PAM Essentials case study”. You can watch it at https://www.syslog-ng.com/webcast-ondemand/log-management-superpowers-a-pam-essentials-case-study/
- You can learn about upcoming webinars and browse recordings of past webinars at https://www.syslog-ng.com/events/
Your feedback and news, or tips about the next issue are welcome. To read this newsletter online, visit: https://syslog-ng.com/blog/

October 09, 2024

Adam Young Why does rpmbuild perf.spec fail
The Linux Kernel git repo has a spec file that builds the Kernel RPM. However, it does not build perf or any of the other userland tools. I want to build a perf RPM using the same code as is used to build the Kernel RPM.

Here are my debugging notes.

When building perf from the command line, one changes to the Linux kernel directory and, after having configured and built the kernel, you can “simply” type make -C tools/perf. It will compile in place. There area few variations of this, such as changing to the directory first, or calling the wrapped makefile in the tools/perf directory, Makefile.perf, to get more control over the build process.

However, merely attempting to do this from a stripped down RPM spec file does not work. Instead, it fails with:
```
  LINK    /root/rpmbuild/BUILD/linux/tools/perf/util/bpf_skel/.tmp/bootstrap/bpftool
/usr/bin/ld: /root/rpmbuild/BUILD/linux/tools/perf/util/bpf_skel/.tmp/bootstrap/main.o: relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `stderr@@GLIBC_2.17' which may bind externally can not be used when making a shared object; recompile with -fPIC
/usr/bin/ld: /root/rpmbuild/BUILD/linux/tools/perf/util/bpf_skel/.tmp/bootstrap/main.o(.text+0x18): unresolvable R_AARCH64_ADR_PREL_PG_HI21 relocation against symbol `stderr@@GLIBC_2.17'
/usr/bin/ld: final link failed: bad value
collect2: error: ld returned 1 exit status
```
I have tried various things with setting/remove CFLAGS and, while it changes the error, it is not in a way that moves me closer to a solution. For example, if I set the CFLAGS on the make command line like this:
```
%{make} CFLAGS="" -C tools/perf  -f Makefile.perf
```
I get this error
```
fs/fs.c:20:10: fatal error: debug-internal.h: No such file or directory
   20 | #include "debug-internal.h"
      |          ^~~~~~~~~~~~~~~~~~
```
The same error occurs if I populate the CFLAGS with the value used by the RPM spec file (reported higher up)
```
CFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -mbranch-protection=standard -fasynchronous-unwind-tables -fstack-clash-protection -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer '
+ export CFLAGS
```
Going back to the original error, I notice that it looks like generated code: /root/rpmbuild/BUILD/linux/tools/perf/util/bpf_skel/.tmp/bootstrap/main.o

The skel and .tmp makes me think this is generated from a script. The main.o aspect is also strange, as the main for the whole perf binary should be in linux/tools/perf/perf.c.

There is a whole chain to build Berkeley Packet Filers (bpf) tools and link it in to perf. It appears that this is the part that is failing. The main.o file linked above is build from the main.d file, which is just a list of other files.

Looking inside the log of the build from the Fedora Spec file, (which does produce a binary) I see that we end up with the same errors shown above. I do not know how that version of perf is built, since it appears to fail in the build.

After a lot more trial and error, I came up with the following line, which builds perf successfully. It uses the –static version, which should minimize the number of shared objects it requires.
```
/usr/bin/make LDFLAGS=-static    CFLAGS=  -s -C tools/perf V=1  VO=1   NO_LIBELF=1   WERROR=0 NO_LIBUNWIND=1 HAVE_CPLUS_DEMANGLE=1 NO_GTK2=1 NO_STRLCPY=1 NO_BIONIC=1 NO_LIBTRACEEVENT=1 NO_CORESIGHT=1 NO_SYSCALL_TABLE=1 NO_LIBDW_DWARF_UNWIND=1 NO_LIBUNWIND=1 NO_DWARF=1 NO_JVMTI=1 NO_ZLIB=1 NO_LIBBPF=1 NO_SDT=1 NO_LOCAL_LIBUNWIND=1 NO_LIBUNWIND=1 NO_LIBAUDIT=1 NO_LIBCRYPTO=1 NO_SLANG=1 NO_GTK2=1 NO_LIBPERL=1 NO_LIBPYTHON=1 NO_JEVENTS=1 NO_LZMA=1 NO_LIBZSTD=1 NO_LIBCAP=1 NO_LIBNUMA=1 NO_AUXTRACE=1 perf
```
With that building successfully, I can start removing the flags that disable libraries. However, if the library is not installed, it will report the absence and just skip it in the build. In order to have a reproducible build, I need to identify the proper set of packages to include and add them as BuildRequires. I think that, in order to document the decisions, I will also keep any NO_* flags for libraries that we explicitly are not including.

October 08, 2024

Cockpit Project Cockpit 326
Cockpit is the modern Linux admin interface. We release regularly.

Here are the release notes from Cockpit 326, cockpit-podman 96, and cockpit-files 9:

cockpit/ws container: Connect to any Linux server

The quay.io/cockpit/ws container provides Cockpit’s web server in environments such as Kubernetes and Fedora CoreOS, connecting to a remote machine via ssh.

Now, the cockpit/ws container gained the ability to connect to any Linux server, even those without Cockpit installed. This provides a convenient way to perform basic administration tasks remotely. This is similar to the Cockpit Client flatpak (available since release 295), but can run anywhere an OCI container can run.

Currently, the following pages are available when connecting to a server without Cockpit: Overview, Metrics, Terminal, Accounts, and Networking. More pages will be added soon, after vetting them for this use.

cockpit/ws container: Support host-specific SSH keys

The cockpit/ws container now supports adding multiple SSH private keys.

In addition to the existing $COCKPIT_SSH_KEY_PATH environment variable, you can now set host specific $COCKPIT_SSH_KEY_PATH_{HOSTNAME} variables, where {HOSTNAME} is the host name (in capital letters) used in the Connect to: field of the login page.

Thanks to benniekiss for contributing this feature!

Bridge supports PCP; cockpit-pcp package is now obsolete

The Python cockpit-bridge, introduced in Cockpit 294, now implements PCP functionality. As a result, the separate cockpit-pcp package is now obsolete.

Storage: Manage Stratis virtual filesystem sizes

Cockpit supports seting a default and maximum size limit for Stratis virtual filesystems, both during creation and when making adjustments.

Podman: pull images from registries without search API

Container creation now supports registries lacking a search API, including GitHub’s container registry (ghcr.io). You can also select a specific tag for images.

Files: basic keyboard shortcuts

Try it out

Cockpit 326, cockpit-podman 96, and cockpit-files 9 are available now:

October 07, 2024

Fedora fans ساخت خودکار فایل Readme برای ماژول های Terraform

یکی از کارها برای استاندارد سازی ماژول های Terraform داشتن فایل README.md برای ماژول ها می باشد. نوشتن این چنین فایلی برای ماژول ترافوم کار زمانگیری می باشید بویژه وقتی که تعداد این ماژول ها زیاد باشند. در این مطلب قصد داریم تا terraform-docs را جهت خودکار سازی ساخت فایل README.md برای ماژول های Terraform […]
The post ساخت خودکار فایل Readme برای ماژول های Terraform first appeared on طرفداران فدورا.
Josh Bressers Episode 449 – The CUPSpocalypse
Josh and Kurt talk about the recent CUPS issue. The vulnerability itself wasn’t all that exciting, but the whole disclosure process was wild. There’s a lot to talk about, many things didn’t quite go as planned and it all leaked early. Let’s talk about why and what it all means.
https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_449_The_CUPSpocalypse.mp3
Show Notes
Josef Strzibny Running multiple apps on a single server with Kamal 2
Kamal 2 finally brings the most requested feature to reality and allows people to run multiple applications simultaneously on a single server. Here’s how.

The Kamal way

Kamal is an application-centric deploy tool rather than a small PaaS. And this hasn’t changed with the new version 2. But what does it even mean?

Let’s look at a typical config/deploy.yml to run a generic application:
```
# config/deploy.yml
service: [APP_NAME]

image: [DOCKER_REGISTRY]/[APP_NAME]

servers:
  web:
    - 165.22.71.211
  job:
    hosts:
      - 165.22.71.211
    cmd: bin/jobs

proxy:
  ssl: true
  host: [APP_DOMAIN]

registry:
  username: [DOCKER_REGISTRY]

  # Always use an access token rather than real password when possible.
  password:
    - KAMAL_REGISTRY_PASSWORD

env:
  ...
```
As you can notice the configuration describes only one particular service. And this hasn’t changed. Applications still have their own configuration. The only thing that changed is the possibility to share their servers.

Kamal Proxy

Kamal 2 adds support for multiple apps with the new Kamal Proxy. The new proxy registers new deployments for services and handles their gapless switchover.

The only thing Kamal Proxy needs to know is the host (domain) of the service so it can route the traffic to the service web containers. This is done with the following Kamal configuration:
```
# config/deploy.yml
...

proxy:
  ssl: true
  host: [APP_DOMAIN]
```
The extra ssl option let’s us also request automatic SSL/TLS certificates via Let’s Encrypt.

There will only be one instance of Kamal Proxy running on a given server, installed by the first deployed application.

Multiple apps

Let’s say we want to deploy three different application on the same server for a local dealership. The main app, API server, and their marketing website. Then we need three different configurations, one for each app.

The main app will run on app.dealership.com:
```
# dealership/config/deploy.yml
service: dealership

image: [DOCKER_REGISTRY]/dealership

servers:
  web:
    - 165.22.71.211
  job:
    hosts:
      - 165.22.71.211
    cmd: bin/jobs

proxy:
  ssl: true
  host: app.dealership.com

registry:
  ...

env:
  ...
```
The API service will run on api.dealership.com:
```
# dealership-api/config/deploy.yml
service: api

image: [DOCKER_REGISTRY]/dealership-api

servers:
  web:
    - 165.22.71.211

proxy:
  ssl: true
  host: api.dealership.com

registry:
  ...

env:
  ...
```
And the marketing website will be accesible from the main domain as well as www.dealership.com:
```
# marketing/config/deploy.yml
service: marketing

image: [DOCKER_REGISTRY]/dealership-web

servers:
  web:
    - 165.22.71.211

proxy:
  ssl: true
  host: "dealership.com,www.dealership.com"

registry:
  ...

env:
  ...
```
Kamal cannot do redirects right now, so the auto redirect from www to non-www variant has to be done on the application side. Also any accessory that needs to expose an HTTP endpoint should actually be another app like these three.

To deploy them we would run kamal setup for each. The first one will install Docker, set up the kamal network, and make sure kamal-proxy is running. The other two would safely skip these steps and deploy to existing proxy.
```
dealeship$ kamal setup
dealeship-api$ kamal setup
marketing$ kamal setup
```
Debugging

If we want to check what apps should Kamal Proxy be running, we can do so on the server with kamal-proxy list:
```
$ ssh [USER]@[SERVER]
# docker exec kamal-proxy kamal-proxy list
Service          Host                 Target           State    TLS
dealership    	 dealearship.com      cde2433e86d6:80  running  yes
dealership-api   api.dealearship.com  82361b53174f:80  running  yes
...
```
We’ll get what hosts and revisions are running for each deployed service as well as their status.

This is not exposed directly to Kamal but we can fix it with an alias:
```
# config/deploy.yml
...
aliases:
  ...
  apps: server exec docker exec kamal-proxy kamal-proxy list
```
Now running kamal apps gives us a nice rundown of what’s running which is pretty sweet.

October 06, 2024

Radka Janek Steam Deck experience on GPD Win 4 with Fedora Linux
I tried other gaming oriented Linux distributions and found them all to be… well, to be frank, bloated. I don’t need Lutris preinstalled, I don’t use it. Just like I don’t need 20 other tools or launchers or managers installed, with services running and draining my battery. Furthermore, I love the ability to simply “tab out” of my steam gamescope and enjoy full desktop environment.

And so I’ve come to the conclusion, that the best thing I can do is to simply start from scratch. I’ve got a little video showcasing what my install looks like, the below is the minimum you’d need to take care of to get something similar.

Note that this is about standard rpm based Fedora - NOT Atomic Fedora (NOT Silverblue/Kinoite/etc)

fsync-kernel

Most of the tools necessary to achieve this are already there. Some devices, including GPD Win 4 do benefit from enabling the fsync kernel copr repository. In order to use it you need to:
- $ sudo dnf copr enable sentry/kernel-fsync
- Edit /etc/yum.repos.d/fedora.repo and /etc/yum.repos.d/fedora-updates.repo
  - Add exclude=kernel* to the main “[fedora]” and “[fedora-updates]” categories respectively
- You should be able to now simply $ sudo dnf update --refresh to grab the fsync kernel and reboot. Verify with uname -a or rpm -qa | grep kernel to see what you’ve got.
- Should the update above fail, for instance because Fedora has got a higher version, you can force it with $ sudo dnf distro-sync kernel*
hhd

HandHeld Daemon provides various functionality necessary to run your handheld seamlessly, such as TDP limits, both through the decky integration as well as using the desktop UI. Installing it is quite simple - enable the hhd-dev copr repository.
- $ sudo dnf copr enable hhd-dev/hhd
Install all the things

Obviously we need steam and gamescope, both of which are already available. And hhd we enabled above.
- $ sudo dnf install steam gamescope hhd hhd-ui
Executing steam in gamescope

I’ve got a little .desktop file in my taskbar that I use to run it. Shove it wherever you like, tldr this is what I run:
- $ gamescope --mangoapp --steam --default-touch-mode 4 --hide-cursor-delay 2000 -f -W 1280 -H 720 -- steam -gamepadui -steamos3 -steampal -steamdeck -pipewire-dmabuf
- As you can see I’m running mine at 720p even though my desktop is at 1080p. Ain’t got no need for games to run higher.
My entire Desktop file is below, should you wish to benefit from a full copypasta… (Note this contains my username. So fix it on your end!)
```
[Desktop Entry]
Categories=Games
Comment[en_US]=Gamescope with fullscreen steam
Comment=Gamescope with fullscreen steam
Exec=gamescope --mangoapp --steam --default-touch-mode 4 --hide-cursor-delay 2000 -f -W 1280 -H 720 -- steam -gamepadui -steamos3 -steampal -steamdeck -pipewire-dmabuf -nointro
GenericName[en_US]=
GenericName=
Icon=steam
MimeType=
Name[en_US]=SteamGamescope
Name=SteamGamescope
Path=/home/rhea/.steam
StartupNotify=true
Terminal=false
TerminalOptions=
Type=Application
X-KDE-SubstituteUID=false
X-KDE-Username=
```
Further tweaks

Autologin your desktop session

We don’t want login screens for deck-like experience. Note that you still need to use your password for sudo, etc. Again I’m on KDE so your configuration might varry a little bit if you’re not.
- Settings -> Login Screen (SDDM) -> clicky the “behavior” button on top -> clicky the check box to automatically log in as your user, and your session.
- Create the nopasswwdlogin group and addyourself to it, and configure pam appropriately - follow the Arch wiki for Passwordless login
Autostart gamescope

I use KDE, your configuration might differ. I simply first created an autostart application in the KDE settings (search for autostart) and then replaced it with a link to my existing .desktop file:
- $ ln -s ~/.local/share/plasma_icons/steam.desktop ~/.config/autostart/steam.desktop
Intro Video

I replaced the default deck startup video with a single black frame .webm here, as I haven’t figured out a better way to get rid of it heh (-nointro cli argument doesn’t seem to work)
- ~/.steam/root/config/uioverrides/movies/deck_startup.webm
Enjoy!

Find me in the Fedora Linux Discord if you have any issues or questions.

GPD Win4 running Fedora Linux

October 04, 2024

Richard Hughes fwupd 2.0.0 and new tricks
Today I tagged fwupd 2.0.0, which includes lots of new hardware support, a ton of bugfixes and more importantly a redesigned device prober and firmware loader that allows it to do some cool tricks. As this is a bigger-than-usual release I’ve written some more verbose releases notes below.

The first notable thing is that we’ve removed the requirement of GUsb in the daemon, and now use libusb directly. This allowed us to move the device emulation support from libgusb up into libfwupdplugin, which now means we can emulate devices created from sysfs too. This means that we can emulate end-to-end firmware updates on fake hidraw and nvme devices in CI just like we’ve been able to emulate using fake USB devices for some time. This increases the coverage of testing for every pull request, and makes sure that none of our “improvements” actually end up breaking firmware updates on some existing device.

The emulation code is actually pretty cool; every USB control request, ioctl(), read() (and everything inbetween) is recorded from a target device and saved to a JSON file with a unique per-request key for each stage of the update process. This is saved to a zip archive and is usually uploaded to the LVFS mirror and used in the device-tests in fwupd. It’s much easier than having a desk full of hardware and because each emulation is just that, emulated, we don’t need to do the tens of thousands of 5ms sleeps in between device writes — which means most emulations take a few ms to load, decompress, write and verify. This means you can test [nearly] “every device we support” in just a few seconds of CI time.

Another nice change is the removal of GUdev as a dependency. GUdev is a nice GObject abstraction over libudev and then sd_device from systemd, but when you’re dealing with thousands of devices (that you’re poking in weird ways), and tens of thousands of device children and parents the “immutable device state” objects drift from reality and the abstraction layers really start to hurt. So instead of using GUdev we now listen to the netlink socket and parse those events into fwupd FuDevice objects, rather than having an abstract device with another abstract device being used as a data source. It has also allowed us to remove at least one layer of caching (that we had to work around in weird ways), and also reduce the memory requirement both at startup and at runtime at the expense of re-implementing the netlink parsing code. It also means we can easily start using ueventd, which makes it possible to run fwupd on Android. More on that another day!

The old

The new

The biggest change, and the feature that’s been requested the most by enterprise customers is the ability to “stream” firmware from archives into devices. What fwupdmgr used to do (and what 1_9_X still does) is:
- Send the cabinet archive to the daemon as a file descriptor
- The daemon then loads the input stream into memory (copy 1)
- The memory blob is parsed as a cabinet archive, and the blocks-with-header are re-assembled into whole files (copy 2)
- The payload is then typically chunked into pieces, with each chunk being allocated as a new blob (copy 3)
- Each chunk is sent to the device being updated
This worked fine for a 32MB firmware payload — we allocate ~100MB of memory and then free it, no bother at all.

Where this fails is for one of two cases: huge firmware or underpowered machine — or in the pathological case, huge video conferencing camera firmware with inexpensive Google ChromeBook. In that example we might have a 1.5GB firmware file (it’s probably a custom Android image…) on a 4GB-of-RAM budget ChromeBook. The running machine has a measly 1GB free system memory, and then fwupd immediately OOMs when just trying to parse the archive, let alone deploy the firmware.

So what can we do to reduce the number of in memory copies, or maybe even remove them all completely? There are two tricks that fwupd 2.0.x uses to load firmware now, and those two primitives we now use all over the source tree:

Partial Input Stream:

This models an input stream (which you can think of like a file descriptor) that is made up of a part of a different input stream at a specific offset. So if you have a base input stream of [123456789] you can build two partial input streams of, say, [234] and [789]. If you try and read() 5 bytes from the first partial stream you just get 3 bytes back. If you seek to offset 0x1 on the second partial input stream you get the two bytes of [89].

Composite Input Stream

This models a different kind of input stream, which is made up of one or more partial input streams. In some cases there can be hundreds of partial streams making up one composite stream. So if you take the first two partial input streams defined a few lines before, and then add them to a composite input stream you get [234789] — and reading 8 bytes at offset 0x0 from that would give you what you expect.

This means the new way of processing firmware archives can be:
- Send the cabinet archive to the daemon as a file descriptor
- The daemon parses it as a cab archive header, and adds the data section of each block to a partial stream that references the base stream at a specific offset
- The daemon “collects” all the partial streams into a composite stream for each file in the archive that spans multiple blocks
- The payload is split into chunks, with each chunk actually being a partial stream of the composite file stream
- Each chunk is read from the stream, and sent to the device being updated
Sooo…. We never actually read the firmware payload from the cabinet file descriptor until we actually send the chunk of payload to the hardware. This means we have to seek() all over the place, possibly many times for each chunk, but in the kernel a seek() is really just doing some pointer maths to a memory buffer and so it’s super quick — even faster in real time than the “simple” process we used in 1_9_X. The only caveat is that you have to use uncompressed cabinet archives (the default for the LVFS) — as using MSZIP decompression currently does need a single copy fallback.

This means we can deploy a 1.5GB firmware payload using an amazingly low 8MB of RSS, and using less CPU that copying 1.5GB of data around a few times. Which means, you can now deploy that huge firmware to that $3,000 meeting room camera from a $200 ChromeBook — but also means we can do the same in RHEL for 5G mobile broadband radios on low-power, low-cost IoT hardware.

Making such huge changes to fwupd meant we could justify branching a new release, and because we bumped the major version it also made sense to remove all the deprecated API in libfwupd. All the changes are documented in the README file, but I’ve already sent patches for gnome-firmware, gnome-software and kde-discover to make the tiny changes needed for the library bump.

My plan for 2.0.x is to ship it in Flathub, and in Fedora 42 — but NOT Fedora 41, RHEL 9 or RHEL 10 just yet. There is a lot of new code that’s only had a little testing, and I fully expect to do a brown paperbag 2.0.1 release in a few days because we’ve managed to break some hardware for some vendor that I don’t own, or we don’t have emulations for. If you do see anything that’s weird, or have hardware that used to be detected, and now isn’t — please let us know.

Anyway, enough talking for now, enjoy!
Daniel Vrátil QCoro 0.11.0 Release Announcement
QCoro 0.11.0 Release Announcement

A long over-due release which has accumulated a bunch of bugfixes but also some fancy new features…read on!

As always, big thanks to everyone who reported issues and contributed to QCoro. Your help is much appreciated!

QCoro::LazyTask<T>

The biggest new features in this release is the brand-new QCoro::LazyTask<T>. It’s a new return type that you can use for your coroutines. It differs from QCoro::Task<T> in that, as the name suggest, the coroutine is evaluated lazily. What that means is when you call a coroutine that returns LazyTask, it will return imediately without executing the body of the coroutine. The body will be executed only once you co_await on the returned LazyTask object.

This is different from the behavior of QCoro::Task<T>, which is eager, meaning that it will start executing the body immediately when called (like a regular function call).
```
QCoro::LazyTask<int> myWorker()
{
    qDebug() << "Starting worker";
    co_return 42;
}

QCoro::Task<> mainCoroutine()
{
    qDebug() << "Creating worker";
    const auto task = myWorker();
    qDebug() << "Awaiting on worker";
    const auto result = co_await task;
    // do something with the result
}
```
This will result in the following output:
```
mainCoroutine(): Creating worker
mainCoroutine(): Awaiting on worker
myWorker(): Starting worker
```
If myWorker() were a QCoro::Task<T> as we know it, the output would look like this:
```
mainCoroutine(): Creating worker
myWorker(): Starting worker
mainCoroutine(): Awaiting on worker
```
The fact that the body of a QCoro::LazyTask<T> coroutine is only executed when co_awaited has one very important implication: it must not be used for Qt slots, Q_INVOKABLEs or, in general, for any coroutine that may be executed directly by the Qt event loop. The reason is, that the Qt event loop is not aware of coroutines (or QCoro), so it will never co_await on the returned QCoro::LazyTask object - which means that the code inside the coroutine would never get executed. This is the reason why the good old QCoro::Task<T> is an eager coroutine - to ensure the body of the coroutine gets executed even when called from the Qt event loop and not co_awaited.

For more details, see the documentation of QCoro::LazyTask<T>.

Defined Semantics for Awaiting Default-Constructed and Moved-From Tasks

This is something that wasn’t clearely defined until now (both in the docs and in the code), which is what happens when you try to co_await on a default-constructed QCoro::Task<T> (or QCoro::LazyTask<T>):
```
co_await QCoro::Task<>(); // will hang indefinitely!
```
Previously this would trigger a Q_ASSERT in debug build and most likely a crash in production build. Starting with QCoro 0.11, awaiting such task will print a qWarning() and will hang indefinitely.

The same applies to awaiting a moved-from task, which is identical to a default-constructed task:
```
QCoro::LazyTask<int> task = myTask();
handleTask(std::move(task));

co_await task; // will hang indefinitely!`
```
Compiler Support

We have dropped official support for older compilers. Since QCoro 0.11, the officially supported compilers are:
- GCC >= 11
- Clang >= 15
- MSVC >= 19.40 (Visual Studio 17 2022)
- AppleClang >= 15 (Xcode 15.2)
QCoro might still compile or work with older versions of those compilers, but we no longer test it and do not guarantee that it will work correctly.

The reason is that coroutine implementation in older versions of GCC and clang were buggy and behaved differently than they do in newer versions, so making sure that QCoro behaves correctly across wide range of compilers was getting more difficult as we implemented more and more complex and advanced features.

Other Features and Changes

A coroutine-friendly version of QFuture::takeResult() is now available in the form of QCoroFuture::takeResult() when building QCoro against Qt 6 (#217).

QCoro::waitFor(QCoro::Task<T>) no longer requires that the task return type T is default-constructible (#223, Joey Richey)

Bugfixes
- Suppress Clang error when building against Android NDK <= 25 (#204, Daniel Vrátil)
- Fixed missing QtGui dependency in QCoroQuick module (#209, Andreas Sturmlechner)
- Fixed QCoroIODevice::write() always returning 0 instead of bytes written (#211, Daniel Vrátil)
- Fixed unchecked std::optional access in QCoroIODevice::write
- Fixed awaiting on signal emission with qCoro() would resume the awaiter in the sender’s thread context (#213, Daniel Vrátil)
- Fixed build wilth clang 18 due to missing #include <exception> (#220, Micah Terhaar)
- Fixed crash when QNetworkAccessManager is destroyed from a coroutine awaiting on a network reply (#231, Daniel Vrátil)
Full changelog

See changelog on Github

Support

If you enjoy using QCoro, consider supporting its development on GitHub Sponsors or buy me a coffee on Ko-fi (after all, more coffee means more code, right?).
Dave Airlie zinking the video

A few years ago Mike and I discussed adding video support to zink, so that we could provide vaapi on top of vulkan video implementations.
This of course got onto a long TODO list and we nerdsniped each other into moving it along, this past couple of weeks we finally dragged it over the line.
This MR adds initial support for zink video decode on top of Vulkan Video. It provides vaapi support. Currently it only support H264 decode, but I've implemented AV1 decode and I've played around a bit with H264 encode. I think adding H265 decode shouldn't be too horrible.
I've tested this mainly on radv, and a bit on anv (but there are some problems I should dig into).
Peter Hutterer HIOCREVOKE merged for kernel 6.12

TLDR: if you know what EVIOCREVOKE does, the same now works for hidraw devices via HIDIOCREVOKE.

The HID standard is the most common hardware protocol for input devices. In the Linux kernel HID is typically translated to the evdev protocol which is what libinput and all Xorg input drivers use. evdev is the kernel's input API and used for all devices, not just HID ones.

evdev is mostly compatible with HID but there are quite a few niche cases where they differ a fair bit. And some cases where evdev doesn't work well because of different assumptions, e.g. it's near-impossible to correctly express a device with 40 generic buttons (as opposed to named buttons like "left", "right", ...[0]). In particular for gaming devices it's quite common to access the HID device directly via the /dev/hidraw nodes. And of course for configuration of devices accessing the hidraw node is a must too (see Solaar, openrazer, libratbag, etc.). Alas, /dev/hidraw nodes are only accessible as root - right now applications work around this by either "run as root" or shipping udev rules tagging the device with uaccess.

evdev too can only be accessed as root (or the input group) but many many moons ago when dinosaurs still roamed the earth (version 3.12 to be precise), David Rheinsberg merged the EVIOCREVOKE ioctl. When called the file descriptor immediately becomes invalid, any further reads/writes will fail with ENODEV. This is a cornerstone for systemd-logind: it hands out a file descriptor via DBus to Xorg or the Wayland compositor but keeps a copy. On VT switch it calls the ioctl, thus preventing any events from reaching said X server/compositor. In turn this means that a) X no longer needs to run as root[1] since it can get input devices from logind and b) X loses access to those input devices at logind's leisure so we don't have to worry about leaking passwords.

Real-time forward to 2024 and kernel 6.12 now gained the HIDIOCREVOKE for /dev/hidraw nodes. The corresponding logind support has also been merged. The principle is the same: logind can hand out an fd to a hidraw node and can revoke it at will so we don't have to worry about data leakage to processes that should not longer receive events. This is the first of many steps towards more general HID support in userspace. It's not immediately usable since logind will only hand out those fds to the session leader (read: compositor or Xorg) so if you as application want that fd you need to convince your display server to give it to you. For that we may have something like the inputfd Wayland protocol (or maybe a portal but right now it seems a Wayland protocol is more likely). But that aside, let's hooray nonetheless. One step down, many more to go.

One of the other side-effects of this is that logind now has an fd to any device opened by a user-space process. With HID-BPF this means we can eventually "firewall" these devices from malicious applications: we could e.g. allow libratbag to configure your mouse' buttons but block any attempts to upload a new firmware. This is very much an idea for now, there's a lot of code that needs to be written to get there. But getting there we can now, so full of optimism we go[2].

[0] to illustrate: the button that goes back in your browser is actually evdev's BTN_SIDE and BTN_BACK is ... just another button assigned to nothing particular by default.
[1] and c) I have to care less about X server CVEs.
[2] mind you, optimism is just another word for naïveté

October 03, 2024

Peter Czanik FreeBSD audit source for syslog-ng

Two weeks ago, I was at EuroBSDcon and received a feature request for syslog-ng. The user wanted to collect FreeBSD audit logs together with other logs using syslog-ng. Writing a native driver in C is time consuming. However, creating an integration based on the program() source of syslog-ng is not that difficult.

This blog shows you the current state of the FreeBSD audit source, how it works, and its limitations. It is also a request for feedback. Please share your experiences at https://github.com/syslog-ng/syslog-ng/discussions/5150!

Before you begin

First, you must enable audit logging on your FreeBSD box. If you do not want to enable it permanently, enable it only for the testing:

service auditd onestart

The syslog-ng package does not have XML parsing enabled by default. The sample configuration I show in the blog uses XML parsing. You should compile the sysutils/syslog-ng port with XML parsing enabled. If you do not enable XML parsing, you can still forward XML logs without parsing, or change the praudit command line to switch to plain text output.

Configuring syslog-ng

The actual “driver” is very simple, just a few lines. Once it is ready, it will be added to the syslog-ng configuration library (SCL), and you do not have to copy it into your configuration. For now, append it to syslog-ng.conf, or create a new configuration file, if you implemented using an include directory in your configuration.

@define def-praudit-params " -p -l -x"

block source freebsd-audit(params("`def-praudit-params`")) {
  program(
    "tail -F /var/audit/current | praudit `params`"
    flags(no-parse)
  );
};

It is a configuration block, typically used in the SCL. It uses the tail command to follow the FreeBSD audit log (with -F to detect file rotations), and praudit is configured to keep running, and print single lines in XML format.

And here comes the rest of the configuration, utilizing the new source in multiple setups. Once the above configuration block is part of SCL, you only need to include this part in your configuration.

source s_fbaudit_xml {
  freebsd-audit();
};

parser p_xml {
  xml(prefix("fbaudit."));
};
destination d_fbaudit_json {
  file("/var/log/fbaudit.json" template("$(format-flat-json
  --leave-initial-dot --scope rfc5424 --scope dot-nv-pairs
        --scope nv-pairs)\n\n"));
};
log {
  source(s_fbaudit_xml);
  parser(p_xml);
  destination(d_fbaudit_json);
};

source s_fbaudit {
  freebsd-audit(params("-p -l"));
};

destination d_fbaudit {
  file("/var/log/fbaudit");
};
log {
  source(s_fbaudit);
  destination(d_fbaudit);
};

This configuration contains two test setups. The first one calls the freebsd-audit() source without any additional parameters, thus having an XML formatted output. It parses the incoming message using the XML parser, and saves it to a JSON formatted file, so you can see the name-value pairs parsed from the XML.

The second one sets the output to single line plain text format and writes it as a regular syslog message.

Note, that in both cases we use the no-parse flag, so the original message is stored in the $MESSAGE macro of syslog-ng, and syslog-ng creates a syslog-ng message header.

Bugs and limitations

While testing the freebsd-audit() source, I ran into a few bugs and limitations.

If a field has a space in it, syslog-ng adds double quotation marks.
The XML parser adds a leading underscore to tag names, which cannot be changed / removed.
As we read the logs using the tail command, there might be some missing or duplicate audit logs when syslog-ng is restarted (depending on the rate of audit logs and the downtime of syslog-ng).
The XML parser throws an error message while reading the beginning of the XML formatted audit log, as it cannot properly parse the header lines.

Testing

Add the above lines to your syslog-ng configuration (disable the XML parser, if you do not have it compiled into syslog-ng), and restart syslog-ng. The easiest way to generate some audit log messages is to login on the FreeBSD console, or using ssh. Once you generated some audit logs, you should see two new log files under the /var/log/ directory.

root@fb14:/usr/local/etc # tail -3 /var/log/fbaudit
Sep 27 15:02:37 fb14 header,97,11,OpenSSH login,0,Fri Sep 27 12:34:25 2024, + 830 msec,subject_ex,root,root,wheel,root,wheel,1321,1321,57418,172.16.167.1,text,successful login root,return,success,0,trailer,97,
Sep 27 15:02:37 fb14 header,97,11,OpenSSH login,0,Fri Sep 27 12:56:15 2024, + 188 msec,subject_ex,root,root,wheel,root,wheel,1404,1404,48770,172.16.167.1,text,successful login root,return,success,0,trailer,97,
Sep 27 15:07:45 fb14 header,97,11,OpenSSH login,0,Fri Sep 27 13:07:45 2024, + 379 msec,subject_ex,root,root,wheel,root,wheel,1522,1522,42126,172.16.167.1,text,successful login root,return,success,0,trailer,97,

root@fb14:/usr/local/etc # tail -6 /var/log/fbaudit.json
{"fbaudit.record.text":"\"successful login root\"","fbaudit.record.subject._uidit-uid":"root","fbaudit.record.subject._tiddt-uid":"57418172.16.167.1","fbaudit.record.subject._siddt-uid":"1321","fbaudit.record.subject._ruidt-uid":"root","fbaudit.record.subject._rgidt-uid":"wheel","fbaudit.record.subject._piddt-uid":"1321","fbaudit.record.subject._gidit-uid":"wheel","fbaudit.record.subject._audit-uid":"root","fbaudit.record.return._retval":"0","fbaudit.record.return._errval":"success","fbaudit.record._version":"11","fbaudit.record._timefier":"\"Fri Sep 27 12:34:25 2024\"","fbaudit.record._msecfier":"\" + 830 msec\"","fbaudit.record._modifier":"0","fbaudit.record._eventon":"\"OpenSSH login\"","TRANSPORT":"local+program","SOURCE":"s_fbaudit_xml","PRIORITY":"notice","MSGFORMAT":"raw","MESSAGE":"<record version=\"11\" event=\"OpenSSH login\" modifier=\"0\" time=\"Fri Sep 27 12:34:25 2024\" msec=\" + 830 msec\" ><subject audit-uid=\"root\" uid=\"root\" gid=\"wheel\" ruid=\"root\" rgid=\"wheel\" pid=\"1321\" sid=\"1321\" tid=\"57418172.16.167.1\" /><text>successful login root</text><return errval=\"success\" retval=\"0\" /></record>","HOST_FROM":"fb14","HOST":"fb14","FACILITY":"user","DATE":"Sep 27 15:02:37"}

{"fbaudit.record.text":"\"successful login root\"","fbaudit.record.subject._uidit-uid":"root","fbaudit.record.subject._tiddt-uid":"48770172.16.167.1","fbaudit.record.subject._siddt-uid":"1404","fbaudit.record.subject._ruidt-uid":"root","fbaudit.record.subject._rgidt-uid":"wheel","fbaudit.record.subject._piddt-uid":"1404","fbaudit.record.subject._gidit-uid":"wheel","fbaudit.record.subject._audit-uid":"root","fbaudit.record.return._retval":"0","fbaudit.record.return._errval":"success","fbaudit.record._version":"11","fbaudit.record._timefier":"\"Fri Sep 27 12:56:15 2024\"","fbaudit.record._msecfier":"\" + 188 msec\"","fbaudit.record._modifier":"0","fbaudit.record._eventon":"\"OpenSSH login\"","TRANSPORT":"local+program","SOURCE":"s_fbaudit_xml","PRIORITY":"notice","MSGFORMAT":"raw","MESSAGE":"<record version=\"11\" event=\"OpenSSH login\" modifier=\"0\" time=\"Fri Sep 27 12:56:15 2024\" msec=\" + 188 msec\" ><subject audit-uid=\"root\" uid=\"root\" gid=\"wheel\" ruid=\"root\" rgid=\"wheel\" pid=\"1404\" sid=\"1404\" tid=\"48770172.16.167.1\" /><text>successful login root</text><return errval=\"success\" retval=\"0\" /></record>","HOST_FROM":"fb14","HOST":"fb14","FACILITY":"user","DATE":"Sep 27 15:02:37"}

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

What is next?

The above configuration collects FreeBSD audit logs to some local files. In most cases you want to collect log messages centrally.

Also, do not forget to provide us with feedback at https://github.com/syslog-ng/syslog-ng/discussions/5150. We are happy to hear problem reports, as it also means that you are actually testing what we are working on. It helps us to make syslog-ng even better. And of course we are also very happy to hear success stories!

If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/syslog-ng/syslog-ng. On Twitter, I am available as @PCzanik, on Mastodon as @Pczanik@fosstodon.org.

Jon Chiappetta Starting a new app for iPhone that allows for some pre-styled/formatted widgets to be used!
I am using this page as the officially documented support page for a new iOS app called “Widgets Factory”

It has been recently initially approved and released to the iOS App Store!

~

Here are some example screenshots:
~

Known Issues

The background task and refresh processing capabilities on iOS are severely limited and hampered due to some more hostile protection mechanisms built in. It would be nice if Apple could improve the background system to guarantee some additional service capabilities:
- Don’t sleep or stop the apps non-main thread if it is expecting a background refresh
- Ensure that the requested caller gets a background refresh process time after waiting a maximum of 5-15 minutes
- Provide a specific API method call that is background approved to perform the basic needed tasks on behalf of the calling application with a minimal guaranteed processing time:
  - Location Coordinates
  - Map Snapshot
  - Web Fetch
  - Widget Views
  - Push Notifications
It would also be nice for apps that are free without ads to be able to have a one-time (or even re-occurring) tip jar that user’s could donate whatever amount they feel comfortable with to the developer.

Contact Information
- root<ats>fossjon<dot>com
- Or comment on this post!
~

October 02, 2024

Kushal Das Thank you Gnome Nautilus scripts
As I upload photos to various services, I generally resize them as required based on portrait or landscape mode. I used to do that for all the photos in a directory and then pick which ones to use. But, I wanted to do it selectively, open the photos in Gnome Nautilus (Files) application and right click and resize the ones I want.

This week I noticed that I can do that with scripts. Those can be in any given language, the selected files will be passed as command line arguments, or full paths will be there in an environment variable NAUTILUS_SCRIPT_SELECTED_FILE_PATHS joined via newline character.

To add any script to the right click menu, you just need to place them in ~/.local/share/nautilus/scripts/ directory. They will show up in the right click menu for scripts.

Below is the script I am using to reduce image sizes:
```
#!/usr/bin/env python3
import os
import sys
import subprocess
from PIL import Image

# paths = os.environ.get("NAUTILUS_SCRIPT_SELECTED_FILE_PATHS", "").split("\n")

paths = sys.argv[1:]

for fpath in paths:
    if fpath.endswith(".jpg") or fpath.endswith(".jpeg"):
        # Assume that is a photo
        try:
            img = Image.open(fpath)
            # basename = os.path.basename(fpath)
            basename = fpath
            name, extension = os.path.splitext(basename)
            new_name = f"{name}_ac{extension}"
            w, h = img.size
            # If w > h then it is a landscape photo
            if w > h:
                subprocess.check_call(["/usr/bin/magick", basename, "-resize", "1024x686", new_name])
            else: # It is a portrait photo
                subprocess.check_call(["/usr/bin/magick", basename, "-resize", "686x1024", new_name])
        except:
            # Don't care, continue
            pass
```
You can see it in action (I selected the photos and right clicked, but the recording missed that part):

October 01, 2024

Fedora Community Blog Laptops, Badges, and a Pelican case of Swag: DevConf Event Report

Following the week of Flock 2024, Fedora kept the late-summer conference train rolling with a community booth at this year’s DevConf US held at Boston University from August 14-16, 2024. This year’s conference was an opportunity to sponsor another key community event, spread the word about Fedora, and connect with influential community members while learning about new industry developments, paying particular attention to AI and cloud spaces.

The Conference

This year’s conference kicked off with a Fireside Chat session with Kelsey Hightower, followed by a series of talks in various tracks, highlighting recent improvements in areas like Cloud Infrastructure, AI, Automotive, Mobile, Development, Security, Compliance, Open Source Success Stories, as well as Leadership and creating Inclusive Communities.

Among this large array of talks were a few that may be of interest to different segments of the wider Fedora community. There were CentOS Automotive talks; talks adapted from presentations from FWD 2024 and Flock 2024; talks from notable community members like Dan Walsh, Neal Gompa, Davide Cavalca, and David Duncan; as well as a couple others that may be of some interest to Fedorans more generally.

The Booth

In addition to these talks, Fedora also had a community booth present at the event. This was an opportunity for members of the Fedora community to come to say “hi,” claim a Fedora Badge, and learn more about some of the more recent developments within Fedora. I’m incredibly grateful to the community members who helped run the booth, including Adam Williamson, David Duncan, Neal Gompa, Sythong Run, Matthew Miller, and everyone else who stopped by to help share the newest developments within Fedora.

Overall, the Fedora booth seemed to go pretty smoothly. One of the main attractions that drew people to the booth was the one laptop per child XO PC, a $100 laptop that ran Fedora and helped bring computer access to parts of the world without easy access to the internet. This green and white PC looked very out of place with a contrasting color scheme and two extendable antennas, especially since it was placed between far more recent models of Slimbook and ThinkPad laptops that were also on display at the booth.

While a strange contrast in both its age and appearance, it seemed like this device still worked pretty well for drawing people to the booth and feeding that interest with some history on the XO PC and how Fedora was involved.

Having the ThinkPad and Slimbook present also created a nice transition to an introduction of the soon-to-launch Fedora Ready promotional program, complete with a nice opportunity for a casual joke about how “unfortunately the green one with the antennae is not part of the Fedora Ready program.” This program was one of the primary things I found myself talking about when people were asking about Fedora, as it’s a great, highly recent project that one of my fellow summer interns Roseline Bassey helped work on. It also serves as a great example of how Fedora is working to make Linux a more viable option for general desktop use by helping improve the discoverability of well-supported hardware as more and more vendors start supporting Linux-based operating systems.

Fedora swag was also quite popular at the booth this year. Many people were grabbing stickers, especially the new Colúr stickers that were seen at Flock. People were also occasionally taking these stickers for people they knew who couldn’t be at the conference, such as their kids. The Fedora Tumblers were especially popular. Being my first time running a conference booth, I had not quite been careful enough with the selection of swag and put a few too many out at the start of the conference. Between this minor mistake and their popularity, they ran out pretty quickly, and by the end of the conference, at least a couple people had come by specifically to ask for them.

There also seemed to be a decent number of people who stopped by the booth either with very minimal prior knowledge of Fedora or because they had been using Fedora for a long time and wanted to start contributing. Many of the more casual visitors were likely hoping to collect stamps from each booth to win a prize; however, a couple community members ended up sticking around for extended conversations and fun shenanigans. Overall, about half of the attendees at the conference were Red Hatters (likely due to the proximity to the Boston office), and many of them also stopped by the booth to learn about Fedora.

In total, we handed out roughly 12 Fedora badges to new or existing Fedora contributors who claimed them by scanning the QR code at our booth. I suspect this number may have been higher if the process of claiming a badge as a new contributor didn’t first require going through the many steps of creating an FAS account. Maybe in the future, there will be a way to help improve the Fedora contributor onboarding experience at conferences by allowing attendees to pre-claim a badge with just an email address. Then a helpful reminder to finish claiming the badge could be sent after the event, guiding people through the FAS signup process and suggesting possible next steps as a new contributor.

The Experience Overall

Given that this was my first time being in charge of a booth at a conference, I would say the experience was quite well prepared before I was even involved. I would attribute the bulk of this smoothness to both the amazing Red Hat events team (shoutout to Dorka for running around for nearly the entire event to keep things running smoothly) and to the existence of the event kit. This event kit—a Pelican case containing almost everything that was needed to run the booth, such as branded tablecloths, swag, and the laptops that were displayed on the table made the booth management process quite easy since everything was already prepared. The biggest hurdle was simply fitting everything in the pelican case after the event and keeping it organised, especially with how densely packed it was with Fedora swag.

Overall Thoughts

So, is it worth doing again? On a personal level I was pretty tired after having attended three conferences in a little under three weeks, and ended up needing at least a week to chill out and recharge, so overall I probably would not recommend trying to do that again. Being asked to help staff the Fedora booth on relatively little notice also meant that I largely ended up choosing to stay at the booth for most of the conference, rather than exploring more of the talks, but since the talks were being recorded, I didn’t feel like this was too much of a loss.

Ultimately, though, I think the success of the event comes down to the goal that was set out for the event in the first place. Having face-to-face interaction with the community at any event is nearly always valuable to any community working in the open, but when there are limits on budget or other resources, the events you choose to attend should be geared towards your goal. If Fedora’s goal with being at DevConf US was to grow Fedora among new audiences and external contributors, another location may have made more sense, however, I think the general goal of gaining contributors along with communicating new developments in Fedora provided something interesting for everyone who came to the booth, regardless of the color of their hat.

Overall, I think this was a great opportunity to experience my first time staffing a booth at a conference, and I think having a broad selection of new developments and things to talk about helped make it easy to provide something interesting to any current or future Fedora users who came to the booth. When the worst part of the conference is being tired halfway through the day because you decided to try and string three conferences together in three weeks, I guess that means everything went pretty well!

The post Laptops, Badges, and a Pelican case of Swag: DevConf Event Report appeared first on Fedora Community Blog.
Fedora fans تشخیص SSD یا HDD بودن هاردیسک در لینوکس

شاید برای شما هم پیش آمده باشد که به یک سیستم لینوکسی دسترسی دارید و می خواهد نوع هاردیسک (SSD یا HDD) آن را تشخیص دهید. برای اینکار روش ها و ابزارهای گوناگونی وجود دارد که در این مطلب قصد داریم به برخی از آنها اشاره کنیم. نکته اینکه برای اجرای برخی دستورها نیاز به […]
The post تشخیص SSD یا HDD بودن هاردیسک در لینوکس first appeared on طرفداران فدورا.

September 30, 2024

Fedora Community Blog Fedora Ops Architect Report
Hello Fedora folks! Can you believe this is the end of September already? Blink and you might have missed the month! I’ve rounded up a few things that are happening around the project that may be of interest, so read on for more.

Fedora Linux 41 Development

We are right in the thick of release season, and if you have a change landing in F41, now is the best time to make sure everything is working as planned. If you get a notification that you are tagged in a release notes ticket, please do verify if your change needs a release note or not, and if so please write one.

We enter Final Freeze on October 15th, and help with identifying and resolving blocker bugs would be hugely appreciated. You can propose and help out through our Blocker Bugs app.

A reminder that Fedora Linux 39 goes EOL on November 19th, and for other key milestones, please reer to the Fedora Linux 41 schedule.

Fedora Linux 42 Development

Fedora Linux 42

A.K.A, the answer to life, the universe and everything. Below are some changes currently in review by our community, and some that are now with FESCo for voting.
- Announced Change Proposals
- Change Proposals awaiting FESCo decision
Our Change Set page has a list of the currently accepted changes, and below are a list of some key dates:
- December 18th – Changes requiring infrastructure changes
- December 24th – Changes requiring mass rebuild
- December 24th – System Wide changes
- January 14th – Self Contained changes
- February 4th – Changes need to be Testable
- February 4th – Branching
- February 18th – Changes need to be Complete
Be sure to keep an eye on the Fedora Linux 42 release schedule, and our Fedora Linux 43 and Fedora Linux 44 are now live also.

Hot Topics

The Fedora Council has proposed an update to our policy governing the promotion to Edition status. You can read more about this change on the blog post and or on discussions.fpo.

There is some great things happening in the boot-c initiative right now! A report on the activity was published last week, and you can read about the progress on the discussions.fpo post.

Our git forge investigation is still in progress with instances of both Forgejo and GitLab available for testing purposes. Please read Akashdeep Dhar’s post about how to get involved with the testing and where to go for help when doing so. We are aiming for the end of October to complete the investigation of the user stories we received and for a report to be submitted to the Council for review, deliberation and decision. The report will also be made public too.

The post Fedora Ops Architect Report appeared first on Fedora Community Blog.
Adam Young Parsing a yum repo with XPath
https://gnome.pages.gitlab.gnome.org/libxml2/xmllint.htmlLets say you want to see what src RPMs are in a given yum repo. If the author used createrepo to create the yum repo, it should be an a fairly standard layout. The following xpath query should pull it out.

Note that you can get xmllint to run the xpath query from libxml2
```
curl http://$yumserver/$somerepo/ > repo.html
xmllint --html  --xpath "//html/body/table/tr/td/a/@href" repo.html | grep src
```
The portion of the query a/@href will match a tag like this
```
<a href="https://blam.src.rpm">
```
Kushal Das Breaking out of algorithm

Many of you already know about my love of photography. I am taking photos for many years, mostly people photos. Portraits in conferences like PyCon or Fedora events. I regularly post photos to wikipedia too, specially for the people/accounts which does not have good quality profile photos. I stopped doing photography as we moved to Sweden, digital camera was old and becoming stable in a new country (details in a different future blog) takes time. But, last year Anwesha bought me a new camera, actually two different cameras. And I started taking photos again.

I started regular photos of the weekly climate protests / demonstrations of Fridays for Future Stockholm group. And then more different street protests and some dance/music events too. I don't have a Facebook account and most people asked me to share over Instagram, so I did that. But, as I covered more & more various protests as a photographer, I noticed my Instagram postos are showing up less in people's feeds. Very less. Was wondering different ways of breaking out of the algorithmic restriction.

Pixelfed is a decentralized, federated ActivityPub based system to share photos. I am going to share photos more on this platform, and hoping people will slowly see more. I started my account yesterday.

You can follow me from any standard ActivityPub system, say your mastodon account itself. Search for @kushal@pixel.kushaldas.photography or https://pixel.kushaldas.photography/kushal in your system and you can then follow it like any other account. If you like the photos, then please share the account (or this blog post) more to your followers and help me to break out of the algorithmic restrictions.

In the technology side, the server runs Debian and containers. On my Fedora system I am super happy to add a few scripts for Gnome Files, they help me to resize the selected images before upload (I will write a blog post tomorrow on this).
Fedora Community Blog Proposed change to the Fedora Council policy for Edition promotion
The Fedora Council is considering a change to our policy for promotion of a Fedora deliverable to “Edition” status. Please read that entire document for context before commenting.

Part of the policy currently reads:
A Fedora Edition:
- addresses a distinct, relevant, and broad use-case or user-base that a Fedora Edition is not currently serving;
- is a long term investment for the Fedora Project; and
- is consistent with all of Fedora’s Four Foundations.
We propose an additional line:

The Council may make exceptions to the “distinct” rule when we determine that doing so best fits the Project’s Mission and Vision.

This change reflects actual practice. For example, there is clear overlap between the use-cases and potential user-bases for the current Server, Cloud, and CoreOS Editions, but each takes a different approach. We are currently considering an exception for a KDE Desktop Edition, which would overlap with Fedora Workstation.

This topic is open for community discussion, following our Policy Change Policy. After two weeks, the Council will vote in a new ticket, and if approved, the policy will be updated.

Approval of this change would not automatically mean that approval of a KDE Desktop Edition, but would allow that possibility.

The post Proposed change to the Fedora Council policy for Edition promotion appeared first on Fedora Community Blog.
Josh Bressers Episode 448 – What’s wrong with CISA?
Josh and Kurt talk about a few things that have recently come out of CISA. They seem to be blaming the vendors for a lot of the problems, but there’s also not any actionable advice telling the vendors what they should be doing. This feels like the classic case of “just security harder”. We need CISA to be leading the way funding and defining security, not blaming vendors for giving the market what it demands.
https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_448_Whats_wrong_with_CISA.mp3
Show Notes
Fabio Alessandro Locati On being the cheapest cloud

Recently, I heard a pitch from a public cloud company. Among other characteristics, a key aspect they stressed is that they are the cheapest cloud. This aspect struck me. Not because I believe it is or is not, but because I’ve heard many companies pitch themselves as the cheapest cloud over the years. I asked the CTO if they were foreseeing consistent and planned cuts in the pricing every year or so.

September 28, 2024

Kushal Das Updated blog theme after many years

One of the major reason of using static blogging for me is to less worry about how the site will look like. Instead the focus was to just write (which of course I did not do well this year). I did not change my blog's theme for many many years.

But, I noticed Oskar Wickström created a monospace based site and kindly released it under MIT license. I liked the theme, so decided to start using it. I still don't know HTML/CSS but managed to change the template for my website.

You can let me know over mastodon what do you think :)

September 27, 2024

Remi Collet PHP on the road to the 8.4.0 release
Version 8.4.0 Release Candidate 1 is released. It's now enter the stabilisation phase for the developers, and the test phase for the users.

RPMs are available in the php:remi-8.4 stream for Fedora ≥ 39 and Enterprise Linux ≥ 8 (RHEL, CentOS, Alma, Rocky...) and as Software Collection in the remi-safe repository (or remi for Fedora)

The repository provides development versions which are not suitable for production usage.

Also read: PHP 8.4 as Software Collection

Installation : follow the Wizard instructions.

Replacement of default PHP by version 8.4 installation, module way (simplest way):
```
dnf module reset php
dnf module install php:remi-8.4
dnf update
```
Parallel installation of version 8.4 as Software Collection (recommended for tests):
```
yum install php84
```
To be noticed :
- EL9 rpm are build using RHEL-9.4
- EL8 rpm are build using RHEL-8.10
- lot of extensions are also available, see the PHP extension RPM status page and PHP version 8.4 tracker
- follow the comments on this page for update until final version
- proposed as a Fedora 42 change
Information, read:
- UPGRADING
- UPGRADING.INTERNALS
Base packages (php)

Software Collections (php84)
Remi Collet PHP version 8.1.30, 8.2.24 and 8.3.12
RPMs of PHP version 8.3.12 are available in the remi-modular repository for Fedora ≥ 39 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.2.24 are available in the remi-modular repository for Fedora ≥ 39 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

RPMs of PHP version 8.1.30 are available in the remi-modular repository for Fedora ≥ 39 and Enterprise Linux ≥ 8 (RHEL, Alma, CentOS, Rocky...).

The packages are available for x86_64 and aarch64.

PHP version 8.0 has reached its end of life and is no longer maintained by the PHP project.

These versions are also available as Software Collections in the remi-safe repository.

These Versions fix 4 security bugs (CVE-2024-8925, CVE-2024-8926, CVE-2024-8927, CVE-2024-9026), so update is strongly recommended.

Version announcements:
Installation: use the Configuration Wizard and choose your version and installation mode.

Replacement of default PHP by version 8.3 installation (simplest):
```
dnf module switch-to php:remi-8.3/common
```
Parallel installation of version 8.3 as Software Collection
```
yum install php83
```
Replacement of default PHP by version 8.2 installation (simplest):
```
dnf module switch-to php:remi-8.2/common
```
Parallel installation of version 8.2 as Software Collection
```
yum install php82
```
And soon in the official updates:
- Fedora Rawhide now has PHP version 8.3.11
- Fedora 41 - PHP 8.3.12
- Fedora 40 - PHP 8.3.12
- Fedora 39 - PHP 8.2.24
To be noticed :
- EL-9 RPMs are built using RHEL-9.4
- EL-8 RPMs are built using RHEL-8.10
- EL-7 repository is closed
- intl extension now uses libicu74 (version 74.2)
- mbstring extension (EL builds) now uses oniguruma5php (version 6.9.9, instead of the outdated system library)
- oci8 extension now uses the RPM of Oracle Instant Client version 23.5 on x86_64, 19.24 on aarch64
- a lot of extensions are also available, see the PHP extensions RPM status (from PECL and other sources) page
Information:
Base packages (php)

Software Collections (php81 / php82 / php83)

September 26, 2024

Javier Martinez Canillas Using an SPI SSD1306 OLED on Fedora with a Raspberry Pi
In a previous post I explained how to use a Solomon SSD1306 OLED display on Fedora with a Raspberry Pi, but that only covered displays that come with a I2C driving interface.

The SSD1306 display controller also supports a (both 3-wire and 4-wire) SPI interface, and the ssd130x DRM driver has support for it since Linux 5.19.

This blog post explains how to setup Fedora to use a SSD1306 OLED when connected through 4-wire SPI interface.

First you need connect the SSD1306 display to the RPi, there are different ways to do this since one can choose the GPIO to use for some the reset and data/command pins.

But to simplify the configuration, one could use the default GPIO pins that are defined in the ssd1306-spi.dtbo provided by the RPi firmware package.

To do this, connect the SSD1306 display to the RPi as follows:
Then you need to install Fedora, this can be done by downloading an aarch64 Fedora raw image (e.g: Workstation Edition) and executing the following command:
```
sudo arm-image-installer --image $image --target=rpi4 -- \\
media=$device --addconsole --addkey=id_rsa.pub \\
--norootpass --resizefs
```
where $device is the block device for your uSD (e.g: /dev/sda) and image is the file name (e.g: Fedora-Workstation-40-1.14.aarch64.raw.xz) of the downloaded image.

Finally you need to configure the RPi firmware to enable the SPI pins and load the ssd1306-spi Device Tree Blob Overlay (dtbo) to register a SSD1306 SPI device, e.g:
```
sudo cat << EOF >> /boot/efi/config.txt
dtparam=spi=on
dtoverlay=ssd1306-spi,inverted
EOF
```
The ssd1306-spi.dtbo supports many parameters in case your display doesn’t match the defaults. Take a look to the RPi overlays README for more details about all these parameters and their possible values.

The ssd130x DRM driver registers an emulated fbdev device that can be bound with fbcon and use the OLED display to have a framebuffer console. If you want to do that, it’s convenient to change the virtual terminal console font to a smaller one, e.g:
```
sudo sed -i 's/FONT=.*/FONT="drdos8x8"/' /etc/vconsole.conf
sudo dracut -f
```
And that’s it. Happy hacking!
Ismael Olea Charla sobre turismo y la wikicosa

A la sazón del día internacional del turismo, Raul Jimenez Ortega ha organizado un evento Geo Developers en Internet al cual me ha invitado a hablar de lo que hemos aprendido en estos años acerca de la relación de Wikipedia, el patrimonio y el turismo. Espero que os guste.
Jon Chiappetta Yet Another Attempt At Proxying My Entire Network (Poor Man VPN)
It’s been a busy year for me again, trying to focus on my self and my health. Mapping out dietary and seasonal allergies, still on the mission of No Dairy, Eggs, Caffeine, High-Fructose-Gluctose-Corn-Syrup, etc. I am able to breathe better and sleep better which is much needed as I get older.

Anyway, I was still running the experiment of tunneling my entire home traffic (network wide) and all connections through a VPN. I first ran into MTU packet size and fragmentation issues related to the fact that the clients on my network default to a 1500 MTU whereas the VPN tunnel interface drops that size by at least 40-60 bytes worth. This can result in packet fragmentation and performance issues which OpenVPN has support for but WireGuard does not.

I then switched to a proxy setup where I redirect and pipe all connection data at the protocol level to a server-side service which forwards it to the VPN endpoint and then out to the internet. This setup had much better performance but I then ran into some connection issues as the firewall states and the timeouts may not exactly be honoured correctly by the serving application.

I rewrote my Python made framework to start fresh again and go back to basics in a lower level language like C and this seems to be working better at the moment. I will continue to run this and test it out as the final replacement hopefully. The list of features this includes is:
- Transparent Dynamic Forwarding Proxy Service (load balancing capable with ip/nftables)
- Frontend UDP Network Connection ILB Mapping (from individual packets to stateful stream)
- Data Fragmentation + TCP Message Ordering & Delivery
- Simple ciphering and better performance
- C-language Multi-threaded
https://github.com/stoops/vpn/

This is the magic part of the code which sits in front of the proxy service and shares the UDP connection states and pre-routes them to the already established VPN tunnel related for that specific load balanced connection.

September 25, 2024

Adam Young More Personal Ansible
I can do anything. I can’t do everything. –Me

Anything worth doing is worth doing in a way you can check in to git. To recall what I did from the command line, I should turn those actions into a persist-able document. Do I? Not often enough. Often I rely on bash history to remind me of what I did last time. Since the machines I work on are out of a global pool, I have been burned by not recording commands before relinquishing a machine.

For complex series of tasks, it makes sense to execute a bash script to perform those tasks, and I have many of these. Shell scripting excels in doing command line tasks. Where it does not do so well is on tasks that are split over multiple machines. While curl is great for pulling and pushing files to webservers, the majority of my remote work requires ssh and scp to set things up. This is where Ansible comes in: If I can make a playbook that records the commands I use to perform that action, I can repeat it on another machine.

Here is what my workflow looks like as I try to get better at it:
- Fetch machine access data from lab scheduler
- Generate inventory file
- Run Shell Script that specifies usecase specific variables to call…
- an Ansible playbook which does the following
  - ssh key management
  - pass Usecase specific configuration
  - Git clones work repository
  - Runs script
  - Reports result
So the question often comes up: when should something be done as a bash script, and when should it be done via Ansible? My take is that Ansible is neither the first thing nor the last thing that you hit: it is the shipping company in the middle of the move. Lets work backwards.

So, write your script. Check it in to git. Push it to a remote server. Then use Ansible to provision that script on the next machine.

I find that I often have a 1-to-1 relationship between scripts I want to run and an Ansible module that does the calling of that code. I make these into modules so I can then mix and match them in playbooks later. This can be done via a refactoring, effort, so I often start with them in playbooks, and refactor them when I want to reuse the same logic in another playbook.

Peter Czanik 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.

Before you begin

If you are reading this blog, most likely you already have MacPorts installed on your machine. If not, follow the instructions from https://www.macports.org/install.php on how to install MacPorts for your operating system.

Installing syslog-ng 3.38

MacPorts has an old version of syslog-ng already included. It works, but it has some problems, and it also lacks many of the available features of syslog-ng.

Installation is simple:

czanik@Peters-MacBook-Pro ~ % sudo port install syslog-ng     
--->  Computing dependencies for syslog-ng
The following dependencies will be installed:
 bzip2
 expat
 gettext-runtime
 glib2
 json-c
 libedit
 libelf
 libffi
 libiconv
 libnet
 ncurses
 openssl
 openssl3
 pcre
 pcre2
 py312-packaging
 python312
 python3_select
 python3_select-312
 python_select
 python_select-312
 sqlite3
 xz
 zlib
Continue? [Y/n]: y
--->  Fetching archive for json-c
[…]
--->  Attempting to fetch syslog-ng-3.38.1_0.darwin_22.x86_64.tbz2.rmd160 from https://packages.macports.org/syslog-ng
--->  Installing syslog-ng @3.38.1_0
--->  Activating syslog-ng @3.38.1_0
--->  Cleaning syslog-ng
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.
--->  Some of the ports you installed have notes:
  
python312 has the following notes:
    To make this the default Python or Python 3 (i.e., the version run by the 'python' or 'python3' commands), run one or both of:
    
        sudo port select --set python python312
        sudo port select --set python3 python312
  syslog-ng has the following notes:
    To use syslog-ng, first unload OS X's built-in syslog daemon:
    
        sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.syslogd.plist
    
    Then customize /opt/local/etc/syslog-ng.conf,
    and load syslog-ng.

    A startup item has been generated that will aid in starting syslog-ng with launchd. It is disabled by default. Execute the following command to start it, and to cause it to launch at startup:
    
        sudo port load syslog-ng
czanik@Peters-MacBook-Pro ~ %

It works, it is rock solid. However, it is old and misses many of the new and optional features:

root@Peters-MacBook-Pro ~ # /opt/local/sbin/syslog-ng -V
syslog-ng 3 (3.38.1)
Config version: 3.35
Installer-Version: 3.38.1
Revision:
Module-Directory: /opt/local/lib/syslog-ng
Module-Path: /opt/local/lib/syslog-ng
Include-Path: /opt/local/share/syslog-ng/include
Available-Modules: timestamp,kvformat,appmodel,afprog,examples,rate-limit-filter,cef,map-value-pairs,stardate,system-source,confgen,afuser,xml,disk-buffer,tfgetent,linux-kmsg-format,dbparser,json-plugin,add-contextual-data,pseudofile,affile,csvparser,basicfuncs,syslogformat,hook-commands,graphite,tags-parser,afstomp,secure-logging,afsocket,cryptofuncs,azure-auth-header,regexp-parser
Enable-Debug: off
Enable-GProf: off
Enable-Memtrace: off
Enable-IPv6: on
Enable-Spoof-Source: on
Enable-TCP-Wrapper: off
Enable-Linux-Caps: off
Enable-Systemd: off

Installing syslog-ng-devel

The syslog-ng-devel port is built upon a recent syslog-ng git snapshot. As syslog-ng is developed in a way that you should be able to create a stable release anytime, it is not a problem.

In this case, the same command that I used to install syslog-ng 3.38 from a binary package will first install the necessary dependencies from packages, then build syslog-ng locally.

czanik@Peters-MacBook-Pro ~ % sudo port install syslog-ng-devel
--->  Computing dependencies for syslog-ng-devel
The following dependencies will be installed:
 bison
 bison-runtime
 brotli
 cmake
 curl
 curl-ca-bundle
 cyrus-sasl2
 flex
 gettext
 gettext-tools-libs
 gperf
 hiredis
 icu
 ivykis
 kerberos5
 libarchive
 libb2
 libbson
 libcomerr
 libcxx
 libdbi
 libesmtp
 libidn2
 libmaxminddb
 libpsl
 librdkafka
 libtextstyle
 libunistring
 libxml2
 lmdb
 lz4
 lzo2
 m4
 mongo-c-driver
 nghttp2
 paho.mqtt.c
 pkgconfig
 popt
 rabbitmq-c
 snappy
 tcp_wrappers
 zstd
Continue? [Y/n]:
--->  Fetching archive for gperf
[…]
--->  Fetching archive for syslog-ng-devel
--->  Attempting to fetch syslog-ng-devel-2024.09.17_0+osl.darwin_22.x86_64.tbz2 from https://packages.macports.org/syslog-ng-devel
--->  Attempting to fetch syslog-ng-devel-2024.09.17_0+osl.darwin_22.x86_64.tbz2 from https://vie.at.packages.macports.org/syslog-ng-devel
--->  Attempting to fetch syslog-ng-devel-2024.09.17_0+osl.darwin_22.x86_64.tbz2 from https://fra.de.packages.macports.org/syslog-ng-devel
--->  Fetching distfiles for syslog-ng-devel
--->  Verifying checksums for syslog-ng-devel
--->  Extracting syslog-ng-devel
--->  Applying patches to syslog-ng-devel
--->  Configuring syslog-ng-devel
--->  Building syslog-ng-devel
--->  Staging syslog-ng-devel into destroot
--->  Installing syslog-ng-devel @2024.09.17_0+osl
--->  Activating syslog-ng-devel @2024.09.17_0+osl
--->  Cleaning syslog-ng-devel
--->  Updating database of binaries
--->  Scanning binaries for linking errors
--->  No broken files found.
--->  No broken ports found.
--->  Some of the ports you installed have notes:
  cmake has the following notes:
    The CMake GUI and Docs are now provided as subports 'cmake-gui' and 'cmake-docs', respectively.
  libpsl has the following notes:
    libpsl API documentation is provided by the libpsl-docs port.
  syslog-ng-devel has the following notes:
    To use syslog-ng, first unload OS X's built-in syslog daemon:
    
        sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.syslogd.plist
    
    Then customize /opt/local/etc/syslog-ng.conf,
    and
    
        sudo load syslog-ng

    A startup item has been generated that will aid in starting syslog-ng-devel with launchd. It is disabled by default. Execute the following command to start it, and to cause it to launch at startup:
    
        sudo port load syslog-ng-devel
czanik@Peters-MacBook-Pro ~ %

Based on the output my suspicion is that pre-built packages might be available soon.

You might have noticed that installing syslog-ng-devel pulled in a lot of dependencies. The reason is simple: after the fixes received from the MacPorts community and from our developers, a lot more features compile now with older compiler versions and on older operating system versions.

Compared to the old package, these are some the additional modules available:

czanik@Peters-MacBook-Pro ~ % sudo /opt/local/sbin/syslog-ng -V
Password:
syslog-ng 4.8.0.157.gd68f5a5.dirty
Config version: 4.2
Installer-Version: 4.8.0.157.gd68f5a5.dirty
Revision: 4.8.0.157.gd68f5a5.dirty
Module-Directory: /opt/local/lib/syslog-ng
Module-Path: /opt/local/lib/syslog-ng
Include-Path: /opt/local/share/syslog-ng/include
Available-Modules: timestamp,darwinosl,kvformat,redis,afamqp,appmodel,afprog,metrics-probe,cef,map_value_pairs,kafka,stardate,system-source,confgen,afuser,xml,disk-buffer,tfgetent,linux-kmsg-format,cloud_auth,correlation,json-plugin,pseudofile,affile,afsmtp,csvparser,basicfuncs,syslogformat,hook-commands,mqtt,afmongodb,graphite,tags-parser,geoip2-plugin,afstomp,http,secure-logging,afsql,mod-python,afsocket,add_contextual_data,cryptofuncs,azure-auth-header,regexp-parser,rate_limit_filter
Enable-Debug: off
Enable-GProf: off
Enable-Memtrace: off
Enable-IPv6: on
Enable-Spoof-Source: on
Enable-TCP-Wrapper: on
Enable-Linux-Caps: off
Enable-Systemd: off

If you want even more modules, you can use “variants” to enable support for grpc-based modules and a native MacOS source:

czanik@Peters-MacBook-Pro ~ % sudo port variants syslog-ng-devel
syslog-ng-devel has the variants:
   debug: Enable debug binaries
   grpc: Enable GRPC modules
[+]osl: Enable support for OSLog
   universal: Build for multiple architectures
czanik@Peters-MacBook-Pro ~ % sudo port install syslog-ng-devel +grpc
--->  Computing dependencies for syslog-ng-devel
The following dependencies will be installed:
 abseil
 c-ares
 grpc
 lbzip2
 libuv
 protobuf3-cpp
 re2
Continue? [Y/n]:
--->  Fetching archive for abseil
[…]

If you check the modules again, you will see even more available:

czanik@Peters-MacBook-Pro ~ % sudo /opt/local/sbin/syslog-ng -V          
Password:
syslog-ng 4.8.0.157.gd68f5a5.dirty
Config version: 4.2
Installer-Version: 4.8.0.157.gd68f5a5.dirty
Revision: 4.8.0.157.gd68f5a5.dirty
Module-Directory: /opt/local/lib/syslog-ng
Module-Path: /opt/local/lib/syslog-ng
Include-Path: /opt/local/share/syslog-ng/include
Available-Modules: bigquery,timestamp,darwinosl,kvformat,redis,afamqp,appmodel,afprog,loki,metrics-probe,cef,map_value_pairs,otel,kafka,stardate,system-source,confgen,afuser,xml,disk-buffer,tfgetent,linux-kmsg-format,cloud_auth,correlation,json-plugin,pseudofile,affile,afsmtp,csvparser,basicfuncs,syslogformat,hook-commands,mqtt,afmongodb,graphite,tags-parser,geoip2-plugin,afstomp,http,secure-logging,afsql,mod-python,afsocket,add_contextual_data,cryptofuncs,azure-auth-header,regexp-parser,rate_limit_filter
Enable-Debug: off
Enable-GProf: off
Enable-Memtrace: off
Enable-IPv6: on
Enable-Spoof-Source: on
Enable-TCP-Wrapper: on
Enable-Linux-Caps: off
Enable-Systemd: off

What is next?

I would like to thank the involved MacPorts developers and my colleagues for making this huge step forward happen.

I would also like to ask for your feedback. Please share your experience with the syslog-ng-devel portand not only if you run into a problem, but also if it works for you as expected.

Cockpit Project Cockpit 325
Cockpit is the modern Linux admin interface. We release regularly.

Here are the release notes from Cockpit 325 and cockpit-machines 320:

Machines: Improvements to snapshots of running machines

When creating a snapshot of a running machine, Cockpit asks where to store its memory file. This has improved in several ways:
- Only a directory needs to be specified; Cockpit will generate a filename.
- The snapshot dialog remembers the storage path, making future snapshots easier.
- Space estimates are shown, including a warning if there isnâ€™t enough storage available.
Machines: Support for VM descriptions

Cockpit can now show and change the descriptions of virtual machines.

Try it out

Cockpit 325 and cockpit-machines 320 are available now:

September 23, 2024

The NeuroFedora Blog Next Open NeuroFedora meeting: 07 October 1300 UTC
Photo by William White on Unsplash.

Please join us at the next regular Open NeuroFedora team meeting on Monday 07 October at 1300 UTC. The meeting is a public meeting, and open for everyone to attend. You can join us in the Fedora meeting channel on chat.fedoraproject.org (our Matrix instance). Note that you can also access this channel from other Matrix home severs, so you do not have to create a Fedora account just to attend the meeting.

You can use this link to convert the meeting time to your local time. Or, you can also use this command in the terminal:
```
$ date -d 'Monday, October 07, 2024 13:00 UTC'
```
The meeting will be chaired by @ankursinha. The agenda for the meeting is:
- New introductions and roll call.
- Tasks from last meeting.
- Open Pagure tickets.
- Package health check.
- Open package reviews check.
- CompNeuro lab compose status check for Fedora 41/rawhide.
- Neuroscience query of the week
- Next meeting day, and chair.
- Open floor.
We hope to see you there!
The NeuroFedora Blog Next Open NeuroFedora meeting: 23 September 1300 UTC
Photo by William White on Unsplash.

Please join us at the next regular Open NeuroFedora team meeting on Monday 23 September at 1300 UTC. The meeting is a public meeting, and open for everyone to attend. You can join us in the Fedora meeting channel on chat.fedoraproject.org (our Matrix instance). Note that you can also access this channel from other Matrix home severs, so you do not have to create a Fedora account just to attend the meeting.

You can use this link to convert the meeting time to your local time. Or, you can also use this command in the terminal:
```
$ date -d 'Monday, September 23, 2024 13:00 UTC'
```
The meeting will be chaired by @ankursinha. The agenda for the meeting is:
- New introductions and roll call.
- Tasks from last meeting.
- Open Pagure tickets.
- Package health check.
- Open package reviews check.
- CompNeuro lab compose status check for Fedora 41/rawhide.
- Neuroscience query of the week
- Next meeting day, and chair.
- Open floor.
We hope to see you there!
Josh Bressers Episode 447 – The Tidelift 2024 open source maintainer report
Josh and Kurt talk about the 2024 Tidelift maintainer report. The report is pretty big and covers a ton of ground. We focus in a few of the statistics that should worry anyone who uses open source. We’ve known for a while developers are struggling, and the numbers back that up. This one feels like the old “we’ve tried nothing and we’re all out of ideas”.
https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_447_The_Tidelift_2024_open_source_maintainer_report.mp3
Show Notes

September 22, 2024

Josef Strzibny A brief look at the new Kamal Proxy replacing Traefik
Kamal 2 is coming with a brand new custom proxy that’s replacing Traefik. Let’s have a look at why is that and what it means.

Why Kamal needs a proxy

Kamal is a simple deployment tool built around Docker containers. While Docker itself has a Swarm mode allowing for more robust deploys, Kamal keeps things simple by running the containers with straightforward docker run calls. But starting and stopping containers this way comes without their automatic replacement. Kamal needs a way to handle zero-downtime deployment for web containers so it originally incorporated Traefik.

Why Traefik

While there are many HTTP proxies around, Kamal was in the market for something of the auto-discovery of Docker containers. Something could make the proxy configuration management minimal. Traefik is such a proxy – it was specifically built as a dynamic reverse proxy for orchestrating container traffic. This meant that Kamal would only need to label the web containers for Traefik to select them. Docker health checks then did the rest by pointing to the healthy containers that should receive new traffic.

Why a new proxy

There was one problem with Traefik. Kamal had to create a special cord file on the host and bind mount it into the container to be able to control the health check that was responsible for driving traffic alongside the label. By introducing the cord file check Kamal could make any container unhealthy by deleting their associated cord file. And while it mostly worked, it was seen as a hack.

Kamal is an imperative tool and so it needs a proxy that works in a similar way. Traefik was also the most complex and misunderstood part of Kamal’s stack. So while people mostly figure things out in the end, there was an opportunity to simplify it. This is especially true when it comes to the most requested feature for Kamal – hosting multiple apps on the same system with automatic TLS certificates.

Kamal Proxy

The new Kamal proxy is simply called kamal-proxy and it’s designed to make it easy to coordinate zero-downtime deployments with an option of issuing TLS certificates. Instead of labeling containers, we tell the proxy what kind of service to deploy with a hostname:port target:
```
$ kamal-proxy deploy my-app --target web-1:3000
```
This reads as deploy myapp service with web-1 hostname on port 3000. We can reference the container like this thanks to the Docker DNS on the same network. Deploying a service like this will wait for the containers to become healthy and reroute the traffic from any previously deployed instance of the service.

But that’s not all. We can also specify a host to run more services on the same server:
```
$ kamal-proxy deploy first-app --target web-1:3000 --host app1.example.com
$ kamal-proxy deploy second-app --target web-2:3000 --host app2.example.com
```
Providing a host will ensure the ports are not in conflict.

And finally, if we need a certificate for the domain name we pass --tls at the end:
```
$ kamal-proxy deploy first-app --target web-1:3000 --host app1.example.com --tls
```
Note that there is no specific configuration file and the proxy itself has to be running.

Kamal 2 configuration

There will be little need for you to run the proxy commands yourself as it will be done by Kamal. Here’s how it will look in the Kamal deploy/config.yml file:
```
# config/deploy.yml
...
# The new proxy config
proxy:
  ssl: true
  host: app.example.com
```
The new proxy settings have two parts. A required host for routing on the same system and optional ssl for automatic TLS certs.

Kamal Proxy features

To sum up the new proxy feature set:
- Routing based on provided hosts
- Automatic TLS certificates via Let’s Encrypt
- Request and response buffering
- Maximum requests and response sizes
The new proxy should also bring new features to Kamal such as pausing requests, maintenance mode and gradual rollouts.

September 21, 2024

Joe Brockmeier A little aerc configuration tip
I’ve been using aerc for a bit now to test it out as my default mail client. I have to say that I’m truly loving it. Today I was trying to clean up the view so that I wasn’t looking at two dozen old IMAP folders in the folders pane, and remapping a few folder names when I ran into what I thought was a snag but was actually a failure on my part to configure things properly at first.

In the aerc account configuration file (/home/user/.config/aerc/accounts.conf) you can specify what folders you want to see, how they should be sorted, and even remap folder names. For example:
```
folders = INBOX,Sent,Archive,@Fedora Mailing Lists
```
That will tell aerc only to display those folders.
```
folders-sort = Inbox, @Fedora Mailing Lists,Archive, Sent
```
Will sort your displayed folders in that order.
```
folder-map = /home/user/.config/aerc/folders
```
That will tell aerc to look in the “folders” file for a mapping of folders to new names, such as:
```
Fedora = @Fedora Mailing Lists
```
If, for example, you’d once upon a time named a folder thusly so that the @ would put it at the top of webmail sort.

The problem I was running into was that I’d remap a folder name and *poof* it’d disappear when I restarted aerc. Initially I thought I was futzing up the configuration in the folder-map file.

Then it finally (after a bit too long) dawned on me that once I remapped the folder name, aerc took me literally and… didn’t show it because it wasn’t listed as Fedora in the folders or folders-sort directive.

Just throwing that out there in case anybody else bangs their head on the keyboard wondering why remapped folders disappear. Happy mailing!

September 20, 2024

Gary Benson Too many git branches?
Do you have too many git branches on the go at once? Here is the command to list them in order of last modification:
```
git for-each-ref --sort=-committerdate refs/heads
```

September 19, 2024

Tomas Tomecek Generating first set of data for LogDetective using InstructLab

In the last blog (Using InstructLab in Log Detective), we went through the installation and set up process for InstructLab. The post finished with knowledge preparation. We’ll continue with that and hopefully end this one with data generated by InstructLab.
Kevin Fenzi fun with laptops
So, rewind to earlier this year: There were 2 laptop announcements of interest to me.

First was the snapdragon X arm laptops that were going to come out. qualcomm was touting that they would have great linux support and they were already working on merging things upstream. Nothing is ever that rosy, but I did pick up a Lenovo Yoga Slim 7x that I have been playing with. Look for a more detailed review and status on that one in a bit. Short summary is that it’s a pretty cool laptop and mainstream linux support is coming along, but it’s not yet reading to be a daily laptop IMHO.

The second was framework announcing a new batch of laptops would be coming out with some nice upgrades, so I pre-ordered one of the ryzen ones. But reader, you may ask: “don’t you already have a framework ryzen laptop? and aren’t they supposed to be upgradable? So why would you order another one?”. To which I answer: yes, and yes, and… because I wanted so many new things it seemed easier to just order a new one and get a spare/second laptop out of it.

I have one of the very first generation framework 13 laptops. It was originally ordered as a intel 11th gen cpu/mb shipped in July of 2021, almost 3.5 years ago. So whats in the newer/latest version that I wanted?
- Better hinges (the old ones are kinda weak and you can cause the display to ‘flop’ if you carry it by that.
- New top cover. The old one is the old multipart one, the new ones have a one part aluminum one.
- New camera thats supposedly better.
- New battery (ok, I replaced the battery in my old one a while back, but always nice to have a new battery)
- Replacement input cover (the thing with the keyboard/touchpad). After hammering mine for 3.5 years, the tab and/or alt keys stick and result in moving between windows being frustrating. Also, new one has no windows key, just a ‘super’ key.
- Higher resolution / refresh rate display. (120hz and 2880×1920 and matte vs 60hz and 2256×1504 and glossy). In particular the glossy is very anoying in highly reflecting areas.
So, I could have replaced all those things, but at that point it seemed like it would be easier to just move to a new chassis and have a spare.

Of course things didn’t go as planned. The laptop arrived and I swapped my memory and nvme drive over to it and… it didn’t boot. Spend a fair bit of time with framework support back and forth. They wanted movies / pictures of most everything and had me do a bunch of things to isolate the problems. They decided it was a bad monitor/display cable and input cover. So, they shipped those replacements to me (they had to replace the display because the cable is attached to it). Unfortunately, they shipped them USPS, so it took about 9 days and because we don’t get USPS here I had to go rescue it from the local postoffice before they sent it back.Today I swapped in the display and input cover and everything worked like a charm. A quick switch of memory and nvme I am am now booted on the new laptop.

September 18, 2024

Peter Czanik A call for syslog-ng testing

After the last syslog-ng release, we started a campaign to close open issues on GitHub. We'd like to continue this effort and call for collaboration from our users and contributors to make OSE even more stable. While unit tests are great (and we do many tests in-house), nothing can replace using syslog-ng in real-world situations. This blog collects some resources about how you can start testing the latest syslog-ng release from GitHub.

Note that you are also welcome to take part in testing without any previous syslog-ng experience. In that case, my tutorial series can help you get started with syslog-ng: https://peter.czanik.hu/posts/syslog-ng-tutorial-toc/

Before you begin

We provide ready-to-use packages built from the latest git master snapshot for some of the major Linux distributions. Nightly containers are also available. However, most of these instructions assume that you want to test on x86_64 Linux, except for openSUSE packages, which are also available for ARM and Power64LE. Generating the source tarball is also only documented for x86_64 Linux or FreeBSD. If snapshot packages are not available for your operating system, the goal is to be able to build packages for your OS, as working without packages is a pain.

Ready-to-use packages

Each night, we check if there are any changes on syslog-ng git master, and new packages are built for Debian and Ubuntu: https://www.syslog-ng.com/community/b/blog/posts/nightly-syslog-ng-builds-for-debian-and-ubuntu

It is not yet automatic, but I build RPM packages from syslog-ng git master on a weekly basis for openSUSE / SLES and Fedora / RHEL: https://www.syslog-ng.com/community/b/blog/posts/rpm-packages-from-syslog-ng-git-head/

Ready-to-use containers

If you do not use any of the above Linux distributions, and do not mind using containers, then you can still try the latest nightly builds without compiling syslog-ng yourself. These containers are based on the nightly Debian packages, mentioned above: https://www.syslog-ng.com/community/b/blog/posts/nightly-syslog-ng-container-images

Compiling syslog-ng in a container

Syslog-ng has a development/release environment powered by Docker (or Podman). It allows you to generate a source release, and from that, packages for several popular Linux distributions: https://www.syslog-ng.com/community/b/blog/posts/dbld-a-syslog-ng-developer-tool-not-just-for-developers

Creating a source tarball

If none of the above solutions work for you, you should build syslog-ng from the source. Of course you can build syslog-ng from git sources, just check it out from https://github.com/syslog-ng/syslog-ng/ However, most operating systems build syslog-ng from the source tarball generated from Git sources. You just have to slightly modify the files used to build syslog-ng for the given OS (ports for FreeBSD, spec files for RPM distros, etc.).

Building source tarballs by hand is not well-documented, but we have described two possible approaches. The “official” way of building a source tarball is described in a blog I already referred to: https://www.syslog-ng.com/community/b/blog/posts/dbld-a-syslog-ng-developer-tool-not-just-for-developers This is also the method used by syslog-ng developers and all automated processes on GitHub.

If you are on FreeBSD, the process is described at https://www.syslog-ng.com/community/b/blog/posts/compiling-syslog-ng-git-snapshots-on-freebsd This post also describes how to modify the Makefile in ports to compile using the freshly-created release tarball.

Testing

Once you have a package, you are ready for testing. We made many fixes in the past few months, for example in the wildcard-file() source. But even if your problem was not directly addressed after the 4.8.0 release, you should join testing. If you experienced a problem in an earlier version, it might already be fixed as a “side effect” of another fix.

Note that both constructive criticism and positive feedback are very welcome! They help us to close issues at https://github.com/syslog-ng/syslog-ng/issues This is also the place what you can use to report new problems.

Testing the latest Git version helps us to make the next syslog-ng the best syslog-ng release ever. So thank you for your time and contributions in advance!

-

If you have questions or comments related to syslog-ng, do not hesitate to contact us. You can reach us by email or even chat with us. For a list of possibilities, check our GitHub page under the “Community” section at https://github.com/syslog-ng/syslog-ng. On Twitter, I am available as @PCzanik, on Mastodon as @Pczanik@fosstodon.org.

September 17, 2024

Fedora fans نسخه Linux Fedora 41 ‌‌Beta منتشر شد

تیم توسعه پروژه ی فدورا انتشار نسخه Linux Fedora 41 Beta را اعلام کرد. این نسخه مانند همیشه شامل تغییرات و بهبود های هیجان انگیزی می باشد که در ادامه به برخی از مهمترین آنها می پردازیم. نسخه بتای فدورا چیست؟ نسخه‌های بتای فدورا از نظر کد کامل هستند و به شدت شبیه به […]
The post نسخه Linux Fedora 41 ‌‌Beta منتشر شد first appeared on طرفداران فدورا.
Charles-Antoine Couret Venez tester Fedora Linux 41 beta dès maintenant
En ce mardi 17 septembre, la communauté du Projet Fedora sera ravie d'apprendre la disponibilité de la version Beta de Fedora Linux 41.

Malgré les risques concernant la stabilité d’une version Beta, il est important de la tester ! En rapportant les bogues maintenant, vous découvrirez les nouveautés avant tout le monde, tout en améliorant la qualité de Fedora Linux 41 et réduisant du même coup le risque de retard. Les versions en développement manquent de testeurs et de retours pour mener à bien leurs buts.

La version finale est pour le moment fixée pour le 22 octobre ou 5 novembre.

Expérience utilisateur
- Passage à GNOME 47 ;
- L'environnement de bureau léger LXQt passe à la version 2.0 ;
- L'éditeur d'image GIMP utilise la branche de développement qui deviendra la version 3 ;
- Le gestionnaire de listes de tâches Taskwarrior évolue à la version 3 ;
- La mise à jour du cœur des systèmes atomiques de bureau peut se faire sans droits administrateurs, mais pas les mises à niveau de celui-ci à savoir passer d'une version Fedora Linux Silverblue 40 à Fedora Linux Silverblue 41 ;
- Mise à disposition des images Spin KDE Plasma Mobile et Fedora Kinoite Mobile ;
- De même le gestionnaire de fenêtres Miracle exploitant Wayland est proposé dans Fedora et bénéficie de son propre Spin ;
- L'installation de Fedora Workstation se fera avec le protocole d'affichage Wayland uniquement, X11 reste disponible et installable après.
Gestion du matériel
- L'installation du pilote propriétaire de Nvidia via GNOME Logiciels est compatible avec les systèmes utilisant l'option Secure Boot ;
- Prise en charge des caméras MIPI pour les systèmes utilisant Intel IPU6 qui concerne de nombreux ordinateurs portables actuels ;
- L'installateur Anaconda prend en charge le chiffrement matériel des disques via le standard TCG OPAL2, mais cela nécessite de passer via un fichier kickstart pour personnaliser l'installation ;
- Utilisation par défaut de l'outil tuned au lieu de power-profiles-daemon pour la gestion de l'énergie de la machine ;
- Mise à jour de ROCm 6.2 pour améliorer la prise en charge de l'IA et le calcul haute performance pour les cartes graphiques ou accélérateurs d'AMD ;
- L'outil de débogue des tables ACPI nommé acpica-tools ne prend plus en charge les architectures gros boutistes tels que s390x ;
- PHP ne prend plus en charge les processeurs x86 32 bits.
Internationalisation
- Le gestionnaire d'entrées IBus par défaut pour la langue traditionnelle chinoise de Taiwan passe de ibus-libzhuyin à ibus-chewing.
Administration système
- Le gestionnaire de paquet dnf est mis à jour vers sa 5e version ;
- Tandis que la commande rpm utilise la version 4.20 ;
- Les systèmes Fedora atomiques de bureau et Fedora IoT disposent de bootupd pour la mise à jour du chargeur de démarrage ;
- Les images atomiques de Fedora proposent les outils dnf et bootc, ce premier est utilisable dans un contexte de développement pour l'instant mais le second peut commencer à servir à déployer des images du système qui sont bootables ;
- La bibliothèque de sécurité OpenSSL n'accepte plus les signatures cryptographiques avec l'algorithme SHA-1 ;
- Stabilisation de la fonctionnalité de Fedora Linux 36 où ostree prenait en charge les formats OCI/Docker pour le transport et le mécanisme de déploiement des conteneurs ;
- Le gestionnaire de réseaux NetworkManager ne prend plus en charge la configuration dans le format ifcfg qui était déjà désuet depuis des années ;
- Dans la même veine, le paquet network-scripts a été retiré, mettant fin à la gestion du réseau via les scripts ifup et ifdown ;
- Les interfaces réseaux pour les éditions Cloud vont utiliser les nouveaux noms par défaut comme adoptés par les autres éditions il y a des années au lieu de conserver les noms traditionnels tels que eth0 ;
- Le gestionnaire de virtualisation libvirt utilise maintenant par défaut le pare-feu nftables au lieu de iptables pour son interface réseau vibr0 ;
- L'outil Netavark pour gérer la pile réseau des conteneurs, notamment avec podman, utilise également par défaut le pare-feu nftables au lieu de iptables ;
- Les unités système de systemd vont utiliser par défaut beaucoup d'options pour améliorer la sécurité des services ;
- Introduction de l'outil fedora-repoquery pour faire des requêtes sur les dépôts comme savoir la version exacte d'un paquet spécifique dans une autre version de Fedora, la date de mise à jour d'un dépôt, ou connaître les paquets qui dépendent d'un paquet spécifique (dépendance inverse donc), etc. ;
- Le gestionnaire de conteneurs Kubernetes a des nouveaux paquets versionnés, permettant d'avoir plusieurs versions en parallèle. Ici les versions 1.29, 1.30 et 1.31 sont proposées avec des noms comme kubernetes1.31 ;
- L'implémentation des interfaces de Kubernetes fait par l'OCI a ses propres paquets cri-o et cri-tools qui sont également versionnés pour pouvoir suivre les versions de Kubernetes.
Développement
- Mise à jour de la suite de compilation GNU : binutils 2.42, glibc 2.40 et gdb 15 ;
- Mise à niveau de la suite de compilateurs LLVM vers la version 19 ;
- Retrait de Python 2.7 dans les dépôts, seule la branche 3 est maintenue dorénavant ;
- D'ailleurs Python bénéficie de la version 3.13 ;
- Python est aussi compilé avec l'optimisation -O3 activée, en ligne avec la manière de faire par le projet officiel et améliorant les performances ;
- Le framework d'écriture de tests en Python, Pytest se teste avec sa version 8 ;
- Mise à jour du langage Go vers la version 1.23 ;
- Mise à jour dans l'écosystème Haskell GHC 9.6 et Stackage LTS 22 ;
- Le langage Perl passe à la version 5.40 ;
- Node.js 22 devient la version de référence, tandis que la version 20 et 18 restent disponibles en parallèle ;
- Pour des raisons de changement de licence, le gestionnaire de bases de données clé-valeur Redis est remplacé par Valkey ;
- La bibliothèque Python d'apprentissage profond Pytorch est éclairée avec sa version 2.4 ;
- L'API engine de la bibliothèque OpenSSL est désactivée car non maintenue tout en gardant une ABI stable.
Projet Fedora
- L'édition de Fedora KDE pour l'architecture AArch64 est maintenant bloquante pour les sorties d'une nouvelle version. L'édition doit être suffisamment stable pour qu'une nouvelle version de Fedora Linux voit le jour ;
- Ultime phase 4 de l'usage généralisé des noms abrégés de licence provenant du projet SPDX pour la licence des paquets plutôt que des noms du projet Fedora ;
- Les bibliothèques Java n'ont plus une dépendance explicite envers le runtime de Java pour simplifier la maintenance, rien ne change concernant les applications ;
- Le paquet systemtap-sdt-devel n'a plus l'outil dtrace qui a été mis dans le paquet systemtap-sdt-dtrace ;
- Ajout d'une tâche de nettoyage lors de la génération des paquets RPM pour améliorer la reproductibilité des paquets ;
- Changement dans les métadonnées des dépôts de Fedora, avec l'usage de l'algorithme de compression zstd et l'abandon des bases de données sqlite pour diminuer la taille des données à télécharger ou à stocker.
Tester

Durant le développement d'une nouvelle version de Fedora Linux, comme cette version Beta, quasiment chaque semaine le projet propose des journées de tests. Le but est de tester pendant une journée une fonctionnalité précise comme le noyau, Fedora Silverblue, la mise à niveau, GNOME, l’internationalisation, etc. L'équipe d'assurance qualité élabore et propose une série de tests en général simples à exécuter. Suffit de les suivre et indiquer si le résultat est celui attendu. Dans le cas contraire, un rapport de bogue devra être ouvert pour permettre l'élaboration d'un correctif.

C'est très simple à suivre et requiert souvent peu de temps (15 minutes à une heure maximum) si vous avez une Beta exploitable sous la main.

Les tests à effectuer et les rapports sont à faire via la page suivante. J'annonce régulièrement sur mon blog quand une journée de tests est planifiée.

Si l'aventure vous intéresse, les images sont disponibles par Torrent ou via le site officiel.

Si vous avez déjà Fedora Linux 40 ou 39 sur votre machine, vous pouvez faire une mise à niveau vers la Beta. Cela consiste en une grosse mise à jour, vos applications et données sont préservées.

Nous vous recommandons dans les deux cas de procéder à une sauvegarde de vos données au préalable.

En cas de bogue, n'oubliez pas de relire la documentation pour signaler les anomalies sur le BugZilla ou de contribuer à la traduction sur Weblate. N'oubliez pas de consulter les bogues déjà connus pour Fedora 41.

Bons tests à tous !

September 16, 2024

Adam Young Standard Deviation

Music and Lyrics by Adam Young,
Copyright 2019
All Rights Reserved

When we Introduce
in to our search for truth
data gathered from the world outside
We’re tempted to reject
measures as defects
specimens that don’t seem to comply.
Just an observation
with a variation
not due to a flaw in the machine
Slightly Greater than one Standard Deviation from the mean

When conditions change
to exceed a range
our assumptions can betray our trust
the carriage made of steel
of your automobile
add oxygen and it will turn to rust
take what starts as fuel
and change some molecules
enough so its no longer gasoline
Slightly greater than one Standard Deviation from the mean

When we are pressed
To show our methods rational
We must confess
we’re either lucky or we fail
it’s all for show
when we precisely calculate
we think we know
but really we approximate

When you discern as mild
what others find quite wild
responding to the pressure to perform
For you to stimulate
you must deviate
beyond the threshold of accepted norms
what is your diversion
another calls perversion
on a scale from kinky to obscene
Slightly greater than one Standard Deviation from the mean
Josh Bressers Episode 446 – Researchers took over .MOBI TLD
Josh and Kurt talk about some security researchers sort of taking over the .MOBI whois server. The story is a bit sensational, but we ask if it really matters? There are a lot of interesting possible attacks, but turning something like this into a good attack is really hard, maybe impossible. The researchers presented the findings in a very reasonable way.
https://traffic.libsyn.com/opensourcesecuritypodcast/Episode_446_Researchers_took_over_MOBI_TLD.mp3
Show Notes
- We Spent $20 To Achieve RCE And Accidentally Became The Admins Of .MOBI
- Heinz says sorry for ketchup QR code that links to porn site

September 14, 2024

Kevin Fenzi Infrastructure happenings, second half of aug – first half of sept 2024

So, I was going to try and do these posts more regularly, but of course thats hard to do. After flock there was a bunch of things I wanted to post, then a bunch of fires and so things got behind. Such is life, so here’s a few things I wanted to talk about in more detail from the last month or so. As always, I do still post on mastodon daily, happy to answer questions or comments there as things happen and expand on things in posts like this.

Fedora 41 branched off rawhide! This I think went much more smoothly than the last cycle. I like to hope it’s because we documented all the things that were not right last time and did them this time. There were a few more things to adjust, it wasn’t perfect, but it was much better!

We upgraded our OpenShift cluters from 4.15 to 4.16. I continue to be very happy how smooth OpenShift upgrades are. Not 100% seamless, but pretty good. This time we had some storage stuff that caused the upgrade to not finish, but it wasn’t too hard to work around. So much nicer than the old 3.x days.

We landed a bunch of koji/kiwi changes before Beta freeze. Kudos to Neal Gompa and Adam Williamson for working through all those. It was nice to mostly get everything lined up before Freeze so we didn’t have to be doing a lot of churn. We got everything working in rawhide first, then merged the f41 changes.

Had a really anoying IPA outage. I was running our main playbook (runs over everything) on a thursday night, just to make sure everything was in sync for the freeze, and… our playbook thought all our ipa servers were not configured right and tried to uninstall and resync them all. Luckily the server that was the CA master refused to uninstall, so we were still up on one server. From that we were able to reinstall/resync the other 2 and get things back up and working. I am still not sure why the playbook saw no dirserv running on the servers (and thus thought they were unconfigured). We are going to adjust that playbook to definitely not try and do that, and instead move setting up a replica to a manual playbook only run by humans as needed.

Thanks to a bunch of work from Stephen Gallagher and Carl George, eln and epel10 are now doing composes just like we do for rawhide and branched. This should allow us to retire our old ODCS (on demand compose service) setup, as its not really maintained upstream anymore and is on EOL os versions. Great to get things all running the same way, but of course we will probibly change everything next year or something.

We managed to sign off on Fedora 41 Beta being released next week. I was pretty amazed, as it didn’t seem like we had enough time to really shake out all the bugs, but testing coverage ended up being pretty good. Looking forward to Beta next week and end of Beta freeze.

September 13, 2024

Daniel Pocock Houston Energy & Climate Week 2024

The inaugural Houston Energy & Climate Week was held from 9 to 13 September 2024.

The schedule included a wide range of events about energy and climate issues on both a local and global scale.

Australian American Chamber of Commerce (AACC) Texas

On the afternoon of Tuesday, 10 September, the Australian American Chamber of Commerce (AACC) Texas ran a panel discussion involving businesses and entrepreneurs with Australian connections.

Many people commented that it was well organized and fun and one of the highlights of the week.

Energy Tech Nexus Founder After Party

For those who survived the Australians and a full day of activities for the opening of Energy Tech Nexus in Texas, there was an after party in the penthouse of the Esperson building.

Foxy Moxy cocktails

The fun continued into the following evening with a cocktail reception at the Houston Moxy hotel. Sustainable beverages were available for people to try.

Smiling Oak sustainable whiskey is produced locally in Texas and seeks to reuse barrels and other materials in the production process.

The Moxy team provided a wide range of food and drinks.

Telmont wines provided champagne from France.

Katie Mehnert (ALLY Energy) gave a speech thanking the volunteers, sponsors and partners who participated in the cocktail event.
Frank Ch. Eigler meanwhile

Meanwhile Joe and Joanne Engineer piddles along building this or that insignificant thing, here goes SpaceX building not just something brilliant, but using it for something beautiful and glorious.

Makes one wants to become a better man.
Remi Collet PHP version 8.2.24RC1 and 8.3.12RC1
Release Candidate versions are available in the testing repository for Fedora and Enterprise Linux (RHEL / CentOS / Alma / Rocky and other clones) to allow more people to test them. They are available as Software Collections, for a parallel installation, the perfect solution for such tests, and also as base packages.

RPMs of PHP version 8.3.12RC1 are available
- as base packages in the remi-modular-test for Fedora 39-41 and Enterprise Linux ≥ 8
- as SCL in remi-test repository
RPMs of PHP version 8.2.24RC1 are available
- as base packages in the remi-modular-test for Fedora 39-41 and Enterprise Linux ≥ 8
- as SCL in remi-test repository
The packages are available for x86_64 and aarch64.

PHP version 8.1 is now in security mode only, so no more RC will be released.

Installation: follow the wizard instructions.

Announcements:
- PHP 8.3.12RC1 available for testing
- PHP 8.2.24RC1 available for testing
Parallel installation of version 8.3 as Software Collection:
```
yum --enablerepo=remi-test install php83
```
Parallel installation of version 8.2 as Software Collection:
```
yum --enablerepo=remi-test install php82
```
Update of system version 8.3:
```
dnf module switch-to php:remi-8.3
dnf --enablerepo=remi-modular-test update php\*
```
Update of system version 8.2:
```
dnf module switch-to php:remi-8.2
dnf --enablerepo=remi-modular-test update php\*
```
Notice:
- version 8.3.11RC1 is also in Fedora rawhide for QA
- version 8.4.0beta5 is also available in the repository
- EL-9 packages are built using RHEL-9.4
- EL-8 packages are built using RHEL-8.10
- oci8 extension uses the RPM of the Oracle Instant Client version 23.5 on x86_64 or 19.24 on aarch64
- intl extension uses libicu 74.2
- RC version is usually the same as the final version (no change accepted after RC, exception for security fix).
- versions 8.2.24 and 8.3.12 are planed for September 26th, in 2 weeks.
Software Collections (php82, php83)

Base packages (php)

September 11, 2024

Peter Czanik The syslog-ng Insider 2024-09: documentation; TRANSPORT macro; rolling RPMs
Dear syslog-ng users,

This is the 123rd issue of syslog-ng Insider, a monthly newsletter that brings you syslog-ng-related news.

NEWS

You can also contribute to the syslog-ng OSE documentation

The up-to-date syslog-ng Administration Guide received a new look and easier navigation, as well as better search experience. Best of all, you can now also easily contribute to the syslog-ng documentation.

https://www.syslog-ng.com/community/b/blog/posts/you-can-also-contribute-to-the-syslog-ng-ose-documentation

The $TRANSPORT macro of syslog-ng

Do you want to know how your log messages arrived to syslog-ng? The new $TRANSPORT macro provides you with part of the answer. It shows you the protocol variant for network sources, or the kind of local source used.

https://www.syslog-ng.com/community/b/blog/posts/the-transport-macro-of-syslog-ng

Rolling RPM platforms added to the syslog-ng package build system

Syslog-ng uses a container-based system to generate the official source tgz and to build ready-to-use packages for various Linux distributions. Recently, we added support for some rolling RPM Linux distributions, allowing us to spot breaking changes before a stable release of the OS would become available.

https://www.syslog-ng.com/community/b/blog/posts/rolling-rpm-platforms-added-to-the-syslog-ng-package-build-system

WEBINARS
- You can browse recordings of past webinars at https://www.syslog-ng.com/events/
Your feedback and news, or tips about the next issue are welcome. To read this newsletter online, visit: https://syslog-ng.com/blog/

September 10, 2024

Josef Strzibny Avoiding environment conflicts with Kamal and Dotenv
We often use Dotenv in Rails for managing environment variables in development. But both Kamal and Dotenv works with .env files by default. Let’s see how to solve this conflict.

Environment conflicts

We often rely on an .env file in development when using Dotenv. This is a direct opposite for Kamal that also loads the same .env file, but for deployment. As an example we might rely on RAILS_MASTER_KEY in an .env file which will differ from development and production. To figure out the right action to take we have to understand what these tools do with the env files in the first place.

Dotenv environments

Dotenv loads several env files by default by their priority. This depends on the environment:
```
# for development
.env.development.local
.env.local
.env.development
.env

# for test
.env.test.local
.env.test
.env

# for production
.env.production.local
.env.local
.env.production
.env
```
An .env.development will have a higher priority and will be loaded before .env. But Dotenv doesn’t just blindly load these files. It skips the values it already finds, so .env file won’t override the other files that came before it.

Kamal environments

Kamal works with the .env file by default but also supports other environments called destinations. Destinations are essentially all production environments, but might still require different variables.

Destinations have their own config and env file. A production could have an associated config/deploy.production.yml config file and .env.production environment file.

Kamal merges this environment file with .env together to produce the final set of variables for a destination.

Solution

A simple fix is providing .env.development file for development while keeping the common .env file. Then optionally also introduce a Kamal’s production target so .env will always contain only safe values.

But it’s not ideal. As long as .env is used for production by Kamal it’s easy to make a mistake by including a production value and misusing it in development.

Instead I advice to completely separate these tools environments.

First we make sure to load Dotenv only in development and test:
```
# Gemfile
gem "dotenv", groups: [:development, :test]
```
And then we remove the .env file from Dotenv default files:
```
# config/application.rb

require_relative "boot"

require "rails/all"

# Require the gems listed in Gemfile, including any gems
# you've limited to :test, :development, or :production.
Bundler.require(*Rails.groups)

Dotenv::Rails.files.delete(".env")
...
```
Dotenv will load .env.development for shared development values and .env.test for shared test values ignoring .env alltogether.

This also means we don’t have to change anything on the Kamal side. We can optinally introduce a production destination, but we are not forced to.

September 09, 2024

William Brown Yubikey Key Vulnerability - How It Affects You
On the 3rd of September, Yubico announced YSA-2024-03, a vulnerability in the infineon cryptograhpic library which may allow private key extraction to be performed. As is tradition, arm chair experts and thought leaders everywhere rushed to have hot takes on the situation, without adequately understanding the way that the attack works and how it fits into Webauthn on a technical level.

TL;DR - Do I Need To Worry

No. This attack while cool as heck, is not a risk to the majority of yubikey users.

But I write opensource code, I'm a target of NSA/ASIO/MI5/Obsidian Order surveillence

No you aren't, keep using your yubikeys.

The Attack

Let's examine yubicos statement about the attack.

An attacker could exploit this issue as part of a sophisticated and targeted attack to recover affected private keys. The attacker would need physical possession of the YubiKey, Security Key, or YubiHSM, knowledge of the accounts they want to target, and specialized equipment to perform the necessary attack. Depending on the use case, the attacker may also require additional knowledge including username, PIN, account password, or authentication key. See Affected Use Cases and Mitigations for more details.

Wow, that's pretty scary. Private keys can be recovered from our secure key hardware! The attacker only needs possession! Think of the evil maid's getting excited to perform this attack right now!

This statement sadly on the part of Yubico is vague to the details of how the attack is carried out and this affects people's ability to perform adequate risk assessment.

The details are buried in the eucleak paper, but the attacker requires:
- The private key must be ECDSA (the default for Webauthn/FIDO2)
- Physical access to the yubikey
- Knowledge of the users PIN
- The ability to disassemble the key
- Specialised equipment to recover the keys
From this, there are four key defences that you still have:
- Your PIN
Without knowing your PIN, the keys can not be recovered. The recovery can only be performed during a signature operation using the key which requires your PIN for each operation.

The authors of the eucleak paper note this:

When this is possible activate all defense layers, e.g. enforce the use of a PIN (or any biometrics) to access to the device.

Provided that the websites you have used your key with enforce user verification (aka a PIN) then the key would be impossible te recover without this. Yubikeys natively have PIN bruteforce protections to prevent and limit the ability of at attacker to attempt to steal your PIN, even with possession.
- The Attack Is Destructive
To carry out the attack, the yubikey needs to be taken apart or drilled open. It's extremely obvious when someone carries this out, and only a highly resourced, motivated, and skilled attacker could consider repairing the key in such a way to mask the subterfuge.
- The Attack Requires Possession
The attacker needs physical access to the key for approximately one hour to carry out the attack, and that is excluding the possible time to repair the damaged key case post attack.
- The Attack Targets ECDSA Keys - Not the Master Key
Every website that you enroll your yubikey to as a device has a unique private key associated to it. While this attack can retrieve the private key, this only allows the attacker to recover one private key at a time, which requires the key to be a resident key, or the attacker needs the CredentialID associated to this yubikey to proceed. Each CredentialID is protected by a device master key and so extraction of one private key only compromises the one target site - not every credential the key has ever issued.

In addition of the attacker is targetting a website that may be behind a VPN, they may not be able to capture the CredentialID in the place to allow the attack to proceed. In some cases the CredentialID may be behind a pre-auth (such as a password auth) step which also prevents the attacker accessing the CredentialID needed for the private key attack to begin at all.

Threat Model - Consumer Device

So now knowing this what is the risk to the average consumer?

Given the need for your PIN, physical access, and the attack being destructive, it's unlikely that anyone will carry out this attack without a high value target and reason.

Another way to frame this, is that there are very few persons in the world who would be worth the expenditure in resources to conduct a targetted against in this manner. And if the attacker is already in possession of the device and your PIN, in most cases the need to execute this attack aren't required since the attacker can simply sign in to your account and then steal the session cookies or whatever else.

Finally, the authors of the paper even state:

Let us emphasize here that we strongly encourage to continue to use an EUCLEAK vulnerable product rather than switching to a solution that does not involve a secure element.

Side Quest - Attestation

As a refresher, lets talk about what attestation is.

When you enroll a security key to a website, that website has no knowledge about your key. In fact all that website sees (in simple versions) is a public key and some boolean flags describing true/false if you touched the device during the signature, and if you entered a PIN or biometric when you used the device.

Yes, that's right, when you enter your PIN to your security key, that stays local on the key and all the remote website sees is a "promise, I actually did check the PIN, you can trust me".

This means someone could easily just make a software key that sends the user-presence and user-verification flags, even if they didn't actually validate them or enforce presence or verification (looking at you password managers).

In most cases though this isn't a problem - the use of cryptographic authentication for the user is a significant improvement over the use of passwords and/or other factors. If a user chooses to do a silly and make a fake-cereal-box key, that's on them to accept the finding out of their fucking around.

But in other places, we can not afford to find out. There may be regulations or rules that enforce policies that must be adhered to for a number of reasons.

For this reason we need a way to signal to the website not just that we have "a security key" but that we have a precise make and model of key, that conforms to a set of guaranteed properties. To achieve this, security keys support a process called attestation which provides a cryptographic proof that the key is a specific make and model.

This allows a website to trust a certificate authority (such as the Yubico CA) and when the key is enrolled it uses it's attestation key to sign the public key as we enroll our key to the website. The website can then trace the trust chain back cryptographically to the Yubico CA and have a strong proof that the key being enrolled must be a legitimate yubikey.

THreat Model - Attestation

So now with our eucleak attack, this does have an impact on sites that enforce attestation. This is because a yubikeys attestation key can now be extracted from a legitimate device that is in the attackers possession. Using the extracted attestation key, we can now sign any key as though it came from a real yubikey. Your password manager could cosplay cryptographically as a yubikey for example.

This has implications on sites that do require strict attestation as it is now possible that someone may attempt to enroll "I can't believe it's not a yubikey" to an account, bypassing the expected security controls.

There are still limited use cases for this, but the primary would be enrolling an attacker controlled exportable key to an account, while retaining the appearance of it being a legitimate yubikey.

NOTE: This does not affect PIV/SmartCard attestation by default since smartcard attestation in yubikeys uses an RSA attestation key instead of an ECDSA one. If you have enrolled your own attestation key that uses ECDSA then this can be extracted, but again falls into the categories above regarding the need for possession and destruction of the key.

Conclusion

While this attack is novel and super technically cool in a spy thriller move heist kind of way, for most yubikey users there is minimal risk to your keys.

The risks that do exist are to organisations with high security assurance needs which rely on attestation, as the trust in attestation provided by the device may now come into question in some circumstances.

September 08, 2024

Guillaume Kulakowski Nextcloud prometheus textfile exporter

Cela fait un petit moment que j’utilise Prometheus et Grafana pour mon NAS. Mais Fedora-Fr ainsi que ce blog tournaient encore sous une stack TIC (Telegraf, InfluxDB, Chronograf). C’est chose à présent corrigée. Bien qu’il existe déjà des exporter pour Nextcloud, je n’avais pas la volonté d’installer un nouveau service pour aller récupérer des logs […]

Cet article Nextcloud prometheus textfile exporter est apparu en premier sur Guillaume Kulakowski's blog.
farhaan SSL: How It Works and Why It Matters
This content is originally posted on https://journal.farhaan.me/ssl-how-it-works-and-why-it-matters

How did it start?

I have been curious about what an SSL Certificate is and how it works. This is a newbie’s log on the path to understanding a thing or two about how it works.

We casually talk about security and how SSL certificates should be used to make your website more secure. In this blog, I am documenting my learnings, and the end goal for me here is to see if I can enable an SSL certificate (sshh… it’s called a TLS Certificate since SSL is long deprecated) on a server locally. Why?

This end goal will help me with a few problems that I face day to day and help me dive deeper to understand the magic.

The Need …

Why do we need an SSL certificate and what does it certify? The obvious answer found all over the internet is that obtaining an SSL certificate guarantees that any connection made to the website is secure.

Okay! But how?

This is the most interesting part. A superficial answer is that a website or application with an SSL certificate means that any data transfer between the client and server will happen over HTTPS (HTTP over SSL/TLS), so the data will be encrypted, making the transfer more secure.

This explanation raises more questions.

Where is the encryption happening? How is the encryption happening? Is encryption the sole reason we are using HTTPS?

How is this working?

To investigate the working I started banking on what I know with my experience with SSL certificates. I have used Let’s Encrypt to obtain and use SSL certificates hence I started working backwards.

An SSL certificate also shows the public that you are who you say you are. To achieve this, we need a Certificate Authority (CA) that has verified the entity and is publicly trusted.

When we install certbot and try to obtain a certificate it:
1. Generate a private key.
2. Generate a public key.
3. Generate a CSR(Certificate Signing Request) and send the CSR to the Certificate Authority(CA).
On receiving the CSR the CA will verify the user, domain etc. and if all goes well it will issue a certificate to the user/domain.

Now, let’s try to understand what exactly a certificate is.

A certificate is a file or document that contains the issuer’s information, the issuer’s public key, and a signature.

The signature is a crucial part of the document because it is used by entities to verify the authenticity of the certificate.

A signature is the checksum of the certificate, calculated using the provided algorithm and then encrypted by the issuer’s private key.

Note: For messages, the public key is used to encrypt and the private key is used to decrypt. For signatures, it works the opposite way.

Now that we have obtained a certificate, our CA authenticates the connection by checking the signature.

The question that puzzled me was: how does my machine trust any of these connections, and will there be a lot of back-and-forth to establish a single HTTPS connection?

This brought me to an understanding that each operating system and browser does ship a bunch of public keys for Root Certificate Authority. The Root CA certifies the intermediate CA’s like Let’s Encrypt and there is a chain of trust that gets verified on each connection.

Hence, the chain of trust is followed and then Root CA Signature gets verified using the public key that is shipped with the Operating System or browser. On Ubuntu, the certificates can be found in /etc/ssl/certs.

Now, that we have an understanding of how security is promised(Not guaranteed) on an HTTPS connection, we can reverse-engineer a few concepts to generate a certificate and force OS/browser to support the certificate.

Generating a Local (Self Signed) Certificate

Various resources will help you generate a self-signed certificate, the ones that I can vouch for are this GitHub gist and the article from Lets Encrypt.

First, we need to generate Root Certificate, Root Primary key and Public Key.
```
openssl req -x509 -nodes -new -sha256 -days 1024 -newkey rsa:2048 -keyout RootCA.key -out RootCA.pem -subj "/C=US/CN=Farhaan-Root-CA"
```
After this you should have 3 files in your directory:

Now we need to have an ext file which has all information about the domain I want the certificate for i.e SAN information:
```
authorityKeyIdentifier=keyid,issuer
basicConstraints=CA:FALSE
keyUsage = digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
subjectAltName = @alt_names
[alt_names]
DNS.1 = localhost
DNS.2 = farhaan.local
DNS.3 = farhaan.bukhsh.local
```
I created a file called farhaan.ext to achieve the same.

Now I need to file a CSR for the domain and generate the private-public key and then sign it with a Root CA.
```
openssl req -new -nodes -newkey rsa:2048 -keyout localhost.key -out localhost.csr -subj "/C=IN/ST=YourState/L=YourCity/O=Example-Certificates/CN=farhaan.local"
```
The above command will give me a private key for the localhost and a Certificate Signing Request file which we can use to generate an SSL Certificate.

and then we run
```
openssl x509 -req -sha256 -days 1024 -in localhost.csr -CA RootCA.pem -CAkey RootCA.key -CAcreateserial -extfile farhaan.ext -out localhost.crt
```
This gives us the localhost.crt file which is the SSL certificate.

Let’s Serve

You can see I am serving the local file on a HTTPS connection. There are a few things that needs to be done, I had a simple python 3 server written and borrowed from here.
```
from http.server import HTTPServer, SimpleHTTPRequestHandler
import ssl
from pathlib import Path

port = 4443

httpd = HTTPServer(("localhost", port), SimpleHTTPRequestHandler)
ssl_context = ssl.SSLContext(ssl.PROTOCOL_TLS_SERVER)
ssl_context.load_cert_chain(Path(__file__).parent / "server.pem")
httpd.socket = ssl_context.wrap_socket(
    httpd.socket,
    server_side=True,
)

print(f"Serving on https://localhost:{port}")
httpd.serve_forever()
```
after that I need to modify my /etc/hosts file on Ubuntu to support farhaan.local .

This is so that farhaan.local redirects to localhost and done. After this we need to make sure Firefox recognizes this so we need to go under `about:preferences` > Privacy & Security > Certificates > View Certificate > import. Here import the RootCA.crt. Now we can visit https://farhaan.local:4443.

We can see that this is an HTTPS connection.

Here is the certificate:

Conclusion

I got to learn about a bunch of things about SSL, Security, etc. while writing this blog. Let me know if you have any clarification or any improvements. Thanks for reading and happy hacking!

This is an independent, censorship-resistant site run by volunteers. This site and the blogs of individual volunteers are not officially affiliated with or endorsed by the Fedora Project.

We Make Fedora

October 14, 2024

Show Notes

October 13, 2024

Fedora Linux 41

Fedora Linux 42

Hot Topics

October 12, 2024

Changes since Kiwi TCMS 13.5

Security

Improvements

Settings

Bug fixes

Refactoring and testing

Kiwi TCMS Enterprise v13.6-mt

Private container images

How to upgrade

October 11, 2024

Infrastructure & Release Engineering

Fedora Infra

CentOS Infra including CentOS CI

Release Engineering

List of new releases of apps maintained by CPE

October 10, 2024

NEWS

Version 4.8.0 of syslog-ng improves FreeBSD and MacOS support

Why it is useful to set the version number in the syslog-ng configuration

We are switching syslog-ng containers from Debian Testing to Stable

WEBINARS

October 09, 2024

October 08, 2024

cockpit/ws container: Connect to any Linux server

cockpit/ws container: Support host-specific SSH keys

Bridge supports PCP; cockpit-pcp package is now obsolete

Storage: Manage Stratis virtual filesystem sizes

Podman: pull images from registries without search API

Files: basic keyboard shortcuts

Try it out

October 07, 2024

Show Notes

The Kamal way

Kamal Proxy

Multiple apps

Debugging

October 06, 2024

fsync-kernel

hhd

Install all the things

Executing steam in gamescope

Further tweaks

Autologin your desktop session

Autostart gamescope

Intro Video

Enjoy!

October 04, 2024

Partial Input Stream:

Composite Input Stream

QCoro 0.11.0 Release Announcement

QCoro::LazyTask<T>

Defined Semantics for Awaiting Default-Constructed and Moved-From Tasks

Compiler Support

Other Features and Changes

Bugfixes

Full changelog

Support

October 03, 2024

Before you begin

Configuring syslog-ng

Bugs and limitations

Testing

What is next?

October 02, 2024

October 01, 2024

The Conference

The Booth

The Experience Overall

Overall Thoughts

September 30, 2024

Fedora Linux 41 Development

Fedora Linux 42 Development

`QCoro::LazyTask<T>`