Oracle Cloud上の古いOracle Linux 7インスタンスのyum設定を更新する

「Notices: General Notices for Oracle Linux Images」というページに「2021.03 – Yum Update for Oracle Linux 7 and Oracle Linux 8 Instances」というのを発見した。

たしかに2021年3月より前に作成したインスタンス Oracle-Linux-7.7-2019.08.28-0, Oracle-Autonomous-Linux-7.8-2020.05-0 には oci-linux-config というパッケージはインストールされていなかった。

$ rpm -qa|grep oci-linux-config
$

とりあえず、ここに書いてある手順通りに進めていく

$ curl -H "Authorization:Bearer Oracle" -sfm 25 http://169.254.169.254/opc/v2/instance/ 2>/dev/null | jq -r '.regionInfo.realmKey'
oc1
$

上記では「oc1」という結果が出力されているが、「oc1」~「oc4」ならOKとのこと。

oci-linux-config パッケージをインストール

$ sudo yum -y install oci-linux-config
読み込んだプラグイン:langpacks, ulninfo
依存性の解決をしています
--> トランザクションの確認を実行しています。
---> パッケージ oci-linux-config.noarch 0:1.0-3.el7 を インストール
--> 依存性解決を終了しました。

依存性を解決しました

================================================================================
 Package               アーキテクチャー
                                   バージョン      リポジトリー            容量
================================================================================
インストール中:
 oci-linux-config      noarch      1.0-3.el7       ol7_ociyum_config       13 k

トランザクションの要約
================================================================================
インストール  1 パッケージ

総ダウンロード容量: 13 k
インストール容量: 29 k
Downloading packages:
oci-linux-config-1.0-3.el7.noarch.rpm                      |  13 kB   00:00
Running transaction check
Running transaction test
Transaction test succeeded
Running transaction
  インストール中          : oci-linux-config-1.0-3.el7.noarch               1/1
IMPORTANT: PLEASE NOTE!!  Oracle Linux yum repository configurations have been updated. New repository configuration files have been installed but are disabled.  To complete the transition, run this script as root user:

/usr/lib/oci-linux-config/oci_yum_configure.sh

  検証中                  : oci-linux-config-1.0-3.el7.noarch               1/1

インストール:
  oci-linux-config.noarch 0:1.0-3.el7

完了しました!
$

/usr/lib/oci-linux-config/oci_yum_configure.sh を実行して /etc/yum.repos.d/ のレポジトリファイルを作成

