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: 7 hours 52 min ago

Build a Django RESTful API on Fedora.

8 hours 49 min ago

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.

Chromium on Fedora finally gets VAAPI support!

Monday 7th of January 2019 09:00:35 AM

Do you like playing videos in your web browser? Well, good news, the Chromium web browser available in Fedora gets a Video Acceleration API support. That makes video playback much smoother while using significantly less resources.

A little bit of history

Chromium with a VAAPI patch was already available on other distributions. But this was not the case with Fedora. I really want hardware acceleration. But my love for Fedora was holding me back. Then with sheer willpower, I joined Fedora and started maintaining a package in COPR.

I am not really a distro hopper but a DE hopper. I usually jump from Gnome to KDE and vice versa depending upon my mood. Then I started maintaining Chromium with vaapi patch on COPR. I was using the official patch which was submitted upstream for code review. I had very little hope that it will get merge. The patch is outdated and and try jobs were failing at that time.

After six months, the Chromium upstream maintainers made a statement that they are not interested to include this patch. So after that I started working on my own patch with referenced from the official patch. My patch is about using the existing flags that other operating system uses instead of creating a new flag just for experimentation.

Chromium uses AMDGPU’s UVD engine while playing a video

Chromium uses Existing flags on Fedora

Effects of the VAAPI patch

Chromium with this patch was extremely stable on both of my machines. They both have AMD GPU. The video playback is smooth. This improved overall power savings as well.

Credits: Tobias Wolfshappen

As you can see, chromium with the vaapi patch takes up significantly less resources in comparison to chromium without the patch and Firefox.  The CPU usage went down from 120% to 10%. The playback is smooth with no shuttering.

VA-API patch in chromium for Fedora

It was then Fedora’s former Engineering Manager @ Red Hat and Chromium maintainer, Tom Callaway, finally recognises the VAAPI patch and decides to include in Fedora’s Chromium browser. Fedora becomes the second distribution to include the VAAPI patch in their official Chromium package.

Managing dotfiles with rcm

Friday 4th of January 2019 08:00:42 AM

A hallmark feature of many GNU/Linux programs is the easy-to-edit configuration file. Nearly all common free software programs store configuration settings inside a plain text file, often in a structured format like JSON, YAML or “INI-like”. These configuration files are frequently found hidden inside a user’s home directory. However, a basic ls won’t reveal them. UNIX standards require that any file or directory name that begins with a period (or “dot”) is considered “hidden” and will not be listed in directory listings unless requested by the user. For example, to list all files using the ls program, pass the -a command-line option.

Over time, these configuration files become highly customized, and managing them becomes increasingly more challenging as time goes on. Not only that, but keeping them synchronized between multiple computers is a common challenge in large organizations. Finally, many users find a sense of pride in their unique configuration settings and want an easy way to share them with friends. That’s where rcm steps in.

rcm is a “rc” file management suite (“rc” is another convention for naming configuration files that has been adopted by some GNU/Linux programs like screen or bash). rcm provides a suite of commands to manage and list files it tracks. Install rcm using dnf.

Getting started

By default, rcm uses ~/.dotfiles for storing all the dotfiles it manages. A managed dotfile is actually stored inside ~/.dotfiles, and a symlink is placed in the expected file’s location. For example, if ~/.bashrc is tracked by rcm, a long listing would look like this.

[link@localhost ~]$ ls -l ~/.bashrc lrwxrwxrwx. 1 link link 27 Dec 16 05:19 .bashrc -> /home/link/.dotfiles/bashrc [link@localhost ~]$

rcm consists of 4 commands:

  • mkrc – convert a file into a dotfile managed by rcm
  • lsrc – list files managed by rcm
  • rcup – synchronize dotfiles managed by rcm
  • rcdn – remove all the symlinks managed by rcm
Share bashrc across two computers

It is not uncommon today for a user to have shell accounts on more than one computer. Keeping dotfiles synchronized between those computers can be a challenge. This scenario will present one possible solution, using only rcm and git.

First, convert (or “bless”) a file into a dotfile managed by rcm with mkrc.

[link@localhost ~]$ mkrc -v ~/.bashrc Moving... '/home/link/.bashrc' -> '/home/link/.dotfiles/bashrc' Linking... '/home/link/.dotfiles/bashrc' -> '/home/link/.bashrc' [link@localhost ~]$

Next, verify the listings are correct with lsrc.

[link@localhost ~]$ lsrc /home/link/.bashrc:/home/link/.dotfiles/bashrc [link@localhost ~]$

Now create a git repository inside ~/.dotfiles and set up an accessible remote repository using your choice of hosted git repositories. Commit the bashrc file and push a new branch.

[link@localhost ~]$ cd ~/.dotfiles [link@localhost .dotfiles]$ git init Initialized empty Git repository in /home/link/.dotfiles/.git/ [link@localhost .dotfiles]$ git remote add origin [link@localhost .dotfiles]$ git add bashrc [link@localhost .dotfiles]$ git commit -m "initial commit" [master (root-commit) b54406b] initial commit 1 file changed, 15 insertions(+) create mode 100644 bashrc [link@localhost .dotfiles]$ git push -u origin master ... [link@localhost .dotfiles]$

On the second machine, clone this repository into ~/.dotfiles.

[link@remotehost ~]$ git clone ~/.dotfiles ... [link@remotehost ~]$

Now update the symlinks managed by rcm with rcup.

[link@remotehost ~]$ rcup -v replacing identical but unlinked /home/link/.bashrc removed '/home/link/.bashrc' '/home/link/.dotfiles/bashrc' -> '/home/link/.bashrc' [link@remotehost ~]$

