Language Selection

English French German Italian Portuguese Spanish

Fedora Magazine

Syndicate content
Guides, information, and news about the Fedora operating system for users, developers, system administrators, and community members.
Updated: 1 day 11 min ago

Set up two-factor authentication for SSH on Fedora

Wednesday 20th of February 2019 08:00:40 AM

Every day there seems to be a security breach reported in the news where our data is at risk. Despite the fact that SSH is a secure way to connect remotely to a system, you can still make it even more secure. This article will show you how.

That’s where two-factor authentication (2FA) comes in. Even if you disable passwords and only allow SSH connections using public and private keys, an unauthorized user could still gain access to your system if they steal your keys.

With two-factor authentication, you can’t connect to a server with just your SSH keys. You also need to provide the randomly generated number displayed by an authenticator application on a mobile phone.

The Time-based One-time Password algorithm (TOTP) is the method shown in this article. Google Authenticator is used as the server application. Google Authenticator is available by default in Fedora.

For your mobile phone, you can use any two-way authentication application that is compatible with TOTP. There are numerous free applications for Android or IOS that work with TOTP and Google Authenticator. This article uses FreeOTP as an example.

Install and set up Google Authenticator

First, install the Google Authenticator package on your server.

$ sudo dnf install -y google-authenticator

Run the application.

$ google-authenticator

The application presents you with a series of questions. The snippets below show you how to answer for a reasonably secure setup.

Do you want authentication tokens to be time-based (y/n) y
Do you want me to update your "/home/user/.google_authenticator" file (y/n)? y

The app provides you with a secret key, verification code, and recovery codes. Keep these in a secure, safe location. The recovery codes are the only way to access your server if you lose your mobile phone.

Set up mobile phone authentication

Install the authenticator application (FreeOTP) on your mobile phone. You can find it in Google Play if you have an Android phone, or in the iTunes store for an Apple iPhone.

A QR code is displayed on the screen. Open up the FreeOTP app on your mobile phone. To add a new account, select the QR code shaped tool at the top on the app, and then scan the QR code. After the setup is complete, you’ll have to provide the random number generated by the authenticator application every time you connect to your server remotely.

Finish configuration

The application asks further questions. The example below shows you how to answer to set up a reasonably secure configuration.

Do you want to disallow multiple uses of the same authentication token? This restricts you to one login about every 30s, but it increases your chances to notice or even prevent man-in-the-middle attacks (y/n) y
By default, tokens are good for 30 seconds. In order to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. If you experience problems with poor time synchronization, you can increase the window from its default size of +-1min (window size of 3) to about +-4min (window size of 17 acceptable tokens).
Do you want to do so? (y/n) n
If the computer that you are logging into isn't hardened against brute-force login attempts, you can enable rate-limiting for the authentication module. By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting (y/n) y

Now you have to set up SSH to take advantage of the new two-way authentication.

Configure SSH

Before completing this step, make sure you’ve already established a working SSH connection using public SSH keys, since we’ll be disabling password connections. If there is a problem or mistake, having a connection will allow you to fix the problem.

On your server, use sudo to edit the /etc/pam.d/sshd file.

$ sudo vi /etc/pam.d/ssh

Comment out the auth substack password-auth line:

#auth       substack     password-auth

Add the following line to the bottom of the file.

auth sufficient

Save and close the file. Next, edit the /etc/ssh/sshd_config file.

$ sudo vi /etc/ssh/sshd_config

Look for the ChallengeResponseAuthentication line and change it to yes.

ChallengeResponseAuthentication yes

Look for the PasswordAuthentication line and change it to no.

PasswordAuthentication no

Add the following line to the bottom of the file.

AuthenticationMethods publickey,password publickey,keyboard-interactive

Save and close the file, and then restart SSH.

$ sudo systemctl restart sshd Testing your two-factor authentication

When you attempt to connect to your server you’re now prompted for a verification code.

[user@client ~]$ ssh
Verification code:

The verification code is randomly generated by your authenticator application on your mobile phone. Since this number changes every few seconds, you need to enter it before it changes.

If you do not enter the verification code, you won’t be able to access the system, and you’ll get a permission denied error:

[user@client ~]$ ssh
Verification code:
Verification code:
Verification code:
Permission denied (keyboard-interactive).
[user@client ~]$ Conclusion

By adding this simple two-way authentication, you’ve now made it much more difficult for an unauthorized user to gain access to your server.

Building Flatpak apps in Gnome Builder on Fedora Silverblue

Monday 18th of February 2019 09:10:40 AM

If you are developing software using Fedora Silverblue, and especially if what you are developing is a Gnome application, Gnome Builder 3.30.3 feels like an obvious choice of IDE.

In this article, I will show you how you can create a simple Gnome application, and how to build it and install it as a Flatpak app on your system.

Gnome and Flatpak applications

Builder has been a part of Gnome for a long time. It is a very mature IDE to me in terms of consistency and completeness.

The Gnome Builder project website offers extensive documentation regarding Gnome application development — I highly recommend spending some time there to anyone interested.

Editor’s note: Getting Builder

Because the initial Fedora Silverblue installation doesn’t include Builder, let’s walk through the installation process first.

Starting with a freshly installed system, the first thing you’ll need to do is to enable a repository providing Builder as a Flatpak — we’ll use Flathub which is a popular 3rd-party repository with many desktop apps.

To enable Flathub on your system, download the repository file from the Fedora Quick Setup page, and double-click it which opens Gnome Software asking you to enable this repository on your system.

After you’re done with that, you can search for Builder in Gnome Software and install it.

Creating a new project

So let’s walk through the creation of a new project for our Gnome app. When you start Gnome Builder, the first display is oriented towards project management.

To create a new project, I clicked on the New… button at the top-left corner which showed me the following view.

You’ll need to fill out the project name, choose your preferred language (I chose C, but other languages will work for this example as well), and the license. Leave the version control on, and select Gnome Application as your template.

I chose gbfprtfsb as the name of my project which means Hello from Gnome 3 on Fedora SilverBlue.

The IDE creates and opens the project once you press create.

Tweaking our new project

The newly created project is opened in the Builder IDE and on my system looks like the following.

This project could be run from within the IDE right now and would give you the ever popular “Hello World!” titled gnome windowed application with a label that says, yup “Hello World!”.

Let’s get a little disruptive and mess up the title and greeting a bit. Complacency leads to mediocrity which leads to entropy overcoming chaos to enforce order, stasis, then finally it all just comes to a halt. It’s therefore our duty to shake it up at every opportunity, if only to knock out any latent entropy that may have accumulated in our systems. Towards such lofty goals, we only need to change two lines of one file, and the file isn’t even a C language file, it’s an XML file used to describe the GUI named gbfprtfsb-window.ui. All we have to do is open it and edit the title and label text, save and then build our masterpiece!

Looking at the screenshot below, I have circled the text we are going to replace. The window is a GtkApplicationWindow, and uses a GtkHeaderBar and GtkLabel to display the text we are changing. In the GtkHeaderBar we will type GBFPRTFSB for the title property. In the GtkLabel we will type Hello from Gnome 3 on Fedora SilverBlue in the label property. Now save the file to record our changes.

Building the project

Well, we have made our changes, and expressed our individualism (cough) at the same time. All that is left is to build it and see what it looks like. The build panel is located near the top of the IDE, middle right, and is represented by the icon that appears to be a brick wall being built as shown on the following picture.

Press the button, and the build process completes. You can also preview your application by clicking on the “play” button next to it.

Building a Flatpak

When we’re happy with our creation, the next step will be building it as a Flatpak. To do that, click on the title in the middle of the top bar, and then on the Export Bundle button.

Once the export has successfully completed, Gnome Builder will open a Nautilus file browser window showing the export directory, with the Flatpak bundle already selected.

To install the app on your system, simply double-click the icon which opens Gnome Software allowing you to install the app. On my system I had to enter my user password twice, which I take to be due to the fact we had no configured GPG key for the project. After it was installed, the application was shown alongside all of the other applications on my system. It can be seen running below.

I think this has successfully shown how easy it is to deploy an application as a Flatpak bundle for Gnome using Builder, and then running it on Fedora Silverblue.

How to watch for releases of upstream projects

Friday 15th of February 2019 08:00:20 AM

Do you want to know when a new version of your favorite project is released? Do you want to make your job as packager easier? If so, this article is for you. It introduces you to the world of You’ll see how it can help you catch up with upstream releases.

What is

The is a combination of two applications: Anitya and the-new-hotness.

Anitya is what you can see when visiting You can use it to add and manage your projects. Anitya also checks for new releases periodically.

The-new-hotness is an application that catches the messages emitted by Anitya. It creates a Bugzilla issue if the project is mapped to a Fedora package.

How to use

Now that you know how it works, let’s focus on how you can use it.

Index page of

First think you need to do is to log in. Anitya provides a few options you can use to log in, including the Fedora Account System (FAS), Yahoo!, or a custom OpenID server.

Login page

When you’re logged in, you’ll see new options in the top panel.

Anitya top panel Add a new project

Now you can add a new project. It’s always good to check whether the project is already added.

Add project form

Next, fill in the information about the project:

  • Project name – Use the upstream project name
  • Homepage – Homepage of the project
  • Backend – Backend is simply the web hosting where the project is hosted. Anitya offers many backends you can chose from. If you can’t find a backend for your project, you can use the custom backend. Every backend has its own additional fields. For example, BitBucket has you specify owner/project.
  • Version scheme – This is used to sort received versions. Right now, Anitya only supports RPM version scheme.
  • Version prefix – This is the prefix that is stripped from any received version. For example, if the tag on GitHub is version_1.2.3, you would use version_ as version prefix. The version will then be presented as 1.2.3. The version prefix v is stripped automatically.
  • Check latest release on submit – If you check this, Anitya will do an initial check on the project when submitted.
  • Distro – The distribution in which this project is used. This could be also added later.
  • Package – The project’s packaged name in the distribution. This is required when the Distro field is filled in.

When you’re happy with the project, submit it. Below you can see how your project may look after you submit.

Project page Add a new distribution mapping

If you want to map the project to a package on a specific distribution, open up the project page first and then click on Add new distribution mapping.

Add distribution mapping form

Here you can chose any distribution already available in Anitya, fill in the package name, and submit it. The new mapping will show up on the project page.

Automatic filing of Bugzilla issues

Now you created a new project and created a mapping for it. This is nice, but how does this help you as a packager? This is where the-new-hotness comes into play.

Every time the-new-hotness sees a new update or new mapping message emitted by Anitya, it checks whether this project is mapped to a package in Fedora. For this to work, the project must have a mapping to Fedora added in Anitya.

If the package is known, the-new-hotness checks the notification setting for this package. That setting can be changed here. The last check the-new-hotness does is whether the version reported by Anitya is newer than the current version of this package in Fedora Rawhide.

If all those checks are positive, the new Bugzilla issue is filed and a Koji scratch build started. After the Koji build is finished, the Bugzilla is updated with output.