$ ls -l /etc/yum.repos.d/
合計 84
-rw-r--r--. 1 root root  488  2月 17 06:40 ksplice-ol7.repo
-rw-r--r--. 1 root root  273  5月 13 15:39 oracle-epel-ol7.repo
-rw-r--r--. 1 root root  242  8月 15  2019 oracle-epel-ol7.repo.20190815
-rw-r--r--. 1 root root  252  5月 13 15:38 oracle-epel-ol7.repo.20210217
-rw-r--r--. 1 root root 4322  6月 11 04:12 oracle-linux-ol7.repo
-rw-r--r--. 1 root root 3825  7月 10  2020 oracle-linux-ol7.repo.20200710
-rw-r--r--. 1 root root 4586  6月  9 12:57 oracle-linux-ol7.repo.rpmnew
-rw-r--r--. 1 root root 1067  2月 26 04:35 oracle-php-ol7.repo
-rw-r--r--. 1 root root  797  4月  6  2020 oracle-php-ol7.repo.20200406
-rw-r--r--. 1 root root  275  8月 15  2019 oracle-softwarecollection-ol7.repo
-rw-r--r--. 1 root root  276  2月 17 06:38 oracle-softwarecollection-ol7.repo.rpmnew
-rw-r--r--. 1 root root 1041  2月  5 04:15 oraclelinux-developer-ol7.repo
-rw-r--r--. 1 root root  802 12月 27  2019 oraclelinux-developer-ol7.repo.20200406
-rw-r--r--. 1 root root 3117  9月 30  2019 public-yum-ol7.repo.sav
-rw-r--r--. 1 root root 2577  5月 28  2020 uek-ol7.repo
-rw-r--r--. 1 root root 2108  4月  6  2020 uek-ol7.repo.20200406
-rw-r--r--. 1 root root 2587  2月 17 06:42 uek-ol7.repo.rpmnew
-rw-r--r--. 1 root root  225  5月 28  2020 virt-ol7.repo
-rw-r--r--. 1 root root  226  2月 17 06:42 virt-ol7.repo.rpmnew
$ sudo /usr/lib/oci-linux-config/oci_yum_configure.sh
読み込んだプラグイン:langpacks, ulninfo
No packages marked for update
Disabling Repository ol7_UEKR6
Repository ol7_developer already enabled
Repository ol7_developer_EPEL already enabled
Repository ol7_developer_php74 already enabled
Repository ol7_ksplice already enabled
Repository ol7_latest already enabled
Repository ol7_software_collections already enabled
Enabling Repository ol7_UEKR5
Enabling Repository ol7_addons
Repository ol7_developer already enabled
Repository ol7_developer_EPEL already enabled
Repository ol7_developer_php74 already enabled
Repository ol7_ksplice already enabled
Repository ol7_latest already enabled
Enabling Repository ol7_ociyum_config
Enabling Repository ol7_optional_latest
Repository ol7_software_collections already enabled
$ ls -l /etc/yum.repos.d/
合計 104
-rw-r--r--. 1 root root  488  2月 17 06:40 ksplice-ol7.repo
-rw-r--r--. 1 root root  273  5月 13 15:39 oracle-epel-ol7.repo
-rw-r--r--. 1 root root  242  8月 15  2019 oracle-epel-ol7.repo.20190815
-rw-r--r--. 1 root root  252  5月 13 15:38 oracle-epel-ol7.repo.20210217
-rw-r--r--. 1 root root 4586  6月 16 10:15 oracle-linux-ol7.repo
-rw-r--r--. 1 root root 3825  7月 10  2020 oracle-linux-ol7.repo.20200710
-rw-r--r--. 1 root root 4322  6月 11 04:12 oracle-linux-ol7.repo.bkp
-rw-r--r--. 1 root root 4586  6月  9 12:57 oracle-linux-ol7.repo.rpmnew.bkp
-rw-r--r--. 1 root root 1067  2月 26 04:35 oracle-php-ol7.repo
-rw-r--r--. 1 root root  797  4月  6  2020 oracle-php-ol7.repo.20200406
-rw-r--r--. 1 root root  276  2月 17 06:38 oracle-softwarecollection-ol7.repo
-rw-r--r--. 1 root root  275  8月 15  2019 oracle-softwarecollection-ol7.repo.bkp
-rw-r--r--. 1 root root  276  2月 17 06:38 oracle-softwarecollection-ol7.repo.rpmnew.bkp
-rw-r--r--. 1 root root 1041  2月  5 04:15 oraclelinux-developer-ol7.repo
-rw-r--r--. 1 root root  802 12月 27  2019 oraclelinux-developer-ol7.repo.20200406
-rw-r--r--. 1 root root 3117  9月 30  2019 public-yum-ol7.repo.sav
-rw-r--r--. 1 root root 2587  6月 16 10:15 uek-ol7.repo
-rw-r--r--. 1 root root 2108  4月  6  2020 uek-ol7.repo.20200406
-rw-r--r--. 1 root root 2577  5月 28  2020 uek-ol7.repo.bkp
-rw-r--r--. 1 root root 2587  2月 17 06:42 uek-ol7.repo.rpmnew.bkp
-rw-r--r--. 1 root root  226  2月 17 06:42 virt-ol7.repo
-rw-r--r--. 1 root root  225  5月 28  2020 virt-ol7.repo.bkp
-rw-r--r--. 1 root root  226  2月 17 06:42 virt-ol7.repo.rpmnew.bkp
$

以前のrepoファイルは全て bkpという名前にリネームされて置き換わった感じですね。

各レポジトリファイルの変更点は「baseurl=https://yum$ociregion.oracle.com/repo/OracleLinux/」という記載だったものが「baseurl=https://yum$ociregion.$ocidomain/repo/OracleLinux/」というように「oracle.com」以外のドメインが設定される可能性に配慮したものに変更されていた。

この$ociregionや$ocidomainはどこで設定されているかというと /etc/yum/vars/ にあるファイルで定義されています。

$ ls -l /etc/yum/vars/
合計 12
-rw-r--r--. 1 root root 11  6月 16 10:15 ocidomain
-rw-r--r--. 1 root root 14  6月 16 10:15 ociregion
-rw-r--r--. 1 root root 13  6月 16 10:15 region
$ cat /etc/yum/vars/ocidomain
oracle.com
$ cat /etc/yum/vars/ociregion
-us-phoenix-1
$ cat /etc/yum/vars/region
us-phoenix-1
$

Oracle Cloud上のLinuxインスタンスでiscsistartというサービスが起動失敗している

Oracle Cloud上Linuxインスタンスでol-consolebaud.serviceの起動に失敗している」の件で、これまでに作ったインスタンスの状態を確認していったところ、一番古いLinuxインスタンスでは「iscsistart_169.254.0.2:::1:iqn.2015\http://x2d02.oracle.boot:uefi.service」というサービスの起動に失敗していた。

