「さくらのVPS」の旧プラン(v4)から新プラン(v5)にサーバを引っ越してみた

　さくらのVPSのプランが新しくなって（リージョンによっては）現行より費用が安くなるのでサーバを移転してみました。しかも今VPSを契約すると抽選でSwitchとかもらえるらしい。

　旧プラン(v3、v4)も放っておけばそのうち新プラン(v5)と同じストレージサイズに増設される予定です。ただし価格は据え置きの模様。

「さくらのVPS SSD V4バージョン」ご利用中のお客様
内容：ストレージの増設を予定しております。
※料金の変更はございません
※本件のストレージ増設作業は無料です。
※V3バージョン以前のサーバ、またはHDDプランは対象外です。
【予告】「さくらのVPS」及び「さくらのVPS for Windows Server」リニューアルのお知らせ – さくらのVPSニュース

　「そのままでもいいかな」とも思っていたのですが、HDDプランだとSSD移行時に「ストレージ変更オプション」相当で1,000円取られるっぽいし、Switch当たるみたいだし、ということで引っ越しを決めました。

　「さくらのVPS」の詳しいプランはこちらを参照のこと。

さくらインターネットのVPS

1. 旧サーバの設定をバックアップ

　rsyncでサーバごとまとめてどかんとコピーでもよかったのですが（たしか前はそうした）、クリーンインストールもいいかと思ったので今回は必要なファイルだけ旧サーバからコピペしました。

/etc/iptables/rules.v4
/etc/iptables/rules.v6
/etc/letsencrypt/cli.ini
/etc/mysql/mariadb.conf.d/50-server.cnf
/etc/nginx/sites-available
/etc/nginx/nginx.conf
/etc/nginx/snippets
/etc/nginx/conf.d/default.conf
/etc/php/7.3/fpm/pool.d/www.conf
/etc/exim4/update-exim4.conf.conf
/etc/ssh/sshd_config

　このほかにWordPressのデータベースとかファイルとかが別であります。
　できるだけプレーンな状態でサーバを運用するのが信条なので荷物は少ないです。最近はNginxやCertbotなんかも標準のリポジトリから引っ張ってこれるので楽になりました。

　ちなみに rsync を使って引っ越ししたときの記録はこちら。

リニューアルした「さくらのVPS」の新プランにサーバを移行した / icoro

2. 新サーバの立ち上げ

　うちではDebianを使っているので、カスタムOSからdebian 10 をインストールしました。よくわかんなくてもインストールガイドに従って進めればインストールは完了します。

カスタムOSインストールガイド – さくらのサポート情報

　特に事情がなければ最初から入ってるCentOS使うのが面倒がなくてオススメです。

2.1. パケットフィルタ

　「さくらのVPS」ではデフォルトだと「パケットフィルタ」がはじめからONになっていますが、カスタムOSをインストールした場合はOFFになります。

パケットフィルタの利用方法 – さくらのVPSニュース

　とりあえずウェブサイトを運用するぶんにはパケットフィルタがあれば十分そう。もうiptablesを使わなくてもいいのん？　SSHのポートが22固定なのがちょい気になりますが、今みんな鍵認証でのログインしか使わないからどうでもいいのかな？　あとIPv6はすべて許可状態になってるのも気になる。IPv6よくわかんないんだけど別にいいのかな……？

　ちなみに「さくらのVPS」でサーバ立ててSSHのポート変えたのに「通らないぞ……？」という場合はパケットフィルタが有効になっているのが原因かもです。

2.2. 鍵認証の設定

　ローカルで作成した公開鍵をサーバに転送します。「USER」は自分のユーザ名、「123.456.789.012」はサーバのIPアドレスに置き換えて下さい。サーバ立ち上げのときくらいしか使わないのでやりかた忘れがち。

$ scp .ssh/id_rsa.pub USER@123.456.789.012:

　サーバにログインして転送した公開鍵をauthorized_keysに追加（リネーム）し、ついでに権限も自分しか参照できないように変更しておきます。

$ mkdir .ssh
$ mv id_rsa.pub .ssh/authorized_keys
$ chmod 700 .ssh
$ chmod 600 .ssh/authorized_keys

　設定したら鍵認証でログインできるか確認してみます。

2.3. 基本的な設定

　ルートに化けてとりあえずサーバをアプデしておきます。debian系はいつからか apt-get でも aptitude でもなく apt を使うようになってました。使い方は apt-get が apt になっただけです。

