ConoHa VPS (v3)にDebianをインストールする方法(2024年1月時点)

本記事はConoHa VPS (v3)でDebianインスタンスを立てようとおもったら、標準イメージにDebianがなくて切ない思いをしたひとのための記事です。

2024/01/20(土)のDebian勉強会(オンライン開催)にて、本記事の内容を発表予定です。 debianjp.connpass.com

はじめに

ConoHa VPSには従来のv2に加えて、v3という異なるインフラのサービス群が昨年追加されました。 v2では標準イメージとしてDebianを選択することができましたが、v3では標準イメージとしてUbuntuは選択できるもののDebianはありません。 OpenBSDとかNetBSDとかFreeBSDはあるのに。

しかし、各種APIは提供されているのでそれを使えばなんとかなりそうです。

なお、ご利用ガイド CLIツールで簡単にISOイメージをマウントするはv2向けっぽいのでv3では利用できません。

ISOイメージをつかってインストールするには

公式ドキュメントにISOイメージを使ってインストールする方法が案内されています。

APIでVPSにISOイメージを挿入する

上記手順に従って作業すればDebianをインストールすることが可能です。やったね。

Debian bookworm 12.4.0のnetinst.isoあたりをダウンロードしてきて使うと良いでしょう。

カスタムISOを使ってインストールしたい

なお、Debian公式イメージを使ってインストールする場合、ConoHa 標準イメージを利用した場合のように次のことができません。

  • 初期構築の時点でsshの公開鍵認証を使う

パスワード認証でsshとかもうやりたくないですよね。最初から公開鍵認証にしたい。

カスタムISOイメージをつくる

ようは事前に公開鍵認証のための設定を仕込んでいけばよいわけです。

自動化のためのソリューションはいろいろあるようです。 お好きなものを選択するのが良いでしょう。

本記事では、preseed.cfgをCDイメージに含めて参照するfile preseedについて説明します。

前提条件は「1 core 512MBの最小スペックのDebianインスタンスを構築し、公開鍵認証でログインできるようにする」です。 インストール時には全部自動化まではできなくてもよいものとします。(きちんと作り込むのがちょっと面倒くさいので)

なお、初期イメージとしてUbuntu 22.04を選択すると最小スペックの512MBのインスタンスは使えません。Ubuntu 20.04を選択しましょう。

事前準備

まずは、CDイメージの中身をとりだしておきます。

sudo mount -o loop debian-12.4.0-amd64-netinst.iso /media/cdrom
sudo cp -r /media/cdrom rootfs
sudo chown $(USER):$(USER) -R rootfs
sudo umount /media/cdrom

あとはこれをcustom-isoとしてコピーしてそっちをいじります。

Graphical Installを無効化する

デフォルトではGUIインストーラーを起動しようとするのであらかじめ殺しておきます。512MBではテキストモードでのインストール一択です。

diff --git a/isolinux/menu.cfg b/isolinux/menu.cfg
index 2b89df3..f8e961a 100644
--- a/isolinux/menu.cfg
+++ b/isolinux/menu.cfg
@@ -3,7 +3,7 @@ menu width 70
 
 menu title Debian GNU/Linux installer menu (BIOS mode)
 include stdmenu.cfg
-include gtk.cfg
+#include gtk.cfg
 include txt.cfg
 menu begin advanced
     menu label ^Advanced options

テキストモードの選択と、リージョンなどの質問をスキップする

うっかり、他のモードでインストールが始まらないように、テキストモードをデフォルトにしておきます。

diff --git a/isolinux/txt.cfg b/isolinux/txt.cfg
old mode 100644
new mode 100755
index 4bec49c..794be48
--- a/isolinux/txt.cfg
+++ b/isolinux/txt.cfg
@@ -1,4 +1,5 @@
 label install
        menu label ^Install
+       menu default
        kernel /install.amd/vmlinuz
-       append vga=788 initrd=/install.amd/initrd.gz --- quiet 
+       append language=en country=US keymap=us file=/cdrom/preseed/preseed.cfg vga=788 initrd=/install.amd/initrd.gz --- quiet 