ぐぐるとOracleサポートの「OCI: iscsistart attempts to connect iscsi target when the network link is not ready (Doc ID 2610486.1)」が出てくるがサポートがないので内容がわからない。

とりあえず、起動失敗しているものと起動成功しているものの/etc/default/grubを比較してみたところ、起動成功しているもののGRUB_CMDLINE_LINUX行には「rd.iscsi.bypass」が追加されていた。

GRUB_CMDLINE_LINUX行に追加して「grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg」を実行してgrub設定を更新、再起動して、問題無く起動するようになった。


確認したOracle Linuxインスタンスの /etc/default/grub設定の比較

Oracle-Linux-7.7-2019.08.28-0 の /etc/default/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_DISABLE_RECOVERY="true"
GRUB_TERMINAL="console"
GRUB_CMDLINE_LINUX="crashkernel=auto LANG=en_US.UTF-8 console=tty0 console=ttyS0,9600 rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 netroot=iscsi:169.254.0.2:::1:iqn.2015-02.oracle.boot:uefi iscsi_param=node.session.timeo.replacement_timeout=6000 net.ifnames=1 nvme_core.shutdown_timeout=10 ipmi_si.tryacpi=0 ipmi_si.trydmi=0 ipmi_si.trydefaults=0 libiscsi.debug_libiscsi_eh=1 loglevel=4"

CentOS-7-2020.06.16-0 の /etc/default/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_DISABLE_RECOVERY="true"
GRUB_TERMINAL="console"
GRUB_CMDLINE_LINUX="crashkernel=auto LANG=en_US.UTF-8 transparent_hugepage=never console=tty0 console=ttyS0,9600 libiscsi.debug_libiscsi_eh=1 rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 ip=dhcp netroot=iscsi:169.254.0.2::::iqn.2015-02.oracle.boot:uefi iscsi_param=node.session.timeo.replacement_timeout=6000 net.ifnames=1 rd.iscsi.bypass"

Oracle-Autonomous-Linux-7.8-2020.05-0 の /etc/default/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_DISABLE_RECOVERY="true"
GRUB_TERMINAL="console"
GRUB_CMDLINE_LINUX="crashkernel=auto LANG=en_US.UTF-8 console=tty0 console=ttyS0,9600 rd.luks=0 rd.lvm=0 rd.md=0 rd.dm=0 rd.iscsi.bypass=1 netroot=iscsi:169.254.0.2:::1:iqn.2015-02.oracle.boot:uefi iscsi_param=node.session.timeo.replacement_timeout=6000 net.ifnames=1 nvme_core.shutdown_timeout=10 ipmi_si.tryacpi=0 ipmi_si.trydmi=0 ipmi_si.trydefaults=0 libiscsi.debug_libiscsi_eh=1 loglevel=4"

Oracle-Linux-8.3-2021.05.12-0 の /etc/default/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
GRUB_TERMINAL="console"
GRUB_CMDLINE_LINUX="crashkernel=auto LANG=en_US.UTF-8 console=tty0 console=ttyS0,9600 rd.luks=0 rd.md=0 rd.dm=0 rd.lvm.vg=ocivolume rd.lvm.lv=ocivolume/root rd.net.timeout.carrier=5 netroot=iscsi:169.254.0.2:::1:iqn.2015-02.oracle.boot:uefi rd.iscsi.param=node.session.timeo.replacement_timeout=6000 net.ifnames=1 nvme_core.shutdown_timeout=10 ipmi_si.tryacpi=0 ipmi_si.trydmi=0 libiscsi.debug_libiscsi_eh=1 loglevel=4 ip=single-dhcp crash_kexec_post_notifiers"

Oracle-Linux-8.3-aarch64-2021.05.12-0 の /etc/default/grub

GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR="$(sed 's, release .*$,,g' /etc/system-release)"
GRUB_DEFAULT=saved
GRUB_DISABLE_SUBMENU=true
GRUB_DISABLE_RECOVERY="true"
GRUB_ENABLE_BLSCFG=true
GRUB_TERMINAL="console"
GRUB_CMDLINE_LINUX="crashkernel=auto LANG=en_US.UTF-8 console=ttyAMA1 console=ttyAMA0,115200 rd.luks=0 rd.md=0 rd.dm=0 rd.lvm.vg=ocivolume rd.lvm.lv=ocivolume/root rd.net.timeout.carrier=5 netroot=iscsi:169.254.0.2:::1:iqn.2015-02.oracle.boot:uefi rd.iscsi.param=node.session.timeo.replacement_timeout=6000 net.ifnames=1 nvme_core.shutdown_timeout=10 ipmi_si.tryacpi=0 ipmi_si.trydmi=0 libiscsi.debug_libiscsi_eh=1 loglevel=4 ip=single-dhcp crash_kexec_post_notifiers"

