インターネットの使えない環境下で RHEL(RedHat Enterprise Linux) 9.0 をインストールして、サブスクリプションを登録するまでの方法を調べてみました。

通常 RHEL 9.x を DVD や ISO からインストールする場合、サブスクリプションの登録がインストーラーの一部に組み込まれていて、（インターネット経由で）サブスクリプションを登録しないとインストールできないようになっています。つまり通常のインストールだとインターネット接続が必須です：

（SOFTWARE 欄の "Connect to Red Hat" と書かれた部分に注目。ここで RedHat ポータルにログインし、サブスクリプションを登録しないとインストーラーは先に進めなくなっています）

しかし特殊なケースで、インターネット接続が全くない（Proxy の設定によって接続できる、とかではなく、そもそもインターネット接続回線そのものが存在していないような）環境下で RHEL をインストールしたいケースもあるはずです。その場合の手順を紹介します。なお以下で紹介するスクリーンショットでは RHEL 9.0 を使っていますが、9.x であれば手順は同様のはずです。


【RHEL 9.x のオフラインインストール手順】
おおまかなオフラインインストール手順を紹介します：
（手順１）インターネット接続環境を使った事前準備
（手順２）RHEL 9.x のオフラインインストール
（手順３）オフライン環境下でのサブスクリプション登録


通常のインストールだとインストール中に RedHat カスタマーポータルの RHSM(RedHat Subscription Management) にアクセスしてサブスクリプションを登録することで、その場でシステムプロファイルを作成＆登録します。一方、インターネットにアクセスできない環境での登録を考慮したケースでは事前に（手動で）システムプロファイルを作成して、その証明書ファイルをダウンロードしておきます。そしてオフライン環境で RHEL をインストールし、ダウンロードした証明書ファイルをインポートすることでサブスクリプション登録を行う、という手順を実行します。ある意味で実行順序が異なるだけで、RedHat のアカウントが必要になる点などは変わりありません。

なお（手順１）のみ、RHEL インストール先マシンとは別のインターネットの使える環境で実施する必要があります。手元の PC などインターネットの使える PC を使って実施してください。


【（手順１）インターネット接続環境を使った事前準備】
インターネットの使える環境下で RHSM のシステムページにアクセスします（ログインしていない場合はログインします）。

以下のような画面が表示されます（ログインしたアカウントで既に RHEL のサブスクリプションを利用している場合は利用中のサブスクリプションの一覧が表示されます）。今回は新しいサブスクリプションのプロファイルを作成したいので「新規作成」ボタンをクリックします：



このサブスクリプションを登録するシステムの種類（物理システム／仮想システム、名前、アーキテクチャ、CPU 数、RHEL バージョン）を入力して、「作成」ボタンをクリックします（ここでは "air-gapped-vm" という名前で作成しています）：



先ほどの画面に戻ると、直前に新規作成したシステム（"air-gapped-vm"）が一覧に含まれて表示されます。この名前部分をクリックします：



作成したシステムの詳細画面に移動します。「サブスクリプション」タブを選択すると、このシステムをどのサブスクリプション（有償／無償／トライアル／・・）に紐づけて利用するかの画面が表示されます。このシステムはまだ作成したばかりでどのサブスクリプションにも紐づいて（アタッチされて）いないはずです。紐づけを作成するので「サブスクリプションをアタッチ」ボタンをクリックします：



自分のアカウントで利用可能なサブスクリプションの一覧が表示されるので、ここから利用するサブスクリプションを選択します。私は個人開発者向けに 15 システムまで無料で利用できる "RedHat Developer Subscription for Individuals" に登録しているので、このサブスクリプションを使うことにしています（というわけで下図では "RedHat Developer Subscription for Individuals" にチェックを入れています）。選択後に「サブスクリプションのアタッチ」ボタンをクリックします：



「サブスクリプション」タブが選択された状態の画面に戻ります。先ほどとは異なり、サブスクリプションがアタッチされているのでアタッチ済みのサブスクリプションが表示されています。　この内容を確認後に「証明書のダウンロード」ボタンをクリックします：



"xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx_certificates.zip"（"x" は英数文字）という名前の zip ファイルが手元の PC にダウンロードされるので、このファイルを展開します。すると "consumer_export.zip" という名前の zip ファイルが含まれているので、これを取り出します：



