PATHpilotのブログ

Windows10が立ち上がらなくなったとの救援要請あり。

PORでCRITICAL PROCESS DIEDが表示される。

これを2回繰り返してから、起動画面が表示される。そこの詳細オプションからスタートアップ修復を試みるもNG。

セーフモードでの起動を試みた。

この後PINを聞いてくる。依頼主はPINを使っていないから分からないとのこと。セキュリティ関係のファイルかレジストリが壊れているのか。。。。

詳細オプションに戻って更新プログラムをアンインストールする。この時、普段使ってるパスワードを受け付けた。

この後PORしてもやはりCRITICAL PROCESS DIEDを繰り返す。

仕方がないので初期状態に戻すことにした。

クラウドからのダウンロードを選んだけれど4GBの空き領域が無いってことで蹴られてしまい、ローカル再インストールで進めた。

可能な限り設定を残したいので、個人ファイルを保持を選択。

パスワードを入力。ここでもパスワードは受け付けられた。

再インストールが無事終わってパスワード入力となり、ここで今までのパスワードが受け付けられない（正しくないと言われる）。しょうがないのでパスワードを忘れた場合でパスワードをリセットする。どうもここで参照するパスワードと上記グリーンスクリーンで参照するパスワードのソースが違うみたい（なんでかわからんけど）。

登録されているメールアドレスに確認コードを送るよう指示。依頼元のメールアドレスを確認することと、依頼元にメール受信（コード受信）をしてもらわないといけない。

これを2回繰り返してPINのリセットができた。

これで復旧した。

どうも原因はWindows10のレジストリーかパラメータファイルか何かがコラプトしたみたい。ハードウエアの問題ではなさそう。

一応復旧したようにみえるけれど、アプリの動作等を確認していないので（ひとさまのPCなので必要以上の操作はしない）どこまで環境が保持されているかは不明。ただ、立ち上がった様子（壁紙も含めて）は障害発生前と同じように見える。

暫く様子をみる。

PCをLenovoのノートブックにしてから、Chrome Remote Desktopにアクセスしているときに右シフトキーが利かなくなった。

Lenovo上でRemote Desktopのキーマッピング設定でShift RightをShift Leftにマッピングしてもダメだった。というか、解決しなかった。

いろいろ調べてMicrosoft Power ToyのKeyboardManagerでキーマッピングすればよいことがわかった。その備忘録。

まずはMicrosoft Learn Challengeにアクセスする。

ここのMicrosoft Storeでインストールするセクションに移動してMicrosoft StoreのPower Toysページからインストールするをクリックする。ここのPower ToysページでDownloadをクリックする。

ダウンロードが完了したらPowerShellにて上記Microsoft Storeでインストールするセクションにあるコマンドラインのコマンドを実行する。PowerShellにはメニューバーのむしめがねアイコンにてpowershellとタイプすれば起動する。

インストールが終わるとメニューバーにPowerToysアイコン（縦のカラーバーのアイコン）が表示されるので、そこをクリックしてPowerToysを立ち上げる。そこでKeyboard Managerを選ぶ。

キーの再マップを選んでShift（Rigit）をShift （Left）にマップする。キーを押すことでキー選択ができる。

OKボタンを押すと警告メッセージが出て、「次のキーには割り当てがありません」と表示されるけれど、それでも続行するをクリックするとキーマッピングが完了する。

これでChrome Remote DesktopでLenovo Notebook PCから右シフトキーが使えるようになった。

めでたし、めでたし。

備忘録

非Windows11 PCをWindows10 からWindows11にアップグレード

MicrosoftからWindows11のmulti-edition ISOイメージをダウンロード
setup.exeの実行、要件を見たいしていないことを確認
sources\appraiserres.dllファイルの中身を削除（ファイル自体を消すと再度作られてしまう）
setup.exeの実行
「セットアップでの更新プログラムのダウンロード方法の更新」をクリック
更新プログラム、ドライバー、オプション機能の入手で「今は実行しない」を選択して次へをクリック
ライセンス条項に同意するをクリック
インストール準備が完了したらインストールをクリック

