Lycolog

最近自鯖を別環境に移行するかどうかについて少し考えている。

現在はUbuntuで運用しており、記憶が確かならUbuntu 16.04 LTSから24.04 LTSまで使ってきているが、幾つかの問題を感じている。別にクリティカルでも何でもないので、やる必要性も薄い。

移行方法についてもやや難しく、UbuntuはNVMe SSD上で動いているため、本来なら別にNVMe SSDを買ってきてそこに試験的に移行先を作り、移行が環境した時点でUbuntuのNVMe SSDと物理的にすり替えたいところだが、SSDが高騰している関係でこの手が使えず、やるとしたら空いているSATA SSDに環境を入れて、運用が軌道に乗りそうならUbuntuを消し飛ばすしかなくなる。つまり戻せないか、戻す場合はUbuntuの入っているNVMe SSDをddでどっかにバックアップしてやる必要がある。凄いめんどい。

ひとまず、以下に移行したくなった好ましくない理由と、移行先について書いていく。

• Ubuntuの好ましくないところ
  • Ubuntuの商業主義が気に食わない
  • Snapが気に食わない
  • 動作が不安定
  • 26でのinit.d切り捨て発表
• Ubuntuの好ましいところ
  • 広く普及しておりノウハウが豊富
  • メジャーアップデートが容易
  • 特に何もしなくても大抵のハードウェアが動く
• 現在検討している移行先
  • Debian
    • 得られそうな利点
    • 懸念点
      • 通信速度が異常に遅かった
      • 移行しても旨味があまりなさそう
  • Proxmox
    • 懸念点
      • スペック的に運用できるか怪しい
      • 運用がだるそう
      • 監視がだるそう
• 通信速度の比較
  • Ubuntu 24.04.4 LTS
  • Debian 13.5.0のLive installer上での計測
  • Proxmox VE 9.2-1
• あとがき

Ubuntuの好ましくないところ

ここに書いていることはほとんど運用面では関係ない吝嗇である。端的に言えばCanonicalの姿勢が嫌いなのである。

Ubuntuの商業主義が気に食わない

自鯖はLinuxのDesktop環境の検証も兼ねているのでUbuntu Desktopを導入しているが、何かあるとCanoninalの製品に誘導されたり、過去にはMSアカウントとの連携をお勧めしてくる画面とも出会った記憶がある。こういうところがどうも好きになれない。

私はCanonicalに金を払う気がないし、LinuxをMSアカウントや、その他何かしらのアカウントと連携させたいとも思っていない。スタンドアロンこそが正義だ。

いやまぁ、Edgeのアカウントは連携するけどさ。

Snapが気に食わない

Snapに対する私の理解としてはSnapdというデーモンの上で動くアプリケーションという感じだ。

コンテナ化されたアプリケーションがDocker見たいなやつの上で動いている。なんかリソース食いそうだしキモイ。ネイティブアプリケーションはバイナリでそのまま動いてほしい。

噂ではFirefoxはaptでインストールしてもSnapdの上で動くらしい。これはWikipediaにも載ってるほど有名な話だ。何故snapdを使ってないのにそうなるのか？キモすぎる。

私は仮想化に対しては余り良いイメージがない。何故なら仮想環境分のオーバーヘッドを含み、無駄にストレージやメモリを食うこと、ホスト環境とゲスト環境の差異により問題が発生した時の特定が困難なことがある。

明示的に触れるDockerやVMならまだしもSnapdは一般向けで普通カスタマイズしない気もするし、そもそもカスタマイズが必要になるとしたらバカバカしい。なんでFirefox動かすのにそんな設定しないといけないのか？

動作が不安定

インストール直後にapt upgradeを叩くとリポジトリが死んでることがある。これは非常に嫌だ。

なんで公式でキッティングされてるリポジトリが死んでるのか？本当に営利企業がやってるのか？と思う。

他にもノートPCに入れてると蓋を閉じて開きなおしたときにキーボード入力が効かなくなり、一切何も操作できなくなることもあった。これは大分困る。

基本的にUbuntuのDesktop環境は不安定で、よくフリーズやクラッシュすると思う。それでもUbuntu 8.04 LTS辺りのころよりは安定したとは思うが…。

26でのinit.d切り捨て発表

init.dを捨てろという話なのだが、移行がだるい。

Ubuntuの好ましいところ