取り出した "consumer_export.zip" ファイルを再度展開すると、"entitlement_certificates" というフォルダが見つかるはずなので、このフォルダの中を参照します：



"entitlement_certificates" フォルダ内に拡張子が ".pem" のファイルが１つ見つかります。このファイルが後ほどオフラインで登録することになるシステムプロファイルの証明書ファイルです。このファイルを取り出しておきます：



後でオフライン状態の RHEL （をインストール前のシステム）で使えるよう、取り出した .pem ファイルを USB メモリにコピーしておきます。

地味に重要だと思っているのですが、ここで利用する USB メモリは「SD カードや micro SD カードを USB のカードリーダーに接続したもの」ではなく、純粋な USB メモリスティックを使うことを推奨します。理由は後からこの USB メモリを指定してシステムにマウントする作業を行うのですが、その際 USB メモリスティックだと名前でなんとなく見つけやすいのに対して、カードリーダーに接続されている場合は（もしかしたら認識すらされていない可能性もあるのに）名前ではわからないので、適当に指定してファイルシステムを破壊してしまう可能性もあるため、これを避けるためです。初めから容量のわかっている USB メモリスティックだと、その容量が名前の一部に含まれていたりする（後述の例だと "Memory Key 4GB" みたいな感じ）ので見つけやすいのでした。

ここまではインターネットの使える環境で行う、いわば「準備」作業です。ここから先はインターネットのない環境で実施します。



【（手順２）RHEL 9.x のオフラインインストール】
インターネット接続の無いマシンに RHEL 9.x の DVD(ISO) メディアをセットして起動＆インストールします。以下、画像は RHEL 9.0 のメディアを使った時のものです。

最初はこんな画面になります。（デフォルトは "Test this media & install Red Hat Enterprise Linux 9.0" ですが）"Install Red Hat Enterprise Linux 9.x" を選択して Enter を押します（メディアテストする場合は放っておいても構いませんが、飛ばした方が早いです）：



メディアからのブートが始まります：



こんな感じの画面になると「あと少し」です。もう少し待ちます：



画面が GUI になり、インストールウィザードが起動します。最初はインストールで使用する言語を選択します（ここでは English - English(United States) を選択したものとして説明を続けます。以下のスクショも英語画面のものです）：



次にこのようなインストール要件を設定する画面になります。赤い文字が表示されている箇所は必須設定が未定になっていることを意味しており、全て指定しないとインストールまで進めません。　大事な点として、SOFTWARE のすぐ下にある "Connect to RedHat" 部分があります。インターネット接続が可能な環境であると判断されると、ここも赤文字になって RedHat のサブスクリプション登録を行うことになりますが、インターネット接続のない環境の場合はここをスルーできるようになります（スルーする場合は後でサブスクリプション登録が必要です）。　私の環境の場合、とりあえずキーボードを日本語キーボード配列にしたい（デフォルトは英語キーボード配列）ので Keyboard をクリックします：



キーボード配列設定画面に移動します。初期状態は "English(US)" しか登録されていないので、下の "＋" をクリックして追加します：



追加するキーボード配列を選択します。ここでは "Japanese" を指定して "Add" ボタンを押します：



"Japanese" が追加されましたが、このままだとデフォルト設定は "English(US)" のままです。そこで "Japanese" を選択した状態で、"＾" のボタンを押して、"Japanese" を一番上まで移動させます：



"Japanese" が一番上になったことでデフォルト設定になりました。これでキーボード配列の作業を完了するので左上の "Done" ボタンをクリックします：



元の画面に戻りました。キーボード配列は "Japanese, English(US)" になっています。　次に必須設定項目である root パスワードを指定します。"Root Password" と書かれた部分をクリックします：



root ユーザーのパスワードを、確認のため２度入力します。このシステムの root ユーザーに SSH からのパスワードログインを許可する場合は "Allow root SSH login with password" にチェックを入れます（入れない場合、SSH で直接 root パスワードによるログインはできなくなります）。終わったら左上の "Done" をクリックして元の画面に戻ります：



インストール先を指定する "Installation Destination" も必須指定項目です。ここをクリックします：



