yamada-hakase’s blog

LinuxなどのOSSやクラウドについて

Red Hat Developer Programに登録して最大16台までRHELを使おう

1. CentOS騒動と、その後のRed Hatの対応

これまで以下の2つの記事で書いてきたように、CentOS終了の影響は大きく、結局RHELの無料範囲が広がることになった。

そこで今回はRed Hat Developer programに登録して、実際に16システムまで利用できるか確認してみよう。

2. Red Hat Developer Programとは

Red Hat Developer Programの詳細は以下サイトを見てほしい。

簡単に言うと、Red Hat Developerという開発者向けリソースと、一部のRed Hat製品が利用できるプログラムだ。以前から存在しているが、今回の改訂で16システムまで利用できるようになったのと、本番環境でも利用できるようになった。

利用条件の詳細は、上記「赤帽エンジニアブログ」や以下のリンクを見てほしい。1ユーザーでの利用に限られるので、複数ユーザーがログインして使うシステムでは利用できないようだ。

3. Red Hat Customer Portalで確認する

すでにRed Hat Developer Programへのユーザー登録を終えているものとして説明する。Red Hat Customer Portalではサブスクリプションの利用状況を確認できる。

  1. Red Hat Customer Portalにログインする。
    https://access.redhat.com/
  2. ページ上の[SUBSCRIPITONS]をクリックする。 rhportal01.png
  3. アクティブなサブスクリプションが「1」になっていて、ページ下のPurchased Productsに「Red Hat Developer Subscription」が表示されている。 rhportal02.png
  4. [Red Hat Developer Subscription]をクリックすると、サブスクリプションの使用状況が表示される。Availableが16となっており、16システムまで登録できることがわかる。 rhportal03.png

4. VMサブスクリプションに登録する

RHELをインストールしたVMサブスクリプションに登録する。登録することでYumリポジトリにアクセスできるだけでなく、Red Hat Customer PortalからもVMを確認できる。

今回はVirtualBoxを使用しているが、ベアメタルサーバーやCloud Accessで認められたクラウドサービスでも構わない。

前提条件

  • ISOイメージをダウンロードして、RHELをインストールしてあること
  • インストールしたRHELからインターネットにアクセスできること

ISOイメージの入手先 https://developers.redhat.com/products/rhel/download

4.1. コマンドラインで登録する

登録手順はマニュアルを参考にしてほしいが、コマンドの場合はマニュアルと手順が異なるので注意する。

# dnf repolist
Updating Subscription Management repositories.
Unable to read consumer identity

This system is not registered to Red Hat Subscription Management. You can use subscription-manager to register.

利用できるリポジトリーがありません

3.subscription-managerコマンドで登録する。文法は次のとおり。ユーザー名とパスワードはRed Hat Customer Portalのものを使用する。--nameを省略すると、ホスト名で登録される。

# subscription-manager register --username [username] --password [password] --name [SYSTEM_NAME]

登録に成功すると次のように表示される。途中にプロキシがあるときは--proxyを指定する。

# subscription-manager register --username <ユーザー名> --password <パスワード>

登録中: subscription.rhsm.redhat.com:443/subscription
このシステムは、次の ID で登録されました: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX
登録したシステム名: localhost.localdomain

4.システムのロールとサービスレベルを設定する。

# subscription-manager role --set="Red Hat Developer Subscription for Individuals"
# subscription-manager service-level --set="Self-Support"

5.サブスクリプションをアタッチする。成功すると次のように表示される。

# subscription-manager attach
インストール済み製品の現在の状態:
製品名: Red Hat Enterprise Linux for x86_64
状態:   サブスクライブ済み

6.サブスクリプションのステータスを確認する。

# subscription-manager list
+-------------------------------------------+
    インストール済み製品のステータス
+-------------------------------------------+
製品名:           Red Hat Enterprise Linux for x86_64
製品 ID:          479
バージョン:       8.3
アーキテクチャー: x86_64
状態:             サブスクライブ済み
状態の詳細:
開始:             2021年01月20日
終了:             2022年01月20日

7.再びリポジトリを確認すると、2つのリポジトリが使えるようになっている。

# dnf repolist
Updating Subscription Management repositories.
repo id                          repo の名前
rhel-8-for-x86_64-appstream-rpms Red Hat Enterprise Linux 8 for x86_64 - AppStream (RPMs)
rhel-8-for-x86_64-baseos-rpms    Red Hat Enterprise Linux 8 for x86_64 - BaseOS (RPMs)

8.アップデートできるパッケージを確認すると表示される。

# dnf check-update
★中略
sudo.x86_64               1.8.29-6.el8_3.1         rhel-8-for-x86_64-baseos-rpms
systemd.x86_64            239-41.el8_3.1           rhel-8-for-x86_64-baseos-rpms
systemd-libs.x86_64       239-41.el8_3.1           rhel-8-for-x86_64-baseos-rpms
systemd-pam.x86_64        239-41.el8_3.1           rhel-8-for-x86_64-baseos-rpms
systemd-udev.x86_64       239-41.el8_3.1           rhel-8-for-x86_64-baseos-rpms
tuned.noarch              2.14.0-3.el8_3.1         rhel-8-for-x86_64-baseos-rpms
tzdata.noarch             2021a-1.el8              rhel-8-for-x86_64-baseos-rpms

※最初に操作したときは「subscription-manager register」を実行しただけでリポジトリにアクセスできたような気がするのだが…。いろいろ操作していたら、今回の手順通りに実行しないとダメだった。

4.2. Red Hat Customer Portalで登録状況を確認する

Red Hat Customer Portalで確認すると、システムが登録されてることが分かる。次のように名前の前に緑の●印が付いていればYumリポジトリを利用できる。 rhportal04.png

概要ページを見ると、1システムが登録され、残りは15システムになっている。 rhportal05.png

4.3. トラブルシュート

登録したシステムはCustomer Portalやsubscription-managerコマンドで削除できる。subscription-managerコマンドは意外に複雑なのでmanを見てほしい。

subscription-manager unregister # システム登録削除
subscription-manager clean      # ローカルディスク上の登録情報削除

5. おわりに

いままでRed Hat Enterprise Linuxを使用したことがないユーザーにとって、サブスクリプション登録は戸惑うかもしれないが、分かってしまえば簡単だ。実際のところ「1ユーザー」という制限があるので、本格的なシステムでの利用は難しいが、完全に個人利用のシステムや、ちょっとした開発やテストでは十分使えるだろう。

今後CentOS Streamになるのか。それともRocky LinuxなどのオルナタティブCentOSになるのか。はたまたRHELOracle Linuxになるのか。今後の1,2年の動向が楽しみである。

CentOS終了に対する大ブーイングでRHELが一部無償になるらしい

CentOS終了その後

2020年12月8日のCentOS終了のアナウンスは衝撃が大きかったようで、筆者が書いた以下のエントリが好評だ。

CentOSからCentOS Streamへ。CentOS終了の衝撃

その後オルタナティブCentOSとして、Rocky Linuxなど、いくつかのRHEL互換ディストリビューションの発表が続いていた。すると2021年1月20日RED HAT BLOGに以下の記事がポストされた。

New Year, new Red Hat Enterprise Linux programs: Easier ways to access RHEL rhelfree01.png

RHELは一部無償になる?

詳しくは上記ブログを読んでほしいが、重要なところを抜き出すと以下のとおり。

  • 開発者向けのRed Hat Developer programでは、これまでも1台のマシンで無償利用できた(開発目的に限る)。
  • Red Hat Developer programの条文(Individual Developer subscription for RHEL)を拡張し、今後は最大16台のマシンを本番運用目的で利用できるようになる。2021年2月1日以降までには実施予定。
  • 新しいDeveloper programはオンプレミスだけでなく、AWSGoogle Cloud、Azureなどでも利用できる。

プログラムが正式に開始されたわけではないので、詳細は今後次第だろう。とりあえず個人ユーザーや小規模ユーザーは助かるかもしれない。

とはいえ、CentOSを大規模利用しているエンタープライズユーザーは世界でもけっこう多そうなのだけれど…。

なお、変更前のRed Hat Developer programのFAQはこちら。

CentOSからOracle Linuxへスクリプトで簡単に移行する

