RHEL Containers on Non-RHEL Hosts

Update 2020-02-05: This continues to work for Fedora 31 on Podman running UBI8 (registry.access.redhat.com/ubi8)

Introduction

I now do most of my development work in a setup based on RPM-OSTree with my own trees , and doing most of my development work inside containers .

However, I do still work for Red Hat, so would like to test stuff against Red Hat Enterprise Linux-based platforms, but as you might be aware getting the required entitlements setup is considered “difficult”, so I did as probably a lot of people do: I used CentOS containers, just because they don’t require fiddling with the entitlement stuff.

The other day, however, I decided that enough is enough and that I need to eat our own dogfood, so that I need to finally get it set up. Now, if I were just running a RHEL host as development machine itself, it would figure itself out all automatically, but obviously I don’t do that, working for Fedora Infrastructure et al, so I set out to figure out how to get it working on a Fedora host.

Turns out: it’s not actually that difficult as people make it to be, so let me write down how I got it working.

Note: This requires the “Docker Super Secrets” patch. If you don’t have this patch (it’s in the Fedora/RHEL distribution of docker), you will need to manually copy/mount the directory. I’ll explain that at the end of this post.

Note 2: You will only be able to follow this when you have actual RHEL entitlements. This will NOT help you get around that, only explain how to use your existing RHEL entitlements. If you don’t have one yet, you can look at the Red Hat Enterprise Linux Developer Subscription for a self-supported developer subscription.

Setting it up

First off, open a terminal on the host and touch a file in /usr/share/rhel/secrets/ to make sure that this directory is writable (it’s not on ostree-based deployments, which means you’ll need to bind-mount it to a directory that is with something like “mount –bind /home/secret/ /usr/share/rhel/secrets/”).

Now, inside this directory, create the following directory structure:

/usr/share/rhel/secrets
\- etc-pki-entitlement
\- rhsm
  |- ca

Now, you will need some files from an existing RHEL installation, but you can just pull down and start a RHEL container and pull them from there, as they are public files. From any RHEL system, copy /etc/rhsm/rhsm.conf to your hosts’ secrets/rhsm/rhsm.conf, and /etc/rhsm/ca/redhat-uep.pem into the hosts’ secrets/rhsm/ca/redhat-uep.pem.

Those are all the public files, now you will need the RHEL entitlement certificates. For this, go to access.redhat.com , and click on the system (or create one) that you are running this on. Make sure it’s the correct architecture and RHEL version.

Next, make sure there are actually subscriptions attached to this system: you will see these listed under “Attached Subscriptions”, and the will have View and Download links under “Entitlement Certificate”. Click on the Download link under the entitlement that you want to use.

This single PEM file that you just downloaded, contains a certificate, entitlement data, a signature and a private key. Copy this file to the hosts’ /usr/share/rhel/secrets/etc-pki-entitlement/entitlement.pem AND /usr/share/rhel/secrets/etc-pki-entitlement/entitlement-key.pem . Yes, that means copying one file to two locations. Normally, Red Hat Subscription Manager splits the private key out of the certificate file before writing, and it expects to the reverse when reading, but we have a single combined file. You could split it manually, but just copying it to two locations is easier in my opinion.

Now, that should be all. Yes, that’s all there is to it. When you now start a new container (“docker run -it registry.access.redhat.com/rhel7/rhel:latest”), you should see these files in /run/secrets and provided that your entitlement is of the correct version/arch, you can now run yum update!

Without super secrets patch

Now, I had promised to also tell how to use this if you do not have the super secrets patch. This can be done by creating /usr/share/rhel/secrets, performing the steps before, and adding a “-v /usr/share/rhel/secrets:/run/secrets” argument to the docker run call. Note that this likely won’t work if you DO have the super secrets patch, because the mounting would get confused.