SVX日記

　 父親というものは、自分の好きなモノを、息子にも好きになってもらいたいと思うものだ。しかし、そうなる場合もないことはないのだろうが、そうならない場合の方が多いように思う。

　 自分の場合、プログラミングやモノ作りが好きなのだが、そういう場面を見ている息子からすれば、それはオヤジが常に優位にいる場面でもあるわけで、対抗意識が強ければ強いほど、それは、むしろその分野を当人から遠ざける方向性に倒れるからだ。

　 そういう自分を振り返ってみれば、モノ作りの方面では尊敬をしつつも、プログラミングの方面で自尊心を保っていたように思える。そのせいか、自分は親に「好きなものを仕事にできるとは限らない」とコトある毎にケチを付けられてきたので、その反動もあって、息子を含む他人には「何でも好きなことをやれ」と言い続け、何も否定しない主義を貫いている。で、気づくと、息子は動画編集のスキルを大きく伸ばしていて、最近は小銭すら稼いでいるようだ。まだ学生なのに。

　 前置きが長くなったが、そんなある晩、息子に「家のネットのダウンロードが遅くて、仕事の素材がなかなか落とせなくて困った」と言われた。遅いったって、光だし、どうせ夜は混雑しているし……と思ったが、そこで「いまどき100Mbpsはアリエナイ」という事実にようやく気づかされた。我ながら技術力には自信がある方だが、良くも悪くもトレンドに乗らなさすぎることにも大いに自信がある。エッヘン。

　 調べるといまどきは10Gbpsも引けるようだ。いや、それはさすがにちょっと過剰なような気もするが……え。1Gbpsへのプラン変更なら、むしろ月額が下がるの!? これはイカン……ホント、トレンドに乗らないという性格も大概にせんといかんな。

　 で、あわててプロバイダに電話してプランのアップグレードを依頼した。いまどきは電話対応もカリカリにチューニングされていて、話も早いのだが、その途中で「お使いの無線ルータは使えなくなります」という不穏な案内が……チョーッと待ったぁ!! Linuxでネットワークを組んでいる我が家の場合それは困るんですが。

　 当然ながら、電話の先は契約担当なので、その件について物言いを付けたら「明日、改めて技術担当から」ということになった。要するに「LinuxからPPPoEしたい」だけなのであるが、それを言ってもたぶんダメだろうから。

　 技術担当の連絡をただ待っていても仕方ないので、自分でも調べる。回線屋のサイトで接続機器の仕様を確認する。何機種もあるようなのでよくわからんが、最近はどうも「モデム」と「ルータ」ではなく「無線」も含めて一体型になった「ホームゲートウェイ」というものが主流のようだ。そら効率を突き詰めればそうなるわな。一体型であっても、単なるモデムとして動いてくれるモードがあればそれでいいんだが、そのモードがあることまでは読み取れない。

　 翌日、技術担当から電話があったが、やっぱり話がよく通じない。ホントに技術担当……なの？ とはいえ、この期に及んでノーゴーという選択肢もありえない。なので、とりあえず、納得したようなフリをして契約を進めることにした。こんなことならイラんツッコミするんじゃなかったワイ。にしても、ホント電話対応はカリカリにチューニングされているのな。電話中に本人確認のSMSを送りつけ、それでサイトに誘導して「同意」ボタンを押させる、なんてこともできるんだな。ガラケーだとできなさそうだが、その場合はどうするのだろう？

　 数日したら工事の日程の調整の連絡がきた。平日でいいので最短で、と依頼。で、本日の昼過ぎに工事担当の方が来られた。ヒゲの似合う愛想のいいイケメン。ルータの置いてある小屋裏に案内して、雑談しながら作業してもらったが、作業も雑談の返しも的確で、スゴく頭がよさそう。30分ほどで作業完了である。

　 経緯をまとめると以下だ。早いね。

07/20(土) チャットに記録を残す
07/21(日) 電話で連絡、ルータが使えない？ 明日技術から連絡させます
07/22(月) 技術から電話で連絡、納得したフリ、明日契約から連絡させます
07/23(火) 契約から電話で連絡、契約変更に同意する
07/27(土) 工事日の調整、08/02(金)の午後に決定
08/02(金) 12時半〜13時で工事完了

　 光ケーブルの芯ムキを見せてもらったりしながら「10Gbpsの契約って多いっすか？」という、ちょっとアブナイ話題を振ってみる。と、もう千件を越えているそうだ。フムン。そこでさらに「それって意味あるんすかね」とツッコむ。すると「ひとりだけ目の前でスピードテストしてくれましたよ、8Gbpg以上出てました」とのこと。まぁ、要するに10Gbpsを活用できているのは、その人を含めたヒト握りの剛のモノだけですよ、という意味だな。まぁ、商売ってのはねぇ、まぁ……商売だからね。

　 さて、テレワークの途中での工事だったので、当然ながら仕事の画面は切断された。とりあえずLinuxルータをハサむのは後にして「モデム無線ルータ」からのLANケーブルをスイッチにブッコむ。手元のPCのNICを上げ直すが、再度LinuxルータのDHCPを拾ってしまう。仕方ないのでスイッチからLinuxルータを外し、もう一度NICを上げ直したらIPアドレスが替わり、外につながるようになった。とりあえずテレワーク接続は復活。ややこしい挑戦は晩にやろう。

　 我が家は各部屋にLANケーブルを引いてあるが、居間以外は1本だけにケチったために、書斎はチープな100Mbpsのスイッチで2本に増やしている都合上、今回の速度アップの恩恵は受けられない。が、テレワークの画面転送やYouTubeの再生なんて実のところ100Mbpsでもオーバスペックなんだよね。

　 さて、仕事が終わって、ジョギングして、晩飯を食って、マンガ読んで、ようやく本題。PPPoE接続に挑戦だ。

　 回線屋が置いていったのは「F5648」という機器。紙の「簡易ユーザガイド」というペラ紙は付けてくれたが、フルスペックのマニュアルはネット経由で読めというがイマフーだ。で「F5648」でググれば一発でマニュアルに到達。なになに「PPPoEブリッジの設定」「初期値:オン」と。あ、うん。そだよね。

　 一度「ホームゲートウェイ」をスイッチから外し「Linuxルータ」をつなぐ。手元のPCにLinuxルータのDHCPからIPを振られたところで、Linuxルータにログイン。PPPoE接続の設定を、前のプロバイダであるODNの設定から変更する。

# nmcli connection modify pppoe-enp2s0 username '123456789012@commufa.jp' password 'xxxxxxxx'

　 「ホームゲートウェイ」を「Linuxルータ」のもう片側につないで、I/Fをアップ。

# nmcli connection up pppoe-enp2s0 

　 あれ、ダメ!? ……と思ったら、再度やったら成功した。え、これだけ？ ……というわけで、やっぱりというか、別に「お使いの無線ルータは使えなくなります」ということはまったくなかった。まぁ「使う必要はない」という意味なら合っているが。

　 さてと。では、実力を拝見。「Linuxルータ」上でデカいファイルを落としてみる。Fedoraのインストールイメージでいいや。

Fedora-Everything-netinst-x86_64-40-1.14.iso  100%[===>] 774.63M  88.8MB/s 時間 8.4s     

　 88.8MB/sということは710.4Mbps。コンテンツのダウンロード速度だけで理論値の70%以上出ている。以前の100Mbpsだったら、理論値の100%が出ても62秒を要するのだから、それが8秒チョイで済んでいるのは助かる。アップグレードしてよかったと言えよう。

　 以下はその時のdstatの結果。recvが200Mオーバだが、これは物理NICであるenp2s0とppp0とで二重計上されているためなので、2で割る必要がある。200Mなら100Mで800Mbps。理論値の80%以上出ていることがわかる。

# dstat 1
----total-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read  writ| recv  send|  in   out | int   csw 
  8   2  87   2   0|   0   266k| 734  1011 |   0     0 |1614   642 
  1   0  99   0   0|   0     0 | 316   726 |   0     0 | 122   105 
 14  13  74   0   0|   0     0 | 106M  691k|   0     0 |6695   516 
 48  24  26   0   0|   0    92k| 211M 1279k|   0     0 |  17k 1002 
 48  24  28   0   0|   0     0 | 212M 1310k|   0     0 |  18k  868 
 39  23  37   1   0|   0   340k| 212M 1325k|   0     0 |  17k  946 
 25  21  53   0   0|   0    88k| 215M 1296k|   0     0 |  16k  508 
 26  22  53   0   0|   0     0 | 216M 1301k|   0     0 |  16k  333 
 47  24  29   0   0|   0     0 | 207M 1224k|   0     0 |  17k 1076 
 47  25  23   5   0|   0    94M| 205M 1261k|   0     0 |  15k 1314 
 30  15  52   2   0|   0    82M| 114M  650k|   0     0 |7992  1650 
  0   0  99   0   0|   0     0 | 435   808 |   0     0 | 110   112 
  0   0  98   1   0|   0    76k|1104  1910 |   0     0 | 201   175 

