FAQs and Guides – Page 2

Posted on June 3, 2022 by — Leave a comment

Fedora Linux editions part 1: Official Editions

Fedora Linux provides several variants to meet your needs. You can find an overview of all the Fedora Linux variants in my previous article Introduce the different Fedora Linux editions. This article will go into a little more detail about the Fedora Linux official editions. There are five editions — Fedora Workstation, Fedora Server, Fedora IoT, Fedora CoreOS, and Fedora Silverblue. The Fedora Linux download page currently shows that three of these are official editions and the remaining two are emerging editions. This article will cover all five editions.

Fedora Workstation

If you are a laptop or desktop computer user, then Fedora Workstation is the right operating system for you. Fedora workstation is very easy to use. You can use this for daily needs such as work, education, hobbies, and more. For example, you can use it to create documents, make presentations, surf the internet, manipulate images, edit videos, and many other things.

This Fedora Linux edition comes with the GNOME Desktop Environment by default. You can work and do activities comfortably using this appearance concept. You can also customize the appearance of this Fedora Workstation according to your preferences, so you will be more comfortable using it. If you are a new Fedora Workstation user, you can read my previous article Things to do after installing Fedora 34 Workstation. Through the article, you will find it easier to start with Fedora Workstation.

More information is available at this link: https://getfedora.org/en/workstation/

Fedora Server

Many companies require their own servers to support their infrastructure. The Fedora Server edition operating system comes with a powerful web-based management interface called Cockpit that has a modern look. Cockpit enables you to easily view and monitor system performance and status.

Fedora Server includes some of the latest technology in the open source world and it is backed by an active community. It is very stable and reliable. However, there is no guarantee that anyone from the Fedora community will be available or able to help if you encounter problems. If you are running mission critical applications and you might require technical support, you might want to consider Red Hat Enterprise Linux instead.

More information is available at this link: https://getfedora.org/en /server/

Fedora IoT

Operating systems designed specifically for IoT devices have become popular. Fedora IoT is an operating system created in response to this. Fedora IoT is an immutable operating system that uses OSTree Technology with atomic updates. This operating system focuses on security which is very important for IoT devices. Fedora IoT has support for multiple architectures. It also comes with a web-based configuration console so that it can be configured remotely without requiring that a keyboard, mouse or monitor be physically connected to the device.

More information is available at this link: https://getfedora.org/en/iot/

Fedora CoreOS

Fedora CoreOS is a container-focused operating system. This operating system is used to run applications safely and reliably in any environment. It is designed for clusters but can also be run as a standalone system. This operating system has high compatibility with Linux Container configurations.

More information is available at this link: https://getfedora.org/en/coreos/

Fedora Silverblue

This edition is a variant of Fedora Workstation with an interface that is not much different. However, the difference is that Fedora Silverblue is an immutable operating system with a container-centric workflow. This means that each installation is exactly the same as another installation of the same version. The goal is to make it more stable, less prone to bugs, and easier to test and develop.

More information is available at this link: https://silverblue.fedoraproject.org/

Conclusion

Each edition of Fedora Linux has a different purpose. The availability of several editions can help you to get an operating system that suits your needs. The Fedora Linux editions discussed in this article are the operating systems available on the main download page for Fedora Linux. You can find download links and more complete documentation at https://getfedora.org/.

Posted on March 21, 2022 by — Leave a comment

Fedora Workstation’s State of Gaming – A Case Study of Control (2019)

Back in the day, it used to irk me as to how GNU/Linux[1] distributions could not be even considered to be in the proximity of video games enthusiasts – less because of the performance of the video games themselves and more because of how inconvenient it could be for them to set it all up. Admittedly, it had been quite a while since an avid video games fan like me did that, so it was almost a no-brainer for me to try it out and see if things have changed. What I ended up finding surprised me – I like to think that it would be just as pleasing to both enthusiasts who have been playing video games on GNU/Linux distributions and to newcomers who have been scoping this, alike.

On a testing bench using an AMD RDNA2-based[2] GPU, the video game was configured to the highest possible graphical preset[3] to really stress the hardware into performing as much as its limiting factor. If the RDNA2 architecture reminds you of something, allow me to share that it is what forms the foundation of the GPU that no other than the widely acclaimed Steam Deck[4] makes use of. For that matter, if you factor in some performance scaling with respect to the handheld nature of the device and the optimized Proton compatibility layer, this article can be representative of what the Steam Deck is capable of when you use Fedora Workstation[5] as a platform of your choice for playing your favourite video games.

**Figure 1** – *GNOME Software* helps to install *Steam* conveniently

To have an apples to apples comparison, we set up two environments – one with Windows 10 21H2[6] and one with Fedora Workstation 35. On the former, I installed MSI Afterburner[7] and ensured that the graphics drivers are up-to-date while I did not have to bother doing the same on the latter as they came preinstalled. The only extra thing that I did was to configure the Lutris v7.1 runner[8] after clicking my way through installing Lutris[9] and MangoHUD[10] from GNOME Software[11]. It is downright astonishing how much you can do these days on GNU/Linux distributions without actually having to interact with the command line, making the entry barrier very low and welcoming.

**Figure 2** – *GNOME Software* helps to install *Lutris* conveniently

Before we get into some actual performance testing and comparison results, let me talk a bit about the video game that is at the centre of the case study. Control[12] is an action-adventure video game developed by Remedy Entertainment[13] and published by 505 Games[14]. The video game is centred around a fictitious organization about paranormal activities and takes inspiration from the likes of the SCP Foundation[15]. It is a well-optimized video game that exhibits great graphics and is a showcase of what the underlying hardware is capable of. I ran tests on both DirectX 11[16] and DirectX 12[17] versions of the video game with their compatibility layers[18], DXVK[19] and VKD3D[20], respectively.

**Figure 3** – *Lutris* configured to play *Control (2019)* using the Wine runner

Following are the results of the tests. I made use of OBS Studio[21], which is available as both an installer binary and as a package in the RPM Fusion[22] repositories, to record around 15 seconds of in-menu gameplay and around 60 seconds of in-game gameplay. As the video game does not have any intrinsic benchmarking tool, the footage had to be broken down into segments of equal time periods to be able to pick up performance statistics on CPU usage, GPU usage and framerate. Please do note, even when OBS Studio introduces a certain overhead to the performance, the comparison still remains valid as in both the platforms the recording software is configured identically.

Metrics

Framerate
- In the menus

Figure 4 – Framerate in the menus

In the game

Figure 5 – Framerate in the game

CPU usage
- In the menus

Figure 6 – CPU usage in the menus

In the game

Figure 7 – CPU usage in the game

GPU usage
- In the menus

Figure 8 – GPU usage in the menus

In the game

Figure 9 – GPU usage in the game

Please feel free to let your inner enthusiast loose in the statistics and try sharing as many performance differences as you have inferred so far in the comments section below. In the meanwhile, allow me to share mine –

With DXVK (DirectX 11), the loss of average in-menu framerate is around 19.87% and the same for average in-game framerate is barely 6.26%. DXVK is almost at the stage where a blind test of framerate smoothness could potentially confuse anyone as to which platform runs natively.
With VKD3D (DirectX 12), the loss of average in-menu framerate is barely 8.67% and the same for average in-game framerate is around 24.51%. VKD3D seems to be steadily catching up and very soon enough, video games would be able to run with minimal loss of performance.
With DXVK, there is only 1.40% of additional average CPU usage in the menus and around 17.88% of the same in the game. Closing this gap would help save battery life on handheld devices.
With VKD3D, the average CPU usage in the menus is around 1.47% less than the equivalent Windows platform and the same in the game is 1.62% more. VKD3D is a great choice for handheld devices.
With DXVK, the average GPU usage in the menus is around 13.40% more than that on Windows and the same in the game is around 1.04% more, making it more efficient in geometry rendering and less so in sprites.
With VKD3D, the average GPU usage in the game is around 8.13% more than that on Windows and the same in the game is around 9.34% less, thus helping save battery on handheld devices running these video games.
The CPU governor[23] makes a marginal difference in performance and hence, it is something that can be left alone untweaked. The marginal difference noticed can also be considered in the margin of error.
Fedora Workstation uses fewer system resources out of the box and hence, can easily dedicate a huge chunk of those to the video game in question but the same is not possible in Windows 10 21H2.

