Tag: Fedora Project community

Posted on by — Leave a comment

From ifcfg to keyfiles: modernizing NetworkManager configuration in Fedora Linux 36

One of the changes in Fedora Linux 36 is that new installations will no longer support the ifcfg files to configure networking. What are those and what replaces them?

A bit of history

In the good old days, connecting a Linux box to a network was easy. For each of the interface cards connected to a network, the system administrator would drop a configuration file into the /etc directory. That configuration file would describe the addressing configuration for a particular network. On Fedora Linux, the configuration file would actually be a shell script snippet like this:

$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
TYPE=Ethernet
DEVICE=eth0
BOOTPROTO=dhcp

A shell script executed on startup would read the file and apply the configuration. Simple.

Towards the end of 2004, however, a change was in the air. Quite literally — the Wi-Fi has become ubiquitous. The portable computers of the day could rapidly connect to new networks and the USB bus allowed even the wired network adapters to come and go while the system was up and running. The network configuration became more dynamic than ever before, rendering the existing network configuration tooling impractical. To the rescue came NetworkManager. On a Fedora Linux system, NetworkManager uses configuration like this:

$ cat /etc/sysconfig/network-scripts/ifcfg-eth0
TYPE=Ethernet
DEVICE=eth0
BOOTPROTO=dhcp

Looks familiar? It should. From the beginning, NetworkManager was intended to work with the existing configuration formats. In fact, it ended up with plugins which would seamlessly convert between NetworkManager’s internal configuration model and the distribution’s native format. On Fedora, it would be the aforementioned ifcfg files.

Let’s take a closer look at them.

Ifcfg files

The legacy network service, now part of the network-scripts package, originally defined the ifcfg file format. Along with the package comes a file called sysconfig.txt that, quite helpfully, documents the format.

As NetworkManager gained traction it often found itself in need of expressing a configuration that was not supported by the old fashioned network service. Given the nature of configuring things with shell scripts, adding new settings is no big deal. The unknown ones are generally just silently ignored. The NetworkManager’s idea of what ifcfg files should look like is described in the nm-settings-ifcfg-rh(5) manual.

In general, NetworkManager tries hard to write ifcfg files that work well with the legacy network service. Nevertheless, sometimes it is just not possible. These days, the number of network connection types that NetworkManager supports vastly outnumber what the legacy network service can configure. . A new format is now used to express what the legacy format can not. This includes VPN connections, broadband modems and more.

Keyfiles

The new format closely resembled the NetworkManager’s native configuration model:

$ cat /etc/NetworkManager/system-connections/VPN.ovpn
[connection]
id=My VPN
uuid=c85a7cdb-973b-491f-998d-b09a590af10e
type=vpn [vpn]
ca=/etc/pki/tls/certs/vpn-ca.pem
connection-type=password
remote=vpn.example.com
username=lkundrak
service-type=org.freedesktop.NetworkManager.openvpn [ipv6]
method=auto
never-default=true

The actual format should be instantly familiar to everyone familiar with Linux systems. It’s the “ini file” or “keyfile” — a bunch of plain text key-value pairs, much like the ifcfg files use, grouped into sections. The nm-settings-ifcfg-keyfile(5) manual documents the format thoroughly.

The main advantage of using this format is that it closely resembles NetworkManager’s idea of how to express network configuration, used both internally and on the D-Bus API. It’s easier to extend without taking into consideration the quirks of the mechanism that was designed in without the benefit of foresight back when the world was young. This means less code, less surprises and less bugs.

In fact there’s nothing the keyfile format can’t express that ifcfg files can. It can express the simple wired connections just as well as the VPNs or modems.

Migrating to keyfiles

The legacy network service served us well for many years, but its days are now long over. Fedora Linux dropped it many releases ago and without it there is seemingly little reason to use the ifcfg files. That is, for new configurations. While Fedora Linux still supports the ifcfg files, it has defaulted to writing keyfiles for quite some time.

Starting with Fedora Linux 36, the ifcfg support will no longer be present in new installations. If you’re still using ifcfg files, do not worry — the existing systems will keep it on upgrades. Nevertheless, you can still decide to uninstall it and carry your configuration over to keyfiles. Keep on reading to learn how.

If you’re like me, you installed your system years ago and you have a mixture of keyfiles and ifcfg files. Here’s how can you check:

$ nmcli -f TYPE,FILENAME,NAME conn
TYPE FILENAME NAME
ethernet /etc/sysconfig/network-scripts/ifcfg-eth0 eth0
wifi /etc/sysconfig/network-scripts/ifcfg-Guest Guest
wifi /etc/NetworkManager/system-connections/Base48 Base48
vpn /etc/NetworkManager/system-connections/VPN.ovpn My VPN

This example shows a VPN connection that must have always used a keyfile and a Wi-Fi connection presumably created after Fedora Linux switched to writing keyfiles by default. There’s also an Ethernet connection and Wi-Fi one from back in the day that use the ifcfg plugin. Let’s see how we can convert those to keyfiles.

The NetworkManager’s command line utility, nmcli(1), acquired a new connection migrate command, that can change the configuration backend used by a connection profile.

