HPE Superdome Flex 280サーバーではLinuxのサポートについて注意が必要(現状RHEL9.0はサポートしない)


2022/12/05追記:2022/11/30にRHEL9.0対応のI/O Service Pack for HPE Superdome Flex Servers Familyがリリースされてました。


HPE Superdome Flex 280サーバーを導入するにあたってLinuxのサポートも必要という話で、RedHat Enterprise Linuxを導入する、という話になった。

ドキュメントを探すと「Installing Operating Systems on HPE Superdome Flex 280 Server」がもっともまとまっている感じだった。

ここの「Supported operating systems」には下記の様に書かれている。

HPE Foundation Software (HFS) version support matrix」を見るとRHEL9.0をサポートしていると読める記述がある。

Software Delivery Repositoryにある「HPE Foundation Software Repository」を見ても指定できるディストリビューションバージョンに9.0が含まれている。

ISOファイルとして入手する場合は「HPE Foundation Software ISO Image for HPE Superdome Flex Servers Family」から入手でき、RHEL9/Oracle Linux 9がサポート対象として記載されている。

上記ページにリンクがある「Running Linux on HPE Superdome Flex 280 Server」は冒頭の「Installing Operating Systems on HPE Superdome Flex 280 Server」を切り出した感じのドキュメントになってようにみえ、特にRHEL9がサポートされない、という認識ではなかった。

しかし!

hpeから、2022年11月2日時点で、HPEがサポートするのはRHEL8.5までで、RHEL8.6とRHEL9.0は現状はサポートしない、との通告を受けた。

なぜ?と聞くと「I/O Service Pack」の対応バージョンが出ていないから、という

確認してみると「Running Linux on HPE Superdome Flex 280 Server」の方には記述がないが、「Installing Operating Systems on HPE Superdome Flex 280 Server」には「HPE Superdome Flex 280 Server I/O Service Pack」という項目がある・・・

しかし、「Customers can use the HPE Superdome Flex 280 Server I/O Service Pack」という表現なので「要求」じゃないはずなのに、要求されている。

ダウンロードリンクは「I/O Service Pack for HPE Superdome Flex Servers Family

firmwareとdriverを新しいものに更新するために使うので、必須ではないはずなのだが、hpeサポートは必須と主張してくる感じです。

じゃあ、RHEL9.0対応版はいつでるの?ときいいてみるものの「不明」という回答。

大丈夫なんか?HPE


2022/11/14追記

RHEL9をサポートするI/O Service Packのリリース見込みがついた、という連絡があったので、とりあえず本件はなんとかなりそう


2022/12/05追記

2022/11/30付けでRHEL8.6とRHEL9.0に対応した「I/O Service Pack for HPE Superdome Flex Servers Family 2022.09」がリリースされていました。

NetApp ONTAPのサポート期間とサポートバージョンの確認


NetApp ONTAPのサポート期間(End of support / EOS)を確認するときにどこを見ればいいか忘れてしまうのでメモ

基本的には 「Software Version Support 」でサポート期間を確認する

ただし、このページ、日本語表示だと情報が古くONTAP 9.9.1までしか掲載されていない(2022/11/02現在) 古い情報のままになっていることがある。

その場合は「English」に変更すると最新情報 ONTAP 9.11.1についても確認出来る。

また、別のページに「SU2: Minimum Recommended ONTAP releases on the NetApp Support Site」という形で各ONTAP OSバージョンでも、最低要求するパッチバージョンの指定、というのがされている。
詳細については→ Active Directoryサーバのセキュリティ強化アップデート(CVE-2022-38023)に伴うONTAPファイルサーバへの影響についてのメモ

2023/09/18付け更新ではONTAP 9.8~9.13.1について下記の様に定義されている。

  • For ONTAP 9.13x, the minimum recommended version is 9.13.1P1.
  • For ONTAP 9.12x, the minimum recommended version is 9.12.1P5.
  • For ONTAP 9.11x, the minimum recommended version is 9.11.1P11.
  • For ONTAP 9.10x, the minimum recommended version is 9.10.1P14.
  • For ONTAP 9.9x, the minimum recommended version is 9.9.1P15.
  • For ONTAP 9.8x, the minimum recommended version is 9.8P18.

