ContinuityCaptureAgent を止めてintel macの発熱を解消する

mac mini 2018 が爆熱なのをずっとがまんして使っていたが、やっと直すことができた。爆熱の原因はContinuityCaptureAgentプロセスが暴走することだった。このためにCPU温度はアイドル時でも100度になっていた。ContinuityCaptureAgentプロセスが何をしていたかというと、macのカメラとして使うための周囲のiPhoneやiPadを探し続けていた。mac使用者のapple IDに紐づけられているiPhone/iPadを全て探す。それらが周囲になければskipして終わる仕様のプログラムだが、bluetoothになんらかの変化があると再度探し始める。そしてbluetoothのなんらかの変化というのはなぜか常に起こっている。つまりmacを起動してからはシャットダウンするまでずっと探し続ける。私のmacでは毎秒3回探していた。1回あたりiPhoneとiPadを11台探す。11台と多いことが問題ではない。台数が少なければ毎秒のループ回数が増えるだけで、仕事は軽くはならない。

 

ContinuityCaptureAgentプロセスはmacOS 13から導入された。そのためmac mini 2018だけでなく、mac mini 2023でもmac mini 2025でも走っている。ところがCPUロードを30％も消費しているのはintel CPU搭載のmac mini 2018だけで、apple silicon CPU搭載の2023/2025ではCPUロードは1%未満だ。mac mini 2023/2025は熱くならない。これがCPUアーキテクチャのせいなのか、他の理由があるのかはわからない。

 

ContinuityCaptureAgentをkillしても、起動設定でdisableしても、すぐに復活してしまう。airdropやhandoffをオフにしても動き続ける。解決方法はbluetoothをオフにすることだけだ。これでContinuityCaptureAgentプロセスは起動しなくなり、CPU温度は100度から52度まで下がった。このことに気づくまで筐体がさわれなくなるほど熱い状態でmac mini 2018を5年間使い続けてしまった。マシンの寿命をずいぶん削ったことが悔やまれる。

新web serverの構築をclaudeに頼む

PHPを利用していたコンテンツの公開をやめて、今は静的HTMLだけの運用になっている。これだと編集しにくいので、なんらかのツールは使いたい。その辺りも含めて新サーバーの設計をclaudeにお願いした。

 

そしていちばん重要かつ面倒なのが、過去のコンテンツを新サーバーに移すことだ。以前のサイトはなんとかwikiを4つとwordpressとでサグラダファミリアみたいな作りになっていた。その5つのツールからコンテンツをサルベージして新サーバーに移すのもclaudeにお願いした。こんなのを人手でやっていたら疲れるだけで何も得るものがない。

 

新サーバーのマシンは手持ちのPCの中から消費電力の低いものを選んで使う。OSは新規に入れる。さて、どんなサイトができあがるだろうか。 

 

半日でできあがった。なんとhtmlファイルだけのサイトになった。PHPはおろか、動くものは何も使ってない。それなのに、これまでの動作は再現されている。おそるべしclaude code。 

ipv6のゆるいセキュリティのおかげでネットワークが快適に

ipv4のセキュリティはしっかりしているが、ipv6には穴があるというのは業界では常識だ。技術的に穴をふさぐことはできるが、放置されていることもある。

 

ここにセキュアなネットワーク機器がある。ipv4の接続はどうやっても無理だ。証明書や暗号鍵や発信元限定等で二重三重に防御されている。ところがipv6特にローカルリンクアドレス通信は無防備である。これを利用すると通信できる。通信が届くだけであって、突破できるのは発信元を限定している部分だけではある。証明書や暗号鍵は突破できない。

 

証明書や暗号鍵を持っている正規ユーザーならこのネットワーク機器を便利に使うことができる。機器がsshを受け付けるなら基本的になんでもできる。

 

機器をgatewayにして自分の使いやすいPCからネットワーク機器を経由してその先のデバイスにアクセスできる。 これは本当にありがたい。ストレスが8割方減った。その先にはH100とかB100とかのハイパフォーマンスの計算資源がたくさんあるのだ。時間によってはガラガラで、もったいないおばけが出る状態だった。手元のmacからこれらが使える。夢のような環境だ。計算し放題（キュー待ちがあるのでこれは言い過ぎ）だ。