It’s a good idea to make a backup of /etc/sysconfig/network-scripts/ifcfg-* files, in case anything goes wrong. Once you have the backup you can try migrating a single connection to a different configuration backend (keyfile by default):

$ nmcli connection migrate eth0
Connection 'eth0' (336aba93-1cd7-4cf4-8e90-e2009db3d4d0) successfully migrated.

Did it work?

$ nmcli -f TYPE,FILENAME,NAME conn
TYPE FILENAME NAME
ethernet /etc/NetworkManager/system-connections/eth0.nmc eth0
wifi /etc/sysconfig/network-scripts/ifcfg-Guest Guest
wifi /etc/NetworkManager/system-connections/Base48 Base48
vpn /etc/NetworkManager/system-connections/VPN.ovpn My VPN

Cool. Can I migrate it back, for no good reason?

$ nmcli conn migrate --plugin ifcfg-rh eth0
Connection 'eth0' (336aba93-1cd7-4cf4-8e90-e2009db3d4d0) successfully migrated.

Excellent. Without specifying more options, the “connection migrate” command ensures all connections use the keyfile backend:

$ nmcli conn migrate
Connection '336aba93-1cd7-4cf4-8e90-e2009db3d4d0' (eth0) successfully migrated.
Connection '3802a9bc-6ca5-4a17-9d0b-346f7212f2d3' (Red Hat Guest) successfully migrated.
Connection 'a082d5a0-5e29-4c67-8b6b-09af1b8d55a0' (Base48) successfully migrated.
Connection 'c85a7cdb-973b-491f-998d-b09a590af10e' (Oh My VPN) successfully migrated.

And that’s all. Now that your system has no ifcfg files, the configuration backend that supports them is of no use and you can remove it:

# dnf remove NetworkManager-initscripts-ifcfg-rh
…

Your system now works the same as it did before, but you can rejoice, for it is now modern.

Posted on by — Leave a comment

Updating Edge Devices with OSTree and Pulp

Connecting industrial machinery to the internet has given birth to infinite opportunities that range from performance improvements and predictive maintenance to data modelling that can lead to novel solutions and use cases. The possibilities are endless. Connecting machinery on such a scale can test the limits of cloud connectivity, depending on your location and network limitations.

An edge device is any piece of hardware that sits at the boundary between two networks. When initial computation happens on servers at the edge, it speeds up user’s interactions with the cloud. Therefore, adding edge devices provides opportunities to optimize performance, shorten the journey, and lighten the load on your cloud connection.

As amazing as it sounds, managing all of this functionality demands continuous attention from administrators. Having a reliable solution to distribute, deploy, and update systems for edge devices from the outset will help you spend time on things that matter.

In this article, we look at how OSTree is well-positioned for upgrading and updating edge devices with versioned updates of Linux-based operating systems. Furthermore, we’ll explore how Pulp facilitates managing and preparing updates of the OSTree content, as well as making it available to edge devices. Together, they provide a powerful free and open-source solution for administering edge devices.

How does OSTree help manage Edge devices?

If you need to deploy hundreds of operating systems to edge devices, safe in the knowledge that you can easily manage future updates and maintenance, an OSTree’s immutable and image-based operating system is ready for the task.

OSTree functions like git, but for operating system binaries. It has git-like content-addressed repositories. The ability to commit and branch entire root filesystem trees resembles the way you submit changes in git. With OSTree, you build an operating system with pre-installed packages, known as an operating system image. After you build the operating system image, it is possible to track it, sign it, test it, and deploy it. These images function as immutable file system trees. When the time comes to change or update, you simply build a new image and deploy it. By atomically switching between different versions of images, you are completely replacing filesystem trees.

OSTree also has a simple CLI that you can use for managing simple workflows, for example, for switching between different versions of images/filesystem trees.

Where do Fedora-IoT Images feature?

As a standalone tool, the base OSTree CLI is not the most feature-rich utility for managing repository content. To make life easier, in the following demo, we will use rpm-ostree. rpm-ostree is a hybrid image/package system that combines the standard OSTree technology as a base image format and accepts RPM on both the client and server-side.

rpm-ostree integrates with Fedora IoT. In comparison to other ecosystems, instead of installing packages via DNF, you install packages with rpm-ostree. After rebooting all changes are applied to a new version of the image.

You can also upgrade or install a new Fedora IoT image with the rpm-ostree utility.

Where and how does Pulp come into this?

Pulp is a platform that handles content management workflows. Using Pulp, you can sync packages from remote repositories such as an RPM server, PyPI, Docker Hub, Ansible Galaxy, and many more. You can host and modify synced packages in repositories inside the Pulp server. You can publish repositories that contain packages available for deployment to production environments.

In our scenario, Pulp provides a platform for storing particular versions of OSTree content, promoting approved content through the content management lifecycle, for example from dev to test, and from test to prod. Pulp also provides a method for publishing content that is consumed by edge devices. Using Pulp, you can pull the latest packages, test, and publish only when safe to do so. Pulp ensures the safety, security, and repeatability of your content supply chain.

