Posted on Leave a comment

Manage containers on Fedora Linux with Podman Desktop

Podman Desktop is an open-source GUI application for managing containers on Linux, macOS, and Windows.

Historically, developers have been using Docker Desktop for graphical management of containers. This worked for those who had Docker Daemon and Docker CLI installed. However, for those who used Podman daemon-less tool, although there were a few Podman frontends like Pods, Podman desktop companion, and Cockpit, there was no official application. This is not the case anymore. Enter Podman Desktop!

This article will discuss features, installation, and use of Podman Desktop, which is developed by developers from Red Hat and other open-source contributors.

Installation

To install Podman Desktop on Fedora Linux, head over to podman-desktop.io, and click the Download for Linux button. You will be presented with two options: Flatpak and zip. In this example we are using Flatpak. After clicking Flatpak, open it in GNOME Software by double clicking the file (if you are using GNOME). You can also install it via the terminal:

flatpak install podman-desktop-X.X.X.flatpak

In the above command, replace X.X.X with the specific version you have downloaded. If you downloaded the zip file, then extract the archive, and launch the Podman Desktop application binary. You can also find pre-release versions by going to the project’s releases page on GitHub.

Features

Podman Desktop is still in its early days. Yet, it supports many common container operations like creating container images, running containers, etc. In addition, you can find a Podman extension under Extensions Catalog in Preferences, which you can use to manage Podman virtual machines on macOS and Windows. Futhermore, Podman Desktop has support for Docker Desktop extensions.

You can install such extensions in the Docker Desktop Extensions section under Preferences. The application window has two panes. The left narrow pane shows different features of the application and the right pane is the content area, which will display relevant information given what is selected on the left.

Podman Desktop 0.0.6 running on Fedora 36

Demo

To get an overall view of Podman Desktop’s capabilities, we will create an image from a Dockerfile and push it to a registry, then pull and run it, all from within Podman Desktop.

Build image

The first step is to create a simple Dockerfile by entering the following lines in the command line:

cat <<EOF>>Dockerfile
FROM docker.io/library/httpd:2.4
COPY . /var/www/html WORKDIR /var/www/html CMD ["httpd", "-D", "FOREGROUND"]
EOF

Now, go to the Images section and press the Build Image button. You will be taken to a new page to specify the Dockerfile, build context and image name. Under Containerfile path, click and browse to pick your Dockerfile. Under image name, enter a name for your image. You can specify a fully qualified image name (FQIN) in the form example.com/username/repo:tag if you want to push the image to a container registry. In this example, I enter quay.io/codezombie/demo-httpd:latest, because I have a public repository named demo-httpd on quay.io. You can follow a similar format to specify your FQIN pointing to your container registry (Quay, Docker Hub, GitHub Container Registry, etc.). Now, press Build and wait for the build to complete.

Push image

Once the build is finished, it’s time to push the image. So, we need to configure a registry in Podman Desktop. Go to Preferences, Registries and press Add registry.

Add Registry dialog

In the Add Registry dialog, enter your registry server address, and your user credentials and click ADD REGISTRY.

Now, I go back to my image in the list of images and push it to the repository by pressing the upload icon. When you hover over the image name that starts with the name of the registry added in the settings (quay.io in this demo), a push button appears alongside the image name.

The push button that appears when you hover over the image name
Image pushed to repository via Podman Desktop

Once the image is pushed, anyone with access to the image repository can pull it. Since my image repository is public, you can easily pull it in Podman Desktop.

Pull image

So, to make sure things work, remove this image locally and pull it in Podman Desktop. Find the image in the list and remove it by pressing the delete icon. Once the image is removed, click the Pull Image button. Enter the fully qualified name in the Image to Pull section and press Pull image.

Our container image is successfully pulled

Create a container

As the last part in our Podman Desktop demo, let us spin up a container from our image and check the result. I go to Containers and press Create Container. This will open up a dialog with two choices: From Containerfile/Dockerfile, and From existing image. Press From existing image. This takes us to the list of images. There, select the image we pulled.

Create a container in Podman Desktop

Now, we select our recently-pulled image from the list and press the Play button in front of it. In the dialog that appears, I enter demo-web as Container Name and 8000 as Port Mapping, and press Start Container.

Container configuration

The container starts running and we can check out our Apache server’s default page by running the following command:

curl http://localhost:8000 
It works!

You should also be able to see the running container in the Containers list, with its status changed to Running. There, you will find available operations in front of the container. For example, you can click the terminal icon to open a TTY into the container!

Display of running container demo-web in Podman Desktop with available operations for the container

What Comes Next

Podman Desktop is still young and under active development. There is a project roadmap on GitHub with a list of exciting and on-demand features including:

  • Kubernetes Integration
  • Support for Pods
  • Task Manager
  • Volumes Support
  • Support fo Docker Compose
  • Kind Support
Posted on Leave a comment

Contribute at the i18n, Release Validation, CrytoPolicy and GNOME 43 Final test weeks for Fedora Linux 37

There are 4 upcoming test days/weeks in the coming weeks. The first is Wed 31 August through Wed 07 Sept. It is to test Pre-Beta Release Validation. The second is Tuesday 6 Sept through Monday 12 Sept. It focuses on testing i18n. The third is Monday 5 Sept the Crypto Policy test day. The fourth is Wed 7 Sept through Wed 14 Sept to test GNOME 43 Final. Please come and test with us to make the upcoming Fedora 37 even better. Read more below on how to participate.

Pre-Beta Release Validation

Fedora Linux is foremost a community-powered distribution. Fedora Linux runs on all sorts of off-the-shelf hardware. The QA team relies on looking at bugs and edge cases coming out of community-owned hardware, so testing pre-release composes is a crucial part of the release process. We try to fix as many of them as we can! Please participate in the pre-beta release validation test week now through 7 September. You can help us catch those bugs at an early stage. A detailed post can be found here

GNOME 43 Final 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 43 Final will land on Fedora which then will be shipped with Fedora Linux 37. To ensure that everything works fine The Workstation Working Group and QA team will have this test week Wed 7 Sept through Wed 14 Sept. Refer to the GNOME 43 test week wiki page for links and resources needed to participate.

i18n test week

i18n test week focuses on testing internationalization features in Fedora Linux. The test week is Tuesday 6 Sept through Monday 12 Sept.

StrongCryptoSettings3 test day

This is a new and unconventional test day. The change, however small, will have impacts across many areas and we want our users to spot as many bugs as we possibly can. The advice is to use exotic VPNs, proprietary chat apps, different email providers and even git workflows. These can be tested with some advice which can be found here. This test day is Monday 5 Sept.

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

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

Posted on Leave a comment

Help improve GNOME!

gnome-info-collect is a new tool that collects anonymous data about how GNOME systems are configured. It sends that information back to GNOME servers where it can be analyzed. The goal of this tool is to help improve GNOME, by providing data that can inform design decisions, influence where resources are invested, and generally help GNOME understand its users better.

The more people who provide data, the better! So, if you would like to help us improve GNOME, please consider installing and running gnome-info-collect on your system. It only takes a second.

As of last week, gnome-info-collect is ready to be used, and we are asking all GNOME users to install and run it!

How to run the tool

Simply install the package from Fedora Copr repository by running the following commands:

$ dnf copr enable vstanek/gnome-info-collect
$ dnf install gnome-info-collect

The Copr repository also contains instructions on how to install on systems without dnf (useful for Silverblue users).

After installing, simply run

$ gnome-info-collect

