EPEL repository on rhel 7.4

Latest response

Can not activate EPEL repository. How can we do it

Responses

Hi Lalan, to activate the EPEL repository on RHEL 7.4 open a terminal and execute the following commands :
sudo rpm -ivh https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm
sudo yum update

Cheers :)
Christian

Confirmed working on RHEL 7.5

I confirm too; it works with RHEL 7.5

Confirmed working on RHEL 7.6

Thank you Christian for this quick and easy solution. Should be marked as best response.

Best regards,
Joerg

You're welcome, Jörg ! I'm glad that you find the instruction to be useful ! :)

Regards,
Christian

Thank for the reply. I tried with the same command previously too. But I can,t see the EPEL repository in the yum.repos.d. I can see only the redhat.repo [root@lalanrh yum.repos.d]# ls redhat.repo [root@lalanrh yum.repos.d]#

When I try to install "Transmission" I couldn't do also. The error I got is "Detailed errors from the package manager follow: installing not available" How can I solve this. Thank you you again for your response. LF

Alternatively you can add the EPEL repository manually ... to do this, first import the EPEL gpg key.
Execute : sudo rpm --import http://dl.fedoraproject.org/pub/epel/RPM-GPG-KEY-EPEL-7

Now add the epel repository - execute : sudo nano /etc/yum.repos.d/epel.repo

Copy the following text and paste it into the empty file :

[epel]
name=Extra Packages for Enterprise Linux 7 - $basearch

baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch

metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch
failovermethod=priority
enabled=1
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7

[epel-debuginfo]
name=Extra Packages for Enterprise Linux 7 - $basearch - Debug

baseurl=http://download.fedoraproject.org/pub/epel/7/$basearch/debug

metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-debug-7&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1

[epel-source]
name=Extra Packages for Enterprise Linux 7 - $basearch - Source

baseurl=http://download.fedoraproject.org/pub/epel/7/SRPMS

metalink=https://mirrors.fedoraproject.org/metalink?repo=epel-source-7&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1

Press Ctrl + X to close the file, then press Y and Enter to save the changes.

Now add the epel-testing repository - execute : sudo nano /etc/yum.repos.d/epel-testing.repo

Copy the following text and paste it into the empty file :

[epel-testing]
name=Extra Packages for Enterprise Linux 7 - Testing - $basearch

baseurl=http://download.fedoraproject.org/pub/epel/testing/7/$basearch

metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-epel7&arch=$basearch
failovermethod=priority
enabled=0
gpgcheck=1
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7

[epel-testing-debuginfo]
name=Extra Packages for Enterprise Linux 7 - Testing - $basearch - Debug

baseurl=http://download.fedoraproject.org/pub/epel/testing/7/$basearch/debug

metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-debug-epel7&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1

[epel-testing-source]
name=Extra Packages for Enterprise Linux 7 - Testing - $basearch - Source

baseurl=http://download.fedoraproject.org/pub/epel/testing/7/SRPMS

metalink=https://mirrors.fedoraproject.org/metalink?repo=testing-source-epel7&arch=$basearch
failovermethod=priority
enabled=0
gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
gpgcheck=1

Press Ctrl + X to close the file, then press Y and Enter to save the changes.

Update the software sources in order to install packages from the EPEL repository : sudo yum update
Transmission is available in the EPEL repo, so to install it, execute : sudo yum install transmission

Regards,
Christian

Can any please tell me why in default configuration baseurl line are commented out.

baseurl=http://download.fedoraproject.org/pub/epel/testing/7/$basearch baseurl=http://download.fedoraproject.org/pub/epel/testing/7/$basearch/debug baseurl=http://download.fedoraproject.org/pub/epel/testing/7/SRPMS

and working with Server hardware using direct internet connection via public ip (using paid subscription on server hardware) And not working for me using proxy internet connection (using developer subscription on Laptop). I have to use "baseurl" lines. It is working fine for me.

What I've posted above is the default configuration and as you can see, nothing is commented out.