The following diagram provides a simplified overview of Pulp. On the left are shown different content types that are mirrored into Pulp from remote sources. These repositories are then served, for instance, to different CI/CD or production environments.

A simplified overview of Pulp. The content is mirrored from remote repositories and made available to different types of environments.

Pulp creates a new repository version automatically when updating or removing packages in a repository. You can distribute each repository version independently.

Pulp has a plugin-based architecture, which means that you must add a plugin for each content type you want to use. For managing OSTree content, you need the OSTree plugin. You can then mirror content from a remote repository, import content from a local tarball, and modify content within a Pulp repository while preserving the integrity of the original content. You can move commits and refs from one repository to another or delete them. Pulp ensures that you are safe to experiment while your production environment remains pinned to a particular version.

Putting it all together

In this section, let’s look at how to build an image with an OSTree commit.

Building a Customized Fedora-IoT Image

We start by booting a new virtual machine (VM) that will have an installed Fedora-IoT OS. For the purposes of this example, it is best to have the same version of the OS installed as the running edge devices have.

All commands in this section are executed on the main admin VM (Fedora IoT 35 OS). On this admin VM, we will build the images that we will then distribute to the edge devices.

Before you begin:

  • First, ensure that the VM is accessible via SSH. To test, enter the following command from within the target OS:
$ systemctl is-active sshd
  • Next, ensure that the following tools for composing operating system images are installed: 
$ sudo rpm-ostree install osbuild-composer composer-cli
$ sudo systemctl enable --now osbuild-composer.socket
  • Now, apply the installed packages by rebooting the system.

In this example a nano editor package is installed on all edge devices. We need to build an image containing a commit with the package.

Create a blueprint file that describes what changes you want to make to the image as shown here:

$ cat install-nano.toml name = "nano-commit"
description = "Installing nano"
version = "0.0.1" [[packages]]
name = "nano"
version = "*"

Push this blueprint to the os build composer utility, which is a tool for composing operating system images. composer-cli communicates with osbuild composer through the CLI:

$ composer-cli blueprints push install-nano.toml

Build a new image:

$ composer-cli compose start-ostree nano-commit fedora-iot-commit --ref fedora/stable/x86_64/iot

The composer will use resources available in your current OS (such as a default operating system version).

Regularly check the status of the build:

$ composer-cli compose status

When the build finishes, download the image:

$ composer-cli compose image ${IMAGE_UUID}

The downloaded image is basically an OSTree repository packed into a tarball. When you extract the archived content, you will notice that one ref is referencing the checksum of a commit. You can find it inside the refs/heads/ directory.

Publishing the Customized Image with Pulp

All commands shown in this section are executed on the main admin VM (Fedora IoT 35 OS).

Before you begin:

  • Ensure that you have installed Pulp and the Pulp CLI for managing OSTree repositories:
$ python3 -m venv venv && source venv/bin/activate
$ pip install pulp-cli-ostree
  • Then configure the reference to the Pulp server:
$ pulp config create && pulp status

Now configure a proxy server or SSH port forwarding to enable network communication between the VM and Pulp. Ensure that you can ping the Pulp server from the VM.

First, create a new OSTree repository:

$ pulp ostree repository create --name fedora-iot

The following command will import the tarball created in the previous section into Pulp:

$ pulp ostree repository import-commits --name fedora-iot --file ${IMAGE_TARBALL_C1} --repository_name repo

Publish the parsed commit as a remote OSTree repository hosted by Pulp:

$ pulp ostree distribution create --name fedora-iot --base-path fedora-iot --repository fedora-iot

Try to fetch the commit checksum from the ref:

$ curl http://${PULP_BASE_ADDR}/pulp/content/pulp-fedora-iot/refs/heads/fedora/stable/x86_64/iot

Distributing the Customized Image to an Edge Device

The Edge device can be another VM or a real device running Fedora IoT.

All commands shown in this section are executed on an Edge device (Fedora IoT 35 OS).

Before you begin:

  • Configure a proxy server or SSH port forwarding to enable network communication between an Edge device and Pulp. Ensure that you can ping the Pulp server from the Edge device. 
  • Ensure that the Edge device is accessible with SSH:
$ systemctl is-active sshd

The nano package should NOT come pre-installed with the official bare Fedora IoT 35 image. Verify that by attempting to run nano inside your terminal.

In Fedora IoT, updates are retrieved from the URL defined in /etc/ostree/remotes.d/fedora-iot.conf. This file can be modified manually or by adding a new remote repository. Learn more at Adding and Removing Remote Repositories.

You can automate the upgrade procedure with an upgrade policy that will be configured at the beginning of deployment. This is done by writing a kickstart file that will boot up an edge device into a headless state. However, for demonstrative purposes, let’s act like a villain and update the aforementioned configuration file manually to have the following content:

[remote "fedora-iot"]
url=http://${PULP_BASE_ADDR}/pulp/content/pulp-fedora-iot/refs/heads/fedora/stable/x86_64/iot
gpg-verify=false
ref=fedora/stable/x86_64/iot

Do not forget to replace the variable ${PULP_BASE_ADDR} with a valid base path to the pulp server.

