How to use Extra Packages for Enterprise Linux (EPEL)?
Environment
- Red Hat Enterprise Linux (RHEL)
Issue
- How to configure a Red Hat Enterprise Linux system to use Extra Packages for Enterprise Linux (EPEL)?
Resolution
Important Notice
- The following information has been provided by Red Hat, but is outside the scope of the posted Service Level Agreements and support procedures.
- Installing unsupported packages does not necessarily make a system unsupportable by Red Hat Global Support Services
- However, Red Hat Global Support Services will be unable to support or debug problems with packages not shipped in standard RHEL channels.
- Installing packages from EPEL is done at the user's own risk.
- The EPEL repository is a community supported repository hosted by the Fedora Community project.
- The EPEL repository is not a part of Red Hat Enterprise Linux and does not fall under Red Hat's Production Support Scope of Coverage. The repository is considered an optional repository and is not tested by Red Hat quality engineers.
Enabling EPEL
- Follow the directions on the EPEL website to install the
epel-releasepackage appropriate to the RHEL version of the system in question. - Ensure that you install the EPEL release that corresponds to the RHEL release you are running.
- EPEL X must be installed on a RHEL X system (where X is 7/8/9 .. will probably continue in this fashion)
If the installation fails with No package epel-release available., you can install the package directly from http URL, as is also described on the EPEL website.
NOTE: Please do not confuse EPEL with the new Extras channel/repository in RHEL 7.
References
This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.
16 Comments
This article should be updated to use yum instead of rpm for the installation command. Using rpm causes the next yum command to gripe thusly:
Warning: RPMDB altered outside of yum.
http://fedoraproject.org/wiki/EPEL#How_can_I_use_these_extra_packages.3F
This site can’t be reached
fedoraproject.org’s server DNS address could not be found. Search Google for fedoraproject org wiki EPEL ERR_NAME_NOT_RESOLVED
Loaded plugins: langpacks, product-id, search-disabled-repos, subscription- : manager rhel-7-desktop-extras-rpms | 3.8 kB 00:00
rhel-7-desktop-optional-rpms | 3.5 kB 00:00
rhel-7-desktop-rpms | 3.5 kB 00:00
(1/6): rhel-7-desktop-extras-rpms/x86_64/group | 104 B 00:01
(2/6): rhel-7-desktop-extras-rpms/x86_64/primary_db | 8.9 kB 00:00
(3/6): rhel-7-desktop-extras-rpms/x86_64/updateinfo | 4.5 kB 00:02
(4/6): rhel-7-desktop-optional-rpms/7Client/x86_64/group | 1.6 kB 00:01
(5/6): rhel-7-desktop-optional-rpms/7Client/x86_64/updatei | 2.2 MB 00:02
(6/6): rhel-7-desktop-optional-rpms/7Client/x86_64/primary | 9.0 MB 00:06
No package ntfs-3g available. Error: Nothing to do
unable to mount HPFS/NTFS/exFA on rhel 7
Until late 2018, Microsoft did not share it's IP with Linux. So at that time, things like ntfs-3g wouldn't be available in various 'indemnified' distributions (a real issue for users in countries like German, the UK, the US, et al.).
However, ntfs-3g is now build in EPEL since the change in IP stance. Here is the Fedora Project Koji page, including the EPEL builds for RHEL (.elX) ... - https://koji.fedoraproject.org/koji/packageinfo?packageID=2654
Couldn't figure out how to enable extra packages so I can install nedit. The article just gives links to other pages that don't explain exactly how to enable extras for RH 6.
See the Wiki page link in the document, https://fedoraproject.org/wiki/EPEL, just above the "How can I use these extra packages?" is the quick start which includes the yum install syntax for 6, 7, and 8 that will install the 'epel-release' package reference in the first line of "How can I use these extra packages?" ; "EPEL has an 'epel-release' package that includes gpg keys for package signing and repository information. Installing this package for your Enterprise Linux version should allow you to use normal tools such as yum to install packages and their dependencies..."
The instructions for installing the appropriate 'epel-release' package is in the quick start section of the wiki.
These solutions only work if you have an internet connected system with access to a repor. Installs of xdrp and tigervnc-server fail because yum cannot reach metadata for epel. Corrective actions REALLY need to take the isolated network owner into consideration.
You can download and install the epel-release package.
$ wget https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm; $ sudo yum install epel-release-latest-7.noarch.rpm
Dear Red Hat, please include the correct material to cover RHEL 8 for this solution.
Perhaps this...
Thanks much!
RJ
As per https://docs.fedoraproject.org/en-US/epel/#_el9
subscription-manager repos --enable codeready-builder-for-rhel-9-$(arch)-rpms
dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm
was what I did to get it working
Hi everyone,
I ran the same above commands and for the first command :
As for the second command, I got the following message :
I wonder what meant "1 local certificate has been deleted" and also wonder why the public key would be missing while it is part of the installation - if I understand correctly the information shown on EPEL at the beginning of this post :
Red Hat article about installing EPEL 9.
Then, I tried to import the key for EPEL 9 with rpm, doing something similar to that :
Red Hat article on GPG key import with rpm.
This is what I tried :
Not sure what to do here - one thing I may think to mention is that the OS is configured with a FIPS level crypto-policy, (draft STIG 9 profile).
Download the EPEL RPM, and do
rpm -ivh epel-release-latest-9.noarch.rpmmanually seems work for me.Hi @Zigit Zo,
Thanks for your message and for sharing the tip!
I followed that issue also here, but that may have been caused or related to the fact that I used a draft STIG config (in my home sandbox to learn a bit :)) and the issue could be related to some secure settings in addition to the update-crypto-policies, which was changed from "FIPS" to 'DEFAULT".
And, despite changing it to DEFAULT, I couldn't use the standard install command described hereabove. Ideally, I was looking to do it in a "clean" way but as it was for personal use only, I tried the following command (that I would not use in a FIPS context...) ;
That command worked, and I then was ready to install the EPEL package of my choice. However, I first tried not to use the --nogpgcheck option, to see what would happen with the GPG key that could not be accessed at the step before.
Not really an expert with these topics so I can't really tell why but this time, the package got installed together with the key that was refused to be installed so far. As such, I didn't have to reuse the option --nogpgcheck a second time but the EPEL 9 GPG key seems now installed.
Having said that, your message pointing at using rpm helped me also in another topic, about a package that appeared impossible to reinstall and uninstall - thanks again!
I have tried unsuccessfully to get the epel.repo to work, but it is not working on my RHEL 7 Server. I continually get this error.
Cannot retrieve metalink for repository: epel/x86_64. Please verify its path and try again
The Repo File has not been modified so I have no idea on why this error is occurring. Here is the entry.
[epel] name=Extra Packages for Enterprise Linux 7 - $basearch
It is much more secure to use the metalink, but if you wish to use a local mirror place its address here. baseurl=http://download.example/pub/epel/7/$basearchmetalink=https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=$basearch&infra=$infra&content=$contentdir failovermethod=priority enabled=1 gpgcheck=1 gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-EPEL-7
You are correct that the repo file hasn't been modified. I even took what you have above and put it in my epel.repo file, and it works correctly. So, no sneaky hidden characters that I can see.
There are two things I would try.
First, completely clear your cache and try again.
If that doesn't get things working, see if you can connect to any repo. Maybe you have some type of network or firewall problem and epel is just the first in the list to fail.
Shouldn't the line that says "
It is much more secure to use the metalink, but if you wish to use a local mirror place its address here." be commented out? Not sure if it doesn't show the pound(number) symbol because the way it parses the post.baseurl set to the invalid download.exmaple domain should be commented out or changed (to debug).
If
yum clean allhas not worked try browsing the URLs. Maybe a repo is (temporarily) down.I was able to open the metalink URL substituting the $basearch variable with x86_64 https://mirrors.fedoraproject.org/metalink?repo=epel-7&arch=x86_64&infra=$infra&
The metalink file references mirror URLs https://muug.ca/mirror/fedora-epel/7/x86_64/repodata/repomd.xml What happens if you try something like baseurl=https://muug.ca/mirror/fedora-epel/7/x86_64
I have to look into what the $infra and $contentdir variables are. My epel.repo has failovermethod=priority on a separate line than metalink=