1. はじめに
RHEL系ディストリビューションにおける、拡張パッケージのリポジトリ 「EPEL」 を使っている人は多いだろう。筆者もこれまでの記事で何度か紹介してきた。ところがクラウドでは状況が微妙に異なる。そこで使い方をまとめることにした。
1-1. モチベーション（記事の目的）
- クラウドでは、デフォルトで有効になっていることや、独自のインストールコマンドが提供されていることがある
- 記事で毎回EPELの使い方を説明するのは無駄
1-2. 前提条件
- RHEL系Linuxディストリビューション。AlmaLinuxやRocky Linux、CentOS、CentOS stream、Amazon Linux、Oracle Linuxなど
2. EPELとは
EPELの概要や使用するうえでの注意事項を説明する。すぐにインストールしたいときは「3. EPELリポジトリを有効にする」に進んでほしい。
2-1. もっとも有名なサードパーティー・リポジトリEPEL
EPEL（Extra Packages for Enterprise Linux）は、Fedoraプロジェクトの有志がビルドした、Red Hat Enterprise Linux (RHEL) 系Linuxディストリビューション向けオプションパッケージ群だ。LinuxのメディアやYumリポジトリに含まれないパッケージ入手先の第１候補になる。
EPELのように、ディストリビューション本家以外が提供するリポジトリを「サードパーティー・リポジトリ」と呼ぶ。EPEL以外にも、以下のリポジトリも有名である。
2-2. なぜサードパーティー・リポジトリが必要か？
理由は簡単で「使いたいアプリケーションが標準のYumリポジトリに含まれていない」もしくは「含まれていてもバージョンが古い」からだ。これはディストリビューションのサポート上の理由だ。
- ディストリビューションベンダーは製品をサポートする責任があるので、標準リポジトリに含めるパッケージを制限している
- 互換性の問題で、同一メジャーバージョン内で新しいバージョンを取り入れられない
これらの問題は、RHEL7までのSoftware Collections（SCL）や、RHEL8から導入されたAppStreamで改善するが、すべての問題が解決するわけではない。
2-2-1. ソースからインストールする？
これらの問題が起きたときソースからビルドする人もいるだろう。ソースコードからのインストールは否定しないが、パッケージ管理ステムのメリットが損なわれる。十分な理由のあるときだけに限ったほうがいいだろう。
ソースからビルドしたときのデメリット
- 依存関係を保ったシステム管理が難しくなる
- インストールしたソフトウェアの削除が困難
- ソースRPMからビルドしたバイナリRPMはサポート対象外になる
2-2-2. 互換性の話
以下の表は、RHELバージョンごとのkernelとglibcのバージョンをまとめたものだ。同一メジャーバージョン内では、アップデートパッケージを適用してもパッケージのバージョンは変わらない。
| ディストリビューション | kernel | glibc |
|---|---|---|
| RHEL6 | 2.6.32 | 2.12 |
| RHEL7 | 3.10.0 | 2.17 |
| RHEL8 | 4.18.0 | 2.28 |
| RHEL9 | 5.14.0 | 2.34 |
| Amazon Linux 2 | 4.14 | 2.26 |
| Amazon Linux 2022 | 5.15 | 2.34 |
| Amazon Linux 2023 | 6.1 | 2.34 |
RPMパッケージは以下のように命名される。kernelやglibcなどのコアコンポーネントの場合、yum updateを実行して変わるのはバージョン以降に付与したリリース番号である。
ここまでしつこく書く理由は、kernelやglibcなどのコアコンポーネントは、アプリケーションの動作保証で極めて重要だからだ。
だから出どころの分からない野良リポジトリを使ってはいけないし、RHEL6用のRPMパッケージをRHEL7にインストールするような強引なことはしてはいけない。
余談
筆者が経験したホラーストーリーがある。とある障害の支援でRHEL6の設定を確かめていたときの出来事だ。いくつかの基本コマンドが動かない。おかしいと思い、以下のコマンドでRed Hat以外のパッケージを探すと、たくさん出てきた。
rpm -qa --qf "%{name} %{vendor}\n" | grep -v "Red Hat"
驚くことにglibcなどのコアコンポーネントがFedoraやScientific Linuxになっていた。それもリリース番号違いでなくバージョン番号違い。本来インストールできないものをnodepsやforceでインストールしたようだ。そんな強引なことをしたら、正常動作しなくて当然だ。逆に動いていたことが不思議でならない。
3. EPELリポジトリを有効にする
EPELを使用するにはepel-releaseパッケージをインストールすればよい。ただし使用するクラウドサービスやLinuxディストリビューションによって注意事項がある。EPELのWebサイトも見てほしい。
- RHEL7では
optionalリポジトリやextrasリポジトリを有効にする必要がある - RHEL8/9では
codeready-builderリポジトリを有効にする必要がある - CentOS StreamやAlmaLinux、RockyLinuxではcrbリポジトリを有効にする必要がある
- AWSのAmazon Linux 2ではEPELを有効にする専用のコマンドがある
- Oracle Linuxでは専用のEPELリポジトリが用意されている
3-1. EPELリポジトリがあるか確認する
OSを新規インストールしたばかりのときは、すぐにepel-releaseパッケージをインストールして問題ない。しかし、長期間使っていたときやクラウドのときは、EPELリポジトリがインストールされていることがある。そのため事前に確認しよう。
- EPELリポジトリの設定ファイルがインストールされているか確認する。何も表示されなければインストールされていない。3-2に進もう。
yum repolist all | grep -i epel
2.次のように表示されたときにはインストールされている。
$ yum repolist all | grep -i epel
epel Extra Packages for Enterprise Linux 8 - x86_64 disabled★
3.リポジトリのstatusが「enabled」のときは使用できるので何もしなくてよい。「disabled」のときにはインストールされているけれど無効なので有効にする必要がある。
$ sudo yum-config-manager --enable epel
$ sudo yum repolist epel
repo id repo name status
epel Extra Packages for Enterprise Linux 8 - x86_64 enabled
3-2. EPELを有効にする（基本）
「クラウドでRHELやRHEL互換ディストリビューションを使うとき」や「オンプレミス環境」ではepel-releaseをインストールする。これが基本になる。
9系Linux OS
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-9.noarch.rpm -y
8系Linux OS
sudo dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm -y
7系Linux OS
sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm -y
6系Linux OS
sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm -y
ヒント
CentOS/CentOS Streamではextrasリポジトリにepel-releaseパッケージがあることが多い。そのときにはyum install epel-releaseでインストールできる。
3-3. RHEL9系
「3-2. EPELを有効にする（基本）」で説明したことが基本だが、個別のLinuxディストリビューションについても補足する。
CentOS Stream 9
dnf config-manager --set-enabled crb
dnf install epel-release epel-next-release
RHEL9
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
AlmaLinux 9, Rocky Linux 9
dnf config-manager --set-enabled crb
dnf install epel-release
3-4. RHEL8系
こちらも同様。
CentOS Stream 8
dnf config-manager --set-enabled powertools
dnf install epel-release epel-next-release
RHEL8
subscription-manager repos --enable codeready-builder-for-rhel-8-$(arch)-rpms
dnf install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm
AlmaLinux 8, Rocky Linux 8
dnf config-manager --set-enabled powertools
dnf install epel-release
3-5. EPELを有効にする（AWS）
Amazon Linux 2ではEPELを有効にする専用のコマンドが用意されている。AWSでもRHELやCentOSでは、前述の方法を利用する。
amazon-linux-extras install epel
インストールに成功すると 「amzn2extra-epel」 と 「epel」 リポジトリが追加される。
$ yum repolist enabled
repo id repo name status
amzn2-core/2/x86_64 Amazon Linux 2 core repository 19791
amzn2extra-docker/2/x86_64 Amazon Extras repo for docker 28
amzn2extra-epel/2/x86_64★ Amazon Extras repo for epel 1
epel/x86_64★ Extra Packages for Enterprise Linux 7 - x86 13141+192
repolist: 32961
amzn2extra-epelリポジトリのパッケージ数が1なのが気になる。調べてみるとepel-releaseだけが含まれていた。
repoファイルの定義を確認すると、EPELのミラーサイトを参照しており、クラウド内にAWS独自のミラーサイトがあるわけではない。ログを確認するとcloudfrontから取得している。
[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
3-6. EPELを有効にする（Oracle Linux）
Oracle Linuxでは、前記の3-4や3-5で説明した方法でもよいが、独自のEPELリポジトリを提供しているので、それらについて紹介する。
Oracle Cloud InfrastructureのOracle Linuxでは「ol7_developer_EPEL」「ol8_developer_EPEL」「ol9_developer_EPEL」という専用のEPELリポジトリが用意してある。また、オンプレミスや他クラウドのOracle Linuxでも、これらのEPELリポジトリを利用できる。
しかし、CentOSなど他のLinuxは用意されてないので前述の方法を利用する。他の注意点もあるので説明する。
2020年8月時点では、Oracle Linux 7用のol7_developer_EPELは限りなくオリジナルのEPELに近い。そのためほとんどの場合EPELの追加インストールは不要だ。
しかしOracle Linux 8用のol8_developer_EPELは収録パッケージ数が少ない。そのためEPELの代替にならない可能性がある。
3-6-1. リポジトリ情報を確認する
Oracle Linux 7
EPELリポジトリが有効になっているか次のコマンドで確認できる。Oracle Linux 7ではol7_developer_EPELリポジトリはデフォルトで有効になっている。
$ yum repolist
repo id repo name status
epel/x86_64 Extra Packages for Enterprise Linux 7 - x 13426
ol7_UEKR5/x86_64 Latest Unbreakable Enterprise Kernel Rele 250
ol7_addons/x86_64 Oracle Linux 7Server Add ons (x86_64) 449
ol7_developer/x86_64 Oracle Linux 7Server Development Packages 1429
ol7_developer_EPEL/x86_64★これ Oracle Linux 7Server Development Packages 32632
ol7_ksplice Ksplice for Oracle Linux 7Server (x86_64) 7891
ol7_latest/x86_64 Oracle Linux 7Server Latest (x86_64) 19388
ol7_oci_included/x86_64 Oracle Software for OCI users on Oracle L 430
ol7_optional_latest/x86_64 Oracle Linux 7Server Optional Latest (x86 14158
ol7_software_collections/x86_64 Software Collection Library release 3.0 p 15263
repolist: 105316
repoファイルの定義を確認すると、リージョンごとに用意したOracle独自のEPELを参照している。
[ol7_developer_EPEL]
name=Oracle Linux $releasever Development Packages ($basearch)
baseurl=http://yum$ociregion.oracle.com/repo/OracleLinux/OL7/developer_EPEL/$basearch/
Oracle Linux 8/9
Oracle Linux 8/9ではol_developer_EPELリポジトリはインストールされているが無効になっていた。利用するには有効にする必要がある。しかし、前述のとおり現時点ではEPELの代替にならない可能性がある。
$ yum repolist all | grep -i epel
ol8_developer_EPEL Oracle Linux 8 EPEL Packages for Development (x86 disabled
参考情報として紹介するが、有効にするには次のコマンドを実行する。
sudo yum-config-manager --enable ol8_developer_EPEL
3-6-2. Oracle Linux用EPELリポジトリをインストールする
EPELがdisableの状態でも参照できるときはenableにすればよい。しかし、そもそも存在しないときは定義ファイルをインストールする必要がある。手順は、次のとおりだ。
sudo yum install oracle-epel-release-el7
sudo yum install oracle-epel-release-el8
sudo yum install oracle-epel-release-el9
3-6-3. さらなる調査
ol7_developer_EPEL からインストールしたpwgenパッケージを確認すると、ビルドホスト（Build Host）やベンダ（Vendor）が 「fedora」 ではない。そのためEPELからソースパッケージを取得して再ビルドしていることが分かる。
$ rpm -qi pwgen
Name : pwgen
Version : 2.08
Release : 1.el7
★中略
Source RPM : pwgen-2.08-1.el7.src.rpm
Build Date : Tue Aug 14 22:24:07 2018
Build Host : x86-ol7-builder-01.us.oracle.com ★
Relocations : (not relocatable)
Vendor : Oracle America ★
URL : http://sf.net/projects/pwgen
Summary : Automatic password generation
★以下省略
重要
「EPELからソースパッケージを取得してビルド」という手順を踏んでいることから、EPELとol7_developer_EPELは厳密には同じバイナリではない。またバージョン等のタイムラグの可能性がある。
依存性などの原因でol7_developer_EPELにあるパッケージのインストールに失敗するときは、EPELに切り替えてみよう。
ol7_developer_EPELとol8_developer_EPELで、どれだけオリジナルのEPELに近いかパッケージ数をカウントしてみた。ol7_developer_EPELはほとんど同じパッケージ数なのに対し、ol8_developer_EPELは半分くらいしかない。
$ sudo yum --disablerepo=* --enablerepo=ol7_developer_EPEL list available | wc -l
14569
$ sudo yum --disablerepo=* --enablerepo=epel list available | wc -l
13624
$ sudo yum --disablerepo=* --enablerepo=ol8_developer_EPEL list available | wc -l
4438
$ sudo yum --disablerepo=* --enablerepo=epel list available | wc -l
6856
4. さらなるEPELの使いこなし
4-1. EPELの有効化／無効化を切り替える
EPELに限らず追加のリポジトリを使用するときは、「常時有効にする」「一時的に有効にする」の2通りの方法がある。EPELを使い始めたら常時有効にするのが一般的だが、よりセーフティーな運用を目指すときは「一時的に有効にする」こともある。
つまり通常は無効にしておき、使うときだけ有効にする方法だ。このようにすることで「EPELのパッケージを明確に区別する」「既存のリポジトリとEPELリポジトリとのコンフリクトを避ける」メリットがある。
常時有効にする
yum repolistで表示されるときは有効になっている。またrepoファイルはenabled=1になっている。
一時的に有効にする
この方法ではEPELを無効化しておき、必要なときだけ有効化する。
- EPELを無効化する。これでyum/dnfを実行してもEPELのパッケージは利用できない。
DNFを使うとき
sudo dnf config-manager --disable epel
yum-config-managerを使うとき
sudo yum-config-manager --disable epel
2.EPELにあるパッケージをインストール／アップデートするときだけ--enablerepoオプションで有効化する。
sudo yum --enablerepo=epel install ＜パッケージ名＞
4-2. トラブルシュート
余力のあるとき執筆予定
5. まとめ
- 標準リポジトリにないパッケージがあるときはEPELを探そう
- 野良リポジトリは使わないこと。使うときは人柱覚悟で
- RPMパッケージの依存性を崩すような強引なことはしないこと
- AWSではEPELを有効にする独自コマンドが提供されている
- Oracle Linuxでは独自のEPELリポジトリを利用できる