This article, will introduce Podman Pods and demonstrate how to use them with a simple application built using Node.js. The app will be lightweight and easy to set up, showcasing the power of running multiple containers in a pod.

What is a Podman Pod?

Podman pod is a group of containers that share the same network, storage, and process namespace. Kubernetes pods inspires it. Pods allow you to run multiple containers that need to work closely together, like a web server and a caching service, in a single isolated unit.

Pods in Podman provide a native way to group containers without needing a full Kubernetes setup. This makes them ideal for development and small-scale applications.

Install Podman

Podman is included by default in Fedora Linux, but if it’s not installed for any reason, you can add it with the following command:

$ sudo dnf install podman -y

For Fedora Linux Silverblue users, Podman is already installed in your system. To verify your installation, you can run a quick hello-world container:

$ podman pull hello-world
$ podman run hello-world

If everything is set up correctly, you’ll see output similar to:

Hello from Docker!

This shows that Podman is up and running, and ready for the next steps.

Starting with a Simple Node.js App in a Pod

To start this example, create a simple web application using Node.js. First, create a directory for the app:

$ mkdir webapp && cd webapp

Inside the webapp directory, create a package.json file that lists the dependencies your project needs:

{
"dependencies": {
"express": "*"
},
"scripts": {
"start": "node index.js"
}
}

Next, create an index.js file that will serve a basic “Hello World” response:

const express = require('express');
const app = express();

app.get('/', (req, res) => {
    res.send("Hello World!");
});

app.listen(8080, () => {
    console.log("Listening on port 8080");
});

Create a Dockerfile for the App

Now, create a Dockerfile in the same directory to build the container image for your app:

FROM node:alpine
WORKDIR /usr/app
COPY ./ ./
RUN npm install
CMD ["npm", "start"]

This Dockerfile will pull a lightweight Node.js image, install the necessary dependencies, and start the app.

Build the Image Using Podman

To build the container image for your app, use the following command:

$ podman build -t webapp .

The -t flag names the image webapp, and the . specifies the current directory as the build context.

Create and Run a Pod with Podman

Now that the image is ready, it’s time to create a pod and run the container inside it. First, create a pod:

$ podman pod create --name mypod -p 8080:8080

This creates a pod named mypod and maps port 8080 on the host to port 8080 inside the pod.
Next, run the Node.js container inside the pod:

$ podman run -d --pod mypod --name webapp-container webapp

The –pod flag specifies that the container should run inside mypod.

Add Another Container to the Pod

One of the key features of pods is the ability to run multiple containers that share resources. For example, let’s add a Redis container to the same pod:

$ podman run -d --pod mypod --name redis-container redis

Now, both the webapp and redis containers are running inside the same pod, sharing the network namespace. This means the webapp can communicate with redis over localhost.

Check Pod and Container Status

The status of the pod and its containers can be verified using:

$ podman pod ps
$ podman ps --pod

These commands will show you the pod’s status and its running containers.

Stopping and Removing the Pod

To stop the pod and all its containers:

$ podman pod stop mypod

To remove the pod and all its containers:

$ podman pod rm mypod

Conclusion

Podman pods offer an easy way to group and manage containers, making it simple to run applications that require multiple containers that must work together. With Podman’s built-in pod support, it is possible to use Kubernetes-like functionality without the complexity.

Silverblue is an operating system for your desktop built on Fedora Linux. It’s excellent for daily use, development, and container-based workflows. It offers numerous advantages such as being able to roll back in case of any problems. This article provides the steps to upgrade to the newly released Fedora Linux 41 Beta, and how to revert if anything unforeseen happens.

Before attempting an upgrade to the Fedora Linux 41 Beta, apply any pending upgrades.

Updating using terminal

Because the Fedora LInux 41 Beta is not available in GNOME Software, the whole upgrade must be done through a terminal.

First, check if the 41 branch is available, which should be true now:

$ ostree remote refs fedora

You should see the following line in the output:

fedora:fedora/41/x86_64/silverblue

If you want to pin the current deployment (this deployment will stay as an option in GRUB until you remove it), you can do it by running:

# 0 is entry position in rpm-ostree status
$ sudo ostree admin pin 0

To remove the pinned deployment use following command (2 corresponds to the entry position in the output from rpm-ostree status ):

$ sudo ostree admin pin --unpin 2

Next, rebase your system to the Fedora 41 branch.

$ rpm-ostree rebase fedora:fedora/41/x86_64/silverblue

Finally, the last thing to do is restart your computer and boot to Fedora Silverblue 41 Beta.