一方で、Ubuntuにもいいところはある。

広く普及しておりノウハウが豊富

人気のディストリのため、情報が多いのは強みかもしれない。

パッケージリポジトリも多く、基本的にUbuntu対応は多いと思う。

メジャーアップデートが容易

コマンド一個叩けばアップデートできるのは便利だ。設定の移行も手伝ってくれる。

特に何もしなくても大抵のハードウェアが動く

5種類くらいのデバイスに突っ込んだり、NICを増設したり、色々してきたが、今のところドライバを入れるとか何か対応したことはない。楽である。

現在検討している移行先

取り敢えずそんなこんなで移行先を探すことにした。

Debian

人生で最も最初に触ったディストリ。保守的で質実剛健という話を聞くやつ。

得られそうな利点

• Canonicalの商業主義から解放される
• Ubuntuより安定している可能性がある
  • Debianは徹底的なテストを経てリリースされているそうなので

懸念点

通信速度が異常に遅かった

懸念点としては何故か通信速度が異常に遅かった点だ。Live installerでiperf3で計測したところ、なんか異常に遅かった。これでは使い物にならない。原因は調べていないがNICは10000Mbpsでリンクアップしていたので、NICより手前で何かが起きていた可能性がある。

以下はDebian 13.5.0のLive installer上で計測した値だ。

Windows -> Debian

Debian -> Windows

移行しても旨味があまりなさそう

手間がかかるだけでCanonicalの開放以外のメリットがなさそう。

移行の手間としても全ての手順をマニュアルに書き出すかAnsibleのような構成管理ツールでやる必要があり、非常に面倒そうである。

Proxmox

仮想環境をたくさん作ってその中でアプリケーションを運用するやつ。コンテナ単位でのバックアップも取れるなど便利そうだ。

この環境に移行する場合、移行が楽というのが最大のメリットだ。一度適当な環境に仮構築しモジュールごとに移行し、移行完了したらLXCのバックアップを取り、Ubuntu環境を潰し、Proxmoxに入れ替え、バックアップを復旧して移行すればリスクも手間も最低限で済む。

またDebianで発生したNICの極端な通信速度劣化についてもProxmoxでは確認できなかった。但しUbuntuよりは遅く見えた。

懸念点

スペック的に運用できるか怪しい

例えばコンテナ単位でのリソース管理はその一つだ。例えばコンテナごとにCPUやメモリ、ストレージを割り当てるとすると、特定のコンテナが跳ねたときにリミットにかかって動作が劣化するが、ネイティブで動かしていればCPUやメモリ、ストレージは共有なので、なんかいい感じにしてくれる。限界突破しない限りOOMは起きないし、私のサーバースペックであれば普通起きない。

しかしコンテナ化して1コンテナCPU2コア、メモリ2GBとかしていればしょぼいVPSみたいになって動作が劣化しそうだし、そんな立派なスペックでもなく、現状CPU6コアのメモリ32GBなので、この割り当てだとすぐに枯渇するのは自明である。ブレードサーバーを持ったホームラボ、k8sを使った運用のようにクラスタ化された環境なら、これはうまくいきそうだが、しょっぱいスペックのマシン一台で成り立つかどうかは怪しい。

Opus 4.8は成り立つというが、この分野ではLLMの言うことを真に受けたくはない。そもそもLLMの出力なんか何言ってるかわからないけど動くからいいか！で採用するものでしかないと思っている。

運用がだるそう

例えば10個くらいLXCを上げているとして、コンテナのイメージをアップデートしますとかなると全部上げていかないといけないだろうから、これは面倒そうだ。

他にもLXC1とLXC2, LXC4に対して作業する場合、それぞれのLXCにSSHDと鍵を入れる必要があり、無駄なオーバーヘッドが出る。つまりLXCを増やし、そこの中に入る場合は台数分のSSHDが多重起動し、その数分の鍵が必要だ。まぁこれについては最悪一個にしてもいいが…。切り替えについてもnginxでリバプロしてハブを作れば上手くいくかもしれないが、そもそもそれが出来るかよくわかっていない。軽くググった感じはできるらしいが、そもそもスイッチする時どうなるのか見当もつかない。/lxc1/path/toみたいな形式になるのだろうか？

そう考えるだけで運用がだるそうである。

