AWSでのRHELメジャーアップグレード

RHEL7系から8系へのアップグレードを行う。バージョンによらず大きな流れは変わらないはず。

RedHatを直接契約している場合とAWSのEC2とで手順が大きく変わるので、そういった前提部分を明確にしたうえで解説する。

  • AWSのEC2でRedHatのサーバーを立てている場合、AWSがサポートしているRedHatのディストリビューションをを使用している扱いとなる。
  • そのため、AWSへの問い合わせも可能。（わからないことは積極的に利用すると良い）
  • メジャーアップデートのインプレースアップグレード（対になる言葉はクリーンインストール）を行う。

参考：RedHat_RHEL 7 から RHEL 8 へのアップグレード

手順内の補足

3章ハードウェア要件

この章はあまり気にしなくて良い。

これ以上のスペックを乗せると対応できない、という『MAX』 の要件を書いているだけで、必要要件ではない。

4.1. アップグレードに向けて RHEL 7 システムの準備

subscription-manager を使用してシステムがサブスクライブされていることを確認します。

RedHat を使用するにあたっては、本来サブスクリプション（ライセンスのようなもの）の登録を行う。サブスクリプションの登録が無い場合、yum rpmコマンドなどでパッケージを使用することができない。

ドキュメントに出てくるSimple Content Access（SCA）とはRedHat サブスクリプションの扱いを簡単にするもの。

AWSのEC2でインスタンスを作成す場合は、 AWS が RedHatのサブスクリプションを登録しており、EC2の料金に含まれている。

AWSが提供するRHELはHourly RHELというパッケージ。Hourlyとは1時間単位のライセンスという意味。

SSHで、以下コマンドを実行し、登録があればAWSのRHELを使用していることが確認できる。

# rpm -qa | grep rh-amazon-rhui-client

ドキュメントでは、subscription-managerのコマンドが多く書かれているが、これはRedHatのサブスクリプションを使用している場合のコマンドなので、AWSのRHELの場合は使用しない。

AWSでは、yum-config-manager を使用するので、アップグレード手順のうち、 subscription-manager ではなく、 yum系コマンドを順次実施していく。

作業手順

主な手順は以下。

  1. バックアップを作成する
  2. 7系の最新にアップグレードする
  3. アップグレードのためのパッケージをインポートする
  4. PREアップグレードを実施する（お試しのアップグレードとリスク評価）
  5. アップグレード

バックアップを作成する

最も大切な手順。

AWSのAMIを作成し、サーバーのバックアップを作っておく。

バックアップを作らずにアップグレードに失敗するとサーバーが復旧できなくなる可能性もあるので、絶対に忘れないこと。

7系の最新にアップグレードする

作業前に、OSのバージョンを確認しておく。

# cat /etc/os-release  // OSの情報
# uname -sr  // カーネルの情報

手元のRHEL7を、7系の最新バージョンにアップグレードする。

# yum list updates  // アップデートがあるか確認
# yum update -y  // アップデート
# reboot  // サーバー再起動

アップグレードに必要なリポジトリを有効化する

アップグレードに必要なリポジトリを有効化、およびパッケージのインストール

# yum-config-manager --enable rhui-client-config-server-7
# yum-config-manager --enable rhel-7-server-rhui-extras-rpms
# yum install -y rh-amazon-rhui-client leapp-rhui-aws  //leapp-rhui-aws aws経由でleappを扱うためのパッケージ

PREアップグレードを実施する

アップグレードにあたってエラーが発生しないことを事前に確認する。

これを怠ると、 アップグレード後にシステムが起動しない可能性がある。

# yum install -y leapp-upgrade //leapp: upgrade用のパッケージ
# leapp preupgrade --no-rhsm // rhsm:REDHAT subscription managerの略。使用しないので、 no-rhsmオプションを付与する

レポートが以下に出力される

/var/log/leapp/

Errorsと、Inhibitorsについては解消しないとアップグレードできない。その他は、レポートを参照してリスクにより判断する。

リスクレベルはREDHATのドキュメントを参照。

主なエラーについては参考までに後述する。

アップグレードを実施する

レポートで出力されたリスク対応が完了したらメジャーアップグレードを実施する。

leapp upgrade --no-rhsm

このあとrebootすると、upgradeされたkernelが起動するが、 その前に改めてカーネル情報を確認する。

grubby --info=ALL

もともと残っていたkernelに加え、以下が追加されていることを確認する。

kernel=/boot/vmlinuz-upgrade.x86_64  // upgradeによって作成されたkernel

加えて、OSの起動設定が、上記のupdateしたkernelを参照していることを確認する

# grubby --default-kernel

問題なければインスタンスを再起動する

# reboot

再起動までは10分以上かかる。途中5分以上無応答に見える時間があるが、処理は進行している。

進み具合を確認したい場合は、以下の手順で確認する。

EC2＞インスタンスを選択＞接続＞EC2 シリアルコンソール

インスタンスが起動したら、サードパーティーパッケージが削除されていないことを確認する

rpm -qa | grep パッケージ名

leappレポートリスク対応

Multiple devel kernels installed

kernelのパッケージが複数インストールされている。以下のコマンドを実行すると、複数のバージョンがあることが確認できる。

