おのたく日記 YouTubeも始めました→

■ おうちサーバが重いと思ったらAnthropicから激しいアクセスが

マインクラフトをやっている子どもたちが、うちのマインクラフトサーバが遅いと言っているので調べてみたら。

どうやらWebサーバにアクセスが来て、そのさきのMariaDBとか含めて忙しくなっているみたいなので、ログを見たら

[29/Dec/2024:00:20:22 +0900] ClaudeBot/1.0; +claudebot@anthropic.com)" ec2-18-118-144-50.us-east-2.compute.amazonaws.com
[29/Dec/2024:00:20:22 +0900] ClaudeBot/1.0; +claudebot@anthropic.com)" ec2-18-118-144-50.us-east-2.compute.amazonaws.com
[29/Dec/2024:00:20:22 +0900] ClaudeBot/1.0; +claudebot@anthropic.com)" ec2-18-226-88-18.us-east-2.compute.amazonaws.com
[29/Dec/2024:00:20:22 +0900] ClaudeBot/1.0; +claudebot@anthropic.com)" ec2-18-226-88-18.us-east-2.compute.amazonaws.com
[29/Dec/2024:00:20:22 +0900] ClaudeBot/1.0; +claudebot@anthropic.com)" ec2-18-226-88-18.us-east-2.compute.amazonaws.com
[29/Dec/2024:00:20:22 +0900] ClaudeBot/1.0; +claudebot@anthropic.com)" ec2-18-226-88-18.us-east-2.compute.amazonaws.com
[29/Dec/2024:00:20:22 +0900] ClaudeBot/1.0; +claudebot@anthropic.com)" ec2-18-226-88-18.us-east-2.compute.amazonaws.com
[29/Dec/2024:00:20:22 +0900] ClaudeBot/1.0; +claudebot@anthropic.com)" ec2-18-226-88-18.us-east-2.compute.amazonaws.com
[29/Dec/2024:00:20:22 +0900] ClaudeBot/1.0; +claudebot@anthropic.com)" ec2-18-226-88-18.us-east-2.compute.amazonaws.com
[29/Dec/2024:00:20:22 +0900] ClaudeBot/1.0; +claudebot@anthropic.com)" ec2-18-226-88-18.us-east-2.compute.amazonaws.com

とな感じで、最近流行りの生成AIで、CloudeというLLMを出しているAnthropicから1秒あたり10回の猛アクセスが来ていた。

クローラのためではない、おうちの非力なサーバは、こんなクローリングには耐えられない。

一時間の転送バイト数で見てみると

時刻              バイト数
29/Dec/2024:00:00 102983126
29/Dec/2024:01:00 113002871
29/Dec/2024:02:00 111779564
29/Dec/2024:03:00 116502868
29/Dec/2024:04:00 114251264
29/Dec/2024:05:00 115431162
29/Dec/2024:06:00 115529007
29/Dec/2024:07:00 113630792
29/Dec/2024:08:00 98580010
29/Dec/2024:09:00 7209040
29/Dec/2024:10:00 113607729
29/Dec/2024:11:00 115349690
29/Dec/2024:12:00 109150164
29/Dec/2024:13:00 111299203
29/Dec/2024:14:00 113046010
29/Dec/2024:15:00 99314245
29/Dec/2024:16:00 110396331
29/Dec/2024:17:00 111492904
29/Dec/2024:18:00 15216338

サーバが忙しい9時前後は減っているけど、1時間あたり100MBのアクセスがずっと続いていた。

接続先別で見ると

バイト数  要求元
2783954 ec2-13-59-83-202.us-east-2.compute.amazonaws.com
2792366 ec2-3-138-178-162.us-east-2.compute.amazonaws.com
2809782 ec2-3-12-76-168.us-east-2.compute.amazonaws.com
2834601 ec2-18-220-110-45.us-east-2.compute.amazonaws.com
2836005 ec2-3-145-73-167.us-east-2.compute.amazonaws.com
3004271 ec2-18-223-158-29.us-east-2.compute.amazonaws.com
...ずっとつづく

と午後6時までで1113台!のAWSを使って1台あたり3MBづつアクセスしてきていた。

生成AIの学習用データが必要なんだろうけど、こんな辺境なサーバーまでご苦労さま。

持っていったデータは、検索条件のタグを変えてるだけの同じデータです。

というわけで、robot.txtに

User-agent: ClaudeBot
Disallow: /

と書いて様子を見てみる。

クローラーのくせに1秒間に10回もアクセスしているので、robot.txtを読んでいないような気もしたけど、

