Tag: fedora

Posted on by — Leave a comment

Using Cockpit to graphically manage systems, without installing Cockpit on them!

It probably sounds too good to be true: the ability to manage remote systems using an easy to use, intuitive graphical interface – without the need to install extra software on the remote systems, enable additional services, or make any other changes on the remote systems. This functionality, however, is now available with a combination of the recently introduced Python bridge for Cockpit and the Cockpit Client Flatpak! This allows Cockpit to manage remote systems, assuming only SSH access and that Python is installed on the remote host. Read on for more information on how this works and how to get started.

If you are not familiar with Cockpit, it is described on the project’s web site as a web-based graphical interface for servers. Cockpit is intended for everyone, especially those who are:

  • new to Linux (including Windows admins)
  • familiar with Linux and want an easy, graphical way to administer servers
  • expert admins who mainly use other tools but want an overview on individual systems

You can easily and intuitively complete a variety of tasks from Cockpit. These including tasks such as:

  • expanding the size of a filesystem
  • creating a network bond
  • modifying the firewall
  • viewing log entries
  • viewing real time and historical performance information
  • managing Podman containers
  • managing KVM virtual machines

and many additional tasks.

Objections to using Cockpit on systems

In the past, I’ve heard two main objections to using Cockpit on systems:

  1. I don’t want to run the Cockpit web server on my systems. Additional network services like this increase the attack surface. I don’t want to open another port in the firewall. I don’t want more HTTPS certificates in my environment to manage and maintain.
  2. I don’t want to install additional packages on my systems. I don’t even have access to install additional packages). The more packages installed, the larger my footprint is, and the more attack surface there is. For me to install additional packages in a production environment, I have to go through a change management process, etc. What a hassle!

Let’s address these one at a time. For the first concern, you have actually had several options for connecting to Cockpit over SSH, without running the Cockpit web server, for quite some time. These options include:

  • The ability to set up a bastion host, which is a host that has the Cockpit web server running on it.  You can then connect to Cockpit on the bastion host using a web browser.  From the Cockpit login screen on the bastion host you can use the Connect to option to specify an alternate host to login to (refer to the LoginTo cockpit.conf configuration option).  Another option is to authenticate to Cockpit on the bastion host, and use the Add new host option.  In either case, the bastion Cockpit host will connect to these additional remote hosts over SSH (so only the bastion host in your environment needs to be running the Cockpit web server).
  • You can use the Cockpit integration available with the upstream Foreman, or downstream Red Hat Satellite, to connect to Cockpit on systems in your environment over SSH.  
  • You can use the Cockpit Client Flatpak, which will connect to systems over SSH.
  • You can use the cockpit/ws container image. This is a containerized version of the Cockpit web server that acts as a containerized bastion host

For more information on these options, refer to the Connecting to the RHEL web console, part 1: SSH access methods blog post. This blog post focuses on the downstream RHEL web console, however, the information also applies to the upstream Cockpit available in Fedora. 

This brings me to the second concern, and the main focus of this article. This is the concern that I don’t want to install additional packages on the remote systems I am managing.  While there are several options for using the web console without the Cockpit web server, all of these options previously had a prerequisite that the remote systems needed to have at least the cockpit-system package installed.  For example, previously if you tried to use the Cockpit Client Flatpak to connect to a remote system that didn’t have Cockpit installed, you’d see an error message stating that the remote system doesn’t have cockpit-bridge installed. 

The Cockpit team has replaced the previous Cockpit bridge (implemented using C) with a new bridge written in Python.  For a technical overview of the function of the Cockpit bridge, and how the new Python bridge was implemented, refer to the recent Monty Python’s Flying Cockpit DevConf presentation by Allison Karlitskaya and Martin Pitt. 

This new Python bridge overcomes the previous limitation requiring Cockpit to be installed on the remote hosts.  

Using the Cockpit Client Flatpak

With the Cockpit Client Flatpak application installed on a workstation, we can connect to remote systems over SSH and manage them using Cockpit.

Installation

In the following example, I’m using a Fedora 38 workstation. Install the Cockpit Client Flatpak by simply opening the GNOME Software application and searching for Cockpit. Note that you’ll need to have Flathub enabled in GNOME Software.

Using the Cockpit Client

Once installed, you’ll see the following when opening the Cockpit Client:

You can type in a hostname or IP address that you would like to connect to. To authenticate as a user other than the user you are currently using, you can use the user@hostname syntax. A list of recent hosts that you’ve connected to will appear, if this is not the first time using the Cockpit Client. In that case, you can simply click on a host name to reconnect

If you have SSH key based authentication setup, you’ll be logged in to the remote host using the key based authentication. With out SSH keys setup, you’ll be prompted to authenticate with a password. In either case, if it is your first time connecting to the host over SSH, you’ll be prompted to accept the host key fingerprint.

As a special case, you can log into your currently running local session by connecting to localhost, without authentication.  

Once connected, you’ll see the Cockpit Overview page:

Cockpit overivew menu

Select the Terminal menu item in Cockpit to show that the remote system that I’m logged in to does not have any Cockpit packages installed:

Cockpit Terminal view

Prerequisites for connecting to systems with Cockpit Client

There are several prerequisites for utilizing Cockpit Client to connect to a remote system. If you are familiar with managing remote hosts with Ansible, you’ll likely already be familiar with the prerequisites. They are the same:

  1. You must have connectivity to the remote system over SSH.
  2. You must have a valid user account on the remote system that you can authenticate with.
  3. If you need the ability to complete privileged operations in Cockpit, the user account on the remote system will need sudo privileges.

If you are connecting to a remote system that doesn’t have Cockpit installed, there are a couple of additional prerequisites:

  1. Python 3.6 or later must be installed on the remote host. This is not usually an issue, with some exceptions, such as Fedora CoreOS which does not include Python by default.
  2. An older version of Cockpit Client can not be used to connect to a newer operating system version. For example, if I installed Cockpit Client on my Fedora 38 workstation today and never updated it, it may not work properly to manage a Fedora 39 or Fedora 40 server in the future.

Frequently asked questions

Here are some frequently asked questions about this functionality:

Question: Cockpit is extendable via additional Applications.  Which Cockpit applications are available if I use the Cockpit Client to connect to a remote system that doesn’t have Cockpit installed?

Answer: Currently, Cockpit Client includes

  • cockpit-machines (virtual machine management)
  • cockpit-podman (Podman container management)
  • cockpit-ostree (used to manage rpm-ostree based systems)
  • cockpit-storaged (storage management)
  • cockpit-sosreport (for generating diagnostic reports)
  • cockpit-selinux (for managing SELinux)
  • cockpit-packagekit (for managing software updates)
  • cockpit-networkmanager (network management)
  • cockpit-kdump (kernel dump configuration) 

The Cockpit team is looking for feedback on what Cockpit applications you’d like to see included in the Cockpit Client. Post a comment below with your feedback. 

Question:  I connected to a remote system that doesn’t have Cockpit installed, but I don’t see Virtual Machines or one of the other applications listed in the menu.  I thought you just said these were included in the Cockpit Client Flatpak?

Answer:  When you login to a remote system that doesn’t have Cockpit packages installed, you’ll only see the menu options for underlying functionality available on the remote system.  For example, you’ll only see Virtual Machines in the Cockpit menu if the remote host has the libvirt-dbus package installed. 

Question: Can Cockpit applications available in the Cockpit Client be used with locally installed Cockpit applications on the remote host?  In other words, if I need a Cockpit application not included in the Cockpit Client, can I install just that single package on the remote host?  

Answer:  No, you cannot mix and match applications included in the Cockpit Client flatpak and those installed locally on the remote host.  For a remote host that has the cockpit-bridge package installed, Cockpit Client will exclusively use the applications that are installed locally on the remote host.  If the remote host does not have the cockpit-bridge package installed, Cockpit Client will exclusively use the applications bundled in the Cockpit Client Flatpak.  

Question:  Can I use Cockpit Client to connect to the local host?

Answer: Yes!  Simply open Cockpit Client and type in localhost and you’ll be able to manage the local host.  You don’t need to have any Cockpit packages installed on the local host if you use this method. You only need the Cockpit Client Flatpak.  

Question:  What Linux distributions can I connect to using the Cockpit Client?

Answer:  Cockpit is compatible with a number of different Linux distributions.  For more information, see the Running Cockpit page.  If connecting to a remote system that doesn’t have Cockpit installed, keep in mind the previously mentioned requirements regarding not connecting to newer OS’s from an older Cockpit Client.  

Question:  Does the Cockpit team have any future plans regarding this functionality? 

Answer:  The Cockpit team is planning on adding the ability to connect to remote hosts without Cockpit packages installed to the cockpit-ws container image. See COCKPIT-954 ticket for more info.  