How to revert

If anything bad happens — for instance, if you can’t boot to Fedora Silverblue 41 Beta at all — it’s easy to go back. Pick the previous entry in the GRUB boot menu (you need to press ESC during boot sequence to see the GRUB menu in newer versions of Fedora Silverblue), and your system will start in its previous state. To make this change permanent, use the following command:

$ rpm-ostree rollback

That’s it. Now you know how to rebase to Fedora Silverblue 41 Beta and fall back. So why not do it today?

Known Issues

• Incorrect check for static configs with bootupd leads to no /boot/loader/grub.cfg after reboot
  We advise users to hold on testing bootupd on their updated Fedora Atomic Desktops & IoT systems until this bug is resolved.

FAQ

Because there are similar questions in comments for each blog about rebasing to newer version of Silverblue I will try to answer them in this section.

Question: Can I skip versions during rebase of Fedora Linux? For example from Fedora Silverblue 39 to Fedora Silverblue 41?

Answer: Although it could be sometimes possible to skip versions during rebase, it is not recommended. You should always update to one version above (39->40 for example) to avoid unnecessary errors.

Question: I have rpm-fusion layered and I got errors during rebase. How should I do the rebase?

Answer: If you have rpm-fusion layered on your Silverblue installation, you should do the following before rebase:

rpm-ostree update --uninstall rpmfusion-free-release --uninstall rpmfusion-nonfree-release --install rpmfusion-free-release --install rpmfusion-nonfree-release

After doing this you can follow the guide in this blog post.

Question: Could this guide be used for other ostree editions (Fedora Atomic Desktops) as well like Kinoite, Sericea (Sway Atomic), Onyx (Budgie Atomic),…?

Yes, you can follow the Rebasing using the terminal part of this guide for every ostree edition of Fedora. Just use the corresponding branch. For example for Kinoite use fedora:fedora/41/x86_64/kinoite

Today, the Fedora Project is pleased to announce the availability of Fedora Linux 41 Beta. While we’ll have more to share with the general availability of Fedora Linux 41 in about a month, there is plenty in the beta to get excited about now.

Get the the prerelease of any of our editions from our project website:

• Fedora Workstation 41 Beta
• Fedora Server 41 Beta
• Fedora IoT 41 Beta
• Fedora Cloud 41 Beta
• Fedora CoreOS “next” stream

You can also update an existing system to the beta using DNF system-upgrade.

What is a Fedora Beta release?

Fedora beta releases are code-complete and will very closely resemble the final release. While the Fedora Project community will be testing this release intensely, we also want you to check and make sure the features you care about are working as intended. The bugs you find and report help make your experience better as well as for millions of Fedora Linux users worldwide! Together, we can help not only make Fedora Linux stronger, but as these fixes and tweaks get pushed upstream to the kernel community, we can contribute to the betterment of the Linux ecosystem and free software holistically.

Some changes of note

Valkey replaces Redis

As Redis recently changed to a proprietary license, we have replaced Redis with Valkey. All software shipped by Fedora is open source and free software, in line with our Freedom foundation. If you are currently using Redis, see How to move from Redis to Valkey for migration help.

Goodbye, Python 2!

Starting with Fedora Linux 41, there will be no Python 2 in Fedora, other than PyPy. Packages requiring Python 2.7 at runtime will need to upgrade to a new version, or be retired also. Developers who still need to test their software on Python 2, or users of software that cannot be updated, can use containers with older Fedora releases.

Proprietary Nvidia driver installation with Secure Boot support

Although it can’t be part of Fedora Linux, we know that the Nvidia binary driver is pragmatically essential for many people. Previously, Nvidia driver installation had been removed from GNOME Software because it didn’t support Secure Boot, which is increasingly-often enabled by default on laptops. This change brings the option back for Fedora Workstation users with Secure Boot supported. This is good news for folks who want to use Fedora Linux for gaming and CUDA. The change also helps Fedora stay relevant for AI/LLVM workloads.

DNF 5 is here

In Fedora Linux 41, the dnf package management command will be updated to version 5. (DNF5 and bootc will be available on image-based Fedora variants such as Atomic desktops and Fedora IoT.) The new packages will make it simpler to build and update bootable container images based on these variants.

DNF and bootc in Image Mode Fedora Variants

In Fedora Linux 41, the DNF package manager will be updated to version 5. This release is faster, smaller, and better. (Pick all three!) You won’t need to change habits — the command is still just dnf, and the basic syntax isn’t different. As one might expect with a major version, there are some incompatible changes. See the DNF 5 documentation for details.

