GitLab CE 16.7.0からGitLab CE 16.7.3へアップデートした。
apt update, apt upgrade で問題なくアップデートできた。
GitLab CE 16.7.0からGitLab CE 16.7.3へアップデートした。
apt update, apt upgrade で問題なくアップデートできた。
FSMOの確認や移動で、「Active Directory スキーマ」を確認するために、MMCに追加しようしたときに「スナップインの追加と削除」に表示されなかった。(OSは、Windows Server 2022)
「Active Directory スキーマ」は、コマンドで「schmmgmt.dll」を追加しないと表示されない。環境は、Windows Server 2022のActive Directory。
ADサーバにログオンして、Powershellを起動して、以下のコマンドを実行する。
regsvr32.exe schmmgmt.dll
追加に成功すると、ポップアップでメッセージが表示される。OSの再起動は不要。
MMCで「スナップインの追加と削除」を表示すると、下図のように追加されている。

ADサーバにログインして、管理者モードのPowershellで以下のコマンドを実行する。
netdom /query fsmo
実行例
PS C:\Users\administrator.TD> netdom /query fsmo
スキーマ マスター ACTIVE2.td.xenos.jp
ドメイン名前付けマスター ACTIVE2.td.xenos.jp
PDC ACTIVE2.td.xenos.co.jp
RID プール マネージャー ACTIVE2.td.xenos.jp
インフラストラクチャ マスター ACTIVE2.td.xenos.jp
コマンドは正しく完了しました。
PS C:\Users\administrator.TD>
Windows Server 2022のADでも変わらず、このコマンドでOKだった。
Surface Pro 7(Windows 10 22H2)で、2024年1月のWindows UpdateのKB5034441が、コード 0x80070643でエラーになる。
回復領域のサイズ不足で、このエラーが発生するとのこと。対応は手動で、回復領域を拡張する必要があるとのこと。Surface Pro 7は、ディスク領域とかは初期状態から変えていないのだが。この問題に直面する人は多そう。めんどくさいな。
参考: https://forest.watch.impress.co.jp/docs/news/1560171.html
利用中のWindows PCの挙動が怪しいときは、システムファイルチェッカーを使ってみる。ファイルの破損等が問題の場合は、システムファイルチェッカーを使うことで修復が行われ、システムが安定する可能性がある。
1. Windows Updateを行って最新の状態にする。
2. コマンドプロンプトを管理者モードで起動する(右クリックして「管理者として起動する」を選択する)。
3. `DISM.exe /Online /Cleanup-image /Restorehealth` を実行する。
4. 3の部分が正常実行されたら、次に `sfc /scannow` を実行する。
5. なにか問題があれば自動修復された旨が表示される。
実行例は下図。

VMware Toolsのバージョンアップ後、Windowsの画面解像度の変更ができなくなった。かつ、VMware Toolsの入れ替え前と比べて、解像度もひくくなった。
これの対応としては、ESXiやvCenterで、仮想マシンのビデオカードの設定を、「設定の自動検出」に変更する。
1. vCenter ServerまたはESXiのウェブUIにログインする。
2. 該当の仮想マシンをシャットダウンする。
3. 「設定の編集」をクリックする
4. ビデオカードの設定を開いて、「設定の自動検出」を選択する。
5. 保存して、仮想マシンを起動する。
6. 仮想マシン(Windows)にログオンして、画面解像度を変更する。