The following command shows you that some packages are going to be installed:

$ rpm-ostree upgrade

Reboot the edge device:

$ systemctl reboot

…rebooting…

Log in to the edge VM via ssh, and check the presence of the nano package that comes from Pulp:

$ nano

Done! You have successfully distributed a customized Fedora IoT image via Pulp!

In case of any questions, do not hesitate to reach out to us at https://pulpproject.org/help.

Posted on by — Leave a comment

3-2-1 Backup plan with Fedora ARM server

Fedora Server Edition works on Single Board Computers (SBC) like Raspberry Pi. This article is aimed at data backup and restoration of personal data for users who want to take advantage of solid server systems and built-in tools like Cockpit. It describes 3 levels of backup.

Pre-requisites

To use this guide, all you need is a working Fedora Linux workstation and the following items.

  • You should read, understand, and practice the requirements as documented in the Fedora Docs for server installation and administration
  • An SBC (Single Board Computer), tested for Fedora Linux. Check hardware status here.
  • Fedora ARM server raw image & ARM image installer
  • A choice of microSD Card (64 GB / Class 10) and SSD device
  • Ethernet cable / DHCP reserved IP or static IP
  • A Linux client workstation with ssh keys prepared
  • Make a choice of cloud storage services
  • Have an additional Linux workstation available

With this setup, I opted for Raspberry Pi 3B+/4B+ (one for hot-swap) because of the price and availability at the time of writing this article. While the Pi server is remotely connected using Cockpit, you can position the Pi near the router for a neat set-up.

Harden server security

After following through with server installation and administration on the SBC, it is a good practice to harden the server security with firewalld.

You must configure the firewall as soon as the server is online before connecting the storage device to the server. Firewalld is a zone-based firewall. It creates one pre-defined zone ‘FedoraServer’ after following through with the installation and administration guide in the Fedora Docs.

Rich rules in firewalld

Rich rules are used to block or allow a particular IP address or address range. The following rule accepts SSH connections only from the host with the registered IP (of client workstation) and drops other connections. Run the commands in Cockpit Terminal or terminal in client workstation connect to the server via ssh.

firewall-cmd --add-rich-rule='rule family=ipv4 source address=<registered_ip_address>/24 service name=ssh log prefix="SSH Logs" level="notice" accept'

Reject ping requests from all hosts

Use this command to set the icmp reject and disallow ping requests

firewall-cmd --add-rich-rule='rule protocol value=icmp reject'

To carry out additional firewall controls, such as managing ports and zones, please refer to the link below. Please be aware that misconfiguring the firewall may make it vulnerable to security breaches.

Managing firewall in Cockpit
firewalld rules

Configure storage for file server

The next step is to connect a storage device to the SBC and partition a newly attached storage device using Cockpit. With Cockpit’s graphical server management interface, managing a home lab (whether a single server or several servers) is much simpler than before. Fedora Linux server offers Cockpit as standard.

In this setup, an SSD device, powered by the USB port of the SBC, is placed in service without the need for an additional power supply.

  • Connect the storage device to a USB port of the SBC
  • After Cockpit is running (as set up in the pre-requisites), visit ip-address-of-machine:9090 in the web browser of your client workstation
  • After logging into Cockpit, click ‘Turn on administrative access’ at the top of the Cockpit page
  • Click the “Storage” on the left pane
  • Select the device under “Drives” section to format and partition a blank storage device
Cockpit Storage management
  • On the screen of the selected storage device create a new partition table or format and create new partitions. When prompted to initialize disk, in the “Partitioning” type, select GPT partition
  • For a file system type from the drop-down list (XFS and ext4), choose ext4. This is suitable for an SBC with limited I/O capability (like USB 2.0 port) and limited bandwidth (less than 200MB/s)
Create a partition in Cockpit
  • To create a single partition taking up all the storage space on the device, specify its mount point, such as “/media” and click “Ok”
  • Click “Create partition”, which creates a new partition mounted at “/media”.

Create backups and restore from backups

Backups are rarely one-size-fits-all. There are a few choices to make such as where the data is backed up, the steps you take to backup data, identify any automation, and determine how to restore backed-up data.

Backup workflow – version 1.0

Backup 1. rsync from client to file server (Raspberry Pi)

The command used for this transfer was:

rsync -azP ~/source syncuser@host1:/destination
Options:
-a, --archive
-z, --compress
-P, --progress

To run rsync with additional options, set the following flags:

Update destination files in-place

--inplace

Append data onto shorter files

--append

Source-side deduplication combined with compression is the most effective way to reduce the size of data to be backed up before it goes to backup storage.

I run this manually at the end of the day. Automation scripts are advantageous once I settled in with the cloud backup workflow.

For details on rsync, please visit the Fedora magazine article here.

Backup 2. rsync from file server to primary cloud storage

Factors to consider when selecting cloud storage are;

  • Cost: Upload, storage, and download fee
  • rsync, sftp supported
  • Data redundancy (RAID 10 or data center redundancy plan in place)
  • Snapshots

One of the cloud storage fitting these criteria is Hetzner’s hosted Nextcloud – Storage Box. You are not tied to a supplier and are free to switch without an exit penalty.