# rpm -qa |grep kernel-devel
kernel-devel-3.10.0-1160.114.2.el7.x86_64
kernel-devel-3.10.0-1160.118.1.el7.x86_64
kernel-devel-3.10.0-1160.119.1.el7.x86_64

kernelは新しいバージョンのものをインストールしても、安全のために古いものがそのまま残る仕様となっている。

そのため、このエラーは必然なのだが、アップグレードに当たってはカーネルを1つにする必要がある。

# yum list updates | grep kernel  // カーネルのバージョンを確認
# package-cleanup-oldkernels --count=1  // 古いカーネルを、1つのみ残して削除
# grubby --info=ALL  // 最新バージョン以外が削除されたか確認
# grubby --default-kernel  // 最新のkernelを選択していることを確認

grubbyは、ブートローダを参照し、メニューエントリを確認するコマンド。簡単に言えば、OSの起動設定。

以下のような表記で、各エントリーのkernelの情報を見ることができる。

kernel=/boot/vmlinuz-3.10.0-1160.119.1.el7.x86_64
kernel=/boot/vmlinuz-0-rescue-ec273b3271fc18bc3dced5e44d419026

vmlinuzはカーネルを実行するバイナリファイルで、後続の数字が実行されるカーネルのバージョン。

rescueは、レスキューモードで起動する場合のエントリー。

カーネルのバージョンからRHELのバージョンを知りたい場合は、RHELのドキュメントを参照。

Missing required answers in the answerfile

アップグレード時には、RHELから複数の確認事項が質問される。

これをサーバー上でやり取りするのではなく、事前にアンサファイルを登録しておくことで省略するのだが、このファイルが無いと言われている。

preupgradeを実施すると、アンサーファイルが存在しない場合は自動で作成されるので、これを編集する。

/var/log/leapp/に自身で作成しても良い。必要な設定記述は以下の通り。

[remove_pam_pkcs11_module_check]
confirm = True

コマンドで実行する場合

# leapp answer-section
# remove_pam_pkcs11_module_check.confirm=True

Packages available in excluded repositories will not be installed

独自にインストールしたサードパーティーのパッケージ等は、Redhatによって署名されていないため、アップグレードに伴い削除、または、それ自身が適切にアップグレードされない可能性がある。

レポートのリスクとしてリストアップされている場合は、 対象のパッケージをメモしておき、 アップグレード後も問題なく存在するかを確認する。

Possible problems with remote login using root account

パスワードでのルートログインは禁止される。

以下のファイルのPermitRttoLogin設定を編集する。

/etc/ssh/sshd_config
  • 編集前：#PermitRttoLogin yes
  • 編集後：PermitRootLogin prohibit-password

Appendix

用語解説

  • RHEL:RedHat Enterprise Linux。 RedHat系Linuxの大枠のディストリビューション名。
  • RHUI:RHELパッケージ管理用システム。 これがあるおかげで、AWS経由でrpm、yumコマンドでRedHat Networkにアクセスできる。
  • rpm RedHat Package Manager。 RedHat系Linuxで使用するパッケージ管理システム。
  • yum：パッケージ管理ツール。依存関係も自動解決してくれたりと便利。rpmコマンドの拡張なので、yumを使用しても、実際呼ばれているのはrpmコマンド。

参考：Red Hat Update Infrastructure(RHUI)について

yumで管理しているリポジトリ

リポジトリ定義は/etc/yum.repos.d に格納されている。だいたいはredhat-rhui.repoの中にまとめて記述されている。

実態は/var/lib/yum/repos/x86_64/7Serverあたり?

RHELのライフサイクル

参考：RHEL7ライフサイクル提供状況

インシデント

コマンド実行時にsubscription-managerの警告が表示される

This system is not registered with an entitlement server. You can use subscription-manager to register.

無視して良い。 RHEL を使用するために必要なsubscription-managerを登録していないとREDHATに忠告されている。EC2の場合はAWSがREDHATと契約している形なので、気にしなくてOK

RedHatナレッジベースが閲覧できない

AWSのRHELの場合は、RHELのサブスクリプションを直接登録していないため、ナレッジベースの各ページ冒頭部分しか見ることができない。

以下から、AWSのライセンスを使用してRHELのナレッジベースにアクセスできる。

AWS Systems Manager＞フリートマネージャー＞アカウント管理＞ナレッジベースへアクセス

参考：AWS_Red Hat ナレッジベースポータルへのアクセス

yumエラー

実行コマンド

# yum install -y rh-amazon-rhui-client leapp-rhui-aws

エラーメッセージ

https://packages.microsoft.com/rhel/7/prod/repodata/repomd.xml: [Errno 14] curl#6 - "Could not resolve host: packages.microsoft.com; Unknown error"
Cannot find a valid baseurl for repo: rhel-7-server-rhui-extras-rpms/x86_64

パッケージの要不要を判断して、必要なければ無効化する。

# cat /etc/yum.repos.d/prod.repo | grep packages-microsoft-com-prod  // 定義ファイルのステータスを確認
# yum-config-manager --disable packages-microsoft-com-prod  // 無効化

 

コメント

タイトルとURLをコピーしました