なお、2023年7月のWindows UpdateによりActive Directoryサービスのセキュリティ強化が行われた影響で、これらのバージョンより低いとActive Directory連携が動かなくなっているので注意してください。

ちなみに、2022/10/24付け更新で、ONTAP 9.7~9.11.1については下記の様に定義されていた。

  • For ONTAP 9.11x, the minimum recommended version is 9.11.1P3.
  • For ONTAP 9.10x, the minimum recommended version is 9.10.1P8.
  • For ONTAP 9.9x, the minimum recommended version is 9.9.1P12.
  • For ONTAP 9.8x, the minimum recommended version is 9.8P14.
  • For ONTAP 9.7x, the minimum recommended version is 9.7P20.

実はこのページ、したの方が重要で、「Download」のリンク集からアクセスできない古いONTAP OSのパッチがダウンロードできるリンクがある。

Clustered Data ONTAP 8.3.2P12Clustered Data ONTAP 8.2.4P6がダウンロードできる。

7-modeのData ONTAP 8.2.5P5もダウンロードできる。


ONTAPと対象機種についてのメモ

・ONTAP 9.13.1 で追加
FAS2820, ASA A150, ASA A900

・ONTAP 9.12.1 で追加
AFF C250, AFF C400, AFF C800, AFF A150

・ONTAP 9.10.1 で追加
AFF A900

・ONTAP 9.9.1 で削除(非サポート)
FAS80xx, AFF80xx, FAS25xx

・ONTAP 9.8で追加
AFF A250, FAS500f, ASA AFF A800

・ONTAP 9.7で追加
FAS8300, FA8700, AFF A400, ASA AFF A220, ASA AFF A700

・ONTAP 9.6で追加
AFF C190, AFF A320
ディスクシェルフ NS224

・ONTAP 9.5で追加
AFF A300, FAS8200

・ONTAP 9.1で追加
FAS2720, FAS2750, AFF A220, AFF A800

・ONTAP 9.1でサポートしているハードウェア
FAS2600シリーズ, FAS8200, FAS9000, AFF A200, AFF A300, AFF A700, AFF A700s
ディスクシェルフ DS460C, DS224C, DS212C


ONTAPバージョンとsnapmirror互換性

以前はONTAPバージョンが3つ違いまでOK、というような感じだった

2023年9月時点での資料「Compatible ONTAP versions for SnapMirror relationships」(日本語ページは自動翻訳のためいらない場所まで翻訳することがあるため注意)

・Unified Replication(XDP)でのsnapmirrorの場合
ONTAP 9.13.1の対応範囲: ONTAP 9.14.0 ~ ONTAP 9.8
ONTAP 9.12.1の対応範囲: ONTAP 9.14.0 ~ ONTAP 9.7
ONTAP 9.11.1の対応範囲: ONTAP 9.14.0 ~ ONTAP 9.6
ONTAP 9.10.1の対応範囲: ONTAP 9.14.0 ~ ONTAP 9.5
ONTAP 9.9.1の対応範囲: ONTAP 9.14.0 ~ ONTAP 9.5
ONTAP 9.8の対応範囲: ONTAP 9.14.0 ~9.5, 9.3 (9.4は不可)
ONTAP 9.7の対応範囲: ONTAP 9.12.1 ~9.5, 9.3 (9.4は不可)

・SVM情報ごと同期を行うSVM-DRの場合
3バージョンしばりがある

・旧形式(DP)のsnapmirrorの場合
3バージョンしばりがある
また、DP形式は9.11.1までのサポートで、9.12.1では使えない

Sierra Wireless EM7330 のfirmwareまわりのメモ