Have more questions not covered here? Ask them in the comments section below!

Conclusion

The new Python bridge, and the corresponding ability to use the Cockpit Client to connect to remote systems without installing Cockpit, makes it incredibly easy to use Cockpit in almost any circumstance.

Try this out! It’s easy to do. Simply install the Cockpit Client Flatpak, and use it to connect to either your localhost or a remote system. Once you’ve tried it, let us know what you think in the comments below.

Posted on by — Leave a comment

Contribute during the DNF5, GNOME 45, and i18n test days

Fedora test days are events 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 to Fedora Linux before, this is a perfect way to get started.

There are four test periods in the upcoming weeks:

  • Friday 11 August through Thursday 17 August , is to test DNF5.
  • Monday 14 August through Sunday 20 August, two test day periods focusing on testing GNOME Desktop and Core Apps.
  • Tuesday 5 September through Monday 11 September, is to test i18n.

Come and test with us to make the upcoming Fedora Linux 39 release even better. Read more below about how to do it.

DNF5

Since the brand new dnf5 package has landed in rawhide, we would like to organize a test week to get some initial feedback on it before it becomes the default. We will be testing DNF5 to iron out any rough edges.

The test week will be Friday 11 August through Thursday 17 August. The test week page is available here .

GNOME 45 test week

GNOME 45 has landed and will be part of the change for Fedora Linux 39. Since GNOME is the default desktop environment for Fedora Workstation, and thus for many Fedora users, this interface and environment merits a lot of testing. The Workstation Working Group and Fedora Quality team have decided to split the test week into two parts:

Monday 14 August through Thursday 17 August, we will be testing GNOME Desktop and Core Apps. You can find the test day page here.

Friday 18 August through Sunday 20 August, the focus will be to test GNOME Apps in general. This will be shipped by default. The test day page is here.

i18n test week

The i18n test week focuses on testing internationalization features in Fedora Linux.

The test week is Tuesday 5 September through Monday 11 September. The test week page is available here.

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

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

Posted on by — Leave a comment

Fedora Linux Flatpak cool apps to try for August

This article introduces projects available in Flathub with installation instructions.

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

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

Authenticator

Authenticator is a simple app that allows you to generate Two-Factor authentication codes. It has a very simple and elegant interface with support for a a lot of algorithms and methods. Some of its features are:

  • Time-based/Counter-based/Steam methods support
  • SHA-1/SHA-256/SHA-512 algorithms support
  • QR code scanner using a camera or from a screenshot
  • Lock the application with a password
  • Backup/Restore from/into known applications like FreeOTP+, Aegis (encrypted / plain-text), andOTP, Google Authenticator

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

flatpak install flathub com.belmoussaoui.Authenticator

Secrets

Secrets is a password manager that integrates with GNOME. It’s easy to use and uses the KeyPass file format. Some of its features are:

  • Supported Encryption Algorithms:
    • AES 256-bit
    • Twofish 256-bit
    • ChaCha20 256-bit
  • Supported Derivation algorithms:
    • Argon2 KDBX4
    • Argon2id KDBX4
    • AES-KDF KDBX 3.1
  • Create or import KeePass safes
  • Add attachments to your encrypted database
  • Generate cryptographically strong passwords
  • Quickly search your favorite entries
  • Automatic database lock during inactivity
  • Support for two-factor authentication

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

flatpak install flathub org.gnome.World.Secrets

Flatsweep

Flatsweep is a simple app to remove residual files after a flatpak is unistalled. It uses GTK4 and Libadwaita to provide a coherent user interface that integrates nicely with GNOME, but you can use it on any desktop environment.

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

flatpak install flathub io.github.giantpinkrobots.flatsweep

Solanum

Solanum is a time tracking app that uses the pomodoro technique. It uses GTK4 and it’s interface integrates nicely with GNOME.

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

flatpak install flathub org.gnome.Solanum
Posted on by — Leave a comment

Video content creation with Kdenlive

Fedora Linux packages a suite of graphical software for content creators. This article introduces a use case and suggestions for creating tutorial videos with Kdenlive.

Plan tutorial

A question that you need to address is whether text and images are appropriate to share your knowledge. If you create resources for learners of graphical software, a tutorial video is something to consider.

Review abstract and draft script

An abstract in content writing helps reviewers look for key points of your tutorial. Depending on your workflow, you can submit this abstract to reviewers for comments, questions, or updates.