ec2-3-149-239-70.us-east-2.compute.amazonaws.com - - [29/Dec/2024:19:56:26 +0900] "GET /robots.txt HTTP/2.0" 200 2033 "-" "Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)"

ちゃんと見てくれて、クロールが止まった。

あとで調べたら12月のアクセスの74%、11月は60%がClaudeBotだったよ。

■ マウスとゲームコントローラーの修理体験

今まであまり使う機会のなかった「接点復活剤」を使って、故障してしまったマウスとゲームコントローラーを修理した体験についてお話しします。

■ なぜ接点復活剤を使うことに？

接点復活剤は、名前は聞いたことがあったものの、古いスイッチなどに使うものというイメージで、自分には縁のないものだと思っていました。しかし、最近になって愛用していたマウスの左クリックが反応が悪くなり、ゲームコントローラーのアナログスティックが正しく認識しなくなったことで、このアイテムに再び注目するようになりました。

これらの症状は、電気的な接点が汚れたり酸化したりすることで、電気がうまく流れなくなり、起こる現象です。このような場合、接点復活剤を使うことで、接点をクリーニングし、電気の流れを回復させることができる場合があります。

■ 接点復活剤の原理

接点復活剤の詳しい原理については、モノタロウの技術情報記事に詳しく解説されています。

簡単に説明すると、接点復活剤は、金属表面に非常に薄い油膜を形成し、電気信号がよりスムーズに流れるようにする働きがあります。

■ マウスの修理

まず、修理したのはマウスです。左クリックが反応が悪くなり、何度もクリックし直さなければならず、非常に使いづらくなっていました。使用したのは、バッファローのBSMBU500Mというマウスです。

修理手順

1. 裏蓋を開ける

   1. マウスの裏側にある滑るシールのうち、一番後ろのものを半分ほど剥がすと、ネジ穴が現れます。他のシールは剥がす必要はありません。

   2. ネジを外したら、上蓋をコードがある方向にずらすと、前の方にあるツメが外れ、上蓋が取り外せます。

2. マイクロスイッチに接点復活剤を塗布する
   上蓋を取り外すと、左クリックのマイクロスイッチが見えます。
   1. マイクロスイッチに、接点復活剤を少量吹きかけます。

   2. マイクロスイッチを数回押して、接点復活剤をなじませます。

   3. 余分な接点復活剤を拭き取る: 周りに付着してしまった接点復活剤を、乾いた布などで拭き取ります。

3. 組み立てる: 上蓋を元の位置に戻し、ネジで固定します。

■ ゲームコントローラーの修理

次に修理したのは、GameSir T4 Proというゲームコントローラーです。左アナログスティックの前後の認識がおかしく、ゲームをプレイする際に支障が出ていました。

修理手順

1. ケースを開ける

   1. ケースの4つのネジを外します。保証シールが貼ってあるネジもあるので、保証期間が切れていることなどを確認してから外しましょう。

   2. ケースの隙間にギターのピックのようなものを差し込み、ツメをこじ開けてケースを開けます。

2. 基板を取り出す: 基板の裏側にアナログスティックの可変抵抗があるので、基板を取り出します。

3. 可変抵抗の清掃

   1. 可変抵抗の緑色の蓋をこじ開け、中に接点復活剤を少量吹きかけます。

   2. 可変抵抗の蓋を閉め、スティックを上下左右に動かして、接点復活剤をなじませます。

4. 組み立てる: 余分な接点復活剤を拭き取り、基板をケースに戻し、ネジで固定します。

■ 修理の結果

マウスとゲームコントローラーの両方を修理した結果、見事に復活させることができました。マウスはクリックの反応がよくなり、ゲームコントローラーもアナログスティックが正しく認識するようになりました。

■ まとめ

今回は、接点復活剤を使って、故障したマウスとゲームコントローラーを修理した体験についてお話ししました。古いデバイスが蘇る喜びを味わえただけでなく、自分で修理することで、愛着がさらに深まりました。

もし、皆さんの周りにも、同じような症状で困っているデバイスがあれば、ぜひ一度試してみてはいかがでしょうか。

■ 注意点

接点復活剤は、精密機器に使用する場合、取扱説明書をよく読んでから使用してください。接点復活剤を誤って他の部品に付着させると、故障の原因となる場合があります。修理の際は、静電気対策をしっかり行いましょう。

■ 免責事項

この記事の内容は、あくまで個人の経験に基づいたものです。この記事を参考に作業を行う場合は、自己責任でお願いいたします。

■ [Debian] deb-multimediaを完全に外す

deb-multimediaは、メディア関係の新しい目なツールのDebパッケージが入っているので、昔から使っている。

