家族の見舞いで病院に行こうと思っていたのですが、最近のcovid-19の影響で見舞いは自粛するよう病院から速達が来ました。
それで少し時間ができたので、conoha VPSの512MBプランのSSD 20GBからSSD 30GBへ引っ越しを行いました。手順は以下の通り。（今回は、zfs send tank@snap | ssh new_machine zfs receive newtankではなく、VPSのimage fileで引っ越しました。）
(1) 元のVPSのimage fileを作成する
% su
# zpool scrub peach
# zpool status peach
(snip)
scan: scrub in progress since Sun Feb 23 09:58:17 2020
12.3G scanned at 51.7M/s, 10.2G issued at 43.1M/s, 13.9G total
0 repaired, 73.58% done, 0 days 00:01:27 to go
(snip)
scrub実行中は上記のような感じで残り時間の予測が表示されます。
scrubが完了すると
# zpool status peach
(snip)
scan: scrub repaired 0 in 0 days 00:04:55 with 0 errors on Sun Feb 23 10:03:12 2020
(snip)
のような表示になります。
# shutdown -p now
念の為、VPSをシャットダウンしてからconohaのコントロールパネル
でimage fileを保存します。
image fileの保存が終わったら、元のVPSを起動します。
(2) 新たなVPSを作成します。512MBプランで先程のimage file を使って作成すると、SSD 30GBのVPSができます。
(3) 新しいVPSをsingle user modeで起動します。
SSD 20GBのimage fileで作成したため、
# gpart show
を実行すると元のVPS(20GB)のSSD partitionが表示されるので、
# gpart recover
vtbd0 recovered
で30GB SSDが正しく利用できるようにリカバーします。
# gpart show -l
=> 34 62914486 vtbd0 GPT (30G)
34 512 1 freebsd-boot (256K)
546 39845376 2 peach (19G)
39845922 2097085 3 freebsd-swap (1.0G)
41943007 20971513 - free - (10G)
今回はpeach(freebsd-zfs)を26GBに、残り(約4GB)をswapに
しました。
# gpart delete -i 3 vtbd0
# gpart resize -i 2 -s 26g vtbd0
# gpart add -t freebsd-swap -l freebsd-swap vtbd0
# gpart show -l
=> 34 62914486 vtbd0 GPT (30G)
34 512 1 freebsd-boot (256K)
546 54525952 2 peach (26G)
54526498 8388022 3 freebsd-swap (4.0G)
# zpool get size peach
NAME PROPERTY VALUE SOURCE
peach size 18.9G -
gpartだけでは増やしたpeachはまだ拡張前の領域しか使えない
ためonlineにします。
# zpool online -e peach vtbd0p2
# zpool get size peach
NAME PROPERTY VALUE SOURCE
peach size 25.9G -
これでちゃんと増えました。
また、zpool statusでupgradeせよと警告が出ていたので、つい
でにupgradeしておきました。
# zpool upgrade peach
# gpart bootcode -b /boot/pmbr -p /boot/gptzfsboot \
-i 1 vtbd0
# zfs mount -a
# zfs set readonly=off peach
これでsingle user modeで書き込み可能となります。しかし
conoha console(svc)は106キーボードを想定しているようで、
101キーボードでの入力は辛い（例えば=は、テキスト送信ウイン
ドーに^を書かないと入力できない)ので、ssh接続ができるよう
に/etc/rc.confと/etc/ipfw.confをssh関連だけ修正して
multi user modeに移行して、あとはxtermでsshして残りの
修正を行いました。（これはconohaのカスコンのvps設定でコ
ンソールキーマップをen-usに変更し忘れていたのが原因でし
た。）修正したファイルは
/usr/local/etc/nsd/nsd.conf
/usr/local/etc/apache24/httpd.conf
/usr/local/etc/apache24/extra/httpd-ssl.conf
/usr/local/etc/dovecot/dovecot.conf
/etc/ssh/sshd_config
/usr/local/etc/nsd/ish.org.conf
/usr/local/etc/nsd/peach.ish.org.conf
/etc/mail/peach.ish.org.mc
です。またxtermでssh接続する手元のマシンは
/etc/nsswitch.confを編集してhosts: files dnsに戻し
てpeachの新アドレスを/etc/hostsに書いて作業しました。
同様に新VPSはnsdで新しいアドレスを広告してもlocal_unbound
はrootサーバから古いVPSのnsdを見に行ってしまうので、
/etc/hostsに新VPSのIPv4/IPv6アドレスを書いて動作確認を
行いました。
(4) 一通り動作確認が終わったら、conohaのカスコンにログインし てDNSを更新する
(5) network solutionsのカスコンにログインしてIPv4のglue recordを修正する。IPv6のglue recordは修正できないのでメー ルで修正を依頼する。
たったこれだけですがテレビを見ながらやったら5時間近くかかってしまいました。VPSを作成し直せばSSD容量が増えることは昨日知ったばかりで何の前準備もしてなかったので、DNSのA/AAAAレコードのttlはやたら大きいままです。従って、かなり長期に渡って旧サーバのIPアドレスがキャッシュされている可能性がありますが旧サーバは今月末位には止めちゃうつもりです。（と新サーバ上のwordpressには書いても旧サーバには書いていませんが..）