For someone who looked into GNU/Linux distributions as a platform for using interactive and entertainment software applications without having any fancy hardware requirements, these results almost feel like a breath of fresh air. With Valve[24] working on strengthening Proton[25] and other communities working on great solutions like Bottles[26] and Lutris, gaming on GNU/Linux distributions is no longer an elusive dream. Things are only going to get better with a great number of video games running at near-native performance as we go on. I do not know for certain if 2022 would be the year of Linux Desktop or not, but if you ask me whether 2022 would be the year of Linux Gaming – I would answer that with a resounding yes. Let me know your thoughts down below!

Appendix

Highest possible graphical preset[3]
Configuration differences[27]
Performance measurements in the menus[28]
Performance measurements in the game[29]

References

Posted on February 16, 2022 by — Leave a comment

How I Customize Fedora Silverblue and Fedora Kinoite

Hello everyone. My name is Yasin and I live in Turkey. I am 28 years old and have used Fedora Silverblue for two months and I am an active Fedora Kinoite user. I want to share the information I’ve learned in the process of using the systems. So I’ve decided to write this article. I hope you like it. Let’s get started.

When one says Fedora Linux, the first edition that comes to mind is Fedora Workstation. However, do not overlook the emerging editions Fedora Silverblue (featuring the GNOME desktop environment) and Fedora Kinoite (featuring the KDE desktop environment). Both of these are reprovisionable operating systems based on libostree. They are created exclusively from official RPM packages from the Fedora Project. In this article, I will demonstrate some common steps you might take after a clean installation of Fedora Silverblue or Fedora Kinoite. Everything listed in this article is optional. Exactly what you want to install or how you want to configure your system will depend on your particular needs. What is demonstrated below is just meant to give you some ideas and to provide some examples.

Disclaimer: Packages from Flathub, RPM Fusion, the Copr build system, GitHub, GitLab, et al. are not managed by the Fedora release team and they do not provide official software builds. Use packages from these sources at your own risk.

System upgrades

Fedora Linux in particular releases feature updates and security updates quite often. So you will want to run the below command regularly to keep your system up-to-date. Open the terminal and enter the following command. Afterwards, restart the computer so the changes will take effect.

$ rpm-ostree upgrade

If you want to preview which packages will be updated, use the follow command first.

$ rpm-ostree update --preview

It is also possible to configure automatic updates by editing the rpm-ostreed.conf file as demonstrated below.

$ sudo nano /etc/rpm-ostreed.conf

Change AutomaticUpdatePolicy to check. Then save the change and quit the editor. After that you need to reload rpm-ostree and enable the automatic timer.

$ rpm-ostree reload
$ systemctl enable rpm-ostreed-automatic.timer --now

Adding Flatpak remotes and other third-party repositories

Fedora Silverblue and Fedora Kinoite come preloaded with the basic Fedora Linux repos. In addition, you might want Flatpak, RPM Fusion or some Copr repos.

Flathub remotes

Flatpak is at the top of the list of ways to install applications on Fedora Silverblue and Fedora Kinoite because it is container-based and it does not require a reboot after installation. To add some remote software libraries and try it out, open the terminal again and enter the following commands.

Fedora Flatpaks remote:

$ flatpak remote-add --if-not-exists fedora oci+https://registry.fedoraproject.org

Flathub remote:

$ flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Flabhub Beta remote:

$ flatpak remote-add --if-not-exists flathub-beta https://flathub.org/beta-repo/flathub-beta.flatpakrepo

KDE nightly remote:

$ flatpak remote-add --if-not-exists kdeapps --from https://distribute.kde.org/kdeapps.flatpakrepo

GNOME nightly remote:

$ flatpak remote-add --if-not-exists gnome-nightly https://nightly.gnome.org/gnome-nightly.flatpakrepo

After the repositories are added, you need to enter the code below in order to update the application catalog in the GNOME Software and Discover stores. In this way, you will be able to manage applications directly from the store without going to flathub.org.

$ flatpak update --appstream

After that, you can use the store to update Flatpak applications, or if you want to update directly from the terminal, you can enter the code below.

$ flatpak update

If you want to see all installed Flatpaks:

$ flatpak list

RPM Fusion repos

Another remote software library you can add is RPM Fusion. To add it on Fedora Silverblue or Fedora Kinoite, open the terminal, enter the following commands and restart.

$ sudo rpm-ostree install https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-$(rpm -E %fedora).noarch.rpm

$ sudo rpm-ostree install https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-$(rpm -E %fedora).noarch.rpm

Copr repos

Copr repos are yet another source of applications that can be installed on Fedora Silverblue and Fedora Kinoite. To add the repos, enter commands in the following form.

$ sudo ostree remote add <name-of-repo> <repository-url>

Example (Heroic Games launcher repo):

$ sudo ostree remote add heroic-games-launcher https://download.copr.fedorainfracloud.org/results/atim/heroic-games-launcher/fedora-$releasever-$basearch/

If you want another option, you can download the repository configuration file from Copr‘s own site and put it in the /etc/yum.repos.d folder.

Examples of popular Flatpak applications

Libre Office

$ flatpak install flathub org.libreoffice.LibreOffice

Lutris

$ flatpak install —user flathub-beta net.lutris.Lutris//beta

Steam

$ flatpak install flathub com.valvesoftware.Steam

VLC

$ flatpak install flathub org.videolan.VLC

Firefox

$ flatpak install flathub org.mozilla.firefox

Note: Fedora Firefox normally comes preloaded with Fedora Silverblue and Fedora Kinoite. However, the Flatpak version of Firefox has more comprehensive codec support.

Installing the Nvidia driver and a specific kernel

If you have installed RPM Fusion repositories, you can install the Nvidia driver by entering the code below and restarting the computer so the changes will take effect.

$ sudo rpm-ostree install akmod-nvidia xorg-x11-drv-nvidia

If you are using the Nvidia System Management Interface (nvidia-smi) or CUDA:

$ sudo rpm-ostree install akmod-nvidia xorg-x11-drv-nvidia-cuda

If you want to install specific kernel, you can always download a kernel from Koji and install it on Fedora Silverblue or Fedora Kinoite using the following command:

$ sudo rpm-ostree override replace ./kernel*.rpm

If you want to install multiple kernels, you will need to pin your deployment by issuing the ostree admin pin 0 command then use the same code above. After restarting, if you pin the new kernel, then you will have two deployments with specific kernels. Remember that you must update them individually because you cannot pin two deployments at the same time.

Toolbx

The Toolbx utility is used primarily for CLI apps, development and debugging tools, etc. However, you can install supported any operating system. In this article, I will give an example of Fedora 35 Workstation installation and use. Fedora Silverblue and Fedora Kinoite come preloaded with Toolbx. So you can start directly.

First, create a toolbox.

$ toolbox create

When the above is complete, enter:

$ toolbox enter

When you see the code that starts with toolbox, then you are in the container operating system. You can list the container(s) by means of:

$ toolbox list

If you want to remove the container, enter:

$ toolbox rmi <container name>

If you need more help, enter:

$ toolbox --help

Thanks to Toolbx, your main operating system will never break. You can pretend to be on Fedora Workstation, install and delete packages, and do things you cannot do on the libostree-based host system. Let’s illustrate with a few examples.

Many users use Toolbx for their developer tools. But it is a really useful tool for regular users as well. For example, you can install Xtreme Download Manager and combine it with Firefox to download content such as music and videos from the internet. It will make your job even easier if you download the file manager before downloading XDM. Now that you are in Toolbx, try installing Nautilus.

$ sudo dnf install nautilus

After that, you can get XDM from here:

https://github.com/subhra74/xdm/releases/download/7.2.11/xdm-setup-7.2.11.tar.xz

Start Nautilus with sudo nautilus while in Toolbx. Then unarchive XDM, open the folder, right click on some empty space and select Open in Terminal. Then enter the below code.

$ su -c ./install.sh

Congratulations! You have successfully installed XDM. After that you will need to open XDM, install Firefox and then open XDM again. Finally, you will want to make the XDM plugin available for Firefox.

$ sudo xdm