ジャンク屋で買ったLTEカード EM7330 、firmwareについて気にしていなかったのですが、あったようなのでメモ

EM7330に関するサポートページ

ただ、ユーザ登録が必須っぽい?

・Firmware
AirPrime EM73xx/MC73xx FW Package Build 4837

EM7330は一番下に「Docomo」という列があって「SWI9X15C_05.05.65.00」となっていた。

・Firmware アップデート用ツール
Module Firmware Download Tool (FDT – command line tool for Windows)

・Windows用ドライバ
Windows Drivers for EM/MC Series Modules (Build 5087)

Windows Updateで持ってくるので気にしていなかったのですが、Windows用ドライバが配布されていました。

富士通サイトには 「Sierra Wireless EM7330 WWAN Driver + Firmware Updater」 があり、SWI9X30C_05.05.63.00 になる

NetAppのボリューム上に.copy_offloadという隠しファイル?ディレクトリ?がある


ONTAPで重複排除を行っているボリュームでSMB 3.0によるODXオフロード機能が働くと.copy_offload という隠しファイルがある、というので確認してみた。

まず、NFSで該当ボリュームをマウントしてls -laで見てみる

# ls -la /mnt/shares/
合計 12
drwxrwxrwx. 3 nobody nobody 4096 10月 12 16:05 .
drwxr-xr-x. 4 nobody nobody 4096  9月 12 10:44 ..
-rwxrwxrwx. 1 nobody nobody   12 10月 12 16:05 test.txt
drwxr-xr-x. 2 nobody nobody 4096 10月 12 16:03 testqtree
#

次にNetAppのdiagモードにあるlsコマンドで見てみる

ontap::*> system node run -node ontap-01 -command ls -a /vol/shares
        64 .
        64 ..
        96 testqtree
        97 test.txt
ontap::*>

重複排除が稼働していない状態では .copy_offload は存在していないということを確認した。

次に、CIFS側からtest2というディレクトリを作って、そこに同じファイルを別名でコピーしてしてみた。

NFSでマウントしてみてみる。

# ls -la /mnt/shares/
合計 16
drwxrwxrwx. 5 nobody nobody 4096 10月 12 16:20 .
drwxr-xr-x. 4 nobody nobody 4096  9月 12 10:44 ..
-rwxrwxrwx. 1 nobody nobody   12 10月 12 16:05 test.txt
drwxrwxrwx. 2 nobody nobody 4096 10月 12 16:20 test2
drwxr-xr-x. 2 nobody nobody 4096 10月 12 16:03 testqtree
#

一般的なクライアントアクセスでは存在を確認できない。

では、NetApp内部で確認するとどうなるのか?

ontap::*> system node run -node ontap-01 -command ls -a /vol/shares/
        64 .
        64 ..
        96 testqtree
       101 .copy_offload
        97 test.txt
        98 test2
ontap::*> system node run -node ontap-01 -command ls -al /vol/shares/
d-rwxrwxrwx       1026         64      5             4096       Wed Oct 12 07:20:48 UTC 2022     .  1662947040
d-rwxrwxrwx       1026         64      5             4096       Wed Oct 12 07:20:48 UTC 2022     ..  1662947040
d-rwxr-xr-x       1026         96      2             4096       Wed Oct 12 07:03:49 UTC 2022     testqtree       43900
 ----------          0        101      0                0       Thu Jan  1 00:00:00 UTC 1970     .copy_offload      139686
 arwxrwxrwx       1026         97      1               12       Wed Oct 12 07:05:28 UTC 2022     test.txt       52407
d-rwxrwxrwx       1026         98      2             4096       Wed Oct 12 07:20:54 UTC 2022     test2      136061

ontap::*>

「.copy_offload」というファイルなのかディレクトリなのかよくわからない何かが作成されていることを確認した。

ONTAP 9.9.1では通常のNFS/CIFSアクセスでは認識できないものであるので、通常利用時は特に気にする必要がないものであるようだ。