1. どこに移行すべきか

各所で話題になっているように、CentOS 8からCentOS 8 Streamへの変更は大きな驚きや落胆をもって迎えられている。筆者自身も驚き、すぐに以下の記事を書いたところだ。

CentOS 7は2024年6月まで猶予はあるが、CentOS 8は2021年12月31日までだ。あと1年しか猶予がない。そこで考えられるのが以下の選択肢だ。

  1. CentOS Streamに移行する
  2. RHELに移行する
  3. Oracle Linuxに移行する
  4. Ubuntuに移行する
  5. 上記以外のLinuxディストリビューションに移行する

どれにするかは、それぞれの考えで選ぶべきだろう。CentOS Streamへの移行方法は、いろいろなところで語られているので、今回は以下のメリットがあるOracle Linuxへの移行方法を解説する。

1-1. 対象環境

※ 今回使用するcentos2ol.shスクリプトCentOS 6にも対応しているが、CentOS 6はサポートが切れているので説明しない。

2. Oracle Linuxへの移行方法

移行にはいろいろな方法があり、今回は下記Oracle Linux Blogで紹介しているcentos2ol.shを使用する。

実際に手を動かす前に「Oracle Linux: A better alternative to CentOS」をサクッと眺めてほしい。また、実際の移行方法はGithuboracle/centos2olに書かれている。

https://github.com/oracle/centos2ol

なお、このスクリプトは急に注目されているので、新しいIssues/Pull requestsが上がっている。そのため今後は、本記事の内容と違いが発生するかもしれない。

移行手順
移行の実行手順は以下のとおり。1から3の事前作業では複数のコマンドを実行する必要がある。しかし、4と5の移行作業は最小限のコマンドで実行できる。

  1. 制限事項の確認
  2. システムバックアップ(本文では省略)
  3. 移行元CentOSの事前準備
  4. 移行スクリプト実行
  5. 手動で実施する移行作業

2. 制限事項の確認

このツールの制限事項を確認しよう。英文と合わせて書いているが一部内容を補足している。スクリプトと同様に更新頻度が高いので、原文をチェックすることを推奨する。

Limitations 1.The script currently needs to be able communicate with the CentOS and Oracle Linux yum repositories either directly or via a proxy.

CentOSOracle LinuxYumリポジトリに直接もしくはプロキシ経由でアクセスできる必要がある。

2.The script currently does not support instances that are registered to a third-party management tool like Spacewalk, Foreman or Uyuni.

Spacewalkのようなパッケージ集中管理ツールの管理下になっていないこと。

3.Compatibility with packages installed from third-party repositories is expected but not guaranteed. Some software doesn't like the existence of an /etc/oracle-release file, for example.

CentOSの公式リポジトリ以外からインストールしたパッケージがあるときは動作保証しない。例えば、商用パッケージなどは/etc/oracle-releaseがあると動作に支障を来すことがある。おそらくEPELやRemi、ELrepoなどは大丈夫。

4.Packages that install third-party and/or closed-source kernel modules, e.g. commercial anti-virus products, may not work after switching.

サードパーティソフトやクローズドソースのカーネルモジュールを使っていると、移行後に動作しない可能性がある。具体的には、アンチウイルスソフトのリアルタイム監視モジュールや、HWベンダが提供するデバイスドライバなどだ。これらのカーネルモジュールはリリース番号まで完全に一致しないと動作しないことが多い。

5.The script only enables the base repositories required to enable switching to Oracle Linux. Users may need to enable additional repositories to obtain updates for packages already installed (see issue #1).

centos2ol.shはCentOSのベースリポジトリだけが有効になっているシステムを対象にしている。そのためPowerToolsリポジトリRHELのCodeReady Builder相当)などを有効にしているときは、それに相当するリポジトリを有効にする必要がある。

※PowerToolsはサードパーティーリポジトリではないので有効にしたままでも問題なさそう。

3. 移行元CentOSの事前準備

事前準備では、移行スクリプトを実行する条件を整える。

なお、事前準備作業には管理者権限が必要だ。そのためコマンドの前にsudoを前につけるか、suしてrootユーザーで実行する必要がある。前者が推奨だが、見た目の簡潔さを重視してsudoを省略している。運用方法に応じて適宜読み替えてほしい。

また、CentOS 8はyumではなくdnfだが、上位互換性があるのでyumに統一する。互換性がない部分だけ別に書くことにする。

重要
本文では触れないが、万が一のトラブルに備えて必ずシステムバックアップを取得すること。

3-1. 問題があるパッケージの有無を確認する

上記の「制限事項4」に該当するパッケージがインストールされていないことを確認する。なお、RPMを使わずにソースからインストールしているときは、今回説明する方法では判断できない。そのときは構築担当者に聞いてほしい。

注意するパッケージは、CentOSリポジトリに含まれていないデバイスドライバアンチウイルスソフトなどのカーネルモジュールだ。

そこで、CentOS以外のリポジトリからインストールしているパッケージを確認する。確認には、おもに次の方法がある。それぞれについて説明する。

  • RPMのVendorに着目する
  • インストール元リポジトリ名に着目する

  • VendorがCentOS以外のパッケージを確認する。

# rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{VENDOR}\n' | grep -v "CentOS"

次の例ではEPEL(Fedora Project)からインストールしたパッケージがある。しかし、htopはユーザー空間で動作するアプリケーションなので問題ない。問題があるのはデバイスドライバなどのカーネルモジュールだ。

epel-release-8-9.el8    Fedora Project
gpg-pubkey-2f86d6a1-5cf7cefb    (none)
gpg-pubkey-8483c65d-5ccc5b19    (none)
htop-2.2.0-6.el8        Fedora Project

ただし「制限事項3」にあるように、サードパーティアプリケーションは問題になる可能性がある。

2.CentOS Plusカーネルなど、baseやupdates以外からインストールしてるカーネルがあるときは、yum removeで削除する。

# rpm -qa kernel* --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{VENDOR}\n' | grep -v "CentOS"

3.インストール元リポジトリ名に着目し、デフォルト以外のリポジトリからインストールしたものを表示する。ただし、list installedでは、パッケージ名やバージョン番号が長いと、行の途中で折り返され、問題ないパッケージも表示されることがある。基本的には1の方法を信頼してほしい。

yum list installed | grep -v @anaconda | grep -v @base | grep -v @updates | grep -v @extras
dnf list installed | grep -v @anaconda | grep -v @Base | grep -i -v @AppStream | grep -v @extras

4.次にカーネルバージョンに依存したカーネルモジュール(ドライバ類)がインストールされていないか確認する。完璧な方法はないが、今回はカーネルと同じバージョン番号がついたパッケージを調べている。

# uname -r
4.18.0-147.el8.x86_64

以下の例は、いずれもベースリポジトリからインストールしたものなので問題ない。anacondaやupdatesは、いずれもベースリポジトリだ。

# yum list installed | grep 4.18.0-147
kernel.x86_64                 4.18.0-147.el8          @anaconda
kernel-core.x86_64            4.18.0-147.el8          @anaconda
kernel-modules.x86_64         4.18.0-147.el8          @anaconda

3-2. ベースリポジトリが有効になっていることを確認する

  1. ベースリポジトリが有効になっていることを確認する。次のようにリポジトリが表示されれば有効になっている。あとで使うので、有効になっているリポジトリをメモしておくこと。
# yum repolist
repo id               repo name                             status
base/7/x86_64         CentOS-7 - Base                       10,072
extras/7/x86_64       CentOS-7 - Extras                        448
updates/7/x86_64      CentOS-7 - Updates                       778
repo id                       repo name
AppStream                     CentOS-8 - AppStream
BaseOS                        CentOS-8 - Base
extras                        CentOS-8 - Extras

ヒント CentOS 8のPowerToolsリポジトリは、Oracle Linux 8のol8_codeready_builderリポジトリに相当する。

2.次のようにrepolistからrepo idの間に、「This system is」で始まる文字が表示されたときは、Spacewalkなどのパッケージ管理システムの配下になっている。移行スクリプトは使えないので、無効にするか、スクリプトの利用を断念する。

# yum repolist
...
This system is receiving updates from Red Hat Satellite or Spacewalk server
repo id                       repo name