from the Terminal. The tool will show you what information will be shared and won’t upload anything until you give your consent.

There are packages for other distributions as well. See the project’s README for more information.

How it works

gnome-info-collect is a simple client-server application. The client can be run on any GNOME system. There, it collects various system data including:

  • Hardware information, including the manufacturer and model
  • Various system settings, including workspace configuration, and which sharing features are enabled
  • Application information, such as which apps are installed, and which ones are favourited
  • Which GNOME shell extensions are installed and enabled

You can find the full list of collected information in the gnome-info-collect README. The tool shows the data that will be collected prior to uploading and, if the user consents to the upload, is then securely sent to GNOME’s servers for processing.

Data privacy

The collected data is completely anonymous and will be used only for the purpose of enhancing usability and user experience of GNOME. No personal information, like usernames or email addresses, is recorded. Any potentially identifying information, such as the IP address of the sender and the precise time of receiving the data, is discarded on the server side. To prevent the same client from sending data multiple times, a salted hash of the machine ID and username is used.

All of this ensures that the collected data is confidential and untraceable.

Spread the word!

The best way to help is to take part by running gnome-info-collect and uploading your anonymous data.

You can also help by sharing this article with other GNOME users, and by encouraging others to run the collection tool themselves. The more users running gnome-info-collect, the better conclusions we can make from the collected data. This will result in an improved GNOME system that is more comfortable for its users.

So, do not hesitate to help improve GNOME. Simply install gnome-info-collect, run it and go tell all your GNOME friends about it! Thank you!

Posted on Leave a comment

Fedora Linux editions part 2: Spins

One of the nice things about using Linux is the wide choice of desktop environments. Fedora Linux official Worksation edition comes with GNOME as default desktop environment, but you can choose another desktop environment as default via Fedora Spins. This article will go into a little more detail about the Fedora Linux Spins. You can find an overview of all the Fedora Linux variants in my previous article Introduce the different Fedora Linux editions.


KDE Plasma Desktop

This Fedora Linux comes with KDE Plasma as the default desktop environment. KDE Plasma is an elegant desktop environment that is very easy to customize. Therefore, you can freely and easily change the appearance of your desktop as you wish. You can customize your favorite themes, install the widgets you want, change icons, change fonts, customize panels according to your preferences, and install various extensions from the community.

Fedora Linux KDE Plasma Desktop is installed with a variety of ready-to-use applications. You’re ready to go online with Firefox, Kontact, Telepathy, KTorrent, and KGet. LibreOffice, Okular, Dolphic, and Ark are ready to use for your office needs. Your multimedia needs will be met with several applications such as Elisa, Dragon Player, K3B, and GwenView.

Fedora KDE Plasma Desktop
Fedora KDE Plasma Desktop

More information is available at this link: https://spins.fedoraproject.org/en/kde/


XFCE Desktop

This version is perfect for those who want a balance between ease of customizing appearance and performance. XFCE itself is made to be fast and light, but still has an attractive appearance. This desktop environment is becoming popular for those with older devices.

Fedora Linux XFCE is installed with various applications that suit your daily needs. These applications are Firefox, Pidgin, Gnumeric, AbiWord, Ristretto, Parole, etc. Fedora Linux XFCE also already has a System Settings menu to make it easier for you to configure your Fedora Linux.

Fedora XFCE Desktop
Fedora XFCE Desktop

More information is available at this link: https://spins.fedoraproject.org/en/xfce/


LXQT Desktop

This spin comes with a lightweight Qt desktop environment, and focuses on modern classic desktops without slowing down the system. This version of Fedora Linux includes applications based on the Qt5 toolkit and is Breeze themed. You will be ready to carry out various daily activities with built-in applications, such as QupZilla, QTerminal, FeatherPad, qpdfview, Dragon Player, etc.

Fedora LXQt Desktop
Fedora LXQt Desktop

More information is available at this link: https://spins.fedoraproject.org/en/lxqt/


MATE-Compiz Desktop

Fedora Linux MATE Compiz Desktop is a combination of MATE and Compiz Fusion. MATE desktop allows this version of Fedora Linux to work optimally by prioritizing productivity and performance. At the same time Compiz Fusion provides a beautiful 3D look with Emerald and GTK + themes. This Fedora Linux is also equipped with various popular applications, such as Firefox, LibreOffice, Parole, FileZilla, etc.

Fedora Mate-Compiz Desktop
Fedora Mate-Compiz Desktop

More information is available at this link: https://spins.fedoraproject.org/en/mate-compiz/


Cinnamon Desktop

Because of its user-friendly interface, Fedora Linux Cinnamon Desktop is perfect for those who may be new to the Linux operating system. You can easily understand how to use this version of Fedora Linux. This spin has built-in applications that are ready to use for your daily needs, such as Firefox, Pidgin, GNOME Terminal, LibreOffice, Thunderbird, Shotwell, etc. You can use Cinnamon Settings to configure your operating system.

Fedora Cinnamon Desktop
Fedora Cinnamon Desktop

More information is available at this link: https://spins.fedoraproject.org/en/cinnamon/


LXDE Desktop

Fedora Linux LXDE Desktop has a desktop environment that performs fast but is designed to keep resource usage low. This spin is designed for low-spec hardware, such as netbooks, mobile devices, and older computers. Fedora Linux LXDE has lightweight and popular applications, such as Midori, AbiWord, Osmo, Sylpheed, etc.

Fedora LXDE Desktop
Fedora LXDE Desktop

More information is available at this link: https://spins.fedoraproject.org/en/lxde/


SoaS Desktop

SoaS stands for Sugar on a Stick. Fedora Linux Sugar Desktop is a learning platform for children, so it has a very simple interface that is easy for children to understand. The word “stick” in this context refers to a thumb drive or memory “stick”. This means this OS has a compact size and can be completely installed on a thumb drive. Schoolchildren can carry their OS on a thumb drive, so they can use it easily at home, school, library, and elsewhere. Fedora Linux SoaS has a variety of interesting learning applications for children, such as Browse, Get Books, Read, Turtle Blocks, Pippy, Paint, Write, Labyrinth, Physic, and FotoToon.

Fedora SOAS Desktop
Fedora SOAS Desktop

More information is available at this link: https://spins.fedoraproject.org/en/soas/


i3 Tiling WM

The i3 Tiling WM spin of Fedora Linux is a bit different from the others. This Fedora Linux spin does not use a desktop environment, but only uses a window manager. The window manager used is i3, which is a very popular tiling window manager among Linux users. Fedora i3 Spin is intended for those who focus on interacting using a keyboard rather than pointing devices, such as a mouse or touchpad. This spin of Fedora Linux is equipped with various applications, such as Firefox, NM Applet, brightlight, azote, htop, mousepad, and Thunar.

Fedora i3 Tiling WM
Fedora i3 Tiling WM

More information is available at this link: https://spins.fedoraproject.org/en/i3/


Conclusion

Fedora Linux provides a large selection of desktop environments through Fedora Linux Spins. You can simply choose one of the Fedora Spins, and immediately enjoy Fedora Linux with the desktop environment of your choice along with its ready-to-use built-in applications. You can find complete information about Fedora Spins at https://spins.fedoraproject.org/.

Posted on Leave a comment

4 cool new projects to try in Copr for August 2022

Copr is a build system for anyone in the Fedora community. It hosts thousands of projects for various purposes and audiences. Some of them should never be installed by anyone, some are already being transitioned to the official Fedora Linux repositories, and the rest are somewhere in between. Copr gives you the opportunity to install third-party software that is not available in Fedora Linux repositories, try nightly versions of your dependencies, use patched builds of your favorite tools to support some non-standard use cases, and just experiment freely.