$ sudo dnf install firefox

$ sudo firefox

A few more example things that you could do in Toolbx include:

Add the repositories from Fedora Silverblue or Fedora Kinoite using the terminal. Alternatively, you could copy the repo files from /etc/yum.repos.d in Fedora Silverblue or Fedora Kinoite to /etc/yum.repos.d in Toolbx.

Keep the container updated by running sudo dnf update periodically. (Tip: For faster downloads, you might want to try adding the fastestmirror=1 and max_parallel_downloads=10 options to the container’s /etc/dnf/dnf.conf file.)

Use the dnf history command to see what changes you’ve made to the container.

You could install multimedia codecs and Windows fonts. But it’s not necessary because rpm-ostree can handle them and the google-croscore-fonts and liberation-fonts are both designed to be compatible with the most common MS fonts.

Layering packages

The package layering method modifies the existing installation. You can permanently install almost any RPM package on Fedora Silverblue or Fedora Kinoite. However, you should only layer packages that you consider essential because, after the layering is complete, you will need to reboot the system before you will be able to use the package. For most packages, I recommend using Toolbx.

Package layering is almost identical to installing a RPM package on Fedora Workstation. It’s just rpm-ostree replacing dnf. For example:

$ rpm-ostree install htop

If you want to remove layered packages:

$ rpm-ostree uninstall htop

If you want to see the all layered packages:

$ rpm-ostree status

If you want to remove all layered packages:

$ rpm-ostree uninstall --all

If you are wondering which packages I’ve chosen to layer on my libostree systems, here are my favorites.

tlp, tlp-rdw: helps to reduce the battery use on laptops

stacer: system optimizer and monitoring

WoeUSB: for preparing bootable Windows ISO images

unrar: for extracting and viewing RAR archives

Gaming

Some ways of playing games on Fedora Silverblue or Fedora Kinoite include the following.

Using platforms (Steam, Lutris, itch.io, GOG and other emulators)

Using compatibility tools (Wine, Proton and others)

Native Linux games (These games can be found in official or third-party repositories; or on their official website)

Other (Virtualbox, web browser games, etc.)

People are often advised to play games designed to run on Linux or Windows using Proton on Steam. However, not all Windows games are compatible with Proton; especially online games with cheat protection software. So it is useful to check the site below before installing the game.

https://www.protondb.com/

In Fedora Silverblue or Fedora Kinoite, there are two ways to install Proton.

From Flathub (using the terminal):

$ flatpak install com.valvesoftware.Steam.CompatibilityTool.Proton

From GitHub (manually):

https://github.com/GloriousEggroll/proton-ge-custom

My advice is to use the proton-ge-custom version (Gloruious Eggroll) because it contains extra patches and fixes for many popular games. You can read about how to install proton-ge-custom and how to activate it on Steam in the README.md file in the above GitHub repo.

If you do not want to use an online platform, it is possible to play the game using Wine. But you need to go to Wine‘s official site and read the reports about the game or try it yourself to see if the game works. Also, don’t think of it as just a game engine. Wine can run a wide verity of Windows programs. So how do you install Wine? Unfortunately, Wine cannot be directly installed on Fedora Silverblue or Fedora Kinoite as a layered package due to rpm-ostree’s lack of 32-bit support. It is possible, however, to install Wine using some indirect methods. The Winepak repo is dead now. So I’ll skip that.

Method 1: Use a Flathub application as a Wine launcher.

Lutris, Bottles, ProtonUp-Qt and finally Phoenicis PlayOnLinux

Method 2: Install Wine or Lutris in Toolbx with Steam.

$ sudo dnf install wine lutris steam

Method 3: Partially install Wine on rpm-ostree.

$ rpm-ostree install wine-core wine-core.i686 lutris

There are other methods of playing games on Linux. Native Linux games, for example, are available in many repositories. Browser games are also easy to access. Installing Windows in a virtual machine is another method. However, while a virtual machine may work for simpler games, I do not recommend it for games that require a lot of processing power.

Other tips and suggestions

In this final section, I would like to mention a few more things that do not depend on anything mentioned earlier in this article.

rpm-ostree tips

You can use the override sub-command to manage base packages. For example, to remove the pre-loaded Firefox:

$ rpm-ostree override remove firefox

If you want to remove all overlays, overrides and initramfs:

$ rpm-ostree ex reset

rpm-ostree provides an experimental live update feature so that you can avoid rebooting after installing packages.

$ rpm-ostree install --apply-live htop

Since you are on Fedora Silverblue or Fedora Kinoite, switching systems or updating to rawhide can be done with just a few commands. Also, reverting is easier than ever.

Substitute system with kinoite or silverblue in the below examples.

Switch systems:

$ rpm-ostree rebase fedora/35/x86_64/system

Upgrade to rawhide:

$ rpm-ostree rebase fedora/rawhide/x86_64/system

Rollback to a previous version:

$ rpm-ostree rollback fedora/35/x86_64/system

Listing packages

On Fedora Workstation you can use dnf to list the packages in the repositories. But this does not work on Fedora Silverblue or Fedora Kinoite. So how do you do it? If you want to list the installed RPM packages on your system, you can use the following command.

To list the installed RPM packages:

$ rpm -qa

However, if you want to list the packages in the repositories, you must either layer the dnfdragora package or enter Toolbx. Then you can use the following dnf commands.

To list all RPM packages (both installed and available):

$ dnf list

To search for a specific RPM package:

$ dnf search <packagename>

Miscellaneous tips

When you want to install an application, first look at the Flatpak remotes. If it’s not there, use Toolbx. Finally, if you cannot run it in Toolbx, layer the package. If you still cannot get what you want to install, the last option is to install Windows in a virtual machine or on a separate partition or hard drive and configure multi-booting.

I do not recommend using any other repositories besides the Fedora, RPM Fusion, and Copr repositories unless required.

Remember that only KDE (Fedora Kinoite) and GNOME (Fedora Silverblue) desktop environments are officially supported by the Fedora Project.

If you want your system to stay the same speed, you can try to avoid doing too much customization (global theme, Conky, Plank, etc.)

For Fedora Kinoite users: To add the option to open folder or file as root in the Dolphin file manager on the right click, install the “Dolphin as root” plugin from the Discover application.

If you want to preview video files without opening them, you can enter: $ rpm-ostree install ffmpegthumbs kffmpegthumbnailer.
Note: For now, do not install Dolphin from Flatpak because it replaces the preinstalled Dolphin on the system. With the Flatpak version of Dolphin, you will not be able to preview videos because it does not contain the packages mentioned above

For Kinoite users: If you want to install a global theme, the installation from the system settings can sometimes cause problems. Instead, download the global theme file from the KDE Store and enter: $ kpackagetool5 -i /home/username/theme folder

Courtesy of Daniel’s guidance on Fedora Discussion, it is possible to install Windows fonts without any package layering.

Courtesy of Badhshah, the following can be used to enable hardware video acceleration if you have an Intel Graphics 4600 chipset: $ rpm-ostree install intel-gpu-tools libva-intel-driver libva-intel-hybrid-driver libva-utils libva-vdpau-driver libvdpau-va-gl mpv vdpauinfo

Conclusion

Dear friends, you have come to the end of this article. If you have anything you want to add to this topic or if you have questions, I am waiting for you in the comments section below. Also, special thanks to Badhshah, Timothée Ravier and Daniels for helping me with some information in preparing this article. Finally, if you want to contribute to Fedora Silverblue or Fedora Kinoite or get more information, check the links below. Thank you for reading.

https://docs.fedoraproject.org/en-US/fedora-silverblue/

https://docs.fedoraproject.org/en-US/fedora-kinoite/

Posted on December 30, 2020 by — Leave a comment

Choose between Btrfs and LVM-ext4

Fedora 33 introduced a new default filesystem in desktop variants, Btrfs. After years of Fedora using ext4 on top of Logical Volume Manager (LVM) volumes, this is a big shift. Changing the default file system requires compelling reasons. While Btrfs is an exciting next-generation file system, ext4 on LVM is well established and stable. This guide aims to explore the high-level features of each and make it easier to choose between Btrfs and LVM-ext4.

In summary