RPM 4.20

Under the hood, our lower-level package management tool is RPM, which also gets a new release, bringing new features for Fedora development. Users won’t see a direct impact immediately, but this update will help us make the distro better overall over time.

Reproducible-builds progress

A post-build cleanup is integrated into the RPM build process, making most Fedora packages now reproducible. That is, you can re-build a package from source and expect the package contents to be exactly identical. If this is interesting to you, check out Fedora Reproducible Builds for more.

New fedora-repoquery tool

Fedora-repoquery is a small command line tool for doing repoqueries of Fedora, EPEL, eln, and Centos Stream package repositories. It wraps dnf repoquery separating the cached repo data under separate repo names for faster cached querying. Repoqueries are frequently used by Fedora developers and users, so a more powerful tool like this is generally useful. 

KDE Plasma Mobile Spin

KDE Plasma Mobile brings the KDE Plasma Desktop to a flexible, mobile format in Fedora 41 as a Spin. This promises to work on both phones, tablets and 2-in-1 laptops.

LXQt 2.0

LXQt in Fedora will be upgraded to v2.0, which notably ports the whole desktop to Qt 6 and adds experimental Wayland support. 

New “Fedora Miracle” spin

The Miracle window manager is a tiling window manager based on the Mir compositor library. While it is a newer project, it contains many useful features such as a manual tiling algorithm, floating window manager support, support for many Wayland protocols, proprietary Nvidia driver support, and much more. Miracle will provide Fedora Linux with a high-quality Wayland experience built with support for all kinds of platforms, including low-end ARM and x86 devices. On top of this, Fedora Linux will be the first distribution to provide a Miracle-based spin, ensuring that it will become the de facto distribution for running Miracle. 

Missing Spins?

A technical glitch means that a few of our spins didn’t build correctly for the beta release — Robotics, Jam, Design Suite, and ARM live images. We still expect these to be part of our final release. If you’re interested in testing these, watch the Nightly Compose Finder for good builds.

Let’s test Fedora 41 Beta together

Since this is a beta release, we expect that you may encounter bugs or missing features. To report issues encountered during testing, contact the Fedora QA team via the test mailing list or in the #quality:fedoraproject.org channel on Fedora Chat (Matrix). As testing progresses, common issues are tracked in the “Common Issues” category on Ask Fedora.

For tips on reporting a bug effectively, read how to file a bug.

Following @t0xic0der and @humaton’s talk on the Git forge ARC (Advance Reconaissance Crew) investigation during Fedora Linux Release Party 40 and more recently, @humaton’s talk on the topic during Flock To Fedora 2024 – we have opened up our ARC investigation to all contributors within the Fedora Project. Please refer to the ARC initiative page to create or retrieve the use case requirements for the Git forge replacement. As part of that we created community deployments for GitLab and Forgejo.

Testing GitLab instance

The GitLab instance has limited access and needs manual approval of the account. To get an account on this instance please follow the instructions below:

1. Create an account on the GitLab instance
2. Open a ticket on Fedora Infrastructure issue
   1. Use Approve my user on GitLab test instance as summary
   2. In Types choose gitlab_testing_request template
   3. Fill in the template
3. Wait for us to approve your account

Our test GitLab instance doesn’t allow SSH pushes. You need to use HTTPS to push changes to the repository.

Testing Forgejo instance

Forgejo test instance is much more straightforward when creating an account as it is connected to our staging Fedora Account System. To get an account follow the instructions below:

1. Create an account in staging Fedora Account System (you can skip this step if you already have the staging Fedora account)
2. Login to Forgejo test instance with your staging Fedora account using Sign In with Fedora Accounts button

Our test Forgejo instance is hosted in the same environment as the GitLab test instance so it doesn’t allow SSH pushes either. You need to use https to push changes to the repository.

Since the Forgejo test instance is using a staging Fedora account you can use the same username for HTTPS push, but for the password you need to generate a token in Settings->Application->Access Tokens.

Sharing feedback with us

To share your testing results use this discussion thread and let us know if either Forgejo or GitLab is suitable for tested use cases.

How to contact us

You can reach us with any question either in this discussion thread or in our Matrix ARC investigation room.

We’ve upgraded the embroidered Fedora shirt collection with dark blue and white T-shirts and polo shirts. There’s a coupon code below, read onward for more details.

Half of the Fedora backpacks were for free

After delivering more than 800 embroidered Fedora garments to more than 50 countries, we’d like to share some numbers about our Fedora shirt project.