3.リポジトリが表示されないときは、リポジトリが無効になっているか、プロキシ等の設定が不足している可能性がある。リポジトリを有効にする方法は次のとおり。プロキシの設定は/etc/yum.confを確認してほしい。

# yum-config-manager --enable base updates extras
# dnf config-manager --enable BaseOS AppStream extras

4.CentOS以外のリポジトリが有効になっているときは無効にする。無効にしたリポジトリは移行後に有効にする。次の例ではEPELリポジトリを無効にしている。

# yum-config-manager --disable epel
# dnf config-manager --disable epel

ヒント ソースを読む限り、以下のリポジトリは有効のままでも自動的に移行してくれそうだ。しかし、十分にテストしていないので、判断はみなさんにお任せする。

CentOSバージョン リポジトリ
7 epel
base-debuginfo
centos-ceph-jewel
centos-gluster
entos-nfs-ganesha30
centos-ovirt

centos-sclo-*
8 epel
HighAvailability
PowerTools
centos-release-nfs-ganesha28
centos-gluster*

3-3. 自動アップデートを無効にする

移行作業中に自動アップデートが動作すると正常に動作しないので無効にする。CentOSの自動アップデート機能には次の2種類がある。

  • yum-cronやdnf-automaticなど
  • デスクトップ環境に組み込まれたPackagekit

デスクトップをインストールしていないときは前者だけを気にすればよい。しかし、デスクトップをインストールしているときは両方を意識する必要がある。

CentOS 7 CentOS 8
サービス yum-cron dnf-automatic
GUIデスクトップ Packagekit Packagekit

CentOS 7とCentOS 8について、それぞれ解説する。

3-3-1. yum-cronを無効にする(CentOS 7のみ)

  1. yum-cronがインストールされているか確認する。インストールされていないときは「3-2-3. Packagekitを無効にする」に進む。
# rpm -qa | grep yum-cron
★何も表示されなければインストールされていない。

2.インストールされているときは起動しているか確認する。次の例では、自動起動が有効で、サービスも起動している。

# systemctl is-enabled yum-cron
enabled ★自動起動有効

# systemctl status yum-cron
● yum-cron.service - Run automatic yum updates as a cron job
   Loaded: loaded (/usr/lib/systemd/system/yum-cron.service; enabled; vendor preset: disabled)
   Active: ★active (exited) since Tue 2020-12-15 08:38:03 GMT; 5min ago
  Process: 18679 ExecStart=/bin/touch /var/lock/subsys/yum-cron (code=exited, status=0/SUCCESS)
 Main PID: 18679 (code=exited, status=0/SUCCESS)

Dec 15 08:38:03 centos7 systemd[1]: Starting Run automatic yum updates as a.....
Dec 15 08:38:03 centos7 systemd[1]: Started Run automatic yum updates as a ...b.
Hint: Some lines were ellipsized, use -l to show in full.

3.yum-cronが起動しているときは、サービスを停止して自動起動もオフにする。

# systemctl disable yum-cron --now

3-3-2. dnf-automaticを無効にする(CentOS 8のみ)

  1. dnf-automaticがインストールされているか確認する。インストールされていないときは「3-2-3. Packagekitを無効にする」に進む。
# rpm -qa | grep dnf-automatic
★何も表示されなければインストールされていない。

2.インストールされているときはタイマーの設定を確認する。次の例では、自動ダウンロードが有効になっている。

# systemctl list-unit-files --type=timer | grep dnf-auto
dnf-automatic-download.timer   enabled ★ダウンロードのみ自動
dnf-automatic-install.timer    disabled
dnf-automatic-notifyonly.timer disabled
dnf-automatic.timer            disabled

3.enableになっているタイマーをすべて無効にする。

# systemctl disable dnf-automatic-download.timer --now

3-3-3. Packagekitを無効にする(CentOS 7/8共通)

GUIデスクトップ環境をインストールしているときは、Packagekitによるアップデートを無効化する。yum-cronやdnf-automaticは自動インストールされないが、デスクトップ環境がインストールされているときはPackagekitはデフォルトで有効化されているので注意が必要だ。

  1. packagekitのステータスを確認する。
# systemctl status packagekit
● packagekit.service - PackageKit Daemon
   Loaded: loaded (/usr/lib/systemd/system/packagekit.service; static; vendor preset: disabled)
   Active: active (running) ★起動 since Tue 2020-12-15 09:31:27 GMT; 59s ago
 Main PID: 21960 (packagekitd)
    Tasks: 3
   CGroup: /system.slice/packagekit.service
           └─21960 /usr/libexec/packagekitd

Dec 15 09:31:26 centos7 systemd[1]: Starting PackageKit Daemon...
Dec 15 09:31:27 centos7 PackageKit[21960]: daemon start
Dec 15 09:31:27 centos7 systemd[1]: Started PackageKit Daemon.
● packagekit.service - PackageKit Daemon
   Loaded: loaded (/usr/lib/systemd/system/packagekit.service; static; vendor preset: disabled)
   Active: inactive (dead) ★停止

Dec 15 09:31:26 centos7 systemd[1]: Starting PackageKit Daemon...
Dec 15 09:31:27 centos7 PackageKit[21960]: daemon start
Dec 15 09:31:27 centos7 systemd[1]: Started PackageKit Daemon.
Dec 15 09:33:36 centos7 systemd[1]: Stopping PackageKit Daemon...
Dec 15 09:33:36 centos7 systemd[1]: Stopped PackageKit Daemon.
Unit packagekit.service could not be found.

2.packagekitが起動しているときは、サービスを停止して自動起動もオフにする。

# systemctl disable packagekit --now

3-3-4.スクリプトをダウンロードする

移行スクリプトをダウンロードする方法は複数ある。いずれの場合でも、スクリプトを実行するsudoが可能なユーザーを使用すること。

A. curlを使う プロキシ環境では--proxyオプションやhttps_proxy環境変数でプロキシサーバを指定すること。

$ curl -O https://raw.githubusercontent.com/oracle/centos2ol/main/centos2ol.sh

B. gitを使う gitがインストールされていないときは、事前にyum install gitでgitをインストールする。プロキシに関してはgitも同様。

$ git clone https://github.com/oracle/centos2ol.git

C. ブラウザを使う 以下のページからダウンロードして、適正なフォルダに配置する。 github-centos2ol.png

3-3-5. 残りの準備作業

  1. Yumのキャッシュをクリアする。
# yum clean all

2./var/cacheに5GB以上の空き容量があることを確認する。空きがないときはLVMを駆使してなんとかする。

# df -h /var/cache
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        30G  1.7G   28G   6% /  ★この例では28GB空いている

4. Oracle Linuxへの移行

すべての準備が整ったのでOracle Linuxへの移行を実施する。

  1. git cloneしたディレクトリでは、centos2olディレクトリ配下にスクリプトがダウンロードされている。
$ ls -F
centos2ol/

2.centos2ol.shスクリプト本体である。

$ cd centos2ol/
$ ls
centos2ol.sh  CONTRIBUTING.md  LICENSE.txt  README.md  SECURITY.md

$ wc -l centos2ol.sh
514 centos2ol.sh ★このときは514行ある

3.移行スクリプトを実行して、CentOSOracle Linuxに切り替える。なお、実行にかかる時間は、インストールされているパッケージ数や回線速度、マシン性能に依存する。わたしが試した環境では30分から90分くらいだった。

sudo bash centos2ol.sh

4.実行が終了すると、以下の行が表示される。

Switch complete. Oracle recommends rebooting this system.

5.指示通りにシステムを再起動する。

$ sudo systemctl reboot

トラブルシュート 移行スクリプトの初期段階では、移行用repoファイル生成している。そのため途中でスクリプトが異常終了すると、repoファイルが中途半端な状態になる可能性がある。そのときは次のコマンドを実行して修復すること。

cd /etc/yum.repos.d
sudo rm switch-to-oraclelinux.repo
sudo rename repo.disabled repo *disabled

5. 移行後の作業

移行スクリプトのおもな挙動は以下のとおり。いくつか確認してみよう。

  • CentOSのパッケージはOracle Linuxのパッケージに置き換えられる
  • 置き換えでは、同じバージョンではなく最新のバージョンになる
  • UEKカーネルがデフォルトカーネルになる