Regards,
Christian

I got installed and activated epel repository but when try to run yum update gave a following error. What will be the reason

[root@localhost yum.repos.d]# yum update Loaded plugins: langpacks, product-id, search-disabled-repos, subscription- : manager epel/x86_64/metalink | 5.7 kB 00:00
epel | 4.3 kB 00:00
(1/3): epel/x86_64/updateinfo | 807 kB 00:11
(2/3): epel/x86_64/group_gz | 170 kB 00:13
(3/3): epel/x86_64/primary_db | 4.8 MB 00:48
Resolving Dependencies --> Running transaction check ---> Package http-parser.x86_64 0:2.7.1-1.el7 will be updated ---> Package http-parser.x86_64 0:2.7.1-3.el7 will be an update ---> Package libgpod.x86_64 0:0.8.2-12.el7 will be updated ---> Package libgpod.x86_64 0:0.8.3-14.el7 will be an update --> Processing Dependency: libusbmuxd.so.2()(64bit) for package: libgpod-0.8.3-14.el7.x86_64 --> Processing Dependency: libplist.so.1()(64bit) for package: libgpod-0.8.3-14.el7.x86_64 --> Processing Dependency: libimobiledevice.so.4()(64bit) for package: libgpod-0.8.3-14.el7.x86_64 --> Finished Dependency Resolution Error: Package: libgpod-0.8.3-14.el7.x86_64 (epel) Requires: libplist.so.1()(64bit) Available: libplist-1.10-4.el7.x86_64 (rhel-7-desktop-rpms) libplist.so.1()(64bit) Installed: libplist-1.12-3.el7.x86_64 (@anaconda/7.4) ~libplist.so.3()(64bit) Error: Package: libgpod-0.8.3-14.el7.x86_64 (epel) Requires: libusbmuxd.so.2()(64bit) Available: usbmuxd-1.0.8-11.el7.x86_64 (rhel-7-desktop-rpms) libusbmuxd.so.2()(64bit) Installed: usbmuxd-1.1.0-1.el7.x86_64 (@anaconda/7.4) Not found Error: Package: libgpod-0.8.3-14.el7.x86_64 (epel) Requires: libimobiledevice.so.4()(64bit) Available: libimobiledevice-1.1.5-6.el7.x86_64 (rhel-7-desktop-rpms) libimobiledevice.so.4()(64bit) Installed: libimobiledevice-1.2.0-1.el7.x86_64 (@anaconda/7.4) ~libimobiledevice.so.6()(64bit)

yum can be configured to try to resolve such errors by temporarily enabling disabled repos and searching for missing dependencies. To enable this functionality please set 'notify_only=0' in /etc/yum/pluginconf.d/search-disabled-repos.conf

Error: Package: libgpod-0.8.3-14.el7.x86_64 (epel) Requires: libplist.so.1()(64bit) Available: libplist-1.10-4.el7.x86_64 (rhel-7-desktop-rpms) libplist.so.1()(64bit) Installed: libplist-1.12-3.el7.x86_64 (@anaconda/7.4) ~libplist.so.3()(64bit) Error: Package: libgpod-0.8.3-14.el7.x86_64 (epel) Requires: libusbmuxd.so.2()(64bit) Available: usbmuxd-1.0.8-11.el7.x86_64 (rhel-7-desktop-rpms) libusbmuxd.so.2()(64bit) Installed: usbmuxd-1.1.0-1.el7.x86_64 (@anaconda/7.4) Not found Error: Package: libgpod-0.8.3-14.el7.x86_64 (epel) Requires: libimobiledevice.so.4()(64bit) Available: libimobiledevice-1.1.5-6.el7.x86_64 (rhel-7-desktop-rpms) libimobiledevice.so.4()(64bit) Installed: libimobiledevice-1.2.0-1.el7.x86_64 (@anaconda/7.4) ~libimobiledevice.so.6()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest [root@localhost yum.repos.d]#