　 ちなみに、以下は7/28に超RIZIN3を観ていた時のトラフィック。WAN回線はアップグレード前の100Mbpsだ。息子が自室のPCで、夫婦がリビングのテレビで(19:10過ぎから)観ている、という状況。

　 enp2s0が100MbpsのWAN側、enp3s0が1GbpsのLAN側なので、送受信量(tx/rx)が逆転の関係にあったり、インタフェイス利用率(%ifutil)に10倍の差があったりするのが面白い。しかし、WAN側でも利用率13%程度なのだな。ハイビジョン映像のトラフィックつうても、たいしたことはない。

00:00:02        IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s   %ifutil
19:00:28       enp2s0    777.06    546.32   1053.54     54.29      0.00      0.00      0.00      8.63
19:00:28       enp3s0    547.48    778.35     51.03   1047.67      0.00      0.00      0.01      0.86
19:10:23       enp2s0    786.91    560.42   1064.08     56.07      0.00      0.00      0.00      8.72
19:10:23       enp3s0    561.40    788.12     52.54   1058.07      0.00      0.00      0.01      0.87
19:20:07       enp2s0   1046.87    599.02   1435.94     58.85      0.00      0.00      0.00     11.76
19:20:07       enp3s0    600.48   1048.39     55.03   1428.08      0.00      0.00      0.01      1.17
19:30:23       enp2s0   1176.59    723.81   1623.07    156.20      0.00      0.00      0.00     13.30
19:30:23       enp3s0    724.96   1177.81    151.31   1614.11      0.00      0.00      0.01      1.32
19:40:13       enp2s0   1144.73    867.22   1587.21    307.30      0.00      0.00      0.00     13.00
19:40:13       enp3s0    868.70   1146.36    301.48   1578.65      0.00      0.00      0.01      1.29
19:50:28       enp2s0   1142.82    861.12   1592.37    293.49      0.00      0.00      0.00     13.04
19:50:28       enp3s0    863.21   1144.96    287.62   1583.80      0.00      0.00      0.01      1.30
20:00:28       enp2s0   1161.78    848.68   1600.73    293.89      0.00      0.00      0.00     13.11
20:00:28       enp3s0    850.56   1163.62    288.19   1591.99      0.00      0.00      0.01      1.30
20:10:14       enp2s0   1164.75    863.29   1602.01    300.75      0.00      0.00      0.00     13.12
20:10:14       enp3s0    865.55   1166.87    294.93   1593.27      0.00      0.00      0.02      1.31
20:20:28       enp2s0   1170.17    852.83   1609.58    297.37      0.00      0.00      0.00     13.19
20:20:28       enp3s0    854.83   1172.10    291.58   1600.80      0.00      0.00      0.01      1.31
20:30:28       enp2s0   1137.20    873.26   1586.78    308.17      0.00      0.00      0.00     13.00
20:30:28       enp3s0    875.02   1138.98    302.21   1578.21      0.00      0.00      0.01      1.29
20:40:24       enp2s0   1135.81    874.62   1583.80    310.24      0.00      0.00      0.00     12.97
20:40:24       enp3s0    876.25   1137.47    304.23   1575.22      0.00      0.00      0.01      1.29
20:50:03       enp2s0   1150.92    857.92   1595.65    293.78      0.00      0.00      0.00     13.07
20:50:03       enp3s0    859.83   1152.80    287.91   1587.00      0.00      0.00      0.01      1.30
21:00:14       enp2s0   1020.80    697.09   1397.78    237.48      0.00      0.00      0.00     11.45
21:00:14       enp3s0    698.16   1021.98    232.70   1390.05      0.00      0.00      0.01      1.14
21:10:01       enp2s0    922.05    311.97   1193.81     40.18      0.00      0.00      0.00      9.78
21:10:01       enp3s0    312.73    922.96     37.71   1186.86      0.00      0.00      0.01      0.97

　 で、回線の1Gbpsへのアップグレード後、試しにリビングのテレビでABEMAのアニメを観てみた場合のトラフィック。550K、4.4Mbpsであるが、enp2s0、enp3s0とも1Gbpsになったため、どちらの利用率も4.4/1000で0.45%となっている。

00:00:02        IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s   %ifutil
12:30:28       enp2s0      8.18      9.13      2.98      1.66      0.00      0.00      0.03      0.00
12:30:28       enp3s0      6.37      6.02      1.18      2.55      0.00      0.00      0.00      0.00
12:40:16       enp2s0    128.73     21.80    174.67      2.59      0.00      0.00      0.03      0.14
12:40:16       enp3s0     22.60    129.46      2.49    173.65      0.00      0.00      0.00      0.14
12:50:24       enp2s0    388.45     36.59    548.85      3.44      0.00      0.00      0.03      0.45
12:50:24       enp3s0     37.63    388.96      3.25    545.30      0.00      0.00      0.00      0.45
13:00:28       enp2s0    145.23     18.59    201.49      1.98      0.00      0.00      0.03      0.17
13:00:28       enp3s0     18.95    145.91      1.84    200.17      0.00      0.00      0.00      0.16

　 それにしても、ネットワーク環境はもう少しイジりたいな。

　 先日「我が家は各部屋にLANケーブルを引いてあるが、居間以外は1本だけにケチったために、書斎はチープな100Mbpsのスイッチで2本に増やしている」と書いた。「テレワークの画面転送やYouTubeの再生なんて実のところ100Mbpsでもオーバスペックなんだよね」というのも事実ではあるのだが、せっかく外と1Gbpsでつながるようになったのに、ちょっともったいない話でもある。

　 そこで1Gbpsのスイッチを買うという手もあろうが、それも本筋ではない。ここは、もう1本、小屋裏からLANケーブルを敷くべきだろう。各部屋にあるコンセントパネルの多くは、LANローゼットが増やせるように予備の場所を設けてあり、そこにはメクラ蓋がしてある。そしてコルゲートチューブにはもう1本通せるくらいの余裕もある。

　 しかし、どうやってLANケーブルを通すのか。3階から1階だ。10mは越えるだろうから、ケーブルを押すだけで通るとは思えない。わざわざ業者さんに頼むのもシャクだ。

　 現状で通っているLANケーブルを呼び線の代わりにして、それを引き抜きながら2本のケーブルに入れ替える、という方法もあろうが、失敗すれば2本どころか0本になってしまうのでリスクがある。それ用の工具としての呼び線を買うという手もあるが、何メートル必要になるか判然としないし、そもそもエラく高い。

　 というわけで、しばらくグルグルと考えていたのだが、ふと、フワッとしたナイロンの荷造り紐を掃除機で吸い出す方法を思いついた。まぁ、そんなにうまくいくはずもないだろうが、ダメモトで……

　 ……え? なんと! うまくいってしまった。しかも、クトゥルフもビックリのアッサリ加減で、だ。驚いたな。

　 試験のつもりだったので、まったく増設する必要のない2階の物干し部屋での成功であり、本命の1階で成功するかどうかはわからないが、とりあえずは喜ばしい。ちなみに、紐の長さ(=管の長さ)を測ってみたら10mチョイであった。結構、長い。

　 その長さのLANケーブルとなると100mのリールで買うことになるのだろうな。この機にカテゴリ6Aを敷くというテもあろうが、スイッチが1Gbpsなのにキバッてもムダだし、一度、敷いてしまえば、次に敷き替えるのも容易だろう。まずはカテゴリ5eでいいかな。

　 世はAI流行りであるが、AIへの関わり方もイロイロで、スマホで語りかける関わり方もあれば、ゼロから学習させる関わり方もある。以前にやった画像認識は、既存のモデルを使っているからその中間か。で、いまは仕事で、客からの問い合わせに対する回答文の自動作成に取り組んでいる。半ば遊びでもあるのだが。

　 日本語で既存の生成AIに問い合わせる形なので、HTTP経由でAPIを叩いているだけであり、技術レベルとしては上記の画像認識よりも浅い。しかし「客からの問い合わせ(メール)に応答し」さらに「客からの『再』問い合わせ(メール)にも応答する」となると、メールのハンドリングだけで地味に大仕事である。キチンとメールを蓄積しておき、キチンとスレッド単位でメール本文を引き出せなくてはならない。軽く「メール本文」て言うけど、エンコード方式はひとつじゃないし、マルチパートだったりするしで、容易ではない。

　 そこに絶好なのが自作のメーラである「Mave」だ。メールの着信を検知したら、そのメッセージIDを元に、過去のメールをスレッドの頭から順に取り出すことができる。