また、起動時のパラメーターでインストール中の言語やキーマップの選択をスキップできるようにします。

他の質問をスキップするために、file=/cdrom/preseed/preseed.cfgを読み込むように指示しておきましょう。 あとは、preseed.cfgがうまく作り込めていればテキストモードでの質問にいちいち答えなくてもいいわけです。

preseed.cfgで公開鍵認証を有効にする

# Setup public key
d-i preseed/late_command string \
  cp /cdrom/preseed/sshd_config.d.local /target/etc/ssh/sshd_config.d/local.conf ; \
  mkdir -p /target/home/debian/.ssh ; \
  cp /cdrom/preseed/authorized_keys /target/home/debian/.ssh/ ; \
  in-target chown debian:debian -R /home/debian/.ssh ; \
  in-target chmod 400 /home/debian/.ssh/authorized_keys

preseed.cfgの最後のあたりに上記のような設定を追加します。 あらかじめdebianユーザーがpreseed.cfgによって作成してあって、そのauthorized_keysを設定するという想定の記述例です。

sshdの設定もCDイメージに含めておけば、上記のようにして一緒に仕込んでおくこともできます。

CDのコンテンツのチェックサムを更新する

cd custom-iso; \
sudo chmod +w md5sum.txt; \
find -follow -type f ! -name md5sum.txt -print0 | xargs -0 md5sum > md5sum.txt; \
sudo chmod -w md5sum.txt

CDイメージに含めるファイルを書き換えているので、チェックサムを更新しておきます。

リマスタリングCD

sudo genisoimage -quiet -r -J -b isolinux/isolinux.bin -c isolinux/boot.cat -no-emul-boot -boot-load-size 4 -boot-info-table -o netinst.iso custom-iso

作業しているディレクトリがcustom-isoだとしたら、その親ディレクトリでコマンドを実行してnetinst.isoを生成します。 (-b-cオプションに指定しているisolinux/isolinux.binなどは親ディレクトリに存在していなくて支障ありません。)

さいごに

本記事は、ConoHa VPS (v3)で標準イメージとしてDebianが選択できるようになったら、役割を終える内容です。 賞味期限がたぶん短いはずなので試すならお早めに。(標準イメージとしてDebianが利用できるならわざわざこんなことしなくてもよいためです。)

この記事はUltimate Hacking Keyboard v2で執筆しました。

My Free Software Activities in Dec 2023

しばらく記事を書いていなかったか。

最近は11月はDebian勉強会で発表したり、年末のあんどきゅめんてっどでびあん2023年冬号の原稿を執筆したりしていた。 今月は地道にパッケージのメンテナンスをしていた。

今年はGitHubスポンサーで投げ銭してもらうというイベントもあった。たぶんDebianでのパッケージのメンテナンス活動が評価されたのだろう。 collectdに投げていたパッチがマージされたのもよかった。ただv6向けの作業などいくつか課題が残っている。

いいキーボード(Ultimate Hacking Keyboard v2)を入手できたので、そのUltimate Hacking Keyboard 60入門を執筆して頒布したりもした。 在庫が若干数なのでどこぞの誰かに刺さるとよい。UHK v2はお高めではあるものの、分割キーボードかつポインティングスティックがついているという意味で自分の印象としてはエンドゲームに近い。 あとはキースイッチとかキーキャップを揃えるという沼が待っているくらいだ。(自作キーボードの沼にはまだはまってはいない。)

来年は、もうちょっと精力的に活動できると良い。

My Free Software Activities in Aug 2023

先月は、パッケージのdouble build問題への対処やDMARCがらみのことを調べてまとめたりしたり、 メロンブックスさんで Ultimate Hacking Keyboard 60入門を頒布しはじめたりもした。在庫はあと2冊のはず。 物理本を欲しい方はそちらをどうぞ。 linux-firewire-utilsのレビューに協力をしたりもしている。

さくらのメールボックス利用者のためのDMARCポリシーの設定方法