pct setを使えばうまくいく可能性が示唆されているが、どうやらこの方法は前述のように根本にパスを追加して、そこから分けていく考えのようだ。ユーザーやグループとかどうなるんだこれ…？Proxmox側でID揃えてくれるのかな？

あとホストのアップデートもだるそうな気がしている。

監視がだるそう

動作パフォーマンスを取ろうにもホストとゲストのどっちのCPUやメモリの使用率を取るかは悩みである。ホストには空きがあるが、ゲストには空きがなければ広げた方がいいかもしれないし、この辺りについては考えがまとまっていない。

通信速度の比較

Ubuntu 24.04.4 LTS

Windows -> Ubuntu

Ubuntu -> Windows

Debian 13.5.0のLive installer上での計測

以下の計測値は全てクライアント側で取得したもの。Windows側にCwndが出ているので表が逆かもしれない（Proxmoxではクライアント側にCwndが出ていたため）

Windows -> Debian

Debian -> Windows

Proxmox VE 9.2-1

以下の計測値は全てWindows上で取得したもので、Proxmox->Windows側はProxmox側のログの値ではない（転記が面倒だったためWindows側の値を取っている）

Windows -> Proxmox

Proxmox -> Windows

Proxmox側（クライアント）にはCwndが出ていたが、Windows側（サーバー）の値を取っているため、その情報が欠落している。

あとがき

Proxmoxで運用の支障がなければ環境分離の観点から移行できるとよさそうだが、メンテナンスのだるさを考えた時にどうかというのでぐるぐるしている。

かといって今のUbuntuを拡張すればするほど移行が手間になってくるので、悩ましい。しかし単一ホストで全部運用するのは間違いなく楽だしなぁ…。

取り敢えずDebianに移行する旨味は余りなさそうだし、これはしなくていいかと思った。

Proxmoxはやってみないとわからない部分もあるのでUbuntu環境のバックアップを入念に取ったうえでやるかもしれないが、問題はUbuntuをバックアップするストレージをどうするか…。

そもそも現時点でやる意義も怪しいので、今はやらない方に倒し、必要が出たときにやるのも一つではある。やりたくなった時にはそれはもう地獄が待っているかもしれないが、それ以前に私はやりたいことが無数にあるのだ。

今回は検証ができたという意味では一つ成果だと思うし、一旦ここで留めておこう。

アクセス解析にノイズが出て鬱陶しいので、海外IPのUAを幾らか調べてみたまとめ。

今年の1月末付近と、5月末に調査を実施している。

集計条件

https://blog.lycolia.info/配下にHTTPリクエストが来た時で、そのURLにファイルが存在しない場合に、海外IP判定が出たものについて次の基準で集計している。

• 2026-01-29 19:30:25 -> 2026-02-03 07:23:22
  • UAに次を含まない
    • bot | curl | wget | google | bing | mastodon | misskey | pleroma | akkoma | lemmy | activitypub | hatena | github | tumblr
  • 日本、韓国、台湾のIP以外
• 2026-05-25 20:15:52 -> 2026-05-29 23:19:00
  • UAに次を含まない
    • bot | curl | wget | google | bing | mastodon | misskey | pleroma | akkoma | lemmy | activitypub | hatena | github | tumblr | meta
  • 日本のIP以外

IPの国判定にはその月のDBIP-City.mmdbを使用した。

2026-01-29 19:30:25 -> 2026-02-03 07:23:22

UA別

• meta-externalagent/1.1はFacebookやInstagramのOGP収集クローラーらしいが、異常にアクセスが多い。無害なので5月のログでは許可している
• Baiduspiderは百度のクローラー、個人的にいい印象はない。
• NULL、UA未設定。まともなアクセスでない可能性が高い。PHPのfile_get_contents()だとデフォは空。curlはcurl/8.19.0みたいなのがデフォルトで入る。
• FaradayはRubyのHTTPクライアントらしい
• Twingly Recon-Sjostromは何かしらのフィードリーダーの可能性がある

国別

アメリカが最多で、中国、インドと続いた。

UAがNULLの国別

アメリカにNULLのUAが多く、意外と中国にはなかった。偽装UAであれ設定してるだけまともといえる。

アクセス先URL

ほとんどが公開URLへのアクセスで有害なURLへのアクセスは思ったよりなかった。

2026-05-25 20:15:52 -> 2026-05-29 23:19:00

UA別