Once an abstract of the tutorial video is agreed upon by the reviewers, a video script is created and works like a manuscript for your tutorial. Break down process steps into each sequence. Check this link for an example.

Screen recording

Use your preferred recording tool that comes with the desktop environment or enable the ‘Screen Grab’ option in Kdenlive in the ‘View’ menu. Alternatively, you can install OBS Studio.

Kdenlive can process various container formats. You should transcode to a high-quality lossless matroska file (.mkv) that ensures high quality and compression ratio.

Installation

Kdenlive supports Linux, Mac, Windows and FreeBSD, which encourages collaboration among content creators. If you are Linux users, go to the packager manager of your distro to install Kdenlive. If you use Fedora Linux, we recommend the Fedora Linux RPM version or Flatpak.

Set up Kdenlive

Let’s start with Kdenlive’s user interface and focus on three sections – Project bin, Monitors and Timeline.

Kdenlive user interface

Project bin

Load video clips into Project Bin on the upper left. The Project Bin lists all the clips that are associated with your project. You can drag and drop the clips onto Project Bin.

Monitors

Clip Monitor on the left window displays the unedited clip that is currently selected in The Project Bin. If you have loaded multiple takes of the same scene (process steps), you need to know which one you’re going to choose and edit. If you changed your mind during editing processes, that’s no problem. You can move around a sequence with timeline and tracks after the initial cut.

The Project Monitor is a place to watch your edited footage.

Timeline

Timeline is a place for all selected clips you edit. Drag and drop the clips directly on to the Timeline from the Project Bin.

Editing processes

Cut and stitch

Timeline cursor, also known as playhead, indicates the position of clips you are working on and previewing in the Project Monitor.

Timeline

The initial cut means editing on a scene by scene basis until you’re ready to stitch tracks together into a complete piece.

Cut when;
– Delayed, boring or repetitive part was recorded. This happens often when recording a scene for loading apps or waiting for rendering on web browser
– Transition pieces when a scene starts and ends
– Trim off a few frames before you tidy up
– Ensure basic continuity – let it flow!

In Timeline, video tracks (V2, V1) are cascaded up whereas audio tracks (A1, A2) are cascaded down as default.

Slide up trimmed video track and stitch frames you want to keep. Delete trimmed frames when you’re sure you don’t need them.

Cut

Timeline works like chef’s chopping board and takes time for new users to get familiar with it. Check the upstream documentation on this link.

Text effects with Titles

Titles are text elements that you can overlay to the timeline. To create Titles, right-click in the The Project Bin and open the Titles window as shown below. Select ‘Create Title’ to save it. Drag and drop the Title to the video track 2 in timeline. Check this link for more information.

Titler

Sound effects

Ambient music could jazz up your video tutorial for the audience.

Go to top left corner of the Project Bin and select the arrow to list options. Select ‘Online Resources’. At the top right, ‘Service’ drop-down menu, choose ‘Freesound’. Select ‘Preview’ to play back and import to download and overlay to A1 audio track.

Sound

Transition and finishing touch

Text and sounds effects will blend well if tracks have transitions. Check this link for fine-tuning your final cut video.

Rendering

In the Render dialogue box (Ctrl + Return) on Project Bin, choose WebM as output file, select ‘More options’ to de-select the Export Audio option, and select ‘Render to File’ to save the clip.

Rendering

WebM offers good compression and output.

Rendering speed is dependent on the number of CPU cores in your computer. If you work with high quality footage and visual effects in a computer with low-end CPU and RAM, adapt your workflow with proxy clips and use script for rendering.

Share your tutorial video

PeerTube is a video sharing platform that runs on GNU/Linux infra, and Open Source/Free Software. Just like Vimeo or YouTube, you can embed your content to your documentation site from PeerTube.

Credits and acknowledgements

Big thanks to Seth Kenlon who provided me with a great deal of inspiration from his publication in Opensource.com and Kdenlive workshop.

Kdenlive Version 23.04.2 was used for this article.

Posted on by — Leave a comment

Coming soon: Fedora for Apple Silicon Macs!

Today at Flock, we announced that Fedora Linux will soon be available on Apple Silicon Macs. Developed in close collaboration with the Fedora Asahi SIG and the Asahi Linux project, the Fedora Asahi Remix will provide a polished experience for Workstation and Server usecases on Apple Silicon systems. The Asahi Linux project has also announced that the new Asahi Linux flagship distribution will be Fedora Asahi Remix.

