Posted on Leave a comment

Fedora 29 on ARM on AWS

This week Amazon announced their new A1 arm64 EC2 Instances powered by their arm64 based Graviton Processors and, with a minor delay, the shiny new Fedora 29 for aarch64 (arm64) is now available to run there too!

Details on getting running on AWS is in this good article on using AWS tools on Fedora article and over all using Fedora on the AWS arm64 EC2 is the same as x86_64.

So while a new architecture on AWS is very exciting it’s at the same time old and boring! You’ll get the same versions of kernel, same features like SELinux and the same versions of the toolchain stacks, like the latest gcc, golang, rust etc in Fedora 29 just like all other architectures. You’ll also get all the usual container tools like podman, buildah, skopeo and kubernetes, and orchestration tools like ansible. Basically if you’re using Fedora on AWS you should be able use it in the same way on arm64.

Getting started

The initial launch of A1 aarch64 instances are available in the following four regions: US East (N. Virginia), US East (Ohio), US West (Oregon), Europe (Ireland). Direct links to launch the Fedora aarch64 AMIs directly are available here on the Fedora Cloud site.

Getting help

The Fedora support for aarch64 is very robust. It’s been widely used and tested across a number of platforms but of course with new users and new use cases will pick up issues that we’ve yet to encounter. So what is the best way to get help? If you’re having a crash in a particular application it should be reported in the usual way through RH Bugzilla, we have an ARMTracker tracker alias to block against to help identify Arm issues. For assistance with Arm specific queries and issues the Fedora Arm mailing list and we have the #fedora-arm IRC channel on Freenode.

Known issues

We have one known issue. The instance takes a while to get started, it can be up to 5 minutes. This is due to entropy and has been a general problem in virtual environments, across all architectures. We’re working to speed this up and it should be fixed soon. Once things are up an running though everything runs as expected.

Upcoming features

There will be Fedora 29 Atomic host coming in the next Two Week Atomic release, we unfortunately missed their release this time by a small window but it’ll be available in about 2 weeks with their next release and will appear on the site once released. We can’t let you have all the fun at once 😉

Posted on Leave a comment

Standalone web applications with GNOME Web

Do you regularly use a single-page web application, but miss some of the benefits of a full-fledged desktop application? The GNOME Web browser, simply named Web (aka Epiphany)  has an awesome feature that allows you to ‘install’ a web application. By doing this, the web application is then presented in the applications menus, GNOME shell search, and is a separate item when switching windows. This short tutorial walks you through the steps of ‘installing’ a web application with GNOME Web.

Install GNOME Web

GNOME Web is not included in the default Fedora install. To install, search in the Software application for ‘web’, and install.

Alternatively, use the following command in the terminal:

sudo dnf install epiphany

Install as Web Application

Next, launch GNOME Web, and browse to the web application you wish to install. Connect to the application using the browser, and choose ‘Install site as Web Application’ from the menu:

GNOME Web next presents a dialog to edit the name of the application. Either leave it as the default (the URL) or change to something more descriptive:

Finally, press Create to ‘install’ your new web application. After creating the web application, close GNOME Web.

Using the new web application

Launch the web application as you would with any typical desktop application. Search for it in the GNOME Shell Overview:

Additionally, the web application will appear as a separate application in the alt-tab application switcher:

One additional feature this adds is that all web notifications from the ‘installed’ web application are presented as regular GNOME notifications.


Posted on Leave a comment

How to Build a Netboot Server, Part 1

Some computer networks need to maintain identical software installations and configurations on several physical machines. One such environment would be a school computer lab. A netboot server can be set up to serve an entire operating system over a network so that the client computers can be configured from one central location. This tutorial will show one method of building a netboot server.

Part 1 of this tutorial will cover creating a netboot server and image. Part 2 will show how to add Kerberos-authenticated home directories to the netboot configuration.

Initial Configuration

Start by downloading one of Fedora Server’s netinst images, burning it to a CD, and booting the server that will be reformatted from it. We just need a typical “Minimal Install” of Fedora Server for our starting point and we will use the command line to add any additional packages that are needed after the installation is finished.

NOTE: For this tutorial we will be using Fedora 28. Other versions may include a slightly different set of packages in their “Minimal Install”. If you start with a different version of Fedora, then you may need to do some troubleshooting if an expected file or command is not available.

Once you have your minimal installation of Fedora Server up and running, log in as root and set the hostname:

$ $ hostnamectl set-hostname $MY_HOSTNAME

NOTE: Red Hat recommends that both static and transient names match the fully-qualified domain name (FQDN) used for the machine in DNS, such as (Understanding Host Names).

NOTE: This guide is meant to be copy-and-paste friendly. Any value that you might need to customize will be stated as a MY_* variable that you can tweak before running the remaining commands. Beware that if you log out, the variable assignments will be cleared.

