更新アシスタントを使ったWindows11 22H2から 23H2化が「エラーコード 0xc00000f0」で失敗した。

一旦、キャンセルを押して終了させた後、完全シャットダウン(シフトキー押しながら、シャットダウンを選択)を行った。そのあと、再度、更新アシスタントを再度実行したところ、今度は成功し、Windows11 23H2になった。
更新アシスタントを使ったWindows11 22H2から 23H2化が「エラーコード 0xc00000f0」で失敗した。

一旦、キャンセルを押して終了させた後、完全シャットダウン(シフトキー押しながら、シャットダウンを選択)を行った。そのあと、再度、更新アシスタントを再度実行したところ、今度は成功し、Windows11 23H2になった。
BroadcomによるVMwareの買収が完了したとのこと。カスタマー向けのお知らせメールも届いた。
https://www.broadcom.com/blog/broadcom-announces-successful-acquisition-of-vmware
はっきり言って、この先が不透明。オンプレ用のESXiは提供はされ続けるだろうけれど、新機能などはどうなるだろうか。枯れたシステムとして、保守されていくような気がしてならない。あとは、サポートの質がさらに悪くなる気がする。保守やライセンス継続のコストも心配なわけで。
Symantec Endpoint ProtectionがBroadcomの配下になったときも、めちゃくちゃ使いにくくなった。というか、管理サイトやサポートサイトへのログインがめんどくさいことになった。この先の一年くらいで同じようになるのではないかと考えると、微妙な気持ちになる。
VMwareのESXi以外となると、Hyper-Vか、Linux KVMか、Xenか。Windows OSを利用することを考えると、管理面を考えなければ、Hyper-Vなんだろうな。
VMware(vSphere)のDRS環境で、同じホスト(同じハードウェア)で稼働させたくないサーバ群がある場合は、アンチアフィニティルールを設定する。
アンチアフィニティルールを使うことで、クラスタを組んでいるサーバが同一のハードウェアで稼働しないようになる(仮想サーバ間の稼働ホストの排他制御のようになる)。これにより、ホストの物理サーバで障害が発生しても、クラスタを組んでいるサーバが一斉にダウンするということは避けられる。クラスタを組んでいなくても、ホットスタンバイのサーバも同時にダウンすることをアンチアフィニティルールの設定でさけることができる。
アフィニティルールのマニュアル
https://docs.vmware.com/jp/VMware-vSphere/8.0/vsphere-resource-management/GUID-94FCC204-115A-4918-9533-BFC588338ECB.html
ついにGoogle App Scriptから、JDBC経由で、Google CloudのCloud SQL のMySQL 8.0のインスタンスに接続を試して、成功した。JDBCがMySQL 8.0 に対応した。(忘れていたけれど、2022年11月も成功していたようだ・・・)
なお、接続はSSL / TLS クライアント証明書による接続。
GASサンプルコード:接続して、DB名とバージョンを取得する
function myFunction() {
dbConnectionSSL()
}
// --------------------------------
// SSLで接続する
// --------------------------------
function dbConnectionSSL(){
Logger.log('start dbConnection function.');
// 接続先設定
var connectionIp = '34.xx.xx.xx'; // 接続のMysqlのIPアドレス(ホスト名も可)
var userName = 'username'; // 接続で使うユーザ名
var passwd = 'passowrd'; // 接続で使うパスワード
var databaseName = 'CT'; // データベース名
var addr = 'jdbc:mysql://' + connectionIp + '/' + databaseName + '?useSSL=true';
// SSL用の証明書を変数に入れる
var clientKey = '\
-----BEGIN RSA PRIVATE KEY-----\n\
zylvsBC2kozS3rAxO1KUeD+rUbdDC/0PDbANXi4s/96qEN9vV80WBfH7Ut1TDdWt\n\
~~~中略~~~
wGeppu4uYW4hSE6rATB+GhNwFJtAl1qz4M2nefKWBCc97wmZte/G\n\
-----END RSA PRIVATE KEY-----';
var clientCert = '\
-----BEGIN CERTIFICATE-----\n\
g+vn0NZqwTzhGhfXV9y7k0wsjqN3VjfvLSkSqinYRgDID/vb7FvAD3qyGyTiR9HT\n\
~~~中略~~~
l+AUFjEP\n\
-----END CERTIFICATE-----';
var serverCa = '\
-----BEGIN CERTIFICATE-----\n\
pIa8Cnto3SIGqcwdV1SjA8iS1ohC3t+2igQq9aykOjd51jSQlVRqsE5lYty1VhiX\n\
~~~中略~~~
fCcN9N2TqwxUXmD7g/+5lBi+wf+FBCPml/cyeRvDu5PZIqQ=\n\
-----END CERTIFICATE-----';
Logger.log('start mysql con');
Logger.log(addr);
var connectionInfo = {
user: userName,
password: passwd,
_serverSslCertificate: serverCa,
_clientSslCertificate: clientCert,
_clientSslKey: clientKey
}
// DBにコネクションをはるオブジェクトを作る
var connection = Jdbc.getConnection(addr, connectionInfo);
Logger.log(connection.getCatalog());
// Select文を実行するための処理
// sqlステートメントをデータベースに送信するためのオブジェクトを作る
var statement = connection.createStatement();
// sqlを実行して結果をオブジェクトに入れる
var result = statement.executeQuery('select @@version;');
// 結果を取り出す
while (result.next()) {
var name = result.getString('@@version');
// ログに出力する
Logger.log(name);
}
// コネクションを閉じる
connection.close();
Logger.log('end');
}
// -----------------------------------
// DB Connection close
// -----------------------------------
function dbConnectionClose(connection) {
Logger.log('start db connection close');
connection.close;
Logger.log('end db connection close');
}