インストール先となるディスクを指定します。また "Storage Configuration" 項目はデフォルトの "Automatic" のままでも構いませんが、（ディスクサイズにもよりますが、"Automatic" だと "/home" がまあまあ大きめに作られてしまうので）自分でパーティションを設定したい場合は "Custom" を選びます。"Automatic" で "Done" をクリックすると元の画面に戻ります。"Custom" の場合は具体的なパーティショニングの画面に移動します：



"Custom" を選択した場合の次画面がこちらです。カスタマイズ指定方法はいくつかありますが、"Click here to create them automatically" をクリックしていったん "Automatic" と同じデフォルト設定にします：



デフォルトのパーティショニング設定が表示されます。この内容で問題なければこのまま "Done" でもいいのですが、「"/home" に３分の１程度作られるのが嫌で全部 "/" で管理したい」ということもあると思います。そんな場合は "/home" を選択した状態で "ー" をクリックして、"/home" を開放します：



パーティショニングから "/home" が消えました。同時に使われていた 30GB ちょっと（画面から確認できるサイズは "31.8GiB"）の領域が余りました。これを "/" に加えたいと思います。"/" を選択します：



"Desired Capacity" 欄を余っている 31.8 GB を足した数に変更します。下の例ではもともと 65.14GB だった容量に余った 31.8 GB を加えて 96.64 (GiB) に変更しました：



これで確定する場合は画面を下にスクロールすると現れる "Update Settings" ボタンをクリックします：



画面上でも "/" の領域が 96.94 GiB に切り替わりました。他に必要な変更があればこの作業を繰り返します。変更が完了したら左上の "Done" をクリックします：



変更があった場合、「本当に変更を書き込むよ」という確認画面が表示されます。"Accept Changes" ボタンをクリックします：



これで "Installation Destination" の設定も完了しました。この時点で未設定な必須設定項目がなくなったので右下の "Begin Installation" ボタンが有効になっています。このままクリックしてもいいのですが、最後にインストール内容を指定する "Software Selection" を見ておきましょう：



デフォルトで "Server with GUI" が選択されています。つまりこのままインストールすると GUI 画面付きの RHEL 9.x がインストールされることになります。GUI が余分であれば "Minimal Install" に変更してもいいと思います。また画面右側で関連するソフトを個別追加できるようにもなっているので、自分の求める内容に変更してください。最後に "Done" をクリックします：



今回はこの内容でインストールしてみます。画面右下の "Begin Installation" ボタンをクリックします：



インストールが開始されます。ここからはしばらく待つだけになります：



無事にインストールが完了すると "Complate!" と表示されます。画面右下の "Reboot System" ボタンで再起動します：



インストールされたディスクから再起動が実行されます：



この例では "Server with GUI" でインストールしたので、起動画面は途中から GUI モードに切り替わります（画像だとわかりにくいですが、白いサークルがクルクル回っています）：



GUI 画面の場合、初回起動時のみ以下のようなセットアップ画面が表示されます。"Start Setup" をクリックしてセットアップを行います：



まずは位置情報を提供するかどうかのプライバシー設定です。オフラインインストールの場合は、要件的にチェックを付けることはないのではないかと思います。ともあれ設定後に "Next" ボタンをクリック：



一般ユーザーの登録を行います。まずは名前とユーザー名を指定して "Next"：



次の画面で先ほど入力した一般ユーザーのパスワードを設定します。設定後に "Next"：



これで初期セットアップは完了です。最後に "Start Using Redhat Enterprise Linux" ボタンをクリックしてセットアップ画面を閉じます：



RHEL の概要説明ツアーアプリが起動しますが、不要であれば "No Thanks" で飛ばせます：



無事にインストールできました。インターネット接続がないので "System Not Registered" と表示されていますが、インストール作業そのものはこれで完了しています：



最後に簡単な使い方を説明しておきます。画面左上の "Activities" をクリックすると以下のような画面になり、使いたいアプリを検索したり、下のドックからアプリを起動できるようになります。試しにドックの右から２番目、ターミナルっぽいアイコンをクリックしてみます：



ターミナルが起動しました。こんな感じで GUI からアプリを起動することができます：



この後の作業で使うことになるので "sudo -i" して root に切り替えておきます：