Did you disable the RHEL repositories ? I can't see them ... It seems that there are packages in the EPEL repository which would be an 'update' to the installed RHEL ones, but would need other packages as dependency that are not available - and the available ones are not compatible, hence the yum update error message you are receiving here.

Regards,
Christian

Can I disable the rhel-7-desktop-rpms and see. Please let me know the reason for this error

This would completely make no sense : you won't get updates for the system any longer ... so please don't do that !

Regards,
Christian

I enable all URLs of epel amd epel-testing repo, but the same error.

Maybe you messed up something in your earlier attempts. I have tested it on two RHEL 7.4 Server installations and everything works as expected : I added the EPEL repository ... sudo yum update runs without any error messages.
Clean up yum, execute : sudo yum clean all, then sudo rm -rf /var/cache/yum and then sudo yum update

Regards,
Christian

I removed both repositories [root@localhost yum.repos.d]# rm epel.repo rm: remove regular file ‘epel.repo’? y [root@localhost yum.repos.d]# rm epel-testing.repo rm: remove regular file ‘epel-testing.repo’? y now the yum update is working smoothly

The reason for receiving the error messages most probably is that you try to install packages from the EPEL repo which have dependency issues. In other words this means that they are (currently) not compatible with packages that are installed on the RHEL 7.4 system. Reminder : please do not forget to have the basic RHEL repos enabled.

Regards,
Christian

Though I can install EPEL repo, when I run the yum update I get the following error [root@lalanrhl /]# yum update Loaded plugins: langpacks, product-id, search-disabled-repos, subscription- : manager epel/x86_64/metalink | 5.0 kB 00:00
epel | 4.3 kB 00:00
(1/3): epel/x86_64/updateinfo | 809 kB 00:13
(2/3): epel/x86_64/group_gz | 170 kB 00:16
(3/3): epel/x86_64/primary_db | 4.8 MB 02:05
Resolving Dependencies --> Running transaction check ---> Package http-parser.x86_64 0:2.7.1-1.el7 will be updated ---> Package http-parser.x86_64 0:2.7.1-3.el7 will be an update ---> Package libgpod.x86_64 0:0.8.2-12.el7 will be updated ---> Package libgpod.x86_64 0:0.8.3-14.el7 will be an update --> Processing Dependency: libusbmuxd.so.2()(64bit) for package: libgpod-0.8.3-14.el7.x86_64 --> Processing Dependency: libplist.so.1()(64bit) for package: libgpod-0.8.3-14.el7.x86_64 --> Processing Dependency: libimobiledevice.so.4()(64bit) for package: libgpod-0.8.3-14.el7.x86_64 --> Finished Dependency Resolution Error: Package: libgpod-0.8.3-14.el7.x86_64 (epel) Requires: libplist.so.1()(64bit) Available: libplist-1.10-4.el7.x86_64 (rhel-7-desktop-rpms) libplist.so.1()(64bit) Installed: libplist-1.12-3.el7.x86_64 (@anaconda/7.4) ~libplist.so.3()(64bit) Error: Package: libgpod-0.8.3-14.el7.x86_64 (epel) Requires: libusbmuxd.so.2()(64bit) Available: usbmuxd-1.0.8-11.el7.x86_64 (rhel-7-desktop-rpms) libusbmuxd.so.2()(64bit) Installed: usbmuxd-1.1.0-1.el7.x86_64 (@anaconda/7.4) Not found Error: Package: libgpod-0.8.3-14.el7.x86_64 (epel) Requires: libimobiledevice.so.4()(64bit) Available: libimobiledevice-1.1.5-6.el7.x86_64 (rhel-7-desktop-rpms) libimobiledevice.so.4()(64bit) Installed: libimobiledevice-1.2.0-1.el7.x86_64 (@anaconda/7.4) ~libimobiledevice.so.6()(64bit)

yum can be configured to try to resolve such errors by temporarily enabling disabled repos and searching for missing dependencies. To enable this functionality please set 'notify_only=0' in /etc/yum/pluginconf.d/search-disabled-repos.conf