Generate SSH keys and create authorized key files in the file server

Use ssh-keygen to generate a new pair of SSH keys for the file server and cloud storage.

ssh-keygen Generating public/private rsa key pair.
Enter file in which to save the key . . .

Insert the required public SSH keys into a new local authorized_keys file.

cat .ssh/id_rsa.pub >> storagebox_authorized_keys

Transfer keys to cloud storage

The next step is to upload the generated authorized_keys file to the Storage Box. To do this, create the directory .ssh with permission 700 and create the file authorized_keys with the public SSH keys and permission 600. Run the following command.

echo -e "mkdir .ssh \n chmod 700 .ssh \n put storagebox_authorized_keys .ssh/authorized_keys \n chmod 600 .ssh/authorized_keys" | sftp <username>@<username>.your-storagebox.de

Use rsync over ssh

Use rsync to synchronize the current state of your file directories to Storage Box.

rsync --progress -e 'ssh -p23' --recursive <local_directory> <username>@<username>.your-storagebox.de:<target_directory>

This process is called a push operation because it “pushes” a directory from the local system to a remote system.

Restore a directory from cloud storage

To restore a directory from the Storage Box, swap the directories:

rsync --progress -e 'ssh -p23' --recursive <username>@<username>.your-storagebox.de:<remote_directory> <local_directory>

Backup 3. Client backup to secondary cloud storage

Deja Dup is in the Fedora software repo, making it a quick backup solution for Fedora Workstation. It handles the GPG encryption, scheduling, and file inclusion (which directories to back up).

Backing up to the secondary cloud
Restoring files from cloud storage

Archive personal data

Not every data needs a 3-2-1 backup strategy. That is personal data share. I repurposed a hand-me-down laptop with a 1TB HDD as an archive of personal data (family photos).

Go to “Sharing” in settings (in my case, the GNOME file manager) and toggle the slider to enable sharing.

Turn on “file sharing”, “Networks” and “Required password”, which allows you to share your public folders with other workstations on your local network using WebDAV.

Prepare fallback options

Untested backups are no better than no backups at all. I take the ‘hot swap’ approach in a home lab environment where disruptions like frequent power outages or liquid damages do happen. However, my recommendations are far from disaster recovery plans or automatic failover in corporate IT.

  • Dry run restoration of files on a regular basis
  • Backup ssh/GPG keys onto an external storage device
  • Copy a raw image of the Fedora ARM server onto an SD card
  • Keep snapshots of full backups at primary cloud storage
  • Automate backup process to minimize human error or oversight

Track activity and troubleshoot with Cockpit

As your project grows, so does the number of servers you manage. Activity and alert tracking in Cockpit ease your administrative burden. You can achieve this in three ways using Cockpit’s graphical interface.

SELinux menu

How to diagnose network issues, find logs and troubleshoot in Cockpit

  • Go to SELinux to check logs
  • Check “solution details”
  • Select “Apply this solution” when necessary
  • View automation script and run it if necessary
SELinux logs

Network or storage logs

Server logs track detailed metrics that correlate CPU load, memory usage, network activity, and storage performance with the system’s journal. Logs are organized under the network or storage dashboard.

Storage logs in Cockpit

Software updates

Cockpit helps security updates on preset time and frequency. You can run all updates when you need them.

Software updates

Congratulations on setting up a file/backup server with the Fedora ARM server edition.

Posted on by — Leave a comment

Contribute at the Fedora Kernel 5.17, CoreOS, Cloud, IoT, and Audio test days

Fedora Linux test days are events where anyone can help make sure changes in Fedora work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed to Fedora before, this is a perfect way to get started.

There are six upcoming test events in the next two weeks.

  • Sunday April 03 through April 10, is to test the Kernel 5.17 changes in Fedora.
  • Monday April 04 through April 11, this test week is focusing on testing Fedora CoreOS.
  • Wednesday April 06 , is to test the Fedora IoT Edition.
  • Friday April 08, is to test Fedora 36 Cloud Base Images.
  • Wednesday April 13, is to test Audio.
  • Thursday April 14, is to test Upgrade Path from Fedora 34 and 35 to Fedora 36.

Come and test with us to make the upcoming Fedora 36 even better. Read more below on how to do it.

Kernel test week

The kernel team is working on the final integration for kernel 5.17. This version was just recently released and will arrive soon in Fedora.

The Fedora kernel and QA teams have organized a test week for Sunday April 03 through April 10. Refer to the wiki page for links to the test images you’ll need to participate. This document clearly outlines the steps.

Fedora CoreOS test week

The Fedora CoreOS team released the first Fedora CoreOS next stream based on Fedora 36. They expect to promote this to the testing stream in two weeks, on the usual schedule.

The Fedora CoreOS and QA teams have organized a test week. It begins Monday, April 04 and runs through the end of the week. Refer to the wiki page for links to the test cases and materials you’ll need to participate.

Fedora IoT Edition test day

