Unable to see EPEL repo on RHEL 7 clients

Latest response

Hi - hoping someone can help me with this. Recently started to use Red Hat Satellite 6.1 and I would like to make the Fedora EPEL repository available to all our RHEL 7 clients. I've followed the unverified knowledgebase article here - https://access.redhat.com/solutions/2211261

So the repo has been added and sync'd successfully but I have been unable to make it visible to any client. I've added it to my content view and then run a subscription-manager etc etc etc --force

But whenever I do the yum repolist all on the client I still only see the RHEL repos and not the EPEL one.

If I add the EPEL repo to the activation key I created and run the subscription-manager command again all I see is the EPEL repo and none of the RHEL ones!!

All our RHEL clients are VMware clients so the RHEL licenses are actually assigned to the VMware hosts - we have unlimited virtual data centre licenses if that makes any difference at all.

If anyone has any help or advice it would be appreciated as at the moment I've right out of ideas.

Thanks - Julian.


So I've found an alternative fix for this, these are the additional steps I did.

1) Follow the steps outlined in https://access.redhat.com/solutions/2211261 to add the EPEL repo to Satellite.

2) Manually synchronise the content and setup a synchronisation plan if you wish.

Now this is where I tried all sorts to add the EPEL repo to the activation key and to the library but nothing worked I could either see the EPEL repo or the RHEL repo’s from clients but never both – spent all day trying to get this to work. In the end I’ve manually added a config on a client to make this work … and it does. So then perform these steps on a production VM.

1) ssh rhel-client

2) vi /etc/yum.repos.d/epel.repo


name=EPEL for RHEL 7 $releasever - $basearch



3) vi epel-gpg-key.txt + add the contents from here https://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-7Server

4) rpm --import ./epel-gpg-key.txt

5) yum install nagios-plugins-nrpe.x86_64 nrpe.x86_64 nagios-plugins-all.x86_64 etc. etc. etc.

And that was it, thanks, hope this helps someone.


A couple of things. Updating an activation-key does not update any running hosts retroactively. Activation Keys only apply at registration time.

Let's take this from the beginning, and I'll add some context. The KCS you linked KCS2211261 does correctly cover how to synchronize a non-Red Hat repository source, such as EPEL.

To get a client to use non-Red Hat content, you have to perform two steps:

  • Synchronize the content.
  • Making the content available to your clients.

Synchronize the content

  • First you create a custom Product (again, this is under Content->Products in the UI). A Product is a collection of repositories that are treated as a singular unit. This is useful for something like EPEL which consists of multiple repositories (such as those for RHEL 6 & 7 [and for each architecture]). Sync plans are tied to products, not repos, and additionally subscriptions are created (or imported in the case of Red Hat products) at the product level.
  • Next, within that product you create one or more repositories for your RPMs (or puppet modules, docker, or file content). In the case of EPEL, I would create 1 repo for each OS/Arch combo.
  • Optional, but highly recommended, associate the product with a sync plan.
  • Synchronize the content.

In doing the process as listed in the KCS, (and also, the Content Management Guide), you intrinsically created a 'subscription' for your custom content (EPEL). This subscription is used to give your clients access to your content.

You may ask: "why do I need a subscription to access non-Red Hat content?":

It allows you to accurate count which systems are using your custom content using the same tools/workflows that you used for Red Hat.

hammer --output json subscription list --organization Example
    "ID": 18,
    "UUID": "2c91809352db8ab10152db9c9c770d57",
    "Name": "Extra Packages for Enterprise Linux",
    "Contract": null,
    "Account": null,
    "Support": null,
    "Quantity": "Unlimited",
    "Consumed": 1,
    "End Date": "2046-02-05T17:10:15.000+0000",
    "Attached": 1

While the number of subscriptions is uncapped/unlimited, it is important that any system that wishes to use your custom product MUST also have your custom subscription attached. (Again see the Content Management Guide) Which brings us to problem number 2:

Making the content available to your clients

Now that we have the bits on the Satellite, We need to A) attach the aforementioned custom subscription & B) actually enable the repositories so we can actually install some bits.

Installing the subscription can be done one of three ways:

  • via an activation-key. Again, as mentioned in my opening comment, this can only be done at registration time, so if you have systems already registered, this doesn't help you. But for future systems, this works perfectly.
  • via hammer (hammer host subscription attach)
  • via the UI (via Hosts -> Content Hosts -> YOUR HOST -> Subscriptions)

Note: if you change subscriptions on a system, you might have to issue a subscription-manager refresh

and lastly, enabling the repo:

  • You can do this on your activation key (once again, only usable at registration time)
  • Add it to a content view, publish/promote & enable via subscription-manager repos.
  • via subscription-manager repos if your systems are using the Default Organization View.


  • sync the content
  • attach the subscription (I am pretty sure this is the step you missed)
  • enable the repo
  • yum install.


Non-Red Hat content is also published over HTTP (by default), which you can use a standard yum repo, which you did. This totally works too, but you lose the ability to track usage AND your lose the ability to customize the repo (via a content view and content view filter)

Thank you Rich for your very thorough and informative reply. I've been through the steps you've suggested and now applied this to the additional RHEL7 clients I wanted to have access to the EPEL repo.

Thanks again, Julian.

I ran into this problem and sure enough the issue was subscription not attached to the host. Question is, do I have to do this to all the hosts? Manually attach a subscription to all the hosts event though the repo was already added in the Content View?