Ubuntuのセキュリティ対応状況を確認していて、状況が「Needs triage」になっているものが多数あり。「Needs triage」はどういう状況なのか忘れるので、メモ。
Needs triage → 脆弱性があるパッケージ（やモジュールなど）が存在しているが、対応が必要かどうかは確認・選別が必要な状況
Ubuntuの場合、ステータスが、Needs triageとなっているものは、脆弱性の影響があるのかどうかわからない状態ということ。
「Released (5.15.0-53.59)」となっているものは、カッコ内のバージョンで対応されているので、それと比べればよい。
「Not vulnerable (code not present)」は、影響なし。
Windows8.1のサポートが2023年1月10日で切れるので、その前にWindows10にアップグレードした。
Microsoftのアップグレートツールをダウンロード（https://www.microsoft.com/ja-jp/software-download/windows10）して実行したところ、「お使いのPCに現在インストールされているWindowsバージョンの言語またはエディションは、このツールでサポートされていません。」と表示されて、バージョンアップに失敗した。
もともと、Windows8.1 Homeが実行されており、Proにするためのライセンスキーを使っていると、Microsoftのサイト（https://www.microsoft.com/ja-jp/software-download/windows10）のツールではアップグレードできない模様。そのため、次の手順で、バージョンアップを行った。
１．PCを初期化して、Windows8.1 Homeにする。
２．Microsoftのサイト（https://www.microsoft.com/ja-jp/software-download/windows10）でツールをダウンロードして実行。
３．ツールを使って、Windows8.1 Homeから、Windows10 Homeにアップグレード。
４．Windows8用のProにするライセンスキーを、アップグレードしたWindows10 Homeに入力する。
５．Windows 10 Proになった。
もとがWindows8なので、ライセンスキーはそのまま使えた模様。エラーにならなかったので、たぶん大丈夫。
Merakiの管理画面から無線LANのAPを再起動する手順は下記。
1. Merakiの管理画面（ダッシュボード）にログインする。
2. 「ネットワーク」の部分で、対象のアクセスポイントがあるネットワークを選択する。
3. 「ワイヤレス」からアクセスポイントを選択する。
4. 「アクセスポイント」の一覧から再起動するアクセスポイントを選択する。
5. ツールを選択する。
6. 「デバイスの再起動」にあるAP再起動ボタンをクリックする。
7. 確認が表示されるので、再起動する場合は「今すぐ再起動」をクリックする。
8. ステータスが表示されるので確認する。
JP1/AJSで実行したジョブで、リターンのコード値が、設定していない「-1073741819」で返されることがある。
これは、起動した実行ファイルに異常（アプリケーションエラー）が発生したときに返される値とのこと。16進数のC0000005なので、メモリのアクセスバイオレーション（保護違反）が発生しているようだ。このエラーコードがJP1/AJSにリターンされている。
公式ドキュメント http://itdoc.hitachi.co.jp/manuals/3020/30203K5520/JPSC0227.HTM
リモートデスクトップ接続経由で、Veeam Backup ＆Recoveryを開いたところ、下記のDPI設定に関する警告がでた。
We hav detected that your DPI scaling level setting is defferent from 100%. This may results in some user interface contorols to appear misplaced
Please consider changing DPI setting to 100% in the display settings.
高解像度のPCで、画面解像度はディスプレイとあっているがディスプレイの「拡大縮小とレイアウト」の表示スケールが100%ではなかったので、この設定がでた。表示が崩れたり、みえないところが出たりするという警告なので、実害がなければ無視でよい。
Windows上で処理されたrrdファイルをLinuxのRRDToolで処理しようとしたらエラーになった。WindowsにRRD Toolをいれて、いろいろとやるのもめんどくさかったので、別のWindowsで蓄積されたRRDのファイルを、WSLのUbuntuにrrdtoolをインストールして処理しようとしていた。「rrdtool dump xxxx.rrd」を行うと下記のエラーが発生した。
zen@PC:~/rrd$ rrdtool dump seg-Pkts.rrd
ERROR: reached EOF while loading header rrd->ds_defWindowsの改行コードがはいっているため、LinuxのRRD Toolで処理できないというエラー。
WindowsのRRD Toolでrrdtool dump して、Linux上のRRDファイルにインポートしないといけないようだ。
つまり、WindowsのRRD Toolで作られたRRDファイルを、Linux上のRRD Toolで直接処理することはできない。
おまけ。同じRRDのファイルに対して、fetchをしても、項目はあっているのに取得できない。これも改行コードが影響しているためと思われる。
zen@PC:~/rrd$ rrdtool fetch seg-Pkts.rrd OutOctets
ERROR: unknown consolidation function 'OutOctets'新しくセットアップしているWindows11モデルのLet’sNote SV1（CF-SV1RDLAS）で、セットアップ中にLANが認識しなくなる不具合が多発しているので、いろいろと切り分けを行ったので、そのメモ。
発生しているのは、初期がWindows11 ver.21H2を、Windows UpdateでWindows11 ver. 22H2 にアップデートしたPCだ。Windows Updateは、12月6日時点での最新まで適用済み。
変な挙動
切り分けでやったこと（すべて失敗し、安定はしない）
他に試してみると、無線LAN接続のときは、スリープから復帰しても、ネットワークにはちゃんと繋がっている。最初から、Windows11 ver.22H2のLet’sNote SV1（CF-SV1RDLAS）では問題は起きない。つまり大型アップデートの影響と思われる。
これまた打つ手なしなので、そのうちWindows Updateで解消するのか、しばらく様子見するしかない。
FreeBSDで、”pkg upgrade”して、パッケージを最新の状態にしたところ、MariaDBが起動しなくなった。エラーログをみていると、DBのテーブルを修復したあとにDBがシャットダウンされている。DBのファイル破損が原因かと思い、いろいろと調べて対応したが、実はファイルの問題ではなかった。
原因は、MariaDBのバージョンが「MariaDB 10.5」に上がったことによる「my.cnf」ファイルの変更だった。
/usr/local/etc/mysql/conf.d/my.cnfこのconf.dのディレクトリに、my.cnfがあることで、これを読みにいって、その設定で失敗して、サービスが落ちていた。同じところに、client.cnfもserver.cnfもあるが、これを読まずにmy.cnfを先に読みにいって、落ちていた。my.cnfは、１つ上の階層の「/usr/local/etc/mysql/」にもあり、conf.dの下を読み込むように書かれている。
いろいろと行ったのだが、対応の正解は、conf.dの下のmy.cnfを消す（リネームでOK）。server.cnfとclient.cnfの設定を確認して、MariaDB（mysqld_safe）を起動させる。
ちなみに、errファイルに記録されていたログは下記。あとは、ログ自体が出力されていない。ログがそもそも出力されていなければ、my.cnfを疑うべきだった。
2022-02-05 15:36:39 0 [Note] /usr/local/libexec/mariadbd (initiated by: unknown): Normal shutdown
2022-02-05 15:36:39 0 [Note] Event Scheduler: Purging the queue. 0 events
2022-02-05 15:36:39 0 [Note] InnoDB: FTS optimize thread exiting.
2022-02-05 15:36:40 0 [Note] InnoDB: Starting shutdown...
2022-02-05 15:36:40 0 [Note] InnoDB: Dumping buffer pool(s) to /var/db/mysql/ib_buffer_pool
2022-02-05 15:36:40 0 [Note] InnoDB: Restricted to 2016 pages due to innodb_buf_pool_dump_pct=25
2022-02-05 15:36:40 0 [Note] InnoDB: Buffer pool(s) dump completed at 220205 15:36:40
2022-02-05 15:36:40 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
2022-02-05 15:36:40 0 [Note] InnoDB: Shutdown completed; log sequence number 1363646560; transaction id 111190553
2022-02-05 15:36:40 0 [Note] /usr/local/libexec/mariadbd: Shutdown complete
Microsoft365のOfficeツールが64bitのとき、Accessの32bitで作られたアプリケーションを開こうとするとエラーになる。Windowsのバージョンは、Windows10とWindows11。表示されるエラーメッセージは下記。
「このデータベースは、32 ビット版の Microsoft Access で作成されています。32ビット版の Microsoft Access で開いてください。」
これを解消するには、Officeツールを32ビット版を使えばいいのだが、通常64ビットのOfficeツールと32ビットのOfficeツールは共存できない。32ビットのOfficeツールだと制約が多いので、なるべくならば64ビットのままにしたい。調べてみると、Access 2010の32ビットのランタイムであれば、最新の64ビットのOfficeツールと共存が可能だ。
Access 2010 の32ビット ランタイムは、下記のMicrosoftのページからダウンロードしてインストールする。
Microsoft Access 2010 Runtime
https://www.microsoft.com/ja-jp/download/details.aspx?id=10910
Access 2010 の32ビット ランタイムをインストールすることで、32ビット版のAccessで作ったツールもエラーなく開くようになった。
WinSCPには、スクリプトによる自動実行ができるモードがある。このとき、読み込ませるスクリプトのファイルの文字コードはUTF-8にする。SJISのファイルの場合、フォルダの指定などでうまく行かず、エラーになることがある（主にマルチバイトのパスやファイル名の処理など）。