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をバックアップするストレージをどうするか…。

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

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

昨年フレッツ光クロス、10Gbps対応に関する覚書を書いてしばらく経つが、いよいよ10GbE対応のための環境を作ろうと思ったので、その記録を残していく。

第一弾はR86S U1を買ったので、その購入録とOSのセットアップまでのログを書いていく。

• 買ったもの
• セットアップ時にあるといいもの
• 初回起動
• 試験起動
• eMMCへのOSインストール
  • 事前準備
  • インストール手順
• 開梱の儀
• 分解
• あとがき

買ったもの

今回購入したのは中華性の怪しい10GbE自作ルーターマシンとして名高いR86S U1だ。もう話題になって数年経っているので旬は過ぎていると思うが、依然として10GbEルーターとして安価な選択肢だと思う。

買った後で気が付いたが、U2のほうがスペックが上で値段同じなのでU2を買ったほうがいい。

セットアップ時にあるといいもの

• HDMI to Micro HDMI変換アダプタ
• SDカード or USBメモリ
• rufusやbalenaEtcherなどのイメージを焼く手段
• MSYS2

初回起動

私が購入したものはeMMC内にOSが上手く入っていないのかgrubが表示されるだけで、マニュアル操作でも起動イメージが見当たらずｍOSを起動することができなかった。

どの道プリインストールされているOSは中国語で役に立たないという話だったのでOSのセットアップを行うことにした。

試験起動

汎用PCへのインストール手順は公式情報である、[OpenWrt Wiki] OpenWrt on x86 hardware (PC / VM / server)が参考になる。

1. リリース一覧を開き最新の安定板を辿り、x86→64に進む
2. generic-ext4-combined-efi.img.gzをダウンロードする
3. sha256sum openwrt-24.10.0-x86-64-generic-ext4-combined-efi.img.gzでハッシュを確認
4. gunzip openwrt-24.10.0-x86-64-generic-ext4-combined-efi.img.gzで展開する
   • Explzhだと上手く解凍できなかったのでMSYS2からgunzipを叩いて対処した
5. 展開して出てきたimgファイルをSDカードかUSBメモリに焼く
6. imgファイルを焼いたメディアをR86Sに差し込む
7. R86Sの電源を入れPOST画面が出たらDeleteを叩き、BIOSに入る
   • 通電時に勝手に電源が入るため一回落とした方がいい
8. 起動順序を差し込んだメディアに変更する

eMMCへのOSインストール

Ubuntuのインストールディスクの中にOpenWrtのイメージをバンドルする方法がわからず、SDカードにimgを焼いてもマウントできなかったのでネットワークを経由してインストールしている。

事前準備

1. OpenWrtのイメージファイルを入力しやすい短いファイル名にしてHTTPが疎通するどこかに置いておく
2. R86S U1に前述のイメージと疎通可能なLAN線を刺す

インストール手順

1. Ubuntu Serverのインストールイメージを落とす
   • 日本語版サイトから落とすとEFIイメージでないものが落ちてきたので本家から落としてきたほうがいい
2. rufusを使って何かしらのメディアに焼く
3. R86S U1を起動し、POST画面でDeleteを叩き、BIOSを開く
4. 起動順序をUbuntuを焼いたメディアにする
   • USBの場合はUSB Key
5. Ubuntuを起動し、GrubでTry or Installを選ぶ
   

   

6. キーマッピングを日本語にするところまでインストールウィザードを進める
7. 右上のヘルプを開き、Enter shellする
   

   

   

8. wgetで事前準備で用意した起動イメージを落とす
9. eMMCにイメージを焼く

   dd if=openwrt-efi.img bs=1M of=/dev/mmcblk0
   

10. shutdownコマンドを叩く
11. 再起動でBIOSに入り起動順序をeMMCに変更
12. GrubにOpenWrtが出て起動することを確認
13. passwdコマンドでパスワードを設定する

2025年8月4日追記

この続きはR86SとOpenWrt 24.10でOCNバーチャルコネクトに接続したときのメモに書いている。

開梱の儀

梱包状態。安い中華製品にしてはなかなか丁寧だ。

箱もしっかりしている。

横の小さな箱にはMicro HDMI -> HDMIケーブルが付属していた。これは親切だ。

開梱すると本体とACアダプタが見えた。やはり梱包が丁寧だ。

箱の底にはマニュアルと検査証、六角が入っていた。この六角は本体を開けるためのものだが、なめてしまい役に立たなかった。