NOTE: Fedora 28 Server tends to dump a lot of logging output to the console by default. You may want to disable the console logging temporarily by running: sysctl -w kernel.printk=0

Next, we need a static network address on our server. The following sequence of commands should find and reconfigure your default network connection appropriately:

$ MY_DNS1= $ MY_DNS2= $ MY_IP= $ MY_PREFIX=24 $ MY_GATEWAY= $ DEFAULT_DEV=$(ip route show default | awk '{print $5}') $ DEFAULT_CON=$(nmcli d show $DEFAULT_DEV | sed -n '/^GENERAL.CONNECTION:/s!.*:\s*!! p') $ nohup bash << END nmcli con mod "$DEFAULT_CON" "$DEFAULT_DEV" nmcli con mod "$DEFAULT_DEV" connection.interface-name "$DEFAULT_DEV" nmcli con mod "$DEFAULT_DEV" ipv4.method disabled nmcli con up "$DEFAULT_DEV" nmcli con add con-name br0 ifname br0 type bridge nmcli con mod br0 bridge.stp no nmcli con mod br0 ipv4.dns $MY_DNS1,$MY_DNS2 nmcli con mod br0 ipv4.addresses $MY_IP/$MY_PREFIX nmcli con mod br0 ipv4.gateway $MY_GATEWAY nmcli con mod br0 ipv4.method manual nmcli con up br0 nmcli con add con-name br0-slave0 ifname "$DEFAULT_DEV" type bridge-slave master br0 nmcli con up br0-slave0 END

NOTE: The last set of commands above is wrapped in a “nohup” script because it will disable networking temporarily. The nohup command should allow the nmcli commands to finish running even while your ssh connection is down. Beware that it may take 10 or so seconds for the connection to come back up and that you will have to start a new ssh connection if you changed the server’s IP address.

NOTE: The above network configuration creates a network bridge on top of the default connection so that we can run a virtual machine instance directly on the server for testing later. If you do not want to test the netboot image directly on the server, you can skip creating the bridge and set the static IP address directly on your default network connection.

Install and Configure NFS4

Start by installing the nfs-utils package:

$ dnf install -y nfs-utils

Create a top-level pseudo filesystem for the NFS exports and share it out to your network:

$ MY_SUBNET= $ mkdir /export $ echo "/export -fsid=0,ro,sec=sys,root_squash $MY_SUBNET/$MY_PREFIX" > /etc/exports

SELinux will interfere with the netboot server’s operation. Configuring exceptions for it is beyond the scope of this tutorial, so we will disable it:

$ sed -i '/GRUB_CMDLINE_LINUX/s/"$/ audit=0 selinux=0"/' /etc/default/grub $ grub2-mkconfig -o /boot/grub2/grub.cfg $ sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/sysconfig/selinux $ setenforce 0

NOTE: Editing the grub command line should not be necessary, but simply editing /etc/sysconfig/selinux proved ineffective across reboots of Fedora Server 28 during testing, so the “selinux=0” flag has been set here to be doubly sure.

Now, add an exception for the NFS service to the local firewall and start the NFS service:

$ firewall-cmd --add-service nfs $ firewall-cmd --runtime-to-permanent $ systemctl enable nfs-server.service $ systemctl start nfs-server.service

Create the Netboot Image

Now that our NFS server is up and running, we need to supply it with an operating system image to serve to the client computers. We will start with a very minimal image and add to it after everything is working.

First, create a new directory where our image will be stored:

$ mkdir /fc28

Use the “dnf” command to build the image under the new directory with only a few base packages:

$ dnf -y --releasever=28 --installroot=/fc28 install fedora-release systemd passwd rootfiles sudo dracut dracut-network nfs-utils vim-minimal dnf

It is important that the “kernel” packages were omitted from the above command. Before they are installed, we need to tweak the set of drivers that will be included in the “initramfs” image that is built automatically when the kernel is first installed. In particular, we need to disable “hostonly” mode so that the initramfs image will work on a wider set of hardware platforms and we need to add support for networking and NFS:

$ echo 'hostonly=no' > /fc28/etc/dracut.conf.d/hostonly.conf $ echo 'add_dracutmodules+=" network nfs "' > /fc28/etc/dracut.conf.d/netboot.conf

Now, install the kernel:

$ dnf -y --installroot=/fc28 install kernel

Set a rule to prevent the kernel from being updated:

$ echo 'exclude=kernel-*' >> /fc28/etc/dnf/dnf.conf

Set the locale:

$ echo 'LANG="en_US.UTF-8"' > /fc28/etc/locale.conf

NOTE: Some programs (e.g. GNOME Terminal) will not function if the locale is not properly configured.

Blank root’s passwd:

$ sed -i 's/^root:\*/root:/' /fc28/etc/shadow

Set the client’s hostname:

$ $ echo $MY_CLIENT_HOSTNAME > /fc28/etc/hostname

Disable logging to the console:

$ echo 'kernel.printk = 0 4 1 7' > /fc28/etc/sysctl.d/00-printk.conf 

Define a local “liveuser” in the netboot image:

$ echo 'liveuser:x:1000:1000::/home/liveuser:/bin/bash' >> /fc28/etc/passwd $ echo 'liveuser::::::::' >> /fc28/etc/shadow $ echo 'liveuser:x:1000:' >> /fc28/etc/group $ echo 'liveuser:!::' >> /fc28/etc/gshadow

Allow “liveuser” to sudo:

$ echo 'liveuser ALL=(ALL) NOPASSWD: ALL' > /fc28/etc/sudoers.d/liveuser

Enable automatic home directory creation:

$ dnf install -y --installroot=/fc28 authselect oddjob-mkhomedir $ echo 'dirs /home' > /fc28/etc/rwtab.d/home $ chroot /fc28 authselect select sssd with-mkhomedir --force $ chroot /fc28 systemctl enable oddjobd.service

Since multiple clients will be mounting our image concurrently, we need to configure the image so that it will operate in read-only mode:

$ sed -i 's/^READONLY=no$/READONLY=yes/' /fc28/etc/sysconfig/readonly-root

Configure logging to go to RAM rather than permanent storage:

$ sed -i 's/^#Storage=auto$/Storage=volatile/' /fc28/etc/systemd/journald.conf

Configure DNS:

$ MY_DNS1= $ MY_DNS2= $ cat << END > /fc28/etc/resolv.conf nameserver $MY_DNS1 nameserver $MY_DNS2 END

Work-around a few bugs that exist for read-only root mounts at the time this tutorial is being written (BZ1542567):

$ echo 'dirs /var/lib/gssproxy' > /fc28/etc/rwtab.d/gssproxy $ cat << END > /fc28/etc/rwtab.d/systemd dirs /var/lib/systemd/catalog dirs /var/lib/systemd/coredump END

Finally, we can create the NFS filesystem for our image and share it out to our subnet:

$ mkdir /export/fc28 $ echo '/fc28 /export/fc28 none bind 0 0' >> /etc/fstab $ mount /export/fc28 $ echo "/export/fc28 -ro,sec=sys,no_root_squash $MY_SUBNET/$MY_PREFIX" > /etc/exports.d/fc28.exports $ exportfs -vr

Create the Boot Loader

Now that we have an operating system available to netboot, we need a boot loader to kickstart it on the client systems. For this setup, we will be using iPXE.

NOTE: This section and the following section — Testing with QEMU — can be done on a separate computer; they do not have to be run on the netboot server.

Install git and use it to download iPXE:

$ dnf install -y git $ git clone $HOME/ipxe

Now we need to create a special startup script for our bootloader:

$ cat << 'END' > $HOME/ipxe/init.ipxe #!ipxe prompt --key 0x02 --timeout 2000 Press Ctrl-B for the iPXE command line... && shell || dhcp || exit set prefix file:///linux chain ${prefix}/boot.cfg || exit END

Enable the “file” download protocol:

$ echo '#define DOWNLOAD_PROTO_FILE' > $HOME/ipxe/src/config/local/general.h

Install the C compiler and related tools and libraries:

$ dnf groupinstall -y "C Development Tools and Libraries"

Build the boot loader:

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

Make note of where the where the newly-compiled boot loader is. We will need it for the next section:

$ IPXE_FILE="$HOME/ipxe/src/bin-x86_64-efi/ipxe.efi"

Testing with QEMU

This section is optional, but you will need to duplicate the file layout of the EFI system partition that is shown below on your physical machines to configure them for netbooting.

NOTE: You could also copy the files to a TFTP server and reference that server from DHCP if you wanted a fully diskless system.

In order to test our boot loader with QEMU, we are going to create a small disk image containing only an EFI system partition and our startup files.

Start by creating the required directory layout for the EFI system partition and copying the boot loader that we created in the previous section to it:

$ mkdir -p $HOME/esp/efi/boot $ mkdir $HOME/esp/linux $ cp $IPXE_FILE $HOME/esp/efi/boot/bootx64.efi

The below command should identify the kernel version that our netboot image is using and store it in a variable for use in the remaining configuration directives:

$ DEFAULT_VER=$(ls -c /fc28/lib/modules | head -n 1)

Define the boot configuration that our client computers will be using:

$ MY_DNS1= $ MY_DNS2= $ $ cat << END > $HOME/esp/linux/boot.cfg #!ipxe kernel --name kernel.efi \${prefix}/vmlinuz-$DEFAULT_VER initrd=initrd.img ro ip=dhcp rd.peerdns=0 nameserver=$MY_DNS1 nameserver=$MY_DNS2 root=nfs4:$MY_NFS4:/fc28 console=tty0 console=ttyS0,115200n8 audit=0 selinux=0 quiet initrd --name initrd.img \${prefix}/initramfs-$DEFAULT_VER.img boot || exit END