If you don’t know how to enable a repository or if you are concerned about whether it is safe to use Copr, please consult the project documentation.

This article takes a closer look at interesting projects that recently landed in Copr.

Ntfy

Ntfy is a simple HTTP-based notification service that allows you to send notifications to your devices using scripts from any computer. To send notifications ntfy uses PUT/POST commands or it is possible to send notifications via ntfy CLI without any registration or login. For this reason, choose a hard-to guess topic name, as this is essentially a password.

In the case of sending notifications, it is as simple as this:

$ ntfy publish beer-lovers "Hi folks. I love beer!"
{"id":"4ZADC9KNKBse", "time":1649963662, "event":"message", "topic":"beer-lovers", "message":"Hi folks. I love beer!"}

And a listener who subscribes to this topic will receive:

$ ntfy subscribe beer-lovers
{"id":"4ZADC9KNKBse", "time":1649963662, "event":"message", "topic":"beer-lovers", "message":"Hi folks. I love beer!"}

If you wish to receive notifications on your phone, then ntfy also has a mobile app for Android so you can send notifications from your laptop to your phone.

Installation instructions

The repo currently provides ntfy for Fedora Linux 35, 36, 37, and Fedora Rawhide. To install it, use these commands:

sudo dnf copr enable cyqsimon/ntfysh
sudo dnf install ntfysh

Koi

If you use light mode during the day but want to protect your eyesight overnight and switch to dark mode, you don’t have to do it manually anymore. Koi will do it for you!

Koi provides KDE Plasma Desktop functionality to automatically switch between light and dark mode according to your preferences. Just set the time and themes.

Installation instructions

The repo currently provides Koi for Fedora Linux 35, 36, 37, and Fedora Rawhide. To install it, use these commands:

sudo dnf copr enable birkch/Koi
sudo dnf install Koi

SwayNotificationCenter

SwayNotificationCenter provides a simple and nice looking GTK GUI for your desktop notifications.

You will find some key features such as do-not-disturb mode, a panel to view previous notifications, track pad/mouse gestures, support for keyboard shortcuts, and customizable widgets. SwayNotificationCenter also provides a good way to configure and customize via JSON and CSS files.

More information on https://github.com/ErikReider/SwayNotificationCenter with screenshots at the bottom of the page.

Installation instructions

The repo currently provides SwayNotificationCenter for Fedora Linux 35, 36, 37, and Fedora Rawhide. To install it, use these commands:

sudo dnf copr enable erikreider/SwayNotificationCenter
sudo dnf install SwayNotificationCenter

Webapp Manager

Ever want to launch your favorite websites from one place? With WebApp manager, you can save your favorite websites and run them later as if they were an apps.

You can set a browser in which you want to open the website and much more. For example, with Firefox, all links are always opened within the WebApp.

WebApp manager showcase

Installation instructions

The repo currently provides WebApp for Fedora Linux 35, 36, 37, and Fedora Rawhide. To install it, use these commands:

sudo dnf copr enable perabyte/webapp-manager
sudo dnf install webapp-manager
Posted on Leave a comment

Contribute at the Fedora Kernel 5.19 and GNOME 43 Beta test weeks

There are two upcoming test weeks in the coming weeks. The first is Sunday 14 August through Sunday 21 August. It is to test Kernel 5.19. The second is Monday 15 August through Monday 22 August. It focuses on testing GNOME 43 Beta. Come and test with us to make the upcoming Fedora 37 even better. Read more below on how to participate.

Kernel test week

The kernel team is working on final integration for Linux kernel 5.19. This version was just recently released, and will arrive soon in Fedora. As a result, the Fedora kernel and QA teams have organized a test week Sunday, August 14, 2022 through Sunday, August 21, 2022. Refer to the wiki page for links to the test images you’ll need to participate.

GNOME 43 Beta 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 43 beta will land on Fedora which then will be shipped with Fedora 37. To ensure that everything works fine The Workstation Working Group and QA team will have this test week Monday 15 August through Monday 22 August. Refer to the GNOME 43 Beta test week wiki page for links and resources needed to participate.

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

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

  • Kernel 5.19 testing on Sunday 14 August through Sunday 21 August
  • Gnome 43 Beta testing on Monday 15 August through Monday 22 August

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

Posted on Leave a comment

Hibernation in Fedora Workstation

This article walks you through the manual setup for hibernation in Fedora Linux 36 Workstation using BTRFS and is based on a gist by eloylp on github.

Goal and Rationale

Hibernation stores the current runtime state of your machine – effectively the contents of your RAM, onto disk and does a clean shutdown. Upon next boot this state is restored from disk to memory such that everything, including open programs, is how you left it.

Fedora Workstation uses ZRAM. This is a sophisticated approach to swap using compression inside a portion of your RAM to avoid the slower on-disk swap files. Unfortunately this means you don’t have persistent space to move your RAM upon hibernation when powering off your machine.

How it works

The technique configures systemd and dracut to store and restore the contents of your RAM in a temporary swap file on disk. The swap file is created just before and removed right after hibernation to avoid trouble with ZRAM. A persistent swap file is not recommended in conjunction with ZRAM, as it creates some confusing problems compromising your systems stability.

A word on compatibility and expectations

Hibernation following this guide might not work flawless on your particular machine(s). Due to possible shortcomings of certain drivers you might experience glitches like non-working wifi or display after resuming from hibernation. In that case feel free to reach out to the comment section of the gist on github, or try the tips from the troubleshooting section at the bottom of this article.

The changes introduced in this article are linked to the systemd hibernation.service and hibernation.target units and hence won’t execute on their own nor interfere with your system if you don’t initiate a hibernation. That being said, if it does not work it still adds some small bloat which you might want to remove.

Hibernation in Fedora Workstation

The first step is to create a btrfs sub volume to contain the swap file.

$ btrfs subvolume create /swap

In order to calculate the size of your swap file use swapon to get the size of your zram device.

$ swapon
NAME TYPE SIZE USED PRIO
/dev/zram0 partition 8G 0B 100

In this example the machine has 16G of RAM and a 8G zram device. ZRAM stores roughly double the amount of system RAM compressed in a portion of your RAM. Let that sink in for a moment. This means that in total the memory of this machine can hold 8G * 2 + 8G of RAM which equals 24G uncompressed data. Create and configure the swapfile using the following commands.

$ touch /swap/swapfile
# Disable Copy On Write on the file
$ chattr +C /swap/swapfile
$ fallocate --length 24G /swap/swapfile
$ chmod 600 /swap/swapfile $ mkswap /swap/swapfile

Modify the dracut configuration and rebuild your initramfs to include the

resume

module, so it can later restore the state at boot.

$ cat <<-EOF | sudo tee /etc/dracut.conf.d/resume.conf
add_dracutmodules+=" resume "
EOF
$ dracut -f

In order to configure grub to tell the kernel to resume from hibernation using the swapfile, you need the UUID and the physical offset.

Use the following command to determine the UUID of the swap file and take note of it.

$ findmnt -no UUID -T /swap/swapfile
dbb0f71f-8fe9-491e-bce7-4e0e3125ecb8

Calculate the correct offset. In order to do this you’ll unfortunately need gcc and the source of the btrfs_map_physical tool, which computes the physical offset of the swapfile on disk. Invoke gcc in the directory you placed the source in and run the tool.