5-1. 移行後の構成を確認する

  1. /etc/oracle-releaseが追加され、/etc/centos-releaseは削除されている。
$ cat /etc/oracle-release
Oracle Linux Server release 8.3

$ cat /etc/centos-release
cat: /etc/centos-release: No such file or directory

2.現在のカーネルを確認すると、Oracle Linux専用のUEK(Unbreakable Enterprise Kernel)に変更されている。UEKとRed Hat互換カーネル(RHCK:Red Hat Compatible Kernel)は、ユーザー空間で動作する通常のアプリケーションは互換性がある。

$ uname -r
5.4.17-2036.101.2.el8uek.x86_6

3.VendorがCentOSのパッケージを調べてみた。すると、現在利用していないカーネルだけが表示された。CentOS 8では、このようにほとんど置き換わったが、CentOS 7では半分くらいが置き換わらなかった。glibcやkernelではないので特に問題はないだろう。今後のスクリプトで改良されるかもしれない。

$ rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{VENDOR}\n' | grep CentOS | sort -n
kernel-4.18.0-147.el8   CentOS
kernel-4.18.0-193.14.2.el8_2    CentOS
kernel-core-4.18.0-147.el8      CentOS
kernel-core-4.18.0-193.14.2.el8_2       CentOS
kernel-modules-4.18.0-147.el8   CentOS
kernel-modules-4.18.0-193.14.2.el8_2    CentOS

4.カーネル関連パッケージとベンダを表示する。ベースリポジトリのパッケージは最新化されるので、RHCKは最新のOracle Linux版と、元のCentOS版がインストールされている。

$  rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}\t%{VENDOR}\n' | grep kernel- | sort -n
kernel-4.18.0-240.1.1.el8_3     Oracle America★最新RHCK
kernel-4.18.0-240.el8   CentOS★元のカーネル
kernel-core-4.18.0-240.1.1.el8_3        Oracle America
kernel-core-4.18.0-240.el8      CentOS
kernel-headers-4.18.0-240.1.1.el8_3     Oracle America
kernel-modules-4.18.0-240.1.1.el8_3     Oracle America
kernel-modules-4.18.0-240.el8   CentOS
kernel-tools-4.18.0-240.1.1.el8_3       Oracle America
kernel-tools-libs-4.18.0-240.1.1.el8_3  Oracle America
kernel-uek-5.4.17-2036.101.2.el8uek     Oracle America★UEK

5.有効になっているリポジトリを確認する。Oracle Linuux用に置き換わっていることが分かる。

# yum repolist
repo id           repo name                                               status
ol7_UEKR6/x86_64  Latest Unbreakable Enterprise Kernel Release 6 for Orac   204
ol7_latest/x86_64 Oracle Linux 7Server Latest (x86_64)                    21394
repolist: 21598
repo id           repo name
ol8_UEKR6         Latest Unbreakable Enterprise Kernel Release 6 for Oracle Linux 8 (x86_64)
ol8_appstream     Oracle Linux 8 Application Stream (x86_64)
ol8_baseos_latest Oracle Linux 8 BaseOS Latest (x86_64)

ヒント Oracle Cloud Infrastructureで移行スクリプトを実行したところ、クラウド用のリポジトリ構成になっていた。

6.リポジトリのrepoファイルを確認すると、CentOSのものは.disableという接尾辞が付けられ無効になっている。実際には.repo以外は無視される。

# ls /etc/yum.repos.d
CentOS-Linux-AppStream.repo.disabled
CentOS-Linux-BaseOS.repo.disabled
CentOS-Linux-ContinuousRelease.repo.disabled
CentOS-Linux-Debuginfo.repo.disabled
CentOS-Linux-Devel.repo.disabled
CentOS-Linux-Extras.repo.disabled
CentOS-Linux-FastTrack.repo.disabled
CentOS-Linux-HighAvailability.repo.disabled
CentOS-Linux-Media.repo.disabled
CentOS-Linux-Plus.repo.disabled
CentOS-Linux-PowerTools.repo.disabled
CentOS-Linux-Sources.repo.disabled
oracle-linux-ol8.repo
uek-ol8.repo

5-2. スクリプト対象外の残作業

最後に、スクリプトが実行しない残作業を実施する。

1.「3-2」のリポジトリの確認で、事前にリポジトリを無効にしたときは元に戻す。

# yum-config-manager --enable リポジトリID
# dnf config-manager --enable リポジトリID

CentOSOracle Linuxリポジトリ比較表は以下のとおり。CentOSのextrasに相当するリポジトリは無い。

CentOS 7 Oracle Linux 7
base
updates
ol7_latest
centos-ceph-jewel oracle-gluster-release-el7
centos-gluster
entos-nfs-ganesha
oracle-gluster-release-el7
centos-ovirt* oracle-ovirt-release-el7
centos-sclo-sclo
centos-sclo-rh
oracle-softwarecollection-release-el7
CentOS 8 Oracle Linux 8
BaseOS ol8_baseos_latest
AppStream ol8_appstream
HighAvailability ol8_addons
PowerTools ol8_codeready_builder
centos-release-nfs-ganesha* oracle-gluster-release-el8
centos-gluster* oracle-gluster-release-el8

2.アップデート可能なパッケージがあるか確認する。あるときはアップデートを検討する。

# yum check-update

3.デフォルトカーネルをRHCKに変更するときは、以下のエントリを参考にすること。

6. おわりに

当初の想定より大作になったが、スクリプトの前提条件を満たしたときの移行作業は簡単なことが分かっただろう。現時点では、スクリプトも十分読める範囲の長さだ。不具合があればGithubで報告してみてはどうだろう。

まとめ

  • 移行スクリプトcentos2ol.shを使うと、簡単にCentOSOracle Linuxへ変更できる。
  • 移行にかかる時間はサーバ1台当たり30分から90分程度。インストール済みパッケージ数やサーバー性能、回線速度に依存する。
  • インターネットのリポジトリに接続可能なこと(プロキシ経由OK)など、スクリプトにはいくつかの制約条件がある。
  • オンプレミスのベアメタルサーバーでデバイスドライバを追加している場合や、アンチウイルスソフトを導入しているときは、再起動に失敗する可能性があるので事前に調査する。

7. 参考資料

あらためてEPELリポジトリの使い方をまとめてみた

1. はじめに

RHELディストリビューションにおける、拡張パッケージのリポジトリ「EPEL」を使っている人は多いだろう。筆者もこれまでの記事で何度か紹介してきた。ところがクラウドでは状況が微妙に異なる。そこで使い方をまとめることにした。

1-1. モチベーション(記事の目的)

  • クラウドでは、デフォルトで有効になっていることや、独自のインストールコマンドが提供されていることがある
  • 記事で毎回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リポジトリに含まれないパッケージ入手先の第1候補になる。

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
Amazon Linux 2 4.14 2.26

RPMパッケージは以下のように命名される。kernelやglibcなどのコアコンポーネントの場合、yum updateを実行して変わるのはバージョン以降に付与したリリース番号である。 rpm-version.PNG ここまでしつこく書く理由は、kernelやglibcなどのコアコンポーネントは、アプリケーションの動作保証で極めて重要だからだ。

だから出どころの分からない野良リポジトリを使ってはいけないし、RHEL6用のRPMパッケージをRHEL7にインストールするような強引なことはしてはいけない。

余談
筆者が経験したホラーストーリーがある。とある障害の支援でRHEL6の設定を確かめていたときの出来事だ。いくつかの基本コマンドが動かない。おかしいと思い、以下のコマンドでRed Hat以外のパッケージを探すと、たくさん出てきた。

rpm -qa --qf "%{name} %{vendor}\n"  | grep -v "Red Hat"

驚くことにglibcなどのコアコンポーネントFedoraScientific Linuxになっていた。それもリリース番号違いでなくバージョン番号違い。本来インストールできないものをnodepsforceでインストールしたようだ。そんな強引なことをしたら、正常動作しなくて当然だ。逆に動いていたことが不思議でならない。

3. EPELリポジトリを有効にする