Oracle Cloud上Linuxインスタンスでol-consolebaud.serviceの起動に失敗している

2020年にOracle Cloud上に作ったLinuxインスタンスの状態を「systemctl status」で確認してみたら、ol-consolebaud.serviceの起動に失敗していた。

画像
ol-consolebaud.service: main process exited, code=exited, status=1/FAILURE
Failed to start Check console baud rate.
Unit ol-consolebaud.service entered failed state.
ol-consolebaud.service failed.

検索してみるとRogerio Eguchi Blog の「OCI – ol-consolebaud.service」を発見。

/etc/default/grub に書かれているシリアルコンソール設定の速度が9600から115200に変更になったことが原因のようである。

Oracle Cloud Infrastructure ドキュメントを確認すると「インポートされたLinuxイメージでのシリアル・コンソール・アクセスの有効化」のブートローダの構成で設定している速度が115200になっている。そして、”シリアルコンソールアクセスの検証”では9600になっていてドキュメントの整合性がとれていない・・・というわけで、途中で変更されたようなのだが、All Oracle Linux 7.x Images の履歴をみたけど、それっぽい変更が見当たらない・・・うーん?

まあ、ともかく原因は判明したのでGRUB_CMDLINE_LINUX行の「console=ttyS0,9600」を「console=ttyS0,115200」に変更。

そして、 「grub2-mkconfig -o /boot/efi/EFI/redhat/grub.cfg」でgrubブートローダに変更を反映して、再起動。

これでol-consolebaudが正常に起動するようになった。

ESXi 7.0 Update 1からSDカード/USBメモリ起動の場合に書き込み回数性能が重要になった件について

2023/05/15追記:「SD card/USB boot device revised guidance (85685)」の2023年2月更新版ではvSphere 8環境での取り扱いについて明記されている。

対処方法1: 普通のローカルディスク起動に変更
対処方法2: SD/USBからブートするが、別途データ保存用ローカルディスクを用意
対処方法3: ESXiをSANのディスクから直接ブートする
対処方法4: SD/USBからブートして、VMFS領域にデータを置く設定
対処方法5: SD/USBからブートして、RAMDISK上にデータを置く設定(再起動すると消える)

基本的にはローカルディスクを使え、という話のようです。


2022/08/05追記:「SD card/USB boot device revised guidance (85685)」にてvSphereの新バージョン(7.0の次)ではSDカード/USBメモリはブートの起点としてしか使えなくなり、別途何らかのストレージにOSDATAを配置する必要がある、ということになる。(新バージョンではRAMDISKは非推奨)


VMware vSphere / ESXi 7.0 から ESXiのブートディスクの構造が変更になった。

VMware vSphere Blog「vSphere 7 – ESXi System Storage Changes
「ESXi のシステム ストレージの概要」の「ESXi 7.0 のシステム ストレージの変更

ESXi 6.0時代 /scratch となっているパーテーションとかあるが、基本的に起動したあとデータ書き込みはあまりないかたちで運用されていた。

ところがESXi 7.0からは細かく分かれていたパーテーションがESX-OSDataパーテーションに統合されている。しかも、ここに書き込みが行われるようになった。

そして、ESXi 7.0 Update 1 / Update 2においてSDカード / USBメモリへの書き込み手法が変更され、起動ディスクに対して従来と比較すると多量の書き込み操作が実行されることになった。

これにより、ESXi 7.0 Update 1 / Update 2において、SDカード/USBメモリ起動にしている場合に、書き換え回数超過によるSDカード/USBメモリのアクセス不可事例が発生しやすくなっているようだ。

VMware KB VMFS-L Locker partition corruption on SD cards in ESXi 7.0 (83376)
VMware Technolopy Network「SD Boot issue Solution in 7.x

上記KB83376を見ると、ESXi 7.0(初期)ではI/O抑制機能があったが、ESXi 7.0 Update 1ではなくなったことが発生しやすくなった要因の1つであるようだ。

しかも、VMware的には「ESXi のシステム ストレージの概要」で、「ESX-OSData は 高耐久性ストレージ デバイス上に作成する必要があります。」と書いてあるから、書き換え回数上限が低いものを使わないのは当然でしょ、というスタンスな模様。

OEMメーカが選定したSDカードなどが死んだとしても、それはその部材を選んだOEMメーカ側の責任だということらしい。

実際、DELLの「VMware vSphere 7.x on Dell EMC PowerEdge Servers Getting Started Guide」の「Getting started with VMware vSphere」をみると、ESXi 7.0ではSDカードは推奨しない、と書いてある。