Fedora Internet of Things is a variant of Fedora focused on IoT ecosystems. Whether you work on a home assistant, industrial gateways, or data storage and analytics, Fedora IoT provides a trusted open source platform to build on. Fedora IoT produces a monthly rolling release to help you keep your ecosystem up-to-date.

The IoT and QA teams will have their test day on Wednesday, April 06. Refer to the wiki page for links and resources to test the IoT Edition.

Fedora Cloud test day

Now that the Fedora Linux 36 is coming close to the release date, the Fedora Cloud SIG would like to get the community together to find and squash some bugs.

The test day is organized for Friday April 08. This event will test Fedora Cloud Base content. See the wiki page for links to the Beta Cloud Base Images. We have qcow, AMI, and ISO images ready for testing.

Audio test day

As part of a recent proposal, Fedora replaced the PulseAudio daemon with a functionally compatible implementation based on PipeWire. This means that all existing clients using the PulseAudio client library will continue to work as before, as well as applications shipped as Flatpak. The last few releases noted significant issues in the community and hence the origin of this regression test day.

See this wiki page for information on testing that everything works as expected. This will occur on Wednesday, April 13.

Upgrade test day

As we come closer to Fedora Linux 36 release dates, it’s time to test upgrades. This release has a lot of changes and it becomes essential that we test the graphical upgrade methods as well as the command line methods.

As a part of this test day, we will test upgrading from a full updated F35 and F34 to F36 for all architectures (x86_64, ARM, aarch64) and variants (WS, cloud, server, silverblue, IoT). See this wiki page for information and details. This test day will happen on Thursday, April 14.

Posted on by — Leave a comment

Using Sourcegraph to Search 34,000+ Fedora Repositories

In October 2021, a Fedora Linux user asked a question about licensing. Fedora Project Leader Matthew Miller left a response: “Since we don’t have a complete, exploded, searchable repository of all of the packages in Fedora, I don’t have a quick way to check.” 

Followed by: “…or possibly pay Sourcegraph to do it for us. They seem like nice people.” He is correct, we (Sourcegraph) are nice people, but we don’t want your money. Instead, we wanted to team up with the Fedora community.

The Fedora Community can now search their universe of open source code—currently over 34,000 repositories and counting.

Introduction to code search

For those who aren’t familiar with the concept of code search, it enables teams to onboard to a new codebase and find answers faster, helps to identify security risks, and many other use cases. Sourcegraph has indexed over two-million repositories across multiple code hosts such as GitHub and GitLab. This article is going to focus strictly on code search for src.fedoraproject.org. Sourcegraph provides both a web app and CLI interface.

Using the Web app

When using the Sourcegraph web app you will need to start each search with repo:^src.fedoraprojects.org before entering any search queries. Using this link to the web app will include this initial string as shown here:

Sourcegraph web app interface

The following sections will provide some web app examples of searches that might be of interest.

Find repositories using popular OSI-approved licenses 

The following query will scan all the repositories for software that is compatible with the “Open Source Definition” (OSD).

repo:^src.fedoraproject.org/ lang:"RPM Spec" License: ^.*apache|bsd|gpl|lgpl|mit|mpl|cddl|epl.*$
License search
Try it!

Find files with TODOs

The following query can find TODOs in 34k repositories. This is great for those looking to contribute to projects that need help.

repo:^src.fedoraproject.org/ "TODO"
Search for TODO
Try it!

Find files being served via FTP

A co-worker of mine from back in the day told me “FTP is a dead protocol”. Is it? You can add to this query to find any other protocol such as irc, https, etc.

repo:^src.fedoraproject.org/ (?:ftp)://[A-Za-z0-9-]{0,63}(.[A-Za-z0-9-]{0,63})+(:d{1,4})?/*(/*[A-Za-z0-9-._]+/*)*(?.*)?(#.*)?
Search for protocol
Try it!

Find files with a vulnerable version of Log4j

This query will find any files that are possibly vulnerable (false positives can happen) to CVE-2021-44228 aka Log4j. You can also search for other vulnerabilities that can then be reported to project maintainers.

repo:^src.fedoraproject.org/ org.apache.logging.log4j 2.((0|1|2|3|4|5|6|7|8|9|10|11|12|13|14|15)(.[0-9]+)) count:all
Search for log4j
Try it!

Use the CLI

Sourcegraph also has a command-line interface tool called src, which allows you to do everything I just mentioned above, plus other useful commands like getting results in JSON for programmatic consumption.

src search -json 'repo:^src.fedoraproject.org/ lang:"RPM Spec" License: ^.*apache|bsd|g
pl|lgpl|mit|mpl|cddl|epl.*$'

JSON output

JSON output
Try it!

Search Syntax

The examples shown may be a good starting point but are by no means the only queries that may be made. You can view all search query syntaxes and create your own as needed.

Conclusion

As you can see, with Sourcegraph, the Fedora Linux community can now quickly search for all code hosted at src.fedoraproject.org, regardless of whether they are literal or complex regex queries.

I appreciate the Fedora Linux community being so helpful and welcoming. If you have anything you want to add or questions, my team and I will be in the comments section below. You can also join us on Slack.