Our most popular items are of course shirts: 266 T-shirts, and 267 polo shirts were sold and there are 30 Fedora laptop backpacks around the world. Half of them were gifts from us to people ordering four or more other items (shirts or sweatshirts). You can still get a backpack too.

The most popular sizes are large (27%) and extra large (26%), followed by medium (19%) and 2XL (16%).

Since we ship worldwide, our Fedora garments are in 53 countries. Most of them in the United States (33%), Germany (14%), United Kingdom (5%) and France (5%). But can you find Moldova, Macao, Ghana or Réunion on the map? Fedora users show their commitment to our favorite operating system with Fedora shirts in these countries and territories too.

Currently in the HELLOTUX Fedora collection you can find T-shirts, polo shirts, a jacket, a hoodie and a laptop backpack. All of these are embroidered with the Fedora logo.

The coupon code

You can get a $5 discount on every Fedora item with the coupon code FEDORA5, and there is the Fedora laptop backpack promo as well.

Order now

Order directly from the HELLOTUX website.

In our ongoing series on Linux system insights, we have a look into essential command-line utilities that provide information about the system’s hardware and status. Following our previous discussions on lscpu, lsusb, dmidecode and lspci, we now turn our attention to lsof and lsblk. These tools are particularly useful for investigating open files, active network connections, and mounted block devices on your Fedora Linux system.

Exploring open files with lsof

lsof (list open files) is a powerful command-line tool. Since almost everything in Linux is treated as a file, lsof provides detailed insight into many parts of your system by listing what files are being used, which processes are accessing them, and even which network ports are open (see e.g. Wikipedia on Network socket for more information).

Basic usage

To start with, execute the basic lsof command to get an overview of the system’s open files:

$ sudo lsof

sudo was used for extended privileges. This is needed to get information about files not opened by processes started by your user. The command outputs a lot of information which can be overwhelming. We are going to narrow down the output to specific information about some common use cases in the following examples.

Example 1: Finding open files by user or process

To identify which files a specific user or process has open, lsof can be very helpful.

To list all files opened by a specific user:

$ sudo lsof -u <username>

This will return a list of open files owned by the given user. For example:

$ sudo lsof -u johndoe

You’ll see details such as the process ID (PID), the file descriptor, the type of file, and the file’s path.

To filter by process, use the -p flag:

$ lsof -p <PID>

This is particularly useful for troubleshooting issues related to specific processes or when you need to check which files a service is holding open. Use sudo if the process is not owned by your user.

Example output:

$ lsof -p 873648
COMMAND    PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
bash    873648 user  cwd    DIR   0,39     8666      257 /home/user
bash    873648 user  rtd    DIR   0,35      158      256 /
bash    873648 user  txt    REG   0,35  1443376 12841259 /usr/bin/bash
bash    873648 user  mem    REG   0,33          12841259 /usr/bin/bash (path dev=0,35)
bash    873648 user  mem    REG   0,33          14055145 /usr/lib/locale/locale-archive (path dev=0,35)
bash    873648 user  mem    REG   0,33          14055914 /usr/lib64/libc.so.6 (path dev=0,35)
bash    873648 user  mem    REG   0,33          13309071 /usr/lib64/libtinfo.so.6.4 (path dev=0,35)
bash    873648 user  mem    REG   0,33          14059926 /usr/lib64/gconv/gconv-modules.cache (path dev=0,35)
bash    873648 user  mem    REG   0,33          14055911 /usr/lib64/ld-linux-x86-64.so.2 (path dev=0,35)
bash    873648 user    0u   CHR  136,3      0t0        6 /dev/pts/3
bash    873648 user    1u   CHR  136,3      0t0        6 /dev/pts/3
bash    873648 user    2u   CHR  136,3      0t0        6 /dev/pts/3
bash    873648 user  255u   CHR  136,3      0t0        6 /dev/pts/3

Example 2: identifying open network connections via sockets

With its ability to list network connections, lsof also becomes a handy tool for diagnosing network-related issues as it is usually even available on hardened, minimal systems.

To display all open network connections (TCP/UDP sockets), run:

$ sudo lsof -i

This will list active Internet connections along with the associated protocol, port, and process details.

You can filter for specific protocols (like TCP or UDP), include or exclude IPv4 and v6 and combine several values (the example section of man lsof provides a lot of useful information, including negation):

$ sudo lsof -i tcp
$ sudo lsof -i udp
$ sudo lsof -i 4tcp
$ sudo lsof -i 6tcp
$ sudo lsof -i 4tcp@example.com