$ gcc -O2 -o btrfs_map_physical btrfs_map_physical.c
$ ./btrfs_map_physical /path/to/swapfile FILE OFFSET EXTENT TYPE LOGICAL SIZE LOGICAL OFFSET PHYSICAL SIZE DEVID PHYSICAL OFFSET
0 regular 4096 2927632384 268435456 1 <4009762816>
4096 prealloc 268431360 2927636480 268431360 1 4009766912
268435456 prealloc 268435456 3251634176 268435456 1 4333764608
536870912 prealloc 268435456 3520069632 268435456 1 4602200064
805306368 prealloc 268435456 3788505088 268435456 1 4870635520
1073741824 prealloc 268435456 4056940544 268435456 1 5139070976
1342177280 prealloc 268435456 4325376000 268435456 1 5407506432
1610612736 prealloc 268435456 4593811456 268435456 1 5675941888

The first value in the PHYSICAL OFFSET column is the relevant one. In the above example it is 4009762816.

Take note of the pagesize you get from getconf PAGESIZE.

Calculate the kernel resume_offset through division of physical offset by the pagesize. In this example that is 4009762816 / 4096 = 978946.

Update your grub configuration file and add the resume and resume_offset kernel cmdline parameters.

grubby --args="resume=UUID=dbb0f71f-8fe9-491e-bce7-4e0e3125ecb8 resume_offset=2459934" --update-kernel=ALL

The created swapfile is only used in the hibernation stage of system shutdown and boot hence not configured in fstab. Systemd units control this behavior, so create the two units hibernate-preparation.service and hibernate-resume.service.

$ cat <<-EOF | sudo tee /etc/systemd/system/hibernate-preparation.service
[Unit]
Description=Enable swap file and disable zram before hibernate
Before=systemd-hibernate.service [Service]
User=root
Type=oneshot
ExecStart=/bin/bash -c "/usr/sbin/swapon /swap/swapfile && /usr/sbin/swapoff /dev/zram0" [Install]
WantedBy=systemd-hibernate.service
EOF
$ systemctl enable hibernate-preparation.service
$ cat <<-EOF | sudo tee /etc/systemd/system/hibernate-resume.service
[Unit]
Description=Disable swap after resuming from hibernation
After=hibernate.target [Service]
User=root
Type=oneshot
ExecStart=/usr/sbin/swapoff /swap/swapfile [Install]
WantedBy=hibernate.target
EOF
$ systemctl enable hibernate-resume.service

Systemd does memory checks on login and hibernation. In order to avoid issues when moving the memory back and forth between swapfile and zram disable some of them.

$ mkdir -p /etc/systemd/system/systemd-logind.service.d/
$ cat <<-EOF | sudo tee /etc/systemd/system/systemd-logind.service.d/override.conf
[Service]
Environment=SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1
EOF
$ mkdir -p /etc/systemd/system/systemd-hibernate.service.d/
$ cat <<-EOF | sudo tee /etc/systemd/system/systemd-hibernate.service.d/override.conf
[Service]
Environment=SYSTEMD_BYPASS_HIBERNATION_MEMORY_CHECK=1
EOF

Reboot your machine for the changes to take effect. The following SELinux configuration won’t work if you don’t reboot first.

SELinux won’t like hibernation attempts just yet. Change that with a new policy. An easy although “brute” approach is to initiate hibernation and use the audit log of this failed attempt via audit2allow. The following command will fail, returning you to a login prompt.

systemctl hibernate

After you’ve logged in again check the audit log, compile a policy and install it. The -b option filters for audit log entries from last boot. The -M option compiles all filtered rules into a module, which is then installed using semodule -i.

$ audit2allow -b
#============= systemd_sleep_t ==============
allow systemd_sleep_t unlabeled_t:dir search;
$ cd /tmp
$ audit2allow -b -M systemd_sleep
$ semodule -i systemd_sleep.pp

Check that hibernation is working via systemctl hibernate again. After resume check that ZRAM is indeed the only active swap device.

$ swapon
NAME TYPE SIZE USED PRIO
/dev/zram0 partition 8G 0B 100

You now have hibernation configured.

GNOME Shell hibernation integration

You might want to add a hibernation button to the GNOME Shell “Power Off / Logout” section. Check out the extension Hibernate Status Button to do so.

Troubleshooting

A first place to troubleshoot any problems is through journalctl -b. Have a look around the end of the log, after trying to hibernate, to pin-point log entries that tell you what might be wrong.

Another source of information on errors is the Problem Reporting tool. Especially problems, that are not common but more specific to your hardware configuration. Have a look at it before and after attempting hibernation and see if something comes up. Follow up on any issues via BugZilla and see if others experience similar problems.

Revert the changes

To reverse the changes made above, follow this check-list:

  • remove the swapfile
  • remove the swap subvolume
  • remove the dracut configuration and rebuild dracut
  • remove kernel cmdline args via grubby –remove-args=
  • disable and remove hibernation preparation and resume services
  • remove systemd overrides for systemd-logind.service and systemd-hibernation.service
  • remove SELinux module via semodule -r systemd_sleep

Credits and Additional Resources

This article is a community effort based primarily on the work of eloylp. As author of this article I’d like to make transparent that I’ve participated in the discussion to advance the gist behind this but many more minds contributed to make this work. Make certain to check out the discussion on github.

There are already some ansible playbooks and shell scripts to automate the process depicted in this guide. For example check out the shell scripts by krokwen and pietryszak or the ansible playbook by jorp

See the arch wiki for the full guide on how to calculate the swapfile offset.

Posted on Leave a comment

Fedora and Parental Controls

We all have people around us, whom we hold dear. Some of them might even rely on you to keep them save. And since the world is constantly changing, that can be a challenge. No more is this apparent than with children, and Linux has long been lacking simple tools to help parents. But that is changing, and here we’ll talk about the new parental controls that Fedora Linux provides.

Users and permissions

First, it’s important to know that any Linux system has a lot of options for user, group, and permission management. Many of these advanced tools are aimed at professional users, though, and we won’t be talking about those here. In this article we’ll focus on home users.

Additionally, parental controls are not just useful for parents. You can use them when helping family members who are technically illiterate. Or perhaps you want to configure a basic workstation for simple administrative tasks. Either way, parental control can offer many security and reliability benefits.

Creating users

From the Settings panel, you can navigate to Users and from there you can select Add User… (after unlocking) to add a new user. You can give them a personal name, a username and their own icon. You can even decide if somebody else should also be an administrator.

Adding a user to your machine is as simple as going to settings, users, and clicking Add User…

You can also set a default password, or even allow a computer to automatically log in. You should help others understand digital security and the value of passwords, but for some people it might be better to just auto-login.

Admin rights

When you give somebody administrator rights, that user will have the same powers as you have on the system. They will be able to make any system change they prefer, and they can also add and remove users themselves.

Users who do not have admin rights, will not be able to make fundamental changes to the computer. They can still use all applications that are already on the system, and they can even download applications from the internet to their home folder. Still, they are ultimately blocked from doing anything that could damage the system.

Accessing the user-directories of others. Only administrator users will be able to do this.

Don’t forget that as an administrator, you can always reset a password. You can also enter another user’s home directory in case you have to. As with all ‘sudo’ rights, you should be careful and you should be considerate of other’s privacy.

Application control

Once one or multiple users are created, you can choose to tweak and control what applications somebody can use. This is done from within Settings > Users by selecting the new user then selecting Parental Controls and then Restrict Applications. Other options are available there, as well.