Special thanks to Vanesa Ortiz for making this collaboration happen, Ben Venker for his help fixing my broken regex (multiple times), as well as Rebecca Dodd and Nick Moore for their help with editing.

Posted on by — Leave a comment

Contribute at the Fedora i18n and GNOME 42 test weeks

There are two upcoming test weeks in the coming weeks. The first is Monday 28 February through Monday 07 March. It is to test GNOME 42. The second is Monday 07 March through Sunday 13 March. It focuses on testing internationalization. Come and test with us to make the upcoming Fedora 36 even better. Read more below on how to do it.

GNOME test week

GNOME is the default desktop environment for Fedora Workstation and thus for many Fedora users. As a part of the planned change the GNOME megaupdate will land on Fedora which then will be shipped with Fedora 36. To ensure that everything works fine The Workstation Working Group and QA team will have this test week Monday 28 February through Monday 07 March. Refer to the GNOME test week wiki page for links and resources.

i18n test week

i18n test week focuses on testing internationalization features in Fedora Linux. The test week is March 07 through March 13.

How do test days work?

A test day is an event where anyone can help make sure changes in Fedora work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed before, this is a perfect way to get started.

To contribute, you only need to be able to download test materials (which include some large files) and then read and follow directions step by step.

Detailed information about both test days are on the wiki pages above. If you’re available on or around the days of the events, please do some testing and report your results.

Fedora test days are events where anyone can help make sure changes in Fedora work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. If you’ve never contributed to Fedora before, this is a perfect way to get started.

Again, The two upcoming test days in the upcoming week are:

  • Monday 28 February through Monday 07 March, to test GNOME 42.
  • Monday 07 March through Sunday 13 March, focusing on testing internationalization.

Come and test with us to make the upcoming Fedora 36 even better.

Posted on by — Leave a comment

Upgraded Fedora shirts

We’ve upgraded the Fedora shirt and sweatshirt collection we announced in March 2020.

A blue Fedora polo shirt. T-shirts ans sweatshirts are available too.

What’s new?

  • We do the embroidery with the new Fedora logo, but the old logo is still available as Fedora Classic.
  • A Fedora hoodie, and crewneck sweatshirt and a long-sleeve t-shirt. The last two are seasonal, only for February.
  • Faster shipping to the US, Canada and the UK. (We ship from Hungary, Europe.)

OK, but is it made with Linux?

A lot of questions come about as to how exactly do we make the embroidery. Do we use Windows for that? There is a short explanation on our website, but let’s give some more details.

You might have read here at Fedora Magazine that there is a good, fully free (as in freedom) solution to making embroidery designs with Inkscape and Inkstitch. This is the future for us too, and sooner or later we will make all of our embroidery with them. But — mainly because Inkstitch is quite new, and we have been embroidering Linux shirts for a decade — we are still using a manufacturer-independent, but “non-free” program, called Embird. We run it with Wine under Debian. This one is the only proprietary piece of software used here. And it must go, soon…

The Fedora embroidery design in Embird, under Linux.

The other software we use is quite standard for Linux: Inkscape, GIMP, ImageMagick, and of course all of the everyday tools you are using on your Fedora Linux desktop and server.

Check out the embroidered Fedora collection here! Don’t forget to use the FEDORA5 coupon code, for the $5 discount on every shirt and sweatshirt.

Posted on by — Leave a comment

Comparison of Fedora Flatpaks and Flathub remotes

In the previous article in this series, we looked at how to get started with Fedora Flatpaks and how to use it. This article compares and contrasts between the Fedora Flatpaks remote and the Flathub remote. Flathub is the de-facto standard Flatpak remote, whereas Fedora Flatpaks is the Fedora Project’s Flatpak remote. The things that differ between the remotes include but are not limited to their policies, their ways of distribution, and their implementation.

Goals and motivation

Fedora Flatpaks and Flathub share the same goals but differ in motivation. The goal is to make applications accessible in their respective field, maximize convenience and minimize maintenance.

Fedora Flatpaks’s motivation is to push RPMs that come directly from the Fedora Project and make them accessible throughout Fedora Linux regardless of the versions, spin, etc. So, in theory, it would be possible to get the latest and greatest applications from the Fedora Project without needing to upgrade to the latest version of Fedora Linux. Of course, it’s always advisable to keep everything up-to-date.

Flathub’s motivation is to simply make applications and tools as accessible as possible regardless of the distribution in use. Hence, all tools are available on GitHub. Filing issues for applications provided by Flathub is the same as filing issues on any project on GitHub.

Packages

Fedora Flatpaks and Flathub create Flatpak applications differently. First and foremost, Fedora Flatpaks literally converts existing RPMs to Flatpak-compatible files where developers can then easily bundle as Flatpak and redistribute them. Flathub, on the other hand, is more open when it comes to how developers bundle applications.

Types of packages published

Fedora Flatpaks only publishes free and open source software, whereas Flathub publishes free and open source software as well as proprietary software. However, Flathub plans to separate proprietary applications from free and open source applications, as stated by a recent blog post from GNOME.

Sources

Flathub is open with what source a Flatpak application (re)uses, whereas Fedora Flatpaks strictly reuses the RPM format.