We are using a Remix as opposed to delivering this support in Fedora Linux proper because this ecosystem is still very fast moving and we believe a Remix will offer the best user experience for the time being. Also, the Remix will allow us to integrate hardware support as it becomes available. Nonetheless, as much of this work as possible is being conducted upstream, with several key components being developed, maintained and packaged in Fedora Linux upstream. Ultimately, we expect Apple Silicon support to be integrated in Fedora Workstation and Fedora Server in a future release, and are working towards this goal. This approach is in line with the overarching goal of the Asahi project itself to integrate support for these systems in the relevant upstream projects.

The first official release of Fedora Asahi Remix is slated to be available by the end of August 2023. Development builds are already available for testing at https://fedora-asahi-remix.org/, though they should be considered unsupported and likely to break until the official release.

Posted on by — Leave a comment

Get ready to Flock to Fedora!

A letter from Fedora Project Leader Matthew Miller

Hello Fedora friends! In just about a week, we will kick off Flock to Fedora — our annual contributor conference. I hope you’re as excited as I am! For the last three years, we’ve run this as a virtual event — we stayed cozy at home with Nest. Now, we’re back to in-person, and I can’t wait to see so many of you again as we flock together to meet in Cork, Ireland.

Flock is different from other conferences — it’s not a showcase or sales pitch, and it’s not a corporate event where we stand up for or root for the companies we work for or are fans of. Of course, we are grateful for our sponsors and our employers, but in Fedora in general — and especially at Flock! — that’s not what things are about. We come together in a positive spirit to collaborate and build. We’re a community of people, and friendship is a cornerstone value. Fedora is our community, and Flock is where we come together.

This year, we’re combining forces with our friends at the CentOS Project: CentOS Connect will be co-located with Flock. CentOS is a different kind of project, but the same approach applies: this is about community. I know there are a lot of strong feelings around Red Hat and CentOS and rebuilds and downstreams lately. Fedora doesn’t control any of that, but it affects us — so, I’m sure we’ll talk about it. (We even have a session related to the topic.) As we talk, though, let’s all keep in mind the spirit of our projects: working together collaboratively to build a better world with free and open source software for everyone. 

The Nest events were wonderful: the best virtual events during the whole pandemic, I think. While I obviously am biased about this, I think it’s fair, since I didn’t really do any of the organizing work. (Thanks to everyone who did, and especially to Marie Nordin!) This year, while we wish everyone could be there in person, we want to make the event as accessible as possible to those who can’t be there, so we will live-stream and record the sessions. I hope you’ll join as many sessions as your local time zone permits.

I look forward to talking about our in-progress strategy, and our goal of doubling the number of active Fedora contributors. I want to hear what all of you are working on, all the ideas you have, all the proposals and plans for the future. Most of all, though, I’m looking forward to seeing so many of my friends again, and making new connections. I hope you are too!

Be sure to check out the schedule. If you haven’t registered yet, don’t forget to do that!

Posted on by — Leave a comment

How to Install and Update Fedora Linux on Android using Termux

If you’re interested in running Linux on your Android device, you’re in luck! It’s possible to install Fedora Linux on Android using Termux. Termux is a terminal emulator for Android that allows you to run Linux commands and utilities on your phone or tablet. It does not replace Android. In this article, we’ll walk you through the process of installing Fedora Linux on Android using Termux and show you how to keep it up to date with the latest versions.

Step by step process

Step 1: Install Termux

To get started, you need to install Termux from the Google Play Store. Once you have Termux installed, open it up and type the following command to update the package list:

pkg update