VMware Toolsの脆弱性の評価は、CVSSv3基本スコアで、CVE-2023-34057は「7.8」(Important)。ゲスト仮想マシンへのローカルユーザーアクセスを持つ悪意のある攻撃者が、仮想マシン内の権限を昇格できる可能性があるとのこと。
「VMware」のゲストOS向けアプリ「VMware Tools」に重大な脆弱性 ~対策版への更新を – 窓の杜 (impress.co.jp)
https://forest.watch.impress.co.jp/docs/news/1543401.html
脆弱性が修正されたバージョンへのVMware Toolsの更新が必要。
対象となるVMware Toolsのバージョン 12.xx、11.xx、10.3.x
脆弱性対応されたバージョン 12.3.5
https://www.vmware.com/security/advisories/VMSA-2023-0024.html
ダウンロードのURLは下記。ダウンロードには、VMwareのCUSTOMER CONNECTのアカウントが必要。
Veeam Backup & Replicaiton のユーザは、Veeam上にユーザを作るわけではなく、Veeamの管理サーバがインストールされたWindowsのローカルアカウントもしくは、ドメインアカウントを使用する。
アカウント追加の手順としては、
1. Windowsに新しくユーザを登録する。
2. 追加したWindowsアカウントのパスワードを登録する。
3. Veeam backup でメインメニューから「Users and Roles」を選択する
4. 「Add」をクリックする
5. 「User or group」フィールドで、ユーザー名またはユーザーグループの名前を「ドメイン\ユーザー名」の形式で入力する。
6. 「Role」リストから、割り当てるロールを選択する。
7. 「OK」をクリックする。
8. Veeam Backupへのログインを試す。
参考:
https://helpcenter.veeam.com/jp/archive/backup/110/hyperv/users_roles.html
NPSサーバ再起動後に、Meraki APからNPSへのRADIUS認証でエラーが発生するようになった。そのときの対応のメモ。
802.1X Failed authentication (EAP failure)
一応、Meraki APの再起動をやってみたが効果なし。Merakiの管理画面から、RADIUS認証を試してみるとエラーになった。RADIUS認証が影響していることが分かったので、RADIUS認証サーバであるWindowsのNPSサーバ側を調べた。
NPS(ネットワークポリシーサーバー)側のログは、イベントビューアーの「Windowsログ」の「セキュリティ」に下記のログがあった。
サーバーで拡張認証プロトコル(EAP)の種類を処理できないため、クライアントを認証できませんでした
RADUISであるNPSサーバまでの通信は行われており、RADUIS認証の中で、ユーザの認証ができていないため、接続が拒否されていることがわかった。NPSサーバに対象を絞って、調査した。
NPSサーバの管理画面で、「NAPを構成する」をクリックしてウィザードを開始してみると、「認証方法の構成」で「NPSサーバー証明書」が「なし」で選択できないことがわかった。つまりサーバ証明書がない(失効していても同じ状態)のが原因なので、これを解消するために対応した。
いろいろと試した結果、結論しては、先の作業で解消した。
1. NPSのサーバで、管理ツールから「証明機関」を開く。
2. ローカルの証明サーバを選んで、右クリック。
3. 「すべてのタスク」から「CA証明書の書き換え」を選択する。
4. 証明書の書き換えで再発行する。
5. NPSサーバ(サービス)を再起動する。
これで、NPSからADのディレクトリに対して、認証ができるようになり、PEAPの認証が正常に行えるようになった。
Cisco NEXUS でVPC構成(VLAN多数)、VMware ESXiによる仮想化、F5 BIG-IPの仮想ロードバランサ、ロードバランサの配下に複数のアプリケーションサーバ、という構成で、ロードバランサの下のAPサーバに通信がうまくできない、という状態が発生した。
状況を切り分けしてみると、下記のような状態になった。
端末→ESXi→Cisco NEXUS (A)→ESXi→BIG-IP→アプリサーバ(X) ・・・ 通信OK
端末→ESXi→Cisco NEXUS (A)→ESXi→BIG-IP→アプリサーバ(Y) ・・・ 通信OK
端末→ESXi→Cisco NEXUS (B)→ESXi→BIG-IP→アプリサーバ(X) ・・・ 通信NG
端末→ESXi→Cisco NEXUS (B)→ESXi→BIG-IP→アプリサーバ(Y) ・・・ 通信NG
※Cisco NEXUSは、2台(AとB)で、VPC(Virtual Port Channel)構成で、L3の役割を行っている。基本的に、VLANを超えるときは、必ずL3のNEXUSを通過する。
※端末と、APサーバ、BIG-IP仮想ロードバランサは、それぞれ別のネットワークに属する。
最初は、L3スイッチである、NEXUSの設定を疑ったのだが、AとBで差異はなく、VPCとしての動作も問題がなかった。BIG-IPを経由しなければ、AとBのどちらのNEXUSを通過しても問題発生しない。
BIG-IPの仮想ロードバランサでの通信制御が不具合につながっている可能性が高いことがわかった。BIG-IP仮想ロードバランサの設定を見ていくと、「Auto Last Hop」の設定がONになっており、これが影響していることがわかった。上位のスイッチであるL3のNexusは2台あるので、アクセスしてきたアクセス経路に通信を返す、のが正しいように見える。しかし、VPC構成になっているで、仮想MACアドレスで制御されているのため、アクセス元のスイッチに返してしまうと、経路が途中で変わってしまい、アクセス元の端末までパケットが届かない。
BIP-IPのほうも、上位スイッチが冗長構成を行っている場合は、「Auto Last Hop」の設定は、オフ(無効)にすることが推奨されている。「Auto Last Hop」の設定をオフにすることで、無事に、AとBのどちらのNexusを経由しても、BIP-IP仮想ロードバランサの下のAPサーバと通信できるようになった。
「Auto Last Hop」の設定は、BIG-IP仮想ロードバランサの設定画面で、
「System」→「Configuration」→「Local Traffic」
の順に選択する。Generalのプロパティに、「Auto Last Hop」の項目があるので、「Enabled」のチェックを外して保存する。
Auto Last Hopの説明
MicrosoftがWindows環境におけるVBScript(VBS)を非推奨にすると発表した。将来的には、VBScriptの実行環境が削除されるとのこと。
「VBScript」は非推奨に、将来のWindowsリリースで削除
https://forest.watch.impress.co.jp/docs/news/1537619.html
しぶとく残ると思われていたIE11も廃止されたので、VBScriptも確実に削除されるだろう。いずれ出るであろうWindows 12は、削除されていてもおかしくはないかも。そう考えると、明確な言及はないけれど、2,3年くらいで無くなるという覚悟が必要そうだ。
また、小まめにGitLab CEのアップデートをやり忘れて、apt updateでのアップデートでエラーになった。今回は、GitLab CE 16.2から、GitLab CE 16.4.1へのアップデートだ。
apt upgradeで発生したエラー(一部抜粋)は下記。
gitlab preinstall: It seems you are upgrading from 16.2 to 16.4.
gitlab preinstall: It is required to upgrade to the latest 16.3.x version first before proceeding.
gitlab preinstall: Please follow the upgrade documentation at https://docs.gitlab.com/ee/update/index.html#upgrade-paths
dpkg: アーカイブ /tmp/apt-dpkg-install-33WUrh/15-gitlab-ce_16.4.1-ce.0_amd64.deb の処理中にエラーが発生しました (--unpack):
new gitlab-ce package pre-installation script subprocess returned error exit status 1
処理中にエラーが発生しました:
/tmp/apt-dpkg-install-33WUrh/15-gitlab-ce_16.4.1-ce.0_amd64.deb
E: Sub-process /usr/bin/dpkg returned an error code (1)
まずは、GitLabのサイトで、アップグレードできるパスを調べる。
これによると、一度、16.3.5にアップグレードしてから、この時点の最新にアップグレードする必要があるとのこと。
アップグレードパス : 16.2 → 16.3.5 → 16.4.1
これを実行したコマンドは下記。段階的にアップデートして、最後に、GitLabを再起動する。
sudo apt update
sudo apt upgrade gitlab-ce=16.3.5-ce.0
sudo apt upgrade gitlab-ce=16.4.1-ce.0
sudo gitlab-ctl restart
何度もやっているので、作業自体はこなれた感じだ。