As such, Flathub has tons of applications that reuse other package formats. For example, the Chrome Flatpak reuses the .deb package, the UnityHub Flatpak reuses the AppImage, the Spotify Flatpak reuses the Snap package, the Android Studio Flatpak uses a tar.gz archive, etc.

Alternatively, Flathub also compiles directly from source. Sometimes from a source archive, from running git clone, etc.

Number of applications

Fedora Flatpaks has fewer applications than Flathub. To list the applications available from a remote, run flatpak remote-ls --app $REMOTE. You can go one step further and get the number of applications by piping to wc -l:

[Terminal ~]$ flatpak remote-ls --app fedora | wc -l
86
[Terminal ~]$ flatpak remote-ls --app flathub | wc -l
1518

Here, at the time of writing this article, we can see that Flathub has 1518 applications available, whereas Fedora Flatpaks has only 86.

OSTree and OCI formats

Implementations are quite different too. Both Fedora Flatpaks and Flathub use Flatpak to help you install, remove, and manage applications. However, in terms of how these applications are published, they fundamentally work differently. Flathub uses the OSTree format to publish applications, whereas Fedora Flatpaks uses the OCI format.

OSTree format

OSTree (or libostree) is a tool to keep track of system binaries. Developers consider OSTree as “Git for binaries” because it is conceptually analogous to git. The OSTree format is the default format for Flatpak, which Flathub uses to publish packages and updates.

When downloading an application, OSTree checks the differences between the installed application (if installed) and the updated application, and intelligently downloads and changes the differences while keeping everything else unchanged, which reduces bandwith. We call this process delta updates.

OCI format

Open Container Initiative (OCI) is an initiative by several organizations to standardize certain elements of containers. Fedora Flatpaks uses the OCI format to publish applications.

This format is similar to how Docker works, which makes it fairly easy to understand for developers who are already familiar with Docker. Furthermore, the OCI format allows the Fedora Project to extend the Fedora Registry, the Fedora Project’s Docker registry, by creating Flatpak applications as Docker images and publishing them to a Docker registry.

This avoids the burden and complications of having to use additional tools to maintain an additional infrastructure just to maintain a Flatpak remote. Instead, the Fedora Project simply reuses the Fedora Registry, to make maintenance much easier and manageable.

Runtimes

Flatpak runtimes are core dependencies where applications reuse these dependencies without duplicating data, also known as “deduplication”. Runtimes may be based on top of other runtimes, or built independently.

Flathub decentralizes these runtimes, meaning runtimes are only available for specific types of applications. For example GTK applications use the GNOME runtime (org.gnome.Platform), Qt applications use the KDE runtime (org.kde.Platform), almost everything else uses the freedesktop.org runtime (org.freedesktop.Platform). The respective organizations maintain these runtimes, and publish them on Flathub. Both the GNOME and KDE runtimes are built on top of the freedesktop.org runtime.

Fedora Flatpaks, on the other hand, uses one runtime for everything, regardless the size of the application. This means, installing one application from Fedora Flatpaks will download and install the whole Fedora runtime (org.fedoraproject.Platform).

Conclusion

In conclusion, we can see that there are several philosophical and technical differences between Fedora Flatpaks and Flathub.

Fedora Flatpaks focuses on fully taking advantage of the existing infrastructure by providing more to an average user without using more resources. In contrast, Flathub strives to make distributing/publishing applications and using them as painless as possible for the developers and for users.

Both remotes are quite impressive with how rapid they improved in very little time. We hope both remotes get better and better, and become the standard across the majority of desktop Linux distributions.

Posted on by — Leave a comment

FedoraShareYourScreen week (F35)

The Fedora Project, through the Marketing team, is happy to announce the first FedoraShareYourScreen week!

We know that even though the stock look of Fedora Linux is awesome, most people love to tweak and adapt their systems to their own workflow. We want to see how your Fedora Linux desktop looks.

FedoraShareYourScreen week

  • Share your screen with us! Take a screenshot of your desktop and share it. Use the hashtag #FedoraShareYourScreen and mention @fedora on Twitter or @thefedoraproject on Instagram. For Mastodon, just use the hashtag. Avoid showing personal and private info.
  • If you use a full Desktop Environment, just a Window Manager, or just the command line, we want to see how it looks! Share your favorite apps, configs, plugins, widgets and everything on your desktop (including your favorite wallpapers if they are SFW 😉).
  • At the end of the week we will be publishing a slide show on YouTube with all the screens collected during the week! Keep it Family Friendly, inappropriate content won’t be included in the video.

Feel proud of your customization and show it to us! From January 31st to February 6th we will be looking, commenting and sharing feedback on the screenshots shared with the hashtag #FedoraShareYourScreen on Twitter, Instagram and Mastodon!

When is this week?

It will start this on January 31st and it will end on February 6th. We will collect all the screenshots on February 7th and the slide show will be published on February 10th.

Will this happen again?

Of course! We want to see everyone’s ideas with all the new stuff that Fedora Linux adds each release. We will be doing this in the middle of each Fedora Linux release. This will give everyone time to customize the desktop and show it in all it’s shininess!