NOTE: If you had ordered VMware ESXi with your Dell EMC PowerEdge server, it is preinstalled on your server. The ESXi installer media is required for reinstallation. The Boot Optimized Storage Solution (BOSS) card is the preferred non-HDD or SSD device for VMware ESXi 7.0 installation. The Dell Internal Dual SD Module (IDSDM) install is no longer recommended due to write endurance issues with the SD flash media. For more information, see the Storage Requirements for ESXi 7.0 Installation or Upgrade section on the VMware ESXi Installation and Setup Guide or see VMware Knowledge Base article 2145210.

さて、この問題について、とることができる方策は下記の5つが考えられる。

その1) 高耐久性のものに変更する(USB接続のSSDや、MLCチップのSDカードなど)
その2) 普通のSSDやHDD起動に変更する
その3) ESXi 7.0 Update 2用の現象低減パッチが7月中にリリース予定(ただし、低減、である)
      → 2021/08/24リリースのESXi 7.0 U2cで提供開始
その4) メインメモリを消費してRamdiskを作成し、そこに書き込ませる
その5) あきらめて、壊れたら交換&ESXi再セットアップ

その4の手法はVMware KB83376 内にリンクがあり「High frequency of read operations on VMware Tools image may cause SD card corruption (2149257)」で説明されている。

ドキュメント的にはESXi 6.0 と ESXi 6.5用になっているが、ESXi 7.0でも適用できるようだ。

ESXi 7.0のshellに入って、現在の /UserVars/ToolsRamdisk の設定を確認

# esxcli system settings advanced list -o /UserVars/ToolsRamdisk
   Path: /UserVars/ToolsRamdisk
   Type: integer
   Int Value: 0
   Default Int Value: 0
   Min Value: 0
   Max Value: 1
   String Value:
   Default String Value:
   Valid Characters:
   Description: Use VMware Tools repository from /tools ramdisk.
#

「Int Value: 0」ということなので、現在は「0」となっている。

これを1に変更するため、以下を実行する

# esxcli system settings advanced set -o /UserVars/ToolsRamdisk -i 1
#

変更が反映されたか確認

# esxcli system settings advanced list -o /UserVars/ToolsRamdisk
   Path: /UserVars/ToolsRamdisk
   Type: integer
   Int Value: 1
   Default Int Value: 0
   Min Value: 0
   Max Value: 1
   String Value:
   Default String Value:
   Valid Characters:
   Description: Use VMware Tools repository from /tools ramdisk.
#

「Int Value: 1」となっていたら変更されている。

この後、ESXi を再起動して、RAMディスクを実際に稼働させる。

ESXi設定のバックアップ&リストア

SDカード/USBメモリが壊れることを許容する場合、ESXiの設定ファイルをバックアップしておき、再セットアップ時にリストアする、という手法が考えられる。

手法はVMware KB「ESXi ホストの構成のバックアップ方法 (2042141)

リストアの際、ESXiにIPアドレスを割り当てておく必要がある。


具体的にどれくらいの書き込み要求があるんだろう?と調べて見た。

DELL PartnerSEつぶやきブログ「BOSSってなんだろう?」から、ESXiが要求するSSD/Flashデバイスに対する要求要件が書かれた「vSphere SSD and Flash Device Support (2145210)」を発見

それによると下記のようになっている。

Table 1: SSD/Flash Endurance Requirements 

SSD/Flash Device Use CaseJEDEC Endurance RequirementWorkload CharectizationNotes
Host Swap Cache365 TBW or betterRandom, infrequent writesHost memory rarely overcommitted
3650 TBW or betterRandom, frequent writesHost memory routinely overcommitted
Regular Datastore3650 TBW or better1Virtual Machine workload dependentSize >= 1TB needs more endurance
vSphere Flash Read Cache (VFlash)365 TBW or betterVirtual Machine workload dependentSize <= 4TB
ESXi Boot Device0.5 TBW minimum2
2 TBW recommended2,6
Sequential (WAF <10)Size >= 4GB3
ESXi Coredump Device0.1 TBW minimum2,4Extremely sequential (WAF ~1)Size >= 4GB3,4
ESXi Logging Device64 TBW (dedicated device)
128 TBW (colocated) 2,5
Sequential7
(WAF < 100 block mode, WAF < 10 page mode)
Size >= 4GB2,3

ESXi起動デバイスとしては2TBWぐらいだったものが、ログデバイスとしての128TBWぐらいが要求され、USBメモリ上を仮想マシンを置く用のVMFSデータストアとしての使うとなると3650TBWが要求される、などと、起動ディスクとして使うだけの場合より50倍以上の要求がある、ということがわかった。

そりゃ、あっさり死にますね


2022/05/06追記

ESXi 7.0U1 では /UserVars/ToolsRamdisk という変数自体がない。