The simplest advice is to stick with the defaults. A fresh Fedora 33 install defaults to Btrfs and upgrading a previous Fedora release continues to use whatever was initially installed, typically LVM-ext4. For an existing Fedora user, the cleanest way to get Btrfs is with a fresh install. However, a fresh install is much more disruptive than a simple upgrade. Unless there is a specific need, this disruption could be unnecessary. The Fedora development team carefully considered both defaults, so be confident with either choice.

What about all the other file systems?

There are a large number of file systems for Linux systems. The number explodes after adding in combinations of volume managers, encryption methods, and storage mechanisms . So why focus on Btrfs and LVM-ext4? For the Fedora audience these two setups are likely to be the most common. Ext4 on top of LVM became the default disk layout in Fedora 11, and ext3 on top of LVM came before that.

Now that Btrfs is the default for Fedora 33, the vast majority of existing users will be looking at whether they should stay where they are or make the jump forward. Faced with a fresh Fedora 33 install, experienced Linux users may wonder whether to use this new file system or fall back to what they are familiar with. So out of the wide field of possible storage options, many Fedora users will wonder how to choose between Btrfs and LVM-ext4.

Commonalities

Despite core differences between the two setups, Btrfs and LVM-ext4 actually have a lot in common. Both are mature and well-tested storage technologies. LVM has been in continuous use since the early days of Fedora Core and ext4 became the default in 2009 with Fedora 11. Btrfs merged into the mainline Linux kernel in 2009 and Facebook uses it widely. SUSE Linux Enterprise 12 made it the default in 2014. So there is plenty of production run time there as well.

Both systems do a great job preventing file system corruption due to unexpected power outages, even though the way they accomplish it is different. Supported configurations include single drive setups as well as spanning multiple devices, and both are capable of creating nearly instant snapshots. A variety of tools exist to help manage either system, both with the command line and graphical interfaces. Either solution works equally well on home desktops and on high-end servers.

Advantages of LVM-ext4

Show the relationship of LVM-ext4 filesystem to hard-drive partitions and mounted directories. — Structure of ext4 on LVM

The ext4 file system focuses on high-performance and scalability, without a lot of extra frills. It is effective at preventing fragmentation over extended periods of time and provides nice tools for when it does happen. Ext4 is rock solid because it built on the previous ext3 file system, bringing with it all the years of in-system testing and bug fixes.

Most of the advanced capabilities in the LVM-ext4 setup come from LVM itself. LVM sits “below” the file system, which means it supports any file system. Logical volumes (LV) are generic block devices so virtual machines can use them directly. This flexibility allows each logical volume to use the right file system, with the right options, for a variety of situations. This layered approach also honors the Unix philosophy of small tools working together.

The volume group (VG) abstraction from the hardware allows LVM to create flexible logical volumes. Each LV pulls from the same storage pool but has its own configuration. Resizing volumes is a lot easier than resizing physical partitions as there are no limitation of ordered placement of the data. LVM physical volumes (PV) can be any number of partitions and can even move between devices while the system is running.

LVM supports read-only and read-write snapshots, which make it easy to create consistent backups from active systems. Each snapshot has a defined size, and a change to the source or snapshot volume use space from there. Alternately, logical volumes can also be part of a thinly provisioned pool. This allows snapshots to automatically use data from a pool instead of consuming fixed sized chunks defined at volume creation.

Multiple devices with LVM

LVM really shines when there are multiple devices. It has native support for most RAID levels and each logical volume can have a different RAID level. LVM will automatically choose appropriate physical devices for the RAID configuration or the user can specify it directly. Basic RAID support includes data striping for performance (RAID0) and mirroring for redundancy (RAID1). Logical volumes can also use advanced setups like RAID5, RAID6, and RAID10. LVM RAID support is mature because under the hood LVM uses the same device-mapper (dm) and multiple-device (md) kernel support used by mdadm.

Logical volumes can also be cached volumes for systems with both fast and slow drives. A classic example is a combination of SSD and spinning-disk drives. Cached volumes use faster drives for more frequently accessed data (or as a write cache), and the slower drive for bulk data.

The large number of stable features in LVM and the reliable performance of ext4 are a testament to how long they have been in use. Of course, with more features comes complexity. It can be challenging to find the right options for the right feature when configuring LVM. For single drive desktop systems, features of LVM like RAID and cache volumes don’t apply. However, logical volumes are more flexible than physical partitions and snapshots are useful. For normal desktop use, the complexity of LVM can also be a barrier to recovering from issues a typical user might encounter.

Advantages of Btrfs

Show the relationship of Btrfs filesystem to hard-drive partitions and mounted directories. — Btrfs Structure

Lessons learned from previous generations guided the features built into Btrfs. Unlike ext4, it can directly span multiple devices, so it brings along features typically found only in volume managers. It also has features that are unique in the Linux file system space (ZFS has a similar feature set, but don’t expect it in the Linux kernel).

Key Btrfs features

Perhaps the most important feature is the checksumming of all data. Checksumming, along with copy-on-write, provides the key method of ensuring file system integrity after unexpected power loss. More uniquely, checksumming can detect errors in the data itself. Silent data corruption, sometimes referred to as bitrot, is more common that most people realize. Without active validation, corruption can end up propagating to all available backups. This leaves the user with no valid copies. By transparently checksumming all data, Btrfs is able to immediately detect any such corruption. Enabling the right dup or raid option allows the file system to transparently fix the corruption as well.

Copy-on-write (COW) is also a fundamental feature of Btrfs, as it is critical in providing file system integrity and instant subvolume snapshots. Snapshots automatically share underlying data when created from common subvolumes. Additionally, after-the-fact deduplication uses the same technology to eliminate identical data blocks. Individual files can use COW features by calling cp with the reflink option. Reflink copies are especially useful for copying large files, such as virtual machine images, that tend to have mostly identical data over time.

Btrfs supports spanning multiple devices with no volume manager required. Multiple device support unlocks data mirroring for redundancy and striping for performance. There is also experimental support for more advanced RAID levels, such as RAID5 and RAID6. Unlike standard RAID setups, the Btrfs raid1 option actually allows an odd number of devices. For example, it can use 3 devices, even if they are are different sizes.

All RAID and dup options are specified at the file system level. As a consequence, individual subvolumes cannot use different options. Note that using the RAID1 option with multiple devices means that all data in the volume is available even if one device fails and the checksum feature maintains the integrity of the data itself. That is beyond what current typical RAID setups can provide.

Additional features

Btrfs also enables quick and easy remote backups. Subvolume snapshots can be sent to a remote system for storage. By leveraging the inherent COW meta-data in the file system, these transfers are efficient by only sending incremental changes from previously sent snapshots. User applications such as snapper make it easy to manage these snapshots.

Additionally, a Btrfs volume can have transparent compression and chattr +c will mark individual files or directories for compression. Not only does compression reduce the space consumed by data, but it helps extend the life of SSDs by reducing the volume of write operations. Compression certainly introduces additional CPU overhead, but a lot of options are available to dial in the right trade-offs.

The integration of file system and volume manager functions by Btrfs means that overall maintenance is simpler than LVM-ext4. Certainly this integration comes with less flexibility, but for most desktop, and even server, setups it is more than sufficient.

Btrfs on LVM

Btrfs can convert an ext3/ext4 file system in place. In-place conversion means no data to copy out and then back in. The data blocks themselves are not even modified. As a result, one option for an existing LVM-ext4 systems is to leave LVM in place and simply convert ext4 over to Btrfs. While doable and supported, there are reasons why this isn’t the best option.

Some of the appeal of Btrfs is the easier management that comes with a file system integrated with a volume manager. By running on top of LVM, there is still some other volume manager in play for any system maintenance. Also, LVM setups typically have multiple fixed sized logical volumes with independent file systems. While Btrfs supports multiple volumes in a given computer, many of the nice features expect a single volume with multiple subvolumes. The user is still stuck manually managing fixed sized LVM volumes if each one has an independent Btrfs volume. Though, the ability to shrink mounted Btrfs filesystems does make working with fixed sized volumes less painful. With online shrink there is no need to boot a live image.