【（手順３）オフライン環境下でのサブスクリプション登録】
このターミナルを使って【手順１】で取り出した証明書ファイルをインポートします。証明書ファイルをコピーした USB スティックを対象のマシンに差し込みます。そして、

# fdisk -l

というコマンドを実行します。コマンドの実行結果にはこのシステムがこの時点で認識しているディスクデバイスの一覧が表示されます。ここで先ほど差し込んだ USB スティックが認識されているデバイス名を見付けます。

下図の例だと、

  :
  :

Disk /dev/sdb: 3.84 GiB, 4127194624 bytes, 8060927 sectors
Disk model: Memory Key 4GB
  :
  :

Device    Boot Start     End Sectors  Size  Id Type
/dev/sdb1         63 8060926 8060064  3.8G   b W95  FAT32

のように表示されています。今回使っている USB メモリは容量が 4GB のもので、"Memory Key 4GB" という名前と、認識されている容量（3.84 GiB）からなんとなくこれ（/dev/sdb）が合致してそうだ、と判断できました（実際にどう表示されるかは USB メモリによって異なります）。そして更にその下の表示から、実際のパーティション名が "/dev/sdb1" であることがわかります。このパーティションをマウントすれば証明書ファイルが取り出せそうです：




といったことが確認できたので、インストール途中のこのシステムに /usb というフォルダを作ってマウントして取り出します。以下のコマンドを実行します（"/dev/sdb1" の部分は実際に認識されているパーティション名に置き換えて実行してください）：

# mkdir /usb

# mount /dev/sdb1 /usb

# df -h　　（/dev/sdb1 が /usb にマウントされたことを確認）

これで USB メモリの内容はこのシステムの /usb フォルダ以下からアクセスできるようになりました。以下のコマンドで実際に証明書ファイル（.pem ファイル）が存在していることを確認します：

# ls -la /usb/*.pem

直接アクセスしてインポートしてもいいと思いますが、念のため一時フォルダにコピーしてからインポートすることにします。証明書ファイルを /tmp 以下にコピーします：

# cp /usb/*.pem /tmp

# ls -la /tmp/*.pem　　（/tmp 以下に証明書ファイルがコピーされたことを確認）

これでこの後の作業には USB メモリスティックは不要なので、ファイルシステムからアンマウントして取り外しておきます：

# umount /dev/sdb1

# df -h　　（/dev/sdb1 が /usb からアンマウントされたことを確認）

ここまでできれば上述の RedHat カスタマーポータルで紹介されていた subscription-manager コマンドを使った登録ができるようになります。というわけで以下を実行して、証明書をシステムにインポートします（/tmp 以下にコピーした .pem ファイル名を正確に入力してください）：

# subscription-manager import --certificate=/tmp/8966514065945099419.pem

実行後に "Successfully imported certification" と表示されていれば成功です。念のため次のコマンドを実行して実際にインポートされた内容を確認することもできます（実行結果はかなり長いです。下図はその下の方の一部だけです）：

# subscription-manager list --consumed

これでオフラインインストールした RHEL システムへのサブスクリプションのインポートまでができました。


（おまけ？）
手順の中でサブスクリプションは登録したんだけど、でもまだこの "System Not Registered" エラーがでるんだよな。。



その回避策はこれらしい。でも RedHat は推奨しない、とのこと：
https://access.redhat.com/ja/solutions/7013937

タグ ：

#subscription

#subscription-manager

#rhel

#rhel9

#offline

#install

RHEL(RedHat Enterprise Linux) を「インターネットから隔離された状態で」使う、というのが本ブログエントリのテーマです。セキュリティ要件など何らかの事情があってインターネットに接続することが許されていない環境下で RHEL を使う、という場合の設定手順を紹介します。

これ、CentOS だと特に意識することもなく、インストール用の DVD などを用意して普通にインストールできるし、（インターネットに接続できない不便さはあっても）そのまま使い続けることもできます。ただ同じことを RHEL でやろうとするとうまくいかないことがあって、それを回避するにはどうすればよいか、を自分なりに調べた内容のアウトプットです。


【RHEL と CentOS との違い】
まず RHEL は CentOS と同じように使えないのでしょうか？　その違いは何で、どのような影響があるのでしょうか？

