2026/07/16(木)経県値の話

投稿日:

旅行記事ネタが溜まっているが、ちっとも書けていないのでハイライト程度に経県値の話を書いておく。なんか旅行記事と関係ない場面の方が文章量がある気もするが、気にしてはいけない。

現時点での経県値

恐ろしいほどまでの西日本偏重である。それも四国と近畿以外は東海道・山陽新幹線の筋道に集中している。

四国と近畿以外で色がついている例外は佐賀と埼玉くらいだ。埼玉は観光しに行ったわけでなく仕事の都合で行っただけであるが、仕事の都合で一瞬だけ東京に住んでいたことがあり、その当時は赤羽に居を構えていたため、映画を見るために川口に通ったことがあるので、ギリギリプライベートでも足を踏み入れた土地となっている。

佐賀は仕事とは完全に無縁で、マンホールを見に行くという字面だけ見ると完全に頭がおかしい行動のために訪れている。

近畿は大体「訪問」しているが、奈良は「接地」で三重は「通過」となっており、近畿地方でも未訪問が残る。

なお、これらのステータスとしては私は次のように定義している。

ステータス 定義
未踏 その領域に地上経由で訪れたことがない
通過 その領域に地上経由で通過した。例えば電車やバスで通過した場合が該当する
接地 その領域に降り立った。例えば駅の構内を歩いた、県境を踏んだなど
訪問 その領域の空港・駅舎・バスターミナルから外に出て、乗り換え以外の目的で歩いた
宿泊 その領域の地上にある宿に宿泊した。フェリーや寝台列車・夜行バスで寝て通過した場合は該当しない
居住 その領域に転居届を提出し、居住した。最短記録は東京都の一ヶ月

通過の内訳

三重県

近鉄名阪特急を利用し通過したため。

ひのとりとアーバンライナーで通過した経験がある。いつかしまかぜで志摩スペイン村に行きたいと思っているが、場所が場所なので気軽に行きづらいのが難点である。

岐阜県

新幹線を利用し通過したため。

岐阜県に対する印象としては新幹線の車窓から見えるソーラーアークと、ゆるキャンの主要キャラクターの名前の由来になった自治体が多くあることが強い。

あとは各務原市には製菓メーカーが多い印象だ。例えばヤングドーナツの宮田製菓をはじめ、名前は一切記憶にないがファミマに置いているドーナツやバウムクーヘン、ベルギーワッフルは各務原市のメーカーが作っていた記憶がある。

静岡県

新幹線を利用し通過した県その2。

静岡県と言えばなんといってもお茶!と言いたいところだが、茶葉の生産量日本一は鹿児島に取られており、実は現在はトップではない。

沼津市ではラブライブ!サンシャインに全てを賭け、移住政策をしたり、駅をサンシャインカラーにしたりと面白い取り組みをしているほか、最近では超かぐや姫!と岳南電車や、富士市のコラボもあり、ゆるキャンの聖地のひとつでもあるため、何かとアニメに対して理解がある印象だ。

地理的には日本最大の行政区である葵区と、それに次ぐ面積を持つ天竜区を抱えるという化け物のようなところでもある。行政区面積二位の天竜区でさえ広島市を超える面積というのだから驚愕である。

交通的には身延町に通じる身延線が伸びているところでもあり、時間があればいつか乗ってみたい場所でもある。

接地の内訳

奈良県

これは2025年11月16日にイオンモール高の原で府県境を跨いだので接地としている。この写真は近鉄高の原駅から出てきて撮影しているので、奈良県の地を踏んでいる状態である。

イオンモール高の原は京都府と奈良県に跨っていることで知られており、建物の中に府県境が存在するのだ。

住所がどこになるか気になるところだが、京都府に所在し、京都府木津川市相楽台1丁目1番1ということになっている。元々は全域が京都府になる予定が奈良県との協議がご破算になり、中途半端に奈良県にはみ出したままになった経緯があるらしい。

最寄り駅は奈良県の高の原駅であるため、厳密に言えば訪問とも解釈できそうだが、私は京都府側にある映画館に行くために歩いて通過しただけであるため、接地扱いとしている。通過か訪問か、接地か悩ましいケースである。

福岡県

接地になっている理由は、博多駅で新幹線を降り、地下鉄や鹿児島本線に乗り換えるために博多駅構内を歩いたためである。

なんで山口と佐賀に訪問してて福岡が接地になるのか?というところだが、端的に言うと福岡では私が見たい映画を見たいときに上映していなかったからというのが最も近い答えになる。