Future plans for

The system is pretty amazing, isn’t it? But this isn’t all. There are plenty of things planned for both Anitya and the-new-hotness. Here’s a short list of future plans:

  • Add consumer – automatically check for new releases on, create projects in Anitya and emit messages about updates
  • Use Fedora package database to automatically guess the package name in Fedora based on the project name and backend
  • Add semantic and calendar version scheme
  • Change current cron job to service: Anitya checks for new versions periodically using a cron job. The plan is to change this to a service that checks projects using queues.
  • Support for more than one version prefix
  • File Github issues for Flathub projects when a new version comes out
  • Create pull requests in Pagure instead of filing a Bugzilla issue
  • Move to OpenShift – this should make deployment much easier than how it is now
  • Convert to Python 3 (mostly done)
  • Conversion to fedora-messaging – This is already in progress and should make communication between Anitya and the-new-hotness more reliable.

Photo by Alexandre Debiève on Unsplash.

Python 3.8 alpha in Fedora

Wednesday 13th of February 2019 11:42:31 PM

The Python developers have released the first alpha of Python 3.8.0 and you can already try it out in Fedora! Test your Python code with 3.8 early to avoid surprises once the final 3.8.0 is out in October.

Install Python 3.8 on Fedora

If you have Fedora 29 or newer, you can install Python 3.8 from the official software repository with dnf:

$ sudo dnf install python38

As more alphas, betas and release candidates of Python 3.8 will be released, the Fedora package will receive updates. No need to compile your own development version of Python, just install it and have it up to date. New features will be added until the first beta.

Test your projects with Python 3.8

Run the python3.8 command to use Python 3.8 or create virtual environments with the builtin venv module, tox or with pipenv. For example:

$ git clone
Cloning into 'six'...
$ cd six/
$ tox -e py38
py38 runtests: commands[0] | python -m pytest -rfsxX
================== test session starts ===================
platform linux -- Python 3.8.0a1, pytest-4.2.1, py-1.7.0, pluggy-0.8.1
collected 195 items ...................................... [ 19%]
.................................................. [ 45%]
.................................................. [ 70%]
..............................................s... [ 96%]
....... [100%]
========= 194 passed, 1 skipped in 0.25 seconds ==========
________________________ summary _________________________
py38: commands succeeded

Convert your Fedora Silverblue to HTPC with Kodi

Wednesday 13th of February 2019 09:38:21 AM

Ever wanted to create a HTPC from old computer laying around. Or just have some spare time and want to try something new. This article could be just for you. It will show you the step by step process to convert a Fedora Silverblue to a fully fledged HTPC.

What is Fedora Silverblue, Kodi and HTPC?

Fedora Silverblue is a system similar to Fedora Workstation. It offers an immutable filesystem (only /var and /etc are writable) and atomic updates using an ostree image, which offers reliable updates with ability to rollback to previous version easily. If you want to find out more about Fedora Silverblue visit or if you want to try it by yourself you can get it here.

Kodi is one of the best multimedia player available. It provides plenty of features (like automatic downloads of metadata for movies, support for UPnP etc.) and it’s open source. It also has many addons. So if you are missing any functionality you could probably find an addon for it.

HTPC is just an acronym for Home Theater PC in simple words a PC that is mainly used as an entertainment station. You can connect it to TV or any monitor and just use it to watch your favorite movies, TV shows or listen to your favorite music.

Why choosing Silverblue to create an HTPC?

So why choosing Fedora Silverblue for HTPC? The main reasons are:

  • Reliability – you don’t need to fear that after update everything stop working and if it does, I can rollback easily
  • New technology – it is a good opportunity to play with a new technology.

And why to choose Kodi ? As stayted before it’s one of the best multimedia player and it’s packaged as a flatpak, which make it easy to install on Silverblue.

Conversion of Fedora Silverblue to HTPC

Let’s go step by step through this process and see how to create a fully usable HTPC from Fedora Silverblue.

1. Installation of Fedora Silverblue

First thing you need to do is to install Fedora Silverblue, this guide will not cover the installation process, but you can expect similar process as with standard Fedora Workstation installation. You can get the Fedora Silverblue ISO here

Don’t create any user during the installation, just set root password. We will create a user for Kodi later.

2. Creation of user for Kodi

When you are in the terminal logged as root, you need to create a user that will be used by Kodi. This can be done using the useradd command.

Go through GNOME initial setup and create a kodi user. You will need to provide a password. The created kodi user will have sudo permissions, but we will remove them at the end.

It’s also recommended you upgrade Fedora Silverblue. Press the Super key (this is usually the key between Alt and Ctrl) and type terminal. Then start the upgrade.

rpm-ostree upgrade

And reboot the system.

systemctl reboot
3. Installation of Kodi from Flathub

Open a terminal and add a Flathub remote repository.

flatpak remote-add --if-not-exists flathub

With the Flathub repository added the installation of Kodi is simple.

flatpak install flathub tv.kodi.Kodi
4. Set Kodi as autostart application

First, create the autostart directory.

mkdir -p /home/kodi/.config/autostart

Then create a symlink for the Kodi desktop file.

ln -s /var/lib/flatpak/exports/share/applications/tv.kodi.Kodi.desktop /home/kodi/.config/autostart/tv.kodi.Kodi.desktop 5. Set autologin for kodi user

This step is very useful together with autostart of Kodi. Every time you restart your HTPC you will end up directly in Kodi and not in the GDM or GNOME shell. To set the auto login you need to add the following lines to /etc/gdm/custom.conf to the [daemon] section

AutomaticLogin=kodi 6. Enable automatic updates

For HTPC automatic updates we will use systemd timers. First create a /etc/systemd/system/htpc-update.service file with following content.

Description=Update HTPC

ExecStart=/usr/bin/sh -c 'rpm-ostree upgrade; flatpak update -y; systemctl reboot'

Then create a /etc/systemd/system/htpc-update.timer file with following content.

Description=Run htpc-update.service once a week

OnCalendar=Wed *-*-* 04:00:00

Start the timer from terminal.

systemctl start htpc-update.timer

You can check if the timer is set with the following command.

systemctl list-timers

This timer will run at 4:00 a.m. each Wednesday. It is recommended to set this to a time when nobody will use the HTPC.

7. Remove root permissions

Now you don’t need root permissions for kodi anymore, so remove it from the wheel group. To do this type following command in a terminal.

sudo usermod -G kodi kodi 8. Disable GNOME features

There are few GNOME features that could be annoying when using Fedora Silverblue as HTPC. Most of these features could be setup directly in Kodi anyway, so if you want them later it’s easy to set them directly in Kodi.

To do this, type the following commands.

# Display dim
dconf write "/org/gnome/settings-daemon/plugins/power/idle-dim" false

# Sleep over time/
dconf write "/org/gnome/settings-daemon/plugins/power/sleep-inactive-ac-type" 0

# Screensaver
dconf write "/org/gnome/desktop/screensaver/lock-enabled" false

# Automatic updates through gnome-software
dconf write "/org/gnome/software/download-updates" false

And that’s it, you just need to do one last restart to apply the dconf changes. After the restart you will end up directly in Kodi.

Kodi What now?

Now I will recommend you to play with the Kodi settings a little bit and set it up to your liking. You can find plenty of guides on the internet.

If you want to automate the process you can use my ansible script that was written just for this occasion.

EDITOR’S NOTE: This article has been edited since initial publication to reflect various improvements and to simplify the procedure.

Photo by Sven Scheuermeier on Unsplash

Deploy a Django REST service on OpenShift

Monday 11th of February 2019 09:00:32 AM

In a previous article we have seen how to build a “To Do” application using the Django REST Framework. In this article we will look on how we can use Minishift to deploy this application on a local OpenShift cluster.


This article is the second part of a series, you should make sure that you have read the first part linked right below. All the code from the first part is available on GitHub.

Build a Django RESTful API on Fedora. Getting started with Minishift

Minishift allows you to run a local OpenShift cluster in a virtual machine. This is very convenient when developing a cloud native application.

Install Minishift

To install Minishift the first thing to do is to download the latest release from their GitHub repository.

For example on Fedora 29 64 bit, you can download the following release

$ cd ~/Download
$ curl -LO

The next step is to copy the content of the tarball into your preferred location for example ~/.local/bin

$ cp ~/Download/minishift-1.31.0-linux-amd64.tgz ~/.local/bin
$ cd ~/.local/bin
$ tar xzvf minishift-1.31.0-linux-amd64.tgz
$ cp minishift-1.31.0-linux-amd64/minishift .
$ rm -rf minishift-1.31.0-linux-amd
$ source ~/.bashrc

You should now be able to run the minishift command from the terminal

$ minishift version
minishift v1.31.0+cfc599 Set up the virtualization environment

To run, Minishift needs to create a virtual machine, therefore we need to make sure that our system is properly configured. On Fedora we need to run the following commands:

$ sudo dnf install libvirt qemu-kv
$ sudo usermod -a -G libvirt $(whoami)
$ newgrp libvirt
$ sudo curl -L -o /usr/local/bin/docker-machine-driver-kvm
$ sudo chmod +x /usr/local/bin/docker-machine-driver-kv Starting Minishift

Now that everything is in place we can start Minishift by simply running:

$ minishift start
-- Starting profile 'minishift'

The server is accessible via web console at:

Using the URL provided (make sure to use your cluster IP address) you can access the OpenShift web console and login using the username developer and password developer.

If you face any problem during the Minishift installation, it is recommended to follow the details of the installation procedure.

Building the Application for OpenShift

Now that we have a OpenShift cluster running locally, we can look at adapting our “To Do” application so that it can deployed on the cluster.

Working with PostgreSQL

To speed up development and make it easy to have a working development environment in the first part of this article series we used SQLite as a database backend. Now that we are looking at running our application in a production like cluster we add support for PostgreSQL.

In order to keep the SQLite setup working for development we are going to create a different settings file for production.

$ cd django-rest-framework-todo/todo_app
$ mkdir settings
$ touch settings/
$ cp settings/
$ mv settings/
$ tree settings/

Now that we have 2 settings files — one for local development and one for production — we can edit to use the PostgreSQL database settings.

In todo_app/settings/ replace the DATABASE dictionary with the following:

"default": {
"ENGINE": "django.db.backends.postgresql",
"NAME": "todoapp",
"USER": "todoapp",
"PASSWORD": os.getenv("DB_PASSWORD"),
"HOST": os.getenv("DB_HOST"),
"PORT": "",

As you can see, we are using Django PostgreSQL backend and we are also making use of environment variables to store secrets or variables that are likely to change.

While we are editing the production settings, let’s configure another secret the SECRET_KEY, replace the current value with the following.

DEBUG = False


We edited the ALLOWED_HOSTS variable to allow any host or domain to be served by django and we have also set the DEBUG variable to False. Finally we are configuring the Django REST Framework to render only JSON, this means that we will not have an HTML interface to interact with the service.

Building the application

We are now ready to build our application in a container, so that it can run on OpenShift. We are going to use the source-to-image (s2i) tool to build a container directly from the git repository. That way we do not need to worry about maintaining a Dockerfile.

For the s2i tool to be able to build our application, we perform a few changes to our repository. First, let’s create a requirements.txt file to list the dependencies needed by the application.

Create django-rest-framework-todo/requirement.txt and add the following:


psycopg2-binary is the client use to connect to PostgreSQL database, and gunicorn is the web server we are using to serve the application.

Next we need to make sure to use the production settings. In django-rest-framework-todo/ and django-rest-framework-todo/ edit the following line:

os.environ.setdefault('DJANGO_SETTINGS_MODULE','todo_app.settings.production') Application Deployment

That’s it, we can now create a new project in OpenShift and deploy the application. First let’s login to Minishift using the command line tool.

$ oc login
Authentication required for (openshift)
Username: developer
Password: developer
Login successful.
$ oc new-project todo
Now using project "todo" on server "".

After login in the cluster we have created a new project “todo” to run our application. The next step is to create a PostgreSQL application .

$ oc new-app postgresql POSTGRESQL_USER=todoapp POSTGRESQL_DATABASE=todoapp POSTGRESQL_PASSWORD=todoapp

Note that we are passing the environment variable needed to configure the database service, these are the same as our application settings.

Before we create our application, we need to know what is the database host address.

$ oc get service
postgresql ClusterIP 5432/TCP 3m

We will use the CLUSTER-IP to configure the DB_HOST environment variable of our Django application.

Let’s create the application:

oc new-app centos/python-36-centos7~ DJANGO_SECRET_KEY=a_very_long_and_random_string DB_PASSWORD=todoapp DB_HOST=

We are using the centos/python-36-centos7 s2i image with a source repository from GitHub. Then we set the needed environment variable DJANGO_SECRET_KEY, DB_PASSWORD and DB_HOST.

Note that we are using the production branch from that repository and not the default master branch.

The last step is to make the application available outside of the cluster. For this execute the following command.

$ oc expose svc/django-rest-framework-todo
$ oc get route

You can now use the HOST/PORT address to access the web service.

Note that the build take couple minutes to complete.

Testing the application

Now that we have our service running we can use HTTPie to easily to test it. First let’s install it.

$ sudo dnf install httpie

We can now use the http command line to send request to our serivce.

$ http -v GET

$ http -v POST title="Task 1" description="A new task"
"description": "A new task",
"id": 1,
"status": "todo",
"title": "Task 1"
$ http -v PATCH status="wip"
"status": "wip"
$ http --follow -v GET
"description": "A new task",
"id": 1,
"status": "todo",
"title": "Task 1"
} Conclusion

In this article, we have learned how to install Minishift on a local development system and how to build and deploy a Django REST application on OpenShift. The code for this article is available on GitHub.

Photo by chuttersnap on Unsplash

Fedora logo redesign

Thursday 7th of February 2019 10:45:19 AM

The current Fedora Logo has been used by Fedora and the Fedora Community since 2005. However, over the past few months, Máirín Duffy and the Fedora Design team, along with the wider Fedora community have been working on redesigning the Fedora logo.

Far from being just an arbitrary logo change, this process is being undertaken to solve a number of issues encountered with the current logo. Some of the issues with the current logo include the lack of a single colour variant, and, consequently the logo not working well on dark backgrounds. Other challenges with the current logo is confusion with other well-known brands, and the use of a proprietary font.

The new Fedora Logo design process

Last month, Máirín posted an amazing article about the history of the Fedora logo, a detailed analysis of the challenges with the current logo, and a proposal of two candidates. A wide ranging discussion with the Fedora community followed, including input from Matt Muñoz, the designer of the current Fedora logo. After the discussions, the following candidate was chosen for further iteration:

In a follow-up post this week, Máirín summarizes the discussions and critiques that took place around the initial proposal, and details the iterations that took place as a result.

After all the discussions and iterations, the following 3 candidates are where the team is currently at:

Join the discussion on the redesign over at Máirín’s blog, and be sure to read the initial post to get the full story on the process undertaken to get to this point.

4 cool new projects to try in COPR for February 2019

Wednesday 6th of February 2019 08:00:40 AM

COPR is a collection of personal repositories for software that isn’t carried in Fedora. Some software doesn’t conform to standards that allow easy packaging. Or it may not meet other Fedora standards, despite being free and open source. COPR can offer these projects outside the Fedora set of packages. Software in COPR isn’t supported by Fedora infrastructure or signed by the project. However, it can be a neat way to try new or experimental software.

Here’s a set of new and interesting projects in COPR.


CryFS is a cryptographic filesystem. It is designed for use with cloud storage, mainly Dropbox, although it works with other storage providers as well. CryFS encrypts not only the files in the filesystem, but also metadata, file sizes and directory structure.

Installation instructions

The repo currently provides CryFS for Fedora 28 and 29, and for EPEL 7. To install CryFS, use these commands:

sudo dnf copr enable fcsm/cryfs
sudo dnf install cryfs Cheat

Cheat is a utility for viewing various cheatsheets in command-line, aiming to help remind usage of programs that are used only occasionally. For many Linux utilities, cheat provides cheatsheets containing condensed information from man pages, focusing mainly on the most used examples. In addition to the built-in cheatsheets, cheat allows you to edit the existing ones or creating new ones from scratch.

Installation instructions

The repo currently provides cheat for Fedora 28, 29 and Rawhide, and for EPEL 7. To install cheat, use these commands:

sudo dnf copr enable tkorbar/cheat
sudo dnf install cheat Setconf

Setconf is a simple program for making changes in configuration files, serving as an alternative for sed. The only thing setconf does is that it finds the key in the specified file and changes its value. Setconf provides only a few options to change its behavior — for example, uncommenting the line that is being changed.

Installation instructions

The repo currently provides setconf for Fedora 27, 28 and 29. To install setconf, use these commands:

sudo dnf copr enable jamacku/setconf
sudo dnf install setconf Reddit Terminal Viewer

Reddit Terminal Viewer, or rtv, is an interface for browsing Reddit from terminal. It provides the basic functionality of Reddit, so you can log in to your account, view subreddits, comment, upvote and discover new topics. Rtv currently doesn’t, however, support Reddit tags.

Installation instructions

The repo currently provides Reddit Terminal Viewer for Fedora 29 and Rawhide. To install Reddit Terminal Viewer, use these commands:

sudo dnf copr enable tc01/rtv
sudo dnf install rtv

Install Fedora remotely using Live media

Monday 4th of February 2019 08:00:48 AM

Say a friend or relative wants to install Fedora, but there are some wrinkles that make them less confident about running the installer themselves. For instance, they might want to save existing content without swapping out the hard drive, which involves shrinking filesystems, not for the inexperienced. This article walks you through a process that allows you to help them install remotely.

Naturally, they need to trust you a lot for this procedure (and you them), since they are giving you total access to the machine. I’ll call them “the client.”

Step 1. They need to download the Live Media from and write it to a USB stick.  I used the Cinnamon Spin, but nothing in this article should be specific to a Desktop Environment.   You’ll need to talk them through all this if needed.  There are also instructions on

Step 2. The client inserts the USB drive into the machine to be installed and boost from USB.  The exact steps to enable USB boot are device specific, and beyond the scope of this article. You may want to make sure the client has access to their product documentation. Or you can ask them for the make and model number of their system, and look up the docs on the internet.

Step 3. Have them connect to the internet via local Wifi or Ethernet, and have them run Firefox to check that it is working.  Send them to this very article, so they can copy and paste relevant commands when you tell them to if needed.

Step 4. Now have them start a terminal from the menu.

[liveuser@localhost-live ~]$ passwd
Changing password for user liveuser.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.
[liveuser@localhost-live ~]$ sudo systemctl start sshd
[liveuser@localhost-live ~]$ ifconfig

Sshd will not allow remote logins with an empty password, so this step assigns a password, which the client will need to share with you. I suggest a series of simple but random words.

The Live media includes pidgin (or a similar chat client for other DEs). It would be helpful to have the client start pidgin and login to a trusted server. I suggest installing jabberd on a Fedora server with a public IP, and allowing open registration. I’ll skip the details for this article. With the client on pidgin with SSL on an XMPP server you trust/control, you can share the password more securely than over the phone.  (Installing OTR would be yet another step to talk them through.)

Now the order of business is to let you connect securely to the client machine.  Have the client share the output of the ifconfig command with you.  If he has a public IP4 or IP6, and you can connect to it, you can skip to step 6.  You can also save steps if they are on a LAN that doesn’t block ethertype 0xfc00 and other Cjdns nodes are on the LAN — but that’s unlikely enough we’ll skip the details.

Step 5. If you are here, your client is in “IP4 NAT jail”, and you need to help him escape by setting up a VPN.  The simplest VPN to setup is Cjdns, but since you don’t want to talk the client through setting even that up, you’ll also need a trusted machine accessible via IP4 on which you can give the client an unprivileged shell account for bootstrapping.  Have the client login to your server with an SSH remote tunnel:

[liveuser@localhost-live ~]$ ssh -R8022:localhost:22
The authenticity of host '' can't be established.
ECDSA key fingerprint is SHA256:kRfekGaa456ga34tddrgg8kZ3VmBbqlx6vZZwhcRpuc.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '' (ECDSA) to the list of known hosts.
username@shared's password:
Last login: Wed Jan 23 18:15:38 2019 from 2001:db8:1234::1019
[theirlogin@shared ~]$

Now you can login to their machine and install Cjdns.  Login to and then into the client machine:

[yourlogin@shared ~]$ ssh -p8022 liveuser@localhost
liveuser@localhost's password:
Last login: Wed Jan 23 18:16:36 2019 from ::1
[liveuser@localhost-live ~]$

Install and configure Cjdns on the client, using these instructions if you are not already familar, and also on your own workstation if you haven’t already.  You could skip installing cjdns-tools and cjdns-selinux on the client since this is a temporarily setup.  But you’ll need the tools to help debug any glitches. 

Run ifconfig tun0 and copy the client’s Cjdns VPN IP to your local /etc/hosts file with a suitable nickname.  I’ll use the nickname h.client for this article. 

[you@yourworkstation ~] $ sudo su -
# echo fc3f:26b0:49ec:7bc7:a757:b6eb:1eae:714f h.client >>/etc/hosts

Verify that you can login to liveuser@h.client from your workstation, and then you can logout of your tunnel login.

Step 6. Install x2goserver on the client.  Tigervnc would be lighter weight for a limited machine, but x2go easily connects to the liveuser desktop so they can see what you are doing for education and transparency.  Some spins include a built-in remote desktop feature as well, but I like x2go. 

Run x2goclient on your workstation, and create a new session:

  • Session name: h.client
  • Host: h.client
  • Login: liveuser
  • Session type: Connect to local desktop

 Now you can do your expert stuff while the client watches. For shrinking existing partitions, I recommend installing gparted and running it before the live install.