changing Parental Controls for a single user.

However, there is a big caveat

Parental controls come with a big caveat: If you want a simple home-user solution, you MUST use Flatpaks.

The problem is as follows. The existing Linux application landscape is quite complex, and it would be almost impossible to introduce a new user-friendly application-control system this late into its life cycle. Thus, the second best solution is to ensure that the next generation of packaging has such functionality from the start.

To use Flatpaks, you can use the Fedora’s repository, or the Flathub repository. If you want to know all the fine details about those projects, then don’t forget to read this recent comparison.

Compromise and limitations

No article would be complete without mentioning the inherit limitations of the parental controls. Besides all the obvious limits of computers not knowing right from wrong, there are also some technical limits to parental controls.

Parental Control’s limits

The security that Parental Controls provides will only work as long as Fedora Linux is running in working order. One could easily bypass all controls by flashing Fedora on a USB stick and starting from a clean, root-powered, installation image. At this point, human supervision is still superior to the machine’s rules.

Adding to that, there are the obvious issues of browsers, store fronts like Steam, and other on-line applications. You can’t block just parts of these applications. Minecraft is a great game for children, but it also allows direct communication with other people. Thus, you’ll have to constantly juggle permissions. Here too, it is better to focus on the human element instead of relying to much on the tools.

Finally, don’t forget about protecting the privacy and well-being of others online. Blocking bad actors with Ublock Origin and/or a DNS based blocker will also help a lot.

Legacy applications

As mentioned before, Fedora and Parental Controls only work with Flatpaks. Every application that is already on the system can be started by users who otherwise don’t have the permissions.

As a rule of thumb; If you want to share a computer with vulnerable family members, don’t install any software that’s inappropriate using the RPM Repositories. Instead, consider using a Flatpak.

Starting the system-wide installation of Firefox from the Terminal. The Flatpak version of Firefox though, will not start.

Summary

There is much that you can do to help those who are less experienced with computers. By simply giving these users their own account and using Flatpaks, you can make their lives a lot easier. Age restrictions can even offer additional benefits. But it’s not all perfect, and good communication and supervision will still be important.

The Parental Controls will improve over time. They have been given more priority in the past few years and there are additional plans. Time-tracking is, for example planned. As the migration to Flatpaks continues, you can expect that more software will respect age-restrictions in the future.

Additional US and UK resources

Sharing Fedora Linux with Parental Controls

So, let’s start a small collaboration here. We’ve all been younger, so how did you escape your parents’ scrutiny? And for those who are taking care of others… how are you helping others? Let’s see what we can learn from each other.

Posted on Leave a comment

Community container images available for applications development

This article aims to introduce community containers, where users can pull them from, and use them. The three groups of containers available for use by community users are discussed. These are: Fedora, CentOS, and CentOS Stream.

What are the differences between the containers?

Fedora containers are based on the latest stable Fedora content, and CentOS-7 containers are based on components from the CentOS-7 and related SCLo SIG components. And finally, CentOS Stream containers are based on either CentOS Stream 8 or CentOS Stream 9.

Each container, e.g. s2i-php-container or s2i-perl-container, contain the same packages which are available for a given operating system. It means, that from a functionality point of view these example containers provides the PHP interpreter or Perl interpreter,respectively. 

Differences can be only in versions, which are available for each distribution. For example:

Fedora PHP containers are available in these versions:

CentOS-7 PHP containers are available in these versions:

CentOS Stream 9 PHP containers are available in these versions:

CentOS Stream 8 is not mentioned here for the PHP use case since users can pull it directly from the Red Hat Container Catalog registry as a UBI image. Containers that are not UBI based have CentOS Stream 8 repositories in the quay.io/sclorg namespace with repository suffix “-c8s”.

Fedora container images moved recently

The Fedora container images have recently moved to the quay.io/fedora registry organization. All of them use Fedora:35, and later Fedora:36 ,as a base image. The CentOS-7 containers are stored in the quay.io/centos7 registry organization. All of them use CentOS-7 as a base image.

CentOS Stream container images

The CentOS Stream containers are stored in the quay.io/sclorg registry organization.

The base image used for our CentOS Stream 8 containers is CentOS Stream 8 with the tag “stream8”.

The base image used for our CentOS Stream 9 containers is CentOS Stream 9 with the tag “stream9”.

In this registry organization, each container contains a “suffix”, either “c8s”  for CentOS Stream 8 or “c9s” for CentOS Stream 9, respectively.

See container PHP-74 for CentOS Stream 9.

Frequency of container image updates and testing

The community-based containers are updated in two ways.

First, when a pull request in the container sources that live under github.com/sclorg organization is merged, the corresponding versions in the GitHub repository are built and pushed into the proper repository.

Second, an update process is also implemented by GitHub Actions set up in each of our GitHub repositories. The base images, like “s2i-core” and “s2i-base”, are built each Tuesday at 1:00 pm. The rest of the containers are built each Wednesday at 1:00 pm.

This means every package update or change is updated in the container image within a few days, not later than after a week.

Each container that is not beyond its end of life is tested by our nightly builds. If we discover or detect an error on some of our containers, we attempt to fix it, but there are no guarantees provided.

What container shall I use?

In the end, what containers are we providing? That’s a great question. All containers live in the GitHub organization https://github.com/sclorg

The list of containers with their upstreams is summarized here:

How to use the container image I picked?

All container images are tuned up to be fully functional in the OpenShift (or OKD and even Kubernetes itself) without any trouble. Some containers support the source-to-image build strategy while some are expected to be used as daemons (like databases, for instance). For specific steps, please, navigate to the GitHub page for the respective container image by following one of the links above.

Finally, Some Real examples

Let’s show how to use PHP container images across all platforms that we support.

First of all, clone the container GitHub repository using this command:

$ git clone https://github.com/sclorg/s2i-php-container

Switch to the following directory created by the cloning step:

$ cd s2i-php-container/examples/from-dockerfile

Fedora example

Start by pulling the Fedora PHP-80 image with this command:

$ podman pull quay.io/fedora/php-80

Modify “Dockerfile” so it refers to Fedora php-80 image. “Dockerfile” then looks like:

FROM quay.io/fedora/php-80 USER 0
# Add application sources
ADD app-src .
RUN chown -R 1001:0 .
USER 1001 # Install the dependencies
RUN TEMPFILE=$(mktemp) && \ curl -o "$TEMPFILE" "https://getcomposer.org/installer" && \ php <"$TEMPFILE" && \ ./composer.phar install --no-interaction --no-ansi --optimize-autoloader # Run script uses standard ways to configure the PHP application
# and execs httpd -D FOREGROUND at the end
# See more in <version>/s2i/bin/run in this repository.
# Shortly what the run script does: The httpd daemon and php need to be
# configured, so this script prepares the configuration based on the container
# parameters (e.g. available memory) and puts the configuration files into
# the appropriate places.
# This can obviously be done differently, and in that case, the final CMD
# should be set to "CMD httpd -D FOREGROUND" instead.
CMD /usr/libexec/s2i/run

Check if the application works properly

Build it by using this command:

$ podman build -f Dockerfile -t cakephp-app-80

Now run the application using this command:

$ podman run -ti --rm -p 8080:8080 cakephp-app-80

To check the PHP version use these commands:

$ podman run -it –rm cakephp-app-80 bash
$ php –version

To check if everything works properly use this command:

$ curl -s -w ‘%{http_code}’ localhost:8080

This should return HTTP code 200. If you would like to see a web page enter “localhost:8080” in your browser.