これは山口には2025年3月23日に宇部市にあるシネマ・スクエア7にメイクアガールを観賞するために訪れ、佐賀県には2025年後半の複数日にわたりゾンビランドサガ ゆめぎんがパラダイスの鑑賞などで訪れた経緯があるからだ。なお、佐賀県の映画館は制覇しており、シアター・シエマ、THEATER ENYA、109シネマズ佐賀、イオンシネマ佐賀大和のすべてで映画鑑賞をしている。他に都道府県下の全映画館を制覇した例がないため、今のところ佐賀県のみが唯一となっている。

そして福岡県ではそういったことがなかったから行っていないということだ。私が遠征するときの動機の半分くらいが映画鑑賞にあるため仕方がない。

とはいえ、福岡県は見るべき場所が多い場所であることも知っているので、余裕があればいつかは行ってみたい場所だ。

例えば九州最大の繁華街と呼ばれる天神を練り歩くのは楽しそうだし、福岡のスカイラインだと私が勝手に思い込んでいるももちなんかも面白そうだ。

ももちはまず何といっても「ももち」という語感がいい。

何より百道さんの名前の由来だと思うので、それだけで行ってみたさがある。

他にもヤシの木ブランコなる場所には珍コンテンツが色々あるようで、ここも面白そうだし、立石ガクブチ店もレトロで良さそうな気配がする。

それに福岡と言えば食もあるだろう。特にチョコレートショップには寄ってみたいと考えている。博多の石畳なんか絶対に食べるべきだろう。一蘭とか一風堂とかめんべいは神戸にもあり何ら目新しさがないが、博多の石畳はここでしか食べられない。しかも定番土産などにも書かれていないので中々コアなコンテンツだと思っている。

因みに博多の石畳は通販でも買えるが、通販ではホールサイズしか扱っておらず、買うととんでもないサイズのケーキが届くので、冷凍庫がない人は買わないほうがいい。大変なことになる。]

あと福岡と言えば舞鶴よかともいい…。

個人的にご当地VTuberにはご当地の話を訛りのある方言で、自分の気持ちで話してほしい部分が大きいので、よかとはすごくいい。

逆にご当地Vを名乗っているのに一生ゲームしてたり、方言を喋らないか、稀に喋ったと思ったら棒読みだったりすると、支持しづらい部分がある。ご当地要素どこ…?みたいな。

そういえば最近知ったのだが、三宮から博多は東京と距離が大きく変わらないらしく、意外と遠いらしい。なんとなく西日本だから近いと思っていたので意外だった。

踏襲率が高すぎる県

兵庫県

まずは私の住む兵庫県から、一度も足を踏み入れていないのは宍粟市と猪名川町、新温泉町、稲美町の4自治体だけで、他は何かしらの形で最低限通過以上になっている。

香美町に訪問、養父市に宿泊しているのに県北部最大の観光地である豊岡市は通過扱いなのが私の奇行ぶりをよく表している。これは香美町にはカニを食べに、養父市には氷ノ山に登りに行ったことによる。豊岡には興味がなかったわけである。

地味に県内宿泊も多く、姫路市と加西市については終電を逃したことによる事故により宿泊を余儀なくされている。

佐賀県

47都道府県の中で唯一全自治体に何かしらの形で足を踏み入れたことのある唯一の県となっているのが佐賀県の特徴である。しかも4つの自治体で宿泊しているため、宿泊した自治体数でも最多となっている。

佐賀県で訪問扱いとなっている自治体は全てマンホールを見に行くためだけに訪問しているので、だいぶ常軌を逸している。それも車社会と言われる佐賀で全て公共交通機関でアクセスしている。なお佐賀の公共交通は徳島と比べると大変充実しており、ほぼ支障にならないと思う。マンホール見て次に周囲を見渡してるだけで時間が溶けて全く時間が足りないので、余裕だ。

アリタセラや伊万里市の街並み、海中鳥居、祐徳稲荷神社、ゆめぎんが、嬉野温泉なんか何時間でも見ていられる。武雄温泉なんか見る時間がなかったくらいだ。

中四国の空白地帯、山陰について

記事に出来ていないが、こないだの高知に行った件で四国は制覇したし、山陽地方も既にすべて訪問済みというところからすると山陰を埋めれば中四国を踏襲できるので、ここも行きたい気がしているが、予算と時間の都合がありなかなか難しい…。

特に島根は出雲大社や、宍道湖、一畑電車、松江城(現存天守)、出雲日御碕灯台、一畑薬師、一畑百貨店の跡地、Shimane Cinema Onozawa、隠岐など訪れたい場所が多くあり、やくもにも乗りたいので、そこそこ目的ができている。