今回のテーマとしてとりあげる問題はサブスクリプションマネージャー（subscription-manager）にあります。RHEL は CentOS とは異なり、サブスクリプションがないと使えません。サブスクリプションは有償のものであったり、開発者向けに無償で提供されているものもありますが、なんらかの登録を行い、その登録情報をインストール中に入力することで使えるようになります（下画面ではインストール中に表示される「Red Hat に接続」という部分で正しいサブスクリプション情報を入力しないと先に進めません。つまりこの時点ではインターネット接続が必要です）：





なお一部のクラウドベンダーでは初めから RHEL がインストールされたイメージを使うことができますが、この場合もサブスクプションを無視して使えているわけではなく、特殊なサブスクリプションが適用された状態になっています（RHEL のサブスクリプション料金がクラウドの料金に含まれているはずです）。サブスクリプションマネージャーはこのサブスクリプション情報を管理するシステムを提供しています。


【サブスクリプションマネージャーが管理しているもの】
このサブスクリプションマネージャーが管理しているものの１つが「yum(dnf) のリポジトリ」です。例えば RHEL の場合、RedHat が提供しているツール類に加えて ansible など RHEL のサブスクリプションを所有している前提で使うことのできるツールが提供されていて、その利用のためのリポジトリ情報（yum などでインストールするためにサーバー情報や鍵情報）がサブスクリプションマネージャーによって管理されています。サブスクリプションマネージャーが yum リポジトリを管理していることで（インターネットに繋がっている RHEL や、特定のクラウド環境内で使っている RHEL は）RHEL 向けに提供されているツールを使うことができる、という仕組みになっています。そしてその仕組みを管理しているのがサブスクリプションマネージャーということになります。


【サブスクリプションマネージャーが有効な場合に不都合となるケース】
そしてこの適用されているサブスクリプション情報は、インストール後の利用時にも影響を与え続けることになります。たとえネットワークインターフェースを無効にするなどしてインターネットに（物理的／論理的に）繋がっていない状況を作り出したとしても、サブスクリプション情報はシステムに残り続けます。

これが「インターネットに接続していない環境」だと不都合な問題が発生します。以下、具体的な画面（VirtualBox 内にインストールした RHEL 9.3 の画面）を交えて紹介します。

まず RHEL 9.3 をインストールします。上述のようにサブスクリプション情報を入力／認証する必要があるため、初期セットアップ時にはインターネット接続が必要です。この時点では VirtualBox 側のネットワーク設定でアダプター割り当てを「NAT」にしていました：



この状態で（インターネット接続がある状態で） "yum repolist" を実行して現在有効な yum のリポジトリを確認すると２つのリポジトリが有効に登録されていました。そして "yum install tmux"（tmux というツールをインストールする際のコマンド）を実行すると登録されているリポジトリから必要なモジュールを探し、「インストールしますか？」と聞かれるところまで実行できました（"n" を押してインストールをキャンセルします）。期待通りの挙動になっています：



この状態からネットワークを無効にします。今回は VirtualBox 側の割り当て設定を「未割当」にしました。RHEL 側からはネットワークアダプターそのものは認識できるが、DHCP などで IP アドレスが割り当てられることもなく、実質的に使えない状態になるはずです。こうすることで物理的なサーバーをインターネットが使えない環境に移動させた時と近い状況が作り出せているはずです：



この状態で先ほどと同じコマンドを実行してみます。"yum repolist" を実行すると先ほどと同じ結果になり、リポジトリそのものは２つ登録されたままになっていることがわかります。しかし "yum install tmux" を実行して tmux をインストールしようとすると、今度は（ネットワークが使えず）リポジトリ先にアクセスすることができないため失敗してしまいます。これもここまでは期待通りの挙動と言えます：



ただ問題は「使えないリポジトリが登録されたままになっている」点です。この状態から tmux などのツールを追加インストールするにはローカルリポジトリを作成するなどすることで可能ではあるのですが、この使えないリポジトリは邪魔なので消す必要があります。