ESXi 7.0U3 だと /UserVars/ToolsRamdisk はあり、システムのインストール先が HDD か SDカードかによって、「Default Int Value」の値が異なっていた。

HDDでは「0」で、SDカードだと「1」となっていた。

このため、手動で変更する必要性は薄いようだ。(SDカードなら必ず”1″となるかは、ドキュメント上に特に記載されていないため、確認を行うこと)


2022/07/21追記

VMware KBに「SD card/USB boot device revised guidance (85685)」という記事が登場

SDカードやUSBメモリからの起動は可能であるものの推奨しないこととなった。

NVMeやSSDから起動しろ、とのこと。

SDカードやUSBメモリから起動した場合でも、OSDATAパーテーションを別のHDDなどに設定する、ということが推奨される。

ESXi 7.xまではRAMDISKで回避することもできるが、次のESXiではその設定はなくなる、とのこと

Oracle Cloud上のインスタンスから管理メールを送信する手法

Oracle Cloud上に作成したインスタンスのうち、Oracle Autonomouse Linux 7インスタンスだと適切に設定している場合、yum-cronなどが実行された際に 送信者 noreply@notification.~.oci.oraclecloud.com でメールを送信する設定になっている。

Oralce Linux 8インスタンスだとそのような設定にはなっていない。

似たような形でインスタンスのrootから送信されるメールを noreply@notification.~.oci.oraclecloud.com で発信する方法があるかを確認した。

参考ドキュメント
Oracle Cloud Infrastructureドキュメント「電子メール配信の開始
Oracle Cloud Infrastructureドキュメント「Postfixと電子メール配信の統合

しかし、「電子メール配信」については有料アカウントが必要になるようだ。

Oracle Autonomouse Linux 7インスタンスが利用しているのは「通知」の方になっている

このサブスクリプション設定が流用できればいいんですけど・・・

Oracle Cloud : 通知サービスとoci-cliを使って一時間ごとにDBCSの状態を通知する

この情報が使えそうです。

今回の環境ではすでに[開発者サービス]-[アプリケーション統合]-[通知]に

すでにAutonomouse Linux用で作成したトピックが作成されているため、それを流用します。

上記の「AL_notification」のトピックOCIDを使用してコマンドを実行・・・

$ oci ons message publish --topic-id ocid1.onstopic.oc1.ap-tokyo-1.<略> --title "test mail" --body "test mail"
-bash: oci: command not found
$

oci-utilsのパッケージがアップデートされていないとエラーになります。その場合はアップデートします。

2024/10/15: いまは python39-oci-cli か python36-oci-cli にociコマンドが含まれているようなので、 oci-utils と python3?-oci-cli をインストールします。

$ sudo dnf update oci-utils -y
Last metadata expiration check: 4:26:16 ago on Tue 08 Jun 2021 01:30:06 PM JST.
Dependencies resolved.
================================================================================
 Package                  Arch     Version            Repository           Size
================================================================================
Upgrading:
 oci-utils                noarch   0.12.4-1.el8       ol8_oci_included    245 k
Installing dependencies:
 python3-arrow            noarch   0.17.0-1.0.1.el8   ol8_oci_included    101 k
 python3-click            noarch   6.7-8.el8          ol8_appstream       131 k
 python3-convertdate      noarch   2.3.0-1.0.1.el8    ol8_oci_included     83 k
 python3-dateparser       noarch   1.0.0-1.0.1.el8    ol8_oci_included    392 k
 python3-hijri-converter  noarch   2.1.1-1.0.1.el8    ol8_oci_included     30 k
 python3-jmespath         noarch   0.10.0-1.el8       ol8_oci_included     48 k
 python3-pymeeus          noarch   0.3.6-2.0.1.el8    ol8_oci_included    1.1 M
 python3-regex            aarch64  2021.4.4-1.el8     ol8_developer_EPEL  328 k
 python3-retrying         noarch   1.3.3-1.0.1.el8    ol8_oci_included     22 k
 python3-terminaltables   noarch   3.1.0-1.0.1.el8    ol8_oci_included     31 k
 python3-tzlocal          noarch   2.0.0-4.el8        ol8_oci_included     37 k
 python36-oci-cli         noarch   2.22.1-1.el8       ol8_oci_included    6.4 M

Transaction Summary
================================================================================
Install  12 Packages
Upgrade   1 Package

Total download size: 8.9 M
<略>
$

$ oci ons message publish --topic-id ocid1.onstopic.oc1.ap-tokyo-1.<略> --title "test mail" --body "test mail"
ERROR: Could not find config file at /home/opc/.oci/config, please follow the instructions in the link to setup the config file https://docs.cloud.oracle.com/en-us/iaas/Content/API/Concepts/sdkconfig.htm
$

ociコマンドに必要な諸設定を行っていないのでエラーになりました。

