Red Hat Enterprise Linux 8 – Repositories, Ansible, and Flatpak

Out of the box, assuming you’ve done a graphical installation (or installed the graphical bits afterwards) you should be left with a Red Hat desktop that uses Gnome, and is relatively well featured out of the box.

You’ll have software like Gnome Boxes, Terminal, Software, Activity Monitor, Firefox… the typical sort of things you expect any desktop environment to ship with by default.

Now, we have some problems.

The first problem is the fact Red Hat doesn’t, and hasn’t ever, shipped with that many packages in its default repositories. The OS is very targeted towards server work and that means you’re a bit limited in overall choice. For example, it nets me frowns from colleagues, but I’ve often found ‘htop’ to be a much more pleasant experience than vanilla ‘top’ and it’s generally in the default repositories for most distributions, not so with Red Hat.

What about EPEL I hear you shout (or type angrily,) well EPEL isn’t ready yet, and it generally lags a bit behind Red Hat releases, because they’ve got to make sure all the software works reliably and isn’t going to cause problems with the latest version of the OS. At the time of writing EPEL is available for for CentOS/RHEL 7, and not 8.

This is not the end of the world, as we shall see.

Repositories

Once you’ve registered your machine:

# subscription-manager register
# subscription-manager attach

You should have access to the various Red Hat repositories, you can view enabled repositories with the following:

# yum repolist
Updating Subscription Management repositories.
Last metadata expiration check: 0:00:15 ago on Sun 09 Jun 2019 15:31:36 BST.
repo id                                 repo name                         status
rhel-8-for-x86_64-appstream-rpms        Red Hat Enterprise Linux 8 for x8 5,086
rhel-8-for-x86_64-baseos-rpms           Red Hat Enterprise Linux 8 for x8 1,963
rhel-8-for-x86_64-highavailability-rpms Red Hat Enterprise Linux 8 for x8    67

This isn’t to say that you absolutely have to stick to the Red Hat ones, as you’re more than welcome to add any compatible (and sensible) repository that you want to, but these are available for you to use from Red Hat.

If you wanted to know what others were available, you would use the following command (note than I’ve truncated it somewhat as the list can be very long:)

# subscription-manager repos --list
+----------------------------------------------------------+
    Available Repositories in /etc/yum.repos.d/redhat.repo
+----------------------------------------------------------+
Repo ID:   ansible-2-for-rhel-8-x86_64-debug-rpms
Repo Name: Red Hat Ansible Engine 2 for RHEL 8 x86_64 (Debug RPMs)
Repo URL:  https://cdn.redhat.com/content/dist/layered/rhel8/x86_64/ansible/2/debug
Enabled:   0

Repo ID:   rhel-8-for-x86_64-sap-solutions-debug-rpms
Repo Name: Red Hat Enterprise Linux 8 for x86_64 - SAP Solutions (Debug RPMs)
Repo URL:  https://cdn.redhat.com/content/dist/rhel8/$releasever/x86_64/sap-solutions/debug
Enabled:   0
...

You will also note that aside from the regular repositories, we have debug repositories available, which I don’t care about for now.

Ansible

I use Ansible a lot, it’s a great tool for automating deployments and it’s so simple that even someone like me can use it!

With that in mind, I very nearly broke my very first rule and used Pip to install the latest version of Ansible, before I noticed that Red Hat actually had a subscription-repo available, apparently with Ansible 2.8.

Repo ID:   ansible-2.8-for-rhel-8-x86_64-rpms
Repo Name: Red Hat Ansible Engine 2.8 for RHEL 8 x86_64 (RPMs)
Repo URL:  https://cdn.redhat.com/content/dist/layered/rhel8/x86_64/ansible/2.8/os
Enabled:   0

So I enabled this, using the following command:

# subscription-manager repos --enable ansible-2.8-for-rhel-8-x86_64-rpms

And… it turned out the repository wasn’t ready yet, and was actually empty.

Fast-forward a few days, and the repository was now populated, meaning installing Ansible 2.8 was a simple case of running a YUM install.

# yum install ansible

It’s worth noting that as of RHEL 8, you’re actually using ‘dnf’ when you invoke the ‘yum’ command, but it’s also worth noting that DNF stands for Did Not Finish in racing, and given my track record with running marathons, it’s not something I enjoy actively invoking.

The end result of this, is I can use a natively installed (and very recent) version of Ansible on my workstation:

$ ansible --version
ansible 2.8.0
  config file = /etc/ansible/ansible.cfg