$ su -
# apt update
# apt upgrade

　さしあたって使いそうなソフトをインストールしておきます。sudoはログインし直さないと有効にならないみたいです。

# apt install sudo logwatch vim

　標準のエディタをvimに変更（デフォルトではnano）。

# update-alternatives --config editor

　ユーザを sudo と www-data のグループに追加。例によって「USER」は自分のユーザ名です。現在所属しているグループは「id USER」で確認できます。www-data を nginx とかにしてる人も多いかも？

# usermod -aG sudo USER
# usermod -aG www-data USER

2.4. ssh設定

　設定ファイル /etc/ssh/sshd_config の中から以下の項目を探し出してパスワードでのログインを無効にします。ポート番号もここで設定します（パケットフィルタを使用している場合は22番固定）。「12345」のところは自分の使いたいポート番号を設定します。

Port 12345
PasswordAuthentication no

　保存したらsshdをリロード。

# /etc/init.d/sshd reload

　今サーバにつないでるターミナルはそのままにしておき、別のターミナルを開いてちゃんと指定したポートでログインできるか確認します。完全にログアウトしちゃうとポート番号のミスタイプなどでログインできなくなった場合、サーバに入る方法がなくなってしまいます（シリアルコンソール使えるけど）。

2.5. iptablesの設定

　iptables は「さくらのVPS」で提供されている「パケットフィルタ」を使ってるなら別に設定しなくてもいいのかも。そういえば最近、 iptables よりも簡易的なファイアウォールが提供されてたような。名前忘れた。

　debian系は再起動すると iptables の設定を忘れてしまうので設定を保持するために一工夫する必要がありました。でも、いつからか iptables-persistent をインストールするだけで設定が保持されるようになりました。なお、 iptables は最初からインストールされています。

# apt install iptables-persistent

　設定ファイルは以下にあります。設定はv4とv6に分かれています。

/etc/iptables/rules.v4
/etc/iptables/rules.v6

　rules.v4 の内容はこんな感じ。

*filter

# Allows all loopback (lo0) traffic and drop all traffic to 127/8 that doesn't use lo0
-A INPUT -i lo -j ACCEPT
-A INPUT ! -i lo -d 127.0.0.0/8 -j REJECT

# Accepts all established inbound connections
-A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT

# Allows all outbound traffic
# You can modify this to only allow certain traffic
-A OUTPUT -j ACCEPT

# Allows HTTP and HTTPS connections from anywhere (the normal ports for websites)
-A INPUT -p tcp --dport 80 -j ACCEPT
-A INPUT -p tcp --dport 443 -j ACCEPT

# Allows SSH connections
# THE -dport NUMBER IS THE SAME ONE YOU SET UP IN THE SSHD_CONFIG FILE
-A INPUT -p tcp -m state --state NEW --dport 30000 -j ACCEPT

# Allow ping
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT

# log iptables denied calls
-A INPUT -m limit --limit 5/min -j LOG --log-prefix "iptables denied: " --log-level 7

# Reject all other inbound - default deny unless explicitly allowed policy
-A INPUT -j REJECT
-A FORWARD -j REJECT

COMMIT

Ubuntu server on VMware Fusion – iptablesをインストールしてみる / icoro

　rules.v6 はとりあえずすべてのアクセスを拒否する設定にしてます。「IPv6でサクサク！」とか健康食品みたいな謳い文句をたまに目にしますが、実際なにがどうなのかよくわかってません。

*filter
:INPUT DROP [0:0]
:FORWARD DROP [0:0]
:OUTPUT DROP [0:0]
COMMIT

　設定を反映して作業は終了。

# netfilter-persistent reload

2.6. exim4の設定

　メール送信ができるようにexim4の設定をしておきます。
　新規で設定する場合は以下のコマンドを実行すると対話式で設定できます。

# dpkg-reconfigure exim4-config

3. ウェブサーバの設定

　ウェブサーバ運用がらみのソフトを一式インストールします。

# apt install certbot mailutils nginx mariadb-server php7.3 php7.3-fpm php7.3-mysql php7.3-curl php7.3-gd php7.3-mbstring php7.3-xml php7.3-zip php-imagick

3.1. MariaDB (MySQL)