NOTE: The above boot script shows a minimal example of how to get iPXE to netboot Linux. Much more complex configurations are possible. Most notably, iPXE has support for interactive boot menus which can be configured with a default selection and a timeout. A more advanced iPXE script could, for example, default to booting an operation system from the local disk and only go to the netboot operation if a user pressed a key before a countdown timer reached zero.

Copy the Linux kernel and its associated initramfs to the EFI system partition:

$ cp $(find /fc28/lib/modules -maxdepth 2 -name 'vmlinuz' | grep -m 1 $DEFAULT_VER) $HOME/esp/linux/vmlinuz-$DEFAULT_VER $ cp $(find /fc28/boot -name 'init*' | grep -m 1 $DEFAULT_VER) $HOME/esp/linux/initramfs-$DEFAULT_VER.img

Our resulting directory layout should look like this:

esp ├── efi │   └── boot │   └── bootx64.efi └── linux ├── boot.cfg ├── initramfs-4.18.18-200.fc28.x86_64.img └── vmlinuz-4.18.18-200.fc28.x86_64

To use our EFI system partition with QEMU, we need to create a small “uefi.img” disk image containing it and then connect that to QEMU as the primary boot drive.

Begin by installing the necessary tools:

$ dnf install -y parted dosfstools

Now create the “uefi.img” file and copy the files from the “esp” directory into it:

$ ESP_SIZE=$(du -ks $HOME/esp | cut -f 1) $ dd if=/dev/zero of=$HOME/uefi.img count=$((${ESP_SIZE}+5000)) bs=1KiB $ UEFI_DEV=$(losetup --show -f $HOME/uefi.img) $ parted ${UEFI_DEV} -s mklabel gpt mkpart EFI FAT16 1MiB 100% toggle 1 boot $ mkfs -t msdos ${UEFI_DEV}p1 $ mkdir -p $HOME/mnt $ mount ${UEFI_DEV}p1 $HOME/mnt $ cp -r $HOME/esp/* $HOME/mnt $ umount $HOME/mnt $ losetup -d ${UEFI_DEV}

NOTE: On a physical computer, you need only copy the files from the “esp” directory to the computer’s existing EFI system partition. You do not need the “uefi.img” file to boot a physical computer.

NOTE: On a physical computer you can rename the “bootx64.efi” file if a file by that name already exists, but if you do so, you will probably have to edit the computer’s BIOS settings and add the renamed efi file to the boot list.

Next we need to install the qemu package:

$ dnf install -y qemu-system-x86

Allow QEMU to access the bridge that we created in the “Initial Configuration” section of this tutorial:

$ echo 'allow br0' > /etc/qemu/bridge.conf

Create a copy of the “OVMF_VARS.fd” image to store our virtual machine’s persistent BIOS settings:

$ cp /usr/share/edk2/ovmf/OVMF_VARS.fd $HOME

Now, start the virtual machine:

$ qemu-system-x86_64 -machine accel=kvm -nographic -m 1024 -drive if=pflash,format=raw,unit=0,file=/usr/share/edk2/ovmf/OVMF_CODE.fd,readonly=on -drive if=pflash,format=raw,unit=1,file=$HOME/OVMF_VARS.fd -drive if=ide,format=raw,file=$HOME/uefi.img -net bridge,br=br0 -net nic,model=virtio

If all goes well, you should see results similar to what is shown in the below image:

You can use the “shutdown” command to get out of the virtual machine and back to the server:

$ sudo shutdown -h now

NOTE: If something goes wrong and the virtual machine hangs, you may need to start a new ssh session to the server and use the “kill” command to terminate the “qemu-system-x86_64” process.

Adding to the Image

Adding to the image should be a simple matter of chroot’ing into the image on the server and running “dnf install <package_name>”.

There is no limit to what can be installed on the netboot image. A full graphical installation should function perfectly.

Here is an example of how to bring our minimal netboot image up to a complete graphical installation:

$ 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 -y groupinstall "Fedora Workstation" $ dnf -y remove gnome-initial-setup $ systemctl disable sshd.service $ systemctl enable gdm.service $ systemctl set-default $ sed -i 's/SELINUX=enforcing/SELINUX=disabled/' /etc/sysconfig/selinux $ logout $ for i in run sys proc dev/shm dev/pts dev; do umount /fc28/$i; done 

Optionally, you may want to enable automatic login for the “liveuser” account:

$ sed -i '/daemon/a AutomaticLoginEnable=true' /fc28/etc/gdm/custom.conf $ sed -i '/daemon/a AutomaticLogin=liveuser' /fc28/etc/gdm/custom.conf
Posted on Leave a comment

How to install extensions via the Software application

GNOME is the default desktop environment shipped with Fedora Workstation. GNOME Shell provides an awesome, minimal, default experience that is easy to pick up and use. However, GNOME Shell Extensions make it easy to add to and change the behavior of GNOME.

The website is the canonical source for quality GNOME extensions, and previously, the easiest way to install was directly from the website. However, recent updates to the GNOME Software application now allow you to browse, search, install, and update extensions from This how to covers the basics of installing these extensions using GNOME Software.

Check the Software Sources

On a Fedora Workstation install, should already be enabled by default as a software source. However, it pays to check that it is enabled before proceeding.

First open the Software Repositories dialog by in Software’s application menu:

software application app menu

Then scroll down, finding the item, and checking it is enabled, and enabling it if needed.

Browse Extensions

With the correct software source enabled, extensions from will start appearing in searches in the Software application. To browse just the extensions, click on the Add-Ons category on the main Software page:

The Shell Extension tab then lists all the available extensions:

Note that some of the extensions above are doubled-up. This is because these extensions are also available as RPMs in the official Fedora repositories.

Installing an Extension

Installing an extension is done in the same manner as any other item in the Software Application — simply press the install button and you will be right to go. Note too, that once an extension is installed, you are easily able to launch the extension settings from the details page. Additionally, note the Source item in the details. This shows you if the extension you are installing is from the official Fedora repos, or the source.

Posted on Leave a comment

Submissions now open for the Fedora 30 supplemental wallpapers

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. Submissions are now open for the Fedora 30 Supplemental Wallpapers, and will remain open until January 31, 2019

Have you always wanted to start contributing to Fedora but don’t know how? Submitting a supplemental wallpaper is one of the easiest ways to start as a Fedora contributor. Keep reading to learn how.

What exactly are the supplemental wallpapers?

Supplemental wallpapers are the non-default wallpapers provided with Fedora. 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.

Dates and deadlines

The submission phase opens November 20, 2018 and ends January 31, 2019 at 23:59 UTC.

Important note: In certain circumstances, submissions during the last hours may not get into the election, if there is no time to do legal research.The legal research is done by hand and very time consuming. Please help by following the guidelines correctly and submit only work that has a correct license.

The voting will open February 5, 2019 and will be open until February 25, 2019 at 23:59 UTC.

How to contribute to this package

Fedora uses the Nuancier application to manage the submissions and the voting process. To submit, you need an Fedora account. If you don’t have one, you can create one here. To vote you must have membership in another group such as cla_done or cla_fpca.

For inspiration you can look to former submissions and the  previous winners. Here are some from the last election:

You may only upload two submissions to Nuancier. In case you submit multiple versions of the same image, the team will choose one version of it and accept it as one submission, and deny the other one.

Previously submissions that were not selected should not be resubmitted, and may be rejected. Creations that lack essential artistic quality may also be rejected.

Denied submissions into Nuancier count. Therefore, if you make two submissions and both are rejected, you cannot submit more. Use your best judgment for your submissions.


You can also earn badges for contributing. One badge is for an accepted submission. Another badge is awarded if your submission is a chosen wallpaper. A third is awarded if you participate in the voting process. You must claim this badge during the voting process, as it is not granted automatically.

Posted on Leave a comment

Akash Angle: How do you Fedora?

We recently interviewed Akash Angle 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 Akash Angle?

Akash is a Linux user who ditched Windows some time ago. An avid Fedora user for  the past 9 years, he has tried out almost all the Fedora flavors and spins to get his day to day tasks done. He was introduced to Fedora by a school friend.

What Hardware?

Akash uses a Lenovo B490 at work. It is equipped with an Intel Core i3-3310 Processor, and a 240GB Kingston SSD. “This laptop is great for day to work like surfing the internet, blogging, and a little bit of photo editing and video editing too. Although not a professional laptop and the specs not being that high end, it does the job perfectly,” says Akash.

He uses a Logitech basic wireless mouse and would like to eventually get a mechanical keyboard. His personal computer — which is a custom-built desktop — has the latest 7th-generation Intel i5 7400 processor, and 8GB Corsair Vengeance RAM.

What Software?

Akash is a fan of the GNOME 3 desktop environment. He loves most of the goodies and bells and whistles the OS can throw in for getting basic tasks done.

For practical reasons he prefers a fresh installation as a way of upgrading to the latest Fedora version. He thinks Fedora 29 is arguably the the best workstation out there. Akash says this has been backed up by reviews of various tech evangelists and open source news sites.

To play videos, his go-to is the VLC video player packaged as a Flatpak, which gives him the latest stable version. When Akash wants to make screenshots, the ultimate tool for him is Shutter, which the Magazine has covered in the past. For graphics, GIMP is something without which he wouldn’t be able to work.

Google Chrome stable, and the dev channel, are his most used web browsers. He also uses Chromium and the default version of Firefox, and sometimes even Opera makes its way into the party as well.

All the rest of the magic Akash does is from the terminal, as he is a power user. The GNOME Terminal app is the one for him.

Favorite wallpapers

One of his favorite wallpapers originally coming from Fedora 16 is the following one:

And this is the one he currently uses on his Fedora 29 Workstation today:


Posted on Leave a comment

VS Code Live Share plugin

Contributing to Open Source projects leads to collaborating with people around the world this is traditionally done via emails or instant messages. But with the rise of extreme programing practices like pair programing being able to remotely share a code editor is a great feature. VS Code has a plugin Live Share that does just that.

Getting Started with Live Share

If you do not have VS Code already installed, you can read our previous article to get started.

Using Visual Studio Code on Fedora

Installing the Live Share plugin

First let’s install the dependencies the Live Share plugin requires.

$ sudo dnf install openssl-libs krb5-libs libicu zlib gnome-keyring libsecret desktop-file-utils xorg-x11-utils

Once the installation completes, the Live Share plugin is ready to be installed from the Extensions marketplace.

More details on the role of each dependency can be found in the Documentation.

Finally reload VS Code to activate the new plugin.

Start a Collaboration Session

To start a new collaboration session, it requires a project to be open in VS Code, so let’s clone the following git repository and open it.

$ git clone

This repository contains the source code of the following Magazine article.

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

In VS Code, use the [Ctrl+K, Ctrl+O] combination to select and open the git repository.

Then from the Live Share extension menu start a collaboration session.

Live Share requires its user to sign in so that it can display the identity of the session participants. You can easily sign in using a GitHub account for example.

Ready to collaborate

To start collaborating Live Share provides a link that can be shared with others. You can get this link in you clipboard by clicking on the Invite paticipants … text.

Once one or more participant have joined the session you can start collaborating.

Sharing Code

This is where Live Share really shines as it shows clearly which participant is currently editing the file.

It is also possible to follow a participant. This has for effect to open in your editor all the files that the participant you are following opens.

Sharing Resources

Another feature of Live Share is to share resources like a server, a terminal or even a debugger session. For example it is very easy to share a terminal session and help a participant setting up a development environment, another example would be to share a database server and to inspect the content of a table.


By default the Live Share connection automatically checks if the host machine and the guest machine can communicate directly, if not Live Share uses a relay hosted in the Azure cloud.

It is possible to configure Live Share to use only direct connection between the host and the guest. For that the host machine needs to open a port in the 5990-5999 range and accept inbound local network connections. The guest needs a network route and outbound access to the host on the same port.

Finally set the connection mode to direct in the Live Share settings.

The documentation provides more details on the connectivity options.

Please note that the Live Share extension is available as Public Preview. The extension source code is currently not open source but this should change once the extension is generally available.

Posted on Leave a comment

How Do You Appreciate Fedora?

This week is the first annual Fedora Appreciation Week. As an extension of the How Do You Fedora? series, this article presents how past interviewees appreciate Fedora. The Fedora Project defines four common values that it encourages all contributors and community members to uphold. Those values are known as the Four Foundations. One such value, Friends, represents the vibrant community of contributors and users from across the world, all working towards the same goal: advancing free software.

Like any community, the Fedora community evolves over time. Each contributor’s story is a little different. That diversity is what makes the Fedora community so strong. Kernel contributor Justin Forbes puts it succinctly:

Fedora is the community. So much of what Fedora is now came as a direct result of community effort.

Fedora is successful today because of the many contributors, both past and present, who have put their time and effort into the project. Here are some of their stories, and how they appreciate others in the community.

You can click on any of the story headers to see our original interviews with these notable people.

Maria Leandro’s story

Fedora has been a huge part of my personal and professional life, so choosing a top moment would leave several fantastic stories behind. I do remember that first time I went to a Flock and meet personally people that I had been interacting, learning from and teaching for almost 5 years. For people like us who spend most of our time behind a screen, having that personal meeting can be life changing. That particular moment is not about the goals or the tasks that need to be done, that moment is the prize to people who work for a common well, for those who change people’s life without asking anything in return, it’s the moment when you put a face to those commits and bugs, to those wallpapers and docs; it’s the moment when we stop being a random robot name to be real… that moment when we hug each other and greet, that has to be the best moment in all Open Source History.

Maria has two favorite wallpapers from Fedora releases:

Fedora Core 7 Wallpaper

Fedora 26 Wallpaper

She sends a special thank you to appreciate Máirín Duffy, who leads the Fedora design team:

Definitely my hero, mo (mizmo). She pushed me to be the designer I am today, always had a chat to solve any doubt I had, and is the most friendly person you can meet.

Maria’s most memorable release was early on:

Probably Fedora 6, since it was the first time I did any artwork at all for the community.

Michael Larabel’s story

Without a doubt the best Fedora memory with friends would have to be celebrating the Fedora “Beefy Miracle” release back in 2012 at LinuxTag in Berlin where the Fedora booth played it so well and was serving up free hot dogs to go with the delicious beverages of the region. Lots of good catching up with open-source contributors, discussing new ideas, and more during the wonderful community-driven open-source events particularly in Europe.

Michael’s favorite Fedora desktop wallpaper will be familiar to current readers of the Magazine. It’s the brand new wallpaper for Fedora 29:

Fedora 29 Wallpaper

Michael also sent a special thank you to a very special contributor who died in 2013:

The late Seth Vidal earns much respect for his contributions to Fedora, Yum, and Red Hat communities. His technical achievements were great and he was a kind and interesting person at conferences, etc.

His favorite release was Fedora Core 3:

Fedora Core 3 certainly holds a special place in my heart as it was the first Fedora release I really became intrigued by as it was in much better shape than FC1/FC2. Since there it improved while overall from say Fedora 26 and newer, each release has felt particularly polished and keeps getting better — including Fedora 29 and my experience with it thus far on many test boxes.

Julita Inca’s story

Julita shared with us this photo from a recent Women in Fedora event, celebrating the positive impact and contributions of women in the Fedora community:

Fedora WOmen Event with Julita Inca

Her favorite Fedora wallpaper is from the Fedora 17 release:

Fedora 17 Wallpaper

Julita also took time to appreciate one of Fedora’s amazing Czech community contributors and organizers:

The person I admired since the beginning was Jiri Eischmann! He is a polite person and very active in his community. He continues to inspire me to this day! I hope to soon attend a celebration of Fedora in Europe where I am living now.

Author’s Postscript

As a fellow Fedoran I would like to thank each of the people who responded to my questions and all of the previous interviewees. Writing the How Do You Fedora? series has been immensely rewarding for me. I have learned about lots of new applications and uses of Fedora. The greatest impact of the series is that it reignites my faith in the goodness of the people who make up the Fedora community with each installment.

Posted on Leave a comment

Celebrate Fifteen Years of Fedora

On November 6, 2003, Red Hat announced Fedora Core 1, the first software release of the Fedora Project. This announcement marked the beginning of a collaborative project between Red Hat and its user community.

A history lesson

The Fedora Project traces its roots to a community-led project called

Fedora is a community project to ease publishing and delivery of 3rd party software on the Red Hat platform.

At the time, Red Hat Linux provided a core set of packages suitable for most users. The Fedora project set themselves up as a community of dedicated Red Hat Linux users with a goal of finding and packaging more software that was not shipped in the core Red Hat Linux product offering.

A few months after launching, an even bigger announcement hit the homepage. Red Hat Linux was merging with Fedora Linux, resulting in the Fedora Project. 🎂

The Fedora Project was now a single, community-based team of passionate Linux developers, many of whom were still Red Hat employees. However, the projects were still somewhat separate. Red Hat Linux became Fedora Core; an openly developed project but was restricted to Red Hat employees. (or Fedora Linux) became Fedora Extras, where community members could continue to contribute packages and enhancements on top of Fedora Core.

This structure continued to exist for six releases of Fedora Core. With the release of Fedora 7, the distinction between Fedora Core and Fedora Extras was dropped, and Fedora was one big, happy family!

What’s new in Fedora Core 1

The Linux software ecosystem 15 years ago looked very different that today. Fedora Core 1 introduced a few new packages that might sound familiar to the astute reader:

  • bitstream-vera-fonts
  • dbus
  • epiphany
  • nano
  • rhythmbox
  • yum

Innovation and early adoption has been a part of Fedora since the beginning. Even in 2003, the Fedora Project was pushing forward with new projects. The following are excerpts from the Fedora Core 1 Release Notes.

  • “CUPS is now the only print spooler provided. During upgrades, if LPRng is installed, it will be replaced by CUPS.”
  • “Fedora Core 1 includes the Native POSIX Thread Library (NPTL), a new implementation of POSIX threads for Linux. This library provides performance improvements and increased scalability.”
  • “Fedora Core 1 now uses a graphical interface while booting.”

Not only that, Fedora was in the process of migrating its font system to the new fontconfig/Xft, and switching to UTF-8 across the distribution!

Default desktop

Even in 2003, GNOME was the default desktop for Fedora.

Fedora Core 1 shipped GNOME 2.4, adopting the classic Red Hat Linux panel layout over the upstream project’s two-panel layout.

The Mozilla Suite was the go-to web browser at the time. Mozilla had not yet started the Firefox standalone browser project, so this suite included an email client and usenet news reader. While Mozilla included an email client, Fedora defaulted to Ximian Evolution as its email/groupware program.

Also included:

  • (formerly StarOffice, and not yet LibreOffice)
  • gAIM (Pidgin would rise in popularity as alternatives to AIM came about, such as Yahoo! Messenger and MSN Messenger)
  • X-Chat

Hardware requirements

Fedora Core 1 has some pretty modest hardware requirements, even for 2003.


At a minimum, it requires a Pentium-class CPU. The release notes include an important note about compiler optimizations.

NOTE: Fedora Core 1 is optimized for Pentium PRO (and later) CPUs, but also supports Pentium-class CPUs. This approach has been taken because Pentium-class optimizations actually result in reduced performance for non-Pentium-class processors.

For a graphical installation (an X11-powered desktop), a 400 MHz Pentium II is recommended. And for text-mode only, a 200 MHz Pentium-class or better!

Hard Disk Space

The release notes list a few different space requirements, depending on the intended use:

  • Custom Installation (Minimal): 520MB
  • Server: 870MB
  • Personal Desktop: 1.9GB
  • Workstation: 2.4GB
  • Custom Installation (Everything): 5.3GB

In today’s world of terabytes of cloud storage, the modest difference in megabytes between a “Server” and “Personal Desktop” seems downright quaint in comparison.


There is evidence of Moore’s Law in the memory requirements for Fedora Core 1 too. At a minimum, for “text-mode”, it requires 64 MB! And for graphical installations, that increases to 192 MB at a minimum, but recommends at least 256 MB.

Try it out!

Fedora is proud of its heritage. There is no better way to understand history than to experience it. Fortunately, modern virtualization software ships with Fedora Workstation by default! So why not try out Fedora Core 1 yourself? We’ve put together a virtual disk image of Fedora Core 1 (927 MB download) that can be imported directly into GNOME Boxes. It even points to the “current” update repositories so you can try out the “new” yum package manager yourself.

Posted on Leave a comment

Create a containerized machine learning model

After data scientists have created a machine learning model, it has to be deployed into production. To run it on different infrastructures, using containers and exposing the model via a REST API is a common way to deploy a machine learning model. This article demonstrates how to roll out a TensorFlow machine learning model, with a REST API delivered by Connexion in a container with Podman.


First, install Podman with the following command:

sudo dnf -y install podman

Next, create a new folder for the container and switch to that directory.

mkdir deployment_container && cd deployment_container

REST API for the TensorFlow model

The next step is to create the REST-API for the machine learning model. This github repository contains a pretrained model, and well as the setup already configured for getting the REST API working.

Clone this in the deployment_container directory with the command:

git clone & ml_model/

The file allows for a Tensorflow prediction, while the weights for the 20x20x20 neural network are located in folder ml_model/.


The file swagger.yaml defines the API for the Connexion library using the Swagger specification. This file contains all of the information necessary to configure your server to provide input parameter validation, output response data validation, URL endpoint definition.

As a bonus Connexion will provide you also with a simple but useful single page web application that demonstrates using the API with JavaScript and updating the DOM with it.

swagger: "2.0" info: description: This is the swagger file that goes with our server code version: "1.0.0" title: Tensorflow Podman Article consumes: - "application/json" produces: - "application/json" basePath: "/" paths: /survival_probability: post: operationId: "" tags: - "Prediction" summary: "The prediction data structure provided by the server application" description: "Retrieve the chance of surviving the titanic disaster" parameters: - in: body name: passenger required: true schema: $ref: '#/definitions/PredictionPost' responses: '201': description: 'Survival probability of an individual Titanic passenger' definitions: PredictionPost: type: object & requirements.txt  defines an entry point to start the Connexion server.

import connexion app = connexion.App(__name__, specification_dir='./') app.add_api('swagger.yaml') if __name__ == '__main__':

requirements.txt defines the python requirements we need to run the program.

connexion tensorflow pandas


For Podman to be able to build an image, create a new file called “Dockerfile” in the deployment_container directory created in the preparation step above:

FROM fedora:28 # File Author / Maintainer MAINTAINER Sven Boesiger <> # Update the sources RUN dnf -y update --refresh # Install additional dependencies RUN dnf -y install libstdc++ RUN dnf -y autoremove # Copy the application folder inside the container ADD /titanic_tf_ml_model /titanic_tf_ml_model # Get pip to download and install requirements: RUN pip3 install -r /titanic_tf_ml_model/requirements.txt # Expose ports EXPOSE 5000 # Set the default directory where CMD will execute WORKDIR /titanic_tf_ml_model # Set the default command to execute # when creating a new container CMD python3

Next, build the container image with the command:

podman build -t ml_deployment .

Run the container

With the Container image built and ready to go, you can run it locally with the command:

podman run -p 5000:5000 ml_deployment

Navigate to in your web browser to access the Swagger/Connexion UI and to test-drive the model:

Of course you can now also access the model with your application via the REST-API.