• metaを弾くようにした結果NULLがトップに上がってきた
• Baiduspiderが来なくなった
• Faradayがrururu.appからのクロールであることが判明した（rururu.appに出た瞬間にログを確認したところ、これしかいなかったため）
• Fediverse系のUAが増えた気がする

国別

前回15件しかなかったブラジルが425件に増えてトップに躍り出た。ブラジルに何があるんだ…。AWSのデータセンター？

そしてアメリカ、カナダ、中国、台湾と次ぐ。アメリカはAWSとかが多い気がする。カナダは知らん。中国は多分人間が来ている気がしているがよくわかっていない。台湾は今回ログの範囲に含めたため初登場。韓国からのアクセスはなかったようだ。

UAがNULLの国別

ブラジルからのアクセスに悪質なものが多かったことが推測できる。

アクセス先URL

圧倒的に有害なアクセスが増えていた。

集計クエリ

事後分析するためにデータをSQLiteに保存していたので、そのクエリ。実は1月のデータはTSVだったので、地味にコンバートに苦労したが、SQLiteクライアントがTSVからのインポートをサポートしていたので、引っかかったのはTSVのタイムスタンプがSat May 30 00:50:56 2026だったのを、DBのタイムスタンプのYYYY-MM-DD HH:mm:ssに変えるくらいだった。これはLLMに変換SQLを出してもらって良しなにしてもらった。

集計テーブルのDDL

CREATE TABLE "deny_log" (
	"id"	INTEGER,
	"url"	TEXT,
	"country"	TEXT,
	"remote_addr"	TEXT,
	"user_agent"	TEXT,
	"timestamp"	TEXT,
	PRIMARY KEY("id" AUTOINCREMENT)
)

UA別

SELECT
	T.UA,
	COUNT(T.UA)
FROM
	(
		SELECT
			CASE
				WHEN user_agent IS NULL
				THEN "NULL"
				ELSE user_agent
			END AS UA
		FROM
			deny_log
		WHERE
			timestamp < '2026-05-20'
	) T
GROUP BY
	UA
ORDER BY
	COUNT(T.UA) DESC

国別

SELECT
	country,
	COUNT(country)
FROM
	deny_log
WHERE
	timestamp < '2026-05-20'
GROUP BY
	country
ORDER BY
	COUNT(country) DESC

UAがNULLの国別

SELECT
	country,
	COUNT(country)
FROM
	deny_log
WHERE
	timestamp < '2026-05-20'
AND user_agent IS NULL
GROUP BY
	country
ORDER BY
	COUNT(country) DESC

アクセス先URL

URLの善悪分類はエクセルを使って手動。

無害＝robot.txtや記事URLなどの公開URL、有害＝管理画面や何かのスクリプトのURLを叩いているもの。

SELECT
	url,
	COUNT(url)
FROM
	deny_log
WHERE
	timestamp < '2026-05-20'
AND (
	url != '/'
	AND url NOT LIKE '/0%'
)
GROUP BY
	url
ORDER BY
	COUNT(url) DESC

あとがき

元々はアクセス解析に出ないようにブロックするために集計していたが（robot.txtが尊重されるとか思ってないので)、善良なBOTの大半が海外IPで対応が面倒なのでいったんブロックはやめることにした。

将来的にはAnubis辺りを導入してWAFを掛けることで対応したいと思う。

あとこれをやってて思ったこととしてUAの中に自分が何者かを入れてくれてるクライアントは凄く親切だなと思った。

ここ一週間で買ったものについて書く。

洗濯バサミの崩壊を阻止するために洗濯バサミを買い、そしてヘッドホンがキツかったので、ヘッドホンのイヤーパッドとウレタンリングを買ったらなんと7年ぶりだったという話。

• 洗濯バサミ
• ヘッドホンのイヤーパッドとウレタンリング

洗濯バサミ

ニシダ株式会社のピンチ20P OB3。ヨドバシで税込み187円というお買い得なやつだった。百均のと比べると高いかもしれないが、耐久性が高いと評判だったので買った。

去年ピンチハンガーの補修パーツを買った訳だが、凄い勢いでピンチの部分が壊れるので、補強用に買ったのがこの品だ。

去年買ったやつと今回買ったやつの比較。まずサイズと色が違う。実際に触ってみると開閉もスムーズで、サイズが大きい分テコの原理で少ない力で開くのもよいと感じた。