Step 7. When the Live Install is finished, the newly installed root filesystem should still be mounted as /mnt/sysimage. Double check, then copy the cjdns config to the new system and enable sshd. Incoming port 22 should be open by default.

[liveuser@localhost-live ~]$ sudo cp /etc/cjdroute.conf /mnt/sysimage/etc
[liveuser@localhost-live ~]$ sudo systemctl --root=/mnt/sysimage enable sshd

You should also install cjdns (or whatever VPN you used instead) on the new system so that the client doesn’t need to do the SSH rigamarole again after rebooting.

[liveuser@localhost-live ~]$ sudo dnf install cjdns --installroot=/mnt/sysimage
[liveuser@localhost-live ~]$ sudo systemctl --root=/mnt/sysimage enable cjdns

Step 8. You should now be ready to reboot! If something goes wrong, your client can boot from the Live Media and do the SSH routine from step 5 again so you can diagnose what went wrong.

Photo by Steve Johnson on Unsplash.

Fedora Classrooms: Silverblue and Badge Design

Friday 1st of February 2019 08:00:25 AM

Fedora Classroom sessions continue with two introductory sessions, on using Fedora Silverblue (February 7), and creating Fedora badges designs (February 10). The general schedule for sessions is availble on the wiki, along with resources and recordings from previous sessions. Details on both these upcoming sessions follow.

Topic: Fedora Silverblue

Fedora Silverblue is a variant of Fedora Workstation that is composed and delivered using ostree technology. It uses some of the same RPMs found in Fedora Workstation but delivers them in a way that produces an “immutable host” for the end user.  This provides atomic upgrades for end users and allows users to move to a fully containerized environment using traditional containers and flatpaks.

This session is aimed at users who want to learn more about Fedora Silverblue,
ostree, rpm-ostree, containers, and Flatpaks.  It is expected that attendees have some basic Linux knowledge.

The following topics will be covered:

  • What’s an immutable host?
  • How is Fedora Silverblue different from Fedora Workstation?
  • What is ostree and rpm-ostree?
  • Upgrading, rollbacks, and rebasing your host.
  • Package layering with rpm-ostree.
  • Using containers and container tools (podman, buildah).
  • Using Flatpaks for GUI applications
When and where Instructor

Micah Abbott is a Principal Quality Engineer working for Red Hat. He remembers his first introduction to Linux was during university when someone showed him Red Hat Linux running on a DEC Alpha Workstation.  He’s dabbled with  various distributions in the following years, but has always had a soft spot for  Fedora. Micah has recently been contributing towards the development  of  Fedora/Red Hat CoreOS and before that Project Atomic.  He enjoys engaging with the community to help solve problems that users are facing and has most recently been spending a lot of time involved with the Fedora Silverblue community.

Topic: Creating Fedora Badges Designs

Fedora Badges is a gamification system created around the hard work of the Fedora community on the various aspects of the Fedora Project. The Badges project helps to drive and motivate Fedora contributors to participate in all different parts of Fedora development, quality, content, events, and stay active in community initiatives. This classroom will explain the process of creating a design for a Fedora Badge.

Here is the agenda for the classroom session:

  • What makes a Fedora Badge?
  • Overview of resources, website, and tickets.
  • Step by step tutorial to design a badge.

Resources needed:

On Fedora, inkscape and comfortaa can be installed using dnf:

sudo dnf install inkscape aajohan-comfortaa-fonts When and where Instructor

Marie Nordin is a graphic designer and fine artist, with a day job as a Assistant Purchasing Manager in Rochester, NY. Marie began working on the Fedora Badges project and the Fedora Design Team in 2013 through an internship with the Outreachy program. She has maintained the design side of the Fedora Badges project for four years, as well as running workshops and teaching others how to  contribute designs to Badges.

5 quick tips for Fedora Workstation users

Wednesday 30th of January 2019 08:00:50 AM

Whether you are a new or long time Fedora Workstation user, you might be looking for some quick tips to customize, tweak or enhance your desktop experience. In this article, we’ll round up five tips to help you get more out of your Fedora Workstation.

Enhancing photos with GNOME Photos

GNOME Photos is a photo library application for sorting and organizing your photo library. Additionally it features basic image editing tools for quick edits. This article walks you through the basics of editing images with GNOME Photos

Enhancing photos with GNOME Photos Try Visual Studio Code

Visual Studio Code is a Open Source text editor that includes debugging features, embedded git control, syntax highlighting, intelligent code completion, snippets, and code refactoring tools. This article walks you through how to install Visual Studio Code on Fedora. Additionally it also covers basic usage tips.

Using Visual Studio Code on Fedora Dash to Dock Extension

Dash to Dock takes the dock that is visible in the GNOME Shell Overview, and places it on the main desktop. This provides a view of open applications at a glance, and provides a quick way to switch windows using the mouse.

This article covers how to install the extension, as well as covering the basic features and settings.

Try the Dash to Dock extension for Fedora Workstation Using Nautilus Scripts

Scripts in Nautilus are not a new feature, but still super useful for automating quick tasks into the File Browser.

Integrating scripts in Nautilus to perform useful tasks Installing more Wallpapers

The Fedora repositories contain a treasure trove of wallpapers created for Fedora releases. This article shows you the wallpapers available from previous releases — going back to Fedora 8 — and what packages to install to get them on your current Fedora install.

How to install more wallpaper packs on Fedora Workstation

3 simple and useful GNOME Shell extensions

Monday 28th of January 2019 12:06:22 PM

The default desktop of Fedora Workstation — GNOME Shell — is known and loved by many users for its minimal, clutter-free user interface. It is also known for the ability to add to the stock interface using extensions. In this article, we cover 3 simple, and useful extensions for GNOME Shell. These three extensions provide a simple extra behaviour to your desktop; simple tasks that you might do every day.

Installing Extensions

The quickest and easiest way to install GNOME Shell extensions is with the Software Application. Check out the previous post here on the Magazine for more details:

How to install extensions via the Software application Removable Drive Menu Removable Drive Menu extension on Fedora 29

First up is the Removable Drive Menu extension. It is a simple tool that adds a small widget in the system tray if you have a removable drive inserted into your computer. This allows you easy access to open Files for your removable drive, or quickly and easily eject the drive for safe removal of the device.

Removable Drive Menu in the Software application Extensions Extension.

The Extensions extension is super useful if you are always installing and trying out new extensions. It provides a list of all the installed extensions, allowing you to enable or disable them. Additionally, if an extension has settings, it allows quick access to the settings dialog for each one.

the Extensions extension in the Software application Frippery Move Clock

Finally, there is the simplest extension in the list. Frippery Move Clock, simply moves the position of the clock from the center of the top bar to the right, next to the status area.

Using Antora for your open source documentation

Friday 25th of January 2019 09:00:29 AM

Are you looking for an easy way to write and publish technical documentation? Let me introduce Antora — an open source documentation site generator. Simple enough for a tiny project, but also complex enough to cover large documentation sites such as Fedora Docs.

With sources stored in git, written in a simple yet powerful markup language AsciiDoc, and a static HTML as an output, Antora makes writing, collaborating on, and publishing your documentation a no-brainer.

The basic concepts

Before we build a simple site, let’s have a look at some of the core concepts Antora uses to make the world a happier place. Or, at least, to build a documentation website.

Organizing the content

All sources that are used to build your documentation site are stored in a git repository. Or multiple ones — potentially owned by different people. For example, at the time of writing, the Fedora Docs had its sources stored in 24 different repositories owned by different groups having their own rules around contributions.

The content in Antora is organized into components, usually representing different areas of your project, or, well, different components of the software you’re documenting — such as the backend, the UI, etc. Components can be independently versioned, and each component gets a separate space on the docs site with its own menu.

Components can be optionally broken down into so-called modules. Modules are mostly invisible on the site, but they allow you to organize your sources into logical groups, and even store each in different git repository if that’s something you need to do. We use this in Fedora Docs to separate the Release Notes, the Installation Guide, and the System Administrator Guide into three different source repositories with their own rules, while preserving a single view in the UI.

What’s great about this approach is that, to some extent, the way your sources are physically structured is not reflected on the site.

Virtual catalog

When assembling the site, Antora builds a virtual catalog of all pages, assigning a unique ID to each one based on its name and the component, the version, and module it belongs to. The page ID is then used to generate URLs for each page, and for internal links as well. So, to some extent, the source repository structure doesn’t really matter as far as the site is concerned.

As an example, if we’d for some reason decided to merge all the 24 repositories of Fedora Docs into one, nothing on the site would change. Well, except the “Edit this page” link on every page that would suddenly point to this one repository.

Independent UI

We’ve covered the content, but how it’s going to look like?

Documentation sites generated with Antora use a so-called UI bundle that defines the look and feel of your site. The UI bundle holds all graphical assets such as CSS, images, etc. to make your site look beautiful.

It is expected that the UI will be developed independently of the documentation content, and that’s exactly what Antora supports.

Putting it all together

Having sources distributed in multiple repositories might raise a question: How do you build the site? The answer is: Antora Playbook.

Antora Playbook is a file that points to all the source repositories and the UI bundle. It also defines additional metadata such as the name of your site.

The Playbook is the only file you need to have locally available in order to build the site. Everything else gets fetched automatically as a part of the build process.

Building a site with Antora

Demo time! To build a minimal site, you need three things:

  1. At least one component holding your AsciiDoc sources.
  2. An Antora Playbook.
  3. A UI bundle

Good news is the nice people behind Antora provide example Antora sources we can try right away.

The Playbook

Let’s first have a look at the Playbook:

title: Antora Demo Site
# the 404 page and sitemap files only get generated when the url property is set
start_page: component-b::index.adoc
- url:
branches: master
- url:
branches: [v2.0, v1.0]
start_path: docs
snapshot: true

As we can see, the Playbook defines some information about the site, lists the content repositories, and points to the UI bundle.

There are two repositories. The demo-component-a with a single branch, and the demo-component-b having two branches, each representing a different version.


The minimal source repository structure is nicely demonstrated in the demo-component-a repository:

antora.yml <- component metadata
ROOT/ <- the default module
nav.adoc <- menu definition
pages/ <- a directory with all the .adoc sources

The following antora.yml contains metadata for this component such as the name and the version of the component, the starting page, and it also points to a menu definition file.

name: component-a
title: Component A
version: 1.5.6
start_page: ROOT:inline-text-formatting.adoc
- modules/ROOT/nav.adoc

The menu definition file is a simple list that defines the structure of the menu and the content. It uses the page ID to identify each page.