EPELを使用するにはepel-releaseパッケージをインストールすればよい。ただし使用するクラウドサービスやLinuxディストリビューションによって以下の注意事項がある。EPELのWebサイトも見てほしい。

3-1. EPELリポジトリがあるか確認する

OSを新規インストールしたばかりのときは、すぐにepel-releaseパッケージをインストールして問題ない。しかし、長期間使っていたときやクラウドのときは、EPELリポジトリがインストールされていることがある。そのため事前に確認しよう。

  1. EPELリポジトリの設定ファイルがインストールされているか確認する。何も表示されなければインストールされていない。3-2に進もう。
sudo yum repolist all | grep -i epel

2.次のように表示されたときにはインストールされている。

$ sudo 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を有効にする(基本)

クラウドRHELCentOSを使うとき」や「オンプレミス環境」では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

ヒント CentOSではextrasリポジトリにepel-releaseパッケージがあることが多い。そのときにはyum install epel-releaseでインストールできる。

3-3. EPELを有効にする(AWS

Amazon Linux 2ではEPELを有効にする専用のコマンドが用意されている。AWSでもRHELCentOSでは、前述の方法を利用する。

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-4. EPELを有効にする(Oracle Linux

Oracle Cloud InfrastructureのOracle Linuxでは「ol7_developer_EPEL」「ol8_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-4-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 Oracle Linux 8ではol7_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-4-2. Oracle Linux用EPELリポジトリをインストールする

EPELがdisableの状態でも参照できるときはenableにすればよい。しかし、そもそも存在しないときは定義ファイルをインストールする必要がある。手順は、次のとおりだ。

$ sudo yum install oracle-epel-release-el7
$ sudo yum install oracle-epel-release-el8

3-4-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
3262
$ sudo yum --disablerepo=* --enablerepo=epel list available | wc -l
6285

4. さらなるEPELの使いこなし

4-1. EPELの有効化/無効化を切り替える

EPELに限らず追加のリポジトリを使用するときは、「常時有効にする」「一時的に有効にする」の2通りの方法がある。EPELを使い始めたら常時有効にするのが一般的だが、よりセーフティーな運用を目指すときは「一時的に有効にする」こともある。

つまり通常は無効にしておき、使うときだけ有効にする方法だ。このようにすることで「EPELのパッケージを明確に区別する」「既存のリポジトリとEPELリポジトリとのコンフリクトを避ける」メリットがある。

常時有効にする
yum repolistで表示されるときは有効になっている。またrepoファイルはenabled=1になっている。

一時的に有効にする
この方法ではEPELを無効化しておき、必要なときだけ有効化する。

  1. EPELを無効化する。これでyumを実行してもEPELのパッケージは利用できない。
sudo yum-config-manager --disable epel

2.EPELにあるパッケージをインストール/アップデートするときだけ--enablerepoオプションで有効化する。

sudo yum --enablerepo=epel install <パッケージ名>

4-2. トラブルシュート

余力のあるとき執筆予定

5. まとめ

  • 標準リポジトリにないパッケージがあるときはEPELを探そう
  • 野良リポジトリは使わないこと。使うときは人柱覚悟で
  • RPMパッケージの依存性を崩すような強引なことはしないこと
  • AWSではEPELを有効にする独自コマンドが提供されている
  • Oracle Cloud InfrastructureのOracle Linux 7では独自のEPELリポジトリを利用できる

CentOSからCentOS Streamへ。CentOS終了の衝撃

2020/12/14追記 CentOS終了に伴い、Rocky Linuxのリリースが発表されました。 ZDNet Japan: CentOSプロジェクトの創始者、「Rocky Linux」プロジェクトを立ち上げ

CentOSからCentOS Streamへ

2020/12/08のCentOS公式ブログで「CentOS Project shifts focus to CentOS Stream」という記事が発表された。 centos8.png

簡単にまとめると次のとおり。

  • CentOS 8は2021/12/31でサポートが終了する
  • CentOSは今後CentOS Streamに移行する
  • CentOS Streamは、RHELのアップストリーム(開発)ブランチ。従来のリビルドしたものとは違う位置づけ
  • CentOS 7のサポート期間は従来通り2024/06/30で変わらず
  • CentOS 8の利用者は、差分が少ないCentOS Streamに移行するか、本番環境利用で心配ならばRHELに移行することが推奨されている

参考までにCentOS / RHELのサポート期間は次のとおり。

バージョン サポート終了
RHEL/CentOS 6 2020/11/30
RHEL/CentOS 7 2024/06/30
CentOS 8 2021/12/31
RHEL 8 2029/05/31

CentOS Streamとは

CentOS Streamは以下の赤帽ブログが詳しい。Fedoraほど離れていないけれど、開発ブランチという位置づけ。

RHELCentOS Streamの関係について、わたしのイメージは下図のとおり。 centos8-1.png

世間の反応

日本のいろいろなネットニュースで取り上げられているけれど、CentOS blogのコメント欄が荒れまくり。Ubuntuに行くって声が多い。

Scientific Linuxはすでに開発中止。となるとProductionで使えるRHEL互換ディストリビューションOracle Linuxなのだけれど、Oracleは嫌われものなのでネガティブな意見が多い。

CentOS"poorman's RHEL"だから、RHELに行けと言われてもつらい。個人や開発環境ならCentOS Streamを使うのもありだけど。

個人的に思うこと

以前の商用パッケージ製品は、RHELSUSEのような商用ディストリビューションしかサポートしていなかった。だけれど最近はAmazon LinuxCentOSをサポートするパッケージも増えてきた。Amazon Linuxはシェアもあるし、AWSのサポートもあるしね。

今回の出来事で、CentOS Streamをサポートする商用パッケージは大幅減の予感。本番環境で使うってのも、エンタープライズ系の人たちはしなさそう。

エンタープライズ&本番環境で使うなら、RHELに行けってことなのだけれど、お金ある人はすでに使ってるはずだし。それとは別に、Red Hatエンタープライズ契約って条件が厳しいんだよね。部分解約が困難とか。

UbuntuSUSE。うーん。

Ubuntuはエッジやデスクトップ、個人利用で使っても、日本のエンタープライズ&本番環境となると苦戦しそう。Ubuntu LTSは最低5年だけれど、日本のシステム更改間隔を考えると短いんだよね。

SUSEを使っているエンタープライズ系のユーザーにたまに出会うのだけれど、日本では現状のマイナー感を脱するのは想像できない。ちなみに、筆者は20年前にLinuxディストリビューション開発にかかわっていました。いまはかかわっていないけど。

Oracle Linuxは選択肢の一つだと思うけれど、宗教上の理由(?)でOracleを使いたくない人が多そう。最近AWSでOracle Linuxが使えるようになっていてビックリ。

今回のことはOracle Corporationも気になったようで、2020/12/12のブログで移行方法を紹介している。

2020/12/16追記 上記ブログで紹介しているスクリプトを実際に実行してみました。

RHEL互換ディストリビューションの作成方法

参考までに、RHEL互換ディストリビューションの一般的な作成方法を紹介する。テストなどは省略。

  1. RHELからソースRPMを入手
  2. ロゴなど商標権に関わる部分をはじめとして、そのまま利用できないものを削除
  3. ディストリビューション固有の変更(味付け)
  4. リビルド
  5. ISOイメージ化

この中で重要なことが2点ある。

1つめは「ディストリビューション固有の変更」。具体的には、既存のRPMパッケージに対する修正や、新規パッケージの追加。互換性を維持する必要があるので、kernelやglibcgccbinutilsなどのコアコンポーネントには手を加えないこと。もしくは、手を加えるとしても、必要最小限にすること。

CentOSの場合は、/etc/redhat-releaseから/etc/centos-releaseへの変更など最小限に抑えている。

CentOS blogのなかでrebuildという表現が出ているけれど、これは上記「4.リビルド」を指している。ニュアンスとしては、ソースを変更しないでリビルドしただけ。

2つめはリビルド時のビルド環境構築。これはプロダクトには含まれないけれど、同一ソースであってもビルド環境(おもにライブラリ群)が異なると、できあがるバイナリも異なる。そのため互換性のあるビルド環境を構築するのは、RHEL互換ディストリビューション作成者の腕の見せ所。

また「RHELのソースはGPLだから、商標権/著作権上まずい部分を削除すれば自由に使える」なんてことを言う人もいるけれど、Red Hatエンタープライズ契約を承諾しているユーザーにとっては、ダークグレーゾーン~ほぼOUT。詳しくは契約書を読んでみて。

ところで「リビルドだけなら簡単」とは思っていませんか?

はっきり言って甘い! Red Hatからスポンサードされる前のCentOSのリリースがどれだけ遅れていたか。マイナーバージョンは一ヶ月くらいでキャッチアップできていたけれど、メジャーバージョンアップの6.0などはインストーラーの改造もあって半年以上リリースが遅れた。

2020/12/19追記 その後、CentOS blogに開発に関する投稿があり、赤帽ブログに翻訳記事が掲載された。興味のある方はどうぞ。

Rocky Linuxに続いて、いくつか開発表明されているけれど、ほとんどが残らない予感。信頼性の高いものを作るって大変なんだよね。テストが不十分なものを使うくらいなら、CentOS Streamのほうがよっぽどいいし。

結局のところタダ乗りが課題

いろいろ文句を言うのは勝手だけれど、OSSの開発者を苦しめているのは資金だろう。現在の主要Linuxディストリビューションは、Red HatSUSECanonicalなど会社がマネタイズしながら、OSSにも還元していることを利用者は忘れてはならない。

マニュアルを作るのも莫大な作業だ。正直なところ、ネットで検索できる情報の質は玉石混交でクズ情報も多い。元は優れたものでも、古くなり陳腐化することもある。それらと比べるとベンダーの公式マニュアルは頼りになる。サポート契約者だけに提供されるナレッジは、さらに頼れる。

ソースコードを書いて貢献するのは難しくても、バグ報告やマニュアルバグ指摘なども貢献の一つだ。また、個別のOSSで言えば、manやマニュアルの日本語化なども、開発者に感謝される。

さらに間接的にはなるが、Qiitaやはてなブログ、書籍や雑誌などに優良な記事を書くことも、わずかながら貢献していることになるだろう。

意外に複雑なLinuxのパスワード生成事情とパスワード生成方法

1. 意外に複雑なパスワード生成事情

システムの構築や管理で強固なパスワードを生成したいことがある。しかしTL;DRに書いたように、Linuxでは意外に複雑な事情がある。そこで今回は主要なコマンドの特性と使い方を説明する。

1-1. TL;DR

  • Linuxにはパスワードを生成するコマンドが複数ある
  • コマンドによって特性が違い、標準リポジトリに「含まれている/含まれていない」などインストール方法も違う
  • 一見ランダムでありながら、発音しやすい(=覚えやすい)パスワード生成方法もある
  • パブリック・クラウドではOSにパスワード・ログインする機会は少ないが、VNCやxrdp、シリアルコンソール接続では必要になることがある

1-2. 対象環境

2. パスワード生成方法を考える

Linuxでパスワードを生成するには、大きく分けて以下の方法がある。

  1. pwmakeやpwgen、mkpasswdなどのパスワード生成コマンドを使う
  2. opensslや /dev/urandomなどを組み合わせて使う
  3. Bitwardenや1Password、LastpassGoogleパスワードマネージャーなどのWebサイトパスワード管理ツールを使う

Webサイトのパスワードを管理するなら3を使うべきだろう。しかし今回は汎用的なパスワード生成を目指している。そのため1の方法を説明する。2の方法は以下のリンクを参照のこと。

2-1. 各コマンドの概要

それぞれのコマンドを簡単に紹介する。

pwgen
 汎用的なパスワード生成コマンド。オプションに指定した条件でパスワードを生成できる。  http://sf.net/projects/pwgen

pwmake
 libpwqualityライブラリに含まれるパスワード生成コマンド。RHEL7系から採用されたpam_pwquality(libpwquality)に統合されているため、オプションを指定しなくてもOSのパスワードポリシーに従ったパスワードを生成できる。  https://github.com/libpwquality/libpwquality/

mkpasswd
 expectに含まれるパスワード生成コマンド。機能はpwgenに似ているが、pwgenのほうが高機能。ただしRHEL系とUbuntuでは、コマンド名は同じだが別物。

ヒント pwgenとpwmakeのmanを見ると「pronounceable passwords」と説明されている。つまり発音しやすいパスワードを生成できる。程度の問題なので、辞書に登録されている単語が含まれるわけではない。

2-2. 各コマンドの入手方法

以下の表は、Linuxディストリビューションごとの入手方法だ。OSのインストールタイプに依存するが、デフォルトでイントールされるのは青字のパッケージだけで、それ以外は任意にインストールする必要がある。カッコ内は入手先リポジトリだ。

ディストリビューション pwmake pwgen mkpasswd
RHEL6系 libpwquality(EPEL) pwgen(EPEL) expect
RHEL7系 libpwquality pwgen(EPEL) expect
RHEL8系 libpwquality pwgen(EPEL) expect
Ubuntu18.04LTS libpwquality-tools pwgen whois

2-3. 各コマンドの使い分け

これまで説明してきたことをまとめると次のようにいえる。次章ではpwmakeとpwgenの使い方を説明する。

  • RHEL7系以降もしくはUbuntuで、OSのログイン・パスワードを生成するにはpwmakeが適している
  • 利用方法を限定しないパスワードを生成するにはpwgenが適している

3. pwgenを使う

汎用的なパスワード生成コマンドpwgenの使用方法を説明する。

3-1. pwgenをインストールする

pwgenはEPELリポジトリから提供されている。ただしパブリック・クラウドのOSイメージでは標準リポジトリに含まれていることもある。RHEL系とUbuntuのそれぞれについて説明する。

RHEL

  1. pwgenがインストールされているか確認する。
$ rpm -qa | grep pwgen
★インストールされていないときは何も表示されない。

2.インストールされていないときは、既存のリポジトリに含まれているか確認する。

$ sudo yum provides pwgen
★No matchesと表示されたときはリポジトリに含まれていない。
No matches found

★リポジトリに含まれているときはパッケージ名が表示される。
pwgen-2.08-1.el7.x86_64 : Automatic password generation
Repo        : epel

3.既存のリポジトリに含まれていないときには、先にEPELリポジトリをインストールする。EPELの詳細は「あらためてEPELリポジトリの使い方をまとめてみた」を参照のこと。

# RHEL6系
sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm -y

# RHEL7系
sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm -y

# RHEL8系
sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-8.noarch.rpm -y

# Amazon Linux 2
sudo amazon-linux-extras install epel

4.pwgenをインストールする。

$ sudo yum install pwgen -y

Ubuntu

$ sudo apt install pwgen

3-2. pwgenの実行方法

pwgenの文法は以下のとおり。オプションの後ろに、パスワード長と個数を指定する。下記以外のオプションはmanを参考のこと。

pwgen [ OPTIONS ] [ pw_length ] [ num_pw ]
オプション 内容
-c 最低一文字の大文字を含める
-A 大文字を含めない
-n 最低一文字の数値を含める
-0 数値を含めない
-y 最低一文字の記号を含める
-s 完全にランダムなパスワードを生成する
-B 1(イチ)やl(エル)、O(オー)、0(ゼロ)など紛らわしい文字は含めない
-1 1行あたり1パスワード表示する

例1)パスワード長は12文字で、最低1文字の大文字(-c)と数値(-n)を含める。個数指定しないときは、次のようにフルスクリーン分が表示される。この中から使いたいものを選べばよい。

$ pwgen -c -n 12
Eiv5roo5pha1 ahnie0Zeogh2 piedu8Vaijoo Foa2eghiiPho teiHosoh8ooF ohgh0Ohwaesh
pahph6Aiyu0M leiB2xahlah1 maePee7fonoe aeGo6xielaeM Veif1Iaj4Na7 beiB8IKungie
Ohlah2aithak Aelaelo2ieri bieRef8ceire cahxu7AF4Ung chah7Aht6vah edeva9Ooquie
gaeWo1Aijae7 ii1AeThuewei oohaeW0nahm5 ohmoot7Ia6Du pho0vooW4eet cu3eeThioKu9
★以下省略

例2)パスワード長は12文字で、最低1文字の大文字(-c)と数値(-n)、記号(-y)を含め、紛らわしい文字(-B)は含めない。1行1パスワード(-1)で5個生成する。