そしてこちらは去年買ったやつと10年くらい壊れてない従来のピンチ。従来のピンチは最近稀に壊れていて、具体的には割れるのだが、壊れたものは去年買ったピンチに置き換えていた。しかし去年買ったピンチは見た目は同じなのに耐久性が悪く、なんと2-3ヶ月くらいで壊れてしまう。マイナーチェンジで材料費がケチられているのかもしれない。

というのでハンガーのピンチを取り換えることに無事成功したので、しばらくは壊れないはずだ。このハンガーは3セットあるので、地味に大変だったが、洗濯物を干すときにピンチが壊れると何ともしんどいので、ことが起きる前に交換しておきたかったのだ。

このハンガーは少ない面積にもかかわらず多くのピンチがついているため、いい具合の感覚で洗濯物を付けることができ、特に冬場に洗濯物を干すときに活躍する。1個明けで干すことで風通しが良くなり、乾燥が早く進むわけだ。ピンチ一個開けで干してもかなりの数を干せるため非常に重宝している。

ヘッドホンのイヤーパッドとウレタンリング

SONY MDR-CD900STの純正イヤーパッドとウレタンリング。これを交換し続けるだけでそこそこ高いヘッドホンを無限に使い続けられるという神アイテムだ。

なんかここ2～3年程ヘッドホンをしてると締め付けがキツくて痛い気がしていたのだが、そもそもパッドが痛んでいたので交換することにした。

ウレタンリングもへにゃへにゃになっていた。

というわけでサクッと交換した。

しかし驚いたのは、いつものようにサウンドハウスで買おうとしたら登録住所が前の住所になっており、少なくとも6年も買い替えてなかったことだ。昔は1-2年に一度は買い替えていた気がするので、放置しすぎた感じがある。

MDR-CD900STとの付き合いは長く、古くは学生時代にノートPCのミニジャックが壊れてからオーディオインターフェースで補完しようとしたところ、ミニジャックではなく標準プラグしかなかったので困っていたところ、学友にMDR-CD900STを勧められて買ったところに端を発する。確か初代は6年ほどで壊してしまい、そこで二代目に買い替えた。記憶が確かなら二代目のイヤーパッドとウレタンリングの交換はこれが二回目だ。

確か二代目の最初の交換は2-3年あたりでやった気がするのだが、何せサウンドハウスの最近のアップデートで過去の履歴がちっとも見れなくなってるので、正確なことはわからない。少なくともTwitterのアーカイブを検索してみた感じ2019年の8月に交換したのが最後だったようだ。つまり7年も交換していなかったことになる。

これは2019年の8月に交換する前の写真だが、当時はかなり酷使していたようで、見た目にも明らかにパッドが死んでいたが、今回は余りそれに気づかない程度しかなかったので、中々パッドがへたっていることに気づけなかったのだろう。

この交換の2年前に購入したと仮定すると11年目ということで、二代目はかなり長持ちしていることになる。初代はケーブルの断線によって交換になったので、二代目は断線しないように扱っている。いや、別に断線してもケーブル売ってるし、はんだ付けすれば交換できるはずだが…ｗ

ひとまず好感したことによってふかふかになって、締め付けも多少マシになったような気がするような、しないような感じなので、しばらくはこれでやっていけるだろう。

私はCD900STをモニタリング用途には使っておらず、リスニングに使っているため、これを数時間付け続けるという、恐らく常識的に考えると狂気じみた使い方をしている。ネトゲ廃人をしていたころなんか、それこそ一日中付けていた。

value-domain-dns-utilを更新したので、その記録とか、その感想の怪文章とか。

• 更新内容
  • ワイルドカード証明を発行するときに失敗する問題の修正
  • モジュール化
  • バージョニングの追加
• 対処が必要なこと
  • Net::DNS::Digの追加
  • Certbotの走行コマンドの変更
• 今回の対応をした理由
• あとがき

更新内容

ワイルドカード証明を発行するときに失敗する問題の修正

これまでDNS更新のタイミングの関係で偶々成功していたが、何度もやってると失敗することが多かったので、失敗しないようにした。

変更前

• vd-dcr.pl
  • APIからDNSレコードを取得→レコードにACME TXTレコードがなければ追加、あれば上書き→編集後のレコードをAPIに送る

変更後

• vd-dcr-auth.pl
  • APIからDNSレコードを取得→レコードにACME TXTレコードを追加