10日以内ならシステム->回復->復元でWindows10に戻すことができる
10日以上に設定したかったら予め以下を実行
DISM /Online /Set-OSUninstallWindow /Value:100
Valueは日数指定、ここでは100日になる。
ただし、一旦この日数を過ぎるとWindows10に戻すことはできなくなる。

ThonnyでRaspberry Pi Picoのversionを最新（1.19.1）にバージョンアップしようとしたら、SSL: CERTIFICATE_VERIFY_FAILED, certificate has expired と言われてエラーになった。この対策の備忘録。

現象から。Certification has expiredと言われる。

どこに有効期限が切れたCertificationがあるんだか分からないので、とりあえずThonnyを最新に更新してみた。更新前。

ThonnyはここからWindows版をダウンロード。更新後。

しかし現象は変わらず。

この症状についてネット検索した結果、この問題のDiscussion Threadにたどり着いた。で、次の書き込みに注目！
I finally got it solved by installing https://letsencrypt.org/certs/lets-encrypt-r3.der 

この中の対応策にならって、このセキュリティ証明書をインポートした。以下、そのステップ記録。

「開く」をクリック。

「証明書のインストール」をクリック。

Thonnyを「すべてのユーザー」でインストールしたので、証明書もローカルコンピューターにインポート。

「自動的に証明書ストアを選択する」を選択。

「完了」をクリック。

これで証明書のインポートは完了。

さてさて、これでうまくいくのだろうかと。。。

うまくいった。Certificationが更新されたということなんだろうけれど、インポートした証明書が一体なんだったのかはよく分からない。

でも、動くようになったので、めでたし、めでたし。

UI-VIEW32にオリジナルマップを入れたので、その手順の備忘録。

大桑村部分を拡大したマップを入れてみた。JA0WBT-7を中心にした長方形エリアがそのマップ。マップを入れるとUI-VIEW32は入れられたマップの表示エリアを四角枠で表示する。

このマップはGoogle Mapのマップで自分が入れたいマップの部分をモニターに表示させてスクリーンコピーでJPEGファイルを作る。

このJPEGファイルの表示領域の左上隅と右下隅の座標をGoogle Mapで取得する。なので、JPEG座標隅位置の座標を取得しやす目印を隅にするとよい。

JPEGファイルはUI-VIEW32¥MAPにokuwa-vil.jpgとして保存した。取得した座標はJPEGファイルと同じファイル名のINFファイル(okuwa-vil.inf)としてMAPディレクトリに保存する。

okuwa-vil.infの内容：

35.45.99N, 137.25.98E　<- 左上隅の座標
35.35.21N, 137.52.23E　<- 右下隅の座標
okuwa-vil　<- マップの名前（マップリストに表示される）

これらのファイルを保存したらUI-VIEW32のMap -> Refresh Map Listを実行する。これでokuwa-vilでAPRS局をポイントできるようにる。

以下がokuwa-vilで表示した例。

なかなか面白い。

APRS I-Gateサーバーを構成したので、その備忘録。

木曽谷はAPRS空白地帯。一方で中央アルプスへの登山道が何本もある。それらの登山道の多くのエリアが携帯圏外。ここでの遭難防止のためにAPRSを活用したいのだが、空白地帯故に役に立たない。これは新たに立ち上げるしかない。

で、とりあず実験システムの構成。

ヤフオク!でゲットしたFT-7800とメルカリでゲットしたThinkCentraで構成した。アンテナは軒先ホイップアンテナ。とりあえずFT7-7800の外部スピーカー端子をThinkCentraのマイク端子に直結した。

ThinkCentraはWindows 11、TNCはAWG Packet Engine、サーバーにはUI-VIEW32で接続した。全体の実験構成は以下。

今回の実験に使ったFT-7800

I-Gateサーバーとして使っているLenovo ThinkCentre。FT-7800の外部スピーカー端子からマイク入力端子に直結している。ThinkCentraに外部スピーカーを取り付け、マイク入力をスピーカーモニターする構成にしてFT-7800からの音声入力をThinkCentraにてモニターしている。