Error: Package: libgpod-0.8.3-14.el7.x86_64 (epel) Requires: libplist.so.1()(64bit) Available: libplist-1.10-4.el7.x86_64 (rhel-7-desktop-rpms) libplist.so.1()(64bit) Installed: libplist-1.12-3.el7.x86_64 (@anaconda/7.4) ~libplist.so.3()(64bit) Error: Package: libgpod-0.8.3-14.el7.x86_64 (epel) Requires: libusbmuxd.so.2()(64bit) Available: usbmuxd-1.0.8-11.el7.x86_64 (rhel-7-desktop-rpms) libusbmuxd.so.2()(64bit) Installed: usbmuxd-1.1.0-1.el7.x86_64 (@anaconda/7.4) Not found Error: Package: libgpod-0.8.3-14.el7.x86_64 (epel) Requires: libimobiledevice.so.4()(64bit) Available: libimobiledevice-1.1.5-6.el7.x86_64 (rhel-7-desktop-rpms) libimobiledevice.so.4()(64bit) Installed: libimobiledevice-1.2.0-1.el7.x86_64 (@anaconda/7.4) ~libimobiledevice.so.6()(64bit) You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest I tried to fix it even after installing a fresh copy of 7.4 system. Still it didn't work and gave the same result. I agree with your final comment "In other words this means that they are (currently) not compatible with packages that are installed on the RHEL 7.4 system". We will wait and see till they fix the bug. Thank you Lalan I thin that your

Well, I don't think that this can considered to be a bug ... I think it is more or less a matter of configuration generally.

Regards,
Christian

I wanted to get the package "transmission" installed via EPEL. though there is this error wit yum update, the package can be downloaded and it is working perfectly.

When you use the --skip-broken option and there are no dependency problems for that very special Transmission package or when you temporarily deactivate the other repos, then of course you can download and install it properly.

Regards,
Christian

I don't enable testing channel of EPEL repo. It worked fine for me. Please temporary enable all RHEL repo to overcome dependency error.

This is a good idea ... the EPEL testing channel is disabled by default and you should only enable it temporarily when there is a problem with a package from the stable channel and the newer package from the testing channel solves it.

Regards,
Christian

I got the problem fixed. epel-testing.repo is disable deftly. It should be enabled. Then the error message want get. Thanks for the concern and helping me out. regards.

You're welcome Lalan,

We're glad when we can help.

Cheers :)
Christian

If you have proxy, you must edit "/etc/yum.conf" and add: proxy=http://: proxy_username= proxy_password=

I was reading the post, and I ran into the same issue as Lalan Fernando. I have added the repo with the file system, but I can not enable it. When I type the command, Subscription-manager repos -enable epel-testing.repo, I get an error message. Subscription-manager repos -enable epel-testing.repo. I get an error epel-testing.rep does not match a valid repository ID. Use “ subscription-manager repos –list” to see valid repositories. When, I do this I see the repo their, but can not enable it. May someone please help me. Thankyou.

Hi Abdel,

This is normal and expected, because EPEL is a 3rd party repository, that cannot be managed with the subscription-manager tool. You can enable or disable a EPEL repository with sudo nano /etc/yum.repos.d/epel.repo. Just change enabled=1 to enabled=0 to disable or enabled=0 to enabled=1 to enable a specific EPEL repository.

Regards,
Christian

Christian,

That is not working. I get this error. Cannot retrieve metalink for repository: epel-source/x86_64. Please verify its path and try again.

Hi Abdel, please make sure that you have the extras-rpms and the optional-rpms repositories enabled :

sudo subscription-manager repos --enable rhel-7-server-extras-rpms
sudo subscription-manager repos --enable rhel-7-server-optional-rpms

Clean yum and yum cache : sudo yum clean all | sudo rm -rf /var/cache/yum | sudo yum update

If it doesn't solve your problem, remove and reinstall the EPEL repo and check the entries as described above.

Regards,
Christian

Thank you Christian a lot - Following steps solved my issue

