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

Let’s try dwm — dynamic window manger

10 hours 31 min ago

If you like efficiency and minimalism, and are looking for a new window manager for your Linux desktop, you should try dwm — dynamic window manager. Written in under 2000 standard lines of code, dwm is extremely fast yet powerful and highly customizable window manager.

You can dynamically choose between tiling, monocle and floating layouts, organize your windows into multiple workspaces using tags, and quickly navigate through using keyboard shortcuts. 

Installation

To install dwm on Fedora, run:

$ sudo dnf install dwm dwm-user

The dwm package installs the window manager itself, and the dwm-user package significantly simplifies configuration which will be explained later in this article.

Additionally, to be able to lock the screen when needed, we’ll also install slock — a simple X display locker.

$ sudo dnf install slock

However, you can use a different one based on your personal preference.

Quick start

To start dwm, choose the dwm-user option on the login screen.

After you log in, you’ll see a very simple desktop. In fact, the only thing there will be a bar at the top listing our nine tags that represent workspaces and a []= symbol that represents the layout of your windows.

Launching applications

Before looking into the layouts, let’s launch some applications so we can play with the layouts as we go. Apps can be started by pressing alt+p and typing the name of the app followed by enter. There is also a shortcut alt+shift+enter for opening a terminal.

Now that we have some apps running, let’s have a look at the layouts.

Layouts

There are three layouts available by default: the tiling layout, the monocle layout, and the floating layout.

The tiling layout, represented by []= on the bar, organizes windows into two main areas: master on the left, and stack on the right. You can activate the tiling layout by pressing alt+t.

The idea behind the tiling layout is that you have your primary window in the master area while still seeing the other ones in the stack, and you can quickly switch between them as needed.

To swap windows between the two areas, hover your mouse over one in the stack area and press alt+enter to swap it with the one in the master area.

The monocle layout, represented by [N] on the top bar, makes your primary window take the whole screen. You can switch to it by pressing alt+m.

Finally, the floating layout lets you move and resize your windows freely. The shortcut for it is alt+f and the symbol on the top bar is ><>.

Workspaces and tags

Each window is assigned to a tag (1-9) listed at the top bar. To view a specific tag, either click on its number using your mouse or press alt+1..9. You can even view multiple tags at once by clicking on their number using the secondary mouse button.

Windows can be moved between different tags by highlighting them using your mouse, and pressing alt+shift+1..9. 

Configuration

To make dwm as minimalistic as possible, it doesn’t use typical configuration files. Instead, you modify a C header file representing the configuration, and recompile it. But don’t worry, in Fedora it’s as simple as just editing one file in your home directory and everything else happens in the background thanks to the dwm-user package provided by the maintainer in Fedora.

First, you need to copy the file into your home directory using a command similar to the following:

$ mkdir ~/.dwm
$ cp /usr/src/dwm-VERSION-RELEASE/config.def.h ~/.dwm/config.h

You can get the exact path by running man dwm-start.

Second, just edit the ~/.dwm/config.h file. As an example, let’s configure a new shortcut to lock the screen by pressing alt+shift+l.

Considering we’ve installed the slock package mentioned earlier in this post, we need to add the following two lines into the file to make it work:

Under the /* commands */ comment, add:

static const char *slockcmd[] = { "slock", NULL };

And the following line into static Key keys[]:

{ MODKEY|ShiftMask, XK_l, spawn, {.v = slockcmd } },

In the end, it should look like as follows: (added lines are highlighted)

...
/* commands */
static char dmenumon[2] = "0"; /* component of dmenucmd, manipulated in spawn() */
static const char *dmenucmd[] = { "dmenu_run", "-m", dmenumon, "-fn", dmenufont, "-nb", normbgcolor, "-nf", normfgcolor, "-sb", selbgcolor, "-sf", selfgcolor, NULL };
static const char *termcmd[]  = { "st", NULL };
static const char *slockcmd[] = { "slock", NULL };