ネットワークインターフェースはSFP+が2口、2.5GbEイーサーが3口。他に電源用USB-C、USB3.0x2、USB2.0x1、SDカード、Micro HDMIといった感じだ。

表面にはケースファンと冷却用のフィンがついている。デザインも悪くない。

裏面と片側面にはゴム足がついており横置きにも縦置きにも対応している感じだ

分解

付属の六角がなめてしまい役に立たなかったのでちゃんとしたのを買ってきた。対応するのは1.5mmだった。

表のふたを開けるとNVMeSSDスロットが見える。ネジ穴的に一番長い奴しか無理だろう。

本体をパカっと二つに。どうやらマザーボードは三枚くらいに分割されているようだった。

あとがき

EFIイメージかBIOSイメージかは好みで選んでいいという記事を何個か見たが、BIOSイメージだと起動しなかったため、EFIイメージのほうがいいかもしれない。

参考までに手持ちのAMD64マシンにBIOSイメージを刺したところ、そもそも認識すらしなかったためダメなのかもしれない。24.10固有の問題なのかどうかはわからないが、今時はUEFIが推奨される環境であると思われるため、EFIイメージで問題ないと思われる。

ひとまずこれで10GbE環境への一歩を踏み出せたと思う。LANが構築でき、現状の環境でWAN込みで安定稼働させられたら実際に10GbE契約もしていきたいところだ。

しかしイメージを焼いたSDをマウントできないのは想定外だった。FAT32でフォーマットしたはずなのでマウントできそうなものだが…。正直焼いてマウントして取り出すより、アップしてwgetしたほうが楽なので別にいいのだが。

ChromeからEdgeに乗り換えて一年半くらい経ったので、個人的にEdgeとChromeに思うところの比較をしてみた。これは別に優劣をつけるものではなく単なる感想。

Ad Block

Edgeには標準でAd Blockが導入されており、Chromeのようにサードパーティ製の胡散臭い拡張機能に依存する必要がない。

参考として個人的にはChromeの場合、uBlock Originを広告ブロッカーとして利用していた。これはAd Blockよりも強力だと思う。

ダウンロード結果の保持

Edgeではダウンロード結果を保持することができる。以下の画像の右側で「ダウンロード」と出ている垂直バーだ。

これが出ているとzipなどの書庫をダウンロードしたときに展開してフォルダに遷移がスムーズにできて便利だし、ダウンロード完了直後にアクション出来なかった場合も対応しやすいので非常に助かる。

Chromeにはこの機能がないのでダウンロードが完了した直後にクリックしようとしてもできないことがあるし、仮にできても展開先を開くには再表示しないとならず手間だ。ダウンロード中にクリックしておくとアクションの予約もできるが、上手く動かないことも多い。これは多分タイムアウトがかかってるのだと思う。

マウスジェスチャ

Edgeには標準でマウスジェスチャが導入されており、サードパーティ製の拡張機能に依存する必要がない。

ChromeのマウスジェスチャといえばcrxMouse Chrome™ Gesturesが有名だと思うが、この拡張機能は過去に公開停止されており、個人的にあまり信頼していない。

Edge標準のマウスジェスチャはcrxMouseと比べると貧弱だが、一般的なパターンと、必要最低限の割り当てができ、特定Webサイトでは機能しないようにするブロックリストもあるため、十分使える。何よりファーストパーティなので安心しやすい。

UIがころころ変わらない

Chromeはコンテキストメニューがスクロール方式になったり、ブックマークバーや各種メニューのボタンがある日突如、肥大化したり、ユーザーを使って大胆なABテストをしてくるので使いづらく感じることがしばしばあった。

Edgeを使っていて、このような破壊的変更を感じることはなく、全体的に落ち着いている印象だ。これは質実剛健なマイクロソフトと、柔軟に対応するGoogleとの会社文化の差としてみることもできそうだ。

クライアント領域の広さ

左がEdge、右がChromeの画面上部のUI部分だが、Edgeのほうが少しだけUIが狭い分、クライアント領域が広い。

Chrome Webストアから消えた拡張の維持

EdgeではChrome Webストアから拡張機能が消えても維持されるが、Chromeだと強制的に削除される。強制的に削除されると設定ごと吹き飛ぶため、Tampermonkeyのようにユーザー定義が大きな拡張はバックアップがないとマニュアルで再導入するのも厳しい。

但しEdgeであってもインストール元が消えているため、ブラウザの再インストール時には消えると思われる。