しかし、サポートされなくなってしまったパッケージが依存関係の邪魔をするようになって久しい。

10月23日の日記で、deb-multimediaを参照するのをやめたけど、ついに調整ができなくなってしまったので、すでにインストールされているdeb-multimedia由来のバーケージをDebianパッケージに戻す事にした。

$ apt-show-versions |grep dmo

で見つけて、手動で入れ替えた。

ただし、Debianには無いものがあって

mythtv
mytharchive
avidemux
ffenv
ffx264
h264enc

は、無くなってしまった。ffenvなどは、ffmpegコマンドで代用できるけど、mythtvで録画したファイルがmythtvで見えなくなっている。

■ [Debian] パッケージの依存関係でミスをしてしまった

自動更新していないSidのパッケージを更新しようとすると、依存関係が変わってしまい、dvdstyler (1:3.3~b3-dmo5)と2mandvd (1:1.8.5-dmo6)をアンインストールするしかなくなってしまいました。

一度、deb-multimediaを外して、なんとかパッケージの依存関係を安定させたのですが、再びインストールしようとすると、依存関係を解決できず、再インストールすることができません。

■ ひとりで趣味としてエンジニアをしていると、壁打ち相手がいないことがありますが、生成AIのレビューに助けられています。最近、生成AIを使ったマージリクエストレビューに感動したのでご紹介します。

去年の7月から nfacha/OpenAI-Gitlab-PR-Review: Prototype Gitlab Webook that submits code to OpenAI for review (github.com)を使って、すべてのコミットコードをレビューしてもらっています。

このレビューでDockerfileの更新について指摘がありました。

「そうそう、これビルドしたバイナリが欲しいのでインストールが失敗したらCIが止まるで良いんだよ」と無視しました。

コード差分も出してくれることはありますが、OpenAI-Gitlab-PR-Reviewはレビューコメントとしてバグやセキュリティの観点でメッセージを出すだけなので、小さな指摘はコピー&ペーストするのも面倒です。そんな中で

そんな中で、最近、Codium-ai/pr-agent: 🚀CodiumAI PR-Agent: An AI-Powered 🤖 Tool for Automated Pull Request Analysis, Feedback, Suggestions and More! 💻🔍 (github.com) も入れました。

これには、マージリクエストのコードを改善するため提案をしてくれる機能( Improve )があります。

これはマージリクエストがオープンしたときや「/improve」とコメントしたときにコードの改善提案を出してくれるのですが、これが提案ごとにスレッドを分けてくれることもあり秀逸で便利です。

例えば、

のような提案もあります。ただし、pr-agentもいつも最適なレビューをしてくれるわけではなく、「分かっているよ。でも早くしたいんだよ」とスレッドをクローズすることもあります。

ただし、pr-agentもいつも最適なレビューをしてくれるわけではなく、例えば同時に出た

のような提案が出てきて「分かっているよ。でも早くしたいんだよ」と緑の丸ボタンでスレッドをクローズすることもあります。

ちなみに、利用しているLLMはGPT-4です。pr-agentはマージリクエストのコメントもすべて見ているので、最初の「バグの有無」も確認していますが、pr-agentが無敵というわけでもないかもしれませんね。

■ [Kindle][Debian] Wine HQ更新

2022年8月1日の日記で、WineではKindle for PCがうまく動かないのでWine HQパッケージをDebianにインストールしましたが、最近のt64の影響でパッケージの依存関係がうまくいかず、アンインストールしてしまいました。

そろそろt64も安定したので、再インストールするために、「Debian WineHQ Repository」を見に行くと、リポジトリキーやその置き場所が少し変わっていました。

# wget -O /etc/apt/keyrings/winehq-archive.key https://dl.winehq.org/wine-builds/winehq.key
# wget -NP /etc/apt/sources.list.d/ https://dl.winehq.org/wine-builds/debian/dists/trixie/winehq-trixie.sources
# rm /usr/share/keyrings/winehq-archive.key

最後の行は古いリポジトリキーのファイルの削除。

そして、

# apt update
# apt install --install-recommends winehq-stable

という感じでWine HQがインストールできました。

■ GooglePhotoをエクスポートしたら容量52倍

11.52GBのGoogleフォトを整理しようと思ってバックアップのためエクスポートしたら、60倍の699GBになりました。

写真としては、11.52GBしかないはずなのに・・・

あ、そういえば「2021年6月1日から容量が無制限でなくなり、無料で利用できる容量は最大15GBに制限されます」と言っていたんだ。2021年6月1日以降は11.52GBだけど、それ以前の10年分が600GB以上あるってことか。