スマートフォンの回線をソフトバンクからamahoに切り替えたので、インターネット回線もソフトバンク光からahamo光に切り替えた。これで少しは月額コストを抑えられるはず。
ahamo光に切り替えたときのメモを残す。
ahamo光の申込みはキャンペーン(10,000ポイントバック)を使ったので、ahamoからキャンペーン用のサイトで申し込みをした。たぶん、これが間違いだったのかもしれない。キャンペーン用のところでなければ、もっとスマートに申し込みなどができていたかもしれない。
キャンペーンでは、docomoコンサルティングからの電話での申込み確認が必須。この電話がとてもダラダラと長い。重要事項の確認が微妙で事前に書類を読めば終わるようなことを電話で1時間くらいかかった。20分とか言っていたのだが。不明なところの確認もあったのだが、不明なところを質問すると、まるで答えられない。切り替え元のソフトバンク光から切り替えるときの注意点で、もとがPPPoE方式でないと、切り替えに時間がかかると言われた。なぜそれが必要なのかを聞いても、答えられなかった。それから、切り替え日で、新しい回線に切り替わってから、実際に通信できるまでに数日かかるという説明もあった。でも、なぜ数日もかかるのかについては教えてもらえず。というか、数日かかるとしか言われない。実際に、謎に2日もかかったわけなんだが。
ルータについては、レンタルではなくて、バッファローのルータ(WSR-1800AX4P-WH)を購入した。OCNバーチャルコネクト対応のルータを用意する必要があったので、バーチャルコネクト対応かつ、とりあえず安いバッファローのWiFi6対応のものを買った。
切替日の朝には、自動的にソフトバンク光側は通信できなくなっている、という説明だったので、そのままにしていた。が、切替日の朝でもソフトバンク光は使えていた。ソフトバンク光のルータの電源を落とし、フレッツ光の終端装置も電源を落とし、20分くらい放置してから、新しいルータ(WSR-1800AX4P)で自動接続を試したが、切り替わらない。というかIPv6のアドレスも取得しない。数時間放置して、ルータを再起動したが接続できない。時間をおいて、何度か試したが接続できず。切替日の翌朝も同じことを試したが、接続できなかった。
切替日の翌日の夜に、確認したところ、IPv6のアドレスは取得できるようになっていた。だが、接続がOCNバーチャルコネクトではなくて、別のものが表示された後に、接続がきれていた。そのため、バッファローのルータを本体側のスイッチでAutoからマニュアルに切り替えて、ブラウザでルータの設定画面を開き、インターネットの設定で、OCNバーチャルコネクトを選択した。(このマニュアルでの設定は、ルータの物理スイッチがAutoに設定されていると表示されないので注意。物理スイッチのAuto設定と、ソフトウェアとしてのAuto設定の2つがあり、これが両方ともマニュアルになっていないと設定できない。)ルータの設定で、OCNバーチャルコネクトを選択して、何回かルータを再起動したら、IPv4のアドレスを取得した表示がルータのステータス画面で表示されて、ahamo光でインターネットの通信ができるようになった。
ネットで見かけていたAmazon Primeビデオが見れないという書き込みもあったが見れた。PCからも、PS4からも、タブレットからも、Amazon Prime Videoは見れた。スプラトゥーン3の通信も問題なし。ルータの性能もあるかもしれないが、ソフトバンク光よりも通信速度は出ている。下りで300Mbpsくらい。
教訓をまとめると・・・
JP1 Network Node Manager(JP1 NNM)に送信されてきたトラップ(SNMP Trap)を表示するのは、nnmtrapdump.ovplコマンドをCLIで実行する。実行すると、結果がコンソールに表示される。件数が多いことが想定されるので、標準出力をつかって、ファイルに書き出す方がよい。
オプションのパラメータを指定することで、期間や送信元のIPアドレスで絞り込むことができる。
例)
C:\Program Files (x86)\Hitachi\Cm2NNMi\bin>nnmtrapdump.ovpl -from 2023-08-30T00:00:00 -to 2023-08-30T23:59:59 -source xxx.xxx.xxx.xxx
参考: https://itpfdoc.hitachi.co.jp/manuals/3021/30213E0230/NNMS0621.HTM
Google Cloud SQLでMySQLのインスタンスを追加すると、タイムゾーンがUTCになる。これを、日本に変える方法のメモ。
タイムゾーンの確認のSQLと実行例。
MySQL [(none)]> SHOW VARIABLES LIKE '%time_zone%'
-> ;
+------------------+--------+
| Variable_name | Value |
+------------------+--------+
| system_time_zone | UTC |
| time_zone | SYSTEM |
+------------------+--------+
2 rows in set (0.157 sec)
MySQL [(none)]>
変更方法
1. Google Cloudの管理画面にアクセスして、SQLの管理画面を開く。
2. 設定変更するインスタンスを開く。
3. 上部メニューの「開く」をクリックする。
4. 「フラグ」のところを広げる
5. 「データベースフラグを追加」をクリックする。
6. フラグ選択で、「default_time_zone」を選択する。
7. 値に、「Asia/Tokyo」を入力する(選択ではなくて、入力する)。
8. 保存する。
9. 保存後に、インスタンスの再起動が必要になるので、再起動する。

設定変更後に確認した例。
システム側はUTCのままだが、アクセスしたとき(セッション)のタイムゾーンは、Asia/Tokyoに変わっており、現在時刻を取得した際の時間も日本時間になっていた。
MySQL [(none)]> SHOW VARIABLES LIKE '%time_zone%';
+------------------+------------+
| Variable_name | Value |
+------------------+------------+
| system_time_zone | UTC |
| time_zone | Asia/Tokyo |
+------------------+------------+
2 rows in set (0.159 sec)
MySQL [(none)]> select now();
+---------------------+
| now() |
+---------------------+
| 2023-12-11 13:50:43 |
+---------------------+
1 row in set (0.154 sec)
MySQL [(none)]>
ADのグループポリシーエディタを開くには、以下を行う。
1. Windowsキー+Rで、「ファイルを指定して実行」を開く。
2. 「gpmc.msc」を入力して、OKをクリックする。
3. ADのグループポリシーエディタが開く。
探すよりも、指定して開く方が早い。