• vd-dcr-cleanup.pl
  • cleanup：PIからDNSレコードを取得→レコードから今回登録したACMEレコードを除去→編集後のレコードをAPIに送る

モジュール化

lib/VdDnsUtil.plをlib/VdDnsUtil.pmに変更し、shebangを削除。

並びに今回の変更で追加したユーティリティも.pmとして実装。

バージョニングの追加

スクリプトを叩いたときに依存モジュールと本体のバージョンが出るようにした。

対処が必要なこと

vd-dcr.plの改修に関わる影響のため、vd-dcr.plを使っている人だけに影響がある。

Net::DNS::Digの追加

rootユーザーで以下を流し、Net::DNS::Digを入れる。既にある場合は不要。

cpan Net::DNS::Dig

Certbotの走行コマンドの変更

certbotを以下の書式で再走行させる。具体的には--manual-cleanup-hookが増えてるので、そこを足す。これによってrenewが上書きされ、次回以降、正しく動作するようになる。

 sudo certbot certonly --manual -n \
   --preferred-challenges dns \
   --agree-tos -m <your-email> \
   --manual-auth-hook "/path/to/vd-dcr-auth.pl <value-domain-api-key> <root-domain> <optional:ttl>" \
+  --manual-cleanup-hook "/path/to/vd-dcr-cleanup.pl <value-domain-api-key> <root-domain> <optional:ttl>" \
   -d <FQDN>

また、従来であればValue-DomainのAPIに更新リクエストを投げてから3秒しか待っていなかったところ、今回はDNSの伝播を待ち、更に5秒待つように直しているため、以前より実行時間が伸びているため、もし何かしらのタイミング処理がある場合は見直しが必要。

今回の対応をした理由

切欠としてはモジュール化の作業中に不具合が発覚したところに始まる。

これまで共通部品として.plを使っていたが、Perlの再利用性について考えていた時に.pmの概念を知ったので改修することにした。その動作確認をしていたところ、ワイルドカードドメインの更新がやたらと失敗することに気付き、本格的に調査を始めたのが発端だ。

そして以前は次の順序で処理していた。

1. 初回走行時にルートドメインのTXTレコードを追加する
2. 二回目走行時にこのレコードをワイルドカード用のTXTレコードで上書きする

しかし、本来これは正しくなかった。ワイルドカードドメインを指定する場合、プライマリとセカンダリのTXTレコードが両方とも登録されている必要があるようだった。

ではなぜ今まで動いていたのか。これはDNS更新のタイミングの関係で偶々成功していただけと思われる。そして、私がそのことに気付いていなかったわけだ。動作確認で何度も実行しているとやけに失敗するので、今回この不具合に対応することに決めた。

そして前述の更新内容に繋がるわけだが、これまでは--manual-auth-hook向けのスクリプトしか用意しておらず、その中で「既存ACMEレコードがあれば上書きする」という擬似的なクリーンアップ処理を行っていた。これが前述の不具合を引き起こす要因となっていたため、次の改修を施した。

• auth側からクリーンアップ処理（既存ACMEレコードの上書き）を除去し、純粋に「TXTレコードを追加する」だけの処理に変更
• 新たに--manual-cleanup-hook用のスクリプトを追加し、authで登録したレコードをDNSから削除する処理を、こちらに新設した

これにより、プライマリ・セカンダリ両方のTXTレコードが正しく揃った状態でLet's Encryptの検証に渡され、検証完了後にきちんと後始末されるようになった。

参考までにコケていたときは次のエラーが出ていた。

Certbot failed to authenticate some domains (authenticator: manual). The Certificate Authority reported these problems:
Domain: hogezzz.lycolia.info
Type: dns
Detail: DNS problem: NXDOMAIN looking up TXT for _acme-challenge.hogezzz.lycolia.info - check that a DNS record exists for this domain

Domain: hogezzz.lycolia.info
Type: unauthorized
Detail: During secondary validation: Incorrect TXT record "tiHFPEdgZ24aejUpmRkkzNvzUoisQn6mDv3d3xqHBNo" found at _acme-challenge.hogezzz.lycolia.info

あとがき

二日で15コミット、変更行数は1,397行追加、217行削除という結構大規模な改修を入れたので、どこかにバグが潜んでいる可能性は捨てきれない。