■ UPSバッテリー交換

先日の日記で書いたように、UPSのバッテリーが死にそうでしたが、とうとうUPSのアラームとともに電源が突然切れました。UPSの電源を入れ直すと通電しましたが、ステータスはNOBATTERYでバッテリーが認識されませんでした。

UPSを後継機のBR400S-JPなどに交換しても良いかと考えましたが、17,000円近くするため、2015年1月以来9年ぶりに今回もバッテリー交換で済ますことにしました。

https://www.amazon.co.jp/dp/B06XJ24QWJ

メーカーのページ「バッテリー交換手順 APC ES (BE550G-JP) : サポート終了製品」によるとサポートは終了していましたが、APC ES500（製番BE500JP）用のRBC2J-S互換バッテリーがアマゾンで販売されていました。

https://www.amazon.co.jp/dp/B01M3OJV0J

ドライバーでネジを外して蓋をスライドするとバッテリーが見えるので、シールを引っ張って取り出し交換しました。長年の使用でバッテリーが膨らんでいたため取り出すのが大変でした。また取り出しが難しいと困るので、シールを新しいものに貼り替えておきました。

電源を再投入すると無事に起動しました。

ということで無事にステータスがONLINEになって充電が開始されている。11V代まで落ちていた電圧も13.4Vで上々。しかし、バッテリーの交換日付が2015年1月17日のままになっているので、更新する。

としてバッテリー交換日付を更新しました。ついでに、電灯線電圧の範囲も以前広げた90〜113Vから、この一年の様子を見ていると、98〜107Vの範囲なので93V〜110Vに変更しました。下は95Vにしたかったのですが、93V以上には設定できないみたいでした。

■ UPS無停電電源装置の電池が弱ってきている

2009年1月5日の日記で交換した、アマゾンで8,600円で買ったAPC ES500(製番BE500JP)だけど、突然、電源につないでいるのに電気残量が減ってきて7%とかになっている。

2015年1月にピーピー鳴るので電池を交換したけど、あの時は電池を交換しても鳴ることがあり、調べてみると電池ではなくて、電源電圧変動の警告だった。あの時は、引っ越したばかりで、まさか日本でもそんなに変動があるとは思わず、電池を交換してしまった。

今回は、引っ越してから2年以上経つのでそんなことはなさそうで、10年近くなるので電池が死んだかな?

買い替えるならば、APC BR400S-JPかな？ 約17,000円かぁ。電池の価格を見ても高くなっているしUPSも高くなったのは、その辺の影響か? それとも正弦波とか機能と性能が上がったからか?

■ GitLab 17.0へのアップグレード時のOmnibus Dockerイメージのエラー解決

概要:

GitLab Omnibus Dockerイメージで、ci_pipelinesテーブルの制約ci_pipelines_pkeyを削除できないというエラーが発生しました。この問題は、他のオブジェクトがこの制約に依存しているため削除できなかったことに起因します。

gitlab-ce-1 | PG::DependentObjectsStillExist: ERROR: cannot drop constraint ci_pipelines_pkey on table ci_pipelines because other objects depend on it
gitlab-ce-1 | DETAIL: constraint fk_rails_a2141b1522 on table ci_builds depends on index ci_pipelines_pkey
gitlab-ce-1 | constraint fk_rails_a2141b1522 on table p_ci_builds depends on index ci_pipelines_pkey
gitlab-ce-1 | HINT: Use DROP ... CASCADE to drop the dependent objects too.

解決方法:

従属オブジェクト（外部キー）を特定し、削除しました。具体的には、以下の手順を踏みました。

1. docker compose gitlab-ce gitlab-psqlコマンドでPostgreSQLコンテナに接続しました。

2. 以下のSQLコマンドを実行し、従属制約を削除しました。

SQL
ALTER TABLE ci_builds DROP CONSTRAINT fk_rails_a2141b1522;
ALTER TABLE p_ci_builds DROP CONSTRAINT fk_rails_a2141b1522;

結果:

上記手順によりエラーを解決し、GitLab Omnibus Dockerイメージを正常に起動できました。

教訓:

今回の経験から、以下の教訓を得ました。

- GitLab Omnibus Dockerイメージでエラーが発生した場合、公式ドキュメントやフォーラムスレッドを参照することで解決策を見つけられることが多い

- データベースに重大な変更を加える前には、必ずデータのバックアップを取る

- 問題が発生した場合は、慌てず原因を特定し、適切な解決策を講じることが重要である

実は、解決方法をGemini 1.5 Proに聞いて、日記も書いてもらい。GPT-4でこの日記を構成してもらったんだけどね。