ビーコン発生機としてFT3Dを使用した。

Software TNC、AGWPEをダウンロードする。この時AGW Monitorも一緒にダウンロードする。具体的な設定方法についてはソフトウエアTNCの解説を参考にした。AGW MonitorはAGW Monitorが実際にデコードできるかをチェックする。チェックの際、トランシーバーの音声出力レベルやPCのマイク入力レベルを調整することになる。

UI-VIEW32のインストールについては、いろいろなWEBページがあるが、どれも10年以上前とかなり古い。けれども、逆にそれ以降このアプリケーションは変更がなく、かつそれ以降あまりインストール事例報告がないともいえる。今回は、以下の3WEBページを参考にさせて頂いた。

• UI-VIEW最初の一歩
• I-GATEを立ててみよう　
• APRSアクセスポイント設定完了　

細かなパラメータ設定は最初の2つに大変助けて頂いた。3つ目には命を救われたように思う。特に今回はWindows 11でのインストールだったのだけれど、アプリの互換性設定についてはめちゃくちゃ貴重な経験を共有いただいた（こころより感謝）。

以下、ちょっとハマったところの備忘録。

真っ先に行うComms Setupでつまづいた。そもそもこのCOMポート設定って何なんだろうってことになるわけだけれど、UI-VIEW32がデータを取得する元はTNCで、ハードウエアTNCの場合はRS-232CでPCと接続するのだろう（これに思い当たるのにちょっと時間がかかった）。であれば、ソフトウエアTNCを使っている場合はどうなるのか？？？先の3つのWEBページの2つ目に答えがあった、Host modeでAGWPEを選べばよいのだ。これで解決した。

Comms SetupでのHost mode設定。

Setup -> APRS Server Setupで接続先となるAPRSサーバーを指定する。ここでは先のWEBページのガイドに沿ってaprsjp.net:14579を設定した。しかし、いつまで経っても自分の存在がMap上に現れない。そこで、Option -> Show IGATE Trafficを選んでRF to Internet Trafficを見てみたが、Trafficがない。つまり、サーバーとの通信がないわけだ。そもそも、APRS Server Setupで設定したサーバーにどういタイミングでログインするのか？？？Server SetupダイアログでOkボタンをクリックしたらログインするのか？？？どうもそこの理解が正しくなかったようだ。Actionメニューを見るとAction -> Connect to APRS Serverとある。ここをクリックしてみた。何度かTimeoutが起きたけれど、数回のチャレンジのあと、無事APRS Serverに接続した。接続するとMap上に沢山のノードが表示され、IGATE TrafficのRF to the Internetにも、ビーコン受信に合わせてトラフィックがレポートされた。

APRS Serverに接続した後のAction Menu。

次にMap上のシンボル設定。ネットで公開されているシンボル設定に従ってシンボルを設定した。

No Diam’ｄでＲ（I-Gate単体でReceive Only）に設定した。

さてさて、これでI-Gateサーバーが動くようになったので、FT3D（暫定的にTX Interval=1分に設定）を携帯して自動車にて近所を走ってみた。以下がその結果。

1分は自動車としては案外長い（移動する）。

とりあえず基礎実験が完了した。今後は以下のテーマで先に進むこととする。

• 携帯圏外（中央アルプス登山道）でのARPS電波受信実験
• パケット認識率向上のためのチューニング（現在は無線機とスピーカー出力とPCのマイク入力直結）
• 双方向通信の為の環境構築
• 9600bpsでの運用実験

まずはめでたし、めでたし。

AmazonにてPCIe 2 serial port adapterを購入。ドライバーインストールで手間取ったので備忘録。

メルカリでLenovo ThinkCentreをゲット。COMポートを使うアプリケーションでの使用が目的だが、届いてみると、なんとCOMポートが実装されていない。しょうがないので、LOW HIGHTのPCIe Serial Port Adapterをアマゾンで購入した。2099円。余分な出費（COMポートの存在を確認していればこの出費はなし）。