sudo subscription-manager repos --enable rhel-7-server-extras-rpms sudo subscription-manager repos --enable rhel-7-server-optional-rpms

Clean yum and yum cache : sudo yum clean all | sudo rm -rf /var/cache/yum | sudo yum update

Hi Bangaly,

You're welcome ! :) Yes, having these two repositories enabled is the (known) precondition for making use of EPEL :

NOTE for RHEL 7 users with certificate subscriptions
EPEL 7 packages assume that the 'optional' repository (rhel-7-server-optional-rpms for servers) and the 'extras' repository (rhel-7-server-extras-rpms for servers) are enabled.  

Regards,
Christian

If we do not have internet on the server and if we do not have active subscription then how can we install and configure epel Suppose my desktop is windows and I’ll connect to the server through putty and my servers are in private network. Is there any possible way that we can download all epel rpms and do some kind of local repo config?

Hi Kiran,

You don't have an active subscription ? Well, then you don't get updates for your system anymore. So, the first thing should be to attach a valid subscription. Of course you can download packages from the EPEL repo and install them manually, but expect to run into (dependency) issues. :)

Regards,
Christian

My company firewall doesn't allow my server to talk dl.fedoraproject.org I can get all updates from RedHat. Is there a work around ? regards, Hau

Hi Hau, a correct and legal workaround ? No - if you want to use the repo, ask your system admin to allow access. :)

Regards,
Christan

Greetings everyone...

Some thoughts and perspective (hopefully) here...

So EPEL has mirrors that you can download the entire set of rpms for a given architecture centos 6 & 7 rhel 6 & 7, but here's some important info to know.

It will probably come as no surprise that EPEL is proved as-is, with no warranty by Red Hat (see the EPEL page, it's description). So EPEL marches on with disregard if people happen to chain themselves to a non-supported edition of either RedHat Linux or Centos Linux.

What does that mean? Glad you asked. So since the developers supporting EPEL march on and update EPEL routinely, the packages there may, or may not actually work with non-supported editions of Red Hat (oh, like RHEL 7.4). So if you have the expectation of using RHEL 7.4 with a current edition of EPEL, you may face unsupported and unexpected results of dependency issue.

What can be done? I'm glad you asked. So press the vendor you have a 3rd-party software that chains you to to some non-supported (or non-current) edition of Red Hat Linux to make their product work with a supported edition of Red Hat. As I type this today on January 24th 2019, the current Red Hat and CentOS release is at 7.6. So the expectation of all of EPEL working with an older (and even older) edition of RHEL or CentOS becomes increasingly frustrating or non-realistic as time marches on.

So if you are running RHEL 7.4 and are attempting to use a current edition of EPEL, you will increasingly run the risk of having rpms in EPEL that just may or may not work in RHEL non-current 7.4 (we are on 7.6 as I type this as mentioned before).

Now back to CentOS Mirrors. Let's say you are encountering difficulty using the primary EPEL repository across the Internet. Perhaps you are behind a corporate firewall. Perhaps there is some other [fill in the blank] reason you can not access EPEL through the internet. You have the option of going to a system that can reach the internet successfully and use wget or some other means to acquire all at once all of the 15GB of EPEL rpms and then presenting it to your systems you wish to have EPEL. The list of mirrors is at this location https://fedoraproject.org/wiki/Mirrors you can download the entire set of rpms, it's a lot, so make sure to acquire the entire set during one download session. You can then take the entire set of rpms you did the time/research to produce a method to do so (I've seen people use even a windows powershell because they are forced to use windows kicking & screaming), I've seen others use rsync or a nicely done wget command with the proper set of arguments. IMPORTANT - when you go to acquire EPEL, grab the whole set of 15GB of rpms at one go, since it is 15 GB total, the hope or expectation of downloading the rpm set for EPEL one by one through a web interface would "not be optimal". After acquiring it, make sure to do the usual "createrepo" command to the directory of rpms you acquired. You can then present it to your systems through an http server, nfs server centrally to the collection of systems you have perhaps behind a corporate firewall. Or if it is just one system, you can put it on a partition on that system that can take the pressure of a 15GB footprint without filling a partition to 100%.

edited for some additional factors

Just some thoughts

Regards

RJ

Hi RJ ! :)

Thank you very much for your (as usual) extremely useful input. Great aspects and thoughts - especially this one :
"So if you have the expectation of using RHEL 7.4 with a current edition of EPEL, you may face unsupported and unexpected results of dependency issue." Cannot agree more and, as we both have advised many members of our community very often : It is definitely recommend to always run the latest stable RHEL edition. It also should be
a known fact that installing software from external sources implements the risk of running into possible issues ...

Regards,
Christian

Gladly, thanks Christian

Hope all is well with you...

added

Unfortunately for those chained to an older release of RHEL, EPEL runs the risk of not playing well because it expects more current RPMs based on continuing development with a current RPM base. I know some are "chained" to an older release because they are heavily invested in some 3rd party software that is either reluctant or slow to respond to continuing updates/upgrades particularly with minor release updates with Red Hat. Some of these vendors will tell their customers that they will not support them if they upgrade their server past a specific release. This causes other issues.

I know of [not naming them here] one decently sized company that would not update their software to work with the latest kernel, and for over 10 months (I think close to a year) and namely with continually updating kernels. This was with a paid and supported product. This caused severe issues with the customer using this software to the point the customer highly considered dumping that 3rd party vendor because they would not update their software to work a newer kernel for nearly a year. The vendor (after much pressure from the customer pointing to the pricy paid receipt) finally did make an upgrade to allow the customer to go to a supported kernel.

Vendors ought to capitulate to reason and update their software to work with current versions of RHEL because it causes issues to the customer. Of course this is much easier said than done. Who bears the weight of issues for this? Generally it is the customers, and the developers, admins who support the OS.

end added

Regards

RJ

You're welcome, RJ ! :) Yes, all is fine ... Hope the same is valid for you.

Regards,
Christian

Which firewall ports / destination addresses to fedora need to be open to access the epel repositories as above?

Hi Rob,

"Firewall ports to fedora" ? Not sure what you mean, but there is nothing special to configure to access the
EPEL repository. The default firewall settings in CentOS / fedora / RHEL systems allow it out-of-the-box. :)