$ pwgen -c -n -y -B -1 12 5
ashoo3ga(M3W
goo7ke\o4aeL
beiHae4voeH.
AJ3ok3ahj{in
shoo7ExiJ"ir

4. pwmakeを使う

pwmakeは、OSのパスワード認証と関係が深いコマンドで、オプションを指定しなくてもOSのパスワードポリシーに従ったパスワードを生成できる。

pwgenが単独のコマンドなのに対し、pwmakeはRHEL7で採用されたpam_pwquality(libpwquality)モジュールに含まれている。そのためpwmakeの理解にはpam_pwqualityの理解も欠かせないので先に説明する。

4-1. pam_pwqualityとは

pam_pwqualityは「大文字小文字混在、○文字以上のパスワードが必須」といったパスワードポリシーを強制するPAMモジュールだ。passwdコマンドを実行すると、以下の順序でパスワードが評価され、満たしているときだけ設定できる。

  • 辞書チェック
  • 設定ファイル/etc/security/pwquality.confのルールチェック

pam_pwqualityの重要な2つのファイル/etc/pam.d/system-auth/etc/security/pwquality.confを説明する。

パスワードをチェックするPAMモジュールは、Linuxのバージョンや種類によって異なる。詳細は以下のリンクを参照のこと。

RHEL7以降:pam_pwquality
RHEL6:pam_cracklib
Ubuntupam_unix。pam_pwqualityもオプションで使用可能    →Enforce Password Complexity Policy On Ubuntu 18.04

4-1-1. /etc/pam.d/system-auth

このファイルはPAMモジュールの定義ファイルで、pam_pwqualityを呼び出し元になっている。今回の説明と関係ない行もあるのでgrepしたものを紹介する。

メディアからインストールしたときのデフォルトは以下のとおり。クラウドではカスタマイズされていることもある。

# grep ^password /etc/pam.d/system-auth
password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type=
password    sufficient    pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password    required      pam_deny.so

次の例では、過去N回のパスワード再利用を防止するためpam_pwhistoryモジュールを併用している。

password    requisite     pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= enforce_for_root
password    requisite     pam_pwhistory.so use_authtok enforce_for_root remember=4
password    sufficient    pam_unix.so sha512 shadow try_first_pass use_authtok enforce_for_root remember=4
password    required      pam_deny.so

参考:RHEL6系の例
RHEL6系ではpam_pwqualityの代わりにpam_cracklibを使用している。パスワードポリシーは後述する設定ファイルではなく、以下のように/etc/pam.d/system-authにインラインで指定する。

password    requisite     pam_cracklib.so retry=3 minlen=8 difok=3 gecoscheck ocredit=-1 dcredit=-1 ucredit=-1 lcredit=-1 enforce_for_root

4-1-2. /etc/security/pwquality.conf

/etc/security/pwquality.confはパスワードのルールを定義する設定ファイルだ。RHEL8系では/etc/security/pwquality.conf.d/pwquality.confのときもある。こちらもファイルが長いのでgrepしたものを紹介する。

# grep -v -e '^\s*#' /etc/security/pwquality.conf

メディアからインストールしたときは、すべてコメントアウトされているので、grepすると何も表示されない。

# Number of characters in the new password that must not be present in the
# old password.
# difok = 5
#
# Minimum acceptable size for the new password (plus one if
# credits are not disabled which is the default). (See pam_cracklib manual.)
# Cannot be set to lower value than 6.
# minlen = 9
★以下省略

多くのクラウドではデフォルト値が設定されていて、Oracle Cloud Infrastructure Computeでは次のように設定されている。簡単に意味を書いたが、詳しくは設定ファイル内のコメントやmanを参考にしてほしい。

difok = 3       # 過去3回のパスワードは利用不可
minlen = 8      # パスワードが8文字以上
dcredit = -1    # 数字が1文字以上
ucredit = -1    # 大文字アルファベットが1文字以上
lcredit = -1    # 小文字アルファベットが1文字以上
ocredit = -1    # 記号が1文字以上
gecoscheck = 1  # /etc/passwdエントリのGECOSフィールドの単語が含まれていない

4-2. pwmakeの実行方法

前置きが長くなったがpwmakeでパスワードを生成しよう。次のようにエントロピービット数を指定する。エントロピービット数を簡単に表すと解読の難易度だ。56以上の数値を指定でき、多くの場合64で十分だ。

pwmake <エントロピービット数>

pwmakeは「pam_pwqualityの設定値」と「エントロピービット数」の両方を考慮してパスワードを生成する。設定ファイルに値がないときは「エントロピービット数」だけを考慮する。次の例を見るとエントロピービット数が大きくなるほどパスワードも長くなっている。

$ pwmake 56
YKHUdiLIj$AH
$ pwmake 64
dEHimAf3PIwUgG
$ pwmake 80
iczaf0D4x@M-EhEGt
$ pwmake 128
Yc4kexIJiw5@sIDM3R6an(ijEDYM

次の例はOracle Cloud Infrastructure Computeで実行した例だ。定義ファイルの内容を反映し、大文字や数値、記号などが含まれている。気に入らないときは複数回実行すればよい。

$ pwmake 64
ErODFOROJ0w+YN

つまりパブリッククラウドのように設定ファイルに定義があるときには非常に便利なコマンドといえる。また定義がないときは大文字・小文字や数値などは運次第だが、強固なパスワードは生成できる。

  • man pwmake
  • man pam_pwquality
  • man pwquality.conf

5. まとめ

  • pwgenは、広い用途で使用できるパスワード生成コマンド
  • pwmakeは、RHEL7系以降でデフォルト・インストールされているパスワード生成コマンド。OSのパスワードポリシーに準じたパスワードを生成するときに便利

今さらOSのログイン・パスワードと思うかも知れないが、一番のきっかけはVNCやxrdpである。これらを使用するときにはクラウドでもパスワードログインが必要だ。

またOracle Cloud InfrastructureやAzure VMのシリアルコンソール接続では、OSユーザーにパスワードを設定する必要がある。

自分で決めた強度の高いパスワードを使ってもよいが、あまり考えずに強度の高いパスワードを生成する方法として、これらのコマンドを活用してはどうだろう。

bash-completionを活用して、manやhelpを見ずに、バシバシ長いコマンドを打つ

1. 入力補完機能を使っていますか?

bashをはじめとして、多くのシェルやコマンドプロンプト入力補完機能(completion)が提供されている。Windowsでも使える機能だし、ほとんどの人が使っているだろう。

$ ls
sample.txt  test1.txt  test2.txt  test3.txt
$ cat s[TAB]キー入力
$ cat sample.txt  ★TABキーを押すと、一致するファイル名が補完される

そしてRHEL6(2010年代~)あたりからは、ファイル名やディレクトリ名だけでなく、コマンドのオプション入力にも使えるようになっている。

1-1.前提条件

1-2. TL;DR

  • 入力補完機能は使っていたが、Linuxコマンドのオプション入力で使えるのは知らなかった。恥ずかしい…。

2. systmctlのオプション長げー問題

ここ数年はRHEL7系をメインに使っているが、長らくRHEL5/RHEL6系を使ってきた。RHEL7系で戸惑うのはserviceコマンドやchkconfigコマンドが使えないことだ(一部は互換機能で使える)。

システム構築・運用でよく使うコマンドなので「chkconfig --listって、systemctlだと何だったっけ…」となりがちである。

そんなときに役立つのがコマンド・オプションの入力補完機能だ。

次のようにsystemctlのあとに「TABキー」を入力すると、オプションの一覧を表示できる。

$ sudo systemctl [TAB]キー入力 ★systemctlのあとに1スペース入れてからTAB
add-requires           hybrid-sleep           reload-or-restart
add-wants              is-active              reload-or-try-restart
cancel                 is-enabled             rescue
cat                    is-failed              reset-failed
condreload             isolate                restart
condrestart            is-system-running      set-default
condstop               kexec                  set-environment
daemon-reexec          kill                   set-property
daemon-reload          link                   show
default                list-dependencies      show-environment
delete                 list-jobs              snapshot
disable                list-sockets           start
edit                   list-timers            status
emergency              list-unit-files        stop
enable                 list-units             suspend
exit                   mask                   switch-root
force-reload           poweroff               try-restart
get-default            preset                 unmask
halt                   reboot                 unset-environment
help                   reenable
hibernate              reload

一覧が表示されれば、こちらのもの。続いてlist-unit-filesを入力すればよい。オプションを入力してる途中も「TABキー」の入力補完は効く。

$ sudo systemctl list-unit-files ★list-unit-filesの途中でもTABの補完が効く

これでsystemctlも怖くない! えっへん!

3. bash-completionとは

ファイル名やディレクトリ名の入力補完では無く、コマンドのオプションを補完するのがbash-completionだ。complete -pを入力して大量の行が表示されるならば利用できると思っていい。

3-1. ディストリビューションごとの状況

Linuxディストリビューションの種類やバージョンによって、標準リポジトリに含まれていないことがある。

$ rpm -q bash-completion
bash-completion-2.7-5.el8.noarch
$  rpm -q bash-completion
bash-completion-2.1-6.el7.noarch
$ rpm -q bash-completion
package bash-completion is not installed
$ dpkg -l bash-completion
||/ Name           Version      Architecture Description
+++-==============-============-============-=================================
ii  bash-completio 1:2.8-1ubunt all          programmable completion for the b

少し古いので現在当てはまるか微妙だが、MacOSの情報はこちら。

3-2. RHEL6系OSへのインストール

RHEL6やCentOS 6、Oracle Linux 6では、bash-completionをEPELリポジトリからインストールする必要がある。その手順を説明する。

  1. EPELリポジトリが有効になっているか確認する。次のように行が存在し、enabledになっていれば利用できる。
$ yum repolist all | grep -i epel
epel                         Extra Packages for Enterprise Linux enabled: 12,586

2.上記以外のときは状況に応じてEPELリポジトリを有効にする。

行はあるがdisabledのとき

$ sudo yum-config-mangaer --enable epel

行自体がないとき

$ sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-6.noarch.rpm -y

3.次のように「Available Packages」に表示されたときは、インストールされていないが、リポジトリには存在している。

$ sudo yum list bash-completion
Loaded plugins: refresh-packagekit, security, ulninfo
Available Packages
bash-completion.noarch                          1:1.3-7.el6                          epel

4.ここまで確認できたらbash-completionをインストールする。

$ sudo yum install bash-completion -y

5.bash-completionを有効にするためにログアウト/ログインする。ログアウトする理由は/etc/profile.d/bash_completion.shbash-completionの定義ファイルを読むためだ。

3-3. bash-completionの定義ファイル

bash-completionの定義ファイルは、次のディレクトリ配下に存在する。

  • /etc/bash_completion.d/
  • /usr/share/bash-completion/completions/

ディレクトリを確認すると大量の定義ファイルがある。このファイルがあるコマンドは、オプションの入力補完ができることになる。

$ ls  /usr/share/bash-completion/completions/ | wc -l
454

$ ls /usr/share/bash-completion/completions/
addpart       fsck.minix      lvextend     raw                  timedatectl
blkdiscard    fsfreeze        lvm          readprofile          tuned-adm
blkid         fstrim          lvmdiskscan  rename               udevadm
blockdev      gapplication    lvreduce     renice               ul
bootctl       gdbus           lvremove     repquota             umount
busctl        getopt          lvrename     resizepart           unshare
bzip2         groupadd        lvresize     rev                  useradd
cal           groupdel        lvs          rpm                  userdel
cfdisk        groupmod        lvscan       rtcwake              usermod
★以下省略

3-4. 入力補完例いろいろ

先ほどのsystemctlの例ではlist-unit-filesオプションを補完した。それ以外にもハイフン(-)やハイフンハイフン(--)で始まるオプションも入力補完できる。

$ sudo systemctl -[TAB]キー入力
-a                     --ignore-dependencies  --quiet
--after                --kill-who             -r
--all                  -l                     --recursive
--before               --no-ask-password      --reverse
--defaults             --no-block             --root
-f                     --no-legend            --runtime
--fail                 --no-pager             -s
--failed               --no-reload            --signal
--force                --now                  --state
--full                 --no-wall              --system
--global               -p                     -t
-h                     -P                     --type
-H                     --privileged           --version
--help                 --property
--host                 -q

表示まで少し時間はかかるが、サービス名(ユニットファイル名)の途中で「TABキー」を入力すると、一致するサービスの一覧を表示できる。

$ sudo systemctl restart sshd[TAB]キー入力
sshd@                sshd.service
sshd-keygen.service  sshd.socket

sshの場合

sshでは、~/.ssh/known_hosts~/.ssh/config/etc/hostsからホスト名候補を表示できる。

$ ssh [TAB]キー入力
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
::1         localhost localhost.localdomain localhost6 localhost6.localdomain6
10.5.1.35 ol7srv.dbprivatenrt01s.work01nrtvcn.oraclevcn.com ol7srv
$ ssh ol7[TAB]キー入力
ol7ksplice
ol7srv
ol7srv2
ol7srv3
ol7srv-vip.dbprivatenrt01s.work01nrtvcn.oraclevcn.com
$ ssh -o [TAB]キー入力
AddressFamily=                     IdentitiesOnly=
BatchMode=                         IdentityFile=
BindAddress=                       IPQoS=
ChallengeResponseAuthentication=   KbdInteractive

ここまで来ると何でもありだ。とりあえず「TABキー」を試してみたい。

定義ファイルを解析すれば、コマンドごとに何ができるかわかる。だけれど数が多いので覚えるのはナンセンスだ。

次のように本来オプションを指定するコマンドなのに、カレントディレクトリのファイルやディレクトリが表示されたときは定義されていない、と覚えた方がいいだろう。

$ sudo yum-config-managar [TAB]キー入力
bash-completion-extras-2.1-11.el7.noarch.rpm
.bash_history
.bash_logout
.bash_profile
.bashrc
.cache/
.config/
.lesshst
sample.txt
.ssh/

3-5. さらに追加モジュール

bash-completionには追加モジュールのbash-completion-extrasがある。こちらはRHEL7系でもEPELリポジトリが必要だ。

なお、現時点利用できるのはEPEL7だけで、EPEL6とEPEL8では提供されていない。しかし、el7のサフィックスは付いていてもnoarchなので、wgetやyumdownloaderで入手して、RHEL6/8系にインストールすれば使えるだろう。

  1. クラウドではデフォルトでEPELリポジトリが有効になっていることがある。次のコマンドでEPELを確認する。このように表示されたときは、すぐにインストールできる。
$ sudo yum list bash-completion-extras
Loaded plugins: langpacks, ulninfo
Available Packages
bash-completion-extras.noarch          1:2.1-11.el7           ol7_developer_EPEL

2.EPELリポジトリがインストールされていないときはインストールする。

$ sudo yum install https://dl.fedoraproject.org/pub/epel/epel-release-latest-7.noarch.rpm -y
$ sudo amazon-linux-extras install epel -y

3.bash-completion-extrasパッケージをインストールする。これで終了だ。

$ sudo yum install bash-completion-extras -y

4.パッケージの中身を確認すると300近いモジュールがあり、mysqlpostgresqlなどもあることがわかる。

$ rpm -ql bash-completion-extras |wc -l
271

$ rpm -ql bash-completion-extras
/usr/share/bash-completion/completions
/usr/share/bash-completion/completions/a2x
/usr/share/bash-completion/completions/aclocal
/usr/share/bash-completion/completions/add_members
/usr/share/bash-completion/completions/alias
/usr/share/bash-completion/completions/alternatives
/usr/share/bash-completion/completions/animate
/usr/share/bash-completion/completions/ant
/usr/share/bash-completion/completions/apropos
/usr/share/bash-completion/completions/arch
/usr/share/bash-completion/completions/arping
★以下省略

4. まとめ

  • bash-completionを使用すると、コマンド・オプションを入力補完できる
  • RHEL6系ではEPELからインストールする必要がある
  • RHEL7/8やUbuntuではデフォルトでインストールされていることが多い。少なくとも標準リポジトリには存在する