* xref:inline-text-formatting.adoc[Basic Inline Text Formatting]
* xref:special-characters.adoc[Special Characters & Symbols]
* xref:admonition.adoc[Admonition]
* xref:sidebar.adoc[Sidebar]
* xref:ui-macros.adoc[UI Macros]
* Lists
** xref:lists/ordered-list.adoc[Ordered List]
** xref:lists/unordered-list.adoc[Unordered List

And finally, there’s the actual content under modules/ROOT/pages/ — you can see the repository for examples, or the AsciiDoc syntax reference

The UI bundle

For the UI, we’ll be using the example UI provided by the project.

Going into the details of Antora UI would be above the scope of this article, but if you’re interested, please see the Antora UI documentation for more info.

Building the site

Note: We’ll be using Podman to run Antora in a container. You can learn about Podman on the Fedora Magazine.

To build the site, we only need to call Antora on the Playbook file.

The easiest way to get antora at the moment is to use the container image provided by the project. You can get it by running:

$ podman pull antora/antora

Let’s get the playbook repository:

$ git clone
$ cd demo-site

And run Antora using the following command:

$ podman run --rm -it -v $(pwd):/antora:z antora/antora site.yml

The site will be available in the public directory. You can either open it in your web browser directly, or start a local web server using:

$ cd public
$ python3 -m http.server 8080

Your site will be available on http://localhost:8080.

Mind map yourself using FreeMind and Fedora

Wednesday 23rd of January 2019 08:00:46 AM

A mind map of yourself sounds a little far-fetched at first. Is this process about neural pathways? Or telepathic communication? Not at all. Instead, a mind map of yourself is a way to describe yourself to others visually. It also shows connections among the characteristics you use to describe yourself. It’s a useful way to share information with others in a clever but also controllable way. You can use any mind map application for this purpose. This article shows you how to get started using FreeMind, available in Fedora.

Get the application

The FreeMind application has been around a while. While the UI is a bit dated and could use a refresh, it’s a powerful app that offers many options for building mind maps. And of course it’s 100% open source. There are other mind mapping apps available for Fedora and Linux users, as well. Check out this previous article that covers several mind map options.

Install FreeMind from the Fedora repositories using the Software app if you’re running Fedora Workstation. Or use this sudo command in a terminal:

$ sudo dnf install freemind

You can launch the app from the GNOME Shell Overview in Fedora Workstation. Or use the application start service your desktop environment provides. FreeMind shows you a new, blank map by default:

FreeMind initial (blank) mind map

A map consists of linked items or descriptions — nodes. When you think of something related to a node you want to capture, simply create a new node connected to it.

Mapping yourself

Click in the initial node. Replace it with your name by editing the text and hitting Enter. You’ve just started your mind map.

What would you think of if you had to fully describe yourself to someone? There are probably many things to cover. How do you spend your time? What do you enjoy? What do you dislike? What do you value? Do you have a family? All of this can be captured in nodes.

To add a node connection, select the existing node, and hit Insert, or use the “light bulb” icon for a new child node. To add another node at the same level as the new child, use Enter.

Don’t worry if you make a mistake. You can use the Delete key to remove an unwanted node. There’s no rules about content. Short nodes are best, though. They allow your mind to move quickly when creating the map. Concise nodes also let viewers scan and understand the map easily later.

This example uses nodes to explore each of these major categories:

Personal mind map, first level

You could do another round of iteration for each of these areas. Let your mind freely connect ideas to generate the map. Don’t worry about “getting it right.” It’s better to get everything out of your head and onto the display. Here’s what a next-level map might look like.

Personal mind map, second level

You could expand on any of these nodes in the same way. Notice how much information you can quickly understand about John Q. Public in the example.

How to use your personal mind map

This is a great way to have team or project members introduce themselves to each other. You can apply all sorts of formatting and color to the map to give it personality. These are fun to do on paper, of course. But having one on your Fedora system means you can always fix mistakes, or even make changes as you change.

Have fun exploring your personal mind map!

Photo by Daniel Hjalmarsson on Unsplash.

Build a Django RESTful API on Fedora.

Monday 21st of January 2019 08:00:55 AM

With the rise of kubernetes and micro-services architecture, being able to quickly write and deploy a RESTful API service is a good skill to have. In this first part of a series of articles, you’ll learn how to use Fedora to build a RESTful application and deploy it on Openshift. Together, we’re going to build the back-end for a “To Do” application.

The APIs allow you to Create, Read, Update, and Delete (CRUD) a task. The tasks are stored in a database and we’re using the Django ORM (Object Relational Mapping) to deal with the database management.

Django App and Rest Framework setup

In a new directory, create a Python 3 virtual environment so that you can install dependencies.

$ mkdir todoapp && cd todoapp
$ python3 -m venv .venv
$ source .venv/bin/activate

After activating the virtual environment, install the dependencies.

(.venv)$ pip install djangorestframework django

Django REST Framework, or DRF, is a framework that makes it easy to create RESTful CRUD APIs. By default it gives access to useful features like browseable APIs, authentication management, serialization of data, and more.

Create the Django project and application

Create the Django project using the django-admin CLI tool provided.

(.venv) $ django-admin startproject todo_app . # Note the trailing '.'
(.venv) $ tree .
└── todo_app
1 directory, 5 files

Next, create the application inside the project.

(.venv) $ cd todo_app
(.venv) $ django-admin startapp todo
(.venv) $ cd ..
(.venv) $ tree .
└── todo_app
├── todo
│ ├──
│ ├──
│ ├──
│ ├── migrations
│ │ └──
│ ├──
│ ├──
│ └──

Now that the basic structure of the project is in place, you can enable the REST framework and the todo application. Let’s add rest_framework and todo to the list of INSTALL_APPS in the project’s

todoapp/todo_app/ # Application definition

]  Application Model and Database

The next step of building our application is to set up the database. By default, Django uses the SQLite database management system. Since SQLite works well and is easy to use during development, let’s keep this default setting. The second part of this series will look at how to replace SQLite with PostgreSQL to run the application in production.

The Task Model

By adding the following code to todo_app/todo/, you define which properties have a task. The application defines a task with a title, description and a status. The status of a task can only be one of the three following states: Backlog, Work in Progress and Done.

from django.db import models

class Task(models.Model):
STATES = (("todo", "Backlog"), ("wip", "Work in Progress"), ("done", "Done"))
title = models.CharField(max_length=255, blank=False, unique=True)
description = models.TextField()
status = models.CharField(max_length=4, choices=STATES, default="todo")

Now create the database migration script that Django uses to update the database with changes.

(.venv) $ PYTHONPATH=. DJANGO_SETTINGS_MODULE=todo_app.settings django-admin makemigrations

Then you can apply the migration to the database.

(.venv) $ PYTHONPATH=. DJANGO_SETTINGS_MODULE=todo_app.settings django-admin migrate

This step creates a file named db.sqlite3 in the root directory of the application. This is where SQLite stores the data.

Access to the data Creating a View

Now that you can represent and store a task in the database, you need a way to access the data.  This is where we start making use of Django REST Framework by using the ModelViewSet. The ModelViewSet provides the following actions on a data model: list, retrieve, create, update, partial update, and destroy.

Let’s add our view to todo_app/todo/

from rest_framework import viewsets

from todo_app.todo.models import Task
from todo_app.todo.serializers import TaskSerializer

class TaskViewSet(viewsets.ModelViewSet):
queryset = Task.objects.all()
serializer_class = TaskSerializer Creating a Serializer

As you can see, the TaskViewSet is using a Serializer. In DRF, serializers convert the data modeled in the application models to a native Python datatype. This datatype can be later easily rendered into JSON or XML, for example. Serializers are also used to deserialize JSON or other content types into the data structure defined in the model.

Let’s add our TaskSerializer object by creating a new file in the project todo_app/todo/

from rest_framework.serializers import ModelSerializer
from todo_app.todo.models import Task

class TaskSerializer(ModelSerializer):
class Meta:
model = Task
fields = "__all__"

We’re using the generic ModelSerializer from DRF, to automatically create a serializer with the fields that correspond to our Task model.

Now that we have a data model a view and way to serialize/deserialize data, we need to map our view actions to URLs. That way we can use HTTP methods to manipulate our data.

Creating a Router

Here again we’re using the power of the Django REST Framework with the DefaultRouter. The DRF DefaultRouter takes care of mapping actions to HTTP Method and URLs.

Before we see a better example of what the DefaultRouter does for us, let’s add a new URL to access the view we have created earlier. Add the following to todo_app/

from django.contrib import admin
from django.conf.urls import url, include

from rest_framework.routers import DefaultRouter

from todo_app.todo.views import TaskViewSet

router = DefaultRouter()
router.register(r"todo", TaskViewSet)