さくらのメールボックスは、自分で独自ドメインのメールサーバーを運用まではしたくない人にとってはメールサービスだけ契約でき、費用もお手頃なのでとても助かっています。

rs.sakura.ad.jp

もし検討するなら、さくらのメールボックスの基本仕様を参照するのがおすすめです。

help.sakura.ad.jp

実際、過去にGandi.netがドメインに付随する無料メールボックスを廃止してしまったときは、さくらのメールボックスに乗り換えました。

kenhys.hatenablog.jp

さて、昨今ではメールをちゃんと送るためにはSPFやらDKIMの設定をしておくことが推奨されています。 ただし、さくらのメールボックスではDKIMは設定できません。

さくらのレンタルサーバに対するご要望はありませんか?
  • 投票数:123
  • コメント数 13

メールサーバーのDKIM対応

現在SPFには対応していますが、DKIMには対応していないので、迷惑メールに分類されないためにも対応を希望します。

sakura.uservoice.com

要望自体はあがっているものの、未対応です。

というわけで、DMARCポリシーでチェックさせるべきはSPFのみということになります。

そのため、独自ドメインのメールアカウントをさくらのメールボックスで運用する場合、次のようなTXTレコードを設定しておくのがおすすめです。

例えば、example.orgなメールアカウントを運用している場合、_dmarc.example.orgのTXTレコードに以下を設定します。

v=DMARC1; p=quarantine; fo=s; aspf=s; rua=mailto:dmarc-reports@example.org; ruf=mailto:dmarc-reports@example.org
項目 説明
p=quarantine 例えば、example.orgから受け取ったメールの認証に失敗したら、不審なメールとして扱うように依頼します。
fo=s SPFしかさくらのメールボックスでは設定できないので、SPFが失敗したら失敗レポートをrufで指定したアドレスへ送信するように依頼します。
aspf=s メールの送信元のドメインが厳密に一致していることをチェックします。例えばexample.orgサブドメインを詐称しているようなメールを受け付けない。
rua 集計レポートの送信先を指定する。
ruf 失敗レポートの送信先を指定する。要は詐称したもしくは設定ミスったメールが送られているようなら、受信したメールサーバーに教えてもらう。

ruaやrufとしてメールアドレスを公開することになるので、場合によってはそこへのSPAMが届くことが懸念されます。

通常はp=noneからはじめて、(設定不備により)不審なメールとして扱われないことをレポートから確認してから、徐々にp=quarantineもしくはp=rejectへと移行するのが推奨されています。 (しかし、そもそもレポートを送るようにちゃんと設定してあるメールサーバーがそれほど多くないという話もあるので、あんまりメリットないならレポートを受け取らない判断をしているところもあるのかもしれません。)

ただ、そのまま忘れていてp=noneかつrufやruaを設定せず運用していると、ドメインを詐称したメールを自分の関知しないところで送られてしまっているまま気づかない状態が続くことになるので、 p=noneにするなら、rufやruaを設定して観測できるようにしてから、早めに移行したほうがよいとは思います。

この記事はUHKv2で執筆しました。

How to setup DMARC policy for subdomain on debian.net

For setting up subdomain on debian.net, we usually use LDAP Gateway. [1]

db.debian.org

[1] https://db.debian.org/doc-mail.html

With changing dnsZoneEntry, we can set up each subdomain of debian.net.

For example, you can customize SPF TXT record for example.debian.net.

example IN TXT v=spf1 a:example.debian.net ~all

But when you setup DMARC policy for dnsZoneEntry, it may cause the trouble. LDAP Gateway returns the following error:

Command is not understood. Halted - no changes committed

This is caused by unsupported v=DMARC1 record by changes@db.debian.org.

Even though LDAP Gateway doesn't support v=DMARC1 record, there is a workaround for it. (e.g example.debian.net)

  • Step 1. If you own your domain, set v=DMARC1 record on your domain. (e.g. _dmarc.example.example.org)

TXT record of _dmarc.example.example.org is something like this:

v=DMARC1; p=quarantine; fo=s; aspf=s; rua=dmarc-reports@example.debian.net; ruf=dmarc-reports@example.debian.net

  • Step 2: Set dnsZoneEntry on debian.net

dmarc.example IN CNAME dmarc.example.example.org.

It means that _dmarc.example.debian.net is provided by _dmarc.example.example.org 's txt record.

Now you can ready to verify it.

My Free Software Activities in July 2023

先月は、Debian勉強会でDebian Installerの話をしたのが主なものかな。 コミケで頒布されるらしい「あんどきゅめんてっどでびあん」には以前発表したrepackの話が収録される予定です。

B450Pro4とM.2 NVMeとPCIEとSATAの組み合わせ問題を解く(2023年7月時点)

本記事はそろそろストレージを交換してみようと思い立ち、調べてみたところ 意外にはまりどころが多かったというお話を書き記したものです。

結論としては、将来的にストレージをたくさん生やすなら、拡張性の高いそれなりのMBを最初から選んでおくべきという身も蓋もないものになりました。 ただし、制約あるのはわかった上で、手持ちの機材をうまく組み合わせて活用しようというのを否定する意図はありません。

B450Pro4にした経緯

購入当時、MBの指名買いまではしないタイプのBTOで購入したためです。 いわゆるチップセットまで指定で、どのマザーボードになるかは店舗におまかせスタイルでした。

カタログスペックを見る限り、端子にはUSB Type-Cも一つあるし(今となっては見劣りするが)くらいは気にしましたが、 特にどのマザーボードでないとだめというような思い入れはなかったためです。

たいていの場合、ある程度経過したら一式まるごと買い替えることになるだろうし、というのもありました。(パーツを交換しつつ想定以上に長く使うことになった)

ストレージを交換したい欲求が高まる

購入当初から使用していたのが、Intel 660pというNVMeです。 SSDに比べて高速ではあるものの、512GBだったので容量もそれほど多くなく、書き込み速度も2000MB/sに届かず今となってはやや見劣りします。 不足する容量については旧PCで使用していたSSDやHDDをSATA接続してまかなっていましたが、SATA接続ではインターフェースの速度の縛り(6Gbps)もあって、遅さが気になってきました。

B450Pro4ではM.2スロットが2つあることを思い出し、新しくM.2 NVMeを調達し、現在使っているIntel 660pをサブにまわすことにしました。

NVMeの情報を探してみたら不穏な話題を見つけた

どのNVMeを調達するか調べていたところ、つぎのような不穏な情報を入手しました。

ASRockの特定MBとSSDの組み合わせ問題

なんとB450Pro4では認識しないものが多数あるというのです。

WDやKIOXIAのものがだめということになると、入手性のよいメジャーと思われるものは使えないということになります。

実際、ASRockのサイトでもややわかりにくいですが、非互換情報が公開されていました。

Not Compatible Storage Device

Toshiba,Kioxia,WD,ZhiTai,ADATA,Patriot,SK Hynix,Kingston,Samsung,Lexarと結構なメーカーと相性の問題を抱えている(なんでそんなことになったレベル)ことがわかります。

Crucialは互換性のある内蔵型SSDの情報があるので、余計なトラブルを踏みたくないなら、Crucial一択でしょう。

https://www.crucial.jp/compatible-upgade-for/asrock/b450-pro4

ただし、ベンチマークの情報によると評価はいまいちなのが残念なところです。

Crucial P5 Plusレビュー:Micronによる自社製造モデルですが・・・

MB自体の制約を整理する

それだけでなく、よくよくB450Pro4の仕様を確認してみると、結構はまりそうな制約がいくつかあることがわかりました。

**M2_1 デバイスで使用されている場合は、PCIE4 は無効になります。

現状ですでに制約がかかっている状態でした。 PCIE4というのは、マザーボードの4つめのPCIEスロットを指します。 GPUはPCIE2スロットを使っているので影響はないが、PCIE 3.0 x4 (32Gbps)なスロットはこの時点で使えなくなっているのでした。

  • 2 x PCI Express 3.0 x16 スロット (PCIE2: x16 モード; PCIE4: x4 モード)*