For connections associated with a particular port:

$ sudo lsof -i :<port_number>

For example, to list connections to port 22 (SSH):

$ sudo lsof -i :22
COMMAND    PID USER   FD   TYPE  DEVICE SIZE/OFF NODE NAME
sshd    904379 root    3u  IPv4 5622530      0t0  TCP *:ssh (LISTEN)
sshd    904379 root    4u  IPv6 5622532      0t0  TCP *:ssh (LISTEN)

This information can be critical for identifying unauthorized connections or simply monitoring network activity on a system for debugging.

Investigating block devices with lsblk

Another useful tool is lsblk, which displays information about all available block devices on your system. Block devices include hard drives, SSDs, and USB storage. This command provides a tree-like view, helping you understand the relationships between partitions, devices, and their mount points.

Basic usage

Running lsblk without any options provides a clean hierarchical structure of the block devices:

$ lsblk

This shows all block devices in a tree structure, including their size, type (disk, partition), and mount point (if applicable).

Examples

For a deeper look into the file systems on your block devices, use the -f flag:

$ lsblk -f

This will display not just the block devices, but also details about the file systems on each partition, including the type (e.g., ext4, vfat, swap), the UUID, and the current mount points.

If you want less information about the devices themselves (without showing partitions or mount points), the -d option is useful:

$ lsblk -d

There is also a -J or –json option. If used, the command outputs the information in JSON format. This provides a structured view that is particularly useful for scripting and automation.

Example outputs from my laptop (some long information like UUIDs stripped for readability):

$ lsblk
NAME                     MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINTS
sda                        8:0    1     0B  0 disk  
sdb                        8:16   1     0B  0 disk  
sdc                        8:32   1     0B  0 disk  
zram0                    252:0    0     8G  0 disk  [SWAP]
nvme0n1                  259:0    0 931,5G  0 disk  
├─nvme0n1p1              259:1    0   600M  0 part  /boot/efi
├─nvme0n1p2              259:2    0     1G  0 part  /boot
└─nvme0n1p3              259:3    0 929,9G  0 part  
  └─luks-84257c20[...]   253:0    0 929,9G  0 crypt /home


$ lsblk -d
NAME    MAJ:MIN RM   SIZE RO TYPE MOUNTPOINTS
sda       8:0    1     0B  0 disk 
sdb       8:16   1     0B  0 disk 
sdc       8:32   1     0B  0 disk 
zram0   252:0    0     8G  0 disk [SWAP]
nvme0n1 259:0    0 931,5G  0 disk

$ lsblk -f
NAME                FSTYPE [...]LABEL    UUID           FSAVAIL FSUSE% MOUNTPOINTS
sda
sdb
sdc
zram0                                                                  [SWAP]
nvme0n1             
├─nvme0n1p1         vfat                 4C5B-4355      579,7M  3%     /boot/efi
├─nvme0n1p2         ext4                 30eff827[...]  605M    31%    /boot
└─nvme0n1p3         crypto_LUKS          84257c20[...]              
  └─luks-84257[...] btrfs       fe[...]  666f9d6f[...]  303,1G  67%    /home
                                                                       /

$ lsblk -f -J
{
   "blockdevices": [
   [...],{
         "name": "nvme0n1",
         "fstype": null,
         "fsver": null,
         "label": null,
         "uuid": null,
         "fsavail": null,
         "fsuse%": null,
         "mountpoints": [
             null
         ],
         "children": [
            {
               "name": "nvme0n1p1",
               "fstype": "vfat",
               "fsver": "FAT32",
               "label": null,
               "uuid": "4C5B-4355",
               "fsavail": "579,7M",
               "fsuse%": "3%",
               "mountpoints": [
                   "/boot/efi"
               ]
            },{
               "name": "nvme0n1p2",
               "fstype": "ext4",
               "fsver": "1.0",
               "label": null,
               "uuid": "30eff827-[...]",
               "fsavail": "605M",
               "fsuse%": "31%",
               "mountpoints": [
                   "/boot"
               ]
            },{
               "name": "nvme0n1p3",
               "fstype": "crypto_LUKS",
               "fsver": "2",
               "label": null,
               "uuid": "84257c20-[...]",
               "fsavail": null,
               "fsuse%": null,
               "mountpoints": [
                   null
               ],
               "children": [
                  {
                     "name": "luks-[...]",
                     "fstype": "btrfs",
                     "fsver": null,
                     "label": "fedora_localhost-live",
                     "uuid": "666f9d6f-[...]",
                     "fsavail": "303,1G",
                     "fsuse%": "67%",
                     "mountpoints": [
                         "/home", "/"
                     ]
                  }
               ]
            }
         ]
      }
   ]
}