鳥取も砂丘や鳥取城跡、青山剛昌ふるさと館、鳥取シネマ、MOVIX日吉津、はわい温泉、水木しげるロード、円形劇場くらよしフィギュアミュージアム、ひなビタ♪×倉吉辺りに興味があり、行ってみたくはあるものの、どれも場所が離れており、公共交通の便が良くなさそうなので攻略が難しそうな気はしている。行くならスーパーはくとで行きたいところだ。三宮から一本でいけるのは便利である。

2026/07/16(木)R86S U1のNICを交換した

R86S U1のNICについているSFP+ポートの片方が不安定という問題があり、これがずっと悩みの種だった。

しかしR86S U1のNICはOCP2.0のメザニンカードという特殊な規格であり、入手が難しかった。あと最近なんでも高いことや、ここ一年近く財政が悪く資金がショートしていたこともあり、中々購入のタイミングがなかったが、偶然安いのを見つけたので交換を決意した。

購入したもの

ほぼ新品 Mellanox ConnectX-4 CX4421A MCX4421A-ACQN ネットワーク インターフェイス PCIe カード (OCP2.0 用)

ほぼ新品とあるが中古なのは間違いない。

写真を見る限り左右でコネクタが異なるといったこともなく、3,745円でConnectX-3からConnectX-4に上げられて不調もなくなるならアリではないか?と思い、購入することにした。

配送

荷物はいつも通りCainiaoから発送され、国内ではエスポ便という聞いたこともない業者に引き渡された。軽く調べたところ株式会社エスポリアという越境ECのサービス会社がやっているようで、ここ最近のアリエクに増えているらしい。ここ自体は仲介業者で配送はしてないらしい。

そういえば最近中華特有のテカテカしたプチプチ袋減った気がする。

実際の配送はかつてAmazon便で悪名を馳せたTMG、椿本グループだった。久々に見たので、一般消費者向け宅配便事業で生きてたのかお前…となった。

開封の儀

結構ちゃんとした箱に入っていた。

中身。緩衝材が底にあり、本体も一応元袋らしきものに入っていた。いい感じのヒートシンクがついているのが素晴らしい。

賞味期限ラベルみたいなものが貼ってあったが非常に強力なシールで、爪でカリカリすると爪が削れるレベルで剥がせなかったため剥がすのを諦めた。

新旧比較をすると上が今まで使っていたやつで、下が今回新たに買ったやつだ。

裏返したところ。裏面には薄いアクリルフィルムが基板を保護するように付いていた。短絡防止用だろうか?ヒートシンクを支えるプッシュピンも見えた。

ラベルを見る限り2019年6月製とみられ、比較的新しい製品なのも嬉しい。以前使っていたConnectX-3は製造時期不明だがCX342Aは2015年のモデルらしいので、だいぶ古い。

どこで見たか記憶にないがConnectX-3はサポート切れが近いか、切れていることもあるという話も見た気がするのでConnectX-4を入手できたのはよかった。メイン機もサーバー機もNICはConnectX-4なのでお揃いになった。

装着は既存のConnetX-3を外し、カードを刺す場所に元々ついてたチップクーラーを除去して取り付けたら、そのまま何事もなく普通に装着できた。

このクーラーがあるとヒートシンクに干渉するので、外す必要があった。

OpenWrt上でのセットアップ

OpenWrt 24.10.0にはドライバがなかったのでドライバを入れるのをやっていく。

SFP+以外に接続手段のない私の環境ではルーターのSSHに繋ぐ術がなかったので、R86S U1本体にキーボードとモニタを接続して作業した。

# まずはNIC周りの調査ツールを入れる
opkg update
opkg install pciutils ethtool

# ドライバの状態とかが見れる
# Kernel driver in use: igcならドライバがない
lspci -nnk

# ドライバを入れる。kmod-mlx4-coreは後で消した
opkg install kmod-mlx5-core
# JISキーボードだとアンスコが出せないので頑張って探して打った
modprobe mlx5_core

あとはこのまま再起動したら普通に繋がった。

そのまま使うと温度が上がりすぎた

現状片側のSFP+しか使っていないうえ、それも初日なので不具合は何もない。以前使っていたのも最低でも一週間は使ってないと不安定化しなかったので、まだ安定性は不明だ。

ただソケットが両方とも同じ形に見えるので、以前使っていたものよりは安定するのではないかと考えている。

温度については高くなりがちなようで、R86S U1本体のCPU温度が51度に達することもあった。

以前のNICの温度はデータがなく比較できないのだが、ここまで上がっていることはなかった気がしている。

NIC本体の温度は取得する方法が今のところ分かっていない。mstflintでmstflint -d xxxx -reg_name MTMPとかしたら、提供されていないとか出た気がするがログは取っていない。

参考までに以下の手順でレジスタの値が取れるっぽい。参考:man/mstreg