...

Flatpak

Now, as I said in the opening post on using RHEL as a workstation, there are some other pieces of software that you just can’t get away from when it comes to modern system administration and DevOps. Slack is one such program.

I’m not actually a fan of Slack, I find it tends to make people sloppy when it comes to going through appropriate channels for work, and I think self-hosted systems are better for workplace environments, but that aside, everybody seems to use it these days.

Slack isn’t available in the default repositories, or this would be a short section, but it is available as a package from Flathub, and Flatpak can be installed from YUM on RHEL 8, giving us access to a much wider variety of programs than we would otherwise have access to.

$ sudo yum install flatpak
$ flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo

Once Flatpak and Flathub are in place, you have two options. You can either search for software from the command line:

$ flatpak search slack
Application ID         Version Branch Remotes Description                   
com.slack.Slack        3.4.2   stable flathub Chat with your team 
...

Or you can now use Gnome Software:

The Software interface is extremely clean.

You can also search for software on the Flathub website, if so inclined.

Software that you, as a Developer or Sysadmin, might find useful include:

  • Slack
  • Visual Studio Code
  • Remmina
  • Skype
  • Builder
  • Atom
  • GitKraken
  • Godot
  • GNU Emacs
  • Sublime Text
  • FileZilla
  • Dropbox

And so on, and so on. All of these are available in the form of Flatpak installations, meaning you don’t have to worry about things like dependencies on your machine.

As with anything, make sure you trust the source of your software, even when it’s proprietary and you can’t even look at the code.

Honestly I think the inclusion of official Flatpak support is one of the best things Red Hat has done with RHEL 8, as it means you get access to a much wider ecosystem than the curated one they offer, without hacking anything to work on your machine.


Adam – Terrafoundry Director and Consultant

Red Hat Enterprise Linux 8 – Boot ISO Installation

This isn’t going to be a long post, not least because installing Linux is something anyone should now be capable of doing (and if you’re not yet, I have a book to recommend.) However, there was a slight caveat I came across when performing the RHEL installation on my laptop.

When I install distributions locally, and I’m forced to use a medium like a CD or DVD, I generally get the ‘net-install’ (what Red Hat calls the Boot ISO) version of the ISO offered from the distribution. This not only saves on their bandwidth, but it means I don’t have to burn gigs of packages to a CD or save them to a thumb drive, when I’m never going to need most of them.

Because of this I grabbed the net-install for RHEL and dug a dusty USB DVD drive out of a drawer to install the OS on my disc-less laptop.

Now… some of you might have already spotted a problem with this, mainly being that because Red Hat’s distribution servers aren’t strictly public (you need a subscription to access them) network installations are generally only recommended if you’re running a local mirror of the upstream repositories. This only became obvious to me after I began the install.

Not one to give up (and actually lacking any large enough pieces of optical media to burn the “full” ISO to) I instead opted to download the full ISO anyway, only I would host it in the form of a web server on another machine, on the same network.

In this way I could still use my net-install disc, only I could point the installer to my hosted directory containing the rest of the packages RHEL wanted.

On my other machine, I downloaded the full ISO, then unpacked it to the local directory:

$ tar xfp rhel-8.0-x86_64-dvd.iso

Note, this was a FreeBSD box, using BSD tar. Your command may differ, always check the man page.

I then used Python’s built in ‘http.server’ to host the contents of the unpacked directory:

$ python3.6 -m http.server 8080

After which, I was able to point the Anaconda installer (on my laptop) to the temporary web server on my other machine. For an example of what this might look like, I provide the below screenshot for your consideration.

Gnome Boxes, in all its glory.

Adam – Terrafoundry Director and Consultant

Red Hat Enterprise Linux 8 – As a Workstation

I recently re-installed my laptop, which in itself doesn’t deserve fanfare and isn’t of any particular note. At one time or another this machine has had Windows, FreeBSD, and various Linux distributions on it (even Ubuntu when I was writing the Linux Administration Cookbook.) What makes it particularly interesting this time is the fact it’s RHEL 8 that I’ve chosen to install.

RHEL 8, the latest offering from the company newly acquired by Big Blue (IBM,) is touted as both a rock-solid server OS, and also something more than capable of handling the daily tasks of any good developer.

It’s of a slight annoyance to me that RHEL 8 was released when it was (May 7, 2019,) as my book on Linux Administration has only been out a few months, but thankfully it also wasn’t the titanic shift that we saw from RHEL 6 to RHEL 7.