CentOS 7 example

Start by pulling the CentOS-7 PHP-73 image using this command:

$ podman pull quay.io/centos7/php-73-centos7

Modify “Dockerfile” so it refers to CentOS php-73 image.

“Dockerfile” then looks like this:

FROM quay.io/centos7/php-73-centos7 USER 0
# Add application sources
ADD app-src .
RUN chown -R 1001:0 .
USER 1001 # Install the dependencies
RUN TEMPFILE=$(mktemp) && \ curl -o "$TEMPFILE" "https://getcomposer.org/installer" && \ php <"$TEMPFILE" && \ ./composer.phar install --no-interaction --no-ansi --optimize-autoloader # Run script uses standard ways to configure the PHP application
# and execs httpd -D FOREGROUND at the end
# See more in <version>/s2i/bin/run in this repository.
# Shortly what the run script does: The httpd daemon and php needs to be
# configured, so this script prepares the configuration based on the container
# parameters (e.g. available memory) and puts the configuration files into
# the appropriate places.
# This can obviously be done differently, and in that case, the final CMD
# should be set to "CMD httpd -D FOREGROUND" instead.
CMD /usr/libexec/s2i/run

Check if the application works properly

Build it using this command:

$ podman build -f Dockerfile -t cakephp-app-73

Now run the application using this command:

$ podman run -ti --rm -p 8080:8080 cakephp-app-73

To check the PHP version us these commands:

$ podman run -it –rm cakephp-app-73 bash
$ php –version

To check if everything works properly use this command:

curl -s -w ‘%{http_code}’ localhost:8080

which should return HTTP code 200. If you would like to see a web page enter localhost:8080 in your browser.

RHEL 9 UBI 9 real example

Start by pulling the RHEL9 UBI-based PHP-80 image using the command:

$ podman pull registry.access.redhat.com/ubi9/php-80

Modify “Dockerfile” so it refers to the RHEL9 ubi9 php-80 image.

“Dockerfile” then looks like:

FROM registry.access.redhat.com/ubi9/php-80 USER 0
# Add application sources
ADD app-src .
RUN chown -R 1001:0 .
USER 1001 # Install the dependencies
RUN TEMPFILE=$(mktemp) && \ curl -o "$TEMPFILE" "https://getcomposer.org/installer" && \ php <"$TEMPFILE" && \ ./composer.phar install --no-interaction --no-ansi --optimize-autoloader # Run script uses standard ways to configure the PHP application
# and execs httpd -D FOREGROUND at the end
# See more in <version>/s2i/bin/run in this repository.
# Shortly what the run script does: The httpd daemon and php needs to be
# configured, so this script prepares the configuration based on the container
# parameters (e.g. available memory) and puts the configuration files into
# the appropriate places.
# This can obviously be done differently, and in that case, the final CMD
# should be set to "CMD httpd -D FOREGROUND" instead.
CMD /usr/libexec/s2i/run

Check if the application works properly

Build it using this command:

$ podman build -f Dockerfile -t cakephp-app-80-ubi9

Now run the application using this command:

$ podman run -ti --rm -p 8080:8080 cakephp-app-80-ubi9

To check the PHP version use these commands:

$ podman run -it –rm cakephp-app-80-ubi9 bash
$ php –version

To check if everything works properly use this command:

curl -s -w ‘%{http_code}’ localhost:8080

which should return HTTP code 200. If you would like to see a web page enter localhost:8080 in your browser.

What to do in the case of a bug or enhancement

Just file a bug (known as an “issue” in GitHub) or even a pull request with a fix, to one of the GitHub repositories mentioned in the previous section.

Posted on Leave a comment

Your Personal Voice Assistant on Fedora Linux

It’s 7 PM. I sit down at my Fedora Linux PC and start a MMORPG. We want to brawl with Red Alliance over some systems they attacked; the usual stuff on a Friday evening in EVE. While we are waiting on a Titan to bridge us to the fighting area, a tune comes to my mind. “Carola, I wanna hear hurricanes.” My HD LED starts to blink for a second and I hear Carola saying “I found one match” and the music starts.

What sounded like Sci-Fi twenty years ago is now a reality for many PC users. For Linux users, this is now possible by installing “Carola” as your Personal Voice Assistant (PVA)[1].

Carola

The first thing people often ask is, “Why did you name it Carola?” 🙂 This is a common misconception. Carola is not the project name. It’s the keyword the PVA reacts to by default. It is similar to “Alexa” or “OK, Google” for those who are familiar with those products. You can configure this keyword. You can also configure other things such as your location, which applications to use by default when opening media files, what CardDAV server to use when looking up contact information, etc. These settings can be personalized for each user. Some of them can even be changed by voice command (e.g. the name, the default TTS engine, and the default apps).

In 2021 I read an article about the Speech-To-Text (STT) system Vosk[2] and started to play a bit with it. The installation was easy. But there was no use-case except for writing what one said down to the screen. A few hours and a hundred lines of Java code later, I could give my PC simple commands. After a few more days of work, it was capable of executing more complex commands. Today, you can tell him/her/it to start apps, redirect audio streams, control audio and video playback, call someone, handle incoming calls, and more. If you have a smart-home (which I haven’t 😉) you can even switch on the light in the kitchen. But back to why I chose “Carola” — it was the most recognizable by the STT system I was using at the time. 😉

Note: This PVA has no English translations yet because it was developed in German. I will use rough translations here which should work once someone helps with translating the config. There are videos out about Carola which show these kinds of interactions in reality[6]. For now, because a few dependencies are unavailable from Fedora Linux’s default repositories, you will need to install the system manually. But don’t be afraid, it is all described in the READ.ME and it is pretty simple.

The time of eSpeak has run out

A voice assistant doesn’t just react to your speech. It can also reply back to you. You might expect it to sound like a creepy robot voice from the 1960s when it was invented. But trust me, Fedora Linux can do better. 😉 Naturally, eSpeak was the first choice because it was installed on the system by default. But today we can choose (even by voice command 😉) what speech engine we want to use.

Text-To-Speech (TTS) systems

Text-To-Speech systems translate the written text to a listenable waveform. Some systems output the waveform directly. Others produce MP3 or WAV files which you can then play with, for example, sox. Over the last year, we’ve experimented with several TTS systems. One outputs the text via the Samsung TTS engine on an Android device. It sounds great, but it requires your cellphone and a special server application. 😉

One of the first speech engines I tried was MBROLA[3]. It produces more understandable audio than eSpeak. But it’s still far from being “good”, as it relies on eSpeak. Think of it as an eSpeak pre-processor. Unfortunately, it is not currently available from Fedora Linux’s default repositories.

Next was Pico2Wave, which still uses the same technique as eSpeak, but on a higher level. Still, this does not meet our vision of speech quality. Also, it has to be extracted from an old Ubuntu package because it isn’t available from the Fedora Linux repositories.

With MaryTTS[4] we reach the first speech processor that produces human speech patterns combined with accent and dialect. MaryTTS was developed in Germany at the Saarland University & the German Research Center for AI. It’s not meant to run on your local PC (but does quite well). Rather, it is meant to run on a network to offer speech output to any kind of client that asks for it. Because modern PCs have way more CPU power than it requires, you can also run it solo on your PC. However, running it locally requires compiling the source code which can be a little tricky to do.

MaryTTS comes with different languages and one remarkable voice for Germans — an old Bavarian woman. This voice model was trained from an old speech archive in Munich and it’s so good that you’d think your PC is at least seventy years old. 🙂 This also makes it seem like you are giving commands to an old women who should be in retirement. This makes giving commands to your PC problematic; trust me. 😉