PCIE自体もCPUによって拡張スロットの速度に影響をうけます。PCIE4の上限はPCIE 3.0 x4なので、32Gbpsまでです。 (注: Ryzenの世代によってこの制限はかわります。)

*M2_2、SATA3_3、および、SATA3_4 共用レーン。 いずれかが使用されている場合は、その他は無効になります。

現在M2_1に刺しているNVMeをM2_2に移動しようと考えていたので、この制限にひっかかります。 念の為旧PCから移設したSSDやHDDの接続先を確認してみたところ、まさにSATA3_3およびSATA3_4を利用していました。 SATA3_A1、SATA3_A2、あるいはSATA3_2等を利用する必要があるようでした。

  • 1 x M.2 ソケット (M2_2), M Key タイプ 2230/2242/2260/2280/22110 M.2 SATA3 6.0 Gb/s モジュール、および、最大 Gen3 x2 (16 Gb/s) までの M.2 PCIe モジュールに対応**

また、M2_2はせいぜい2000MB/s程度しかだせません。 ただし、このスロットを使おうとしているIntel 660pはそもそも1500MB/s程度でこの上限に達しないので制限は受けません。

  • 1 x ウルトラ M.2 ソケット (M2_1), 最大 Gen3 x4 (32 Gb/s) までのタイプ M Key 2242/2260/2280 M.2 PCIe モジュールに対応

M2_1は4000MB/sが上限でした。

したがって、上記制約を考慮してNVMeを増設しようとすると、次のようなことになります。

案1: M2_2に増設する案

  • M2_1: 新規NVMe 4000MB/sまでのもの。ただし認識しないメーカーを避けること。
  • M2_2: 旧NVMeをM2_1から移設する。2000MB/sまでのもの。
  • PCIE4: 使用不可
  • SATA3_3: 使用不可
  • SATA3_4: 使用不可

案2: PCIE4に増設する案

この案にする場合、NVMe・PCIE変換ボードを介する必要があります。

  • M2_1: 使わない
  • M2_2: 旧NVMeをM2_1から移設する。2000MB/sまでのもの。
  • PCIE4: NVMe・PCIE変換ボードを介して新規NVMeを刺す。4000MB/sまでのもの。
  • SATA3_3: 使用不可
  • SATA3_4: 使用不可

あるいは、PCIE 2.0 x1なところに変換ボード(PCIe NVMe 変換アダプター)を使ってNVMeを刺すということもできるらしいです。 ただしその場合の上限は500MB/s程度になるようなので、刺せてもあまりうれしくないでしょう。

というわけで、最終的には(余計な変換ボードを噛まさなくてよい)案1のM2_1とM2_2併用案に落ちつきました。

さいごに

HIKSEMI 2TB NVMe (FUTURE70-02TB)は使えるという情報があったので、試してみたところ確かに使えました。(HIKSEMI 2TB NVMe Liteは3D NANDで別物。) kdiskmarkで測定したところ、3200〜3500MB/s程度でるようです。(Gen4向けのをGen3なB450Pro4のNVMeスロットに刺すのはちょっともったいない気もしますが、実売1万3000程度なのでお手頃感はあります。)

sudo smartctl -i /dev/nvme0n1p1
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.3.0-2-amd64] (local build)
Copyright (C) 2002-22, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       HS-SSD-FUTURE 2048G
Serial Number:                      (省略)
Firmware Version:                   SN08193
PCI Vendor/Subsystem ID:            0x1e4b
IEEE OUI Identifier:                0x000000
Total NVM Capacity:                 2,048,408,248,320 [2.04 TB]
Unallocated NVM Capacity:           0
Controller ID:                      0
NVMe Version:                       1.4
Number of Namespaces:               1
Namespace 1 Size/Capacity:          2,048,408,248,320 [2.04 TB]
Namespace 1 Formatted LBA Size:     512
Namespace 1 IEEE EUI-64:            000000 0000000002
Local Time is:                      Sun Jul 23 19:29:49 2023 JST