届いたアダプター。

早速実装した。

DRIVER CD-ROMが付属していたがドライバーインストールファイルの日付が2018と古いのでネットからメーカーのドライバーをダウンロードした。このドライバーページは英語版。PUMPSETUP.EXEというインストールツールを使ってインストールしたがエラーが表示された。

デバイスマネージャで見てもドライバーのインストールが無いといって黄色のビックリマークが表示される。どうもデバイスドライバーがWindows11に対応していないようだ。ダウンロードページの説明ではWindows11対応になっているのだが、、、

Googleで検索しなおすと同じメーカーの中国語ダウンロードページがあった。ドライバーをダウンロードして日付を見ると2021年になっている。これならWindows 11対応だろうと思い、先にインストールしたドライバーをアンインストールしてから、ここからダウンロードしたドライバーをインストールしてみた。インストール成功。デバイスマネージャでCOMポートが二つ表示された。

ということで、めでたし、めでたし。

今までTeam Viewerを個人使用で使ってきた。いろいろと面倒なことが起きたのでChrome Desktopに乗り換えようと思う。

インストールは至って簡単で、Chrome Desktopをインストールするだけ。クライアントからのアクセスはChomeを使う。重要なのは同一Googleアカウントで、サーバー、クライアントともログインするということ。つまり、同じGoogleアカウントでログインしているPC同士はPINコードさえ入力すればリモートアクセスを許可するというもの。

同じGoogleアカウントでログインしていて、Chrome Desktopサーバーとなっているマシーンはクライアントから一覧で見ることができる。

ここでログインしたいRemote Desktopを選択すればよい。

ではTeam Viewerの良いところがあるか、自分の過去の利用状況から考えてみた。Team Viewerで使ったのはファイル転送や再起動などだ。それ以外は単純なRemote Desktopとしてしか使ていない。

Chrome DesktopでもCtl+Alt+Delを送ることができるからリモートから再起動が可能だ。

ファイル転送もできる。

となると、Team Viewerを使い続ける意味があるのか？今の所、それを主張しうるポイントがない。今後はChrome DesktopでリモートFT8運用をおこなってみるかな。

とある事からBondを試すことになった。なんだかんだで結構時間がかかってしまって、朝から初めてもう外は薄暗くなってきてしまった。
で、いつものように備忘録。

環境はVMWare Player上の仮想サーバーのCentOS7.8。ネットワークアダプターは3つ用意して接続状態に設定。そのうち一つだけにIPアドレスを手動で設定しておくけれども、残り2つは何も事前設定しないでおく。

CentOSが立ち上がった直後のインターフェース状態は以下の通り。ens33だけにIPアドレスをセットしてある。