Conclusion

The lsof and lsblk commands are providing insights into file usage, network activity, and block device structures. Whether you’re tracking down open file handles, diagnosing network connections, or reviewing storage devices; whether you’re troubleshooting, optimizing, or simply curious; these tools provide valuable data that can help you better understand and manage your Fedora Linux environment. See you next time when we will have a look at more useful listing and information command line tools and how to use them.

Fedora test days are events where anyone can help make certain that 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 start.

There are two upcoming test periods in the next two weeks covering two topics:

• Tuesday 10 Sept through Monday 16 Sept , is to test i18n
• Monday 09 Sept through Friday 13 Sept, is to test the Tuned as Default Power Profile.

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

i18n Test Days

The i18n team is testing changes for Fedora Linux 41 (IBus Chewing default for Traditional Chinese (Taiwan) and others). As a result, the i18n and QA teams organized a test week from Tuesday, September 10, 2024, through Monday, September 16, 2024. The wiki page contains links to the test images you’ll need to participate.

Tuned as default

We’re excited to invite testers to participate in the testing of the new Tuned Power Daemon in Fedora 41, which will soon become the default power profile daemon. This new feature aims to improve power management by offering more efficient power-saving profiles and enhanced customization options. Your feedback will be instrumental in ensuring a smooth transition from the previous power-profiles-daemon to Tuned.

Whether you’re a seasoned tester or new to Fedora, your contributions will help identify any bugs and refine this feature to offer the best experience for all Fedora users. Join us in shaping the future of power management in Fedora 41! Testing will occur Monday 09 Sept through Friday 13 Sept,The wiki page has more information about how to continue.

How do test days work?

A test day is an event where anyone can help make sure changes in Fedora Linux work well in an upcoming release. Fedora community members often participate, and the public is welcome at these events. This is a perfect way to start contributing.

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 all the test days is available on the wiki pages mentioned above. If you’re available on or around the days of the events, please do some testing and report your results. All the test day pages receive some final touches which complete about 24 hrs before the test day begins. We urge you to be patient about resources that are, in most cases, uploaded hours before the test day starts.

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

SyncStar lets users create bootable USB storage devices with the operating system of their choice. This application is intended to be deployed on kiosk devices and electronic signage where conference guests and booth visitors can avail themselves of its services. Install the syncstar package from the Fedora Linux repositories or the syncstar project from the Python Package Index to get started.

$ sudo dnf install syncstar

(venv) $ pip install syncstar

Inspiration

The idea of building SyncStar came from the original concept of the Fedorator project. This was a kiosk device for writing a Live image of Fedora Linux onto USB flash drives intended to be used on Fedora Project conference booths. While the scheme was innovative as it allowed visitors at our booths to consider using Fedora Linux, the adoption could not spread widely due to the pause in in-person conferences due to the COVID-19 pandemic. The rise in prices of Raspberry Pi devices and supporting peripherals due to the global semiconductor shortage was also detrimental to the usability of the project. The foundational hardware elements of the project were now difficult to acquire and access to a 3D printer was still difficult in some parts of the world — thereby greatly heightening the entry barrier for booth organizers. Anyone wanting to run a Fedora Project booth in their neighborhood conference in the hopes of increasing the adoption of Fedora Linux could not easily do so.

Objective

The goal behind building SyncStar was to achieve what Fedorator set out to do while providing solutions to its shortcomings along the way. Questions like “How can we significantly reduce the dependency on specific kinds of external hardware while retaining similar functionality of the project?”, “How can we improve the self-service user interaction experience if we were not to include touchscreen hardware?”, “How can we ensure a lower entry barrier for someone wanting to represent Fedora Project in their local FOSS conference happening a week from now?” and many more arose. To address concerns like these, SyncStar was fabricated as a headless service by design — thus no longer necessitating the user interactions to happen on the same device on which the bootable USB devices are created. Instead, a responsive web interface was developed to be conveniently accessible on browsers across devices as long as they are connected to the same network as the device running the service.

Features

• Asynchronous multiprocessing allows for flashing multiple storage devices simultaneously
• Programming standards and engineering methodologies are maintained as much as possible
• Frontend is adaptive across various viewport types and browser-side assistive technologies
• Detailed documentation for both consumption and development purposes are readily provided
• Minimal command line interface based configuration with wide range of customizable options
• Stellar overall codebase quality is ensured with 100% coverage of functional backend code
• Over 46 checks are provided for unit based, end-to-end based integration based codebase testing
• GitHub Actions and Pre-Commit CI are enabled to automate maintenance of codebase quality