PHP脆弱性対策に本腰をいれる（セキュリティ対策を本気でしたのは生まれて初めて？）

PCを使い始めて46年、インターネットに繋げてから40年経つが、見聞きした全ての脆弱性を無視してきた。全ての脆弱性が「そんなん俺には関係ない」で済んでいたからだ。ところが今回のPHP脆弱性はそうは言ってられなかった。CVE-2026-109618とCVE-2026-109619は上手に攻撃プログラムを作ればサーバーのファイルを読んだり攻撃者が置いたプログラムを実行したりできる。私の自宅のwebサーバーも例外ではなかった。webサーバーは分散処理で3台動かしていたが、先ほどPHPを動かしていた2台を止めた。もう1台はPHPを使っていないのでそのまま動かしている。

 

良い機会なので、サーバーエンジンの見直しと、サーバー内コンテンツの見直しをしようと思う。webサーバーのうち1台は初代apacheが動いていたのだからよくこれまで持ったものだと思う。今後はOSから入れ直してサーバーエンジンはnginxにしようと思う。

musicデータベースを遠隔地に置く

2拠点生活ならぬ3拠点生活になってしまった。それぞれの拠点にLANがあって、楽曲データ入りのNASをおいてある。ラズベリーパイで動かしているLogitech Media ServerがNASの楽曲を読んでクライアントで再生する。NASの中の楽曲は3拠点とも同じだ。冗長である。

 

今回、3拠点LANをVPNで統合できたので、楽曲NASは1台で済むようになった。Logitech Media Serverも1台で済むのだが、ラズベリーパイは電気を食わないので3拠点にそのまま1台ずつ置きっぱなしだ。NASを2台廃止できて電気代的にお得になった。

 

VPNは数年前であればYAMAHA製のルーターを使っただろう。今回はOpenWrtのルーターを使えたので、もっと安く実現できた。 

 

拠点をA/B/CとするとAB間の距離は50kmで、AC間の距離は900kmである。AB間でpingを打つと17msかかる。AC間でpingを打つと45msかかる。拠点のLAN内ではpingは3msだ。スループットは50Mbpsしか出ない。スループットを律速しているのはNASのHDDの読み出し速度と、SMBプロトコルをプロセッサが処理する速度だ。

それでもフリマは犯罪者向けだった

以前に犯罪者が利用することにフリマかオークションかは無関係という報告をした。ところがである。不正な出品はフリマが多い。現在金券はメルカリでもyahooフリマでも出品は禁止されている。しかし堂々と売られている。これはどういう理由だろうか。

 

日本ではメルカリ（フリマ）が犯罪者利用が多く、米国ではeBay（オークション）が犯罪者利用が多いのは以前の報告で述べた通りだ。犯罪者が利用するのはフリマ形式かオークション形式かが理由ではなく、プラットフォームを提供している業者のモラルが低いからだというのが理由だった。しかし、同じ業者であるyahooオークションとyahooフリマを比べるとyahooフリマの方が不正出品が多い。これは業者のモラルでは説明できない。

 

私の仮説はこうだ。メルカリ社のモラルが低かったため、犯罪者はメルカリを好んで利用していた。その後yahoo社がフリマを始めた。犯罪者はメルカリでフリマ形式に慣れていたからという理由で、yahooオークションではなく、yahooフリマを好んで利用しているのではないか。 もうひとつは単に手数料の問題だ。yahooオークションの手数料は10%、yahooフリマの手数料は5%だから、より手数料の安いyahooフリマが選ばれる。

TimeCapsuleSMBにてAirMac TimeCapsuleがSMB対応機として復活

TimeCapsuleSMBが開発されていた。githubからインストーラーを拾える。インストールすると、AirMac TimeCapsuleがSMB対応になってTimeMachine機能が使えるように復活した。

 

SMB対応になっても、AirMacユーティリティはこれまで通り使える。これまでは機器全体の認証パスワードとディスクアクセスの認証パスワードを別々にできていたが、SMB対応後はどちらも同じパスワードとなる。共有ディスクのディレクトリ名もこれまでは任意の名前をつけられていたが、SMB対応後はShareとよくある名前になる。