RHELインスタンスだとyumが使えない?


RHELインスタンスだとyumが使えない

という情報をちょっと聞いたので調べてみました。
そのとき得た知見を残しておきます。

とりあえず試してみる

使用したAMIはAmazon Linux 2 AMI (HVM), SSD Volume Typeです。
EC2ダッシュボードからREHLのAMIを選んでEC2を作成してyum updateしたら
普通にできました。
はて、、、

RHELインスタンス→スナップショット→AMI→インスタンス作成

調べてみると上記の方法で作成したインスタンスだとyumが使えないという情報を得たので
こちらも試してみました。

確かにこのフローで作成したインスタンスでyumコマンドを使うとエラーになりました。
「Authorization Required」と言われているので認証が必要らしいです。

[admin@ip-10-0-1-10 ~]$ sudo yum search tomcat
Loaded plugins: amazon-id, rhui-lb, security
https://rhui2-cds02.ap-northeast-1.aws.ce.redhat.com/pulp/repos//rhui-client-config/rhel/server/6/x86_64/os/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 – “The requested URL returned error: 401 Authorization Required”
Trying other mirror.
https://rhui2-cds01.ap-northeast-1.aws.ce.redhat.com/pulp/repos//rhui-client-config/rhel/server/6/x86_64/os/repodata/repomd.xml: [Errno 14] PYCURL ERROR 22 – “The requested URL returned error: 401 Authorization Required”
Trying other mirror.
Error: Cannot retrieve repository metadata (repomd.xml) for repository: rhui-ap-northeast-1-client-config-server-6. Please verify its path and try again

作成フローが違うと何が変わってくるのか。

原因

メタデータが抜けるのが原因とのことなのでメタデータを確認してみます。
最初にたてたインスタンスと比較すると「billingProducts」の値が「null」になっていました。

スナップショット→AMI→インスタンスで作成した場合のメタデータ

[admin@ip-10-0-1-10 ~]$curl http://169.254.169.254/latest/dynamic/instance-identity/document
{
  "devpayProductCodes" : null,
  "marketplaceProductCodes" : null,
  "privateIp" : "10.0.1.10",
  "version" : "2017-09-30",
  "instanceId" : "i-01cfe26787cd7538f",
  "billingProducts" : [ "null" ],
  "instanceType" : "t2.micro",
  "availabilityZone" : "ap-northeast-1d",
  "kernelId" : null,
  "ramdiskId" : null,
  "accountId" : "554447165874",
  "architecture" : "x86_64",
  "imageId" : "ami-6b0d5f0d",
  "pendingTime" : "2018-08-11T05:28:17Z",
  "region" : "ap-northeast-1"
通常のRHELインスタンスのメタデータ(billingProducts抜粋)
"billingProducts" : [ "bp-6fa54006" ]

billingProductsとは

ライセンス情報(請求コード?)がここに入ります。
スナップショットからAMIを作成するとライセンス情報が保持されないため、起動後のパッケージ更新等が
出来なります。

対策

AMIの作成には以下の二通りがありますが、EC2から直接AMIを作成することで今回の事象を回避することができるそうです。
- EC2から直接AMIを作成する
- スナップショットからAMIを作成する

公式でもスナップショットから手動でAMIを作成することは勧めていませんとありました→AMI作成について
ライセンス周りの話なので他の商用のディストリビューションでも同様の事象が起こりそうですね。

参考

以下のリンクを参考にさせていただきました。