Note: Termux requires Android >= 7 to run. Support for Android 5 and 6 was dropped at v0.83 on 2020-01-01, but you can find old builds on archive.org ( https://archive.org/details/termux-repositories-legacy/ ) if needed.

Step 2: Install Proot-Distro

Next, you’ll need to install Proot-Distro. Proot-Distro is a tool that allows you to install and run Linux distributions in a chroot environment. To install Proot-Distro, run the following command:

pkg install proot-distro

Step 3: Install Fedora

With Proot-Distro installed, you can now use it to install Fedora. To install Fedora, run the following command:

proot-distro install fedora

This will download and install the latest version of Fedora.

Step 4: Configure dnf

Now that you have Fedora installed, you’ll need to configure dnf, Fedora’s package manager. By default, dnf may try to install SELinux packages, which won’t work properly in a chroot environment. To prevent this, exclude SELinux packages installation by editing the dnf configuration file. Run the following command to open the dnf configuration file for editing :

cd ../usr/var/lib/proot-distro/installed-rootfs/fedora/etc/dnf
vi dnf.conf

You may substitute the nano editor for vi, if it is more to your liking. Once you’re in the file, find the line that says excludepkgs= and add *selinux* to the end of the line, like so:

excludepkgs=*selinux*

It may be necessary to add the excludepkgs line. Save these changes and exit the editor.

Step 5: Install a Desktop Environment (Optional)

Fedora comes with a number of desktop environments to choose from. If you’d like to install a desktop environment, you can do so with the following commands:

proot-distro login fedora
dnf groupinstall "Fedora Workstation" --skip-broken

This will switch from termux into the chroot Fedora installation and install the GNOME desktop environment, along with a number of other packages. If you prefer a different desktop environment, you can replace Fedora Workstation with the name of the group for your preferred environment.

Step 6: Install VNC Server (Optional)

If you plan on using your Fedora installation with a graphical interface, you’ll need to install a VNC server. This will allow you to connect to the Fedora desktop from another computer or device. To install the TigerVNC server, run the following command:

dnf install tigervnc-server.aarch64 -y

This will install the VNC server, along with any necessary dependencies.

Step 7: Upgrading Fedora

Now that you have Fedora installed, you’ll want to keep it up to date with the latest versions. To upgrade Fedora, run the following commands:

sudo dnf upgrade --refresh
sudo dnf install dnf-plugin-system-upgrade
sudo dnf system-upgrade download –releasever=37
export DNF_SYSTEM_UPGRADE_NO_REBOOT=1
sudo -E dnf system-upgrade reboot
sudo -E dnf system-upgrade upgrade
sudo dnf upgrade --refresh

First command sudo dnf upgrade –refresh refreshes the package cache and updates any installed packages.

The second command sudo dnf install dnf-plugin-system-upgrade installs the dnf-plugin-system-upgrade package, needed for the upgrade process.

The third command sudo dnf system-upgrade download –releasever=37 downloads the necessary packages for the upgrade to version 37 of Fedora. Replace 37 with the desired release version.

The fourth command export DNF_SYSTEM_UPGRADE_NO_REBOOT=1 sets an environment variable to prevent the system from rebooting after the upgrade.

The fifth command sudo -E dnf system-upgrade reboot reboots the system to start the upgrade process. Make sure to save any important work before running this command.

The sixth command sudo -E dnf system-upgrade upgrade performs the upgrade process.

Finally, the seventh command sudo dnf upgrade –refresh updates any remaining packages and ensures that your system is fully up to date.

Errors Encountered

During the installation and upgrade process, you may encounter errors. Two common errors are described below, along with their solutions.

Error 1: sudo: /etc/sudo.conf is owned by uid 1001, should be 0
Solution: This error occurs when the ownership of the sudo.conf file is incorrect. To fix this, run the following command:

chmod +s /usr/bin/sudo

This sets the setuid bit on the sudo command, which allows it to run with root privileges.

Error 2: filesystem package didn’t get upgraded post OS upgrade
Solution: This error occurs when the filesystem package is not upgraded during the upgrade process. To fix this, run the following commands:

sudo rpm -e --nodeps filesystem
dnf download filesystem

The first command removes the filesystem package, and the second command downloads the latest version of the package. If you encounter any errors during the upgrade process, you can use rpmrebuild to rebuild the package with any necessary modifications.

Conclusion

In this article, we’ve shown you how to install Fedora Linux on Android using Termux and how to keep it up to date with the latest versions. While there may be some errors to overcome during the installation and upgrade process, following the steps outlined in this article should help you get Fedora up and running on your Android device in no time.

Posted on by — Leave a comment

Packit – how to trigger jobs manually

Packit is an open-source project aiming to ease the integration of your project with Fedora Linux, CentOS Stream, and other distributions. Projects that use Packit usually build RPM packages. This article will introduce new features. The new user onboarding process is available here.

Testing Farm execution

From Packit you can easily trigger your tests on Testing Farm without building the RPMs. This is very handy for projects that basically may not build RPMs, but just want to use these two services for verifying the code. As a good example, we refer to the Strimzi project where users consume container images.

In such cases, the users just want to trigger the tests, verify the code and see some output. This option is available from the beginning. Users can easily define when the tests will be executed – for every pull request, for every commit, or for releases. That sounds pretty cool. However, when you have complex tests (5h+ per test run as we have in Strimzi) you probably don’t want to trigger all tests for each commit. So how can the users achieve that?

Manual Trigger

We introduced a new configuration option, manual_trigger, to enable triggering Packit jobs only manually. With this new configuration of Packit jobs, users can easily enable the manual triggering of a job. The job will NOT automatically trigger when, for example, a new commit arrives to pull a request.

Users need to specify manual_trigger in the test’s job description. The value for this option must be boolean and will default to False. The following is an example of the use of this option. A more complete example is available here.

... - job: tests trigger: pull_request identifier: "regression-operators" targets: - centos-stream-9-x86_64 - centos-stream-9-aarch64 skip_build: true manual_trigger: true labels: - regression - operators - regression-operators - ro tf_extra_params: test: fmf: name: regression-operators
...

This new configuration option allows users to utilize a new flow. When a pull request is opened (for example in draft mode), users push new commits and fixes, or when they are about to finish the pull request, they can easily type /packit test as a pull request comment and all jobs defined in packit.yaml for pull request will be triggered.

Labeling and identifying

The above solution is very easy to use. There might be use cases, however, where users don’t want to trigger all the jobs. For example, when you have 10 jobs defined with different test scopes, you probably don’t want to trigger acceptance and regression tests at the same time since acceptance could be a subset of regression.

There are now two options to trigger a specific job. The first one is to trigger the job based on an identifier. If the user specifies identifier: test-1 in the job configuration, Packit comment command for execution of the tests will look like this /packit test –identifier test1. This command will execute jobs with the specific identifier (test-1) and nothing else.

An example how to trigger testing-farm test job via Packit with --identifier parameter.

The second option for triggering specific jobs allows you to execute more than one job based on their identifiers. You can use multiple identifiers in a comma-separated list but it might be cumbersome to specify long lists of identifiers every time. To add a better user experience we’ve introduced the labels configuration that allows grouping together multiple jobs. The command /packit test –labels upgrade,regression will trigger all jobs that contain upgrade or regression in the list of labels in the job configuration.

An example how to trigger testing-farm test job via Packit with --labels parameter.

Conclusion

If you hesitated to utilize Packit due to the limitation of missing manual triggering of the jobs or missing labeling, you can start now! As mentioned, Packit is an open-source service and these improvements were done as contributions from outside of the Packit team, everyone can contribute so if you are missing some features, feel free to open a pull request!

For more information about newly added options you should check the documentation. In case you are new to Packit you can also view the talk from the Packit team from DevConf 2023 or DevConf Mini 2023. ​

Posted on by — Leave a comment

Fedora Linux editions part 4: Alt Downloads

Fedora Alt Downloads is a remarkable resource provided by the Fedora Project, offering alternative distribution options for users seeking specific requirements or unique use cases. This article will delve into the diverse selection of Fedora Alt Downloads, highlighting their significance and how they cater to different needs within the Fedora community. You can find an overview of all the Fedora Linux variants in my previous article Introduce the different Fedora Linux editions.

Network Installer

The Fedora Network Installer is an efficient and flexible tool for installing Fedora Linux. This is Fedora’s online installer. Unlike the baked-in Live images that the main editions use, this installer allows you to customize which software packages will be installed at installation time. However, because the packages to be installed are not baked into this installer image, network access will be required at installation time to download the selected packages.

Don’t confuse this with network booting which is a method of initiating an operating system or operating system installer from a small Preboot Execution Environment. (Though it is possible for that sort of bootloader to chain-load Fedora’s network installer.)

Torrent Downlods

Fedora Torrent Downloads utilize the BitTorrent protocol, which is a peer-to-peer file sharing protocol. Instead of relying on a central server for downloads, BitTorrent enables users to download Fedora Linux images from multiple sources simultaneously. This decentralized approach enhances download speeds and reduces strain on individual servers, resulting in a faster and more reliable download experience. Fedora Torrent Downloads offer a fast, reliable, and community-driven method for obtaining Fedora Linux images. By harnessing the power of the BitTorrent protocol, Fedora leverages the collective bandwidth and resources of users worldwide, resulting in faster downloads and improved reliability.

Details are available at this link: https://torrent.fedoraproject.org/

Alternate Architectures

Fedora Alternate Architectures is an initiative by the Fedora Project that aims to expand the compatibility of the Fedora Linux operating systems by offering a range of architecture options. In addition to the standard x86_64 architecture, Fedora Alternate Architectures provides support for alternative architectures, including ARM AArch64, Power, and s390x. This initiative allows you to select the architecture that best suits their hardware requirements, enabling Fedora Linux to run on a diverse range of devices and systems. Whether you have a Raspberry Pi, a server with Power processors, or other specialized hardware, Fedora Alternate Architectures ensures that you have a tailored Fedora Linux experience that meets your specific needs.

Details are available at this link: https://alt.fedoraproject.org/alt/

Fedora Cloud

After I wrote my initial post in this series that introduced the main Fedora Linux editions, Fedora Cloud was restored to full edition status. There are still some links to the Fedora Cloud images on the Fedora Alt Downloads page. But they will be removed soon. The correct place to get the latest Fedora Cloud images is now https://fedoraproject.org/cloud/download/.

Fedora Cloud images are a collection of images provided by the Fedora Project for use in cloud environments. Fedora Cloud images are specifically designed to run applications in the cloud with efficiency and optimal performance. By using Fedora Cloud images, you can quickly deploy and run applications in the cloud without the need to spend time configuring the operating system from scratch. Fedora Cloud images also provide flexibility in terms of scalability, allowing you to easily adjust the size and capacity of resources according to the needs of your applications.

Testing Images

Fedora Testing Images are a collection of specialized system images designed for testing and contributing to the development of Fedora Linux. These images allow you to test the latest features, explore the recent changes in Fedora Linux, and report any issues encountered. By using Fedora Testing Images, you can actively participate in the development of Fedora Linux by providing valuable feedback and contributions.

Your participation in testing and contributing to Fedora Testing Images plays a vital role in maintaining and improving the quality and reliability of Fedora Linux. By reporting issues, testing software, and providing feedback, you can assist Fedora developers in fixing bugs, enhancing performance, and identifying areas for further improvement and development. Fedora Testing Images provide an easy and secure way for you to engage directly in the development of Fedora Linux, strengthening the community and resulting in a better and more reliable operating system for all Fedora users.

Rawhide

Fedora Rawhide is the development branch of the Fedora Linux operating system. It provides a continuously evolving and cutting-edge version of the Fedora Linux OS. It serves as a testing ground for new features, enhancements, and software updates that are targeted for inclusion in future stable releases of Fedora Linux. Fedora Rawhide offers early access to the latest software packages, allowing users to stay at the forefront of technology and contribute to the testing and refinement of Fedora Linux.

Using Fedora Rawhide comes with both benefits and considerations. On one hand, it provides a platform for early adopters, developers, and contributors to test and provide feedback on upcoming features and changes. This helps identify and address issues before they are included in stable releases. On the other hand, since Fedora Rawhide is constantly under development, it may encounter bugs, instability, and compatibility issues. Therefore, it is recommended only for experienced users who are comfortable with troubleshooting and actively contributing to the Fedora community.

Details are available at this link: https://docs.fedoraproject.org/en-US/releases/rawhide/

Conclusion

Fedora Alt Downloads provides an impressive array of alternative distributions, catering to diverse needs within the Fedora community. Whether it’s through Fedora Spins, Fedora Labs, Fedora Remixes, Fedora Silverblue, or ARM editions, users can find specialized distributions that suit their requirements, preferences, and use cases. This versatility and community-driven approach makes Fedora Alt Downloads a valuable resource for Fedora Linux enthusiasts, fostering innovation, and customization within the Fedora ecosystem. You can find complete information about Fedora Alt Downloads at https://alt.fedoraproject.org/

Posted on by — Leave a comment

Contribute at the Fedora Linux Test Week for Kernel 6.4

The kernel team is working on final integration for Linux kernel 6.4. This version was just recently released, and will arrive soon in Fedora Linux. As a result, the Fedora Linux kernel and QA teams have organized a test week from Sunday, July 09, 2023 to Sunday, July 16, 2023. The wiki page in this article contains links to the test images you’ll need to participate. Please continue reading for details.

How does a test week work?

A test week is an event where anyone can help ensure 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 do the following things:

  • Download test materials, which include some large files
  • Read and follow directions step by step

The wiki page for the kernel test day has a lot of good information on what and how to test. After you’ve done some testing, you can log your results in the test day web application. If you’re available on or around the days of the event, please do some testing and report your results. We have a document which provides all the necessary steps.

Happy testing, and we hope to see you on one of the test days.