　MySQL はいつの頃からか MariaDB に変わっていました。名前は違いますが、中身はほぼ MySQL です。OpenOffice と LibreOffice 的な事情のようです。

　　以下のコマンドで初期設定ができます。前からあったっけ？

# mysql_secure_installation
Remove anonymous users? [Y/n] y
(anonymousユーザを削除しますか？)
Disallow root login remotely? [Y/n] y
(rootのリモートログインを制限しますか？)
Remove test database and access to it? [Y/n] y
(testデータベースを削除しますか？)
Reload privilege tables now? [Y/n] y
(特権テーブルを更新しますか？)

　従来の my.cnf に相当するファイルは /etc/mysql/mariadb.conf.d/50-server.cnf のようです。

3.1.1. unix_socket 認証プラグイン

　Ver.5.7からは root の認証に unix_socket 認証プラグインを使うようになっていて、なんとrootに化けてから

# mysql

と入力するだけで MySQL (MariaDB) の root アカウントとしてログインすることができます。-u も -p も不要！

　しかしその一方で、root アカウントに入るにはサーバの root アカウントになっている必要があるため、PhpMyAdmin で root アカウントにログインすることができなくなりました（新規インストールした場合。過去のVer.からアップデートした場合はそのまま使えるっぽい）。

　どうしても PhpMyAdmin を使ってデータベースを管理したければ、root アカウントを unix_socket 認証からパスワード認証に変える（戻す）か、root とは別に全権を付与したアカウントを作成するかする必要があります。
　例えばこんな感じ（「PHPMYADMIN_ROOT」は phpmyadmin で使うアカウント名、「PASSWORD」はそのアカウントで使うパスワードに置き換えてください）。

CREATE USER 'PHPMYADMIN_ROOT'@'localhost' IDENTIFIED BY 'PASSWORD';
GRANT ALL PRIVILEGES ON *.* TO 'PHPMYADMIN_ROOT'@'localhost' WITH GRANT OPTION;
FLUSH PRIVILEGES;

Ubuntu 18.04 + MariaDB | 技術メモの壁

3.2. Let’s Encrypt

　Let’s Encryptのサーバ引っ越し作業は /etc/letsencrypt を新しいサーバにまるごと移せばそのまま使えるらしいです。でもよくわかんなかったので普通に設定し直しました。

　DNS に登録しているIPアドレスを書き換え、ドメインが新しいサーバを向いていることを確認したのち、certbot を実行します。

# certbot certonly --webroot -w /var/www/DOMAIN/PATH/ -d WWW.DOMAIN.COM

　/var/www/DOMAIN/PATH/ はルートディレクトリのパス、WWW.DOMAIN.COM は https を使用するドメインで置き換えてください。

Nginx 側で http へのアクセスを https に転送する設定にしていると失敗するので、あらかじめ http でもアクセスできるようにしておきましょう。
　このやり方だと切替の際に数分から数十分程度のダウンタイムが発生しますが、なんかもっとスマートなやり方あるんですかね？

3.2.1. 自動更新の設定

　Let’s Encrypt を使用している場合、3ヶ月ごと（証明書が更新されるタイミング）に Nginx をリロードして更新された証明書を読み込ませる必要があります。これを手動で実行するのはスマートではないので、証明書の更新時に Nginx をリロードする設定を /etc/letsencrypt/cli.ini に追記しておきます。

post-hook = /etc/init.d/nginx reload

　/etc/cron.d/certbot をに直接 post-hook を記入する方法もありますが、こちらのほうが作業も管理も簡単です。

　だいたいこんな感じ。あとはWordPressのデータベースとかwp-contentとかを新しいサーバにコピーして移転完了。

3.2.2. 証明書の削除

　サブドメインが不要になって証明書を削除するときは revoke を使用します。例によって WWW.DOMAIN.COM は削除したいサブドメインです。

# certbot revoke --cert-name WWW.DOMAIN.COM

スナップショットがとりたいです！

　ずっとサーバを引っ越しするときの手順をまとめておこうと思っていたのでいい機会といえばいい機会だったかも。まとめてみたら思ってたより手を加えてる設定ファイルが少なかったです。
　さくっとディスクイメージを保存できるような機能を提供してもらえるとバックアップとか引っ越しが簡単になっていいなって思うんですけど、果たしてそんな日はくるのでしょうか……自分でMondo Rescueとか使ったほうが早いかな……

参考

さくらインターネットのVPS