何せ以前開発していたvalue-domain-dns-cert-registerから、このvalue-domain-dns-utilに移行するときにLLMにガっとやらせてから、今回に至るまでコードのメンテはほとんどLLMに任せている。

当然LLMが書いたコードはレビューして明らかに変なところは手直ししているが、精々コード全体の3-4割で、過半数はLLMが書き、LLMが直せる場所は私が直さずLLMに直させている。テストコードに至っては99%くらいLLMに書かせており、正直正しいコードが掛かれているのかまで見切れていない。以前なら血眼になってテストコードを書いていたはずなのに不思議なものである。

まぁでも実コードを手直ししたら落ちたので、たぶん機能していると思う。あとvalue-domain-dns-cert-registerから継承されたテストコードについては一通り見ているので、全く見ていないわけでもない。

LLMにコードを書かせると作るのは楽だがレビューが大変なのが困りものだ。あと私はAnthropicをBANされている関係で地味にお金がかかるのも困りものである。今回の改修には20USDほどかかっており、安くはない。もう少し手でコードを書くべきだとは思う。考える力も徐々に薄れていっている気がしており、人間として危機感を感じることもある。

ボケ防止のためにはAIに頼らず、自分の手を動かすのも大切なことだと思う。こういう話では、よくそろばん論を持ち出して、そろばんを使わなくなったが人類は劣化していない、電卓があるみたいなことを言う人がいるが、実際問題珠算ができる人は非常に速い速度で暗算ができ、頭の回転も速いとされているので、電卓があるから優位と言われれば、それは違うと思う。例えば電卓を取り出す時間で計算が終わっていたり、物事を予測しやすかったりするわけだ。

ある能力が減った分、別の能力が増えるみたいな考えもあるとは思うが、一人の人間としてAIにべったり過ぎるのもやや危険ではないかと思う。第一災害時どうするんだと思うし、登山などでは電波の届かない山の中ではそもそも使えないとかもあるし、ボケるボケないも寿命に影響するみたいな話は聞くので、考える力は大切だと思う。私は管理職とか企画職みたいなところよりは、現場人間でありたい気もしているし…。

なんだかオチが迷走してきたが、とりあえずvalue-domain-dns-utilはワイルドカード証明書も含めて安定して動くようになったはずなので、必要に応じて更新してもらえれば安定性が増すかもしれない。もしバグを踏んだら報告してもらえれば対応するかもしれません。

しかしこのスクリプトは動作確認が非常に面倒なので、できればもう手を入れたくないところではある…。

そば米汁のそば米を自家製そば米にして作ったもの。

調理時間は30分程度。

• 材料
• 調理方法
• 一食当たりの栄養価の目安
• おまけ：抜き実で作ったときの写真

材料

二食分。夕飯に作って、余りを翌日食べることもできる。

そば米でなく、生の抜き実でも作れる。その場合は50mlが40gの目安。抜き実で作った場合の特徴としては、芯が残り芋のようにホクホクした食感になるのと、出汁の染みが悪くなるのと、ぬめりが出る。

個人的にはそば米で作ったほうが食味が良いと感じている。

調理方法

1. 人参、鳴門金時、玉ねぎを5mmほどの細切りにする。皮は剥かない
   

   

   

   

2. しいたけは軸を外し5mmの薄切りにし、軸も5mmくらいの薄切りにする
   

   

3. 鶏もも肉を適当な細切りにする
   

   

4. 鍋に水500mlを入れ、沸騰させる
   

   

5. 中火にする
   

   

6. 鍋にヒガシマルうどんスープを溶かす
   

   

7. 鍋にそば米→具材の順で入れる
   

   

   

8. 蓋をして10分煮込む
   

   

9. 蓋を開けて盛り付けて完成
   

   

   

一食当たりの栄養価の目安

二食分としたときの一食当たりの栄養価の目安。数値はあすけんを使い、そばの実の部分はそば米として計算している。

おまけ：抜き実で作ったときの写真

40gの分量。

茹でた後の状態。出汁の吸いが悪く、そばの実があまり目立たない。

盛り付けた状態。そば米と比べるとふっくらしておらず、小ぶりな見た目で、緑色が強く出る。

食感としては芋のようにホクホクした感じになるのと、朝作って夜に作り置きを食べようとするとぬめりが強いと感じた。また半日おいても出汁の染みが悪く、ホクホク感が残ったので、個人的にはそば米化した方が、食味が好ましかった。