[root@localhost ~]# ifconfig
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.1.60 netmask 255.255.255.0 broadcast 192.168.1.255
inet6 fe80::20c:29ff:fe89:51ca prefixlen 64 scopeid 0x20<link>
inet6 240b:11:4541:9100:20c:29ff:fe89:51ca prefixlen 64 scopeid 0x0<global>
ether 00:0c:29:89:51:ca txqueuelen 1000 (Ethernet)
RX packets 74 bytes 6888 (6.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 82 bytes 9410 (9.1 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ens37: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether 00:0c:29:89:51:d4 txqueuelen 1000 (Ethernet)
RX packets 27 bytes 2082 (2.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ens38: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether 00:0c:29:89:51:de txqueuelen 1000 (Ethernet)
RX packets 27 bytes 2082 (2.0 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 68 bytes 5908 (5.7 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 68 bytes 5908 (5.7 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

virbr0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.122.1 netmask 255.255.255.0 broadcast 192.168.122.255
ether 52:54:00:b1:f3:35 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0

ens33にはインターフェース情報が設定されていて、のこりの2つのネットワークデバイスのens37とens38はいずれもstateはUPになっているけれどもインターフェース情報は未設定。

[root@localhost ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:89:51:ca brd ff:ff:ff:ff:ff:ff
inet 192.168.1.60/24 brd 192.168.1.255 scope global noprefixroute ens33
valid_lft forever preferred_lft forever
inet6 240b:11:4541:9100:20c:29ff:fe89:51ca/64 scope global mngtmpaddr dynamic
valid_lft 2591893sec preferred_lft 604693sec
inet6 fe80::20c:29ff:fe89:51ca/64 scope link
valid_lft forever preferred_lft forever
3: ens37: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:89:51:d4 brd ff:ff:ff:ff:ff:ff
4: ens38: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:89:51:de brd ff:ff:ff:ff:ff:ff
5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:b1:f3:35 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN group default qlen 1000
link/ether 52:54:00:b1:f3:35 brd ff:ff:ff:ff:ff:ff

で、これらをまとめると現在はこんな状態。インターフェース名ens33に対してのみネットワークデバイスens33が紐づけられている。

[root@localhost ~]# nmcli c
NAME UUID TYPE DEVICE
ens33 5fe6b09c-d12c-456e-9b1f-1d018a789fd2 ethernet ens33
virbr0 3de4169c-88a9-424f-b931-52ae87288f01 bridge virbr0
ens37 23a1e399-5010-4b12-842e-f43fcb6fb36c ethernet --
ens38 204e9f07-1a89-4c28-9ef1-1e0f775f9352 ethernet --

BondingのMasterを作成する。接続名とインターフェース名の両方とも名前はbond0と命名。モードはactive-backup。

[root@localhost ~]# nmcli connection add type bond autoconnect no con-name bond0 ifname bond0 mode active-backup
接続 'bond0' (329498e1-1f6b-4ed5-9885-c1a401cc63dc) が正常に追加されました。

確認。bond0が作られている。

[root@localhost ~]# nmcli c
NAME UUID TYPE DEVICE
ens33 5fe6b09c-d12c-456e-9b1f-1d018a789fd2 ethernet ens33
virbr0 3de4169c-88a9-424f-b931-52ae87288f01 bridge virbr0
bond0 329498e1-1f6b-4ed5-9885-c1a401cc63dc bond --
ens37 23a1e399-5010-4b12-842e-f43fcb6fb36c ethernet --
ens38 204e9f07-1a89-4c28-9ef1-1e0f775f9352 ethernet --

ens37とens38をSlaveとしてMaster bond0に登録する。

[root@localhost ~]# nmcli connection add type bond-slave autoconnect no ifname ens37 master bond0
接続 'bond-slave-ens37' (a2516f43-5725-425f-80c0-f6226d125f84) が正常に追加されました。
[root@localhost ~]# nmcli connection add type bond-slave autoconnect no ifname ens38 master bond0
接続 'bond-slave-ens38' (5c1e4b8b-dc77-414b-8a91-3ab3cc809056) が正常に追加されました。

状況の確認。いずれもbond-slaveとして接続名が登録されている。

[root@localhost ~]# nmcli c
NAME UUID TYPE DEVICE
ens33 5fe6b09c-d12c-456e-9b1f-1d018a789fd2 ethernet ens33
virbr0 3de4169c-88a9-424f-b931-52ae87288f01 bridge virbr0
bond-slave-ens37 a2516f43-5725-425f-80c0-f6226d125f84 ethernet --
bond-slave-ens38 5c1e4b8b-dc77-414b-8a91-3ab3cc809056 ethernet --
bond0 329498e1-1f6b-4ed5-9885-c1a401cc63dc bond --
ens37 23a1e399-5010-4b12-842e-f43fcb6fb36c ethernet --
ens38 204e9f07-1a89-4c28-9ef1-1e0f775f9352 ethernet --

Masterであるbond0にIPアドレス等を設定する。

[root@localhost ~]# nmcli c mod bond0 ipv4.method manual ipv4.address "192.168.1.61/24" ipv4.gateway "192.168.1.1" ipv4.dns "192.168.1.1" ipv6.method ignore

以降のシステム再起動でens37とens38が自動で接続状態にならないように、かつbond-slave-ens37とbond-slave-ens38とbond0が自動で接続状態になるように設定する。つまり、ens37とens38は単独ではイネーブルにならないであくまでbond-slaveとしてイネーブルされることを明示的に設定するわけだ。

[root@localhost ~]# nmcli c m ens37 connection.autoconnect no
[root@localhost ~]# nmcli c m ens38 connection.autoconnect no
[root@localhost ~]# nmcli c m bond-slave-ens37 connection.autoconnect yes
[root@localhost ~]# nmcli c m bond-slave-ens38 connection.autoconnect yes
[root@localhost ~]# nmcli c m bond0 connection.autoconnect yes

設定状態を確認する。

[root@localhost ~]# nmcli -f connection c s bond-slave-ens37
connection.id: bond-slave-ens37
connection.uuid: a2516f43-5725-425f-80c0-f6226d125f84
connection.stable-id: --
connection.type: 802-3-ethernet
connection.interface-name: ens37
connection.autoconnect: はい
connection.autoconnect-priority: 0
connection.autoconnect-retries: -1 (default)
connection.multi-connect: 0 (default)
connection.auth-retries: -1
connection.timestamp: 1602314980
connection.read-only: いいえ
connection.permissions: --
connection.zone: --
connection.master: bond0
connection.slave-type: bond
connection.autoconnect-slaves: -1 (default)
connection.secondaries: --
connection.gateway-ping-timeout: 0
connection.metered: 不明
connection.lldp: default
connection.mdns: -1 (default)
connection.llmnr: -1 (default)

[root@localhost ~]# nmcli -f connection c s bond-slave-ens38
connection.id: bond-slave-ens38
connection.uuid: 5c1e4b8b-dc77-414b-8a91-3ab3cc809056
connection.stable-id: --
connection.type: 802-3-ethernet
connection.interface-name: ens38
connection.autoconnect: はい
connection.autoconnect-priority: 0
connection.autoconnect-retries: -1 (default)
connection.multi-connect: 0 (default)
connection.auth-retries: -1
connection.timestamp: 1602314980
connection.read-only: いいえ
connection.permissions: --
connection.zone: --
connection.master: bond0
connection.slave-type: bond
connection.autoconnect-slaves: -1 (default)
connection.secondaries: --
connection.gateway-ping-timeout: 0
connection.metered: 不明
connection.lldp: default
connection.mdns: -1 (default)
connection.llmnr: -1 (default)

[root@localhost ~]# nmcli -f connection c s bond0
connection.id: bond0
connection.uuid: 329498e1-1f6b-4ed5-9885-c1a401cc63dc
connection.stable-id: --
connection.type: bond
connection.interface-name: bond0
connection.autoconnect: はい
connection.autoconnect-priority: 0
connection.autoconnect-retries: -1 (default)
connection.multi-connect: 0 (default)
connection.auth-retries: -1
connection.timestamp: 1602314980
connection.read-only: いいえ
connection.permissions: --
connection.zone: --
connection.master: --
connection.slave-type: --
connection.autoconnect-slaves: -1 (default)
connection.secondaries: --
connection.gateway-ping-timeout: 0
connection.metered: 不明
connection.lldp: default
connection.mdns: -1 (default)
connection.llmnr: -1 (default)

一連の変更を反映させるためにネットワークサービスの再起動を行う。

[root@localhost ~]# systemctl restart NetworkManager
[root@localhost ~]# systemctl restart network.service

出来上がった結果は以下のとおり。

[root@localhost ~]# nmcli c
NAME UUID TYPE DEVICE
ens33 5fe6b09c-d12c-456e-9b1f-1d018a789fd2 ethernet ens33
bond0 329498e1-1f6b-4ed5-9885-c1a401cc63dc bond bond0
virbr0 b8211a91-b2aa-4c8d-af4d-7207588fadff bridge virbr0
bond-slave-ens37 a2516f43-5725-425f-80c0-f6226d125f84 ethernet ens37
bond-slave-ens38 5c1e4b8b-dc77-414b-8a91-3ab3cc809056 ethernet ens38
ens37 23a1e399-5010-4b12-842e-f43fcb6fb36c ethernet --
ens38 204e9f07-1a89-4c28-9ef1-1e0f775f9352 ethernet --

[root@localhost ~]# ip a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ens33: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 00:0c:29:89:51:ca brd ff:ff:ff:ff:ff:ff
inet 192.168.1.60/24 brd 192.168.1.255 scope global noprefixroute ens33
valid_lft forever preferred_lft forever
inet6 240b:11:4541:9100:20c:29ff:fe89:51ca/64 scope global mngtmpaddr dynamic
valid_lft 2591984sec preferred_lft 604784sec
inet6 fe80::20c:29ff:fe89:51ca/64 scope link
valid_lft forever preferred_lft forever
3: ens37: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP group default qlen 1000
link/ether 00:0c:29:89:51:d4 brd ff:ff:ff:ff:ff:ff
4: ens38: <BROADCAST,MULTICAST,SLAVE,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast master bond0 state UP group default qlen 1000
link/ether 00:0c:29:89:51:d4 brd ff:ff:ff:ff:ff:ff
5: virbr0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue state DOWN group default qlen 1000
link/ether 52:54:00:b1:f3:35 brd ff:ff:ff:ff:ff:ff
inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
valid_lft forever preferred_lft forever
6: virbr0-nic: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast master virbr0 state DOWN group default qlen 1000
link/ether 52:54:00:b1:f3:35 brd ff:ff:ff:ff:ff:ff
8: bond0: <BROADCAST,MULTICAST,MASTER,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 00:0c:29:89:51:d4 brd ff:ff:ff:ff:ff:ff
inet 192.168.1.61/24 brd 192.168.1.255 scope global noprefixroute bond0
valid_lft forever preferred_lft forever
inet6 240b:11:4541:9100:20c:29ff:fe89:51d4/64 scope global mngtmpaddr dynamic
valid_lft 2591984sec preferred_lft 604784sec
inet6 fe80::20c:29ff:fe89:51d4/64 scope link
valid_lft forever preferred_lft forever
[root@localhost ~]#

そとから192.168.1.61でpingして疎通確認を行ってオッケー。

この作業を行って分かったことは、Bonding設定が終わるとSlaveに設定したens37とens38のMACアドレスが同じになる(末尾d4)ことと、Masterのbond0のMACアドレスも同じになること。試しにってことでもう一つSlaveを追加しても同じMACアドレスになった。ということはMasterのIPアドレスをこのMACアドレスに設定して、Slaveに設定したどのポートも外からは金太郎飴に見えるようにするってことなんだろうなぁ、、、とぼや～と理解した感じ（少なくともactive-standbyでは）。

まぁ、時間は費やしたけれど、新しい理解（ぼや～だけど）を得られたみたいだから良しとするか。

追記：
モニターの前から離れる前に、この理解は本当に正しいのかなぁって思ってちょっと調べてみたんだけれども、どうやら正しい感じだ。で、更に現在のBonding状態がActiveなSlaveの切り替え方法が見つかったので実際にやってみた。

[root@localhost ~]# cat /proc/net/bonding/bond0
Ethernet Channel Bonding Driver: v3.7.1 (April 27, 2011)

Bonding Mode: fault-tolerance (active-backup)
Primary Slave: None
Currently Active Slave: ens37
MII Status: up
MII Polling Interval (ms): 100
Up Delay (ms): 0
Down Delay (ms): 0

Slave Interface: ens37
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:0c:29:89:51:d4
Slave queue ID: 0

Slave Interface: ens38
MII Status: up
Speed: 1000 Mbps
Duplex: full
Link Failure Count: 0
Permanent HW addr: 00:0c:29:89:51:de
Slave queue ID: 0

ActiveなSlaveを切り替えてみる。現在ens37がActive。
[root@localhost ~]# cat /proc/net/bonding/bond0 | grep Currently
Currently Active Slave: ens37

切り替え実行。

[root@localhost ~]# ifenslave -c bond0 ens38

切り替え確認。

[root@localhost ~]# cat /proc/net/bonding/bond0 | grep Currently
Currently Active Slave: ens38
[root@localhost ~]#

ちゃんと動いているようだ。めでたし、めでたし。

追記２：

Masterのbond0のIPアドレスは/etc/sysconfig/network-scripts/ifcfg-bond0にかかれているIPADDRを変更すれば良いが、変更後NetworkManagerやnetwork.serviceをrestartしただけではIPアドレスが更新されなかった。で、実際には以下を実行することで変更を反映させた。

# nmcli c down bond0
# nmcli c up bond0

これは知ってないとハマるところだろうなぁ。まぁ、たまたまnmcli c up コマンドを実行した直後にこの課題にぶつかったので、試しにこのコマンド投げてみたら、、、ってことに過ぎなかったから。

追記３：

いろいろと先人の知恵を学んでいるとどうやら正解は以下のようだ。

# nmcli c reload <接続名>   ここではbond0
# nmcli c down <接続名>
# nmcli c up <接続名>

今から６年程前に結構一生懸命になってデモ用のRestletサーバーを構成したことがある。その頃のことを思い出して、久々にRestletサーバーを試してみた。目的はRaspberry Piの話し相手の作成。

環境は以下のとおり：
Centos 7.8
Java 1.8.0
Restlet 2.4.3

Step-1
Javaのインストール
# yum install java-1.8.0-openjdk java-1.8.0-openjdk-devel

Step-2
Restletのインストール
以下からzipをダウンロードする。
https://restlet.talend.com/downloads/current/
展開先は$HOME/workにした。

Step-3
環境変数の設定
Homeの.bash_profileに以下を設定する
export JAVA_HOME=/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.262.b10-0.el7_8.x86_64
export PATH=$PATH:$JAVA_HOME/bin
export CLASSPATH=.:$JAVA_HOME/jre/lib:JAVA_HOME/lib:$JAVA_HOME/lib/tools.jar:$HOME/work/restlet-jse-2.4.3/lib/org.restlet.jar:$home/work
なお、Class編集を含むコーディング環境は$home/workとしている。
備忘録として、、、上記環境変数の即時有効化には以下のコマンドを実行。
source ./.bash_profile

Step-4
コードの作成
作ったJAVAコードは以下の３つ：
ServerMain.java：Port8010でServerを立ち上げ、Dispatcherを呼ぶ
ServerDispatcher.java：コマンドに従ってFunctionを呼ぶ（この時点ではDataInpuのみを呼び出している）
DataInput.java：Dispatcherに呼び出されるFunction（中身はこの時点では空）

以下がソースコード。昔のコードを引っ張りだして今時点で不要な部分はざっくりとそぎ落としてあるけれどもimportはそのままなので、余分なライブラリがImportされているかも（だろう）。

ServerMain.java

import org.restlet.Component;
import org.restlet.data.Protocol;
import org.restlet.resource.ServerResource;

ServerDispatcher.java

DataIn.java

それぞれのJavaコードをコンパイルしてClassファイル化しておく。
以下、ServerMainの実行。クライアントからのコマンドの実行結果（19:58:07）が出力されている。インプットデータはtestと表示している。

# java ServerMain
Starting the internal [HTTP/1.1] server on port 8010
Starting ServerDispatcher application
/command/datain/test
input :test
2020-09-27 19:58:07 192.168.1.8 - - 8010 GET /command/datain/test - 200 18 0 56 http://192.168.1.62:8010 curl/7.55.1 -

上記出力をさせた、実際にクライアントから実行したコマンドは以下。testをパラメータとして渡している。

>curl http://192.168.1.62:8010/command/datain/test
return from datain
>

これで基本形が出来たことになる（と言うか昔のコードを復活したことになる）。

次のステップはRaspberry Piからコマンド（多分温度計の値）を送ってみたいと思う。
で、今日はここまで。