# 必要なツールのインストール
opkg install lspci mstflint
# MellanoxのデバイスIDの取得
lspci | grep Mellanox | awk '{print $1}'
# レジスタ名一覧
mstflint -d <デバイスID> -show_regs
# レジスタ値の取得
mstflint -d <デバイスID> -reg_name <レジスタ名> -g

関係ないがデータがないのはGrafanaに出しているデータを永続化していないため、tmpが吹き飛ぶと消える状態なので、ここはそのうち何とかしないといけない。

冷却対策

端的に言うとヒートシンクを剥がし、R86S U1に元からついてるクーラーを装着した。

まずはConnectX-4を取り出し、ヒートシンクを外し、グリスを塗りなおす。この時ついでに裏のフィルムも剥がし、熱が溜まらないようにした。

R86S U1に元々ついてたチップクーラー(前述の奴)を持ってきて、付け直した。

ファンレス冷却(ヒートシンク)とファン冷却(クーラー)で同時刻に温度を比べたところ、5度ほど下がるという結果が出たので、かなり効果があった。

新しい奴のヒートシンクの方が目が細かく作りもしっかりしているように見えるが、風のあるなしがそれほどまでに大きいということだろう。

しょぼいヒートシンクと小さいファンの組み合わせなのであまり意味がないだろうと侮っていたが、結果は歴然だった。恐らくこれはケースが小さく通気の余地が少ないこともあり、自然対流には期待できないということの表れなのだろう。

ベンチマーク

以下の構成で速度を計測した結果。そもそもLAN内でパケットがルーターの中を通っているかが謎なのでルーターNIC交換の影響があるかどうかは不明である。

Windows - R86S U1 - MikroTik CRS305-1G-4S+IN - Ubuntu

以前の計測結果はこっち

Windows → Ubuntu