なお、NFSアクセスで.copy_offloadというファイルが作成できるかを確認してみたところ、作成がエラーとなったが「そのようなファイルやディレクトリはありません(No such file or directory)」という微妙なメッセージでの失敗だった。

# touch /mnt/shares/.copy_offload
touch: '/mnt/shares/.copy_offload' に touch できません: そのようなファイルやディレクトリはありません
# echo test > /mnt/shares/.copy_offload
-bash: /mnt/shares/.copy_offload: そのようなファイルやディレクトリはありません
# echo test > /mnt/shares/.copy_offload2
# ls -l /mnt/shares/.copy_offload*
-rw-r--r--. 1 nobody nobody 5 10月 12 16:45 /mnt/shares/.copy_offload2
# ls -la /mnt/shares/.copy_offload*
-rw-r--r--. 1 nobody nobody 5 10月 12 16:45 /mnt/shares/.copy_offload2
# export LANG=C
# echo test > /mnt/shares/.copy_offload
-bash: /mnt/shares/.copy_offload: No such file or directory
#

閉鎖環境内でアラートメールの送信ができるだけのためのメールサーバ設定(AlmaLinux8/RHEL8/Oracle Linux8)


閉鎖環境で機器初期セットアップを行う際に、アラートメールの送信先を指定する必要があったりする。

その時に、メール送信テストが行えるような簡易的なLinuxサーバを作るためのメモ書きです。

なお、メールの送信先は「root@adosakana.local」としておいて、Linuxユーザのroot宛にメールが届くような設定です。

メールを読むときは /var/mail/root に届くのを直接見るか、mail/mailx/muttコマンドなどで見る想定です。

(1) AlmaLinux / RHEL / Oracle Linux 8の最小インストールを実施

(2) アップデート

「dnf update -y」でパッケージを最新に

(3) SMTPで使用するポート開け

「firewall-cmd –add-service smtp –permanent」で追加

# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources:
  services: cockpit dhcpv6-client ssh
  ports:
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
# firewall-cmd --add-service smtp --permanent
success
# firewall-cmd --reload
success
# firewall-cmd --list-all
public (active)
  target: default
  icmp-block-inversion: no
  interfaces: ens192
  sources:
  services: cockpit dhcpv6-client smtp ssh
  ports:
  protocols:
  forward: no
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:
#

(4) postfixのインストール

「dnf install postfix」でpostfixをインストール

(5) postfixの設定ファイルを編集

まず、テストに使うメールアドレスのドメイン名を「mydomain=~」で定義(myhostname 定義はそのまま使った)

# The mydomain parameter specifies the local internet domain name.
# The default is to use $myhostname minus the first component.
# $mydomain is used as a default value for many other configuration
# parameters.
#
#mydomain = domain.tld
mydomain = adosakana.local

メール送信者にドメイン名指定がない場合に、mydomainで設定した内容を適用するために「myorigin = $mydomain」

# SENDING MAIL
#
# The myorigin parameter specifies the domain that locally-posted
# mail appears to come from. The default is to append $myhostname,
# which is fine for small sites.  If you run a domain with multiple
# machines, you should (1) change this to $mydomain and (2) set up
# a domain-wide alias database that aliases each user to
# user@that.users.mailhost.
#
# For the sake of consistency between sender and recipient addresses,
# myorigin also specifies the default domain name that is appended
# to recipient addresses that have no @domain part.
#
#myorigin = $myhostname
myorigin = $mydomain

どのNICからきたSMTP要求でも受付させるための「inet_interfaces = all」を定義

# RECEIVING MAIL

# The inet_interfaces parameter specifies the network interface
# addresses that this mail system receives mail on.  By default,
# the software claims all active interfaces on the machine. The
# parameter also controls delivery of mail to user@[ip.address].
#
# See also the proxy_interfaces parameter, for network addresses that
# are forwarded to us via a proxy or network address translator.
#
# Note: you need to stop/start Postfix when this parameter changes.
#
inet_interfaces = all
#inet_interfaces = $myhostname
#inet_interfaces = $myhostname, localhost
#inet_interfaces = localhost