The physical locations of logical volumes must be carefully considered when using the multiple device support of Btrfs. To Btrfs, each LV is a separate physical device and if that is not actually the case, then certain data availability features might make the wrong decision. For example, using raid1 for data typically provides protection if a single drive fails. If the actual logical volumes are on the same physical device, then there is no redundancy.

If there is a strong need for some particular LVM feature, such as raw block devices or cached logical volumes, then running Btrfs on top of LVM makes sense. In this configuration, Btrfs still provides most of its advantages such as checksumming and easy sending of incremental snapshots. While LVM has some operational overhead when used, it is no more so with Btrfs than with any other file system.

Wrap up

When trying to choose between Btrfs and LVM-ext4 there is no single right answer. Each user has unique requirements, and the same user may have different systems with different needs. Take a look at the feature set of each configuration, and decide if there is something compelling about one over the other. If not, there is nothing wrong with sticking with the defaults. There are excellent reasons to choose either setup.

Posted on December 18, 2020 by — Leave a comment

Using pods with Podman on Fedora

This article shows the reader how easy it is to get started using pods with Podman on Fedora. But what is Podman? Well, we will start by saying that Podman is a container engine developed by Red Hat, and yes, if you thought about Docker when reading container engine, you are on the right track. A whole new revolution of containerization started with Docker, and Kubernetes added the concept of pods in the area of container orchestration when dealing with containers that share some common resources. But hold on! Do you really think it is worth sticking with Docker alone by assuming it’s the only effective way of containerization? Podman can also manage pods on Fedora as well as the containers used in those pods.

Podman is a daemonless, open source, Linux native tool designed to make it easy to find, run, build, share and deploy applications using Open Containers Initiative (OCI) Containers and Container Images.

From the official Podman documentation at http://docs.podman.io/en/latest/

Why should we switch to Podman?

Podman is a daemonless container engine for developing, managing, and running OCI Containers on your Linux System. Containers can either be run as root or in rootless mode. Podman directly interacts with an image registry, containers and image storage.

Install Podman:

sudo dnf -y install podman

Creating a Pod:

To start using the pod we first need to create it and for that we have a basic command structure

 $ podman pod create

The command above contains no arguments and hence it will create a pod with a randomly generated name. You might however, want to give your pod a relevant name. For that you just need to modify the above command a bit.

 $ podman pod create --name climoiselle

The pod will be created and will report back to you the ID of the pod. In the example shown the pod was given the name ‘climoiselle’. To view the newly created pod is easy by using the command shown below:

 $ podman pod list

As you can see, there are two pods listed here, one named darshna and the one created from the example named climoiselle. No doubt you notice that both pods already include one container, yet we sisn’t deploy a container to the pods yet.
What is that extra container inside the pod? This randomly generated container is an infra container. Every podman pod includes this infra container and in practice these containers do nothing but go to sleep. Their purpose is to hold the namespaces associated with the pod and to allow Podman to connect other containers to the pod. The other purpose of the infra container is to allow the pod to keep running when all associated containers have been stopped.

You can also view the individual containers within a pod with the command:

 $ podman ps -a --pod

Add a container

The cool thing is, you can add more containers to your newly deployed pod. Always remember the name of your pod. It’s important as you’ll need that name in order to deploy the container in that pod. We’ll use the official ubuntu image and deploy a container using it running the top command.

 $ podman run -dt --pod climoiselle ubuntu top

Everything in a Single Command:

Podman has an agile characteristic when it comes to deploying a container in a pod which you created. You can create a pod and deploy a container to the said pod with a single command using Podman. Let’s say you want to deploy an NGINX container, exposing external port 8080 to internal port 80 to a new pod named test_server.

 $ podman run -dt --pod new:test_server -p 8080:80 nginx

Created a new pod and deployed a container together

Let’s check all pods that have been created and the number of containers running in each of them …

 $ podman pod list

List of the containers, their state and number of containers running into them