[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.01   sec  1.07 GBytes  9.13 Gbits/sec
[  5]   1.01-2.01   sec  1.09 GBytes  9.36 Gbits/sec
[  5]   2.01-3.00   sec  1.08 GBytes  9.36 Gbits/sec
[  5]   3.00-4.00   sec  1.09 GBytes  9.36 Gbits/sec
[  5]   4.00-5.01   sec  1.10 GBytes  9.36 Gbits/sec
[  5]   5.01-6.00   sec  1.08 GBytes  9.36 Gbits/sec
[  5]   6.00-7.01   sec  1.10 GBytes  9.36 Gbits/sec
[  5]   7.01-8.01   sec  1.09 GBytes  9.36 Gbits/sec
[  5]   8.01-9.01   sec  1.09 GBytes  9.36 Gbits/sec
[  5]   9.01-10.00  sec  1.08 GBytes  9.36 Gbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  10.9 GBytes  9.34 Gbits/sec                  sender
[  5]   0.00-10.00  sec  10.9 GBytes  9.33 Gbits/sec                  receiver

Ubuntu→Windows

[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  1.08 GBytes  9.30 Gbits/sec    0   1.54 MBytes       
[  5]   1.00-2.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.62 MBytes       
[  5]   2.00-3.00   sec  1.08 GBytes  9.27 Gbits/sec    0   1.70 MBytes       
[  5]   3.00-4.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.78 MBytes       
[  5]   4.00-5.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.78 MBytes       
[  5]   5.00-6.00   sec  1.08 GBytes  9.29 Gbits/sec    0   1.78 MBytes       
[  5]   6.00-7.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.78 MBytes       
[  5]   7.00-8.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.93 MBytes       
[  5]   8.00-9.00   sec  1.08 GBytes  9.28 Gbits/sec    0   1.93 MBytes       
[  5]   9.00-10.00  sec  1.08 GBytes  9.28 Gbits/sec    0   1.93 MBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  10.8 GBytes  9.28 Gbits/sec    0             sender
[  5]   0.00-10.00  sec  10.8 GBytes  9.28 Gbits/sec                  receiver

まとめ

前回と比較すると若干速度が落ちているが、サーバーとして動かしてて帯域を食っている分減っているのかもしれない。

Windows→Ubuntu(上り) Windows→Ubuntu(下り) Ubuntu→Windows(上り) Ubuntu→Windows(下り)
9.34 Gbps 9.33 Gbps 9.28 Gbps 9.28 Gbps

交換前のConnectX-3が改造品だった話

以前使っていたPCB000620は元々SFP+片ポートモデルで、どうやらR86S U1では2ポートに改造していたようだ。

その影響なのか明らかに片方だけソケットの形が異なる。上側のほうが綺麗で、下側は使いこまれているのか、ややぼろ目に見える。

裏面を見ると片方ははんだ付けされているが、片方は差し込んであるだけ。シールも一度剥がしたものを貼り付けているのか、ペラペラしていてすぐに剥がせた。

おそらく上側(PORT 0)のはんだ付けされていた方が本来のソケットで、後から付けたやつ、つまり下側(PORT 1)が差し込んだだけの奴と思われる。

本来のソケットがぼろい方、後付けのが綺麗な方である。

奥の方の作りも異なる。左がPORT 0、右がPORT 1。

R86S U1のNICについているSFP+ポートの片方が不安定だった話で不安定だったのはPORT 1の方なので、改造して無理に取り付けていた方が不具合を発していたのだろう。本来できないことをしているので無理もない。

裏面の形も異なる。

恐らくよくある片ポートの奴にソケットを増設したのだと思う。

ソケットが片ポートしかなくても回路が実装されていることはよくあるので、この回路を流用しているのだと思う。回路もあるし、チップも恐らく同じなので原理的には問題なく動きそうに思える。

R86S U1のSFP+を使い始めたのは2025年の9月17日からだった[1]が、同年12月13日にはリンクアップとリンクダウンが繰り返される事象を確認していて、同年12月25日にSFP+差し込みポートの変更を行ってからは一度も起きていない。

この時の気温が落ちたので金属製のSFP+ソケットの接触不良になったのではないか?と考えていたが、恐らくソケットではなく、基板本体との接触が寒暖差でダメになったのかもしれない。実際、先ほどの写真を見ても基板の穴からピンが出たり出ていなかったりするので、寒暖差でここが僅かに狂った結果、基板と接触不良になり、回路がチャタリングした結果、リンクアップとリンクダウンをミリ秒単位で繰り返す状態が起きていたのかもしれない。

もし、この理屈が正しければ強く押し込んではんだ付けすれば改善しそうではある。

あとがき

NIC交換の時に取り出した時、酷い埃まみれになっていたのでいい加減、冷却面をどうにかしたい気がしている。

普段は上に80mm角ファンを載せて運用しているため、埃の元凶はこれである。一旦はファンフィルターを買ってその場を凌ぎたいところだが、本質的にはちゃんとしたケースに収めてちゃんとしたクーラーをつけるのが最良だと思っている。

R86S U1を冷やそうとした作業の残渣にも書いているが、R86S U1の冷却機構は耐久性があるように見えず、また大して冷やしてもくれない。上にファンを載せて風を入れていると、いつの日か中が埃まみれになってしまうし、このケースはメンテナンス性が良くないので清掃も面倒だ。

理想論としてはこんな感じのケースに組み込めればよいだろう。これならメンテナンスがしやすいし、NICのヒートシンクも元の奴が生かせそうだ。ファンも40mm角ファンだろうから壊れても交換が容易である。

まぁこれは行き過ぎとしても、ラズパイのタワークーラーを載せるとか、そういうのができるとよいなとは思っている。基板むき出しは埃が溜まってショートしそうなので、ケースもあった方がいいだろう。

ただそれをどう実現するかが難しいところで、まず本来的には3D CADでケースやCPUクーラーをモデリングし、CNCで金属を削るという工程が必要だろうが、そんなものはないし、仮に3Dプリンタである程度何とかするにしても、3D CADの使い方を学ぶところからだと気が遠くなる話で、なかなか難しい…。

そもそもノギスで測っても測るたびに数ミリ単位の誤差が出るので、アナログな図面を書くことすら困難だ(多分ノギスの角度が微妙に毎回ズレてる)

こんなことであれば去年アリエクのセールでファンレスのR86SであるR86S-FLN100を買っておけばよかった。今は22.7万もするが、去年は11万くらいで、セールでは9万にまで落ちていて、買いだった。まぁあとからは何とでも言えるし、そもそも9万でも安くないわけで、言ったところで仕方がない。

現実案としては厚紙にボードを固定して外枠をペンで引き、ネジ穴については基板のネジ穴スレスレの何かを差し込んでマーキングすればそれなりに正確なものが取れるだろうから、一度手書きで図面を書き、それを基にアクリル板を加工し、簡単なケースを作るのが一段階目としてはよさそうな気がする。

ただCPUクーラーをどうするかという問題が根深く、ここが難点になると思う…。これはCPUクーラーを作るにはCPUのヒートスプレッダに乗ってくれるヒートシンクを持ったファンと、そのファンと基板のネジ穴を繋ぐ足が必要になるからだ。ヒートシンクと基板のネジ穴がマッチしないとならないので、恐らくこれが一番の難関だろう…。

たぶん厚紙→アクリル板がいければ図面を起こせるので、カスタムアルミケース業者に発注すれば、きちんとしたものも作れると思う。そこまでやるかどうかは未定だが…w


  1. 宅内に10GbE環境を導入してみたの写真のタイムスタンプから推定。

2026/07/13(月)令和にPerlでCGIを作る

更新日:
投稿日:

令和の時代にPerlでCGI…?という感じだが、PHP-FPMの上で動いてるLaravelとかもCGIの親戚みたいなものなので、そこまで違和感はないと思う。何せFPMはFastCGI Process Managerの略だからね。

でも令和の時代にPerl…?というのは、ちょっと面白いと思っている。

確認環境

Env Ver
Perl v5.38.2
fcgiwrap 1.1.0-14build1
nginx 1.24.0

実装方法

nginxの設定例

この設定ではドメイン直下のどこにアクセスされてもファイルがなければindex.cgiに飛ばしてCGIにルーティングを処理させるようにしている。

パスごとにCGIファイルを配置する方式ならtry_filesは不要だ。

server {
  listen [::]:443 ssl;
  server_name example.com;

  ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

  root /var/www;

  location / {
    index index.cgi;
    try_files $uri $uri/ /index.cgi;
  }

  location ~ ^.+\.cgi$ {
    fastcgi_pass unix:/var/run/fcgiwrap.socket;
    fastcgi_index index.cgi;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param HTTPS on;
    fastcgi_param SERVER_PORT 443;
  }
}

最低限の実装

Hello worldを出すだけの奴。レスポンスヘッダを書かないとnginxではエラーになった。Apacheでは試していない。

コード
#!/bin/env perl

# HTTPメッセージに近い構造になっている
# レスポンスヘッダを書いている
print "Content-Type: text/html; charset=UTF-8\r\n\r\n";
# レスポンスボディ
print 'Hello world';

これをindex.cgiとかで置いてやって所有者をwww-data:www-dataにして実行権限を付与したら動く。

sudo chown www-data:www-data index.cgi
sudo chmod u+x index.cgi

実行時エラーを出したりする

ファイルの先頭に以下の二行を加えると、実行時エラーをサーバーログに吐き出すようになる。

use strict;
use warnings;
コード
#!/bin/env perl
use strict;
use warnings;

# HTTPメッセージに近い構造になっている
# レスポンスヘッダを書いている
print "Content-Type: text/html; charset=UTF-8\r\n\r\n";
# レスポンスボディ
print 'Hello world';

環境変数を出す

コード
#!/bin/env perl
use strict;
use warnings;

print "Content-Type: text/html; charset=UTF-8\r\n\r\n";
print "QUERY_STRING => $ENV{QUERY_STRING}<br>";
print "REQUEST_METHOD => $ENV{REQUEST_METHOD}<br>";
print "CONTENT_TYPE => $ENV{CONTENT_TYPE}<br>";
print "CONTENT_LENGTH => $ENV{CONTENT_LENGTH}<br>";
print "SCRIPT_NAME => $ENV{SCRIPT_NAME}<br>";
print "REQUEST_URI => $ENV{REQUEST_URI}<br>";
print "DOCUMENT_URI => $ENV{DOCUMENT_URI}<br>";
print "DOCUMENT_ROOT => $ENV{DOCUMENT_ROOT}<br>";
print "SERVER_PROTOCOL => $ENV{SERVER_PROTOCOL}<br>";
print "REQUEST_SCHEME => $ENV{REQUEST_SCHEME}<br>";
print "HTTPS => $ENV{HTTPS}<br>";
print "GATEWAY_INTERFACE => $ENV{GATEWAY_INTERFACE}<br>";
print "SERVER_SOFTWARE => $ENV{SERVER_SOFTWARE}<br>";
print "REMOTE_ADDR => $ENV{REMOTE_ADDR}<br>";
print "REMOTE_PORT => $ENV{REMOTE_PORT}<br>";
print "REMOTE_USER => $ENV{REMOTE_USER}<br>";
print "SERVER_ADDR => $ENV{SERVER_ADDR}<br>";
print "SERVER_PORT => $ENV{SERVER_PORT}<br>";
print "SERVER_NAME => $ENV{SERVER_NAME}<br>";
実行結果

ライブラリを呼び出す

lib/Lyndbaum/Core.pmに次のライブラリを作成したとする。

パス名とpackage名の大文字小文字が一致してないと動かないので注意。

use strict;
use warnings;

package Lyndbaum::Core;

sub getEnv() {
    return (
        QUERY_STRING => $ENV{QUERY_STRING},
        REQUEST_METHOD => $ENV{REQUEST_METHOD},
        CONTENT_TYPE => $ENV{CONTENT_TYPE},
        CONTENT_LENGTH => $ENV{CONTENT_LENGTH},
        SCRIPT_NAME => $ENV{SCRIPT_NAME},
        REQUEST_URI => $ENV{REQUEST_URI},
        DOCUMENT_URI => $ENV{DOCUMENT_URI},
        DOCUMENT_ROOT => $ENV{DOCUMENT_ROOT},
        SERVER_PROTOCOL => $ENV{SERVER_PROTOCOL},
        REQUEST_SCHEME => $ENV{REQUEST_SCHEME},
        HTTPS => $ENV{HTTPS},
        GATEWAY_INTERFACE => $ENV{GATEWAY_INTERFACE},
        SERVER_SOFTWARE => $ENV{SERVER_SOFTWARE},
        REMOTE_ADDR => $ENV{REMOTE_ADDR},
        REMOTE_PORT => $ENV{REMOTE_PORT},
        REMOTE_USER => $ENV{REMOTE_USER},
        SERVER_ADDR => $ENV{SERVER_ADDR},
        SERVER_PORT => $ENV{SERVER_PORT},
        SERVER_NAME => $ENV{SERVER_NAME}
    );
}

1;
コード
#!/bin/env perl
use strict;
use warnings;

# @INCはライブラリをインクルードするパスを指定するための組み込み変数で
# unshiftは配列に要素を追加する関数
# つまりインクルードパスに./libを追加している
unshift(@INC, './lib');
# 読み込んだライブラリの使用
use Lyndbaum::Core;
# %で始まる変数は連想配列(ハッシュ)として機能する
my %e = Lyndbaum::Core::getEnv();

print "Content-Type: text/html; charset=UTF-8\r\n\r\n";
# ハッシュは$変数名{キー名}で参照できる
print "REQUEST_SCHEME: $e{REQUEST_SCHEME}<br>";
print "HTTPS: $e{HTTPS}<br>";
print "HOST: $e{HOST}<br>";
print "SERVER_NAME: $e{SERVER_NAME}<br>";
print "REQUEST_URI: $e{REQUEST_URI}<br>";
print "DOCUMENT_URI: $e{DOCUMENT_URI}<br>";
print "SCRIPT_NAME: $e{SCRIPT_NAME}<br>";

unshift(@INC, './lib');use lib './lib';元の構文みたいなものらしい。adiaryの実装がこうだったので真似してみたが、バッドプラクティスの可能性がある。

ステータスコードなどを返す

コード
#!/bin/env perl
use strict;
use warnings;

unshift(@INC, './lib');

use Lyndbaum::Core;

my %e = Lyndbaum::Core::getEnv();

# Status: <コード>でレスポンスステータスコードを返せる
# 指定しないと200になった
print "Status: 200\r\n";
# 好きなサーバー名を書いて君だけのサーバーを名乗ろう!
print "Server: Lyndbaum\r\n";
print "Content-Type: text/html; charset=UTF-8\r\n\r\n";
# レスポンスボディ
print "REQUEST_SCHEME: $e{REQUEST_SCHEME}<br>";
print "HTTPS: $e{HTTPS}<br>";
print "HOST: $e{HOST}<br>";
print "SERVER_NAME: $e{SERVER_NAME}<br>";
print "REQUEST_URI: $e{REQUEST_URI}<br>";
print "DOCUMENT_URI: $e{DOCUMENT_URI}<br>";
print "SCRIPT_NAME: $e{SCRIPT_NAME}<br>";

ルーティングする

パスが取れるのでもう朝飯前。

コード
#!/bin/env perl
use strict;
use warnings;

unshift(@INC, './lib');

use Lyndbaum::Core;

my %e = Lyndbaum::Core::getEnv();

print "Status: 200\r\n";
print "Server: Lyndbaum\r\n";
print "Content-Type: text/html; charset=UTF-8\r\n\r\n";

if ($e{REQUEST_URI} eq '/hoge') {
    # 文字列比較はeqなので注意、シェルスクリプトと同じ!!
    print "hoge!!";
} else {
    print "REQUEST_SCHEME: $e{REQUEST_SCHEME}<br>";
    print "HTTPS: $e{HTTPS}<br>";
    print "HOST: $e{HOST}<br>";
    print "SERVER_NAME: $e{SERVER_NAME}<br>";
    print "REQUEST_URI: $e{REQUEST_URI}<br>";
    print "DOCUMENT_URI: $e{DOCUMENT_URI}<br>";
    print "SCRIPT_NAME: $e{SCRIPT_NAME}<br>";
}

あとがき

何故Perlかというところだが、単にCGIとして実装したかったからだ。PHPやRuby, Pythonなどの選択肢もあると思うが、私はPythonが好きではなく、Rubyには興味がなく、最近のPHPもあまり好きではない。そこでPerlにすることにした。

PerlはPHPと比べたときに破壊的変更が少なく、枯れており、構文を覚えればワンライナーや簡単なスクリプトを書くのも便利だ。他にも構文が柔軟な部分も素晴らしい。

例えばPHPであれば以下のようにエスケープが必要なコードは

$hoge = '"/hoge/\'fuga\'/piyo/"';
if (preg_match("/(\/'fuga'\/)/", $hoge, $mat) === 1) {
    echo $mat[1];
}

Perlではこう書ける。

$hoge = qq("/hoge/'fuga'/piyo/");
if ($hoge =~ m|(/'fuga'/)|) {
    print $1;
}

qq()のqはquoteを指し、quoteが二つあるのでダブルクォートを指し示す。この演算子を使うことでPerlでは文字のエスケープを減らすことができ、書きやすさと可読性を保ちやすくなる。qq<>とかqq{}みたいに任意の記号を使うことができるので、文字列の中に(出たら終わりじゃんみたいなこともない。大変柔軟性がある。

$hoge =~ m|(/'fuga'/)|=~は正規表現の比較に使う演算子だが、ついでにキャプチャもしてくれる。更にm||のように書くことで正規表現内に/が含まれていてもエスケープ不要になる。qq同様に使う記号は好きに変えられる。

反面でPerl特有の演算子でもあるため、Perlが分からない人には暗号にしか見えないのは欠点と言えるだろう。

またPerlにはNode.jsの面倒さのようなものもない。例えばNode.jsならパッケージマネージャーをnpm, yarn, pnpmなどのどれにするかとか、実行環境をDeno, Bun, Node.jsなどのどれにするかとか、バージョン管理をVolta, nodenv, nvmなどのどれにするかとか、様々な争いがあると思うが、Perlにはそんなものはないと思う。

それに、このブログで利用しているadiaryはPerl CGIで実装されているし、lycolia.info配下のページも実は全部Perl CGIとして実装している[1]。つまり最近私の中でPerlブームが訪れているわけだ。ソフトウェア配布に置いてるのも現状Perl実装だしね。


  1. しかも恐ろしいことにルーティングなしでページ単位にcgiファイルがあるぞ!

2026/07/10(金)Windows 11でウィンドウが切り替わりづらい問題を解消したような気がする

投稿日:

Alt+Tabやタスクバーからのマウス操作で上手く切り替わらないことがあったので、その対策。

この問題自体の再現性が低い問題があり、これで完全に解消するかどうかは不明だ。そのため、まだ検証中である。

確認環境

  • Windows 11 Pro 25H2 (OSビルド26200.8737)

前提条件

  • タスクバーを自動で隠す設定にしている
  • タスクバーのボタンをまとめる設定にしている
  • タスクバーのボタンにラベルを出していない
  • タスクバー関係のユーティリティソフトを使っておらず、Windows標準の状態

解決する問題

こういう面倒な状態を解消する。

  • Alt+Tabでウィンドウを切り替えたのに切り替わってない
  • タスクバーからウィンドウをクリックしたのに切り替わらない
  • 前面にあるウィンドウをすべて最小化することでどうにか切り替えている状況

解決した方法

タスクバーを自動で隠す設定をやめるだけで解決した。

推定原因

タスクバーを自動で隠す設定でも切り替わる切り替わらないウィンドウがあるが、恐らくタスクバーを自動で隠す設定で、タスクバーの裏に回っているウィンドウがいるとそこに切り替わりづらくなると思う。

ただ、隠す設定をON/OFFすると、その瞬間は改善し再発しなくなったため、確証はない。

2026/07/10(金)OpenWrtでDHCPを払い出し直す方法

投稿日:

接続端末の追加・変更などでDHCPの変更をしたいときに、既存の払い出し期限を待たずに即座に新しい設定を反映させる方法。

確認環境

Env Ver
OpenWrt 24.10.0 (r28427-6df0e3d02a)
dnsmasq 2.90-r4

やり方

  1. DHCPの設定を必要に応じて変更する

    • LuCIからやってもいいが、ファイルベースでやる場合は/etc/config/dhcpを開いて直すとよい。形式は次のような感じ

      config host
             option name 'hoge'
             list mac '12:23:34:55:56:1A'
             option ip '192.168.12.10'
             option leasetime 'infinite'
      
      config host
             option name 'piyo'
             list mac 'F3:BB:11:22:34:2F'
             option ip '192.168.12.15'
             option leasetime 'infinite'
      
  2. 接続している機器をすべて切断する

  3. DHCPキャッシュを消して、dnsmasqを再起動する
    rm /tmp/dhcp.leases
    /etc/init.d/dnsmasq restart
    
  4. 接続している機器を再接続する