リポジトリの情報は /etc/yum.repos.d/ フォルダ以下に .repo という拡張子を持ったファイルを用意しておくことでシステムに認識させることができます。RHEL の場合も /etc/yum.repos.d/redhat.repo というファイルが用意されており、ここでサブスクリプション情報に合わせたリポジトリが使えるようになっています。　というわけでいったんこのファイルを（redhat_repo などに）リネームして、RHEL のリポジトリが無効になるよう更新してみます。　本来ならばこれで登録リポジトリは空になるはずだと期待していたのですが、実際にやっていると登録リポジトリは変わらず２つ存在したままで、しかもリネームしたはずの /etc/yum.repos.d/redhat.repo ファイルがいつの間にか復活（！？）していました：



これがサブスクリプションマネージャーの挙動です。ansible など RHEL のサブスクリプションがないと使えないリポジトリも含めて管理されており、何かの手違いでサブスクリプション情報が消えてしまわないよう（ansible などがインストールできなくなってしまわないよう）リポジトリ情報はリポジトリファイル以外でも管理されていて、変更が加わってもリポジトリの更新時に再度自動で復活させるような挙動を見せます。

この挙動により RHEL をインターネット接続がない環境で使おうとした際の、上述の「使えないリポジトリが登録されたままになっている」点を解決しようとしてもすぐに元に戻ってしまう、という問題が残ってしまうのでした。


（↓以下補足）
自分だけのケースかもしれませんが少し補足します。上述のようなインターネット接続が使えない環境下で RedHat OCP(OpenShift Container Platform) をローカルインストールしようと試みた際に RedHat が提供している ocp4-helpernode というツールを使おうとしました。　その時も上述のように RedHat のリポジトリが自動で復活する問題を抱えていたのですが、「ローカルリポジトリを作って、自動復活する前に各種ツールをインストールして準備」したつもりでした。　が、それだと最終的に ocp4-helpernode を使おうとした段階になって RedHat のリポジトリが復活してしまい、「準備ツールをインストールした時と環境が異なっている」ことが検知されたようなエラーメッセージ（↓）が表示されて止まってしまいました：

  :
  :
TASK [set_fact] ****************************************************************
ok: [localhost]

TASK [Install needed packages] *************************************************
fatal: [localhost]: FAILED! => {"changed": false, "failures": [], "msg": "Unknown Error occurred: Some packages from local repository have incorrect checksum", "rc": 1, "results": []}

自分の場合はもともとこの環境を作りたくて調べていたのですが、CentOS とは異なり、RHEL だとこのリポジトリを管理するサブスクリプションマネージャーをどうにかしないといけない、ということがわかったのでした。

なお、同じこと（OCP をネットワーク接続のない環境で物理サーバーにインストール）を RHEL ではなく CentOS を使って行うことも検討したのですが、こちらの場合は RHEL のサブスクリプションには含まれている ansible や ansible の関連ツールのインストールが別途必要になったり、上で紹介した ocp4-helpernode 自体が RHEL 向けだけに提供されていたりして、別の部分で余計にややこしそうだったのであきらめました。
（↑以上補足）


というわけで、RHEL のサブスクリプションマネージャーは便利な反面、利用形態によっては邪魔になってしまうケースもあることがわかったのでした。


【サブスクリプションマネージャーを無効にする方法】
前置きの長いブログになってしまいましたが、このような背景からサブスクリプションマネージャーを無効にしたい、という需要も少なからずあるように感じています。もちろん無効にすることで RHEL が管理している最新のリポジトリは使えなくなってしまうし、ansible など RHEL のサブスクリプションと合わせて提供されるツールもインストールできなくなってしまうというリスクがあります。そのリスクを理解した上で「それでも無効にしたい」場合だけ実施するようにしてください（私は責任取れません）。

RHEL のサブスクリプションマネージャーは以下のコマンドで無効にできます：

# subscription-manager config --rhsm.manage_repos=0

上述のような「インターネット接続がない環境下でいろいろなツールをセットアップ」しないといけないようなケースでは、まず上のコマンドを実行してサブスクリプションマネージャーを無効化した上で、DVD などから必要なモジュールを取り出し、あるいはファイルのみダウンロードしたりした上で、必要に応じてローカルリポジトリを用意してインストール／セットアップを行う、という手順が必要になると思います。

自分のように OCP をネットワーク接続のない環境でセットアップ、、なんて無茶なことをやろうとする場合に自分が調べてこのブログにまとめた関連情報（躓きそうな箇所に関する情報）を以下に記載しておくので参考にしていただけると嬉しいです：