Scenarios

1. Set up the SyncStar service on the Fedora Linux promoting booth laptop or Raspberry Pi
2. Open up the SyncStar dashboard either on the booth laptop or on a smartphone
3. Lay over the swags like Fedora Project branded USB flash drives on the booth desk
4. Let a conference attendee ask if the USB flash drives on the booth table are for taking
5. Tell them that they are as long as they use SyncStar to get themselves a copy of Fedora Linux
6. Have them start the live bootable media creation and strike up a conversation with them
7. Allow other attendees to use their own USB flash drives with discretion in parallel
8. Advertise for sidestream communities by keeping their offerings in the collection

Nomenclature

You might be curious about where this fancy name comes from. Sync is a standard system call in the Unix operating system, which commits all data from the kernel filesystem buffers to non-volatile storage. This functionality is also made available in the similarly named command line utility that is used to persist a file read/write operation. While the project might not necessarily make direct use of the said system call, the functionality it tries to achieve is similar i.e. writing operating system images on the USB storage devices to make them into Live bootable media. What’s more, it has a bunch of bells and whistles like asynchronous task queues and responsive web interfaces atop the previous functionality and is that not what stars do? So that is where the fancy name “SyncStar” came from.

Appeal

If you like the efforts made here and want to support the development of the project, please consider giving a star to the project and forking it your namespace. I appreciate all kinds of contributions — ranging from small sized bug fixes to major sized feature additions as well as from trivial documentation changes to awesome codebase refactoring. Even if you do not have the capacity to take the development for a spin, you can help me out by testing out the project and getting in touch with me on the issue tracker with the things that must be fixed and the things that should be introduced. SyncStar is far from perfect right now, but with all our efforts combined, it can most definitely get closer to being great. With that mentioned, I thank you for reading through the entirety of this article .

After a long resting period, I’m back with more Cool Apps to try in flatpak format.

This article introduces projects available in Flathub with installation instructions.

Flathub is the place to get and distribute apps for all of Linux. It is powered by Flatpak, allowing Flathub apps to run on almost any Linux distribution.

Please read “Getting started with Flatpak“. In order to enable flathub as your flatpak provider, use the instructions on the flatpak site.

These apps are classified into four categories:

• Productivity
• Games
• Creativity
• Miscellaneous

Adventure List

In the Productivity section we have Adventure List. Adventure List is a Todo list app that helps you organize your tasks and goals in a fun and easy way. Whether you want to plan a trip, learn a new skill, or just get things done, Adventure List is the app for you.

Features:

• Due dates: Set due dates for your tasks and get reminders when they’re due.
• Recurring due dates: Set tasks to recur on a regular basis, so you never forget to do them.
• Notifications: Get notifications when tasks are due, so you can stay on top of your to-do list.
• Android widget: Add a widget to your Android home screen to quickly view your to-do list.
• Desktop widget mode: Pin your to-do list to your computer desktop as a widget, so you can always see what you need to do.
• Cross-platform: Available on Linux, Windows, and Android, so you can access your lists from anywhere.
• Open source: Adventure List is open source, so you can contribute to its development or customize it to your liking.

You can install “Adventure List” by clicking the install button on the web site or manually using this command:

flatpak install flathub codes.merritt.adventurelist

Endless Sky

In the Games section we have Endless Sky. This is fun space game that will take a lot of your time.

Explore other star systems. Earn money by trading, carrying passengers, or completing missions. Use your earnings to buy a better ship or to upgrade the weapons and engines on your current one. Blow up pirates. Take sides in a civil war. Or leave human space behind and hope to find some friendly aliens whose culture is more civilized than your own.

You can install “Endless Sky” by clicking the install button on the web site or manually using this command:

flatpak install flathub io.github.endless_sky.endless_sky

Endless Sky, is also available as an rpm in the Fedora Linux repositories

Sitemarker

In the Miscellaneous section we have Sitemarker. This is a bookmarks manager. Small, simple, and helps a lot to keep things organized.

You can install “Sitemarker” by clicking the install button on the web site or manually using this command:

flatpak install flathub io.github.aerocyber.sitemarker

Krita