他端末とのタブ共有

Edgeを利用している他の端末が現在開いているタブを共有できる。これは最後に開いていた状態を持っているため、電源が落ちている端末のタブも見れる。

この機能は端末を多く持っている人ほど恩恵があるだろう。Chromeにも同様の機能があるようだが、内容は確認していない。

閉じたウィンドウを開き直す

Edgeでは誤ってウィンドウを閉じたときでも、閉じたウィンドウを復元できる機能がある。

最近閉じた項目にウィンドウが閉じた履歴が出るので、ここから復帰できる。

もちろん閉じたウィンドウの中身は展開でき、何を閉じたかも確認できる。

Chromeにもあるが、履歴に存在せずショートカットキーで出しづらいのと、何を閉じたのかが一目でわからないのが微妙に感じる。

垂直タブバー

Edgeには垂直タブバーがあり、多数のタブを開いているときに便利なケースがある。しかし個人的にはChromeのタブリストの方が必要な時にだけ画面上に被さるように出てくるため使いやすいと感じている。Edgeのは画面が狭くなるし、タブバーを開いている間は本来のタブが消えてしまうので操作性が悪い。

Edgeの垂直タブバー

垂直タブバーを表示すると元々のタブが消え操作性が変わってしまう上、能動的に非表示にしないと画面を占有して邪魔なので私はあまり好きではない。

タブバーを出す前	タブバーを出した後

Chromeの同等機能

Edgeと比べてUIに破壊的変化がなく、フォーカスを失えば勝手に消えるので便利だ。

設定同期

Edgeの設定同期には問題がある。それは設定の大半が同期されないことだ。Edgeにはマイクロソフトによるお節介機能が多くあり、これを無効化するための設定が多くあるのだが、これらは全く同期されない。無数に設定がある割に不親切だ。マイクロソフトの広告系の機能ならまだしも、マウスジェスチャすら同期されないのはいくら何でも酷いと思う。

一方でChromeは、設定画面にあるものであれば、ほとんどすべての設定が同期される。標準ダウンロード方式以外恐らくすべて同期されているのではなかろうか？

設定の単純さ

Edgeにはマイクロソフトの利益に繋がる広告機能や、Copilotなどの本質的にブラウザとして不要な機能が山のようにあり、これらの有効無効を切り替える設定が数多くある。これは多くの人間にとっては複雑なことだと思う。

一方でChromeの設定も多いとはいえ、Edgeと比べると単純だ。設定することもさほどないので導入が圧倒的に楽である。

ブラウザベンダーの広告

Edgeはひたすらマイクロソフトのサービスに誘導するように色々と邪魔くさく仕向けてくるが、Chromeではそんなことはない。

但しこの広告は設定で消す事ができるため、一度消してしまえば気になることはない。

HTTPヘッダを持たないHTTPリクエストはあり得るのか？というのを検証しているときに気づいた話。

RFC 7230ではHostヘッダを持たないHTTPリクエストは禁止されており、これを受けたサーバーは400応答を返すことを必須としている。

RFC 7230:Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and RoutingのHostより

A client MUST send a Host header field in an HTTP/1.1 request even if
the request-target is in the absolute-form, since this allows the
Host information to be forwarded through ancient HTTP/1.0 proxies
that might not have implemented Host.

A server MUST respond with a 400 (Bad Request) status code to any
HTTP/1.1 request message that lacks a Host header field and to any
request message that contains more than one Host header field or a
Host header field with an invalid field-value.

なお、Node.jsのHTTPサーバー機能ではHostヘッダーのない要求を受け入れることができる。

http.createServer([options][, requestListener])を見ると、以下のようにrequireHostHeader: falseを渡すことで実現可能だ。規定値はtrueであるため、基本的にはHostヘッダーなしの要求は400応答が返される。

import http from 'node:http';

http
  .createServer({requireHostHeader: false}, (req, res) => {
    console.log(req.headers);
    res.statusCode = 200;
    res.end();
  })
  .listen(3000);

nginxにおいてもHostヘッダーなしの要求は以下の応答が返されたため同様と思われる。

<html>
<head><title>400 Bad Request</title></head>
<body>
<center><h1>400 Bad Request</h1></center>
<hr><center>nginx/1.26.0</center>
</body>
</html>

但し、nginxにおいてHostなしの要求を許容する方法は見つからなかった。Server namesによるとserver_name "";とすることで出来そうに見えたが、これは機能させることができず、400応答が返された。