あらためてEPELリポジトリの使い方をまとめてみた
1. はじめに
RHEL系ディストリビューションにおける、拡張パッケージのリポジトリ「EPEL」を使っている人は多いだろう。筆者もこれまでの記事で何度か紹介してきた。ところがクラウドでは状況が微妙に異なる。そこで使い方をまとめることにした。
1-1. TL;DR
- クラウドでは、デフォルトで有効になっていることや、独自のインストールコマンドが提供されていることがある
- 記事で毎回EPELの使い方を説明するのは無駄
1-2. 前提条件
2. EPELとは
EPELを使う手順は簡単だ。すぐにインストールしたいときは「3. EPELリポジトリを有効にする」に進んでほしい。ここでは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. ソースからインストールする？
これらの問題が起きたときソースからビルドする人もいるだろう。ソースコードからのインストールは否定しないが、パッケージ管理ステムのメリットが損なわれる。十分な理由のあるときだけに限ったほうがいいだろう。
ソースからビルドしたときのデメリット
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 |
| Amazon Linux 2 | 4.14 | 2.26 |
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では
codeready-builderリポジトリを有効にする必要がある - AWSのAmazon Linux 2ではEPELを有効にする専用のコマンドがある
- Oracle Cloud InfrastructureのOracle Linux 7では、専用のEPELリポジトリがデフォルトで有効になっている
3-1. EPELを有効にする（基本）
「クラウドでRHELやCentOSを使うとき」や「オンプレミス環境」ではepel-releaseをインストールする。これが基本になる。
8系Linux OS
sudo yum 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
3-2. EPELを有効にする（AWS）
Amazon Linux 2ではEPELを有効にする専用のコマンドが用意されている。AWSでもRHELやCentOSでは、前述の方法を利用する。
sudo 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-2. EPELを有効にする（Oracle Cloud Infrastructure）
Oracle Cloud InfrastructureのOracle Linux 7では「ol7_developer_EPEL」という専用のEPELリポジトリが用意してある。そのため追加作業は不要だが、他のOSでは前述の方法を利用する。
EPELリポジトリが有効になっているか、次のコマンドで確認するといいだろう。
$ yum repolist repo id repo name status ol7_UEKR5/x86_64 Latest Unbreakable Enterprise Kernel Rele 217 ol7_addons/x86_64 Oracle Linux 7Server Add ons (x86_64) 433 ol7_developer/x86_64 Oracle Linux 7Server Development Packages 1349 ol7_developer_EPEL/x86_64★これ Oracle Linux 7Server Development Packages 32336 ol7_ksplice Ksplice for Oracle Linux 7Server (x86_64) 7356 ol7_latest/x86_64 Oracle Linux 7Server Latest (x86_64) 18986 ol7_oci_included/x86_64 Oracle Software for OCI users on Oracle L 321 ol7_optional_latest/x86_64 Oracle Linux 7Server Optional Latest (x86 13984 ol7_software_collections/x86_64 Software Collection Library release 3.0 p 14564 repolist: 89546
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/
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に切り替えてみよう。
4. さらなるEPELの使いこなし
4-1. EPELの有効化／無効化を切り替える
EPELに限らず追加のリポジトリを使用するときは、「常時有効にする」「一時的に有効にする」の二通りの方法がある。EPELを使い始めたら常時有効にするのが一般的だが、EPELのパッケージを明示的に区別したいときは「一時的に有効にする」ことで区別できる。
常時有効にする
yum repolistで表示されるときは有効になっている。またrepoファイルはenabled=1になっている。
一時的に有効にする この方法ではEPELを無効化しておき、必要なときだけ有効化する。
- EPELを無効化する。これでyumを実行してもEPELのパッケージは利用できない。
sudo yum-config-manager --disable epel
2.EPELにあるパッケージをインストール／アップデートするときだけ--enablerepoオプションで有効化する。
sudo yum --enablerepo=epel install ＜パッケージ名＞
4-2. トラブルシュート
余力のあるとき執筆予定