Overwrite the existing ~/.bashrc (if it exists) and restart the shell.

That’s it!  The host-specific option (-o) is a useful addition to the scenario above. And as always, be sure to read the manpages; they contain a wealth of example commands.

Fedora classroom: LaTeX 101 for beginners

Wednesday 2nd of January 2019 01:13:01 PM

Fedora Classroom sessions continue with an introductory session on LaTeX. The general schedule for sessions is available on the wiki, along with resources and recordings from previous sessions.

Topic: LaTeX 101

LaTeX is a typesetting system that the de-facto standard for scientific publishing. It is Free software, and enables the generation of a multitude of high quality documents. LaTeX documents are written in plaintext and compiled to DVI/PDF. This permits the user to focus on writing the text, leaving the typesetting to LaTeX.

This LaTeX 101 session is aimed at absolute beginners. So, no prior knowledge of LaTeX is required. The session will:

  • introduce LaTeX.
  • walk through writing a simple LaTeX document explaining basic commands.
  • demonstrate compiling the document to a PDF.
  • show the inclusion of references in the document from a bibliography.
  • give an example of collaborative writing using LaTeX and Git.

You will need:

  • a text editor of choice.
  • a LaTeX installation.
  • optionally, a knowledge of Git and Github would be useful.

LaTeX and Git can be installed on Fedora using dnf:

sudo dnf install texlive-latex texlive-bibtex git

For other systems, LaTeX can be obtained here.

When and where Instructor

Ankur Sinha (“FranciscoD”) is a Free Software supporter and has been with the Fedora community for the better part of a decade now. Ankur started as a font package maintainer and has since branched out to many other teams and SIGs. He uses Fedora Workstation and prefers the terminal whenever possible. Currently, he’s working on his PhD in computational neuroscience in the UK. When he has time to spare, he focuses on the Fedora Join SIG, Fedora classrooms, and  NeuroFedora. You can get in touch with him via his Fedora project e-mail or on one of the many Fedora IRC channels.

Carlos Castro León: How Do You Fedora?

Monday 31st of December 2018 04:28:32 PM

We recently interviewed Carlos Castro León on how he uses Fedora. This is part of a series on the Fedora Magazine. The series profiles Fedora users and how they use Fedora to get things done. Contact us on the feedback form to express your interest in becoming a interviewee.

Who is Carlos Castro León?

Carlos Castro León is a computer engineer in northern Peru. He started using Linux in 2006 when another Linux user helped him install Ubuntu Edgy Eft. When Carlos attended college he decided to use a more stable distribution: “I already knew about Fedora 16 and decided to use it.” Castro León currently works as a computer engineer in Peru. His main task is to coordinate the activities of a team of individuals who manage the servers and networking at his company.

He loves food. He says his favorites are El Cabrito and La Caigua Rellena: “They are delicious and if you come to Peru I can give you very good recommendations.”

Carlos finds the most difficult thing is to get people interested in open source. He overcame resistance from his colleagues by building on the success of the first project. “My first project was implementing OpenVPN,” he says. After this he implemented the following servers: Zimbra, GLPI, DHCP, Rsync, Bacula, Owncloud, and Alfresco.

The Fedora Community

Castro León has some fantastic things to say about the Fedora Community: “They are always attentive to solve problems.”  He added, “the community documentation is available to everyone.” He would like to encourage the spread of open source. Carlos would like to create workshops, events and give presentations at universities. Castro León would like to see more people understand the full potential of having a computer engineering career within an open source project.

What Hardware?

Carlos owns a Dell Inspiron 15 5000 laptop with Fedora installed. He also uses a Brother DCP-T500W printer connected via wireless. “I have not had any issues with hardware or software compatibility,” he reports. For design work he uses a 20 inch monitor and extends the screen. At work he has a Lenovo M700 tiny. This computer has both Windows 10 and most importantly a Fedora install. Carlos says, “I prefer to use Fedora because it has better performance and I have not had problems connecting to shared resources within the office.”

What Software?

Castro León is currently running Fedora 29. For personal projects he uses GIMP, Inkscape, Kdenlive, Audacity, VLC and Simple Screen Recorder. At work he makes use of Shutter, Libre Office, GEdit, and Terminal.

Best of 2018: Fedora for developers

Friday 28th of December 2018 08:00:56 AM

Building custom apps in Python on Fedora — using either a Python IDE that helps you learn understand the language, or a popular editor that also works with many other languages. And what about Rust — a very fast and safe programming language. Yes, it’s been a whole year again! What a great time to look back at the most popular articles on the Fedora Magazine written by our awesome contributors.

Let’s dive into another article of the “Best of 2018” series — this time it’s all about developers, and how you can use Fedora to be your great developer workstation.

Building an RSS notifier in Python

Building a simple app is one of the best way to learn a programming language. Or a new environment. And Fedora loves Python!

This article walks you through building your very own RSS notifier using Python on Fedora. You’ll learn how to parse RSS feeds and send email with Python.

Never miss a Magazine article — build your own RSS notification system

Meet Thonny — A Python IDE that teaches you

Are you learning Python? Or do you want to just understand how it works under the hood? Thonny is a Python IDE designed specifically for this.

This article demonstrates how to use Thonny to understand how Python works — from calling functions to  the difference between values vs. references. It’s debugger lets you explore everything that happens in the background. It’s a great tool for beginners.

Learn to code with Thonny — a Python IDE for beginners

Using VS Code for Python

Already fluent in Python and looking for an editor that would work well with the language? Maybe even one that could work with multiple languages? Let’s have a look at VS Code.