The top of the line of available TTS systems is GTTS[5]. It is available from the default Fedora Linux repositories. This TTS produces the best sound quality for a wide variety of languages and, for standard voices, “the first 4 million characters are free each month”[7]. The downside of this TTS is that the text is sent to Google’s servers[8] for processing and translation into an audible speech format. This might be a privacy concern depending on the nature of the data that you are sending for translation. Be mindful that the PVA will repeat parts of what you said if it did not understand your command or when it tells you things in response to your question. For this reason, GTTS is not the default TTS. However, it is pre-configured in the PVA repo[1] and ready to use.

Let’s talk about privacy

You just read that your TTS system could rat you out to Google. This leads to other questions. Namely, “Does the STT system do this too?” It doesn’t. Vosk runs entirely on your PC. There are no cloud services involved. But of course, your assistant needs to know things in order to assist you.

One of the simpler functions is to produce a weather report. For this to work, the assistant needs to relay your question to the weather provider’s API server. The provider can reasonably assume that you normally aren’t interested in the weather for places you do not live. So the server can derive where that you live based on what city you most frequently inquire about and it can collaborate its deduction based on your device’s IP address.

Consequently, if you configure a service in your PVA’s config, you should ask yourself if this service will cause a privacy problem for you. Many PVA functions won’t because they work locally or they use services under your control (the CalDAV and CardDAV address book services, for example). The same is true for the upcoming IMAP feature. You will use the same email provider that your email app is already configured to use. So there are no extra concerns for the IMAP feature. But what happens if you decided to use GTTS because these simple text fragments are “no big deal” and the PVA reads out loud the incoming email? Here the decision for a TTS engine gets more and more important.

One of PVA’s functions is playing music on command. By itself, this function may not seem concerning. However, an upcoming feature might change this. It will be able to tell what you want to listen to by the use of abstract requests like “Jazz”. At the moment, the PVA searches for this term in filenames and metadata it found in your MP3 archive. In the future, it will have a local track list of all the audiophile wishes you had in the past and it will produce a TOP song list for the search term.

It will write every file you added to the playlist to a database and it will count how many times a match to your abstract request is found and play the song(s) with the best score. On the plus side, you get your favorite music. But what happens if an external plugin or hacked app takes this list and exfiltrates the data to someone who pays for this kind of information?

Now this feature becomes a privacy concern. There is no great risk at the moment since this feature needs to be enabled and, for now, PVA is not widespread enough to be a target. But this may change and you should be aware of these kinds of privacy concerns before they become a problem.

As a best effort to address such privacy concerns, PVA will disable features that require external communication by default. So if you use the base installation, there should be very few privacy concerns. There is one known exception — all texts sent to the PVA app are recorded in ~/.var/log/pva.log. This should make it easier to find flaws in the STT engine and track down other problems.

Always keep in mind that privacy can also be undermined by third-party add-ons.

What can you expect from your assistant?

PVA auto-configures itself on first start-up with a basic configuration. For example, it adds the default paths from the freedesktop.org specs to all your pictures, music, documents and videos. It creates a local cache and config directory where you can place your version of the config files, add new ones, or overwrite existing ones. Usually user customizations are added to the config. But you can overwrite existing values. Before we dig deeper, let’s present some more of PVA’s features.

The Weather Report app is a classic. No assistant would be complete without it. 🙂 All it needs to know is the name of your hometown. The weather provider used is wttr.in. You can point your browser at this URL to find for your city’s unique identifier. You have no idea how many “Neustadt” exists in Germany alone. 😉 Because it is a webservice, you don’t need to install anything. It works out-of-the-box using cURL.

Asking your PVA what time it is, is also a classic and it works out of the box. You can also ask your PC how it feels: “Carola, what is the actual load?” Or, more abstractly, “Carola, how do you feel?” 😉

For playing audio, PVA uses QMMP by default. It comes with an easy to use command line interface and a rich feature set. You will need to install this app before you can use it. Luckily, Fedora Linux ships this. QMMP gives you remote control over loudness, track number, track-position, playback, and it gives us information about what is currently playing. So you can ask your PVA what is playing when it is playing random tracks.

Controlling QMMP by voice is one of the features I cannot do without again. I often end up in situations where I have full-screen windows with complex code on the screen. If you loose your focus, you loose your workflow. Developers call this “being in the flow” or “in the tunnel”. Here, voice control comes in very handy. You do not need to divert your focus from your work. You can just say what you want and it “magically” it happens! 😉

The phone-call feature works in a similar way. You can now ask your SIP software to make a call to a contact in your CardDAV address book without diverting your focusing from your work. As this is a complex process, it needs a little extra care. There is a special internal function for handling the parsing of the command sentence. “Carola, call Andreas” is enough to initiate a call. The first match in the address book will be called. If you know more than one person with the same name, I hope they have nicknames. 😉 Also, since one contact might have multiple phone numbers (e.g. for home and for work), you can specify which number should be called: “Carola, call Andreas at work.”

Even if it doesn’t look like a complex problem, consider which of the words the PVA receives are part of the name and which are just binding words like “at” in the above example? It is not that easy to determine. So we need to follow a precise syntax. But it needs to be natural or humans will not use it. Another thing that is important when interacting with humans is that they tend to alternate their command structures. Parsing a human sentence is more complex for a computer than you might think. It’s natural for you, but the opposite of logic for a computer. Keep this in mind as you read further. It is a reoccurring challenge.

Another example of when voice control can come in handy is controlling video playback is while you exercise. You are likely not in reach of a mouse or a remote (KDE Connect) nor do you want to stop your work out just because someone asks you something. With voice control, you can ask the PC to pause playback and then ask it to resume after you have answered the question or otherwise addressed the problem.

For audio and video players that offer a MPRIS2 interface on DBUS, you can control them on the spot without adding the CLI (command line interface) commands to your config. Based on MPRIS2 you can even control Netflix or YouTube in your Firefox browser. OK, you can’t currently choose the track to watch. But you can change the volume and (un)pause the playback. And all of this can be done with the same set of commands in your config.

There are many situations where voice control is superior or even necessary. What I haven’t told you yet is that the first device I deployed PVA to was a PinePhone. Smartphones can be used for many things. You might use it as an MP3 player while you drive or as a navigational tool. It doesn’t work with Gnome Maps (yet). But controlling a PinePhone via voice while driving will be more and more important in the Linux community. So hopefully further advancements will be made in this area. Fun fact/tip, if you use it as an MP3 player, don’t make it too loud. Or better yet, use an external speaker system[6].

If you use Thunderbird to manage your email, it is capable of composing and sending an email using only CLI arguments. Consequently, your PVA can compose and send email using Thunderbird. All you need to do is to tell your PVA the recipient, the subject, and then dictate the content of the body. It will also do some minor interpretation for you. While I still write my emails by hand, I can imagine situations where it could be useful. I did not have an opportunity to work with a disabled person to test this method of email composition. But it might be interesting.

The PVA can also be handy for short reminders. You can tell your PVA when and what it should remind you about. For example, “Carola, remind me in 10 minutes to check the kitchen” or, “Carola, remind me at 10 to call Andreas”. The PVA will respond if it understood and acknowledge your reminder.

The best comes last. With Twinkle, your PVA can take a call and interact with the caller just as it does with you. One thing I have not explained yet is that your PVA requires authorization codes for vital or potentially dangerous operations. I find it reminiscent of a scene from “Star Trek”. 😉