受信するメールを決めるために「mydestination =~」を指定。とりあえず全部受け取るような感じの設定にする

# Specify a list of host or domain names, /file/name or type:table
# patterns, separated by commas and/or whitespace. A /file/name
# pattern is replaced by its contents; a type:table is matched when
# a name matches a lookup key (the right-hand side is ignored).
# Continue long lines by starting the next line with whitespace.
#
# See also below, section "REJECTING MAIL FOR UNKNOWN LOCAL USERS".
#
#mydestination = $myhostname, localhost.$mydomain, localhost
mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain
#mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain,
#       mail.$mydomain, www.$mydomain, ftp.$mydomain

メール送信側のSSLプロトコル対応が古い場合を考慮して「smtpd_tls_security_level=none」と暗号化の要求レベルをなしにしておく

# Announce STARTTLS support to remote SMTP clients, but do not require that
# clients use TLS encryption (opportunistic TLS inbound).
#
#smtpd_tls_security_level = may
smtpd_tls_security_level = none

なお、「lost connection after STARTTLS from unknown」という形でSMTP接続を拒否される場合は、おそらく標準値の「smtpd_tls_security_level = may」で設定している場合。(TLS1.2以降を必須、とかそんな感じ)

(6) postfixを起動

「systemctl enable postfix」でOS起動時にpostfixも起動するように設定し、

「systemctl start postfix」でいますぐpostfixを起動させている

# systemctl status postfix
● postfix.service - Postfix Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/postfix.service; disabled; vendor pr>
   Active: inactive (dead)
# systemctl enable postfix
Created symlink /etc/systemd/system/multi-user.target.wants/postfix.service → /usr/lib/systemd/system/postfix.service.
# systemctl status postfix
● postfix.service - Postfix Mail Transport Agent
   Loaded: loaded (/usr/lib/systemd/system/postfix.service; enabled; vendor pre>
   Active: inactive (dead)
# systemctl start postfix
#


おまけ: mutt コマンドでメールを送信しようとしたけど、送れない

とあるプロダクトのアラートメールの送信手法がmuttコマンドを利用していた。

「smtpd_tls_security_level = may」設定のpostfixにメールを送ると「lost connection after STARTTLS from unknown」で送れていなかった。

postfix側ではなく、mutt側で対策取れるかを確認したところ /etc/Muttrc.local などの muttの設定ファイル内で「set ssl_starttls = no」と設定して、STARTTLSの使用を取りやめることでメール送信に成功するようになった。

RHEL8.5サーバから mutt コマンドでメール送信する場合、SSL関連の設定を調べると以下の様なものがある

set ssl_verify_host = no
set ssl_verify_dates = no
set ssl_starttls = yes
set ssl_use_tlsv1_3 = yes
set ssl_use_tlsv1_2 = yes
set ssl_use_tlsv1_1 = yes
set ssl_use_tlsv1 = no
set ssl_use_sslv3 = no
set ssl_use_sslv2 = no

ただ、RHEL8.5で試してみたところ「ssl_use_sslv2」というオプションは存在していなかった。

# echo "test mail"  | mutt -F ~/testmuttrc -s "test mail title" 受信者 -d 10
レベル 10 でデバッグ中。
/root/testmuttrc 中の 14 行目でエラー: ssl_use_sslv2 は不明な変数
source: /root/testmuttrc 中でエラー
#

また、opensslコマンドのs_clientでSSLv2 SSLv3の接続ができるかを試験してみたところ、オプション自体が廃止されていた。

# openssl s_client -connect 172.17.44.50:25 -servername 172.17.44.50 -ssl3
s_client: Option unknown option -ssl3
s_client: Use -help for summary.
# openssl s_client -connect 172.17.44.50:25 -servername 172.17.44.50 -ssl2
s_client: Option unknown option -ssl2
s_client: Use -help for summary.
#