In the Creativity section we have Krita. Krita is a full-featured digital art studio. It is perfect for sketching and painting, and presents an end-to-end solution for creating digital painting files from scratch by masters. It is a great choice for creating concept art, comics, textures for rendering and matte paintings. One of the great points of Krita is that it supports many colorspaces like RGB and CMYK at 8 and 16 bits integer channels, as well as 16 and 32 bits floating point channels. Have fun painting with the advanced brush engines, amazing filters and many handy features that make Krita a great choice.

You can install “Krita” by clicking the install button on the web site or manually using this command:

flatpak install flathub org.kde.krita

Krita is also available as an rpm in the Fedora Linux repositories

Starting with Fedora Linux 41 (currently rawhide, late October 2024 release target), Kubernetes RPMs will transition from a single Kubernetes version for each Fedora Linux release to multiple versions for each release. The planned versioned Kubernetes RPMs will include all versions currently supported by the Kubernetes team.

Repackaging

The initial release of the versioned RPMs in Rawhide will include the following:

• Kubernetes 1.31 (RPM named as kubernetes1.31)
• Kubernetes 1.30 (kubernetes1.30)
• Kubernetes 1.29 (kubernetes1.29)

This change uncouples the link between Fedora Linux releases and Kubernetes versions. This allows Kubernetes cluster administrators, using Fedora Linux as their machine operating system, to update Kubernetes or update Fedora Linux without a forced change to the other component.

The unversioned RPMs for Kubernetes in rawhide (v1.29) will continue to receive updates until February 2025.

The Kubernetes team has three (3) releases each year, along with monthly patch updates. Fedora Linux 41 goes live with Kubernetes 1.31, 1.30, and 1.29. Kubernetes 1.28 will be close to end-of-life and Kubernetes 1.27 will no longer be supported.

Each Kubernetes release in Fedora has 4 rpms (Kubernetes v1.31 as an example):

1. kubernetes1.31 – contains the kubelet runtime present on each machine in the cluster.
2. kubernetes1.31-client – contains the kubectl command line client used by cluster administrators.
3. kubernetes1.31-kubeadm – contains the optional kubeadm command line client used to initialize or upgrade machines that are part of a cluster.
4. kubernetes1.31-systemd – contains Kubernetes systemd units that are used in manually initialized clusters. If kubeadm is used to initialize the cluster then this rpm is not needed.

Kubernetes is developed using the Go language with each Kubernetes release developed with a specific version of Go. This can constrain the releases of Kubernetes available for a specific Fedora version. Fedora 39, for example went live with Go v1.21 which excludes Kubernetes 1.30 and 1.31 which rely on Go v1.22.

Kubernetes v1.29 is the last version deployed using the original, unversioned kubernetes rpm name. Plain kubernetes-1.29 rpms will be available with updates in Fedora 40 and 41 until Kubernetes v1.29 goes end-of-life in late February 2025. The unversioned Kubernetes rpm will be retired in Fedora 42.

Internal changes

The versioned Kubernetes rpms have several internal changes worth noting since they may change how a cluster is configured by an administrator.

First, these rpms no longer create the kube sysuser that was the user identity for a some kubelet related files. This change brings the default user and group ownership of kubelet files and directories in line with the standard set by the Kubernetes developers.

Second, when using kubeadm to initialize a machine to join a cluster, kubelet is configured by a kubelet configuration file. Older Fedora Kubernetes rpms use command line configuration parameters which are now mostly deprecated. This change brings kubelet configuration in line with recommendations from the Kubernetes team. See the Quick Doc referenced below for more detailed information on configuration options and recommendations for Fedora machines.

Third, the default settings of the kubelet related systemd service files found in the kubernetesX.XX and kubernetesX.XX-kubeadm rpms are now consistent with the same files from the Kubernetes team. These changes are needed to enable the adoption of the kubelet configuration file standard.

In addition to versioned Kubernetes rpms, the CRI-O and CRI-Tools rpms are also versioned for Fedora. Both CRI-O and CRI-Tools are designed to version match the Kubernetes cluster they are used with. Version matching happens at the ‘minor’ level of the semantic versioning standard (semver.org) used by all three products. A version of 1.31.1, for example, has a MAJOR version of 1, a MINOR version of 31, and a PATCH version of 1. Patch version updates for Kubernetes, CRI-O, or CRI-Tools should not cause any issues – provided that you follow general Kubernetes node upgrade guidelines (https://kubernetes.io/docs/tasks/administer-cluster/kubeadm/upgrading-linux-nodes/).

Further information

More information on Kubernetes RPMs and versions in Fedora Linux is available at https://docs.fedoraproject.org/en-US/quick-docs/using-kubernetes/.