As a bit of background, Red Hat now offer a free installation (including access to their repositories) with a developer account. Simply go to their site, sign up, and you can enable a subscription for your machine easily enough.

Why install RHEL, when CentOS is a thing?

The answer here is mostly, “to give it a go,” but I can expand on it a little more:

  • CentOS, while equivalent to Red Hat in terms of compiled software, lacks some features which are RHEL specific, such as the Subscription Manager. If I have an issue with one of these, or want to know more, it’s nice to know the software is already at my fingertips.
  • Increasingly I’m working in environments that have Red Hat agreements, and because of that I like to know that the machine I’m working on has the exact same solutions (and problems) as the server OSes I’m touching.
  • Solutions to problems frequently come from Red Hat, and are then adopted by other distributions. While this isn’t true for everything, Red Hat being a commercial outfit, means they have customers to please. In the real world this means that RHEL usually has fixes for the latest round of Intel execution bugs before a lot of other offerings, along with detailed ‘issue’ pages surrounding the exploits.
  • It’s solid, arguably more so than any other distribution. That isn’t to say there aren’t stable operating systems out there, but Red Hat’s ability to mostly leave things in a stable and consistent state for months, or even years, means I can rely on this laptop no matter which end of the UK I happen to be in.

Of course, these reasons are as full of holes as the front of the latest Mac Pro, but I needed to justify this project to myself, because the last question I wanted to answer was simple…

Can I do my work on RHEL 8?

This was the question I really wanted to know the answer to, because in theory, there’s nothing standing in my way except a bit of patience, and a need to keep things “polished.”

When I say polished I mean that yes, I can install CentOS and then realise I need a more recent kernel, so install one from ELRepo; or I can decide I really want that version of Node.js, so install it from upstream; but soon you start to get surrounded with hacks and fixes that make your OS feel like a clumsy mess.

I have thoughts on keeping your installations ‘clumsy-fix-free,’ and they’re well documented in the book subtly linked above.

I don’t want to install things using Pip, or get additional Gems. I don’t want to have third party repos cluttering my yum.repos.d directory, and I don’t want to compile anything from source (except stuff I’m actively writing or working on!)

Now this is a bit of a problem in the real world, which sadly we live in. I’ll still likely have to concede that installing the latest binary directly from the Hashicorp website is the best way to get Packer or Terraform, and I’m going to resort to Flatpak for some stuff, as you’ll see later, but these are sacrifices that I don’t want to make too many of, and RHEL might be able to do that.

But who knows, maybe even this will get too much for me and I’ll skip happily back into Arch Linux land, confident in the knowledge that everyone who gave me a funny look for installing RHEL on my workstation was wholeheartedly correct.

What these posts are for.

I don’t really expect them to be relevant to many people, not least because I suspect the number of people running Red Hat on their workstation machines is close to the hundreds, rather than the thousands, but I like to document problems and solutions I address when working, and this seems like as good a way as any.

So I suppose, these blog posts are mostly a reference for me, and maybe a couple more oddballs out there who get distracted by red fedoras.


Adam – Terrafoundry Director and Consultant

I wrote a book

Go buy it.

I’ve just finished writing a book titled ‘Linux Administration Cookbook’ for Packt Publishing. Available here: https://www.packtpub.com/virtualization-and-cloud/linux-administration-cookbook

The writing process was… somewhat manic, and owing to how quickly I can write, the publication date was brought forward by two months (which only applied more pressure.)

I hope you find it informative (if you choose to buy and read it) or just downright impressive (if you don’t.)


Adam – Terrafoundry Director and Consultant

This site is PaaS

I mean, in the purely technical sense. At the end of the day there’s always a server somewhere, but in this particular case the server is hosted by Gandi.Net (who I use for their excellent product offerings and customer service) and the site is just a series of files accessible through git or their API.

Having made the transition from managing an entire server for just one website, I have to admit that it’s a breath of fresh air. Where before there was the constant patching, monitoring, and security checks to consider (for an entire OS) my workload has now been cut quite considerably.

I don’t expect this site to get a huge amount of traffic, and even if it does (due to a popular blog post or other) it won’t be enough to cripple the hosting plan that I’m on with Gandi, or their infrastructure.

I’ll be keeping my servers around, I am a techie after all, but they’ve basically been relegated to a playground of sorts, with my big-professional and grown-up sites sitting in a place that I’m considerably less likely to break them.

Who knows, I may get tired of things being so simple and easy in the future, and go back to the headache of setting up iptables rules to block script-kiddies.