接続がプライベートではありません（2）

Let's Encryptの問題が気になって、
UTMメーカーの記事の原文を見てみた。
日本語への機械翻訳は細かいところが不明確で信用できない。

楽に読めるようになりたい。

Let's Encryptは古いルート証明書が期限切れになった後も、
新しいルート証明書と古いルート証明書の両方へアクセス可能としていて、
どちらにアクセスするかはクライアント依存のようだ。

UTMで問題が発生するのは、ISRG Root X1 rootがまだ有効にもかかわらず
UTMは証明書のチェーンを完全に検証しようとして、
CA IdenTrust DST Root CA X3が無効であることを発見してしまうため。

UTMメーカーは問題となる期限切れの証明書を証明書ストアから削除したけれど
問題は解決しなかった。

アンカーがローカルの証明書ストアに存在しないとき、
UTMはhttp://apps.identrust.com/roots/dstrootcax3.p7cにアクセスして
証明書チェーンを再構築しようとするが、証明書チェーンが不完全なため
再構築に失敗する。

ただし、このURLが利用できない場合、UTMは最初から信頼チェーンを再構築し、ISRC Root X1 Root CA証明書を使用しようとする。

そのためには、UTMからhttp://apps.identrust.comへのアクセスをブロックすればよい。
これを実現するには、DNSブラックホーリングまたはFQDNポリシーを使用して
apps.identrust.comへのアクセスをブロックする。

具体的には、こうしろとコマンドが書いてあるけれど、どうやるんだろう。
これはコンソールに打ち込むコマンドかな？
DNSブラックホーリングって何だろう？
apps.identrust.comのIPは127.0.0.1だよ、
とUTM内のDNSに登録するってこと？

地上波みていたらスクリーンセーバ

2週間程前、実家の母からLINEメッセージが届いた。
「テレビを買ったんだけど、すぐにこんな画面になって困っている」
スクリーンセーバみたいな写真が添付されている。
先週見に行く約束だったんだけど、避難所開設で呼び出されて行けなかった。
今日もまた娘の部活の送り迎えをしないといけないんだけど、
午前中は時間があるので早起きして実家へ行った。
やい、部活動顧問の〇▽！親の送り迎えを前提に練習試合すんな▽※×！

テレビはTOSHIBAのREGZA 43Z570Kだ。
取扱説明書を見たところ、AndroidTVにスクリーンセーバの機能があるようだ。
スクリーンセーバのタイムアウトを最長2時間にできるけれど、
スクリーンセーバをOFFにすることはできない。
AndroidTVの機能なのに地上波を見ているときに起動しないでほしい。

REGZAのサポートサイトに、チャットによるお問い合わせがあった。
ダメ元で試してみよう。
スクリーンセーバをOFFにできないか聞いてみると、
できない、という回答だった。やっぱりそうか。
でも、地上波を見ているときに起動するのは違和感があるので、
これについても確認してみた。
すると、地上波を見ているときには起動しないはず、という答え。
おっと、聞き方変えて良かった！
電源コードを抜いてしばらく放置したら、スクリーンセーバは起動しなくなった。

最近はACアダプタ別売りなの？

各公民館にZoom専用端末を入れることになった。
公民館から庁内LAN経由でweb会議すると帯域が不足するので、
Zoom専用端末だけローカルブレークアウトさせよう。
それならば、フリースポットも整備しようと
バッファローのフリースポット協議会モデルルータFS-M1266を
調達仕様に入れておいた。

落札事業者と導入に向けて打ち合わせをしたところ、ACアダプタが別売りと判明した。
うそでしょー、別途入手しないといけないよ。
バッファローのHPを見ると「※別売りのACアダプター WLE-OP-AC12C が必要です。」と書いてある。
仕様は見たはずなんだけど、見落としたのかな。
ACアダプタの価格を見ると、1個税込み5,280円。
参ったなあ。

接続がプライベートではありません

教委のUTMを入れ替え後、閲覧できなくなったサイトがあると連絡があった。
ブラウザで見てみると、「接続がプライベートではありません」と表示される。
証明書の情報を見ると、発行日は2022年7月16日で、有効期限は切れていない。
ただ、発行者がUTMメーカーの名前になっている。何で？
仮想ブラウザやスマホでは問題なく閲覧できる。
スマホで証明書の情報を見ると、発行者はLet's Encryptだ。
無償の証明書だから何かあるのかな？