まず、キーを作成します。なお、passphraseは何も入力せずエンターキーのみにします(そうしないとスクリプト実行の時にpassphraseを要求される)

$ oci setup keys
Enter a passphrase for your private key (empty for no passphrase):
Public key written to: /home/opc/.oci/oci_api_key_public.pem
Private key written to: /home/opc/.oci/oci_api_key.pem
Public key fingerprint: xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx


    If you haven't already uploaded your API Signing public key through the
    console, follow the instructions on the page linked below in the section
    'How to upload the public key':

        https://docs.cloud.oracle.com/Content/API/Concepts/apisigningkey.htm#How2

$  ls -al ~/.oci
total 8
drwx------. 2 opc opc   59 Jun  7 17:32 .
drwx------. 5 opc opc  138 Jun  7 17:32 ..
-rw-------. 1 opc opc 1679 Jun  7 17:32 oci_api_key.pem
-rw-------. 1 opc opc  451 Jun  7 17:32 oci_api_key_public.pem
$

作成された oci_api_key_public.pem の内容を[アイデンティティとセキュリティ]-[アイデンティティ]-[ユーザー]に登録されている各ユーザから、使用するユーザを選択し[リソース]-[APIキー]に登録します。

なお、APIキーは無料アカウントでは3つまで登録可能で、それ以上は登録できませんでした。
使ってないものを消すには面倒くさいですが、各ユーザの~/.oci/oci_api_key.pem のフィンガープリントを計算して、登録されているものを比較する必要があります。

フィンガープリントの計算手法はOracle Cloudドキュメント「キーのフィンガープリントの取得方法」にあるように「openssl rsa -pubout -outform DER -in ~/.oci/oci_api_key.pem | openssl md5 -c」で実施出来ます。

つぎに~/.oci/config ファイル作成のために

[ガバナンスと管理]-[アカウント管理]-[テナンシ詳細]にて、テナントのOCIDを取得

また、ユーザのOCIDと先ほど登録したAPIキーのフィンガープリントを configファイルに記載する。

$ cat ~/.oci/config
[DEFAULT]
key_file=/home/opc/.oci/oci_api_key.pem
region=ap-tokyo-1
tenancy=ocid1.tenancy.oc1..aaaaaaaa7lml<略>
user=ocid1.user.oc1..aaaaaaaamenibh4iny<略>
fingerprint=<略>
$

記載してociコマンドを再実行

$ oci ons message publish --topic-id ocid1.onstopic.oc1.ap-tokyo-1.aa<略> --title "test mail" --body "test mail"
WARNING: Permissions on /home/opc/.oci/config are too open.
To fix this please try executing the following command:
oci setup repair-file-permissions --file /home/opc/.oci/config
Alternatively to hide this warning, you may set the environment variable, OCI_CLI_SUPPRESS_FILE_PERMISSIONS_WARNING:
export OCI_CLI_SUPPRESS_FILE_PERMISSIONS_WARNING=True

{
  "data": {
    "message-id": "56ca7636-1605-7a19-5344-<略>",
    "time-stamp": null
  }
}
$

まず、「WARNING: Permissions on /home/opc/.oci/config are too open.」についてはパーミッション問題なので、書いてある通りに対処する。

$ ls -l /home/opc/.oci/config
-rw-rw-rw-. 1 opc opc 299 Jun  7 17:43 /home/opc/.oci/config
$ oci setup repair-file-permissions --file /home/opc/.oci/config
$ ls -l /home/opc/.oci/config
-rw-------. 1 opc opc 299 Jun  7 17:43 /home/opc/.oci/config
$

再実行

$ oci ons message publish --topic-id ocid1.onstopic.oc1.ap-tokyo-1.aaaaaaaacesi5<略> --title "test mail" --body "test mail"
{
  "data": {
    "message-id": "c491e672-9401-beb3-16f5-<略>",
    "time-stamp": null
  }
}
$

成功か失敗か分かりづらいですが、成功していました。(WARNING: Permissions の時のやつもメール送信は出来ていました)

というわけで、ociコマンドを使用することで、Oracle Cloudの通知を使ってシステムメールを送信することができそうなことがわかりました。

ociコマンドは https://github.com/oracle/oci-cli にソースがある

つぎに dnf automaticでそれを実行するにはどういう手法が最適化の検討です。

DNF Automatic」には「[command] section」と「[command_email] section」があり、利用できそうです。

違いの詳細については「RHEL8/CentOS8のdnf automaticのemitters設定を調べた」に書きましたが、今回の場合は[command_email]sectionを使うことにします。

dnf automaticではメール本文を標準入力で指定することになっていて、そのままではociコマンドのbodyオプションとして渡すことができません。