Do you want to know a detailed configuration of the pods which are running? Just type in the command shown below:

 podman pod inspect [pod's name/id]

Make it stop!

To stop the pods, we need to use the name or ID of the pod. With the information from podman’s pod list command, we can view the pods and their infra id. Simply use podman with the command stop and give the particular name/infra id of the pod.

 $ podman pod stop climoiselle

Hey take a look!

After following this short tutorial, you can see how quickly you can use pods with podman on fedora. It’s an easy and convenient way to use containers that share resources and interact together.

Add storage to your Fedora system with LVM

Sometimes there is a need to add another disk to your system. This is where Logical Volume Management (LVM) comes in handy. The cool thing about LVM is that it’s fairly flexible. There are several ways to add a disk. This article describes one way to do it.

Heads up!

This article does not cover the process of physically installing a new disk drive into your system. Consult your system and disk documentation on how to do that properly.

Important: Always make sure you have backups of important data. The steps described in this article will destroy data if it already exists on the new disk.

Good to know

This article doesn’t cover every LVM feature deeply; the focus is on adding a disk. But basically, LVM has volume groups, made up of one or more partitions and/or disks. You add the partitions or disks as physical volumes. A volume group can be broken down into many logical volumes. Logical volumes can be used as any other storage for filesystems, ramdisks, etc. More information can be found here.

Think of the physical volumes as forming a pool of storage (a volume group) from which you then carve out logical volumes for your system to use directly.

Preparation

Make sure you can see the disk you want to add. Use lsblk prior to adding the disk to see what storage is already available or in use.

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
zram0 251:0 0 989M 0 disk [SWAP]
vda 252:0 0 20G 0 disk
├─vda1 252:1 0 1G 0 part /boot
└─vda2 252:2 0 19G 0 part
└─fedora_fedora-root 253:0 0 19G 0 lvm /

This article uses a virtual machine with virtual storage. Therefore the device names start with vda for the first disk, vdb for the second, and so on. The name of your device may be different. Many systems will see physical disks as sda for the first disk, sdb for the second, and so on.

Once the new disk has been connected and your system is back up and running, use lsblk again to see the new block device.

$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
zram0 251:0 0 989M 0 disk [SWAP]
vda 252:0 0 20G 0 disk
├─vda1 252:1 0 1G 0 part /boot
└─vda2 252:2 0 19G 0 part
└─fedora_fedora-root 253:0 0 19G 0 lvm /
vdb 252:16 0 10G 0 disk

There is now a new device named vdb. The location for the device is /dev/vdb.

$ ls -l /dev/vdb
brw-rw----. 1 root disk 252, 16 Nov 24 12:56 /dev/vdb

We can see the disk, but we cannot use it with LVM yet. If you run blkid you should not see it listed. For this and following commands, you’ll need to ensure your system is configured so you can use sudo:

$ sudo blkid
/dev/vda1: UUID="4847cb4d-6666-47e3-9e3b-12d83b2d2448" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="830679b8-01"
/dev/vda2: UUID="k5eWpP-6MXw-foh5-Vbgg-JMZ1-VEf9-ARaGNd" TYPE="LVM2_member" PARTUUID="830679b8-02"
/dev/mapper/fedora_fedora-root: UUID="f8ab802f-8c5f-4766-af33-90e78573f3cc" BLOCK_SIZE="4096" TYPE="ext4"
/dev/zram0: UUID="fc6d7a48-2bd5-4066-9bcf-f062b61f6a60" TYPE="swap"

Add the disk to LVM

Initialize the disk using pvcreate. You need to pass the full path to the device. In this example it is /dev/vdb; on your system it may be /dev/sdb or another device name.

$ sudo pvcreate /dev/vdb
Physical volume "/dev/vdb" successfully created.

You should see the disk has been initialized as an LVM2_member when you run blkid:

$ sudo blkid
/dev/vda1: UUID="4847cb4d-6666-47e3-9e3b-12d83b2d2448" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="830679b8-01"
/dev/vda2: UUID="k5eWpP-6MXw-foh5-Vbgg-JMZ1-VEf9-ARaGNd" TYPE="LVM2_member" PARTUUID="830679b8-02"
/dev/mapper/fedora_fedora-root: UUID="f8ab802f-8c5f-4766-af33-90e78573f3cc" BLOCK_SIZE="4096" TYPE="ext4"
/dev/zram0: UUID="fc6d7a48-2bd5-4066-9bcf-f062b61f6a60" TYPE="swap"
/dev/vdb: UUID="4uUUuI-lMQY-WyS5-lo0W-lqjW-Qvqw-RqeroE" TYPE="LVM2_member"

You can list all physical volumes currently available using pvs:

$ sudo pvs
PV VG Fmt Attr PSize PFree
/dev/vda2 fedora_fedora lvm2 a-- <19.00g 0
/dev/vdb lvm2 --- 10.00g 10.00g

/dev/vdb is listed as a PV (phsyical volume), but it isn’t assigned to a VG (Volume Group) yet.

Add the pysical volume to a volume group

You can find a list of available volume groups using vgs:

$ sudo vgs
VG #PV #LV #SN Attr VSize VFree
fedora_fedora 1 1 0 wz--n- 19.00g 0

In this example, there is only one volume group available. Next, add the physical volume to fedora_fedora:

$ sudo vgextend fedora_fedora /dev/vdb
Volume group "fedora_fedora" successfully extended

You should now see the physical volume is added to the volume group:

$ sudo pvs PV VG Fmt Attr PSize PFree
/dev/vda2 fedora_fedora lvm2 a– <19.00g 0
/dev/vdb fedora_fedora lvm2 a– <10.00g <10.00g

Look at the volume groups:

$ sudo vgs
VG #PV #LV #SN Attr VSize VFree
fedora_fedora 2 1 0 wz–n- 28.99g <10.00g

You can get a detailed list of the specific volume group and physical volumes as well:

$ sudo vgdisplay fedora_fedora
--- Volume group ---
VG Name fedora_fedora
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 3
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 1
Open LV 1
Max PV 0
Cur PV 2
Act PV 2
VG Size 28.99 GiB
PE Size 4.00 MiB
Total PE 7422
Alloc PE / Size 4863 / 19.00 GiB
Free PE / Size 2559 / 10.00 GiB
VG UUID C5dL2s-dirA-SQ15-TfQU-T3yt-l83E-oI6pkp

Look at the PV:

$ sudo pvdisplay /dev/vdb --- Physical volume --- PV Name /dev/vdb VG Name fedora_fedora PV Size 10.00 GiB / not usable 4.00 MiB Allocatable yes PE Size 4.00 MiB Total PE 2559 Free PE 2559 Allocated PE 0 PV UUID 4uUUuI-lMQY-WyS5-lo0W-lqjW-Qvqw-RqeroE

Now that we have added the disk, we can allocate space to logical volumes (LVs):

$ sudo lvs
LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert
root fedora_fedora -wi-ao---- 19.00g

Look at the logical volumes. Here’s a detailed look at the root LV:

$ sudo lvdisplay fedora_fedora/root
--- Logical volume ---
LV Path /dev/fedora_fedora/root
LV Name root
VG Name fedora_fedora
LV UUID yqc9cw-AvOw-G1Ni-bCT3-3HAa-qnw3-qUSHGM
LV Write Access read/write
LV Creation host, time fedora, 2020-11-24 11:44:36 -0500
LV Status available
LV Size 19.00 GiB
Current LE 4863
Segments 1
Allocation inherit
Read ahead sectors auto
- currently set to 256
Block device 253:0

Look at the size of the root filesystem and compare it to the logical volume size.

$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/fedora_fedora-root 19G 1.4G 17G 8% /

The logical volume and the filesystem both agree the size is 19G. Let’s add 5G to the root logical volume:

$ sudo lvresize -L +5G fedora_fedora/root
Size of logical volume fedora_fedora/root changed from 19.00 GiB (4863 extents) to 24.00 GiB (6143 extents).
Logical volume fedora_fedora/root successfully resized.

We now have 24G available to the logical volume. Look at the / filesystem.

$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/fedora_fedora-root 19G 1.4G 17G 8% /

We are still showing only 19G free. This is because the logical volume is not the same as the filesytem. To use the new space added to the logical volume, resize the filesystem.

$ sudo resize2fs /dev/fedora_fedora/root
resize2fs 1.45.6 (20-Mar-2020)
Filesystem at /dev/fedora_fedora/root is mounted on /; on-line resizing required
old_desc_blocks = 3, new_desc_blocks = 3
The filesystem on /dev/fedora_fedora/root is now 6290432 (4k) blocks long.

Look at the size of the filesystem.

$ df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/fedora_fedora-root 24G 1.4G 21G 7% /

As you can see, the root file system (/) has taken all of the space available on the logical volume and no reboot was needed.

You have now initialized a disk as a physical volume, and extended the volume group with the new physical volume. After that you increased the size of the logical volume, and resized the filesystem to use the new space from the logical volume.

Posted on November 30, 2020 by — Leave a comment

Getting started with Stratis – up and running

When adding storage to a Linux server, system administrators often use commands like pvcreate, vgcreate, lvcreate, and mkfs to integrate the new storage into the system. Stratis is a command-line tool designed to make managing storage much simpler. It creates, modifies, and destroys pools of storage. It also allocates and deallocates filesystems from the storage pools.

Instead of an entirely in-kernel approach like ZFS or Btrfs, Stratis uses a hybrid approach with components in both user space and kernel land. It builds on existing block device managers like device mapper and existing filesystems like XFS. Monitoring and control is performed by a user space daemon.

Stratis tries to avoid some ZFS characteristics like restrictions on adding new hard drives or replacing existing drives with bigger ones. One of its main design goals is to achieve a positive command-line experience.

Install Stratis

Begin by installing the required packages. Several Python-related dependencies will be automatically pulled in. The stratisd package provides the stratisd daemon which creates, manages, and monitors local storage pools. The stratis-cli package provides the stratis command along with several Python libraries.

# yum install -y stratisd stratis-cli

Next, enable the stratisd service.

# systemctl enable --now stratisd

Note that the “enable –now” syntax shown above both permanently enables and immediately starts the service.

After determining what disks/block devices are present and available, the three basic steps to using Stratis are:

Create a pool of the desired disks.
Create a filesystem in the pool.
Mount the filesystem.

In the following example, four virtual disks are available in a virtual machine. Be sure not to use the root/system disk (/dev/vda in this example)!

# sfdisk -s
/dev/vda: 31457280
/dev/vdb:   5242880
/dev/vdc:   5242880
/dev/vdd:   5242880
/dev/vde:   5242880
total: 52428800 blocks

Create a storage pool using Stratis

# stratis pool create testpool /dev/vdb /dev/vdc
# stratis pool list
Name Total Physical Size  Total Physical Used
testpool 10 GiB 56 MiB

After creating the pool, check the status of its block devices:

# stratis blockdev list
Pool Name   Device Node Physical Size   State  Tier
testpool  /dev/vdb            5 GiB  In-use  Data
testpool  /dev/vdc            5 GiB  In-use  Data

Create a filesystem using Stratis

Next, create a filesystem. As mentioned earlier, Stratis uses the existing DM (device mapper) and XFS filesystem technologies to create thinly-provisioned filesystems. By building on these existing technologies, large filesystems can be created and it is possible to add physical storage as storage needs grow.

# stratis fs create testpool testfs
# stratis fs list
Pool Name  Name  Used Created        Device            UUID
testpool  testfs 546 MiB  Apr 18 2020 09:15 /stratis/testpool/testfs  095fb4891a5743d0a589217071ff71dc

Note that “fs” in the example above can optionally be written out as “filesystem”.

Mount the filesystem

Next, create a mount point and mount the filesystem.

# mkdir /testdir
# mount /stratis/testpool/testfs /testdir
# df -h | egrep 'stratis|Filesystem'
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/stratis-1-3e8e[truncated]71dc  1.0T  7.2G 1017G   1% /testdir

The actual space used by a filesystem is shown using the stratis fs list command demonstrated previously. Notice how the testdir filesystem has a virtual size of 1.0T. If the data in a filesystem approaches its virtual size, and there is available space in the storage pool, Stratis will automatically grow the filesystem. Note that beginning with Fedora 34, the form of device path will be /dev/stratis/<pool-name>/<filesystem-name>.

Add the filesystem to fstab

To configure automatic mounting of the filesystem at boot time, run following commands:

# UUID=`lsblk -n -o uuid /stratis/testpool/testfs`
# echo "UUID=${UUID} /testdir xfs defaults 0 0" >> /etc/fstab

After updating fstab, verify that the entry is correct by unmounting and mounting the filesystem:

# umount /testdir
# mount /testdir
# df -h | egrep 'stratis|Filesystem'
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/stratis-1-3e8e[truncated]71dc  1.0T  7.2G 1017G   1% /testdir

Adding cache devices with Stratis

Suppose /dev/vdd is an available SSD (solid state disk). To configure it as a cache device and check its status, use the following commands:

# stratis pool add-cache testpool  /dev/vdd
# stratis blockdev
Pool Name   Device Node Physical Size  State   Tier
testpool   /dev/vdb            5 GiB  In-use   Data
testpool   /dev/vdc            5 GiB  In-use   Data
testpool   /dev/vdd            5 GiB  In-use  Cache

Growing the storage pool

Suppose the testfs filesystem is close to using all the storage capacity of testpool. You could add an additional disk/block device to the pool with commands similar to the following:

# stratis pool add-data testpool /dev/vde
# stratis blockdev
Pool Name Device Node Physical Size   State   Tier
testpool   /dev/vdb           5 GiB  In-use   Data
testpool   /dev/vdc           5 GiB  In-use   Data
testpool   /dev/vdd           5 GiB  In-use  Cache
testpool   /dev/vde           5 GiB  In-use   Data

After adding the device, verify that the pool shows the added capacity:

# stratis pool
Name      Total Physical Size   Total Physical Used
testpool             15 GiB           606 MiB

Conclusion

Stratis is a tool designed to make managing storage much simpler. Creating a filesystem with enterprise functionalities like thin-provisioning, snapshots, volume management, and caching can be accomplished quickly and easily with just a few basic commands.

Posted on November 16, 2020 by — Leave a comment

Podman with capabilities on Fedora

Containerization is a booming technology. As many as seventy-five percent of global organizations could be running some type of containerization technology in the near future. Since widely used technologies are more likely to be targeted by hackers, securing containers is especially important. This article will demonstrate how POSIX capabilities are used to secure Podman containers. Podman is the default container management tool in RHEL8.

Determine the Podman container’s privilege mode

Containers run in either privileged or unprivileged mode. In privileged mode, the container uid 0 is mapped to the host’s uid 0. For some use cases, unprivileged containers lack sufficient access to the resources of the host machine. Technologies and techniques including Mandatory Access Control (apparmor, SELinux), seccomp filters, dropping of capabilities, and namespaces help to secure containers regardless of their mode of operation.

To determine the privilege mode from outside the container:

$ podman inspect --format="{{.HostConfig.Privileged}}" <container id>

If the above command returns true then the container is running in privileged mode. If it returns false then the container is running in unprivileged mode.

To determine the privilege mode from inside the container:

$ ip link add dummy0 type dummy

If this command allows you to create an interface then you are running a privileged container. Otherwise you are running an unprivileged container.

Capabilities

Namespaces isolate a container’s processes from arbitrary access to the resources of its host and from access to the resources of other containers running on the same host. Processes within privileged containers, however, might still be able to do things like alter the IP routing table, trace arbitrary processes, and load kernel modules. Capabilities allow one to apply finer-grained restrictions on what resources the processes within a container can access or alter; even when the container is running in privileged mode. Capabilities also allow one to assign privileges to an unprivileged container that it would not otherwise have.

For example, to add the NET_ADMIN capability to an unprivileged container so that a network interface can be created inside of the container, you would run podman with parameters similar to the following:

[root@vm1 ~]# podman run -it --cap-add=NET_ADMIN centos
[root@b27fea33ccf1 /]# ip link add dummy0 type dummy
[root@b27fea33ccf1 /]# ip link

The above commands demonstrate a dummy0 interface being created in an unprivileged container. Without the NET_ADMIN capability, an unprivileged container would not be able to create an interface. The above commands demonstrate how to grant a capability to an unprivileged container.

Currently, there are about 39 capabilities that can be granted or denied. Privileged containers are granted many capabilities by default. It is advisable to drop unneeded capabilities from privileged containers to make them more secure.

To drop all capabilities from a container:

$ podman run -it -d --name mycontainer --cap-drop=all centos

To list a container’s capabilities:

$ podman exec -it 48f11d9fa512 capsh --print

The above command should show that no capabilities are granted to the container.

Refer to the capabilities man page for a complete list of capabilities:

$ man capabilities

Use the capsh command to list the capabilities you currently possess:

$ capsh --print

As another example, the below command demonstrates dropping the NET_RAW capability from a container. Without the NET_RAW capability, servers on the internet cannot be pinged from within the container.

$ podman run -it --name mycontainer1 --cap-drop=net_raw centos
>>> ping google.com (will output error, operation not permitted)

As a final example, if your container were to only need the SETUID and SETGID capabilities, you could achieve such a permission set by dropping all capabilities and then re-adding only those two.

$ podman run -d --cap-drop=all --cap-add=setuid --cap-add=setgid fedora sleep 5 > /dev/null; pscap | grep sleep

The pscap command shown above should show the capabilities that have been granted to the container.

I hope you enjoyed this brief exploration of how capabilities are used to secure Podman containers.

Thank You!

Posted on November 11, 2020 by — Leave a comment

Using Fedora 33 with Microsoft’s WSL2

If you’re like me, you may find yourself running Windows for a variety of reasons from work to gaming. Sure you could run Fedora in a virtual machine or as a container, but those don’t blend into a common windows experience as easily as the Windows Subsystem for Linux (WSL). Using Fedora via WSL will let you blend the two environments together for a fantastic development environment.

Prerequisites

There are a few basics you’ll need in order to make this all work. You should be running Windows 10, and have WSL2 installed already. If not, check out the Microsoft documentation for instructions, and come back here when you’re finished. Microsoft recommends setting wsl2 as the distro default for simplicity. This guide assumes you’ve done that.

Next, you’re going to need some means of unpacking xz compressed files. You can do this with another WSL-based distribution, or use 7zip.

Download a Fedora 33 rootfs

Since Fedora doesn’t ship an actual rootfs archive, we’re going to abuse the one used to generate the container image for dockerhub. You will want to download the tar.xz file from the fedora-cloud GitHub repository. Once you have the tar.xz, uncompress it, but don’t unpack it. You want to end up with something like fedora-33-datestamp.tar. Once you have that, you’re ready to build the image.

Composing the WSL Fedora build

I prefer to use c:\distros, but you can choose nearly whatever location you want. Whatever you choose, make sure the top level path exists before you import the build. Now open a cmd or powershell prompt, because it’s time to import:

 wsl.exe --import Fedora-33 c:\distros\Fedora-33 $HOME\Downloads\fedora-33.tar

You will see Fedora-33 show up in wsl’s list

 PS C:\Users\jperrin> wsl.exe -l -v

  NAME                   STATE           VERSION

  Fedora-33                 Stopped         2

From here, you can start to play around with Fedora in wsl, but we have a few things we need to do to make it actually useful as a wsl distro.

 wsl -d Fedora-33

This will launch Fedora’s wsl instance as the root user. From here, you’re going to install a few core packages and set a new default user. You’re also going to need to configure sudo, otherwise you won’t be able to easily elevate privileges if you need to install something else later.

 dnf update

dnf install wget curl sudo ncurses dnf-plugins-core dnf-utils passwd findutils

wslutilites uses curl and wget for things like VS Code integration, so they’re useful to have around. Since you need to use a Copr repo for this, you want the added dnf functionality.

Add your user

Now it’s time to add your user, and set it as the default.

 useradd -G wheel yourusername

passwd yourusername

Now that you’ve created your username and added a password, make sure they work. Exit the wsl instance, and launch it again, this time specifying the username. You’re also going to test sudo, and check your uid.

 wsl -d Fedora-33 -u yourusername

$id -u

1000

$ sudo cat /etc/shadow

Assuming everything worked fine, you’re now ready to set the default user for your Fedora setup in Windows. To do this, exit the wsl instance and get back into Powershell. This Powershell one-liner configures your user properly:

 Get-ItemProperty Registry::HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Lxss\*\ DistributionName | Where-Object -Property DistributionName -eq Fedora-33  | Set-ItemProperty -Name DefaultUid -Value 1000

Now you should be able to launch WSL again without specifying a user, and be yourself instead of root.

Customize!

From here, you’re done getting the basic Fedora 33 setup running in wsl, but it doesn’t have the Windows integration piece yet. If this is something you want, there’s a Copr repo to enable. If you choose to add this piece, you’ll be able to run Windows apps directly from inside your shell, as well as integrate your Linux environment easily with VS Code. Note that Copr is not officially supported by Fedora infrastructure. Use packages at your own risk

 dnf copr enable trustywolf/wslu

Now you can go configure your terminal, setup a Python development environment, or however else you want to use Fedora 33. Enjoy!

Posted on November 9, 2020 by — Leave a comment

Getting started with Stratis encryption

Stratis is described on its official website as an “easy to use local storage management for Linux.” See this short video for a quick demonstration of the basics. The video was recorded on a Red Hat Enterprise Linux 8 system. The concepts shown in the video also apply to Stratis in Fedora.

Stratis version 2.1 introduces support for encryption. Continue reading to learn how to get started with encryption in Stratis.

Prerequisites

Encryption requires Stratis version 2.1 or greater. The examples in this post use a pre-release of Fedora 33. Stratis 2.1 will be available in the final release of Fedora 33.

You’ll also need at least one available block device to create an encrypted pool. The examples shown below were done on a KVM virtual machine with a 5 GB virtual disk drive (/dev/vdb).

Create a key in the kernel keyring

The Linux kernel keyring is used to store the encryption key. For more information on the kernel keyring, refer to the keyrings manual page (man keyrings).

Use the stratis key set command to set up the key within the kernel keyring. You must specify where the key should be read from. To read the key from standard input, use the –capture-key option. To retrieve the key from a file, use the –keyfile-path <file> option. The last parameter is a key description. It will be used later when you create the encrypted Stratis pool.

For example, to create a key with the description pool1key, and to read the key from standard input, you would enter:

# stratis key set --capture-key pool1key
Enter desired key data followed by the return key:

The command prompts us to type the key data / passphrase, and the key is then created within the kernel keyring.

To verify that the key was created, run stratis key list:

# stratis key list
Key Description
pool1key

This verifies that the pool1key was created. Note that these keys are not persistent. If the host is rebooted, the key will need to be provided again before the encrypted Stratis pool can be accessed (this process is covered later).

If you have multiple encrypted pools, they can have a separate keys, or they can share the same key.

The keys can also be viewed using the following keyctl commands:

# keyctl get_persistent @s
318044983
# keyctl show
Session Keyring
 701701270 --alswrv      0     0  keyring: _ses
 649111286 --alswrv      0 65534   \_ keyring: _uid.0
 318044983 ---lswrv      0 65534   \_ keyring: _persistent.0
1051260141 --alswrv      0     0       \_ user: stratis-1-key-pool1key

Create the encrypted Stratis pool

Now that a key has been created for Stratis, the next step is to create the encrypted Stratis pool. Encrypting a pool can only be done at pool creation. It isn’t currently possible to encrypt an existing pool.

Use the stratis pool create command to create a pool. Add –key-desc and the key description that you provided in the previous step (pool1key). This will signal to Stratis that the pool should be encrypted using the provided key. The below example creates the Stratis pool on /dev/vdb, and names it pool1. Be sure to specify an empty/available device on your system.

# stratis pool create --key-desc pool1key pool1 /dev/vdb

You can verify that the pool has been created with the stratis pool list command:

# stratis pool list 
Name                     Total Physical   Properties
pool1   4.98 GiB / 37.63 MiB / 4.95 GiB      ~Ca, Cr

In the sample output shown above, ~Ca indicates that caching is disabled (the tilde negates the property). Cr indicates that encryption is enabled. Note that caching and encryption are mutually exclusive. Both features cannot be simultaneously enabled.

Next, create a filesystem. The below example, demonstrates creating a filesystem named filesystem1, mounting it at the /filesystem1 mountpoint, and creating a test file in the new filesystem:

# stratis filesystem create pool1 filesystem1
# mkdir /filesystem1
# mount /stratis/pool1/filesystem1 /filesystem1
# cd /filesystem1
# echo "this is a test file" > testfile

Access the encrypted pool after a reboot

When you reboot you’ll notice that Stratis no longer shows your encrypted pool or its block device:

# stratis pool list
Name   Total Physical   Properties

# stratis blockdev list
Pool Name   Device Node   Physical Size   Tier

To access the encrypted pool, first re-create the key with the same key description and key data / passphrase that you used previously:

# stratis key set --capture-key pool1key
Enter desired key data followed by the return key:

Next, run the stratis pool unlock command, and verify that you can now see the pool and its block device:

# stratis pool unlock
# stratis pool list
Name                      Total Physical   Properties
pool1   4.98 GiB / 583.65 MiB / 4.41 GiB      ~Ca, Cr
# stratis blockdev list
Pool Name   Device Node   Physical Size   Tier
pool1       /dev/dm-2          4.98 GiB   Data

Next, mount the filesystem and verify that you can access the test file you created previously:

# mount /stratis/pool1/filesystem1 /filesystem1/
# cat /filesystem1/testfile 
this is a test file

Use a systemd unit file to automatically unlock a Stratis pool at boot

It is possible to automatically unlock your Stratis pool at boot without manual intervention. However, a file containing the key must be available. Storing the key in a file might be a security concern in some environments.

The systemd unit file shown below provides a simple method to unlock a Stratis pool at boot and mount the filesystem. Feedback on a better/alternative methods is welcome. You can provide suggestions in the comment section at the end of this article.

Start by creating your key file with the following command. Be sure to substitute passphrase with the same key data / passphrase you entered previously.

# echo -n passphrase > /root/pool1key

Make sure that the file is only readable by root:

# chmod 400 /root/pool1key
# chown root:root /root/pool1key

Create a systemd unit file at /etc/systemd/system/stratis-filesystem1.service with the following content:

[Unit]
Description = stratis mount pool1 filesystem1 file system
After = stratisd.service [Service]
ExecStartPre=sleep 2
ExecStartPre=stratis key set --keyfile-path /root/pool1key pool1key
ExecStartPre=stratis pool unlock
ExecStartPre=sleep 3
ExecStart=mount /stratis/pool1/filesystem1 /filesystem1
RemainAfterExit=yes [Install]
WantedBy = multi-user.target

Next, enable the service so that it will run at boot:

# systemctl enable stratis-filesystem1.service

Now reboot and verify that the Stratis pool has been automatically unlocked and that its filesystem is mounted.

Summary and conclusion

In today’s environment, encryption is a must for many people and organizations. This post demonstrated how to enable encryption in Stratis 2.1.

Fedora Workstation

Fedora Server

Fedora IoT

Fedora CoreOS

Fedora Silverblue

Conclusion

Metrics

Appendix

References

System upgrades

Adding Flatpak remotes and other third-party repositories

Flathub remotes

RPM Fusion repos

Copr repos

Examples of popular Flatpak applications

Installing the Nvidia driver and a specific kernel

Toolbx

Layering packages

Gaming

Other tips and suggestions

rpm-ostree tips

Listing packages

Miscellaneous tips

Conclusion

In summary

What about all the other file systems?

Commonalities

Advantages of LVM-ext4

Multiple devices with LVM

Advantages of Btrfs

Key Btrfs features

Additional features

Btrfs on LVM

Wrap up

Why should we switch to Podman?

Install Podman:

Creating a Pod:

Add a container

Everything in a Single Command:

Make it stop!

Hey take a look!

Further reading

Heads up!

Good to know

Preparation

Add the disk to LVM

Add the pysical volume to a volume group

Install Stratis

Create a storage pool using Stratis

Create a filesystem using Stratis

Mount the filesystem

Add the filesystem to fstab

Adding cache devices with Stratis

Growing the storage pool

Conclusion

Determine the Podman container’s privilege mode

Capabilities

Prerequisites

Download a Fedora 33 rootfs

Composing the WSL Fedora build

Add your user

Customize!

Prerequisites

Create a key in the kernel keyring

Create the encrypted Stratis pool

Access the encrypted pool after a reboot

Use a systemd unit file to automatically unlock a Stratis pool at boot

Summary and conclusion