static Key keys[] = {
/* modifier                     key        function        argument */
{ MODKEY|ShiftMask,             XK_l,      spawn,          {.v = slockcmd } },
{ MODKEY,                       XK_p,      spawn,          {.v = dmenucmd } },
{ MODKEY|ShiftMask,             XK_Return, spawn,          {.v = termcmd } },
...

Save the file.

Finally, just log out by pressing alt+shift+q and log in again. The scripts provided by the dwm-user package will recognize that you have changed the config.h file in your home directory and recompile dwm on login. And becuse dwm is so tiny, it’s fast enough you won’t even notice it.

You can try locking your screen now by pressing alt+shift+l, and then logging back in again by typing your password and pressing enter.

Conclusion

If you like minimalism and want a very fast yet powerful window manager, dwm might be just what you have been looking for. However, it probably isn’t for beginners. There might be a lot of additional configuration you’ll need to do in order to make it just as you like it.

To learn more about dwm, see the project’s homepage at https://dwm.suckless.org/.

GNOME 3.32 released & coming to Fedora 30

Friday 15th of March 2019 02:34:37 AM

Today, the GNOME project announced the release of GNOME 3.32.

The release of the GNOME desktop is the default desktop environment in the upcoming release of Fedora 30 Workstation. GNOME 3.32 includes a wide range of enhancements, including: new default application icons, a new emoji chooser in the on screen keyboard, and improved per-app permissions control.

GNOME 3.32 New Icons

GNOME 3.32 features a range of UI tweaks and improvements. Notably, the entire default icon library has been updated and refreshed, featuring more vibrant colours.

Some of the new icons in GNOME 3.32

Additionally, the colours of the desktop are tweaked to the brighter colour palette to match the new icons.

App Menus deprecated

In GNOME 3. the App Menu is the dropdown that appeared in the top left of the panel next to the Activities hotspot. As of GNOME 3.32, this UI feature is deprecated, and all core GNOME default applications now no longer have App Menus.

Fractional Scaling

Previously, the GNOME UI could only scale in increments of 1. With the wide range of different DPI screens available this may cause a strange middle ground on some displays, where the UI is either too small or too large when scaled. GNOME 3.32 provides experimental support for scaling the UI by more granular amounts.

Better emoji input

GNOME 3.32 features an updated on-screen keyboard implementation. Most notably, this includes the ability to easily “type” emoji with the on-screen keyboard

Emoji on-screen keyboard in GNOME 3.32 Improved App permissions control

The new “Application Permissions” in the main settings dialog allows users to view and change permissions for applications.

Read more about this release

There are many more changes and enhancements in this major version of GNOME. Check out the release announcement and the release notes from the GNOME Project for more information.

Screenshots in this post are from the GNOME 3.32 release notes

Libravatar has a new home

Wednesday 13th of March 2019 09:00:24 AM

Libravatar is a free and open source service that anyone can use to host and share an avatar (profile picture) to other websites. Read on for some news about the service and its relevance to the Fedora Project.

As defined in the project’s blog, The Libravatar project is part of a movement working to give control back to people, away from centralized services and the organizations running them. It addresses a simple problem: putting a face on an email address.

The project originated from the will to have a free, as in freedom, service alternative to Gravatar, giving the users the possibility to use a hosted service or to run their own instance of the service and have full control of their data.

In April 2018 the Libravatar project announced that the service will be shutting down. The service is/was being used by many communities like Fedora, Mozilla and the Linux Kernel to name a few. The announcement triggered a big response from the community, of people interested and willing to help to keep it running.

After some coordination, and a complete rewrite of the application the launch of the new service was announced Tuesday 19th February 2019. The Fedora Project is proud to sponsor Libravatar by providing the infrastructure needed to run the service.

Discuss everything Fedora

Monday 11th of March 2019 08:00:15 AM

Are you interested in how Fedora is being developed? Do you want to get involved, or see what goes into making a release? You want to check out Fedora Discussion. It is a relatively new place where members of the Fedora Community meet to discuss, ask questions, and interact. Keep reading for more information.

Note that the Fedora Discussion system is mainly aimed at contributors. If you have questions on using Fedora, check out Ask Fedora (which is being migrated in the future).

Fedora Discussion is a forum and discussion site that uses the Discourse open source discussion platform.

There are already several categories useful for Fedora users, including Desktop (covering Fedora Workstation, Fedora Silverblue, KDE, XFCE, and more) and the Server, Cloud, and IoT category . Additionally, some of the Fedora Special Interest Groups (SIGs) have discussions as well. Finally, the Fedora Friends category helps you connect with other Fedora users and Community members by providing discussions about upcoming meetups and hackfests.

Contribute at the Kernel and Fedora IoT Edition Test Days

Sunday 10th of March 2019 08:00:01 AM

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

There are two upcoming test days this week. The first, on Tuesday March 12, is to test the Kernel 5.0. Wednesday March 13, the test day is focusing on Fedora IoT Edition. Come and test with us to make the upcoming Fedora 30 even better.

Kernel test day

The kernel team is working on final integration for kernel 5.0. This version was just recently released and will arrive soon in Fedora. This version will also be the shipping kernel for Fedora 30. As a
result, the Fedora kernel and QA teams have organized a test day for
Tuesday, March 12. Refer to the wiki page for links to the test images you’ll need to participate.

Fedora IoT Edition test day

Fedora Internet of Things is a variant of Fedora focused on IoT ecosystems. Whether you’re working on a home assistant, industrial gateways, or data storage and analytics, Fedora IoT provides a trusted open source platform to build on. Fedora IoT produces a monthly rolling release to help you keep your ecosystem up-to-date. The IoT and QA teams will have this test day for on Wednesday, March 13. Refer to the wiki page for links and resources to test the IoT Edition.

How do test days work?

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

To contribute, you only need to be able to download test materials (which include some large files) and then read and follow directions step by step.

Detailed information about both test days are on the wiki pages above. If you’re available on or around the days of the events, please do some testing and report your results.

Start a Fedora 29 installation from the GRUB menu

Friday 8th of March 2019 01:30:29 PM

Many VPS (or cloud) providers offer a Fedora image; if yours doesn’t, ask them to consider doing so. Fedora 29 cloud images are available here https://alt.fedoraproject.org/cloud/. However, in that case this article gives you an alternative to try.

In some cases the provider will allow you to load a custom image (raw or QCOW format). They may even let you mount an ISO and perform an installation from scratch. Another use case for booting into an installation from the GRUB menu is a remote server without physical access (or via some out of band remote management console). In this case you cannot insert an USB key or an installation DVD to boot. What if you want to use your preferred distribution in any case, and not be forced to use what is provided?

The solution

One possible way to solve this is to start the Fedora installer using GRUB2. As a prerequisite to the following steps, you’ll need a VM (or baremetal machine) running CentOS 7, with a working network and internet connection.

Be aware that the following instructions come with caveats such as noted. It depends on:

  • The kind of virtualization used by the provider (KVM or VMWare should be fine), and
  • Whether they allow to start the installed system from the disk volume, or if they use some alternative method to load a different kernel that is not the one shipped by the distribution.

Also, whenever you are modifying the GRUB menu with grub2-mkconfig there is the potential to end up booting into the GRUB shell if the menuentry ends up with an error.

Downloading vmlinuz and initrd

To get the initrd.img and the vmlinuz files issue the following commands one after the other.

curl -L -o /boot/initrd-fedora.img https://download.fedoraproject.org/pub/fedora/linux/releases/29/Server/x86_64/os/isolinux/initrd.img

curl -L -o /boot/vmlinuz-fedora https://download.fedoraproject.org/pub/fedora/linux/releases/29/Server/x86_64/os/isolinux/vmlinuz Take some notes

Take note of the current IP address, the MAC address, and the default gateway.

ip a
ip route

And take note of the UUID of the boot partition using the command

blkid

In some cases /boot could be a directory inside the root partition, so you need its UUID.

Add a new menu entry to GRUB

Edit this file /etc/grub.d/40_custom and add this entry (similar to other entries you can find in /etc/grub2.cfg):

menuentry 'FedoraNetInstall' {
load_video
set gfxpayload=keep #Keep gfxmode
insmod gzio #Load the gzio module
insmod part_msdos #Load the MS DOS partition module
insmod ext2 #Load the ext2 partition module
set root='hd0,msdos1' #Set Grub root
if [ x$feature_platform_search_hint = xy ];
then
search --no-floppy --fs-uuid --set=root --hint='hd0,msdos1' <UUID>
else
search --no-floppy --fs-uuid --set=root <UUID>
fi
linux16 /vmlinuz-fedora ip=<IP>::<Gateway>:<Netmask>:eth0:none nameserver=<DNS> ifname=eth0:<MAC address> inst.repo=https://download.fedoraproject.org/pub/fedora/linux/releases/29/Server/x86_64/os inst.lang=en_US inst.keymap=en
initrd16 /initrd-fedora.img
}

Change the values (UUID, IP, gateway and so on) accordingly to reflect your configuration. If you are using DHCP for networking, you don’t need to enter any networking information. If /boot is not a separate partition, you will have to prepend /boot to /vmlinuz-fedora, and also to /initrd-fedora.img in the menuentry.

Generate the new GRUB configuration file

Before generating your grub.cfg file with grub2-mkconfig it is strongly recommended to copy the original grub.cfg file to another name, such as grub.cfg.bak. Also in the /etc/grub.d directory any files not being used to generate the menuentry should be made non-executable with chmod a-x <filename>. CentOS 7 uses 00_header, 00_tuned, 01_users, and 10_linux when generating grub.cfg. Those files and 40_custom need to remain executable for grub2-mkconfig to work as expected.

To make a new grub.cfg file in /boot/grub2 issue the following command as root or preferably with sudo:https://fedoramagazine.org/howto-use-sudo/

grub2-mkconfig -o /boot/grub2/grub.cfg

Then set up the default menu entry that will be selected upon reboot.

grub2-reboot FedoraNetInstall Reboot into your new GRUB menu

After reboot, you should see the typical web console that cloud providers usually offer in their management dashboard. If the boot is successful, you should find yourself following a regular Fedora installation.

By adding inst.text here:

linux16 /vmlinuz-fedora inst.text ip=<IP>::<Gateway>:<Netmask>:eth0:none [...]

You could perform the installation in text mode instead of graphical mode.

If GRUB2 is not installed

If the machine is running grub legacy, edit /etc/grub.conf and add these lines:

title Fedora Inst
root (hd0,0)
kernel /boot/vmlinuz-fedora
ip=<IP>::<Gateway>:<Netmask>::eth0:none nameserver=<DNS> ifname=eth0:<MAC address>
inst.repo=https://download.fedoraproject.org/pub/fedora/linux/releases/29/Server/x86_64/os inst.lang=en_US inst.keymap=en
initrd /boot/initrd-fedora.img

Then issue the following command, where vdX is the VM primary disk.

grub-install /dev/vdX

If you get an error stating No suitable drive was found in the generated device map, try to install GRUB manually. Issue the grub command, then run these commands:

grub> find /boot/grub/stage1 find /boot/grub/stage1 (hd0,0)
grub> root (hd0,0)
root (hd0,0)
Filesystem type is ext2fs, partition type 0x83
grub> setup (hd0)
setup (hd0)
Checking if "/boot/grub/stage1" exists... yes
Checking if "/boot/grub/stage2" exists... yes
Checking if "/boot/grub/e2fs_stage1_5" exists... yes
Running "embed /boot/grub/e2fs_stage1_5 (hd0)"... 27 sectors are embedded. succeeded
Running "install /boot/grub/stage1 (hd0) (hd0)1+27 p (hd0,0)/boot/grub/stage2 /boot/grub/grub.conf"... succeeded
Done.
grub> quit Final notes and troubleshooting

This installation method works best with the VM (or baremetal machine) equipped with at least 2GB of RAM. The CentOS installation should be a default install to begin with, and is expected to use the ext2 filesystem as per the examples.

Pay special attention when partitioning the disk, leave the partition table as is, and format the existing partitions.

For more information on grub2 and how to use the tools provided to better customize your GRUB boot experience, check out this Fedora documentation on the GRUB boot loader.

If you do find yourself in the GRUB shell, you can boot from the backup you made earlier (grub.cfg.bak), by doing something like the following:

grub> ls (hd0), (hd0,msdos1), (hd0,gpt2)
grub> ls (hd0,msdos1)/ efi/ grub2/ initramfs.img vmlinuz
grub> ls (hd0,msdos1)/grub2 device.map grub.cfg grub.cfg.bak
grub> configfile (hd0,msdos1)/grub2/grub.cfg.bak
grub> boot

Get cooking with GNOME Recipes on Fedora

Wednesday 6th of March 2019 10:54:57 AM

Do you love to cook? Looking for a better way to manage your recipes using Fedora? GNOME Recipes is an awesome application available to install in Fedora to store and organize your recipe collection.

GNOME Recipes is an recipe management tool from the GNOME project. It has the visual style of a modern GNOME style application, and feels similar to GNOME Software, but for food.

Installing GNOME Recipes

Recipes is available to install from the 3rd party Flathub repositories. If you have never installed an application from Flathub before, set it up using the following guide:

Install Flathub apps on Fedora

After correctly setting up Flathub as a software source, you will be able to search for and install Recipes via GNOME Software.

Recipe management

Recipes allows you to manually add your own collection of recipes, including photos, ingredients, directions, as well as extra metadata like preparation time, cuisine style, and spiciness.

When entering in a new item, GNOME Recipes there are a range of different measurement units to choose from, as well as special tags for items like temperature, allowing you to easily switch units.

Community recipes

In addition to manually entering in your favourite dishes for your own use, it also allows you to find, use, and contribute recipes to the community. Additionally, you can mark your favourites, and search the collection by the myriad of metadata available for each recipe.

Step by step guidance

One of the awesome little features in GNOME Recipes is the step by step fullscreen mode. When you are ready to cook, simply activate this mode, move you laptop to the kitchen, and you will have a full screen display of the current step in the cooking method. Futhermore, you can set up the recipes to have timers displayed on this mode when something is in the oven.

Fedora 30 supplemental wallpapers

Friday 1st of March 2019 08:00:43 AM

Each release, the Fedora Design team works with the community on a set of 16 additional wallpapers. Users can install and use these to supplement the standard wallpaper. The Fedora Design team encourages submissions from the whole community. Contributors then use the Nuancier app to vote on the top 16 to include.

Voting has closed on the extra wallpapers for Fedora 30. Voters chose from among 56 submissions. A total of 128 Fedora contributors voted, choosing the following 16 backgrounds to include in Fedora 30:

(Editors’ note: Thank you to Sirko Kemter, who authored this article and conducted the voting process.)

JDK Mission Control is now in Fedora 29

Thursday 28th of February 2019 08:00:57 AM

JDK Mission Control (JMC) is now available as a module in Fedora 29. JDK Mission Control is a powerful profiling application for HotSpot JVMs. It has an advanced set of tools that enables efficient and detailed analysis of the extensive data collected by JDK Flight Recorder (JFR). JMC requires JDK 8 or later.

JFR is part of the JVM, and is available in OpenJDK 11 or Oracle JDK 7u4 or later. Therefore, to generate a flight recording to be loaded into JMC for analysis, the target application needs to run on OpenJDK 11 or OracleJDK 7u4 or later.

This article is a guide to install and run JMC on Fedora 29 Workstation. Then you’ll learn how to use it to solve a common problem with Java programs called hot methods.

Installing JMC on Fedora 29

Using Java 11 will allow JMC to record JFR data for itself. Install Java 11 via:

$ sudo dnf install java-11-openjdk

Enable and install the JMC module with the default profile via:

$ sudo dnf module install jmc:latest/default

Run JMC targeting the Java 11 JRE via:

$ jmc -vm /usr/lib/jvm/jre-11/bin
Using JMC and JFR to explore hot methods

JDK Mission Control can be used to deeply analyze Java applications. In this example, we will take a look at hot methods. Hot methods are methods where a high proportion of time is spent during execution. These are good places to start investigating when trying to reduce overall execution time.

To demonstrate, here is a portion of code for a Java application.

Initiator Sample Code

In practice, there are multiple methods of analyzing Java applications in JDK Mission Control. As an example, you can run the application with Flight Recording enabled and set to dump on JVM exit. This generates a Flight Recording (.jfr) file when the application exits, which can be opened by JDK Mission Control. Note that Flight Recorder is available in OpenJDK 11+ and OracleJDK 7u4+.

For example, for OpenJDK 11+ use this command to run the class with Flight Recorder:

$ java -XX:+FlightRecorder -XX:StartFlightRecording=dumponexit=true,filename=initiator.jfr Initiator

After the application has completed execution, open the resulting Flight Recording with JMC. Below is the automated analysis results.

Automated Analysis Results

The automated Method Profiling analysis already indicates a potential optimization area in the calls to Integer.equals(Object). Going to the Method Profiling tab, select that method and check the Stack Trace for it as shown below.

Method Profiling View

In this Stack Trace, you can follow the calls to the method Initiator.countIntersection(Initiator). Checking the Initiator class, shown below, note that counting intersections between two Integer collections would be better done using HashSet collections instead of LinkedLists collections.

After making this change, you can see the execution improve in the follow-up Flight Recording.

Method Profiling View of ‘After’ Code

JDK Mission Control and JDK Flight Recorder gives you a highly detailed view of your Java application behavior. You can use it to diagnose issues with hot methods, deadlocks, lock contention, memory leaks and more. Try it out via the JMC module in Fedora 29!

Netboot a Fedora Live CD

Monday 25th of February 2019 10:08:18 AM

Live CDs are useful for many tasks such as:

  • installing the operating system to a hard drive
  • repairing a boot loader or performing other rescue-mode operations
  • providing a consistent and minimal environment for web browsing
  • …and much more.

As an alternative to using DVDs and USB drives to store your Live CD images, you can upload them to an iSCSI server where they will be less likely to get lost or damaged. This guide shows you how to load your Live CD images onto an iSCSI server and access them with the iPXE boot loader.

Download a Live CD Image $ MY_RLSE=27
$ MY_LIVE=$(wget -q -O - https://dl.fedoraproject.org/pub/archive/fedora/linux/releases/$MY_RLSE/Workstation/x86_64/iso | perl -ne '/(Fedora[^ ]*?-Live-[^ ]*?\.iso)(?{print $^N})/;')
$ MY_NAME=fc$MY_RLSE
$ wget -O $MY_NAME.iso https://dl.fedoraproject.org/pub/archive/fedora/linux/releases/$MY_RLSE/Workstation/x86_64/iso/$MY_LIVE

The above commands download the Fedora-Workstation-Live-x86_64-27-1.6.iso Fedora Live image and save it as fc27.iso. Change the value of MY_RLSE to download other archived versions. Or you can browse to https://getfedora.org/ to download the latest Fedora live image. Versions prior to 21 used different naming conventions, and must be downloaded manually here. If you download a Live CD image manually, set the MY_NAME variable to the basename of the file without the extension. That way the commands in the following sections will reference the correct file.

Convert the Live CD Image

Use the livecd-iso-to-disk tool to convert the ISO file to a disk image and add the netroot parameter to the embedded kernel command line:

$ sudo dnf install -y livecd-tools
$ MY_SIZE=$(du -ms $MY_NAME.iso | cut -f 1)
$ dd if=/dev/zero of=$MY_NAME.img bs=1MiB count=0 seek=$(($MY_SIZE+512))
$ MY_SRVR=server-01.example.edu
$ MY_RVRS=$(echo $MY_SRVR | tr '.' "\n" | tac | tr "\n" '.' | cut -b -${#MY_SRVR})
$ MY_LOOP=$(sudo losetup --show --nooverlap --find $MY_NAME.img)
$ sudo livecd-iso-to-disk --format --extra-kernel-args netroot=iscsi:$MY_SRVR:::1:iqn.$MY_RVRS:$MY_NAME $MY_NAME.iso $MY_LOOP
$ sudo losetup -d $MY_LOOP Upload the Live Image to your Server

Create a directory on your iSCSI server to store your live images and then upload your modified image to it.

For releases 21 and greater:

$ MY_FLDR=/images
$ scp $MY_NAME.img $MY_SRVR:$MY_FLDR/

For releases prior to 21:

$ MY_FLDR=/images
$ MY_LOOP=$(sudo losetup --show --nooverlap --find --partscan $MY_NAME.img)
$ sudo tune2fs -O ^has_journal ${MY_LOOP}p1
$ sudo e2fsck ${MY_LOOP}p1
$ sudo dd status=none if=${MY_LOOP}p1 | ssh $MY_SRVR "dd of=$MY_FLDR/$MY_NAME.img"
$ sudo losetup -d $MY_LOOP Define the iSCSI Target

Run the following commands on your iSCSI server:

$ sudo -i
# MY_NAME=fc27
# MY_FLDR=/images
# MY_SRVR=`hostname`
# MY_RVRS=$(echo $MY_SRVR | tr '.' "\n" | tac | tr "\n" '.' | cut -b -${#MY_SRVR})
# cat << END > /etc/tgt/conf.d/$MY_NAME.conf
<target iqn.$MY_RVRS:$MY_NAME>
backing-store $MY_FLDR/$MY_NAME.img
readonly 1
allow-in-use yes
</target>
END
# tgt-admin --update ALL Create a Bootable USB Drive

The iPXE boot loader has a sanboot command you can use to connect to and start the live images hosted on your iSCSI server. It can be compiled in many different formats. The format that works best depends on the type of hardware you’re running. As an example, the following instructions show how to chain load iPXE from syslinux on a USB drive.

First, download iPXE and build it in its lkrn format. This should be done as a normal user on a workstation:

$ sudo dnf install -y git
$ git clone http://git.ipxe.org/ipxe.git $HOME/ipxe
$ sudo dnf groupinstall -y "C Development Tools and Libraries"
$ cd $HOME/ipxe/src
$ make clean
$ make bin/ipxe.lkrn
$ cp bin/ipxe.lkrn /tmp

Next, prepare a USB drive with a MSDOS partition table and a FAT32 file system. The below commands assume that you have already connected the USB drive to be formatted. Be careful that you do not format the wrong drive!

$ sudo -i
# dnf install -y parted util-linux dosfstools
# echo; find /dev/disk/by-id ! -regex '.*-part.*' -name 'usb-*' -exec readlink -f {} \; | xargs -i bash -c "parted -s {} unit MiB print | perl -0 -ne '/^Model: ([^(]*).*\n.*?([0-9]*MiB)/i && print \"Found: {} = \$2 \$1\n\"'"; echo; read -e -i "$(find /dev/disk/by-id ! -regex '.*-part.*' -name 'usb-*' -exec readlink -f {} \; -quit)" -p "Drive to format: " MY_USB
# umount $MY_USB?
# wipefs -a $MY_USB
# parted -s $MY_USB mklabel msdos mkpart primary fat32 1MiB 100% set 1 boot on
# mkfs -t vfat -F 32 ${MY_USB}1

Finally, install syslinux on the USB drive and configure it to chain load iPXE:

# dnf install -y syslinux-nonlinux
# syslinux -i ${MY_USB}1
# dd if=/usr/share/syslinux/mbr.bin of=${MY_USB}
# MY_MNT=$(mktemp -d)
# mount ${MY_USB}1 $MY_MNT
# MY_NAME=fc27
# MY_SRVR=server-01.example.edu
# MY_RVRS=$(echo $MY_SRVR | tr '.' "\n" | tac | tr "\n" '.' | cut -b -${#MY_SRVR})
# cat << END > $MY_MNT/syslinux.cfg
ui menu.c32
default $MY_NAME
timeout 100
menu title SYSLINUX
label $MY_NAME
menu label ${MY_NAME^^}
kernel ipxe.lkrn
append dhcp && sanboot iscsi:$MY_SRVR:::1:iqn.$MY_RVRS:$MY_NAME
END
# cp /usr/share/syslinux/menu.c32 $MY_MNT
# cp /usr/share/syslinux/libutil.c32 $MY_MNT
# cp /tmp/ipxe.lkrn $MY_MNT
# umount ${MY_USB}1

You should be able to use this same USB drive to netboot additional iSCSI targets simply by editing the syslinux.cfg file and adding additional menu entries.

This is just one method of loading iPXE. You could install syslinux directly on your workstation. Another option is to compile iPXE as an EFI executable and place it directly in your ESP. Yet another is to compile iPXE as a PXE loader and place it on your TFTP server to be referenced by DHCP. The best option depends on your environment.

Final Notes
  • You may want to add the –filename \EFI\BOOT\grubx64.efi parameter to the sanboot command if you compile iPXE in its EFI format.
  • It is possible to create custom live images. Refer to Creating and using live CD for more information.
  • It is possible to add the –overlay-size-mb and –home-size-mb parameters to the livecd-iso-to-disk command to create live images with persistent storage. However, if you have multiple concurrent users, you’ll need to set up your iSCSI server to manage separate per-user writeable overlays. This is similar to what was shown in the “How to Build a Netboot Server, Part 4” article.
  • The live images support a persistenthome option on their kernel command line (e.g. persistenthome=LABEL=HOME). Used together with CHAP-authenticated iSCSI targets, the persistenthome option provides an interesting alternative to NFS for centralized home directories.

Photo by Chris Yates on Unsplash.

Using the NetworkManager’s DNSMasq plugin

Friday 22nd of February 2019 08:29:27 AM

The dnsmasq plugin is a hidden gem of NetworkManager. When using the plugin, instead of using whatever DNS nameserver is doled out by DHCP, NetworkManager will configure a local copy of dnsmasq that can be customized.

You may ask, why would you want to do this? For me personally, I have two use cases:

First, on my laptop, I run a full OpenShift installation for testing purposes. In order to make this work, I really need to be able to add DNS records. I can run a local dnsmasq without NetworkManager, but this config is easier than managing my own.

Second, when I’m at home, I still want to use my home network’s DNS while on VPN. Many VPNs are configured to only route specific traffic through the VPN tunnel and leave my default route in place. This means I can access my local network’s printer and still connect to resources on the VPN.

This is very nice, as it means I can still access my network printer or listen to music from my media server while doing work. However, the VPN connection overwrites my resolv.conf with DNS servers from the VPN network. Therefore, my home network’s DNS is no longer accessible.

The dnsmasq plugin solves this by running a local dnsmasq server that is controlled by NetworkManager. My resolv.conf always points to localhost. For records defined locally (e.g. for my OpenShift Cluster), dnsmasq resolves these correctly. Using more advanced dnsmasq config, I can selectively forward requests for certain domains to specific servers (e.g. to always correctly resolve my home network hosts). And for all other requests, dnsmasq will forward to the DNS servers associated with my current network or VPN.

Here’s how to configure it in Fedora 29:

For some context, my domain on my laptop is called ‘laplab’ and my home domain is ‘.homelab’. At home my DNS server is 172.31.0.1. For DNS entries in laplab, most of those are defined in /etc/hosts. dnsmasq can then slurp them up. I also have some additional DNS entries defined for a wildcard DNS and some aliases.

Below are the five files that need to be added. The files in dnsmasq.d could be combined, but are split up to hopefully better show the example.

  • /etc/NetworkManager/conf.d/00-use-dnsmasq.conf
  • /etc/NetworkManager/dnsmasq.d/00-homelab.conf
  • /etc/NetworkManager/dnsmasq.d/01-laplab.conf
  • /etc/NetworkManager/dnsmasq.d/02-add-hosts.conf
  • /etc/hosts
# /etc/NetworkManager/conf.d/00-use-dnsmasq.conf # # This enabled the dnsmasq plugin. [main] dns=dnsmasq # /etc/NetworkManager/dnsmasq.d/00-homelab.conf # # This file directs dnsmasq to forward any request to resolve # names under the .homelab domain to 172.31.0.1, my # home DNS server. server=/homelab/172.31.0.1 # /etc/NetworkManager/dnsmasq.d/01-laplab.conf # This file sets up the local lablab domain and # defines some aliases and a wildcard. local=/laplab/ # The below defines a Wildcard DNS Entry. address=/.ose.laplab/192.168.101.125 # Below I define some host names. I also pull in address=/openshift.laplab/192.168.101.120 address=/openshift-int.laplab/192.168.101.120 # /etc/NetworkManager/dnsmasq.d/02-add-hosts.conf # By default, the plugin does not read from /etc/hosts. # This forces the plugin to slurp in the file. # # If you didn't want to write to the /etc/hosts file. This could # be pointed to another file. # addn-hosts=/etc/hosts # /etc/hosts # # The hostnames I define in that will be brought in and resolvable # because of the config in the 02-add-hosts.conf file. # 127.0.0.1 localhost localhost.localdomain ::1 localhost localhost.localdomain # Notice that my hosts be in the .laplab domain, like as configured # in 01-laplab.conf file 192.168.101.120 ose-lap-jumphost.laplab 192.168.101.128 ose-lap-node1.laplab # Name not in .laplab will also get picked up. So be careful # defining items here. 172.31.0.88 overwrite.public.domain.com

After all those files are in place, restart NetworkManager with systemctl restart NetworkManager. If everything is working right, you should see that your resolv.conf points to 127.0.0.1 and a new dnsmasq process spawned.

$ ps -ef | grep dnsmasq dnsmasq 1835 1188 0 08:01 ? 00:00:00 /usr/sbin/dnsmasq --no-resolv --keep-in-foreground --no-hosts --bind-interfaces --pid-file=/var/run/NetworkManager/dnsmasq.pid --listen-address=127.0.0.1 --cache-size=400 --clear-on-reload --conf-file=/dev/null --proxy-dnssec --enable-dbus=org.freedesktop.NetworkManager.dnsmasq --conf-dir=/etc/NetworkManager/dnsmasq.d $ cat /etc/resolv.conf # Generated by NetworkManager nameserver 127.0.0.1 $ host ose-lap-jumphost.laplab ose-lap-jumphost.laplab has address 192.168.101.120

This configuration will survive reboots and, in my testing, works with almost every network and VPN I’ve tried it with.

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/sshd

Comment out the auth substack password-auth line:

#auth       substack     password-auth

Add the following line to the bottom of the file.

auth sufficient pam_google_authenticator.so

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 user@example.com
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 user@example.com
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 release-monitoring.org. You’ll see how it can help you catch up with upstream releases.

What is release-monitoring.org?

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

Anitya is what you can see when visiting release-monitoring.org. 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 release-monitoring.org

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

Index page of release-monitoring.org

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 release-monitoring.org

The release-monitoring.org 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:

Anitya
  • Add libraries.io consumer – automatically check for new releases on libraries.io, 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
the-new-hotness
  • 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)
Both
  • 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 https://github.com/benjaminp/six.git
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

test_six.py ...................................... [ 19%]
.................................................. [ 45%]
.................................................. [ 70%]
..............................................s... [ 96%]
....... [100%]
========= 194 passed, 1 skipped in 0.25 seconds ==========
________________________ summary _________________________
py38: commands succeeded
congratulations

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 https://silverblue.fedoraproject.org/ 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 https://flathub.org/repo/flathub.flatpakrepo

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

AutomaticLoginEnable=True
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.

[Unit]
Description=Update HTPC

[Service]
Type=oneshot
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.

[Unit]
Description=Run htpc-update.service once a week

[Timer]
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.

Prerequisites

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 https://github.com/minishift/minishift/releases/download/v1.31.0/minishift-1.31.0-linux-amd64.tgz

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 https://github.com/dhiltgen/docker-machine-kvm/releases/download/v0.10.0/docker-machine-driver-kvm-centos7 -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:
https://192.168.42.140:8443/console

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/__init__.py
$ cp settings.py settings/local.py
$ mv settings.py settings/production.py
$ tree settings/
settings/
├── __init__.py
├── local.py
└── production.py

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

In todo_app/settings/productions.py replace the DATABASE dictionary with the following:

DATABASES = {
"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.

SECRET_KEY = os.getenv("DJANGO_SECRET_KEY")
ALLOWED_HOSTS = ["*"]
DEBUG = False

REST_FRAMEWORK = {
'DEFAULT_RENDERER_CLASSES': (
'rest_framework.renderers.JSONRenderer',
)
}

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:

django
djangorestframework
psycopg2-binary
gunicorn

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/manage.py and django-rest-framework-todo/wsgi.py 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 https://192.168.42.140:8443 (openshift)
Username: developer
Password: developer
Login successful.
....
$ oc new-project todo
Now using project "todo" on server "https://192.168.42.140:8443".
....

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
NAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGE
postgresql ClusterIP 172.30.88.94 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~https://github.com/cverna/django-rest-framework-todo.git#production DJANGO_SECRET_KEY=a_very_long_and_random_string DB_PASSWORD=todoapp DB_HOST=172.30.88.9

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
NAME HOST/PORT
django-rest-framework-todo django-rest-framework-todo-todo.192.168.42.140.nip.io

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://django-rest-framework-todo-todo.192.168.42.140.nip.io/api/todo/
....
[]

$ http -v POST http://django-rest-framework-todo-todo.192.168.42.140.nip.io/api/todo/ title="Task 1" description="A new task"
...
{
"description": "A new task",
"id": 1,
"status": "todo",
"title": "Task 1"
}
$ http -v PATCH http://django-rest-framework-todo-todo.192.168.42.140.nip.io/api/todo/1 status="wip"
{
"status": "wip"
}
$ http --follow -v GET http://django-rest-framework-todo-todo.192.168.42.140.nip.io/api/todo/1
{
"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

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 https://getfedora.org 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 getfedora.org.

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 username@shared.example.net
The authenticity of host 'shared.example.net' can't be established.
ECDSA key fingerprint is SHA256:kRfekGaa456ga34tddrgg8kZ3VmBbqlx6vZZwhcRpuc.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'shared.example.net' (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 shared.example.net 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.

More in Tux Machines

Forbes Says The Raspberry Pi Is Big Business

Not that it’s something the average Hackaday reader is unaware of, but the Raspberry Pi is a rather popular device. While we don’t have hard numbers to back it up (extra credit for anyone who wishes to crunch the numbers), it certainly seems a day doesn’t go by that there isn’t a Raspberry Pi story on the front page. But given that a small, cheap, relatively powerful, Linux computer was something the hacking community had dreamed of for years, it’s hardly surprising. [...] So where has the Pi been seen punching a clock? At Sony, for a start. The consumer electronics giant has been installing Pis in several of their factories to monitor various pieces of equipment. They record everything from temperature to vibration and send that to a centralized server using an in-house developed protocol. Some of the Pis are even equipped with cameras which feed into computer vision systems to keep an eye out for anything unusual. [Parmy] also describes how the Raspberry Pi is being used in Africa to monitor the level of trash inside of garbage bins and automatically dispatch a truck to come pick it up for collection. In Europe, they’re being used to monitor the health of fueling stations for hydrogen powered vehicles. All over the world, businesses are realizing they can build their own monitoring systems for as little as 1/10th the cost of turn-key systems; with managers occasionally paying for the diminutive Linux computers out of their own pocket. Read more

Graphics: NVIDIA, Nouveau and Vulkan

  • NVIDIA 418.49.04 Linux Driver Brings Host Query Reset & YCbCr Image Arrays
    NVIDIA has issued new Vulkan beta drivers leading up to the Game Developers Conference 2019 as well as this next week there being NVIDIA's GPU Technology Conference (GTC) nearby in California. The only publicly mentioned changes to this weekend's NVIDIA 418.49.04 Linux driver update (and 419.62 on the Windows side) is support for the VK_EXT_host_query_reset and VK_EXT_ycbcr_image_arrays extensions.
  • Nouveau NIR Support Lands In Mesa 19.1 Git
    It shouldn't come as any surprise, but landing today in Mesa 19.1 Git is the initial support for the Nouveau Gallium3D code to make use of the NIR intermediate representation as an alternative to Gallium's TGSI. The Nouveau NIR support is part of the lengthy effort by Red Hat developers on supporting this IR as part of their SPIR-V and compute upbringing. The NIR support is also a stepping stone towards a potential NVIDIA Vulkan driver in the future.
  • Vulkan 1.1.104 Brings Native HDR, Exclusive Fullscreen Extensions
    With the annual Game Developers' Conference (GDC) kicking off tomorrow in San Francisco, Khronos' Vulkan working group today released Vulkan 1.1.104 that comes with several noteworthy extensions. Vulkan 1.1.104 is the big update for GDC 2019 rather than say Vulkan 1.2, but it's quite a nice update as part of the working group's weekly/bi-weekly release regiment. In particular, Vulkan 1.1.104 is exciting for an AMD native HDR extension and also a full-screen exclusive extension.
  • Interested In FreeSync With The RADV Vulkan Driver? Testing Help Is Needed
    Since the long-awaited introduction of FreeSync support with the Linux 5.0 kernel, one of the missing elements has been this variable rate refresh support within the RADV Vulkan driver. When the FreeSync/VRR bits were merged into Linux 5.0, the RadeonSI Gallium3D support was quick to land for OpenGL games but RADV Vulkan support was not to be found. Of course, RADV is the unofficial Radeon open-source Vulkan driver not officially backed by AMD but is the more popular driver compared to their official AMDVLK driver or the official but closed driver in their Radeon Software PRO driver package (well, it's built from the same sources as AMDVLK but currently with their closed-source shader compiler rather than LLVM). So RADV support for FreeSync has been one of the features users have been quite curious about and eager to see.

New Screencasts: Xubuntu 18.04.2, Ubuntu MATE, and Rosa Fresh 11

9 Admirable Graphical File Managers

Being able to navigate your local filesystem is an important function of personal computing. File managers have come a long way since early directory editors like DIRED. While they aren’t cutting-edge technology, they are essential software to manage any computer. File management consists of creating, opening, renaming, moving / copying, deleting and searching for files. But file managers also frequently offer other functionality. In the field of desktop environments, there are two desktops that dominate the open source landscape: KDE and GNOME. They are smart, stable, and generally stay out of the way. These use the widget toolkits Qt and GTK respectively. And there are many excellent Qt and GTK file managers available. We covered the finest in our Qt File Managers Roundup and GTK File Managers Roundup. But with Linux, you’re never short of alternatives. There are many graphical non-Qt and non-Gtk file managers available. This article examines 9 such file managers. The quality is remarkably good. Read more