なので、Oracle Cloud Infrastructure Document Notifications Publish Messages(日本語版) を起点に調べていったところOracle Cloud Infrastructure Documentation / API Reference and Endpoints の「PublishMessage」にて、REST API/Java SDK/Python SDK/Go SDK/TypeScript SDK/.NET SDK/Ruby SDKを使った場合のコードサンプルを発見。

ociコマンドはpyhonを使っているので、Python SDKのサンプルコードを利用した /usr/local/bin/oci-notification-mail を作って使用します。

topic_id=のところは自分の環境に合わせてください。

$ sudo vi /usr/local/bin/oci-notification-mail
$ cat /usr/local/bin/oci-notification-mail
#!/usr/bin/python3
# This is an automatically generated code sample.
# To make this code sample work in your Oracle Cloud tenancy,
# please replace the values for any parameters whose current values do not fit
# your use case (such as resource IDs, strings containing ‘EXAMPLE’ or ‘unique_id’, and
# boolean, number, and enum parameters with values not fitting your use case).

import oci
import sys

argvs=sys.argv
argc = len(argvs)
subject=argvs[1]
textbody="".join(sys.stdin.readlines())

# Create a default config using DEFAULT profile in default location
# Refer to
# https://docs.cloud.oracle.com/en-us/iaas/Content/API/Concepts/sdkconfig.htm#SDK_and_CLI_Configuration_File
# for more info
config = oci.config.from_file()


# Initialize service client with default config file
ons_client = oci.ons.NotificationDataPlaneClient(config)

# Send the request to service, some parameters are not required, see API
# doc for more info
publish_message_response = ons_client.publish_message(
    topic_id="ocid1.onstopic.oc1.ap-tokyo-1.<略>",
    message_details=oci.ons.models.MessageDetails(
        body=textbody,
        title=subject),
    message_type="RAW_TEXT")

# Get the data from response
print(publish_message_response.data)
$ sudo chmod a+x /usr/local/bin/oci-notification-mail
$

まずこれを作成したあと、送信テストをします。

$ cat /etc/hosts | /usr/local/bin/oci-notification-mail testmail
{
  "message_id": "ef1aa15b-98d0-1824-68ef-<略>",
  "time_stamp": null
}
$

これを実行してしばらく待つと、「Subject:testmail」 で、本文が/etc/hostsの中身になっているメールが届きます。

スクリプトが正常に動作することを確認できたら、ociコマンドがrootユーザでも実行できるように .oci ディレクトリの内容を /root/.oci にコピーします。書かれてるpemファイルのパスなどはそのままでかまいません。注意点は /root/.oci ディレクトリの権限を 700 にしておく、ということです。

最後にdnf automaticの設定を変更します。

変更する場所は2つ

「[emitters] セクション」のemit_via を「emit_via=command_email」に変更

「[command_email]セクション」のcommand_formatを「command_format = “/usr/local/bin/oci-notification-mail {subject}”」、「#stdin_format = “{body}”」を「stdin_format = “{body}”」に変更します。

これにより、dnf automaticでパッチが適用された場合に下記の様なメールが届くようになりました。

おまけ

ちなみに、Oracle Linux 8の標準インスタンスではpostfixやsendmailではなく、esmtp というパッケージでメール送信が行われるようです。

$ ls -l /usr/sbin/sendmail
lrwxrwxrwx. 1 root root 21 May 27 13:04 /usr/sbin/sendmail -> /etc/alternatives/mta
$ ls -l /etc/alternatives/mta
lrwxrwxrwx. 1 root root 22 May 27 13:04 /etc/alternatives/mta -> /usr/bin/esmtp-wrapper
$ ls -l /usr/bin/esmtp-wrapper
-rwxr-xr-x. 1 root root 3374 Jul  2  2020 /usr/bin/esmtp-wrapper
$  rpm -qa|grep smtp
esmtp-1.2-15.el8.aarch64
libesmtp-1.0.6-18.el8.aarch64
$ alternatives --display mta
mta - status is auto.
 link currently points to /usr/bin/esmtp-wrapper
/usr/bin/esmtp-wrapper - priority 30
 slave mta-sendmail: /usr/bin/esmtp-wrapper
 slave mta-sendmailman: /usr/share/man/man1/esmtp.1.gz
 slave mta-mailq: /usr/bin/esmtp-wrapper
 slave mta-mailqman: /usr/share/man/man1/esmtp.1.gz
Current `best' version is /usr/bin/esmtp-wrapper.
$

公式ページに「THIS PROJECT IS NO LONGER BEING MAINTAINED. IF IT DOESN’T WORK FOR YOU SEE THESE LINKS.」って書いてあるのにRHEL/CentOS/Oracle Linux 8で使っているのか・・・