“Carola, reboot PC.”
“Authorization code alpha is needed to perform this operation.”
“Carola, authorization code alpha three four seven.”

And if the code is correct, the requested action will proceed. Requiring these authorization codes helps to alleviate the fear that someone might hack your PC through the PVA and cause trouble. Though about the worst that could happen at the moment is that you could unwillingly send spam to someone or your PC might be left playing music all day long. 😉 However, if you have home automation running and configured, it is probably better not to have Twinkle answer the phone.

Let’s take a look behind the curtain

This list is long and detailed. So I will focus on some basics.

PVA comes with a rudimentary form of hard-coded human responses. You can modify and expand them as you like. But there is no intelligence in them. You can, however, build reaction chains that are so long that a normal human cannot detect the repeating phrases.

Here are two examples. Let’s ask the PVA for its name.

reaction:”what is your name”,””,”my name is %KEYWORD”

Here is a more complex example that uses the word “not”.

reaction:”this works”,”not”,”of course it does”
reaction:”this works not”,””,”uh oh, please contact my developer”

As the absence of the word “not” is crucial to the meaning of a sentence, reactions contain “positive” and “negative” terms to work. The rule is as follows.

Positive words MUST be inside the sentence, negative words MUST NOT be inside the sentence. In developer terms it can be written as “if ( p && !n ) do …”.

If your reaction texts give a human a new clue what to say next and you can anticipate this, then it is possible to build complex reaction chains that will simulate a conversation. I have even heard from people using this feature that they like talking to their PC (and these are not your stereotypical nerds 😉). As you can use the same trigger for multiple reactions, alternative chains are possible.

Starting applications

Part of the basic functionality is to start the apps that you’ve named. In the beginning, there was a fixed list of apps that was hard-coded. But now, you can extend this via the config. Let’s take a quick look at it.

app:”office”,”openoffice4″
app:”txt”,”gedit”
app:”pdf”,”evince”
app:”gfx”,”gnome-open”
app:”mail”,”thunderbird”

The corresponding voice commands would be “Carola, start mail”, “Carola, open mail” or, in free-form, you could say, “Carola, start Krita” (Krita is an OpenSource paint app that is available on Fedora Linux). You can configure several alternative versions of the command sentences. These can be regular expressions (regex) or multiple entries in the config file. These apps are also used in complex commands like searching for files and opening the resultant set with an app. For example, “Carola, search pictures of Iceland and open them with Krita.” The previous command would cause the PVA to search in your configured picture paths for filenames matching “iceland” and then open them with Krita. This works for all apps as long as their launchers accept filenames as arguments on their CLI. Even if this isn’t the case for your favorite app, you might still be able to write a small “wrapper” script in Bash and then use that script as the app target for the PVA.

Via voice command, you can switch apps out for a configured alternative on the fly.

alternatives:”firefox”,”web”,”firefox”
alternatives:”google chrome”,”web”,”google-chrome”
alternatives:”chromium free”,”web”,” chromium-freeworld”
alternatives:”chromium privacy”,”web”,” chromium-privacy-browser”
alternatives:”openoffice”,”office”,”openoffice4″
alternatives:”libreoffice”,”office”,”libreoffice”

By using the “use {alternative}” syntax you select what you want to use next. For example, “Carola use Firefox” or “Carola use Chromium free”. It’s working for any app in the app list. But how are these commands defined?

command:”start”,”STARTAPP”,”app”,””
command:”open”,”OPENAPP”,”app”,””

Quite simple: “Carola, start Firefox app” will start Firefox. “Carola, start Firefox” would also work because the term “app” is filtered out.

Next is the positive and negative list of words again. Here is the reaction syntax.

command:”how is the weather”,”CURRENTWEATHERNOW”,””,”tomorrow”
command:”how will the weather be”,”CURRENTWEATHERNEXT”,””,”tomorrow”
command:”how will the weather be tomorro
w”,”CURRENTWEATHERTOMORROW”,””,””

The commands in the second column are some of PVA’s internal function names. They are coded internally because processing the result can be tricky. You can, however, outsource those commands to an external Bash script. Below is an example that shows how to call a custom Bash script.

replacements:”h d m i”,”hdmi”
replacements:”u s b”,”usb”

command:”switch .* to kopfhörer”,”EXEC:pulse.outx:x%0x:xhdmi”
command:”switch .* to lautsprecher”,”EXEC:pulse.outx:x%0x:xdefault”
command:”switch .* to .* now”,”EXEC:pulse.outx:x%0x:x%1″

The last of the above commands will switch the output device of a named (first “.*”) running app in pulseaudio to the named (second “.*”) device. As you can see, it works using regular-expression-like syntax. The syntax is not, however, fully-featured. All three of the above commands call the script pulse.out with two parameters. That is, “pulse.out <procname> <devicename>”. Now there is no need to start PAVUControl anymore. Instead, you can just grab your headset and tell your PC to use it. 🙂

There is no limit to the number of .* wildcards in the command or execution part. Feel free to code a response for something like, “Carola, switch on the light in the kitchen.”

command:”switch .* the light in .*”,”EXEC:smarthomex:x%0x:x%1″

If you are wondering about those “x:x” character sequences in the execution part, those are being used to escape whitespaces because they tend to appear in filenames.

Oops, it sent your mail to Hermine instead of Hermann

All these voice commands only work correctly when the STT system works flawlessly. Of course, it often does not. Do not have false hopes. It’s not perfect. However, PVA can auto-correct some common errors by configuring replacements.

PVA can correct simple mistakes.

replacements:”hi länder”,”highlander”
replacements:”cash”,”cache”
replacements:”karola”,”carola”

Or, it can perform context replacements. These are only done if a command has been recognized.

contextreplacements:”STARTAPP”,”kreta”,”krita”
contextreplacements:”STARTAPP”,”konfig”,”config”
contextreplacements:”ADDTITLE”,”föge”,”füge”

Shown above is the entry “Krita” which sounds like the German word “Kreta” which is a Greek island. STT Vosk likes “Kreta”. So we need to replace this. But not every time. If we perform a web search for “Kreta”, it would be counter productive to replace it with “Krita”. You can add simple replacements to the config. I suggest that you use the user config for these because other users my encounter different problems.

If you don’t know why a command is not being recognized correctly, you can the always check the log at ~/.var/log/pva.log.

Contribution

If you want to contribute to this project, feel free to do so. It is available on Github[1]. Since Vosk now has support for eighteen languages, translating the texts to different languages would be a great place that a contributor could get started.

To get PVA installed on Fedora Linux, it is required to rebuild Vosk and its libraries with Fedora sources. We tried to do so earlier this year, but we failed when we ran into some exotic mathlib dependencies that we couldn’t get to compile on Fedora Linux. We are hoping that a good, skilled C developer could solve this problem and get those resulting packages reviewed by Fedora packagers. 🙂

I hope I have awoken some interest from our dear readers. The world of PVA needs your awesome configs! 🙂

Best regards,
Marius Schwarz

References

[1] https://github.com/Cyborgscode/Personal-Voice-Assistent

[2] https://alphacephei.com/vosk

[3] https://github.com/numediart

[4] https://marytts.github.io

[5] Available from the Fedora Linux repositories:

  • dnf install gtts

[6] http://static.bloggt-in-braunschweig.de/Pinephone-PVA-TEST1.mp4

[7] https://cloud.google.com/text-to-speech

[8] https://cloud.google.com/text-to-speech/docs/reference/rest