urlpatterns = [
url(r"^api/", include((router.urls, "todo"))),

As you can see, we’re registering our TaskViewSet to the DefaultRouter. Then later, we’re mapping all the router URLs to the /api endpoint. This way, DRF takes care of mapping the URLs and HTTP method to our view actions (list, retrieve, create, update, destroy).

For example, accessing the api/todo endpoint with a GET HTTP request calls the list action of our view. Doing the same but using a POST HTTP request calls the create action.

To get a better grasp of this, let’s run the application and start using our API.

Running the application

We can run the application using the development server provided by Django. This server should only be used during development. We’ll see in the second part of this tutorial how to use a web server better suited for production.

(.venv)$ PYTHONPATH=. DJANGO_SETTINGS_MODULE=todo_app.settings django-admin runserver
Django version 2.1.5, using settings 'todo_app.settings'
Starting development server at
Quit the server with CONTROL-C.

Now we can access the application at the following URL:

DRF provides an interface to the view actions, for example listing or creating tasks, using the following URL:

Or updating/deleting an existing tasks with this URL:


In this article you’ve learned how to create a basic RESTful API using the Django REST Framework. In the second part of this series, we’ll update this application to use the PostgreSQL database management system, and deploy it in OpenShift.

The source code of the application is available on GitHub.

How Do You Fedora: Journey into 2019

Friday 18th of January 2019 08:00:54 AM

Fedora had an amazing 2018. The distribution saw many improvements with the introduction of Fedora 28 and Fedora 29. Fedora 28 included third party repositories, making it easy to get software like the Steam client, Google Chrome and Nvidia’s proprietary drivers. Fedora 29 brought support for automatic updates for Flatpack.

One of the four foundations of Fedora is Friends. Here at the Magazine we’re looking back at 2018, and ahead to 2019, from the perspective of several members of the Fedora community. This article focuses on what each of them did last year, and what they’re looking forward to this year.

Fedora in 2018

Radka Janekova attended five events in 2018. She went to FOSDEM as a Fedora Ambassador, gave two presentations at and three presentation on dotnet in Fedora. Janekova starting using DaVinci Resolve in 2018: “DaVinci Resolve which is very Linux friendly video editor.” She did note one drawback, saying, “It may not be entirely open source though!”

Julita Inca has been to many places in the world in 2018. “I took part of the Fedora 29 Release Party in Poland where I shared my experiences of being an Ambassador of Fedora these years in Peru.” She is currently located in the University of Edinburgh. “I am focusing in getting a Master in High Performance Computing in the University of Edinburgh using ARCHER that has CentOS as Operating System.” As part of her masters degree she is using a lot of new software. “I am learning new software for parallel programming I learned openMP and MPI.” To profile code in C and Fortran she is using Intel’s Vtune

Jose Bonilla went to a DevOps event hosted by a company called Rancher. Rancher is an open source company that provides a container orchestration framework which can be hosted in a variety of ways, including in the cloud or self-hosted. “I went to this event because I wished to gain more insight into how I can use Fedora containerization in my organization and to teach students how to manage applications and services.” This event showed that the power of open source is less focus on competition and more on completion. “There were several open source projects at this event working completely in tandem without ever having this as a goal. The companies at this event were Google, Rancher, Gitlab and Aqua.” Jose used a variety of open source applications in 2018. “I used Cockpit, Portainer and Rancher OS. Portainer and Rancher are both services that manage dockers containers. Which only proves the utility of containers. I believe this to be the future of compute environments.” He is also working on tools for data analytics. “I am improving on my knowledge of Elasticsearch and the Elastic Stack — Kibana, which is an extraordinarily powerful open source set of tools for data analytics.”

Carlos Enrique Castro León has not been to a Fedora event in Peru, but listens to Red Hat Command Line Hero. “I really like to listen to him since I can meet people related to free code.” Last year he started using Kdenlive and Inkscape. “I like them because there is a large community in Spanish that can help me.”

Akinsola Akinwale started using VSCode, Calligra and Qt5 Designer in 2018. He uses VScode for Python development. For editing documents and spreadsheets he uses Calligra. “I love Vscode for its embedded VIM , terminal & easy of use.” He started using Calligra just for a change of pace. He likes the flexibility of Qt5 designed for creating graphical user interfaces instead of coding it all in Vscode.

Kevin Fenzi went to several Fedora events in 2018. He enjoyed all of them, but liked Flock in Dresden the best of them all. “At Flock in Dresden I got a chance to talk face to face with many other Fedora contributors that I only talk to via IRC or email the rest of the time. The organizers did an awesome job, the venue was great and it was all around just a great time. There were some talks that made me think, and others that made me excited to see what would happen with them in the coming year. Also, the chance to have high bandwith talks really helped move some ideas along to reality.” There were two applications Kevin started using in 2018. “First, after many years of use, I realized it was time to move on from using rdiff-backups for my backups. It’s a great tool, but it’s in python2 and very inactive upstream. After looking around I settled on borg backup and have been happily using that since. It has a few rough edges (it needs lots of cache files to do really fast backups, etc) but it has a very active community and seems to work pretty nicely.” The other application that Kevin started using in OpenShift. “Secondly, 2018 was the year I really dug into OpenShift. I understand now much more about how it works and how things are connected and how to manage and upgrade it. In 2019 we hope to move a bunch of things over to our OpenShift cluster. The OpenShift team is really doing a great job of making something that deploys and upgrades easily and are adding great features all the time (most recently the admin console, which is great to watch what your cluster is doing!).”

Fedora in 2019

Radka plans to do similar presentations in 2019. “At FOSDEM this time I’ll be presenting a story of an open source project eating servers with C#.” Janekova targets pre-university students in an effort to encourage young women to get involved in technology. “I really want to help dotnet and C# grow in the open source world, and I also want to educate the next generation a little bit better in terms of what women can or can not do.”

Julita plans on holding two events in 2019. “I can promote the use of Fedora and GNOME in Edinburgh University.” When she returns to Peru she plans on holding a conference on writing parallel code on Fedora and Gnome.

Jose plans on continuing to push open source initiatives such as cloud and container infrastructures. He will also continue teaching advanced Unix systems administration. “I am now helping a new generation of Red Hat Certified Professionals seek their place in the world of open source. It is indeed a joy when a student mentions they have obtained their certification because of what they were exposed to in my class.” He also plans on spending some more time with his art again.

Carlos would like to write for Fedora Magazine and help bring the magazine to the Latin American community. “I would like to contribute to Fedora Magazine. If possible I would like to help with the magazine in Spanish.”

Akinsola wants to hold a Fedora a release part in 2019. “I want make many people aware of Fedora, make them aware they can be part of the release and it is easy to do.” He would also like to ensure that new Fedora users have an easy time of adapting to their new OS.

Kevin is planning is excited about 2019 being a time of great change for Fedora. “In 2019 I am looking forward to seeing what and how we retool things to allow for lifecycle changes and more self service deliverables. I think it’s going to be a ton of work, but I am hopeful we will come out of it with a much better structure to carry us forward to the next period of Fedora success.” Kevin also had some words of appreciation for everyone in the Fedora community. “I’d like to thank everyone in the Fedora community for all their hard work on Fedora, it wouldn’t exist without the vibrant community we have.”

Photo by Perry Grone on Unsplash.

Fedora Classroom: Getting started with L10N

Wednesday 16th of January 2019 08:00:26 AM

Fedora Classroom sessions continue with an introductory session on Fedora Localization (L10N). The general schedule for sessions is available on the wiki, along with resources and recordings from previous sessions. Read on for more details about the upcoming L10N Classroom session next week.

Topic: Getting Started with L10N

The goal of the Fedora Localization Project (FLP) is to bring everything around Fedora (the Software, Documentation, Websites, and culture) closer to local communities (countries, languages and in general cultural groups).  The session is aimed at beginners. Here is the agenda:

  • What is L10N?
  • Difference between Translation and Localization
  • Overview: How does L10N work?
  • Fedora structure and peculiarities related to L10N
  • Ways to join, help, and contribute
  • Further information with references and links
When and where Instructor

Silvia Sánchez has been a Fedora community member for a number of years. She currently focuses her contributions on QA, translation, wiki editing, and the Ambassadors teams among others. She has a varied background, having studied systems, programming, design, and photography. She speaks, reads, and writes Spanish, English, and German and further, also reads Portuguese, French, and Italian. In her free time, Silvia enjoys forest walks, art, and writing fiction.

Contribute at the Fedora Test Day for kernel 4.20

Monday 14th of January 2019 06:49:34 PM

The kernel team is working on final integration for kernel 4.20. This version was just recently released, and will arrive soon in Fedora. This version has many security fixes included. As a result, the Fedora kernel and QA teams have organized a test day for Tuesday, January 15, 2019. Refer to the wiki page for links to the test images you’ll need to participate.

How do test days work?

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

To contribute, you only need to be able to 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 day of the event, please do some testing and report your results.

Happy testing, and we hope to see you on test day.

How to Build a Netboot Server, Part 4

Monday 14th of January 2019 08:00:11 AM

One significant limitation of the netboot server built in this series is the operating system image being served is read-only. Some use cases may require the end user to modify the image. For example, an instructor may want to have the students install and configure software packages like MariaDB and Node.js as part of their course walk-through.

An added benefit of writable netboot images is the end user’s “personalized” operating system can follow them to different workstations they may use at later times.

Change the Bootmenu Application to use HTTPS

Create a self-signed certificate for the bootmenu application:

$ sudo -i # MY_NAME=$(</etc/hostname) # MY_TLSD=/opt/bootmenu/tls # mkdir $MY_TLSD # openssl req -newkey rsa:2048 -nodes -keyout $MY_TLSD/$MY_NAME.key -x509 -days 3650 -out $MY_TLSD/$MY_NAME.pem

Verify your certificate’s values. Make sure the “CN” value in the “Subject” line matches the DNS name that your iPXE clients use to connect to your bootmenu server:

# openssl x509 -text -noout -in $MY_TLSD/$MY_NAME.pem

Next, update the bootmenu application’s listen directive to use the HTTPS port and the newly created certificate and key:

# sed -i "s#listen => .*#listen => ['https://$MY_NAME:443?cert=$MY_TLSD/$MY_NAME.pem\&key=$MY_TLSD/$MY_NAME.key\&ciphers=AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA'],#" /opt/bootmenu/bootmenu.conf

Note the ciphers have been restricted to those currently supported by iPXE.

GnuTLS requires the “CAP_DAC_READ_SEARCH” capability, so add it to the bootmenu application’s systemd service:

# sed -i '/^AmbientCapabilities=/ s/$/ CAP_DAC_READ_SEARCH/' /etc/systemd/system/bootmenu.service # sed -i 's/Serves iPXE Menus over HTTP/Serves iPXE Menus over HTTPS/' /etc/systemd/system/bootmenu.service # systemctl daemon-reload

Now, add an exception for the bootmenu service to the firewall and restart the service:

# MY_SUBNET= # MY_PREFIX=24 # firewall-cmd --add-rich-rule="rule family='ipv4' source address='$MY_SUBNET/$MY_PREFIX' service name='https' accept" # firewall-cmd --runtime-to-permanent # systemctl restart bootmenu.service

Use wget to verify it’s working:

$ $ MY_TLSD=/opt/bootmenu/tls $ wget -q --ca-certificate=$MY_TLSD/$MY_NAME.pem -O - https://$MY_NAME/menu Add HTTPS to iPXE

Update init.ipxe to use HTTPS. Then recompile the ipxe bootloader with options to embed and trust the self-signed certificate you created for the bootmenu application:

$ echo '#define DOWNLOAD_PROTO_HTTPS' >> $HOME/ipxe/src/config/local/general.h $ sed -i 's/^chain http:/chain https:/' $HOME/ipxe/init.ipxe $ cp $MY_TLSD/$MY_NAME.pem $HOME/ipxe $ cd $HOME/ipxe/src $ make clean $ make bin-x86_64-efi/ipxe.efi EMBED=../init.ipxe CERT="../$MY_NAME.pem" TRUST="../$MY_NAME.pem"

You can now copy the HTTPS-enabled iPXE bootloader out to your clients and test that everything is working correctly:

$ cp $HOME/ipxe/src/bin-x86_64-efi/ipxe.efi $HOME/esp/efi/boot/bootx64.efi Add User Authentication to Mojolicious

Create a PAM service definition for the bootmenu application:

# dnf install -y pam_krb5 # echo 'auth required' > /etc/pam.d/bootmenu

Add a library to the bootmenu application that uses the Authen-PAM perl module to perform user authentication:

# dnf install -y perl-Authen-PAM; # MY_MOJO=/opt/bootmenu # mkdir $MY_MOJO/lib # cat << 'END' > $MY_MOJO/lib/ package PAM; use Authen::PAM; sub auth { my $success = 0; my $username = shift; my $password = shift; my $callback = sub { my @res; while (@_) { my $code = shift; my $msg = shift; my $ans = ""; $ans = $username if ($code == PAM_PROMPT_ECHO_ON()); $ans = $password if ($code == PAM_PROMPT_ECHO_OFF()); push @res, (PAM_SUCCESS(), $ans); } push @res, PAM_SUCCESS(); return @res; }; my $pamh = new Authen::PAM('bootmenu', $username, $callback); { last unless ref $pamh; last unless $pamh->pam_authenticate() == PAM_SUCCESS; $success = 1; } return $success; } return 1; END

The above code is taken almost verbatim from the Authen::PAM::FAQ man page.

Redefine the bootmenu application so it returns a netboot template only if a valid username and password are supplied:

# cat << 'END' > $MY_MOJO/ #!/usr/bin/env perl use lib 'lib'; use PAM; use Mojolicious::Lite; use Mojolicious::Plugins; use Mojo::Util ('url_unescape'); plugin 'Config'; get '/menu'; get '/boot' => sub { my $c = shift; my $instance = $c->param('instance'); my $username = $c->param('username'); my $password = $c->param('password'); my $template = 'menu'; { last unless $instance =~ /^fc[[:digit:]]{2}$/; last unless $username =~ /^[[:alnum:]]+$/; last unless PAM::auth($username, url_unescape($password)); $template = $instance; } return $c->render(template => $template); }; app->start; END

The bootmenu application now looks for the lib directory relative to its WorkingDirectory. However, by default the working directory is set to the root directory of the server for systemd units. Therefore, you must update the systemd unit to set WorkingDirectory to the root of the bootmenu application instead:

# sed -i "/^RuntimeDirectory=/ a WorkingDirectory=$MY_MOJO" /etc/systemd/system/bootmenu.service # systemctl daemon-reload

Update the templates to work with the redefined bootmenu application:

# cd $MY_MOJO/templates # MY_BOOTMENU_SERVER=$(</etc/hostname) # MY_FEDORA_RELEASES="28 29" # for i in $MY_FEDORA_RELEASES; do echo '#!ipxe' > fc$i.html.ep; grep "^kernel\|initrd" menu.html.ep | grep "fc$i" >> fc$i.html.ep; echo "boot || chain https://$MY_BOOTMENU_SERVER/menu" >> fc$i.html.ep; sed -i "/^:f$i$/,/^boot /c :f$i\nlogin\nchain https://$MY_BOOTMENU_SERVER/boot?instance=fc$i\&username=\${username}\&password=\${password:uristring} || goto failed" menu.html.ep; done

The result of the last command above should be three files similar to the following:


#!ipxe set timeout 5000 :menu menu iPXE Boot Menu item --key 1 lcl 1. Microsoft Windows 10 item --key 2 f29 2. RedHat Fedora 29 item --key 3 f28 3. RedHat Fedora 28 choose --timeout ${timeout} --default lcl selected || goto shell set timeout 0 goto ${selected} :failed echo boot failed, dropping to shell... goto shell :shell echo type 'exit' to get the back to the menu set timeout 0 shell goto menu :lcl exit :f29 login chain${username}&password=${password:uristring} || goto failed :f28 login chain${username}&password=${password:uristring} || goto failed


#!ipxe kernel --name kernel.efi ${prefix}/vmlinuz-4.19.5-300.fc29.x86_64 initrd=initrd.img ro ip=dhcp rd.peerdns=0 nameserver= nameserver= root=/dev/disk/by-path/ console=tty0 console=ttyS0,115200n8 audit=0 selinux=0 quiet initrd --name initrd.img ${prefix}/initramfs-4.19.5-300.fc29.x86_64.img boot || chain


#!ipxe kernel --name kernel.efi ${prefix}/vmlinuz-4.19.3-200.fc28.x86_64 initrd=initrd.img ro ip=dhcp rd.peerdns=0 nameserver= nameserver= root=/dev/disk/by-path/ console=tty0 console=ttyS0,115200n8 audit=0 selinux=0 quiet initrd --name initrd.img ${prefix}/initramfs-4.19.3-200.fc28.x86_64.img boot || chain

Now, restart the bootmenu application and verify authentication is working:

# systemctl restart bootmenu.service Make the iSCSI Target Writeable

Now that user authentication works through iPXE, you can create per-user, writeable overlays on top of the read-only image on demand when users connect. Using a copy-on-write overlay has three advantages over simply copying the original image file for each user:

  1. The copy can be created very quickly. This allows creation on-demand.
  2. The copy does not increase the disk usage on the server. Only what the user writes to their personal copy of the image is stored in addition to the original image.
  3. Since most sectors for each copy are the same sectors on the server’s storage, they’ll likely already be loaded in RAM when subsequent users access their copies of the operating system. This improves the server’s performance because RAM is faster than disk I/O.

One potential pitfall of using copy-on-write is that once overlays are created, the images on which they are overlayed must not be changed. If they are changed, all the overlays will be corrupted. Then the overlays must be deleted and replaced with new, blank overlays. Even simply mounting the image file in read-write mode can cause sufficient filesystem updates to corrupt the overlays.

Due to the potential for the overlays to be corrupted if the original image is modified, mark the original image as immutable by running:

# chattr +i </path/to/file>

You can use lsattr </path/to/file> to view the status of the immutable flag and use  to chattr -i </path/to/file> unset the immutable flag. While the immutable flag is set, even the root user or a system process running as root cannot modify or delete the file.

Begin by stopping the tgtd.service so you can change the image files:

# systemctl stop tgtd.service

It’s normal for this command to take a minute or so to stop when there are connections still open.

Now, remove the read-only iSCSI export. Then update the readonly-root configuration file in the template so the image is no longer read-only:

# MY_FC=fc29 # rm -f /etc/tgt/conf.d/$MY_FC.conf # TEMP_MNT=$(mktemp -d) # mount /$MY_FC.img $TEMP_MNT # sed -i 's/^READONLY=yes$/READONLY=no/' $TEMP_MNT/etc/sysconfig/readonly-root # sed -i 's/^Storage=volatile$/#Storage=auto/' $TEMP_MNT/etc/systemd/journald.conf # umount $TEMP_MNT

Journald was changed from logging to volatile memory back to its default (log to disk if /var/log/journal exists) because a user reported his clients would freeze with an out-of-memory error due to an application generating excessive system logs. The downside to setting logging to disk is that extra write traffic is generated by the clients, and might burden your netboot server with unnecessary I/O. You should decide which option — log to memory or log to disk — is preferable depending on your environment.

Since you won’t make any further changes to the template image, set the immutable flag on it and restart the tgtd.service:

# chattr +i /$MY_FC.img # systemctl start tgtd.service

Now, update the bootmenu application:

# cat << 'END' > $MY_MOJO/ #!/usr/bin/env perl use lib 'lib'; use PAM; use Mojolicious::Lite; use Mojolicious::Plugins; use Mojo::Util ('url_unescape'); plugin 'Config'; get '/menu'; get '/boot' => sub { my $c = shift; my $instance = $c->param('instance'); my $username = $c->param('username'); my $password = $c->param('password'); my $chapscrt; my $template = 'menu'; { last unless $instance =~ /^fc[[:digit:]]{2}$/; last unless $username =~ /^[[:alnum:]]+$/; last unless PAM::auth($username, url_unescape($password)); last unless $chapscrt = `sudo scripts/mktgt $instance $username`; $template = $instance; } return $c->render(template => $template, username => $username, chapscrt => $chapscrt); }; app->start; END

This new version of the bootmenu application calls a custom mktgt script which, on success, returns a random CHAP password for each new iSCSI target that it creates. The CHAP password prevents one user from mounting another user’s iSCSI target by indirect means. The app only returns the correct iSCSI target password to a user who has successfully authenticated.

The mktgt script is prefixed with sudo because it needs root privileges to create the target.

The $username and $chapscrt variables also pass to the render command so they can be incorporated into the templates returned to the user when necessary.

Next, update our boot templates so they can read the username and chapscrt variables and pass them along to the end user. Also update the templates to mount the root filesystem in rw (read-write) mode:

# cd $MY_MOJO/templates # sed -i "s/:$MY_FC/:$MY_FC-<%= \$username %>/g" $MY_FC.html.ep # sed -i "s/ netroot=iscsi:/ netroot=iscsi:<%= \$username %>:<%= \$chapscrt %>@/" $MY_FC.html.ep # sed -i "s/ ro / rw /" $MY_FC.html.ep

After running the above commands, you should have boot templates like the following:

#!ipxe kernel --name kernel.efi ${prefix}/vmlinuz-4.19.5-300.fc29.x86_64 initrd=initrd.img rw ip=dhcp rd.peerdns=0 nameserver= nameserver= root=/dev/disk/by-path/<%= $username %>-lun-1 netroot=iscsi:<%= $username %>:<%= $chapscrt %><%= $username %> console=tty0 console=ttyS0,115200n8 audit=0 selinux=0 quiet initrd --name initrd.img ${prefix}/initramfs-4.19.5-300.fc29.x86_64.img boot || chain

NOTE: If you need to view the boot template after the variables have been interpolated, you can insert the “shell” command on its own line just before the “boot” command. Then, when you netboot your client, iPXE gives you an interactive shell where you can enter “imgstat” to view the parameters being passed to the kernel. If everything looks correct, you can type “exit” to leave the shell and continue the boot process.

Now allow the bootmenu user to run the mktgt script (and only that script) as root via sudo:

# echo "bootmenu ALL = NOPASSWD: $MY_MOJO/scripts/mktgt *" > /etc/sudoers.d/bootmenu

The bootmenu user should not have write access to the mktgt script or any other files under its home directory. All the files under /opt/bootmenu should be owned by root, and should not be writable by any user other than root.

Sudo does not work well with systemd’s DynamicUser option, so create a normal user account and set the systemd service to run as that user:

# useradd -r -c 'iPXE Boot Menu Service' -d /opt/bootmenu -s /sbin/nologin bootmenu # sed -i 's/^DynamicUser=true$/User=bootmenu/' /etc/systemd/system/bootmenu.service # systemctl daemon-reload

Finally, create a directory for the copy-on-write overlays and create the mktgt script that manages the iSCSI targets and their overlayed backing stores:

# mkdir /$MY_FC.cow # mkdir $MY_MOJO/scripts # cat << 'END' > $MY_MOJO/scripts/mktgt #!/usr/bin/env perl # if another instance of this script is running, wait for it to finish "$ENV{FLOCKER}" eq 'MKTGT' or exec "env FLOCKER=MKTGT flock /tmp $0 @ARGV"; # use "RETURN" to print to STDOUT; everything else goes to STDERR by default open(RETURN, '>&', STDOUT); open(STDOUT, '>&', STDERR); my $instance = shift or die "instance not provided"; my $username = shift or die "username not provided"; my $img = "/$instance.img"; my $dir = "/$instance.cow"; my $top = "$dir/$username"; -f "$img" or die "'$img' is not a file"; -d "$dir" or die "'$dir' is not a directory"; my $base; die unless $base = `losetup --show --read-only --nooverlap --find $img`; chomp $base; my $size; die unless $size = `blockdev --getsz $base`; chomp $size; # create the per-user sparse file if it does not exist if (! -e "$top") { die unless system("dd if=/dev/zero of=$top status=none bs=512 count=0 seek=$size") == 0; } # create the copy-on-write overlay if it does not exist my $cow="$instance-$username"; my $dev="/dev/mapper/$cow"; if (! -e "$dev") { my $over; die unless $over = `losetup --show --nooverlap --find $top`; chomp $over; die unless system("echo 0 $size snapshot $base $over p 8 | dmsetup create $cow") == 0; } my $tgtadm = '/usr/sbin/tgtadm --lld iscsi'; # get textual representations of the iscsi targets my $text = `$tgtadm --op show --mode target`; my @targets = $text =~ /(?:^T.*\n)(?:^ .*\n)*/mg; # convert the textual representations into a hash table my $targets = {}; foreach (@targets) { my $tgt; my $sid; foreach (split /\n/) { /^Target (\d+)(?{ $tgt = $targets->{$^N} = [] })/; /I_T nexus: (\d+)(?{ $sid = $^N })/; /Connection: (\d+)(?{ push @{$tgt}, [ $sid, $^N ] })/; } } my $hostname; die unless $hostname = `hostname`; chomp $hostname; my $target = 'iqn.' . join('.', reverse split('\.', $hostname)) . ":$cow"; # find the target id corresponding to the provided target name and # close any existing connections to it my $tid = 0; foreach (@targets) { next unless /^Target (\d+)(?{ $tid = $^N }): $target$/m; foreach (@{$targets->{$tid}}) { die unless system("$tgtadm --op delete --mode conn --tid $tid --sid $_->[0] --cid $_->[1]") == 0; } } # create a new target if an existing one was not found if ($tid == 0) { # find an available target id my @ids = (0, sort keys %{$targets}); $tid = 1; while ($ids[$tid]==$tid) { $tid++ } # create the target die unless -e "$dev"; die unless system("$tgtadm --op new --mode target --tid $tid --targetname $target") == 0; die unless system("$tgtadm --op new --mode logicalunit --tid $tid --lun 1 --backing-store $dev") == 0; die unless system("$tgtadm --op bind --mode target --tid $tid --initiator-address ALL") == 0; } # (re)set the provided target's chap password my $password = join('', map(chr(int(rand(26))+65), 1..8)); my $accounts = `$tgtadm --op show --mode account`; if ($accounts =~ / $username$/m) { die unless system("$tgtadm --op delete --mode account --user $username") == 0; } die unless system("$tgtadm --op new --mode account --user $username --password $password") == 0; die unless system("$tgtadm --op bind --mode account --tid $tid --user $username") == 0; # return the new password to the iscsi target on stdout print RETURN $password; END # chmod +x $MY_MOJO/scripts/mktgt

The above script does five things:

  1. It creates the /<instance>.cow/<username> sparse file if it does not already exist.
  2. It creates the /dev/mapper/<instance>-<username> device node that serves as the copy-on-write backing store for the iSCSI target if it does not already exist.
  3. It creates the iqn.<reverse-hostname>:<instance>-<username> iSCSI target if it does not exist. Or, if the target does exist, it closes any existing connections to it because the image can only be opened in read-write mode from one place at a time.
  4. It (re)sets the chap password on the iqn.<reverse-hostname>:<instance>-<username> iSCSI target to a new random value.
  5. It prints the new chap password on standard output if all of the previous tasks compeleted successfully.

You should be able to test the mktgt script from the command line by running it with valid test parameters. For example:

# echo `$MY_MOJO/scripts/mktgt fc29 jsmith`

When run from the command line, the mktgt script should print out either the eight-character random password for the iSCSI target if it succeeded or the line number on which something went wrong if it failed.

On occasion, you may want to delete an iSCSI target without having to stop the entire service. For example, a user might inadvertently corrupt their personal image, in which case you would need to systematically undo everything that the above mktgt script does so that the next time they log in they will get a copy of the original image.

Below is an rmtgt script that undoes, in reverse order, what the above mktgt script did:

# mkdir $HOME/bin # cat << 'END' > $HOME/bin/rmtgt #!/usr/bin/env perl @ARGV >= 2 or die "usage: $0 <instance> <username> [+d|+f]\n"; my $instance = shift; my $username = shift; my $rmd = ($ARGV[0] eq '+d'); #remove device node if +d flag is set my $rmf = ($ARGV[0] eq '+f'); #remove sparse file if +f flag is set my $cow = "$instance-$username"; my $hostname; die unless $hostname = `hostname`; chomp $hostname; my $tgtadm = '/usr/sbin/tgtadm'; my $target = 'iqn.' . join('.', reverse split('\.', $hostname)) . ":$cow"; my $text = `$tgtadm --op show --mode target`; my @targets = $text =~ /(?:^T.*\n)(?:^ .*\n)*/mg; my $targets = {}; foreach (@targets) { my $tgt; my $sid; foreach (split /\n/) { /^Target (\d+)(?{ $tgt = $targets->{$^N} = [] })/; /I_T nexus: (\d+)(?{ $sid = $^N })/; /Connection: (\d+)(?{ push @{$tgt}, [ $sid, $^N ] })/; } } my $tid = 0; foreach (@targets) { next unless /^Target (\d+)(?{ $tid = $^N }): $target$/m; foreach (@{$targets->{$tid}}) { die unless system("$tgtadm --op delete --mode conn --tid $tid --sid $_->[0] --cid $_->[1]") == 0; } die unless system("$tgtadm --op delete --mode target --tid $tid") == 0; print "target $tid deleted\n"; sleep 1; } my $dev = "/dev/mapper/$cow"; if ($rmd or ($rmf and -e $dev)) { die unless system("dmsetup remove $cow") == 0; print "device node $dev deleted\n"; } if ($rmf) { my $sf = "/$instance.cow/$username"; die "sparse file $sf not found" unless -e "$sf"; die unless system("rm -f $sf") == 0; die unless not -e "$sf"; print "sparse file $sf deleted\n"; } END # chmod +x $HOME/bin/rmtgt

For example, to use the above script to completely remove the fc29-jsmith target including its backing store device node and its sparse file, run the following:

# rmtgt fc29 jsmith +f

Once you’ve verified that the mktgt script is working properly, you can restart the bootmenu service. The next time someone netboots, they should receive a personal copy of the the netboot image they can write to:

# systemctl restart bootmenu.service

Users should now be able to modify the root filesystem as demonstrated in the below screenshot:

Fedora classroom: Building Container images with Buildah

Wednesday 9th of January 2019 09:00:49 AM

Fedora Classroom sessions continue with an introductory session on the use of Buildah to create container images. The general schedule for sessions is availble on the wiki, along with resources and recordings from previous sessions.

Topic: Building container images with Buildah

Containers are becoming the de facto standard for building and distributing applications. Fedora as a modern operating system already supports container use by default. As with every new technology, there are different applications and services available for adopting it. This classroom will explain and demonstrate the Buildah command line tool for building container images and its implementation in Fedora 29.

Here’s the agenda for the Classroom session:

  • Quick overview of What is a container image?
  • Deep dive into container architecture.
  • Container runtimes.
  • Building container images from commandline.
  • Building container images using Dockerfile.
  • Running Buildah within a container.
When and where
  • The session will be held on the Jitsi video-conferencing platform. Please use this URL to join the session:
  • It will be held on  Tuesday, January 15 at 1600 UTC.  (Please click the link to see the time in your time zone.)

Dan Walsh is a Distinguished Engineer for Red Hat. Dan is a recognized expert in Linux Security and container technologies. He has been working on container technologies for the last 17 years at Red Hat. Dan now leads the Container Runtime team at Red Hat. Responsible for the CRI-O, Buildah, Podman, and Skopeo projects.

More in Tux Machines

Server: HTTP Clients, IIS DDoS and 'DevOps' Hype From Red Hat

  • What are good command line HTTP clients?
    The whole is greater than the sum of its parts is a very famous quote from Aristotle, a Greek philosopher and scientist. This quote is particularly pertinent to Linux. In my view, one of Linux’s biggest strengths is its synergy. The usefulness of Linux doesn’t derive only from the huge raft of open source (command line) utilities. Instead, it’s the synergy generated by using them together, sometimes in conjunction with larger applications. The Unix philosophy spawned a “software tools” movement which focused on developing concise, basic, clear, modular and extensible code that can be used for other projects. This philosophy remains an important element for many Linux projects. Good open source developers writing utilities seek to make sure the utility does its job as well as possible, and work well with other utilities. The goal is that users have a handful of tools, each of which seeks to excel at one thing. Some utilities work well independently. This article looks at 4 open source command line HTTP clients. These clients let you download files over the internet from the command line. But they can also be used for many more interesting purposes such as testing, debugging and interacting with HTTP servers and web applications. Working with HTTP from the command-line is a worthwhile skill for HTTP architects and API designers. If you need to play around with an API, HTTPie and curl will be invaluable.
  • Microsoft publishes security alert on IIS bug that causes 100% CPU usage spikes
    The Microsoft Security Response Center published yesterday a security advisory about a denial of service (DOS) issue impacting IIS (Internet Information Services), Microsoft's web server technology.
  • 5 things to master to be a DevOps engineer
    There's an increasing global demand for DevOps professionals, IT pros who are skilled in software development and operations. In fact, the Linux Foundation's Open Source Jobs Report ranked DevOps as the most in-demand skill, and DevOps career opportunities are thriving worldwide. The main focus of DevOps is bridging the gap between development and operations teams by reducing painful handoffs and increasing collaboration. This is not accomplished by making developers work on operations tasks nor by making system administrators work on development tasks. Instead, both of these roles are replaced by a single role, DevOps, that works on tasks within a cooperative team. As Dave Zwieback wrote in DevOps Hiring, "organizations that have embraced DevOps need people who would naturally resist organization silos."

Purism's Privacy and Security-Focused Librem 5 Linux Phone to Arrive in Q3 2019

Initially planned to ship in early 2019, the revolutionary Librem 5 mobile phone was delayed for April 2019, but now it suffered just one more delay due to the CPU choices the development team had to make to deliver a stable and reliable device that won't heat up or discharge too quickly. Purism had to choose between the i.MX8M Quad or the i.MX8M Mini processors for their Librem 5 Linux-powered smartphone, but after many trials and errors they decided to go with the i.MX8M Quad CPU as manufacturer NXP recently released a new software stack solving all previous power consumption and heating issues. Read more

Qt Creator 4.9 Beta released

We are happy to announce the release of Qt Creator 4.9 Beta! There are many improvements and fixes included in Qt Creator 4.9. I’ll just mention some highlights in this blog post. Please refer to our change log for a more thorough overview. Read more

Hack Week - Browsersync integration for Online

Recently my LibreOffice work is mostly focused on the Online. It's nice to see how it is growing with new features and has better UI. But when I was working on improving toolbars (eg. folding menubar or reorganization of items) I noticed one annoying thing from the developer perspective. After every small change, I had to restart the server to provide updated content for the browser. It takes few seconds for switching windows, killing old server then running new one which requires some tests to be passed. Last week during the Hack Week funded by Collabora Productivity I was able to work on my own projects. It was a good opportunity for me to try to improve the process mentioned above. I've heard previously about browsersync so I decided to try it out. It is a tool which can automatically reload used .css and .js files in all browser sessions after change detection. To make it work browsersync can start proxy server watching files on the original server and sending events to the browser clients if needed. Read more