• ローカル環境内に yum リポジトリを作成する
• "yum install xxxxx -y" の "-y" の逆オプション
• "yum install xxxxx" でインストールされるモジュールをダウンロードだけする
• yum がモジュールをダウンロードするまでの内部挙動を理解して wget で実現してみる
• RHEL9 への／からの SSH 接続ができない問題への対処

（参照）
ネットワークが制限された環境でのクラスターのベアメタルへのインストール
OpenShift on Power 完全オフライン環境でのインストール

 

タグ ：

#ocp

#rhel

#subscription

#manager

自分は（慣れの要素が大きいのですが）CentOS は未だに 6.x をメインに使っています。「別に不便じゃないし～」程度にしか考えていなかったのですが、その姿勢を改めた方がいいかなあ、と思うことがあったので、その時の様子と対処がいかに大変だったかをまとめました。

Linux で比較的新しめのアプリケーションを使おうとすると、たまにこんなエラーメッセージが出ることがあります：

./xxxxx: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by ./xxxxx)
./xxxxx: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.14' not found (required by ./xxxxx)
./xxxxx: /usr/lib64/libstdc++.so.6: version `CXXABI_1.3.5' not found (required by ./xxxxx)
./xxxxx: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.15' not found (required by /opt/Xxxxx/libnode.so)

これはシステムにインストールされている libstdc++(GLIBC) ライブラリが古く、動かそうとしているアプリケーションが要求するバージョン（上の例では 3.4.14 や 3.4.15）と合わないためのエラーが発生していることを意味しています。


※実はこのエラーはこのブログエントリの最後に「Rodeo は CentOS/RHEL 7.x 上で動かすのが無難」と書いた時の話です。CentOS 6.8 で普通に Rodeo をインストールして動かすと、ここで紹介しているようなエラーに遭遇するのでした：
CentOS に Rodeo(Python IDE)をインストールする


実際にシステムに組み込まれている libstdc++ のバージョンを確認するには以下のコマンドを実行します（青字は出力結果）：

# strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX

GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH

この例の場合、3.4.1 から 3.4.13 までは組み込まれているシステムであることが分かります。このシステムで上記アプリケーションを動かそうとすると 3.4.14 や 3.4.15 は組み込まれていないため、上述のようなエラーが発生してしまう、ということになるのでした。エラーの原因はこれで特定できました。


この状況を回避するには libstdc++ を必要なバージョンが組み込まれた新しいものと入れ替える必要があります。そして libstdc++ は gcc に含まれるモジュールなので、（まず gcc ビルドの前提となる glibc を更新して、）gcc をビルドして、そこから libstdc++ を取り出して既存のものと入れ替える、というちと面倒な手順を実行する必要があるのでした。要するに libstdc++ を新しくするためには gcc をビルドする必要があるのです。。

更に、ここまでは全ての Linux ディストリビューションに言える内容なのですが、実際にこの手順を行う場合、CentOS/RHEL 6.x だとものすごく面倒な手順が待ち構えているのでした。実際に行った長い道のりを以下に紹介します。



まず、gcc のビルドに必要なヘッダーファイルをインストールします。具体的には gmp-devel, mpfr-devel, libmpc-devel が必要で、かつ 64bit 環境では glibc-devel.i686 までも必要になります。このうち libmpc-devel 以外は標準の yum リポジトリからインストールできますが、libmpc-devel は EPEL から入手する必要があります。

というわけで、まずは EPEL リポジトリをダウンロード：

# yum install epel-release

続けて上記３つのヘッダファイルと 32bit 版 glibc ヘッダをダウンロードします：

# yum install gmp-devel mpfr-devel libmpc-devel
# yum install glibc-devel.i686

ヘッダファイルの準備ができた所で最初に前提となる glibc をダウンロードしてビルドします。以下の例では /usr/local/src 以下にソースコードを展開しています：

# cd /usr/local/src
# wget http://ftp.gnome.org/pub/gnome/sources/glib/2.32/glib-2.32.4.tar.xz
# tar Jxvf glib-2.32.4.tar.xz
# rm glib-2.32.4.tar.xz
# cd glib-2.32.4
# ./configure
# make
# make install

そして、ここからやっと gcc のソースコードをダウンロードしてビルドします。ちなみにここから先の手順を行うためには 5GB 弱の空きディスク容量が必要になります。また make の実行を開始してから完了するまでに数時間かかります。スペックにもよりますが、昼寝ではなく一度マジ寝して起きる頃に終わっている、というくらいの時間を見ておく必要があります (^^;：

# cd /usr/local/src
# curl -LO http://ftp.tsukuba.wide.ad.jp/software/gcc/releases/gcc-4.8.4/gcc-4.8.4.tar.gz
# tar fxz gcc-4.8.4.tar.gz
# rm gcc-4.8.4.tar.gz
# cd gcc-4.8.4
# ./configure
# make　（僕の仮想環境ではここで4～5時間かかりました・・）
# make install

・・・で、gcc のビルドが無事に完了したら libstdc++ の入れ替えを行います。まずは現在の状況を確認します：

# ls -l /usr/lib64/libstdc*

lrwxrwxrwx 1 root root     19  1月 23 12:35 2017 /usr/lib64/libstdc++.so.6 -> libstdc++.so.6.0.13
-rwxr-xr-x 1 root root 989840  5月 10 18:38 2016 /usr/lib64/libstdc++.so.6.0.13

ビルドした結果から、目的のライブラリをコピーして、シンボリックリンクを作り直します：

# cp /usr/local/src/gcc-4.8.4/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs/libstdc++.so.6.0.19 /usr/lib64
# cd /usr/lib64
# mv libstdc++.so.6 libstdc++.so.6.bak
# ln -s libstdc++.so.6.0.19 libstdc++.so.6
# ls -l /usr/lib64/libstdc*

lrwxrwxrwx 1 root root      19  2月 14 12:07 2017 /usr/lib64/libstdc++.so.6 -> libstdc++.so.6.0.19
-rwxr-xr-x 1 root root  989840  5月 10 18:38 2016 /usr/lib64/libstdc++.so.6.0.13
-rwxr-xr-x 1 root root 6468627  2月 14 12:06 2017 /usr/lib64/libstdc++.so.6.0.19
lrwxrwxrwx 1 root root      19  5月 26 11:23 2016 /usr/lib64/libstdc++.so.6.bak -> libstdc++.so.6.0.13

最後に目的のバージョン（今回であれば 3.4.14 や 3.4.15）が有効になっているかどうかを確認します：

# strings /usr/lib64/libstdc++.so.6 | grep GLIBCXX

GLIBCXX_3.4
GLIBCXX_3.4.1
GLIBCXX_3.4.2
GLIBCXX_3.4.3
GLIBCXX_3.4.4
GLIBCXX_3.4.5
GLIBCXX_3.4.6
GLIBCXX_3.4.7
GLIBCXX_3.4.8
GLIBCXX_3.4.9
GLIBCXX_3.4.10
GLIBCXX_3.4.11
GLIBCXX_3.4.12
GLIBCXX_3.4.13
GLIBCXX_3.4.14
GLIBCXX_3.4.15
GLIBCXX_3.4.16
GLIBCXX_3.4.17
GLIBCXX_3.4.18
GLIBCXX_3.4.19
GLIBCXX_FORCE_NEW
GLIBCXX_DEBUG_MESSAGE_LENGTH

期待通りのライブラリに更新できました。これで CentOS 6.x でも Rodeo が動くようになりました。いやあ、長かった。めでたし、めでたし：

↑今回のブログエントリは、この「CentOS 6.x 上で動く Rodeo」のスクリーンショットを撮るまでがいかに大変であったかを分かっていただきたいがために書きました。 (^^;


ここまで確認できれば glibc や gcc のソースコード一式は不要なので、消してしまっても構いません（何しろこの環境のために 5GB 前後のディスクを専有しているので・・・）

# cd /usr/local/src
# rf -rf glib-2.32.4
# rm -rf gcc-4.8.4

（参考）
http://qiita.com/dozo/items/de393588d5c267794ced

https://www.saintsouth.net/blog/update-libstdcpp-on-centos6/



 

タグ ：

#gnu

#rhel

#gcc

#glibc

#centos

#libstdc++