検索してみると、Let's Encryptのルート証明書が切り替えられ、
古い証明書は2021年9月30日に期限が切れたようだ。
これが影響しているのかな。
古いルート証明書はIdenTrust DST Root CA X3で、
新しいルート証明書はISRC Root X1 Root CAだそうだ。
ブラウザを見てみると、ISRC Root X1 Root CAはちゃんと入っている。
ということは、UTMで何か対応できていないのだろうか。
ネットで検索すると関係しそうな記事があった。

これによると、2021年5月以降に発行されたLet's Encrypt証明書では、
問題は発生しません、だって。
じゃあ何がいけないんだろう。
まずはUTMの納入事業者に問い合わせてみるか。

hypervisorディスク障害

サーバー室に入ったら、Hyper-Vサーバーのディスクの警告ランプが点灯していた。
GroupSessionとjitsiとFessを動かしているサーバーだ。
GroupSessionが停止すると大騒ぎなので、早急にディスクを交換しなきゃ。
どういう状態なのか確認しようと思ったけれど、
ハイパーバイザーのメニューでは状態を確認できない。
とり急ぎ交換用ディスクの見積もり依頼をかけて、状態確認方法を調べてみた。

■HDDの状態を確認する方法
1.ServerView RAID Manager
2.Ctrl-Rユーティリティ

RAID Managerは富士通のサイトからダウンロードでき、GUIで状態を管理できる。
でも、ハイパーバイザーでは動作しない。GUIがないから当然か。
Ctrl-RユーティリティはRAIDコントローラのBIOSに内蔵している。
入り口はPOST画面なので、サーバーの再起動が必要だ。
再起動かけると2度と起動しない可能性があるので、先にバックアップしなきゃ。

■Ctrl-Rユーティリティを使う前にもう少し情報を収集しよう。
サーバーにはディスクが8本インストールされている。
そのうち5番目のディスクに警告ランプが点灯している。
ディスクのアクセスランプの点灯状況をしばらく監視していたところ、
5番目と7番目以外はアクセスがあるようだ。
7番目にアクセスがないということは、
7番目と8番目をホットスペアにしていたのかもしれない。

ディスクの情報を見てみよう。
コマンドプロンプトからpowershellを起動する
C:\> powershell
物理ディスクの情報を表示する
PS > Get-WmiObject Win32_DiskDrive
    Partitions : 1
    DeviceID   : \\.\PHYSICALDRIVE1
    Model      : FTS PRAID EP400i SCSI Disk Device
    Size       : 1199163571200
    Caption    : FTS PRAID EP400i SCSI Disk Device
    
    Partitions : 3
    DeviceID   : \\.\PHYSICALDRIVE0
    Model      : FTS PRAID EP400i SCSI Disk Device
    Size       : 599581785600
    Caption    : FTS PRAID EP400i SCSI Disk Device
RAIDで2つのディスクを構築してあるようだ。
Partition1は1.2TBなので多分600GBのディスク4本でRAID10
Patrition3は600GBなので多分600GBのディスク2本でRAID1

ボリュームの情報を見てみよう
PS > Get-Volume
    DriveLetter FileSystemType DriveType SizeRemaining Size
    ----------- -------------- --------- ------------- ----
    F           NTFS           Fixed         770.63 GB   1.09 TB
    E           NTFS           Fixed          237.4 GB 358.41 GB
                NTFS           Fixed         515.35 MB    549 MB
    C           NTFS           Fixed         182.59 GB 199.46 GB
サイズから推測すると、こうなる。
物理ディスクのPartition3に、CとEドライブ
物理ディスクのPartition1に、Fドライブ

■構成の推測
8本の600GBのHDDを使って次のように構成してあると思う。
HDD1と2　RAID1にしてCドライブとEドライブを作成。
　　　　　CドライブにHyper-V 2019 hypervisorをインストール。
　　　　　Eドライブは作業用の領域。Fessの少し古い仮想マシンがある。
HDD3～6　RAID10にしてFドライブを作成。ここに仮想マシンが格納されている。
HDD7と8　HOTSPARE
このディスク定価で1本20万円もする！ので
使いきらずにHOTSPARE多めにしたんじゃないかな。
その後HDD5に障害が発生したので、代わりにHDD8が使われたんだろう。
アクセスランプの点灯状況から、RAIDの再構築は完了していそうだ。

徹夜で修復作業をしなくても良いよね？