SQL Server 2022がリリース候補版になったとのこと。
https://www.itmedia.co.jp/news/articles/2208/26/news085.html
リリース候補版が発表されたので、今年の秋（2022年秋）には正式リリース版が出そうである。SQL Server 2019を入れたばかりなのだが。そんなに機能をフル活用しないので、SQL Server 2022にしておきたかった。タイミングが合わないものである。
SQL Server 2022がリリースされたら、Express Editionか、MSDNで試すかな。
またお名前ドットコムのVPSで、メンテナンスによりNICを変更された。固定IPアドレスはNICの設定となっているので、メンテナンスが終わってもネットワークには繋がらず。
前もNICの割当が変更されてネットワークダウンしっぱなしになった。VPSはサーバ用のサービスなのだから、もっと気を使ってほしい。別にカスタムイメージを使っているわけでなく、標準インストールから使えるOSだったというのに。
NICは、変更されて、10GのNICから、1GのNICに変更された。前のメンテナンスのときに10Gになったと思ったら、また1G接続に戻されたのだ。NICの接続速度は、10Gも使うわけはないのでよいのだが、そのためにNICごと変更するのは止めてほしいものだ。
ネットワーク的に外部との通信を厳しく制限している環境で、Windows Server 2019のWindows Updateをやっていた。httpsでの外部通信用に443番ポートは通信できるようにしていたが、http用の80番ポートはファイアウォールで閉じたままだった。
443番ポートだけ開けてあって、80番ポートを閉じたネットワークで、Windows Updateを行うと、アップデート対象のリストの取得ができなくてエラーになる。最初の通信を80番ポートでやっているため、80番ポートでの通信ができないとWindows Updateができない。Windows Updateには、80番ポートと443番ポートを使う、というのは本当で、「と」というのがポイント。「or」ではなく「and」である。
ちなみに、Windows Updateで80番ポートを使わない方法を探して、いろいろと試したがことごとく失敗した。両方のポートが必要だ。
「Dirty Cred（CVE-2022-2588）」についてのUbuntuのページ。修正されたカーネルのバージョンを調べて、アップデート後にそれよりも新しくなっていればよい。
https://ubuntu.com/security/CVE-2022-2588
修正パッチは出ているので、”apt update” “apt upgrade” でできるはずなので、試した。カーネルのバージョンが変わっていることが確認できたので、apt upgradeで問題なし。
作業前
zen@LABO:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.6 LTS
Release: 18.04
Codename: bionic
zen@LABO:~$ uname -a
Linux LABO 4.15.0-166-generic #174-Ubuntu SMP Wed Dec 8 19:07:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
zen@LABO:~$作業後
zen@LABO:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.6 LTS
Release: 18.04
Codename: bionic
zen@LABO:~$ uname -a
Linux LABO 4.15.0-191-generic #202-Ubuntu SMP Thu Aug 4 01:49:29 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
zen@LABO:~$作業前
zen@TEST:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.4 LTS
Release: 20.04
Codename: focal
zen@TEST:~$ uname -a
Linux TEST 5.4.0-109-generic #123-Ubuntu SMP Fri Apr 8 09:10:54 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
zen@TEST:~$作業後
zen@TEST:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 20.04.4 LTS
Release: 20.04
Codename: focal
zen@TEST:~$ uname -a
Linux TEST 5.4.0-125-generic #141-Ubuntu SMP Wed Aug 10 13:42:03 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
zen@TEST:~$.NET Framework 4.8系の最新バージョンである「.NET Framework 4.8.1」が出た。
Announcing .NET Framework 4.8.1
https://devblogs.microsoft.com/dotnet/announcing-dotnet-framework-481/
これ、Windows10/11とWindows Server 2022が対象なので、Windows Server 2019が対象外。開発ツールのVisual Studioも、Visual Studio 2022になる。
Windows Server 2019で .NET Framework 4.8.1 が使えないのが、セキュリティなど面できになるところだ。4.8.1にしたら、今のところ、Windows Server 2019で使えないし、難しい。
休みで、のんびりと本をよんで勉強していたら、突然のアラート。調べてみると、サーバに対して、ping も飛ぶし、ssh接続もできた。死んでいるのは、Webサーバへのアクセスのみ。プロセスもみてみると、httpdはいる。ブラウザでは応答不能なので、正常に動作しておらず、ハングアップしたっぽい。（FreeBSD 13.1 release と Apache2.4 の組み合わせ）
↓ ps auxの結果
root@ray:/var/log # ps aux | grep httpd
root 925 0.0 0.9 48980 17712 - Ss 25Jul22 1:44.07 /usr/local/sbin/httpd -DNOHTTPACCEPT
www 22306 0.0 1.6 63636 33864 - S 10:59 0:00.43 /usr/local/sbin/httpd -DNOHTTPACCEPT
www 22307 0.0 1.6 63700 34020 - S 10:59 0:00.43 /usr/local/sbin/httpd -DNOHTTPACCEPT
www 22308 0.0 0.9 48980 17728 - S 10:59 0:00.00 /usr/local/sbin/httpd -DNOHTTPACCEPT
www 22309 0.0 0.9 48980 17728 - S 10:59 0:00.00 /usr/local/sbin/httpd -DNOHTTPACCEPT
www 22310 0.0 0.9 48980 17728 - S 10:59 0:00.00 /usr/local/sbin/httpd -DNOHTTPACCEPT
www 22311 0.0 0.9 48980 17728 - S 10:59 0:00.00 /usr/local/sbin/httpd -DNOHTTPACCEPT
root 22314 0.0 0.1 12844 2032 0 S+ 10:59 0:00.00 grep httpd「-DNOHTTPACCEPT」がhttpdの引数としてあるけれど、どうやらこれは関係ないっぽい。これがついていても、Apacheは動いているというページがあるので。
「httpd -k restart」をやってみたが、なかなか応答が帰ってこず。応答が帰ってきたあとも、ブラウザではアクセスできず。
完全にhttpdプロセスが止まっていないことも考慮して、「httpd -k stop」「httpd -k stop」を行ってみたが駄目だった。エラーは出ているけれど、httpd自体は起動できているので、とりあえず無視。
root@ray:/var/log # httpd -k start
[Mon Aug 15 10:59:51.520174 2022] [core:warn] [pid 22319] (2)No such file or directory: AH00075: Failed to enable the 'httpready' Accept Filter
[Mon Aug 15 10:59:51.520649 2022] [core:warn] [pid 22319] (2)No such file or directory: AH00075: Failed to enable the 'httpready' Accept Filter
[Mon Aug 15 10:59:51.520656 2022] [core:warn] [pid 22319] (2)No such file or directory: AH00075: Failed to enable the 'dataready' Accept Filter
[Mon Aug 15 10:59:51.520661 2022] [core:warn] [pid 22319] (2)No such file or directory: AH00075: Failed to enable the 'dataready' Accept Filterもう一度、restartで再起動させてみたら、今度は正常にブラウザでアクセスできた。とりあえず、障害としては復旧したのでよし。
http/httpsでの疎通が取れなくなった時間のエラーログも確認してみたが、エラーログは記録されていなかった。調査はしたけれど、結局、原因不明。
自分のサーバなので、休みでよかった。しかし、休みで家にいるときに、この不可解な現象は・・・己の未熟さを顧みて、勉強を続けろってことだろうか。
古いADに参加したWindows11で、Microsoft365のWordやExcel、PowerPointにログインすると、TPMのエラーが発生して正常にログインできない。
Windows10でも同じ問題は起きていたが、こちらはWindowsのセキュリティアップデートを手動アンインストールすることで、ログインできるようになる。Windows11でも同じことを試したが、TPMエラーは解消せず。
いろいろと調べて、試していたところ、レジストリ値の変更で対処できることが分かった。
１．Windowsキーを押して、「regedit」と入力して、レジストリエディターを開く
２．下記の値を探して開く（選択する）
コンピューター\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\Protect\Providers\df9d8cd0-1501-11d1-8c7a-00c04fc297eb３．右クリックし、「新規」で「DWORD(32ビット)値」を選択する
４．名前を「ProtectionPolicy」に変える
５．「ProtectionPolicy」をダブルクリックして開き、「値のデータ」を「1」に変えて、OKをクリックする
６．OSを再起動してから、M365のログインを試す。
同じ方法で、Windows10のTPMエラーも解消することがわかっている。Providersの下の値は、環境によって変わる可能性はあり。その時は探して値追加を試す。
参考）
https://itguys.al/office-365-account-setup-tpm-error-80090034-fixed
Windowsで、テキスト形式のログをリアルタイムで確認したくて、”less +F” や “tail -f” のようなものがないかと調べていたら、Powershellでできるとのこと。
Get-Content -Path ログファイル -wait -tail 0止めるときは、「Ctrl ＋ C」で止める。
もし、文字化けが発生する場合には、「-encoding utf8」（utf8の部分は適切な文字コードに変える）を付けて実行する。
使ってみたが、便利。問題はコマンドを忘れそうなこと。
MySQLでSelect文の結果をファイルに書き出すのは簡単だった。Select文の最後に「INTO OUTFILE」でファイルの出力パスとファイル名を指定するだけだった。
SELECT * FROM テーブル名 INTO OUTFILE '出力ファイルパス';それから、書き込み先の権限がないと、エラーで失敗する。その場合は、書き込みするディレクトリのパーミッションを確認する。下記は、失敗したところ。
root@localhost [zen]> select * from item into outfile '/usr/home/zen/item.csv';
ERROR 1 (HY000): Can't create/write to file '/usr/home/zen/item.csv' (Errcode: 13 "Permission denied")
root@localhost [zen]>やっとGoogle Chatで作成したSpaces（チャットルーム）を削除できるようになった。今までは、チャットルームを抜けることはできても、消すことはできなかった。地味なアップデートだけど、うれしいアップデート。これでゴミを消せる。
https://workspaceupdates.googleblog.com/2022/07/delete-chat-spaces-and-their-content.html
削除には、Spacesのスペース名のところをクリックして、プルダウンで表示されたメニューから「削除」を選ぶ。
Spacesを削除すると、チャットの内容とファイルが消えるので、注意は必要。