mail0 = folder.get_mail_by_message_id(message_id)
mail0.folder.thread_sqs(mail0.sq).each {|sq|
	mail = mail0.folder.get_mail(sq)
	mailbody = ''; 	mail.body_each {|line|
		mailbody << line
	}
  :

　 我ながら、悪くないコードだ。sqってのは各メールのシーケンス番号。これだけのコードで、過去の問い合わせの経緯をまとめることができる。

　 で、本題。まとめた経緯をAIに渡し、自動作成させた回答文をAIから受取り、どうする？ 客に返す……のはちょっと早すぎる。当面は回答作成担当者へのサジェスチョンに使うのがせいぜいだ。が、どっちにしろ、回答文はメールで送ることになる。どうやって？

　 以前に書いたライブラリを使おうと思ったが、そこでふと思いついた。外からMaveのメール受信機能を拝借してメールをpopするmave_fetchコマンドがあるのだから、逆に、外からMaveのメール送信機能を拝借してメールをsmtpするmave_sendコマンドがあってもいいんじゃないかと。

　 そうすれば、改めて送受信アカウントなどを設定する必要もなくなるし、勝手に「送信済み(Sent)」フォルダにメールが残るし、勝手に「電子署名(S/MIME)」にも対応することになり、いいことづくめだ。

　 で、書いてみたら、紆余曲折の末、実質は以下だけで済んでしまった。我ながら、無駄がないにも程がある。書いてあるまんまだ。

Encoding.default_external = 'UTF-8'
begin
	mave = MaveController.new({:CONFIGS => @configs})
	header = {}
	header['Subject'] = 'テストメール'
	header['From'] = '送信元 <from@example.com>'
	header['To'] = '送信先 <to@example.com>'
	header['X-Mave-Store-Folder'] = 'Outbox'
	mave.generate_mail(header, [], ['テスト'])
	mave.send_mail_smtp
	mave.kill_mave
rescue
	print($!.message + $/)
end

　 あとはこれを、生成AIとやりとりするコードの後に足すだけだ。はい、これにて、今回の盆栽の剪定作業は終了。いやぁ、盆栽って本当に楽しいもんですねぇ。ではまた。

　 という成果を受けて、同じような要領で1階の書斎まで呼び線を引こうと試したのだが引けなかった。紐を割かなかったのが原因かもしれん。

　 DIYが好きな自分は、こういう状況はむしろ楽しみでもあるし「自前でウマいことやったった」感を味わいたいので、業者さんに頼む気にはならないのだが、ウマくいかなければ、それはそれでそれが心労となる面倒な性格である。なんだろうな、関西人の「高ければウマいのは当たり前」「ウマくても安くなきゃ不満」みたいな気持ちだろうか。知らんけど。

　 要するに本当はこうしたいのだが、ケーブルが1本しか敷かれてないので、現状ではこうなっている、ということだ。

　 だが、そこで思いついた。別に2台同時に高速通信する必要はないし、仕事PCを使う時は、必ず主力PCも立ち上げている。その条件なら、ケーブルを追加しなくても、こういうテがあるではないか。

　 主力PCにイーサネットポートを追加し、ブリッジ(≒スイッチ、≠ルータ)の役割をさせ、仕事PCの通信を中継をさせればいい。手元には100MbpsのUSBイーサしかないが、ちょっと調べたらイマドキはUSB3.0の1Gbpsのモノも千円チョイで買えるようだ。普通に思考すればギガビットのスイッチに置き換えるのが普通の思考であることはわかっているが、上記の方法ならば必要のない時には電源が切れるという利点がある。まぁ、普通に置き換えるだけじゃ面白くないってのもあるんだが。

　 で、ここからが本題。USBイーサを挿したら、主力PC内に仮想ブリッジを設定するのであるが、以前からこのブリッジの設定について、納得のいっていない点があるのだ。なんでブリッジデバイスにIPアドレス付いちゃってんの？

　 ブリッジの設定自体は、GUIからチョイチョイとできてしまい、この状態になる。

# brctl show
bridge name     bridge id               STP enabled     interfaces
bridge0         8000.e86a64573438       no              enp3s0f0     ※本体のイーサポート
                                                        enp4s0f3u4u4 ※USBのイーサポート
 
# ip addr show
enp3s0f0:     <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bridge0 state UP group default qlen 1000
enp4s0f3u4u4: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel master bridge0 state UP group default qlen 1000
bridge0:      <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 172.28.0.99/16 brd 172.28.255.255 scope global dynamic noprefixroute bridge0

　 んが、ネットワークの基本ではあるが、ブリッジつうのはレイヤ2であるから、それ自体にIPアドレスは付かないはずなのだ。同じ理屈でスイッチングハブにもIPアドレスは付かない。スマートスイッチだと管理用のIPアドレスが付くかもしれないが、それは意味が違う。なのに、現状を絵に描くとこう。

　 自分のイメージ的にはこう、もしくは、こう、だと思えるのだが。

　 動いてんだから問題ないじゃん、という考え方もあろうが、サポートでメシ食っている人間としては、その指向はあまりよろしくないので、少し突き詰めてみる。んが、現状の物理デバイスをネタに突き詰めてもいいのだが、実はdockerのコンテナ環境もブリッジを使い倒している。なので、そっちの方面から深堀りしてみることにする。

　 ネタはこないだ導入したミニPCの上の、Fedora40のdocker(podman)環境だ。常々、コンテナを起動するとifconfigってやたら賑やかになるよなぁ、と思ってはいたが、あまり中身を意識したことはなかった。

# ip addr show
podman1:  mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 10.89.0.1/24 brd 10.89.0.255 scope global podman1
veth0@if2:  mtu 1500 qdisc noqueue master podman1 state UP group default qlen 1000
podman2:  mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 10.89.1.1/24 brd 10.89.1.255 scope global podman2
veth1@if2:  mtu 1500 qdisc noqueue master podman2 state UP group default qlen 1000

　 コンテナを立ち上げるとpodmanX, vethXが対で増える。vethXってナニよ？ 試しに母艦とコンテナ両方でtcpdumpを採りながら、母艦からコンテナAにpingを打ったら理解できた。基本tcpdumpに-i anyの指定はご法度だが、最近はI/F名も出るようになって便利なんだよな。

# tcpdump -tt -nn -i any icmp
.220946 podman1 Out IP 10.89.0.1 > 10.89.0.2: ICMP echo request, id 174, seq 1, length 64
.220958 veth0   Out IP 10.89.0.1 > 10.89.0.2: ICMP echo request, id 174, seq 1, length 64
.220973 eth0    In  IP 10.89.0.1 > 10.89.0.2: ICMP echo request, id 174, seq 1, length 64
.221012 eth0    Out IP 10.89.0.2 > 10.89.0.1: ICMP echo reply, id 174, seq 1, length 64
.221016 veth0   P   IP 10.89.0.2 > 10.89.0.1: ICMP echo reply, id 174, seq 1, length 64
.221020 podman1 In  IP 10.89.0.2 > 10.89.0.1: ICMP echo reply, id 174, seq 1, length 64

　 わかりやすい。行きはpodman1 veth0, eth0の順、帰りはその逆順。veth0て、内部にある外向け(?)の仮想のイーサポートってことだったんだな。Virtual-ETHer。つまり、図にするとこうだ。

　 コンテナ間通信を行う場合は、コンテナの所属するネットワーク名を合わせる。つまり、図にするとこうだ。

　 コンテナBからコンテナAにpingを打ってみる。

$ sudo ping 10.89.0.2
# tcpdump -tt -nn -i any icmp
.724550 eth0  Out IP 10.89.0.3 > 10.89.0.2: ICMP echo request, id 175, seq 1, length 64
.724553 veth1 P   IP 10.89.0.3 > 10.89.0.2: ICMP echo request, id 175, seq 1, length 64
.724554 veth0 Out IP 10.89.0.3 > 10.89.0.2: ICMP echo request, id 175, seq 1, length 64
.724570 veth0 P   IP 10.89.0.2 > 10.89.0.3: ICMP echo reply, id 175, seq 1, length 64
.724571 veth1 Out IP 10.89.0.2 > 10.89.0.3: ICMP echo reply, id 175, seq 1, length 64
.724571 eth0  In  IP 10.89.0.2 > 10.89.0.3: ICMP echo reply, id 175, seq 1, length 64

　 さっきと異なり、podman1を経由していない。いやいや、ブリッジを経由しないでパケットが届くわけないよね。逆に考えれば「podman1という名前はブリッジそのものを指しているわけではない」ということになってしまう。podman1は「ブリッジにオマケでくっついているNIC」を指している、と理解すればいいのだろうか？

　 podman1のIPアドレスを外してみよう。

# ip addr show podman1
podman1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 10.89.0.1/24 brd 10.89.0.255 scope global podman1
# ip addr del 10.89.0.1/24 dev podman1
# ip addr show podman1
podman1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000

　 こうすると、コンテナAから母艦へのpingは通らなくなるが、コンテナBからコンテナAへのpingは通る。

　 今回「なんでブリッジデバイスにIPアドレス付いちゃってんの？」てのが納得のいっていない点なので、podman1にIPアドレスが付いていない状態で、母艦とコンテナ間で通信ができればなんとなく納得できる。んが、IPアドレスを付ける場所がなければどうしようもないので、仮想NICを作ってみる。

# ip link add veth101 type veth peer name veth100
# ip link show
veth100@veth101: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000
veth101@veth100: <BROADCAST,MULTICAST,M-DOWN> mtu 1500 qdisc noop state DOWN mode DEFAULT group default qlen 1000

　 仮想NICはペアで互いにリンクした状態で生成されるようだ。veth101の側にIPアドレスを付け、双方をアップする。

# ip addr add 10.89.0.101/24 dev veth101
# ip link set veth100 up
# ip link set veth101 up
# ip addr show
veth100@veth101: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
veth101@veth100: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
    inet 10.89.0.101/24 scope global veth101

　 そして、コンテナBから母艦へpingを打ってみる……が、通らない。そりゃ、veth100/veth101ペアはどこにもつながっていないからだ。veth100の方をブリッジにつなげてやる。

# brctl show
bridge name     bridge id               STP enabled     interfaces
podman1         8000.26d98dba414b       no              veth0
                                                        veth1
# brctl addif podman1 veth100
# brctl show
bridge name     bridge id               STP enabled     interfaces
podman1         8000.26d98dba414b       no              veth0
                                                        veth1
                                                        veth100

　 つまり、図にするとこうだ。

　 で、再度コンテナBから母艦へpingを打ってみると……

$ sudo ping 10.89.0.101
# tcpdump -tt -nn -i any icmp
.923306 eth0    Out IP 10.89.0.3 > 10.89.0.101: ICMP echo request, id 173, seq 1, length 64
.923310 veth1   P   IP 10.89.0.3 > 10.89.0.101: ICMP echo request, id 173, seq 1, length 64
.923311 veth100 Out IP 10.89.0.3 > 10.89.0.101: ICMP echo request, id 173, seq 1, length 64
.923311 veth101 In  IP 10.89.0.3 > 10.89.0.101: ICMP echo request, id 173, seq 1, length 64
.923378 veth101 Out IP 10.89.0.101 > 10.89.0.3: ICMP echo reply, id 173, seq 1, length 64
.923379 veth100 P   IP 10.89.0.101 > 10.89.0.3: ICMP echo reply, id 173, seq 1, length 64
.923381 veth1   Out IP 10.89.0.101 > 10.89.0.3: ICMP echo reply, id 173, seq 1, length 64
.923381 eth0    In  IP 10.89.0.101 > 10.89.0.3: ICMP echo reply, id 173, seq 1, length 64

　 通ったー!! んが、結局ここまでやってわかったことは「そんな面倒なことしなくて済むように」「ブリッジにはオマケでNICがくっついて」いて、それが「ブリッジデバイスにIPアドレス付いちゃってる」ように見える、ってことっぽい。

　 ちなみに、コンテナBは、podman1のアドレスがデフォルトゲートウェイになっていて、DNSもそこを指しているので、そのIPアドレスを外してしまっている現状では、外と通信することができない。デフォルトゲートウェイをveth101にし、別のDNSを参照するようにすれば、外と通信することができるようになる。つまり、podman1のIPアドレスを外し、veth100/veth101で通信するようにした状態も、特に間違っているわけではないということだ。

$ ip route show
default via 10.89.0.1 dev eth0 proto static metric 100 
10.89.0.0/24 dev eth0 proto kernel scope link src 10.89.0.3 
$ sudo ip route delete default via 10.89.0.1
$ ip route show
10.89.0.0/24 dev eth0 proto kernel scope link src 10.89.0.3 
$ sudo ip route add default via 10.89.0.101 dev eth0
$ ip route show
default via 10.89.0.101 dev eth0 
10.89.0.0/24 dev eth0 proto kernel scope link src 10.89.0.3 
 
$ cat /etc/resolv.conf 
search dns.podman
nameserver 10.89.0.1
$ sudo vi /etc/resolv.conf
$ cat /etc/resolv.conf 
search dns.podman
nameserver 172.28.0.1
 
$ curl www.example.com
<!doctype html>
<html>
<head>
    <title>Example Domain</title>
      :

　 結局、まぁそうだろうな、というトコロに落ちたわけだが、今回の試行を通じて、コンテナネットワークに関する知見も増えたし、様々なipコマンドの使い方も身に付いた。つまるところプログラミングもネットワークも経験の積み重ねなんだよね。で、肝心の仕事PCへの中継についてもできているのだが、それはまたもう少しネタを揃えて後日まとめるとして……別の意味で「自前でウマいことやったった」状態になっちまったいま、楽しみのような苦しみのようなケーブルの増設作業はどうすんだオレ……。

　 ここ数日、いわゆる人間ドックの受診に備えて対策をしてきた。

　 といっても、イカにもそのヘンのオッサンがやりそうな「悪い数字が出ないように直前だけ酒量や油モノを控える」などという低レベルな対策とは根本から異なる。

　 自分はもう4年ぐらい前から、キッチリと運動習慣を身につけていて、既にスッキリとしたカラダを手に入れ、維持できているからだ。じゃ、どんな対策をするかといえば、少しだけ炭水化物を絞って、よりスッキリしたカラダになることと、胃カメラで必要になる絶食に備えることだ。

　 自分はボディビルダではないが、一応、そっち側の世界の知識もカジっている。意外かもしれないが、彼らは常にバッキバキのカラダを維持しているわけではない。脂肪の量を極限まで落としたバッキバキ状態の維持は極めて困難で、実は健康には良くないのだ。病気になりやすいほどらしい。だからコンテストの日にピークに達するように調整し、その後はすぐに緩めるのである。

　 今回、自分がやったのも程度は違うが似たようなもので、普段はドンブリイッパイ食っている昼と夜の炭水化物を少し減らす。それだけで10日で1kg減るのだ。普段の筋トレでそういう「燃費の悪い」カラダに仕上げているから。で、人間ドックが終わったら緩める。

　 そして絶食への備え。これもボディビルダの世界の話だが、カラダは小さな穴のあいた風船みたいなもので、空気を入れるのを緩めれば、緩めた分だけ徐々にシボんでいくものなのだ。つまり、運動量と栄養素の供給を緩めれば、緩めた分だけカラダも徐々にシボむ。一度ムッキムキに仕上げたらそれで終わりではないのだ。ムッキムキであればあるほど、運動量と栄養素の「継続的な激しい供給」が必須なのだ。

　 「ダイエット」なんて言っている連中は、ここを誤解している人が多い気がする。運動であれ、食事制限であれ、それで痩せたカラダを維持したいのならば、ずっと継続する必要があるのだ。「リバウンド」なんて特別な現象でも何でもないのである。近所のジムに「人生最後のダイエット」なんて宣伝文句が掲げてあるのだが「目標に達したら終わるから最後」なのか「目標に達しても継続するから最後」なのか、どっちの意味なのだろう。ジムの経営者なら知らないはずはないだろうからミスリードを誘っているのか。真実は間違いなく後者だ。ワルキューレの「AXIA～ダイスキでダイキライ～」の「♪もう君を想い出したりしない、だって一度も忘れることないから」みたいだな。

　 だからこそ、ボディビルダが恐れるのが運動量と栄養素の供給のストップである。「カタボる」からである。「カタボる」とは「カタボリックする」という意味で、要するに筋肉をエネルギーに変換することで減らしてしまう事象を指す。筋肉は使い続け、タンパク質で増築し続け、必要なエネルギー量は炭水化物から供給し続けたいのだ。ボディビルダに絶食は禁忌なのである。

　 もうひとつ問題がある。人間ドック前日は激しい運動をしてはいけないのである。激しい運動をすると、多少なりとも筋肉が壊れるので、血中の老廃物が増え、それが腎臓機能の低下として誤診断されてしまうからだ。

　 自分はボディビルダではないが、上記のような理屈を知っているから、絶食も禁トレもモノスゴくイヤなのだ。なにより、筋トレもジョギングも、イザ禁止されると、妙に手持ち無沙汰になって落ち着かない気持ちになってしまう。数年前までは運動が好きな性格じゃなかったのになぁ。運動習慣って、逆に怖いわ。

　 というわけで、絞りきっているわけではないが、現在の状態である。

　 実は先日、Amazonで衣料を買った。暑いので外に着て出られるゆったりとしたタンクトップと、ミリタリテイストのパンツなのだが、前者が2XLなのに、なんと後者はSである。2XL, XL, L, M, Sであるから、上半身と下半身とで4段違いである。サイズを確認した上での注文なのに、さすがに大丈夫なのか不安だったが、届いたらピッタリであった。それが上で着けているパンツだ。腹回りにはまだ余裕がある。しかし、この歳でタンクトップ着て外に出られるのは、ちょっと誇らしい。運動するようになってホントによかった。前にも書いたが、猫背も撫で肩も胃下垂も、筋トレで治るのだ。

　 そして、前々日まで鍛えまくり、当日の零時まで食べまくり、そして早朝、指定の粥を食べたら胃カメラまで絶食だ。検査は午後。胃カメラがツラくないといえばウソになるが、本当にツラいのは待ち時間の方だ。空腹には慣れてないし、サッサと終わって糖質(＝炭水化物、エネルギー)を採りたい。胃カメラは、実施前に喉に麻酔をするため、終わっても麻酔が切れるまで1時間の飲み食い禁止を言い渡されるのだが、いつもそれを無視して病院を出るなりコーラとプロテインと弁当を掻き込んでいる。あぁ、ようやく終わったよ。

　 しかし、50歳近くにもなって運動を始めるとは思わなかったが、決してそういう人も少なくはないようだ。加齢で気が長くなるからかもしれない。それでも決して遅くはなく、間違いなく成果は出る。だから、気分的にはこれからも続けられそうな自信はあるのだが、逆に肉体的にはいつまで続けられるのだろうな……。

　 普通のノートPCにUSBイーサを追加し、ブリッジの役割をさせることで、スイッチングハブなしに有線接続の機器を増やすという思いつきの続きだ。

　 実際にブリッジまで組んでみたものの、なぜか仕事PCにIPアドレスが付かないために通信ができない。ブリッジを挟んだってサブネット(172.28.0.0/16)は同じなんだから、既存のLinuxルータのDHCPからIPを振られることを期待してたんだが、なんでや？ ……と、思ったが、ブリッジはブロードキャストを通さないのであった。DHCPはクライアントがブロードキャストで「オレのIPくれ〜」と叫ぶのが始まりであるから、それがLinuxルータまで届かなければ、そら付かん。

　 そういう時のために、DHCPパケットをリレーするデーモンがなかったけな、と思って探したらあった。「dhcp-relay」だ。

# dnf install dhcp-relay
# cp /lib/systemd/system/dhcrelay.service /etc/systemd/system/
# vi /etc/systemd/system/dhcrelay.service 
# diff /usr/lib/systemd/system/dhcrelay.service /etc/systemd/system/dhcrelay.service 
< ExecStart=/usr/sbin/dhcrelay -d --no-pid
> ExecStart=/usr/sbin/dhcrelay -d --no-pid 172.28.0.1
# systemctl daemon-reload
# systemctl start dhcrelay
# systemctl status dhcrelay
# systemctl enable dhcrelay

　 これで、無事にIPアドレスが付いた……のだが、まだ通信ができない!? え、なんで!?

　 どうやって情報を見つけたのか忘れたが、Linuxのブリッジにはなぜか「iptablesを通す(→結果、捨てられる)」という仕組みがあるらしい。セキュリティレベル強化の一環なのだろうが、機能の積み重ね(レイヤ)的におかしなことになっていないか、それは？ 基本レイヤ3を扱い、ルータのレイヤに居る「ip」tablesなのだよね。まぁ、理屈は置いといて、その動作は以下で解除できるらしい。

# cat /proc/sys/net/bridge/bridge-nf-call-iptables 
1
# echo 0 > /proc/sys/net/bridge/bridge-nf-call-iptables 
# cat /proc/sys/net/bridge/bridge-nf-call-iptables 
0

　 再起動後も有効になるようにsysctlに書いておく。ついでなので、一族郎党皆殺し。

# sysctl -p /etc/sysctl.d/50-bridge-nf-call.conf 
# vi /etc/sysctl.d/50-bridge-nf-call.conf
# cat /etc/sysctl.d/50-bridge-nf-call.conf
net.bridge.bridge-nf-call-arptables = 0
net.bridge.bridge-nf-call-ip6tables = 0
net.bridge.bridge-nf-call-iptables = 0

　 無事、通信ができるようになった……と、ここで気づいたのだが、さっきの「dhcp-relay」って必要だったのか？ ホントに「ブリッジはブロードキャストを通さない」んだっけ？ と思って、改めて調べたら、ブロードキャストを通さないのはルータだ。ブリッジはブロードキャストを通す。「MACを学習して必要のないパケットをフィルタする」というブリッジ/スイッチの特性と混同していたようだ。

　 「dhcp-relay」はサブネットが異なる(ルータの先の)場所にDHCPサーバが置けるようにすることで、DHCPサーバを集約するためのものだ。「dhcp-relay」を落とした後も、仕事PCへのIPアドレスの付与に影響はなかった。「dhcp-relay」で改善したのも確かっぽいが、真の原因はブリッジがiptablesを通していたこと。ま、試行錯誤する中ではよくあることよ。

　 通信ができるようになったところで、お楽しみのスピードテスト。まずは、普通に主力PCで試してみる。普通つうても、こいつの上流にもLinuxルータはいるんだけれどね。

　 結果は「下り808.6Mbps, 上り865.8Mbps」。理論値の8割以上も出ているんだから十分だろう。その時のdstatの結果が以下。

# dstat 1 
----total-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read  writ| recv  send|  in   out | int   csw 
  4   3  89   0   0|   0   140k|   0     0 |   0     0 |8856    13k
  3   2  93   0   0|   0   381k|  10k   12k|   0     0 |4999  6892 
  4   2  91   0   0|   0   384k|  33k 8780 |   0     0 |6221  8058 
 28  11  57   0   0|   0     0 | 206M 1409k|   0     0 |  59k   24k
 27  11  58   0   0|   0     0 | 211M 1278k|   0     0 |  60k   24k
 20  10  66   0   0|   0     0 | 118M   47M|   0     0 |  42k   21k
 23  10  61   0   0|   0  4093B| 406k  239M|   0     0 |  22k   20k
 25  11  59   0   0|   0     0 | 432k  240M|   0     0 |  22k   20k
 23  10  60   0   0|   0    40k| 405k  235M|   0     0 |  22k   20k
 24  10  59   0   0|   0     0 | 412k  238M|   0     0 |  22k   20k
 23  11  59   0   0|   0   152k| 377k  238M|   0     0 |  22k   21k
 20  10  63   0   0|   0     0 | 397k  217M|   0     0 |  21k   19k
 22  11  61   0   0|   0    40k| 469k  217M|   0     0 |  21k   19k
 20  10  64   0   0|   0     0 | 403k  232M|   0     0 |  21k   20k
 27  13  54   0   0|   0     0 | 470k  236M|   0     0 |  22k   21k
 17   8  70   0   0|   0    56k| 268k  136M|   0     0 |  16k   16k
  6   3  89   0   0|   0    56k|  18k 9246 |   0     0 |7390  9949 
  4   2  92   0   0|   0   104k| 110    70 |   0     0 |5797  8192 
  3   2  93   0   0|   0     0 | 236   654 |   0     0 |4232  5827 

　 recvが200M前後、sendが220M前後。前に書いた時はenp2s0とppp0との二重計上だったが、今回はenp3s0f0とbridge0とで二重計上されている。2で割ると、200Mなら100Mで800Mbps、220Mなら110Mで880Mbpsなのでだいたい合っている。usrが20%、sysが10%というCPU使用率も着目点だ。スピードテストはhttps/tcp通信っぽいが、十分に余裕があるといえよう。

　 次は、本題の仕事PC。さて、ブリッジを通してもちゃんと速度が出るのか。

　 結果は「下り835.0Mbps, 上り859.1Mbps」。ほぼ同等に出ているといえよう。その時のdstatの結果が以下。

# dstat 1 
----total-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read  writ| recv  send|  in   out | int   csw 
 11   4  78   4   0|   0   100k| 386B   66B|   0     0 |2345  5408 
 13   5  77   2   0|   0     0 | 326B   66B|   0     0 |2716  7648 
 10   4  82   3   0|   0     0 | 386B   66B|   0     0 |2219  5155 
 30  13  55   1   0|   0     0 |  37M   96k|   0     0 |  19k 9051 
 28  24  45   2   0|   0     0 | 106M  183k|   0     0 |  46k   12k
 27  23  48   1   0|   0     0 | 106M  184k|   0     0 |  46k   12k
 25  18  54   2   0|   0     0 |  65M   12M|   0     0 |  37k   12k
 25  13  61   1   0|   0     0 | 289k  110M|   0     0 |  71k   11k
 24  11  62   2   0| 128k  140k| 316k  110M|   0     0 |  70k   10k
 26  10  62   1   0|   0     0 | 309k  111M|   0     0 |  70k   10k
 24  11  63   1   0|   0     0 | 312k  109M|   0     0 |  69k   10k
 24  11  62   1   0|   0     0 | 322k  110M|   0     0 |  70k   10k
 25  12  61   1   0|   0     0 | 327k  110M|   0     0 |  69k   10k
 25  13  62   2   0|   0     0 | 351k  110M|   0     0 |  69k   11k
 23  11  62   2   0|   0    60k| 309k  109M|   0     0 |  69k   10k
 24  11  62   2   0|   0     0 | 294k  110M|   0     0 |  70k   11k
 23   9  64   2   0|   0    16k| 294k  110M|   0     0 |  70k   10k
 23   5  68   1   0|   0     0 |  60k   21M|   0     0 |  17k 7024
 13   4  79   2   0|   0     0 | 326B   66B|   0     0 |2535  5668
 18   6  73   2   0|   0     0 | 803B 2957B|   0     0 |3026  5645
 10   4  83   3   0|   0     0 | 326B   66B|   0     0 |2197  4736

　 こっちに二重計上はない。recvが105M前後で840Mbps、sendが110M前後で880Mbpsなのでだいたい合っている。主力PCのそれよりもusrとsysはわずかに高いが、N100のCPU性能がわずかに低いということだ。とはいえ、こちらも十分に余裕があるといえよう。

　 ちなみに、以下は仕事PCの計測中の主力PCのdstatの結果。ブリッジとしての仕事っぷりがわかる。

　 中継をしているのでrecvとsendの両方に値が出ている。中継はカーネルの処理なのでsysが上がるかと思ったが、usrが上がるようだ。とはいえ、中継するだけの場合は、httpsの処理も、tcpの処理もないので、たいして上がることはない。

# dstat 1
----total-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read  writ| recv  send|  in   out | int   csw
  1   1  97   0   0|   0     0 | 214   728 |   0     0 |1991  2843
  1   1  97   0   0|   0    72k| 108   660 |   0     0 |2249  3181
  1   1  97   0   0|   0     0 |  23k   21k|   0     0 |2524  3436
 12   1  83   0   0|   0     0 | 105M  106M|   0     0 |  61k 5648
 10   1  80   0   0|   0   459k| 112M  112M|   0     0 |  56k 5686
 13   1  82   0   0|   0     0 | 111M  112M|   0     0 |  65k 5884
 12   3  80   1   0|   0  2216k|  83M   83M|   0     0 |  25k 9690
  7   1  82   0   0|   0   204k| 115M  117M|   0     0 |  28k 5127
  7   1  83   0   0|   0     0 | 116M  117M|   0     0 |  28k 5053
  6   1  83   0   0|   0     0 | 115M  116M|   0     0 |  28k 5260
 10   2  78   0   0|   0    12k| 115M  117M|   0     0 |  31k 9722
  7   1  83   0   0|   0     0 | 116M  117M|   0     0 |  28k 4925
  7   0  83   0   0|   0     0 | 116M  117M|   0     0 |  29k 5037
  6   1  83   0   0|   0    92k| 114M  116M|   0     0 |  28k 5648
  6   0  84   0   0|   0     0 | 116M  117M|   0     0 |  27k 4842
  5   1  84   0   0|   0     0 | 115M  117M|   0     0 |  27k 4545
  3   0  90   0   0|   0    16k|  68M   70M|   0     0 |  17k 4062
  1   1  97   0   0|   0     0 |  10k 6306 |   0     0 |2274  3165
  1   1  98   0   0|   0     0 | 108   660 |   0     0 |2094  3088
  1   1  97   0   0|   0     0 |3539  4139 |   0     0 |2362  3421

　 さらにオモシロ実験。先に「手元には100MbpsのUSBイーサしかない」と書いたが、実はもうひとつ「LUA-KTX」という100MbpsだがUSB1.1という珍妙なUSBイーサも手元にある。差込口の形状がちょっとカッコイイ。この際だ。全部いっぺんに挿して、全部ブリッジにしちゃって、スピードテストをしてみよう。LANの口が4つて、そりゃもうルータやがな。

　 まずは「USB-LAN100R」という100Mbpsのイーサ。結果は「下り91.6Mbps, 上り92.8Mbps」。LANの速度である100Mbpsが理論値になるから、その9割チョイというのは妥当だ。

　 その時のdstatの結果が以下。

$ dstat 1
----total-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read  writ| recv  send|  in   out | int   csw 
 23   7  67   2   0|   0   189k| 150B  132B|   0     0 |3680  7029 
 18   4  74   2   0|   0    24k|8262B   12k|   0     0 |3122  6281 
 32  10  54   1   0|   0     0 |8876k  140k|   0     0 |  20k   14k
 24  10  61   2   0|   0   568k|  12M  122k|   0     0 |  25k   13k
 24  11  61   2   0|   0   160k|  12M   97k|   0     0 |  24k 9948 
 22  11  63   2   0|   0   112k|  12M  116k|   0     0 |  24k   10k
 23  11  63   2   0|   0    80k|  12M  128k|   0     0 |  24k   12k
 25  11  61   1   0| 128k    0 |  12M  163k|   0     0 |  25k   15k
 22  11  63   2   0|   0     0 |  12M  155k|   0     0 |  25k   15k
 20  10  65   2   0|   0     0 |  12M  105k|   0     0 |  24k   11k
 21  10  62   2   0|   0   112k|  12M  154k|   0     0 |  24k   14k
 21  10  67   2   0|   0     0 |  12M   83k|   0     0 |  23k 9188 
 22  10  64   2   0|  64k    0 |5602k 1651k|   0     0 |  15k   13k
 20  10  67   2   0|   0     0 |  70k   12M|   0     0 |  15k 9059 
 19   7  70   2   0|   0     0 |  72k   12M|   0     0 |  14k 8815 
 20   8  68   2   0|   0   100k|  71k   12M|   0     0 |  14k 8906 
 19   8  69   2   0|   0   192k|  73k   12M|   0     0 |  14k 8677 
 19   7  71   2   0|   0     0 |  72k   12M|   0     0 |  14k 8621 
 19   8  69   1   0|   0     0 |  70k   12M|   0     0 |  14k 8666 
 20   7  70   2   0|   0     0 |  76k   12M|   0     0 |  14k 8834 
 19   6  71   2   0|   0     0 |  68k   12M|   0     0 |  14k 8618 
 19   6  71   2   0|   0     0 |  67k   12M|   0     0 |  14k 8803 
 20   7  69   3   0|   0    32k|  71k   12M|   0     0 |  14k 8345 
 18   6  73   2   0|   0     0 |  65k   12M|   0     0 |  14k 7699 
 18   6  73   2   0|   0     0 |  68k   12M|   0     0 |  14k 7552 
 18   6  72   2   0|   0     0 |  68k   12M|   0     0 |  14k 7671 
 18   6  73   2   0|   0     0 |  67k   12M|   0     0 |  14k 7530 
 20   7  70   2   0|   0    40k|  55k 9391k|   0     0 |  12k 7368 
 21   5  71   2   0| 128k    0 | 804B    0 |   0     0 |3045  5925 
 13   4  80   1   0|   0    60k| 180B    0 |   0     0 |2279  5453 

　 最後に「LUA-KTX」という100MbpsのイーサだがUSB1.1というもの。結果は「下り6.76Mbps, 上り7.62Mbps」。100Mbpsどころか10Mbpsにすら達していない。これはUSB1.1の上限が12Mbpsであることによるもの。

　 12Mbpsなら10Mbps以上は出てもいいと思うかもしれないが、それはUSB通信が半二重モードであるため、受取り確認(ACK)などの逆方向の通信で消費されているためだと推測する。それでも、半分(6Mbps)以上は出ているんだから、そんなもんなんだろう。とはいえ、端末作業やブラウザで探しモノする分には十分な速度だ。ADSLを思い出せば、だいぶ速い方だよね？

$ dstat 1
----total-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai stl| read  writ| recv  send|  in   out | int   csw 
 28   6  63   2   0|   0     0 |   0     0 |   0     0 |3186  6450 
 16   5  75   2   0|   0     0 |   0     0 |   0     0 |2783  6073 
  9   4  84   2   0|   0     0 |   0     0 |   0     0 |2053  4456 
 29   7  60   2   0|   0    76k| 174k   22k|   0     0 |4406  7780 
 24   6  66   1   0|   0     0 | 877k   41k|   0     0 |6371  8781 
 17   7  72   2   0|   0     0 | 872k   41k|   0     0 |6156  8867 
 16   7  73   2   0|   0     0 | 875k   38k|   0     0 |6014  9115 
 18   6  73   2   0|   0     0 | 870k   45k|   0     0 |6202  8721 
 17   7  70   3   0|   0   268k| 876k   37k|   0     0 |6081  9099 
 18   5  73   2   0|   0     0 | 878k   37k|   0     0 |6027  9076 
 17   6  73   2   0|   0     0 | 873k   43k|   0     0 |6086  8812 
 18   6  74   1   0|   0     0 | 872k   45k|   0     0 |6114  8808 
 17   6  73   1   0|   0     0 | 872k   43k|   0     0 |6088  8923 
 16   6  71   3   0|   0   160k| 799k   36k|   0     0 |5790  8879 
 17   7  72   2   0|   0  4097B| 857k   37k|   0     0 |5928  9079 
 18   6  72   2   0|   0     0 | 872k   43k|   0     0 |6237  9042 
 19   6  71   2   0|   0     0 | 234k  725k|   0     0 |5257  9144 
 18   6  72   2   0|   0     0 |  19k  991k|   0     0 |4632  8649 
 17   6  73   2   0|   0     0 |  20k  979k|   0     0 |4618  8607 
 17   6  73   2   0|   0     0 |  21k  986k|   0     0 |4539  8628 
 18   6  71   3   0|   0    12k|  21k  980k|   0     0 |4580  8440 
 16   6  74   2   0|   0     0 |  19k  984k|   0     0 |4605  8663 
 18   5  74   2   0|   0     0 |  23k  985k|   0     0 |4555  8589 
 17   6  74   2   0|   0     0 |  21k  977k|   0     0 |4552  8539 
 17   6  74   2   0|   0     0 |  19k  984k|   0     0 |4505  8515 
 17   7  73   2   0|   0     0 |  22k  986k|   0     0 |4639  8497 
 16   6  74   2   0|   0     0 |  24k  983k|   0     0 |4266  7642 
 17   5  74   2   0|   0     0 |  17k  986k|   0     0 |4183  7428 
 17   6  75   2   0|   0     0 |  16k  986k|   0     0 |4106  7359 
 15   5  74   2   0|   0     0 |  16k  994k|   0     0 |4296  7696 
 17   5  75   2   0|   0     0 |  16k  984k|   0     0 |4070  7295 
 22   6  69   2   0|   0     0 |6947B  309k|   0     0 |3674  6804 
 12   3  80   2   0|   0     0 |   0     0 |   0     0 |2376  4758 
 13   5  79   2   0|   0     0 |  60B   42B|   0     0 |2448  5640 
 16   5  76   2   0|   0     0 |3499B 6017B|   0     0 |2898  5357

　 つうわけで、たった千円チョイの投資で、希望の通信環境と、多くの知見と、楽しい謎解きの時間を手に入れることができた。そういう時間って、実は狙って手に入れることが難しい。課題を見つけることが難しいし、対象が難しすぎれば解けないし、一度解いたら終わってしまうから。これまでに何度か書いているが、学生時代にセガマーク3用のトラックボールをジャンク扱いで購入し、試行錯誤(当時、電子工作の知識なし)でX68kにつなげたことがあったが、まさにああいう楽しさなんだよなぁ。

　 なにしろ捕虜が「手を振る」という仕草が衝撃だった。チョップリフターだ。詳しい経緯は忘れたが、最初に目にしたのはオリジナルのアップルII版だった気がする。その時はプレイすることはできなかったが。ヘリコプタで飛んでいって、攻撃して、救助して戻る。救助っていうアクションがヘリならではだ。戦争ゲームでも、壊すだけじゃなくて助けるってのがイイ。

　 しかし、なんというか、ゲームとして破綻していないか？ ロクに狙って攻撃できない。ロクに攻撃が避けられない。セガの移植したアーケード版もあるんだが、破綻したゲーム性は似たようなもの。セガらしくない。遊びたいのはそういうゲームなんだから、もっとちゃんと作ってよ。なんでそうなるんだよ。

　 思い返せば、メガドライブで「デザートストライク」というヘリのゲームを遊んだことがある。サイドビューじゃなく、クォータビューだったが、ずいぶん熱中して遊んだ。自分は、そういうゲームが好きなんだ。で、当然のように続編の「ジャングルストライク」を買ったんだが、なぜか操作方法が変わっていた。厳密に言うと「デザートストライク」では3種類から選べたのに、それが固定になっていた。で、ロクに狙って攻撃できない。ロクに攻撃が避けられない。数日は遊んだが序盤で放り投げた。なんでそうなるんだよ。

　 で、先日、セールということで、なんとなく「コンバット！サーチ＆レスキュー」というゲームを買った。100円だし、たいした期待もしていなかった……けど……アレ？ これじゃねぇの？ 俺が遊びたかったのって!?

　 画面がサイドビューなのはチョップリフターと同じだが、ヘリに耐久性があるので、被弾一発ではミスにはならない。いわゆる体力制。自分は基本的に体力制は好きではないのだが、フワフワとしたヘリの挙動を再現するならば、キリキリと弾除けしたりはできないから、そうデザインするほかはない。まぁ、実際のヘリも機銃一発では落ちないしな。

　 なので、被弾ゼロにはできないが、被弾しにくいマニューバをすることが、ゲームの肝になる。そしてヘリの操作方法が衝撃。なんと、基本「L」と「R」という、ふたつのデジタルボタンだけ。それなのに、それで自在に空を飛ばしている感を味わえる。なにせイカにもヘリっぽい浮遊感が秀逸で、離陸も着陸もホバリングも、すごく「してる」感があるのだ。まさに、こういうチョップリフターが遊びたかったんだよ、オレは！

　 そりゃ、細かい粗はいくらでもあるけれど、定価でも800円なので文句をつけてもしゃーない。むしろ、もっとお金を取っていいから、ステージのバリエーションとか増やして欲しいくらいだ。コンプリートしちゃったんだよ。スターもドッグタグも。しゃーない、もう1回データ消して最初からやるさ。

　 調べると、このゲームの開発元はハンガリーのInvictus Gamesってトコらしく、原題は「Dustoff Heli Rescue 2」。2作目だったのね。前作に「Dustoff HeliRescue」と、最新作に「Dustoff Z」があるようだが、どっちも日本のスイッチ向けにはリリースされていない。残念。

　 なんだかX68kで遊んだ「ウィングス」を思い出すな。悪い意味で。やっぱり、ロクに狙って攻撃できない。ロクに攻撃が避けられない。遊びたいのはそういうゲームなんだから、もっとちゃんと作ってよ。なんでそうなるんだよ、ってゲームだったな。あれも。

　 ついでにX68kで遊んだ「クランクトアロウ」「三段変形ファジー」も思い出すな。いい意味で。なんつうか、ほのぼのしたミリタリ感と、独特の操作感なのかなぁ、テイストが似ているんだよなぁ。そういうゲームがしたいなら、自分で作るというテもあるか。うーむ。

　 先日「仕事で既存の生成AIに問い合わせる仕組みを作っている」と書いたが、そのすぐ横で後輩が「手元で生成AI動きました」なんて報告を上げてきた。え、マジッ!?

　 聞くとちゃんとコンテナで上げていて、普通にコンソールから日本語で質問を与えられる状態になっていて驚愕。なにかがうまくいってなくて「こんにちは」の応答に数分かかるようだが、とりあえず動くということだけでスゴい。自分的に、同僚からこういう刺激を与えられるのって、すごく嬉しい。滅多になかったことだ。

　 ollamaという流行りの仕組みを使っているらしい。調べると、それほどの手数を要さずに動くようだ。それほどの超弩級スペックも必要ないっぽい。こういう、同僚からの嬉しい刺激に報いる一番の方法は、すぐに追いついて一緒になって取り組むことだ。

　 というわけで、やってみた。自分はすぐにdocker-compose.ymlにまとめてしまうのが好きなので、以下のようにまとめてしまう。

services:
    ollama:
        image:
            docker.io/ollama/ollama
        container_name:
            ollama-alpha
        ports:
            - "11434:11434"
        volumes:
            - pv:/root/.ollama
volumes:
    pv:
        driver: local
# データを永続的に保持する領域として
# mkdir -pv pv しておくこと
        driver_opts:
            type: none
            o: bind
            device: $PWD/pv

　 ollamaコンテナを上げたら、日本語の言語モデルの導入が必要になる。どの言語モデルを導入するのが適当かわからないので、ググって出てきたサイトのお勧めをそのまま試す。また、Modelfileという定義を書いて初期設定をする必要があるのだが、それもよくわからないので同サイトのお勧めをそのまま試す。

/root/docker/ollama # cd pv
/root/docker/ollama/pv # mkdir llm-jp-13b-instruct
/root/docker/ollama/pv # cd llm-jp-13b-instruct
/root/docker/ollama/pv/llm-jp-13b-instruct # wget llm-jp-13b-instruct-full-ac_001_16x-dolly-ichikara_004_001_single-oasst-oasst2-v2.0-Q4_K_M.gguf
/root/docker/ollama/pv/llm-jp-13b-instruct # vi Modelfile
/root/docker/ollama/pv/llm-jp-13b-instruct # cat Modelfile 
FROM ./llm-jp-13b-instruct-full-ac_001_16x-dolly-ichikara_004_001_single-oasst-oasst2-v2.0-Q4_K_M.gguf
 
PARAMETER temperature 0.7
PARAMETER top_p 0.95
PARAMETER repeat_penalty 1.05
PARAMETER stop "<EOD|LLM-jp>"
 
TEMPLATE """{{ if .System }}{{ .System }}{{ end }}{{ if .Prompt }}
 
### 指示:
{{ .Prompt }}{{ end }}
 
### 応答:
{{ .Response }}<EOD|LLM-jp>"""
SYSTEM """以下は、タスクを説明する指示です。要求を適切に満たす応答を書きなさい。"""
 
/root/docker/ollama/pv/llm-jp-13b-instruct # cd ../..
/root/docker/ollama # docker_exec
# INTO [ollama-alpha].
root@aef3abf257e5:/# cd root/.ollama/llm-jp-13b-instruct
root@aef3abf257e5:~/.ollama/llm-jp-13b-instruct# ollama create llm-jp-13b-instruct -f Modelfile
root@aef3abf257e5:~/.ollama/llm-jp-13b-instruct# ollama list
NAME                       	ID          	SIZE  	MODIFIED     
llm-jp-13b-instruct:latest 	bb43f78e1cbd	8.3 GB	7 seconds ago	
root@aef3abf257e5:~/.ollama/llm-jp-13b-instruct# exit

　 コンテナの中で「ollama create」することで「llm-jp-13b-instruct」という名前で言語モデルを登録している。それが終われば、以下でコンテナの外から日本語で質問を与えられる。

/root/docker/ollama # docker exec -it ollama-alpha ollama run llm-jp-13b-instruct
>>> こんちは。
こんにちは。
 
>>> Send a message (/? for help)

　 「こんちは。」だけなら10秒くらいで応答が返ってきた。速くはないが、N100のローエンドPCで、だからね。

/root/docker/ollama # docker stats
ID            NAME                  CPU %       MEM USAGE / LIMIT  MEM %       NET IO             BLOCK IO           PIDS        CPU TIME      AVG CPU %
aef3abf257e5  ollama-alpha          390.81%     14.72GB / 16.53GB  89.06%      6.952kB / 978B     8.959GB / 2.052GB  30          7m59.065034s  114.62%

　 とはいえ、コンテナの動作状況を見るとパッツンパッツンだ。言語モデルの大きさの7.8Gに対し、メモリは15G弱が専有される。ただし、動作による増減はないっぽい。

　 ちょうど1年半前くらいにChatGPTで遊んでみていたが、手元で動くのはもっと先だと思っていたわ。まぁ、アーケード版に対するファミコン版かもしれんけど、それでも手元で動くのは夢がある。

　 例によって遊んでみよう。

/root/docker/ollama # docker exec -it ollama-alpha ollama run llm-jp-13b-instruct
>>> 1980年台の傑作アーケードゲームを5つ挙げてください。
1980年代のアーケード・ビデオゲームの傑作には以下のようなものがある：
 
ギャラガ
スペースインベーダー
ドンキーコング
パックマン
フロッガー
 
>>> ドンキーコングとはどんなゲームですか？
ドンキー・コング』は、1982年にナムコが開発・発売したアーケード・コン
ピュータ・ゲーム。プレイヤーはアーケード版『キングコング』（1980年）を
基にしたゲームで、アーケード版ドンキーコングのスピンオフ作品。
 
プレイヤーはアーケード版キングコングのキャラクターであるドンキーコング
を操作し、アーケード版キングコングの敵役であるアーケード版キングコング
のキャラクターであるコングを避けながら、バナナを集め、できるだけ長く生
き残ることを目指す。
 
>>> Send a message (/? for help)

　 まぁ、例によって派手にハルシネっているが、それはそれで面白い。

　 実はちょっと前に、社内のAIサービスのAPIを対象にRubyのライブラリを書いていたのだが、どうもAIのAPIというのは、既にデファクトスタンダードがあるようだ。手元にAIがあるなら、転用できるか試してみようかしらん。

　 ガキの頃「銃のプラモデル」を作ったことがある。少なくともふたつ。リボルバーとオートを組んだ記憶がある。弾の発射機能はないが、模擬実包の弾倉への装填が楽しめる。

　 小学生くらいだっただろうから、ヒドい出来だったろうが、妙に記憶に残っている。それほど緻密に銃の構造を再現していたわけでもなかったのだろうが、なかなかに興味深かった。ガンプラでも、その仕組みを自らの手の中で扱うのが、その楽しさの一部だと思う。変形機構なんかがあるものは、特に。

　 で、また作ってみたくなったのだが、当然というか何というか、現在の多くの模擬銃はサバイバルゲームに用いるために発射機能のあるもので、内部構造についての再現度は低そうだ。高価だし。それでも「モデルガン」というジャンルでは、極力内部構造を再現したものもあるが、よりニッチなだけに大人向けの高級志向であり、やっぱり高価だ。

　 そんな経緯でしばらく放置状態だったのだが、先日、ヘリのゲームの新作が遊べないかと、手元のLinuxマシンにダメモトでSteamをインストールしてみたところ、アッサリとインストールできてしまったものの、肝心のヘリのゲームはWindows専用で遊べない。とはいえ、Linuxでもゲームが動くことを確認してみようと、無料ゲームを検索してみたところ「World of Guns: GunDisassembly」というタイトルを見つけた。あれ？ これ……って、もしかして、そういうオイラにうってつけのゲームなんじゃないの!?

　 それがゲームであるかどうかは微妙な内容ではあるが、ひたすらに銃をバラし、バラしきったら、また組み立てる、という内容はまさにやりたかったことだ。画面の中とはいえ、発砲することもでき、それをスローで鑑賞することもできる。うーむ。こういう趣味って、一般的ではないにしろ、普遍的なものなんだなぁ。

　 銃については詳しくなく、西側はM16、東側はAK-47、ルパンはワルサーP38程度の知識しかなかったが、同ゲームにおける「リュウ」は「コルト・ガバメント」だった。そういやガキのころ、なぜか「ガバメント」という英単語に「銃」のイメージを感じていたのはこれが原因だったのか。「政府」という単語に火薬の匂いが被るのが、どうにも不思議だったのだが「官給品」から来ているのね。なるほど。

　 ゲームの中でバラしてみると、意外にパーツ数が多く、容易には手順は覚えられないが、何度もやっているうちにわかってくる。実際に目の前に銃が現れたら、初見でもバラせそうな気さえしてくる。んが、やっぱり実際のパーツを手で感じながらやりたいよなぁ。画面の中では感じ方に限界がある。

　 で、せめてそれっぽいオモチャはないかと検索してみると、なんだか木製のパズルにたどり着いた。こっちはリボルバーな形状だが、素直に魅力を感じる形状でもある。中国製だが、レビューを見ても悪い評価がほとんどない。安価だし、とりあえずポチってみた。

　 1ヶ月かかるといわれつつ、1週間くらいで届いた。さっそく組み立てる。いやはや、パーツの精度は想像以上に高く、どれもカッチリと固定される。数時間で組み上げたが、接着剤なしにもかかわらず、恐ろしいほどのシッカリ感だ。個体差もあるだろうが、少なくとも自分の手元にあるものについては、難クセひとつ付けられないレベルであった。安物感はない。優雅な時間だったなぁ。

　 そんなにいらんよ、というくらい輪ゴムが付いてきたが、同時に6発までは装填できる。シングルアクションながら、動作は確実だ。的も5個付いてくるので、至れり尽くせり。残念ながら、エイムは役に立たないものの、ゴムは概ね同じところに飛んではいく。そういや、ガキの頃に割りバシ鉄砲も無数に作ったよなぁ。いいなぁこれ。手元に置いて手慰みにしちゃいそうだ。

　 最近は「誰でも同じものが作れる」なんてつまんない、と思っていたが、プログラムと違って手で触れられるし、これはこれでたまには楽しいものだな。これだけレベルの高いキットだと、同じシリーズのAK-47も作ってみたくなるな……いや、いっそのことピンボールまでいってしまうのか!?