This article shows you how to install the Python extension. Its features include code linting, code formatting, or running tasks — such as a Flask server for development. You’ll also learn how to work with unit tests which is always useful!

How to use VS Code for your Python projects

Going fast and safe with Rust

And what about something else than Python? Something a bit more rusty? Well, meet Rust — a language designed to be blazingly fast and safe.

This article introduces you to Rust the programing language, its modules called Crates, and some applications written in Rust. You’ll also learn about the Rust SIG in Fedora should you wish to get even more involved.

Oxidizing Fedora: Try Rust and its applications today

Best of 2018: Fedora for System Administrators

Monday 24th of December 2018 08:00:11 AM

Continuing our round-up of the year’s best reads on Fedora Magazine, this stellar collection covers articles of particular interests to system administrators.

Fedora supports and includes some superb tools for System Administrators, and these picks really highlight what’s on offer.

How to reset root password

Many of us – sysadmins or otherwise – have faced this dilemma at one time or another. Misplacing the root password feels like game over, but it isn’t!

Curt talks us through exactly how we can regain control of our Fedora systems by resetting the root password.

How to reset a root password on Fedora

Configuring software repositories in Fedora

Changing the repositories your Fedora system gets its software from can be a little nerve-wracking. What if you update packages you didn’t want to update? How can you trust the new repo?

Fortunately, Paul shows us exactly how to add extra repos, and how to make sure we keep the versions we want to keep.

Configure software repositories in Fedora

F28 on the RasPi 3B+

In July, Sinny shared this fantastic article with us, giving a step-by-step guide to running Fedora 28 on a Raspberry Pi 3B+.

Raspberry Pi devices have spread around the world as an affordable and open system for both play and work – and with this guide, you can now install and configure your favourite distro on one in no time.

Fedora 28 on Raspberry Pi 3 B+

Using Ansible to set up a workstation

The incredibly flexible and powerful management tool Ansible was covered by Link in July. An essential tool for so many Sysadmins, Anisible allows for simplified and custom deployment, configuration, and management of Fedora and other Linux-based systems.

Link’s article introduces us to Ansible, and shows us how to get up and running with configuring and installing a workstation.

Using Ansible to set up a workstation


How to Build a Netboot Server, Part 3

Friday 21st of December 2018 08:00:57 AM

The How to Build a Netboot Server, Part 1 article provided a minimal iPXE boot script for your netboot image. Many users probably have a local operating system that they want to use in addition to the netboot image. But switching bootloaders using the typical workstation’s BIOS can be cumbersome. This part of the series shows how to set up some more complex iPXE configurations. These allow the end user to easily choose which operating system they want to boot. They also let the system administrator manage the boot menus from a central server.

An interactive iPXE boot menu

The commands below redefine the netboot image’s boot.cfg as an interactive iPXE boot menu with a 5 second countdown timer:

$ MY_FVER=29 $ MY_KRNL=$(ls -c /fc$MY_FVER/lib/modules | head -n 1) $ MY_DNS1= $ MY_DNS2= $ $ MY_EMAN=$(echo $MY_NAME | tr '.' "\n" | tac | tr "\n" '.' | cut -b -${#MY_NAME}) $ MY_ADDR=$(host -t A $MY_NAME | awk '{print $4}') $ cat << END > $HOME/esp/linux/boot.cfg #!ipxe set timeout 5000 :menu menu iPXE Boot Menu item --key 1 lcl 1. Microsoft Windows 10 item --key 2 f$MY_FVER 2. RedHat Fedora $MY_FVER 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 :f$MY_FVER kernel --name kernel.efi \${prefix}/vmlinuz-$MY_KRNL initrd=initrd.img ro ip=dhcp rd.peerdns=0 nameserver=$MY_DNS1 nameserver=$MY_DNS2 root=/dev/disk/by-path/ip-$MY_ADDR:3260-iscsi-iqn.$MY_EMAN:fc$MY_FVER-lun-1 netroot=iscsi:$MY_ADDR::::iqn.$MY_EMAN:fc$MY_FVER console=tty0 console=ttyS0,115200n8 audit=0 selinux=0 quiet initrd --name initrd.img \${prefix}/initramfs-$MY_KRNL.img boot || goto failed END

The above menu has five sections:

  • menu defines the actual menu that will be shown on the screen.
  • failed notifies the user that something went wrong and drops the user to a shell so they can troubleshot the problem.
  • shell provides an interactive command prompt. You can reach it either by pressing the Esc key while at the boot menu or if the “boot” command returns with a failure code.
  • lcl contains a single command that tells iPXE to exit and return control back to the BIOS. Whatever you want to boot by default (e.g. the workstation’s local hard drive) must be listed as the next boot item right after iPXE in your workstation’s BIOS.
  • f29 contains the same netboot code used earlier but with the final exit replaced with goto failed.

Copy the updated boot.cfg from your $HOME/esp/linux directory out to the ESPs of all your client systems. If all goes well, you should see results similar to the image below:

A server hosted boot menu

Another feature you can add to the netboot server is the ability to manage all the client boot menus from one central location. This feature can be especially useful when rolling out a new version of the OS. It lets you perform a sort of atomic transaction to switch all clients over to the new OS after you’ve copied the new kernel and initramfs out to the ESPs of all the clients.

Install Mojolicious:

$ sudo -i # dnf install -y perl-Mojolicious

Define the “bootmenu” app:

# mkdir /opt/bootmenu # cat << END > /opt/bootmenu/ #!/usr/bin/env perl use Mojolicious::Lite; use Mojolicious::Plugins; plugin 'Config'; get '/menu'; app->start; END # chmod 755 /opt/bootmenu/

Define the configuration file for the bootmenu app:

# cat << END > /opt/bootmenu/bootmenu.conf { hypnotoad => { listen => ['http://*:80'], pid_file => '/run/bootmenu/', } } END

This is an extremely simple Mojolicious application that listens on port 80 and only answers to /menu requests. If you want a quick introduction to what Mojolicious can do, run man Mojolicious::Guides::Growing to view the manual. Use the Q key to quit the manual.

Move boot.cfg over to our netboot app as a template named menu.html.ep:

# mkdir /opt/bootmenu/templates # mv $HOME/esp/linux/boot.cfg /opt/bootmenu/templates/menu.html.ep

Define a systemd service to manage the bootmenu app:

# cat << END > /etc/systemd/system/bootmenu.service [Unit] Description=Serves iPXE Menus over HTTP [Service] Type=forking DynamicUser=true RuntimeDirectory=bootmenu PIDFile=/run/bootmenu/ ExecStart=/usr/bin/hypnotoad /opt/bootmenu/ ExecReload=/usr/bin/hypnotoad /opt/bootmenu/ AmbientCapabilities=CAP_NET_BIND_SERVICE KillMode=process [Install] END

Add an exception for the HTTP service to the local firewall and start the bootmenu service:

# firewall-cmd --add-service http # firewall-cmd --runtime-to-permanent # systemctl enable bootmenu.service # systemctl start bootmenu.service

Test it with wget:

$ sudo dnf install -y wget $ $ wget -q -O - http://$MY_BOOTMENU_SERVER/menu

The above command should output something 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 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 kernel --name kernel.efi ${prefix}/vmlinuz-4.19.4-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.4-300.fc29.x86_64.img boot || goto failed

Now that the boot menu server is working, rebuild the ipxe.efi bootloader with an init script that points to it.

First, update the init.ipxe script created in part one of this series:

$ $ cat << END > $HOME/ipxe/init.ipxe #!ipxe dhcp || exit set prefix file:///linux chain http://$MY_BOOTMENU_SERVER/menu || exit END

Now, rebuild the boot loader:

$ cd $HOME/ipxe/src $ make clean $ make bin-x86_64-efi/ipxe.efi EMBED=../init.ipxe

Copy the updated bootloader to your ESP:

$ cp $HOME/ipxe/src/bin-x86_64-efi/ipxe.efi $HOME/esp/efi/boot/bootx64.efi

After you’ve copied the updated bootloader to all your clients, you can make future updates to the boot menu simply by editing /opt/bootmenu/templates/menu.html.ep and running:

$ sudo systemctl restart bootmenu.service Making further changes

If the boot menu server is working properly, you’ll longer need the the boot.cfg file on your client systems.

For example, re-add the Fedora 28 image to the boot menu:

$ sudo -i # MY_FVER=28 # MY_KRNL=$(ls -c /fc$MY_FVER/lib/modules | head -n 1) # MY_DNS1= # MY_DNS2= # MY_NAME=$(</etc/hostname) # MY_EMAN=$(echo $MY_NAME | tr '.' "\n" | tac | tr "\n" '.' | cut -b -${#MY_NAME}) # MY_ADDR=$(host -t A $MY_NAME | awk '{print $4}') # cat << END >> /opt/bootmenu/templates/menu.html.ep :f$MY_FVER kernel --name kernel.efi \${prefix}/vmlinuz-$MY_KRNL initrd=initrd.img ro ip=dhcp rd.peerdns=0 nameserver=$MY_DNS1 nameserver=$MY_DNS2 root=/dev/disk/by-path/ip-$MY_ADDR:3260-iscsi-iqn.$MY_EMAN:fc$MY_FVER-lun-1 netroot=iscsi:$MY_ADDR::::iqn.$MY_EMAN:fc$MY_FVER console=tty0 console=ttyS0,115200n8 audit=0 selinux=0 quiet initrd --name initrd.img \${prefix}/initramfs-$MY_KRNL.img boot || goto failed END # sed -i "/item --key 2/a item --key 3 f$MY_FVER 3. RedHat Fedora $MY_FVER" /opt/bootmenu/templates/menu.html.ep # systemctl restart bootmenu.service

If all goes well, your clients should see results similar to the image below the next time they boot:

Best of 2018: Fedora at the Command Line

Wednesday 19th of December 2018 08:00:20 AM

Fedora isn’t just a hugely popular desktop Linux OS. Like most Linux systems it features a powerful command line interface. That lets interested users tinker under the hood to an astounding level. Over the course of the year the Magazine has shown lots of fascinating ways to get into the command line.

As part of our Best of 2018 series, we look back at some of the most popular posts on Fedora Magazine that focus on the command line.

4 cool apps for your terminal

In July, Alexander took a look at command line applications that are, well — cool! The command line is often reserved for more technical work. But this exciting post shows you can still have plenty of fun in a text-based world.

4 cool apps for your terminal

4 tips for better tmux sessions

Are you using or interested in learning more about tmux? The terminal multiplexer is incredibly powerful, allowing for multiple windows and panes within one terminal window. In this article, Paul takes you through some great tips to boost your experience with tmux, and make it work even better.

4 tips for better tmux sessions

Set up zsh on your Fedora system

In a reminder that a Linux system is infinitely customizable, Eduard took us through switching to the zsh shell with this post from May. These instructions to install and get up and running with zsh make it easy to get comfortable changing to a new shell.

Set up zsh on your Fedora system

Your favorite

Do you have a favorite command line post on Fedora Magazine this year? Or perhaps a favorite terminal application you’d like to share? Use the comment section below to share your tips and enjoyment of the command line.

4 cool new projects to try in COPR for December 2018

Monday 17th of December 2018 08:00:29 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.


MindForger is a Markdown editor and a notebook. In addition to features you’d expect from a Markdown editor, MindForger lets you split a single file into multiple notes. It’s easy to organize the notes and move them around between files, as well as search through them. I’ve been using MindForger for some time for my study notes, so it’s nice that it’s available through COPR now.

Installation instructions

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

sudo dnf copr enable deadmozay/mindforger sudo dnf install mindforger Clingo

Clingo is a program for solving logical problems using answer set programming (ASP) modeling language. With ASP, you can declaratively describe a problem as a logical program that Clingo then solves. As a result, Clingo produces solutions to the problem in the form of logical models, called answer sets.

Installation instructions

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

sudo dnf copr enable timn/clingo sudo dnf install clingo SGVrecord

SGVrecord is a simple tool for recording your screen. It allows you to either capture the whole screen or select just a part of it. Furthermore, it is possible to make the record with or without sound. Sgvrecord produces files in WebM format.

Installation instructions

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

sudo dnf copr enable youssefmsourani/sgvrecord sudo dnf install sgvrecord Watchman

Watchman is a service for monitoring and recording when changes are done to files.
You can specify directory trees for Watchman to monitor, as well as define actions
that are triggered when specified files are changed.

Installation instructions

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

sudo dnf copr enable eklitzke/watchman sudo dnf install watchman

Best of 2018: Fedora as your Linux desktop

Friday 14th of December 2018 01:48:00 PM

Gaming on your Linux desktop, trying alternative desktop environments, and tweaking little details such as your boot screen. Yes, it’s been a whole year again! What a great time to look back at the most popular articles on the Fedora Magazine written by our awesome contributors.

Let’s dive into the first article of the “Best of 2018” series — this time focused on Fedora Workstation and how you like to use it on your Linux desktop.

Install NVIDIA GPU on your system

Are you a gamer or a researcher? Having a strong GPU might be crucial for you.

This article will guide you through the installation of an NVIDIA GPU — both the hardware and the drivers — on your Fedora Workstation. Ready for science and some fun?

Install an NVIDIA GPU on almost any machine

Install Steam or Chrome from 3rd-party repositories

Now that we have a powerful GPU installed on our system, let’s play some games! Did you know you can install Steam, a popular gaming platform, on Fedora?

If you’re not a gamer, you might appreciate a wide variety of other popular software such as Google Chrome that can be installed from the third-party repos.

This article gives you all the information you need about the new third-party repositories. You’ll learn how to enable them and how to consume the apps using Gnome Software or DNF.

New third-party repositories — easily install Chrome & Steam on Fedora

Get started with openbox

One favorite perk of using a Linux desktop is the variety of different window managers. And there are many different ones available for Fedora.

This article covers openbox — a lightweight window manager focusing on minimal desktop experience.

Getting Started with the openbox windows manager in Fedora

And since there are so many window managers, here is a small bonus you: 5 cool tiling window managers — using tiles instead of windows.

Change your Plymouth bootup theme

And in case you like visually tweaking your system in any way possible, don’t forget about your boot screen!

This article shows you how to change the Plymouth bootup theme.

How to change the Plymouth bootup theme

How to Build a Netboot Server, Part 2

Wednesday 12th of December 2018 08:00:19 AM

The article How to Build a Netboot Server, Part 1 showed you how to create a netboot image with a “liveuser” account whose home directory lives in volatile memory. Most users probably want to preserve files and settings across reboots, though. So this second part of the netboot series shows how to reconfigure the netboot image from part one so that Active Directory user accounts can log in and their home directories can be automatically mounted from a NFS server.

Part 3 of this series will show how to make an interactive and centrally-configurable iPXE boot menu for the netboot clients.

Setup NFS4 Home Directories with KRB5 Authentication

Follow the directions from the previous post “Share NFS Home Directories Securely with Kerberos,” then return here.

Remove the Liveuser Account

Remove the “liveuser” account created in part one of this series:

$ sudo -i # sed -i '/automaticlogin/Id' /fc28/etc/gdm/custom.conf # rm -f /fc28/etc/sudoers.d/liveuser # for i in passwd shadow group gshadow; do sed -i '/^liveuser:/d' /fc28/etc/$i; done Configure NTP, KRB5 and SSSD

Next, we will need to duplicate the NTP, KRB5, and SSSD configuration that we set up on the server in the client image so that the same accounts will be available:

# MY_HOSTNAME=$(</etc/hostname) # MY_DOMAIN=${MY_HOSTNAME#*.} # dnf -y --installroot=/fc28 install ntp krb5-workstation sssd # cp /etc/ntp.conf /fc28/etc # chroot /fc28 systemctl enable ntpd.service # cp /etc/krb5.conf.d/${MY_DOMAIN%%.*} /fc28/etc/krb5.conf.d # cp /etc/sssd/sssd.conf /fc28/etc/sssd

Reconfigure sssd to provide authentication services, in addition to the identification service already configured:

# sed -i '/services =/s/$/, pam/' /fc28/etc/sssd/sssd.conf

Also, ensure none of the clients attempt to update the computer account password:

# sed -i '/id_provider/a \ \ ad_maximum_machine_account_password_age = 0' /fc28/etc/sssd/sssd.conf

Also, copy the nfsnobody definitions:

# for i in passwd shadow group gshadow; do grep "^nfsnobody:" /etc/$i >> /fc28/etc/$i; done Join Active Directory

Next, you’ll perform a chroot to join the client image to Active Directory. Begin by deleting any pre-existing computer account with the same name your netboot image will use:

# MY_USERNAME=jsmith # MY_CLIENT_HOSTNAME=$(</fc28/etc/hostname) # adcli delete-computer "${MY_CLIENT_HOSTNAME%%.*}" -U "$MY_USERNAME"

Also delete the krb5.keytab file from the netboot image if it exists:

# rm -f /fc28/etc/krb5.keytab

Perform a chroot into the netboot image:

# for i in dev dev/pts dev/shm proc sys run; do mount -o bind /$i /fc28/$i; done # chroot /fc28 /usr/bin/bash --login

Perform the join:

# MY_USERNAME=jsmith # MY_HOSTNAME=$(</etc/hostname) # MY_DOMAIN=${MY_HOSTNAME#*.} # MY_REALM=${MY_DOMAIN^^} # MY_OU="cn=computers,dc=${MY_DOMAIN//./,dc=}" # adcli join $MY_DOMAIN --login-user="$MY_USERNAME" --computer-name="${MY_HOSTNAME%%.*}" --host-fqdn="$MY_HOSTNAME" --user-principal="host/$MY_HOSTNAME@$MY_REALM" --domain-ou="$MY_OU"

Now log out of the chroot and clear the root user’s command history:

# logout # for i in run sys proc dev/shm dev/pts dev; do umount /fc28/$i; done # > /fc28/root/.bash_history Install and Configure PAM Mount

We want our clients to automatically mount the user’s home directory when they log in. To accomplish this, we’ll use the “pam_mount” module. Install and configure pam_mount:

# dnf install -y --installroot=/fc28 pam_mount # cat << END > /fc28/etc/security/pam_mount.conf.xml <?xml version="1.0" encoding="utf-8" ?> <!DOCTYPE pam_mount SYSTEM "pam_mount.conf.xml.dtd"> <pam_mount> <debug enable="0" /> <volume uid="1400000000-1499999999" fstype="nfs4" server="$MY_HOSTNAME" path="/home/%(USER)" mountpoint="/home/%(USER)" options="sec=krb5" /> <mkmountpoint enable="1" remove="0" /> <msg-authpw>Password:</msg-authpw> </pam_mount> END

Reconfigure PAM to use pam_mount:

# dnf install -y patch # cp -r /fc28/usr/share/authselect/default/sssd /fc28/etc/authselect/custom # echo 'initgroups: files' >> /fc28/etc/authselect/custom/sssd/nsswitch.conf # patch /fc28/etc/authselect/custom/sssd/system-auth << END @@ -12 +12,2 @@ -auth sufficient forward_pass +auth requisite {include if "with-pammount"} +auth sufficient {if "with-pammount":use_first_pass|forward_pass} @@ -35,2 +36,3 @@ session required +session optional {include if "with-pammount"} session optional END # patch /fc28/etc/authselect/custom/sssd/password-auth << END @@ -9 +9,2 @@ -auth sufficient forward_pass +auth requisite {include if "with-pammount"} +auth sufficient {if "with-pammount":use_first_pass|forward_pass} @@ -32,2 +33,3 @@ session required +session optional {include if "with-pammount"} session optional END # chroot /fc28 authselect select custom/sssd with-pammount --force

Also ensure the NFS server’s hostname is always resolvable from the client:

# MY_IP=$(host -t A $MY_HOSTNAME | awk '{print $4}') # echo "$MY_IP $MY_HOSTNAME ${MY_HOSTNAME%%.*}" >> /fc28/etc/hosts

Optionally, allow all users to run sudo:

# echo '%users ALL=(ALL) NOPASSWD: ALL' > /fc28/etc/sudoers.d/users Convert the NFS Root to an iSCSI Backing-Store

Current versions of nfs-utils may have difficulty establishing a second connection from the client back to the NFS server for home directories when an nfsroot connection is already established. The client hangs when attempting to access the home directory. So, we will work around the problem by using a different protocol (iSCSI) for sharing our netboot image.

First chroot into the image to reconfigure its initramfs for booting from an iSCSI root:

# for i in dev dev/pts dev/shm proc sys run; do mount -o bind /$i /fc28/$i; done # chroot /fc28 /usr/bin/bash --login # dnf install -y iscsi-initiator-utils # sed -i 's/nfs/iscsi/' /etc/dracut.conf.d/netboot.conf # echo 'omit_drivers+=" qedi "' > /etc/dracut.conf.d/omit-qedi.conf # echo 'blacklist qedi' > /etc/modprobe.d/blacklist-qedi.conf # KERNEL=$(ls -c /lib/modules | head -n 1) # INITRD=$(find /boot -name 'init*' | grep -m 1 $KERNEL) # dracut -f $INITRD $KERNEL # logout # for i in run sys proc dev/shm dev/pts dev; do umount /fc28/$i; done # > /fc28/root/.bash_history

The qedi driver broke iscsi during testing, so it’s been disabled here.

Next, create a fc28.img sparse file. This file serves as the iSCSI target’s backing store:

# FC28_SIZE=$(du -ms /fc28 | cut -f 1) # dd if=/dev/zero of=/fc28.img bs=1MiB count=0 seek=$(($FC28_SIZE*2))

(If you have one available, a separate partition or disk drive can be used instead of creating a file.)

Next, format the image with a filesystem, mount it, and copy the netboot image into it:

# mkfs -t xfs -L NETROOT /fc28.img # TEMP_MNT=$(mktemp -d) # mount /fc28.img $TEMP_MNT # cp -a /fc28/* $TEMP_MNT # umount $TEMP_MNT

During testing using SquashFS, the client would occasionally stutter. It seems that SquashFS does not perform well when doing random I/O from a multiprocessor client. (See also The curious case of stalled squashfs reads.) If you want to improve throughput performance with filesystem compression, ZFS is probably a better option.

If you need extremely high throughput from the iSCSI server (say, for hundreds of clients), it might be possible to load balance a Ceph cluster. For more information, see Load Balancing Ceph Object Gateway Servers with HAProxy and Keepalived.

Install and Configure iSCSI

Install the scsi-target-utils package which will provide the iSCSI daemon for serving our image out to our clients:

# dnf install -y scsi-target-utils

Configure the iSCSI daemon to serve the fc28.img file:

# MY_REVERSE_HOSTNAME=$(echo $MY_HOSTNAME | tr '.' "\n" | tac | tr "\n" '.' | cut -b -${#MY_HOSTNAME}) # cat << END > /etc/tgt/conf.d/fc28.conf <target iqn.$MY_REVERSE_HOSTNAME:fc28> backing-store /fc28.img readonly 1 </target> END

The leading iqn. is expected by /usr/lib/dracut/modules.d/40network/

Add an exception to the firewall and enable and start the service:

# firewall-cmd --add-service=iscsi-target # firewall-cmd --runtime-to-permanent # systemctl enable tgtd.service # systemctl start tgtd.service

You should now be able to see the image being shared with the tgtadm command:

# tgtadm --mode target --op show

The above command should output something similar to the following:

Target 1: System information: Driver: iscsi State: ready I_T nexus information: LUN information: LUN: 0 Type: controller SCSI ID: IET 00010000 SCSI SN: beaf10 Size: 0 MB, Block size: 1 Online: Yes Removable media: No Prevent removal: No Readonly: No SWP: No Thin-provisioning: No Backing store type: null Backing store path: None Backing store flags:   LUN: 1 Type: disk SCSI ID: IET 00010001 SCSI SN: beaf11 Size: 10488 MB, Block size: 512 Online: Yes Removable media: No Prevent removal: No Readonly: Yes SWP: No Thin-provisioning: No Backing store type: rdwr Backing store path: /fc28.img Backing store flags: Account information: ACL information: ALL

We can now remove the NFS share that we created in part one of this series:

# rm -f /etc/exports.d/fc28.exports # exportfs -rv # umount /export/fc28 # rmdir /export/fc28 # sed -i '/^\/fc28 /d' /etc/fstab

You can also delete the /fc28 filesystem, but you may want to keep it for performing future updates.

Update the ESP to use the iSCSI Kernel

Ipdate the ESP to contain the iSCSI-enabled initramfs:

$ rm -vf $HOME/esp/linux/*.fc28.* $ MY_KRNL=$(ls -c /fc28/lib/modules | head -n 1) $ cp $(find /fc28/lib/modules -maxdepth 2 -name 'vmlinuz' | grep -m 1 $MY_KRNL) $HOME/esp/linux/vmlinuz-$MY_KRNL $ cp $(find /fc28/boot -name 'init*' | grep -m 1 $MY_KRNL) $HOME/esp/linux/initramfs-$MY_KRNL.img

Update the boot.cfg file to pass the new root and netroot parameters:

$ $ MY_EMAN=$(echo $MY_NAME | tr '.' "\n" | tac | tr "\n" '.' | cut -b -${#MY_NAME}) $ MY_ADDR=$(host -t A $MY_NAME | awk '{print $4}') $ sed -i "s! root=[^ ]*! root=/dev/disk/by-path/ip-$MY_ADDR:3260-iscsi-iqn.$MY_EMAN:fc28-lun-1 netroot=iscsi:$MY_ADDR::::iqn.$MY_EMAN:fc28!" $HOME/esp/linux/boot.cfg

Now you just need to copy the updated files from your $HOME/esp/linux directory out to the ESPs of all your client systems. You should see results similar to what is shown in the below screenshot:

Upgrading the Image

First, make a copy of the current image:

# cp -a /fc28 /fc29

Chroot into the new copy of the image:

# for i in dev dev/pts dev/shm proc sys run; do mount -o bind /$i /fc29/$i; done # chroot /fc29 /usr/bin/bash --login

Allow updating the kernel:

# sed -i 's/^exclude=kernel-\*$/#exclude=kernel-*/' /etc/dnf/dnf.conf

Perform the upgrade:

# dnf distro-sync -y --releasever=29

Prevent the kernel from being updated:

# sed -i 's/^#exclude=kernel-\*$/exclude=kernel-*/' /etc/dnf/dnf.conf

The above command is optional, but saves you from having to copy a new kernel out to the clients if you add or update a few packages in the image at some future time.

Clean up dnf’s package cache:

# dnf clean all

Exit the chroot and clear root’s command history:

# logout # for i in run sys proc dev/shm dev/pts dev; do umount /fc29/$i; done # > /fc29/root/.bash_history

Create the iSCSI image:

# FC29_SIZE=$(du -ms /fc29 | cut -f 1) # dd if=/dev/zero of=/fc29.img bs=1MiB count=0 seek=$(($FC29_SIZE*2)) # mkfs -t xfs -L NETROOT /fc29.img # TEMP_MNT=$(mktemp -d) # mount /fc29.img $TEMP_MNT # cp -a /fc29/* $TEMP_MNT # umount $TEMP_MNT

Define a new iSCSI target that points to our new image and export it:

# MY_HOSTNAME=$(</etc/hostname) # MY_REVERSE_HOSTNAME=$(echo $MY_HOSTNAME | tr '.' "\n" | tac | tr "\n" '.' | cut -b -${#MY_HOSTNAME}) # cat << END > /etc/tgt/conf.d/fc29.conf <target iqn.$MY_REVERSE_HOSTNAME:fc29> backing-store /fc29.img readonly 1 </target> END # tgt-admin --update ALL

Add the new kernel and initramfs to the ESP:

$ MY_KRNL=$(ls -c /fc29/lib/modules | head -n 1) $ cp $(find /fc29/lib/modules -maxdepth 2 -name 'vmlinuz' | grep -m 1 $MY_KRNL) $HOME/esp/linux/vmlinuz-$MY_KRNL $ cp $(find /fc29/boot -name 'init*' | grep -m 1 $MY_KRNL) $HOME/esp/linux/initramfs-$MY_KRNL.img

Update the boot.cfg in the ESP:

$ MY_DNS1= $ MY_DNS2= $ $ MY_EMAN=$(echo $MY_NAME | tr '.' "\n" | tac | tr "\n" '.' | cut -b -${#MY_NAME}) $ MY_ADDR=$(host -t A $MY_NAME | awk '{print $4}') $ cat << END > $HOME/esp/linux/boot.cfg #!ipxe kernel --name kernel.efi \${prefix}/vmlinuz-$MY_KRNL initrd=initrd.img ro ip=dhcp rd.peerdns=0 nameserver=$MY_DNS1 nameserver=$MY_DNS2 root=/dev/disk/by-path/ip-$MY_ADDR:3260-iscsi-iqn.$MY_EMAN:fc29-lun-1 netroot=iscsi:$MY_ADDR::::iqn.$MY_EMAN:fc29 console=tty0 console=ttyS0,115200n8 audit=0 selinux=0 quiet initrd --name initrd.img \${prefix}/initramfs-$MY_KRNL.img boot || exit END

Finally, copy the files from your $HOME/esp/linux directory out to the ESPs of all your client systems and enjoy!

More in Tux Machines

today's howtos

Audiocasts: Linux in the Ham Shack (LHS), Linux Action News, Open Source Security Podcast and Let’s Encrypt

  • LHS Episode #266: #$%&! Net Neutrality
    Welcome to the first episode of Linux in the Ham Shack for 2019. In this episode, the hosts discuss topics including the 2018 RTTY Roundup using FT-8, Cubesats and wideband receivers in space, the ORI at Hamcation, Wekcan, Raspberry Pi-based VPN servers, the LHS Linux distributions, CW trainers and much more.
  • LHS Episode #267: The Weekender XXII
    Welcome to the 22nd edition of the LHS Weekender. In this episode, the hosts discuss upcoming amateur radio contests and special event stations, Open Source events in the next fortnight, Linux distributions of interest, news about science, technology and related endeavors as well is dive into food, drink and other hedonistic topics.
  • Linux Action News 89
    Another troubling week for MongoDB, ZFS On Linux lands a kernel workaround, and 600 days of postmarketOS. Plus our thoughts on the new Project Trident release, and Mozilla ending the Test Pilot program.
  • Open Source Security Podcast: Episode 130 - Chat with Snyk co-founder Danny Grander
  • The ACME Era | TechSNAP 395
    We welcome Jim to the show, and he and Wes dive deep into all things Let’s Encrypt.

Review: Sculpt OS 18.09

The Sculpt OS website suggests that the operating system is ready for day to day use, at least in some environments: "Sculpt is used as day-to-day OS by the Genode developers." Though this makes me wonder in what capacity the operating system runs on the machines of those developers. When I tried out the Haiku beta last year, the operating system had some limitations, but I could see how it could be useful to some people in environments with compatible hardware. In theory, I could browse the web, perform some basic tasks and develop software on Haiku. With Sculpt though, I was unable to get the operating system to do anything, from a user's point of view. The small OS could download packages and load some of them into memory, and it could display a graph of related components. Sculpt could connect to my network and mount additional storage. All of this is good and a fine demo of the Genode design. However, I (as a user) was unable to interact with any applications, find a command line, or browse the file system. All of this put a severe damper on my ability to use Sculpt to do anything useful. Genode, and by extension Sculpt OS, has some interesting design goals when it comes to security and minimalism. However, I don't think Sculpt is practical for any end-user tasks at this time. Read more

This Week in Linux, Chrome OS, and Death of Windows 10 Mobile

  • Episode 51 | This Week in Linux
    On this episode of This Week in Linux, we got some new announcements from Inkscape, Purism, Solus, Mozilla, and Steam. We’ll also check out some new Distro releases from Netrunner, Deeping, Android X86 and more. Then we’ll look at some new hardware offerings from Purism and Entroware. Later in the show will talk about some drama happening with a project’s licensing issues and then we’ll round out the episode with some Linux Gaming news including some sales from Humble Bundle. All that and much more!
  • Chrome OS 73 Dev Channel adds Google Drive, Play Files mount in Linux, USB device management and Crostini backup flag
    On Tuesday, Google released the first iteration of Chrome OS 73 for the Dev Channel and there are quite a few new items related to Project Crostini, for Linux app support. Some things in the lengthy changelog only set up new features coming soon while others add new functionality. Here’s a rundown on some of the Crostini additions to Chrome OS 73.
  • Tens to be disappointed as Windows 10 Mobile death date set: Doomed phone OS won't see 2020
    Microsoft has formally set the end date for support of its all-but-forgotten Windows 10 Mobile platform. The Redmond code factory said today that, come December 10, it's curtains for the ill-fated smartphone venture. The retirement will end a four-year run for a Microsoft phone effort that never really got off the ground and helped destroy Nokia in the process. "The end of support date applies to all Windows 10 Mobile products, including Windows 10 Mobile and Windows 10 Mobile Enterprise," Microsoft declared.