Regards,
Christian

Hi,
I think what Rob means is how to access the epel when you are in a subnet with restricted internet access. Where for example the outgoing traffic is limited due to security policy.

@Rob: I do not know if there exists any list naming the servers that are serving epel. But it would be a mess to maintain a firewall ruleset because the hosts serving epel could change over time.

How many hosts should access epel? If there are more than just a handful you might wanna think about bildung a local mirror. Then only one host needs internet access and all the others could use the server in your LAN.

Best regards,
Joerg

Rob, you might have to use something to grab all of epel and present it locally. We do this for various customers as required.

Regards

RJ

Excuse me for my incomplete question. I do have a local repository server, that syncs with some Red Hat repositories and makes them available in our network. That is an enterprise server in the DMZ. Now I would add the Epel repositories, so that I can sync them too to this local server. That is why I asked which firewall/proxy ports and destinations I need to open.

Confirmed working on RHEL 7.4

Anyone landing here please bear in mind this specific discussion was started back in 2017. That said, many are still reporting EPEL working to some degree with non-supported versions of Red Hat. Know that EPEL itself is provided free by Red Hat, but without any support. There is no guarantee that a current-day (Oct 2019 as I type this) will work with some older version of RHEL. If it does, great, if it doesn't, know you really ought to use a current-supported version of RHEL (as I type this, RHEL 7.7 and 6.10 and 8.0 are supported and current as of October 2019).

By the time you read this months, perhaps years later, be aware that it is a best practice to use a current version of Red Hat/CentOS etc, regardless if you use EPEL.

Regards

RJ

Thank you, RJ ... and once again I completely agree with you ! :)

Regards,
Christian