投稿者「yattenator」のアーカイブ

Raspberry Pi で OpenVPN サーバを作成 (L2VPN編)

OpenVPN と tap インターフェイスを使って、自宅に接続できるレイヤー2 (ブリッジモード) VPNを作成する。Layer2モードだと、自宅外から VPN 接続したときに bonjour や Windows ネットワーク検索のようなサービスが、自宅内と同様に使えるのがメリット。

自宅内サーバ: Raspberry Pi 2 (Raspbian 9.x stretch)
環境は以下の図の通り。

この文書の手順以外に別途、インターネット接続ルータでサービスポートを外部公開 (スタティック NAT) しておく必要がある。

クライアント側の要件として、Apple iOS 系機器は tap デバイスに対応していないため、Layer2 VPN を利用できないので本稿のターゲットから外れる。Android 系も標準 API標準クライアントでは tap に対応していない(端末の root 権限があれば対応可能。また有料ソフトウェアの OpenVPN Client は tap に対応している)。Windows 用の OpenVPN GUI、Mac の Tunnelblick などは tap デバイスに対応している。

1. OpenVPN パッケージインストール

OpenVPN 本体と、ブリッジ設定に必要な bridge-utils をインストールする。

$ sudo apt install openvpn bridge-utils

2. Raspbian のネットワークインターフェイスを bridge 設定にする

サーバ側の eth0 デバイスを直接使わず、ブリッジデバイス br0 を使い eth0 をそのメンバーとするように設定する。OpenVPNサーバプログラムの使う tap0 デバイスも br0 のメンバーとして、ブリッジ接続できるようにする。

サーバの IP アドレスとしては、固定アドレスを設定する(自宅内のIPアドレスをルータのDHCPに任せているなら、DHCP配布範囲外のアドレスで固定する)。

マシン起動時に自動的にブリッジデバイスが有効になるよう、interfaces ファイルを編集する。

$ sudo vi /etc/network/interfaces

auto br0
iface br0 inet static
        address 192.168.100.20
        netmask 255.255.255.0
        network 192.168.100.0
        broadcast 192.168.100.255
        gateway 192.168.100.1
        dns-nameservers 192.168.100.1
        dns-search example.com
        bridge_ports eth0

もともと eth0 だったところを br0 にして、bridge_ports eth0 を追加するように編集する。

ここで一度再起動して、br0 に IP アドレスが付くことを確認する。
$ sudo shutdown -r now

起動したら IP アドレスの状況を確認する。br0 に IP アドレスが付いていれば OK。

$ ip a
1: lo: <loopback,up,lower_up> mtu 65536 qdisc noqueue state UNKNOWN group defaul
t qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
2: eth0: <broadcast,multicast,up,lower_up> mtu 1500 qdisc pfifo_fast master br0
state UP group default qlen 1000
    link/ether 00:00:5e:00:53:11 brd ff:ff:ff:ff:ff:ff
3: br0: <broadcast,multicast,up,lower_up> mtu 1500 qdisc noqueue state UP group
default qlen 1000
    link/ether 00:00:5e:00:53:fe brd ff:ff:ff:ff:ff:ff
    inet 192.168.100.20/24 brd 192.168.100.255 scope global br0
       valid_lft forever preferred_lft forever</broadcast,multicast,up,lower_up></broadcast,multicast,up,lower_up></loopback,up,lower_up>

3. OpenVPN サーバ設定

OpenVPN サーバの設定ファイルを作成する。サンプル設定ファイルをコピーして、それをベースに編集する。

$ sudo mkdir -p /var/log/openvpn /etc/openvpn/ccd
$ sudo cp /usr/share/doc/openvpn/examples/sample-config-files/server.conf.gz /etc/openvpn/server/
$ sudo gzip -d /etc/openvpn/server/server.conf.gz
$ sudo mv /etc/openvpn/server/{server,udp7231}.conf
$ sudo vi /etc/openvpn/server/udp7231.conf

port 7231
proto udp
dev tap
ca ca.crt
cert server.crt
key server.key
dh dh2048.pem
server-bridge 192.168.100.0 255.255.255.0 192.168.100.192 192.168.100.223
push "dhcp-option DNS 192.168.100.1"
push "dhcp-option DOMAIN example.com"
client-to-client
keepalive 10 120
tls-auth ta.key 0
cipher AES-256-CBC
user nobody
group nogroup
persist-key
persist-tun
status /var/log/openvpn/openvpn-status.log
log-append  /var/log/openvpn/openvpn.log
verb 3
explicit-exit-notify 1
crl-verify crl.pem

dev tap 設定にするところがブリッジ方式の要になる。server-bridge 設定には、VPN クライアントに配布する IP アドレスの範囲を指定する。自宅内ルータの DHCP では、この範囲を配布対象外にしておくこと。

トランスポート層プロトコルは UDP を利用する(TCP over TCP 問題を避けるため)。利用するポートは念のため標準の 1194 から変えておくこととして、適当にランダムで決める。今回は 7231 とした。

4. サーバ証明書の準備

easy-rsa パッケージを利用して CA を作成し、サーバ証明書・鍵を作成する。CA 作業用ディレクトリとして、/etc/openvpn/easy-rsa を作成する。

$ sudo make-cadir /etc/openvpn/easy-rsa
$ sudo -i
# cd /etc/openvpn/easy-rsa
# ln -s openssl-1.0.0.cnf openssl.cnf
# vi vars

以下のような設定をvarファイルに記述する。

export KEY_SIZE=2048
export KEY_COUNTRY="JP"
export KEY_PROVINCE="Aichi"
export KEY_CITY="Nagoya"
export KEY_ORG="Home"
export KEY_EMAIL="root@raspberrypi.example.com"
export KEY_OU="Server"

CA を作成し、サーバ鍵・証明書を作成する。

# . vars
# ./clean-all
# ./build-ca
# ./build-key-server server

TLS Static Key と DH Keyを作成する。DH Keyの生成にはかなりの時間がかかる(Raspberry Piでは10分以上)

# openvpn --genkey --secret /etc/openvpn/server/ta.key
# ./build-dh
# cp -p keys/ca.crt keys/server.crt keys/server.key keys/dh2048.pem /etc/openvpn/server/
# exit

5. OpenVPN サービスの有効化と起動

サーバ側 OpenVPN サービス用の systemd ユニットファイルは /lib/systemd/system/openvpn-server@.service である。@の後に、サーバ設定ファイルのドットより前の名前(今回の場合は “udp7231″)を指定して有効化・起動する。

サービスを有効化し、起動する。
$ sudo systemctl enable openvpn-server@udp7231
Created symlink /etc/systemd/system/multi-user.target.wants/openvpn-server@udp7231.service → /lib/systemd/system/openvpn-server@.service.
$ sudo systemctl start openvpn-server@udp7231

これだけだと、ブリッジデバイス br0 に tap0 デバイスが組み込まれず、VPN クライアントと LAN との相互通信ができない。/etc/systemd 以下に追加の systemd ユニットファイルを作成して、その中で tap0 を br0 に追加する処理を行う。

$ sudo vi /etc/systemd/system/openvpn-bridge.service

[Unit]
Description=OpenVPN bridge service
Requires=openvpn-server@udp7231.service
After=openvpn-server@udp7231.service

[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/bin/sh -c '/sbin/brctl addbr br0 || /bin/true'
ExecStartPost=/bin/sh -c '/sbin/brctl addif br0 tap0 || /bin/true'
ExecStartPost=/sbin/ip link set tap0 up
ExecReload=/bin/true
ExecStop=/sbin/brctl delif br0 tap0

[Install]
WantedBy=multi-user.target

brctl addbr br0 の行は本来必要ないはず(br0 の立ち上げは /etc/network/interfaces に書いてあれば自動的に実行される)なのだが、タイミングの問題で openvpn サービス起動時にまだ br0 が無い場合があり、次の行の brctl addif br0 tap0 に失敗することがあるため、念のため加えている。

上記で作成した自作サービスを起動する。
$ sudo systemctl enable openvpn-bridge
Created symlink /etc/systemd/system/multi-user.target.wants/openvpn-bridge.service → /etc/systemd/system/openvpn-bridge.service.
$ sudo systemctl start openvpn-bridge

6. iptables 設定

ローカルファイアウォール設定で、OpenVPN の利用するポートを開けておく。

iptables の設定に iptables-persistent パッケージを利用している場合は、/etc/iptables/rules.v4 を編集して以下の行を加える。

-A INPUT -p udp -m udp --dport 7231 -j ACCEPT

設定を再読み込みする。
$ sudo netfilter-persistent reload

もしiptables直接ではなくufwを使っているのであれば、以下のコマンドでサービスポートを開ける。
$ sudo ufw allow 7231/udp
$ sudo ufw reload

ブリッジ設定の場合、パケットフォワーディングの設定(sysctl -w net.ipv4.ip_forward=1)は不要。

7. クライアント側設定テンプレートの作成

設定を複数のクライアントに配布するため、元となるテンプレートファイルを作成する。

$ sudo cp /usr/share/doc/openvpn/examples/sample-config-files/client.conf /etc/openvpn/client/client.template
$ sudo vi /etc/openvpn/client/client.template

client
dev tap
proto udp
remote 203.0.113.10 7231
resolv-retry infinite
nobind
persist-key
persist-tun
remote-cert-tls server
key-direction 1
cipher AES-256-CBC
verb 3
<tls-auth>
ここに /etc/openvpn/server/ta.key ファイルの内容をペーストする。
</tls-auth>
<ca>
ここに /etc/openvpn/server/ca.crt ファイルの内容をペーストする。
</ca>
<key>
</key>
<cert>
</cert>

証明書・鍵ファイル等を別ファイルの形で配布しても良いが、設定ファイルの中に取り込む形にしてみる。設定を単一ファイルで配布できれば取り回しが良いため。

8. クライアント証明書の発行と設定ファイルの作成

テストクライアント用の設定を作成して、動作検証してみる。

まず、1番目のクライアント鍵・証明書 (client1と命名) を発行する。

$ sudo -i
# cd /etc/openvpn/easy-rsa
# . vars
# ./build-key client1
# exit

クライアント1のための設定ファイル (client1.ovpn) をテンプレートから作成する。

$ sudo cp /etc/openvpn/client/{client.template,client1.ovpn}
$ sudo vi /etc/openvpn/client/client1.ovpn

client1.ovpn ファイルの中の <cert>, <key> 各セクションの中に、作成したクライアント証明書 (client1.crt) と鍵 (client1.key) ファイルの内容をコピー&ペーストする。

作成した /etc/openvpn/client/client1.ovpn ファイルを配布して、クライアントデバイスにインストールして接続確認する。

接続成功するようなら、client2、client3、…と設定ファイルを同様に作成していく。

9. クライアント証明書の失効手続き

クライアントを使わなくなったら、証明書を失効させておく。client1を失効させるためには、以下のコマンドを実行する。

$ sudo -i
# cd /etc/openvpn/easy-rsa
# . vars
# ./revoke-all client1

ffmpeg vs libav

動画・音声コーデック界のスイスアーミーナイフと呼ばれる ffmpeg から、数年前に libav がforkして分裂した。

参考: ffmpegとlibavの背景事情

Debian/Ubuntu の標準パッケージは libav の方に追随したのだが、結局メンテナンス頻度の問題で ffmpeg に再度鞍替えしたらしい。

参考: Ubuntu 15.10 その12 – Libavが無くなり、FFmpegに戻りました

forkがあったときにどっちに付いていくかは微妙な問題だけど、単なるいちユーザーとしては多数派になった方が使えればどうでもいいのよ、と思わないでもない。ffmpeg コマンドを前提にして色々スクリプトを書いていたが、コマンドが avconv に変わって、また ffmpeg に変わって、しかも微妙に互換性がないという困ったことになっている。

OpenOffice.org とか MySQL とか、ほかにも色々あるはず。

nginx のモジュール追加リビルド (CentOS 7 EPEL 版)

nginx 公式や epel パッケージの nginx バイナリでは使いたいモジュールがコンパイルされていない。特に nginx-dav-ext-module(WebDAV で OPTIONS メソッドが利用可能になる)、headers-more-nginx-module(HTTPヘッダを追加したり削除したり)、nginx-ct(証明書の透明性対応ができる)を使いたいので、ソースからビルドすることにする。

前提として、使用 OS は CentOS 7 である。

nginx 公式の RPM パッケージもあるが、この記事では epel リポジトリの nginx RPM をベースに、必要なモジュールの記述を追加して SRPM からリビルドしてみる。

1. コンパイルに必要なパッケージをインストール

$ sudo yum install gperftools-devel openssl-devel pcre-devel zlib-devel GeoIP-devel gd-devel perl-devel perl-ExtUtils-Embed libxslt-devel expat-devel git

2. epel リポジトリを追加

epel リポジトリを追加する。追加済みであれば作業の必要なし。
$ sudo yum install epel-release

3. SRPM の入手

SRPM をダウンロード・インストールする。
$ sudo yum install -y yum-utils
$ sudo yum-config-manager --enable epel-testing
$ yumdownloader --source nginx
$ rpm -ivh nginx-1.16.1-1.el7.src.rpm

今後 yum update で勝手にアップデートされないように、epel レポジトリを無効化しておく。
$ sudo yum-config-manager --disable epel\*

4. カスタマイズ

SRPM の spec ファイルを編集する。
$ vi rpmbuild/SPECS/nginx.spec

以下、nginx.spec に青字の部分を追加する。追加する3つのモジュールのうち、nginx-ct は元々 nginx に含まれていて動的モジュール化されている mod-mail と mod-stream に依存するため、これも動的モジュール化する(そうしないとビルドエラーになる)。

(58行目から)
BuildRequires: openssl-devel
BuildRequires: pcre-devel
BuildRequires: zlib-devel
BuildRequires: expat-devel
BuildRequires: git

Requires: nginx-filesystem = %{epoch}:%{version}-%{release}
%if 0%{?el7}

(78行目から)
Requires: openssl
Requires: pcre
Requires: expat
Requires(pre): nginx-filesystem
%if 0%{?with_mailcap_mimetypes}
Requires: nginx-mimetypes

(106行目から)
Requires: nginx-mod-http-xslt-filter = %{epoch}:%{version}-%{release}
Requires: nginx-mod-mail = %{epoch}:%{version}-%{release}
Requires: nginx-mod-stream = %{epoch}:%{version}-%{release}
Requires: nginx-mod-ct = %{epoch}:%{version}-%{release}

%description all-modules
Meta package that installs all available nginx modules.

(176行目から)
%description mod-stream
%{summary}.

%package mod-ct
Summary: Nginx ct modules
Requires: nginx

%description mod-ct
%{summary}.


%prep
%setup -q
git clone https://github.com/arut/nginx-dav-ext-module.git
git clone https://github.com/openresty/headers-more-nginx-module.git
git clone https://github.com/grahamedgecombe/nginx-ct.git
%patch0 -p0
%patch2 -p1
cp %{SOURCE200} %{SOURCE210} %{SOURCE10} %{SOURCE12} .

(246行目から)
--with-pcre-jit \
--with-stream=dynamic \
--with-stream_ssl_module \
--add-module=./nginx-dav-ext-module \
--add-module=./headers-more-nginx-module \
--add-dynamic-module=./nginx-ct \
%if 0%{?with_gperftools}
--with-google_perftools_module \
%endif

(343行目から)
> %{buildroot}%{_datadir}/nginx/modules/mod-mail.conf
echo 'load_module "%{_libdir}/nginx/modules/ngx_stream_module.so";' \
> %{buildroot}%{_datadir}/nginx/modules/mod-stream.conf
echo 'load_module "%{_libdir}/nginx/modules/ngx_ssl_ct_module.so";' \
> %{buildroot}%{_datadir}/nginx/modules/mod-ct.conf
echo 'load_module "%{_libdir}/nginx/modules/ngx_http_ssl_ct_module.so";' \
> %{buildroot}%{_datadir}/nginx/modules/mod-http-ct.conf
echo 'load_module "%{_libdir}/nginx/modules/ngx_mail_ssl_ct_module.so";' \
> %{buildroot}%{_datadir}/nginx/modules/mod-mail_ct.conf
echo 'load_module "%{_libdir}/nginx/modules/ngx_stream_ssl_ct_module.so";' \
> %{buildroot}%{_datadir}/nginx/modules/mod-stream_ct.conf

%pre filesystem
getent group %{nginx_user} > /dev/null || groupadd -r %{nginx_user}

(386行目から)
/usr/bin/systemctl reload nginx.service >/dev/null 2>&1 || :
fi

%post mod-ct
if [ $1 -eq 1 ]; then
/usr/bin/systemctl reload nginx.service >/dev/null 2>&1 || :
fi

%preun
%systemd_preun nginx.service

(475行目から)
%{_datadir}/nginx/modules/mod-stream.conf
%{_libdir}/nginx/modules/ngx_stream_module.so

%files mod-ct
%{_datadir}/nginx/modules/mod-ct.conf
%{_datadir}/nginx/modules/mod-http-ct.conf
%{_datadir}/nginx/modules/mod-mail_ct.conf
%{_datadir}/nginx/modules/mod-stream_ct.conf
%{_libdir}/nginx/modules/ngx_http_ssl_ct_module.so
%{_libdir}/nginx/modules/ngx_mail_ssl_ct_module.so
%{_libdir}/nginx/modules/ngx_ssl_ct_module.so
%{_libdir}/nginx/modules/ngx_stream_ssl_ct_module.so


%changelog
* Sun Sep 15 2019 Warren Togami <warren@blockstream.com>
(以下略)

5. ビルド、インストール

ビルドを実行する。
$ rpmbuild --with geoip -ba rpmbuild/SPECS/nginx.spec

RPM が出来上がったらインストールする。すでに EPEL や nginx 公式 RPM をインストールしてしまっている場合は、先に削除しておくこと。

既存パッケージの削除:
$ sudo yum erase `rpm -qa | grep nginx`

カスタマイズした RPM のインストール:
$ sudo yum localinstall rpmbuild/RPMS/x86_64/nginx-1.*.rpm rpmbuild/RPMS/x86_64/nginx-mod-*.rpm rpmbuild/RPMS/noarch/nginx-*.rpm

6. 起動

デーモンを起動する。
$ sudo systemctl enable nginx
$ sudo systemctl start nginx

Exchange Server が正常終了しなかった場合のデータベース復旧

Exchange Server の入ったサーバが、OSごと固まったり、ハードウェアトラブルで停止した場合の復旧方法を考えてみる。

ひとまずOSを立ち上げなおすことが出来たとして、Exchange Server を起動しようとするとデータベースが dirty shutdown 状態となっており、マウントできない場合がある。

こういう場合にマイクロソフトの提供している手順ドキュメントがあるのだが…
修復済みの Exchange データベースのサポート ポリシーの変更

上記ドキュメントの手順3を進める前にデータベースをマウントする必要がある。しかし手順1、2でデータベースを掃除したにもかかわらず、それでもマウントできないということもある。

実行例:

[PS] C:\Windows\system32> Mount-Database -Identity MailboxDB01 -force
データベース "MailboxDB01" をマウントできませんでした。エラー: Active Manager
 の操作に失敗しました。エラー: データベース操作が失敗しました。エラー:
 操作が失敗し、メッセージが生成されました:
 MapiExceptionDatabaseError: Unable to mount database. (hr=0x80004005, ec=1108)
Diagnostic context:
...

そういう場合はトランザクションログが壊れている可能性が高いので、ログファイルを削除(退避)するとよい。

トランザクションログファイルの状態を示すコマンドとして、eseutil /ml コマンドがある。

[PS] C:\Windows\system32> eseutil /ml D:\Exchange\MailboxDB01\E00

これで壊れているログファイルがどれなのかわかるが、ともかくデータベースと同一ディレクトリにある拡張子.logのファイル(拡張子を隠す設定になっていたら表示すること!)をすべて別フォルダに退避してからマウントコマンドを実行するとよい。

[PS] C:\Windows\system32> D:
[PS] D:\> cd \Exchange\MailboxDB01
[PS] D:\Exchange\MailboxDB01> mkdir backup
[PS] D:\Exchange\MailboxDB01> move *.log backup
[PS] D:\Exchange\MailboxDB01> Mount-Database -Identity MailboxDB01 -force

openswan vs strongswan vs libreswan

IPsec の実装として、openswan / strongswan / libreswan どれを使えばいいの?というお話。

どの実装もかつてのFreeS/WAN IPsecの末裔であって、似たような設定で動作するのだけど微妙に書式が違う、というやっかいなことになっている。

openswan:
もうメンテされていない古い実装。Ubuntu 18.04 LTS も CentOS 7 もパッケージを用意していないので、あえて使う理由がない。Debian 9.x (stretch) には残っているが…
libreswan:
openswanのフォークで、現状メンテされている。RedHat/CentOS 系や Fedora、Ubuntu にも標準パッケージで用意されている。Debian 9.x (stretch) にはパッケージなし。
strongswan:
FreeS/WAN から分岐した別実装。Debian/Ubuntu 系 OS、また Fedora では標準パッケージで用意されている。RedHat/CentOS 系の場合は epel リポジトリに入っている。

ということで openswan は使わないものとして、ざっくり RedHat 系は libreswan、Debian 系は strongswan を使えば良いのではと考える。

※RedHat Enterprise Linux の場合は libreswan を推奨しているようなので、これを使うべきと思われる。
RedHat セキュリティーガイド 4.6. Libreswan を使用した仮想プライベートネットワーク (VPN) のセキュリティー保護

重要: Libreswan および Linux カーネルが実装する IKE/IPsec VPN は、Red Hat Enterprise Linux 7 で使用することが推奨される唯一の VPN テクノロジーです。その他の VPN テクノロジーを使用するリスクを理解せずに使用しないでください。

参考:
IPsec for Linux – strongSwan vs Openswan vs Libreswan vs other(?)

DNSSEC ルートゾーン KSK ロールオーバーについて

DNSSECのルートゾーンKSKロールオーバーについて、ロールオーバー前後でDNSの検索に支障が出ないよう、各所から通達が出ている。

ルートゾーンKSKロールオーバーによる影響とその確認方法について (JPRS)
KSKロールオーバーについて (JPNIC)

(2017/10月予定だった切り替えが延期され、現在は 2018/10/11 に予定されています)

1. 管理下の DNS キャッシュは DNSSEC 検証をしているか

DNS キャッシュサーバーを管理している場合は、一応気を付けたほうが良い。管理下の DNS キャッシュサーバーに対して、dig コマンドでDNSSEC 対応済みドメイン (例: jprs.jp) の情報を検索したときに、回答に ad フラグが付いていたら「キャッシュサーバーでDNSSEC署名検証が有効になっている」状態なので、更新後の鍵を設定してやる必要があるかもしれない。

adフラグが付いている例:

$ dig jprs.jp. @mydns.example.com

; <<>> DiG 9.10.3-P4-Ubuntu <<>> jprs.jp.
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26772
;; flags: qr rd ra ad; QUERY: 1, ANSWER: 1, AUTHORITY: 4, ADDITIONAL: 9
...

(参考: DNSSECチュートリアル~実践編~)

2. RHEL 7 / CentOS 7 + BIND の場合

named.confにデフォルトで以下の設定が入っていて、DNSSEC署名検証が有効になっている。

options {
...
        dnssec-enable yes;
        dnssec-validation yes;

        /* Path to ISC DLV key */
        bindkeys-file "/etc/named.iscdlv.key";

        managed-keys-directory "/var/named/dynamic";
...
};
...
include "/etc/named.root.key";

対処法1. パッケージアップデート

/etc/named.iscdlv.key と /etc/named.root.key に、ルートゾーンの鍵が入っている。パッケージバージョンがbind-9.9.4-38.4以降であれば、上記2ファイルに新しい鍵が追加されるので、bindのパッケージをアップデートしてしまうのが一番手っ取り早く安心できる方法ではある。

対処法2. 自動更新に任せる

9.9.4-38.3以前のパッケージを使っている場合でも、RFC5011 の自動更新に対応している。named を起動すると更新後の鍵は /var/named/dynamic/managed-keys.bind{,.jnl} として自動保存される。このため、特に何かをする必要はない。

# とはいえ、CVE-2017-3142、CVE-2017-3143への対処が9.9.4-38.5以降で行われているので、パッケージを更新した方が良い。

3. RHEL 7 / CentOS 7 + Unbound の場合

デフォルトの /var/lib/unbound/root.key には古い鍵しか入っていないが、/etc/unbound/unbound.conf に以下の記述があり、自動更新が有効になっている。

server:
...
        auto-trust-anchor-file: "/var/lib/unbound/root.key"
...

unbound のデーモンを起動すると、/var/lib/unbound/root.key に新しい鍵が追加される。

このため、これらの設定を変更していなければ、特に対処の必要はない。

4. 確認、その他

EDNS0を無効化していないこと、経路上でTCP53が通ること、フラグメントパケットが通ることも確認しておく。

大きなサイズの DNS 応答に対応できているかどうかは、DNS-OARCが確認用のレコードを用意してくれているので、以下の dig コマンドで確認できる。

$ dig +bufsize=4096 +short rs.dns-oarc.net txt

非対応のキャッシュサーバだと、以下のような回答が返ってくる。

rst.x476.rs.dns-oarc.net.
rst.x485.x476.rs.dns-oarc.net.
rst.x490.x485.x476.rs.dns-oarc.net.
"203.0.113.1 DNS reply size limit is at least 490"
"203.0.113.1 lacks EDNS, defaults to 512"
"Tested at 2017-08-31 01:19:47 UTC"

可用性セットを考慮したAzure仮想マシンのリストア

Azure ポータルからの操作では可用性セットの中に仮想マシンをリストアできないので、PowerShellで実行する。

まず、Azure PowerShellの環境を整えておく(参考)。

さらに、リソースグループ/仮想マシン/Recovery Services vault/ストレージアカウントの名前を事前にAzureポータルで調べておく。この例では、以下のようなリソース名になっている。

  • リソースグループ:Test01_RG
  • 仮想ネットワーク名:Test01_VNET
  • Recovery Services vault:Test01-Backup
  • 元の仮想マシン名:web1
  • 復元先仮想マシン名:restoretest1
  • ストレージアカウント名:test01st
  • リージョン:東日本

1. コンテキストをRecovery Services vaultに設定する

Get-AzureRmRecoveryServicesVault -Name "Test01-Backup" | Set-AzureRmRecoveryServicesVaultContext

2. 仮想マシンを選択

FriendlyNameオプションの引数に、復元したい仮想マシンの名前を入れる。

$namedContainer = Get-AzureRmRecoveryServicesBackupContainer -ContainerType "AzureVM" -Status "Registered" -FriendlyName "web1"
$backupItem = Get-AzureRmRecoveryServicesBackupItem -Container $namedContainer -WorkloadType "AzureVM"

3. 対象とする復元ポイントを探す

最近1週間のバックアップオブジェクトを配列rpに入れる。

$startDate = (Get-Date).AddDays(-7)
$endDate = Get-Date
$rp = Get-AzureRmRecoveryServicesBackupRecoveryPoint -Item $backupItem -StartDate $startDate.ToUniversalTime() -EndDate $endDate.ToUniversalTime()
$rp[0]

最終行、$rp[0]の実行で、一番最近の復元ポイントが表示される。これ以外を選びたい場合は$rp[1]などを順次表示して、日付と時刻(UTC)で判断して選ぶ。

4. 復元ポイントを選択して、ディスクを復元する

$rp[0]の復元ポイントの仮想ディスクを戻す。

$restorejob = Restore-AzureRmRecoveryServicesBackupItem -RecoveryPoint $rp[0] -StorageAccountName "test01st" -StorageAccountResourceGroupName "Test01_RG"
Wait-AzureRmRecoveryServicesBackupJob -Job $restorejob -Timeout 43200

1行目で復元ジョブを実行できるが、ジョブ完了前にプロンプトに戻ってしまうので、2行目のWait-AzureRmRecoveryServicesBackupJobを実行して完了を待つ。

5. 復元ジョブの情報を元にJSONファイルを作成する

$destination_pathには、JSONファイルのフルパスを記述する。コマンドを実行するユーザで書き込めるフォルダを指定すること。

$restorejob = Get-AzureRmRecoveryServicesBackupJob -Job $restorejob
$details = Get-AzureRmRecoveryServicesBackupJobDetails -Job $restorejob
$properties = $details.properties
$storageAccountName = $properties["Target Storage Account Name"]
$containerName = $properties["Config Blob Container Name"]
$blobName = $properties["Config Blob Name"]
Set-AzureRmCurrentStorageAccount -Name $storageAccountName -ResourceGroupName "Test01_RG"
$destination_path = "C:\Users\test\Desktop\vmconfig.json"
Get-AzureStorageBlobContent -Container $containerName -Blob $blobName -Destination $destination_path

6. 復元する仮想マシンの設定をJSONファイルから読み込む

VMNameオプションで復元先仮想マシンの名前を指定する。元の仮想マシンと同じにすることはできない。

$obj = ((Get-Content -Path $destination_path -Raw -Encoding Unicode)).TrimEnd([char]0x00) | ConvertFrom-Json
$availabilitySet = Get-AzureRmAvailabilitySet -ResourceGroupName "Test01_RG" -Name "test_availability_set"
$vm = New-AzureRmVMConfig -VMSize $obj.'properties.hardwareProfile'.vmSize -VMName "restoretest1" -AvailabilitySetId $availabilitySet.Id

7. ディスクの設定を追加する

下記の例ではOSディスクがrt1-osdiskという名前に、データディスクがrt1-datadisk1, rt1-datadisk2,…という名前になる。

Set-AzureRmVMOSDisk -VM $vm -Name "rt1-osdisk" -VhdUri $obj.'properties.storageProfile'.osDisk.vhd.Uri -CreateOption "Attach"
$vm.storageProfile.OsDisk.OsType = $obj.'properties.storageProfile'.OsDisk.OsType
foreach($dd in $obj.'properties.storageProfile'.DataDisks)
{
  $dataDiskName = "rt1-datadisk" + $dd.lun
  $vm = Add-AzureRmVMDataDisk -VM $vm -Name $dataDiskName -VhdUri $dd.vhd.Uri -Lun $dd.lun -CreateOption "Attach"
}

8. NICの設定を追加する

$nicName = "rt1-nic"
$pip = New-AzureRmPublicIpAddress -Name $nicName -ResourceGroupName "Test01_RG" -Location "japaneast" -AllocationMethod Dynamic
$vnet = Get-AzureRmVirtualNetwork -Name "Test01_VNET" -ResourceGroupName "Test01_RG"
$nic = New-AzureRmNetworkInterface -Name $nicName -ResourceGroupName "Test01_RG" -Location "japaneast" -SubnetId $vnet.Subnets[0].Id -PublicIpAddressId $pip.Id
$vm = Add-AzureRmVMNetworkInterface -VM $vm -Id $nic.Id

9. 仮想マシン復元を実行する

New-AzureRmVM -ResourceGroupName "Test01_RG" -Location "japaneast" -VM $vm

10. 後処理

あとはポータルで実施する。
・復元した仮想マシンのNICに、ネットワークセキュリティグループを追加
・復元した仮想マシンのNICに、元々のパブリックIPアドレスを付け替える
・復元した仮想マシンを、ロードバランサーのバックエンドプールに追加する

参考URL:
Azureでスナップショットの取得について(Azure Backup サービス)
AzureRM.RecoveryServices.Backup コマンドレットを使って仮想マシンをバックアップする
AzureBackupから可用性セットへリストアするPowerShellスクリプト

Azure PowerShellの準備

環境:Windows10 Pro 1703 64bitで確認。

まずローカルWindowsで管理者権限のPowerShellウインドウを開き、AzureRMモジュールをインストールする。

PS C:\WINDOWS\system32> Install-Module AzureRM

信頼されていないリポジトリ
信頼されていないリポジトリからモジュールをインストールしようとしています。このリポジトリを
信頼する場合は、Set-PSRepository コマンドレットを実行して、リポジトリの InstallationPolicy 
の値を変更してください。'PSGallery' からモジュールをインストールしますか?
[Y] はい(Y)  [A] すべて続行(A)  [N] いいえ(N)  [L] すべて無視(L)  [S] 中断(S)  [?] ヘルプ (既定値は "N"): y
(Enterを押す)

あとは自動的にモジュールがインストールされる。

次に管理者権限PowerShellを閉じ、一般権限のPowerShellを開く。

Microsoftアカウントでログインする。

PS C:\Users\username> Login-AzureRmAccount

ポップアップウインドウが表示されるので、そこにユーザ名とパスワードを入力する。

これで準備完了なので、以下やりたいことを実行する。

参考URL:
Azure PowerShell のインストールおよび構成
Azure PowerShell と Resource Manager でリソースを管理する

HTTP/2 (ALPN) 対応の nginx を SRPM からビルド

※以下はCentOS 7.3までの古い内容です。CentOS 7.4 では OpenSSL 1.0.2 が標準となったため、以下の作業は不要です。

CentOS7.3 に含まれる標準パッケージの OpenSSL が 1.0.1 系なので、それをリンクしてビルドした nginx 公式のバイナリでは HTTP/2 (ALPN) が利用できない。そこで、openssl-1.0.2 系のソースツリーを使って nginx 公式の SRPM をリビルドすることとする。

ついでに、geoipモジュールとdav_extモジュールも使いたいので、追加した上でビルドする。

1. コンパイルに必要なパッケージをインストール

$ sudo yum install expat-devel pcre-devel zlib-devel GeoIP-devel

2. nginxの公式レポジトリを追加

レポジトリファイルを作成する。
$ sudo vi /etc/yum.repos.d/nginx.repo

[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=0
enabled=1

[nginx-source]
name=nginx repo - Source
baseurl=http://nginx.org/packages/centos/$releasever/SRPMS/
gpgcheck=0
enabled=1

3. ダウンロード

SRPMをダウンロード・インストールする。
$ sudo yum install -y yum-utils
$ yumdownloader --source nginx
$ rpm -ivh --nosignature nginx-1.12.1-1.el7.ngx.src.rpm

今後yum updateで勝手にアップデートされないように、nginxレポジトリを無効化しておく。
$ sudo yum-config-manager --disable nginx
$ sudo yum-config-manager --disable nginx-source

OpenSSL 1.0.2 のソースをダウンロードして展開する。
$ cd /tmp
$ wget https://www.openssl.org/source/openssl-1.0.2l.tar.gz
$ tar xzf openssl-1.0.2l.tar.gz
$ cd ~

OpenSSL のビルドはしなくてよい。

4. カスタマイズ

SRPM の spec ファイルを編集する。
$ vi rpmbuild/SPECS/nginx.spec

青字の部分は追加、赤字で打消し線のところは削除する。

#
%define nginx_home %{_localstatedir}/cache/nginx
%define nginx_user nginx
%define nginx_group nginx
%define nginx_loggroup adm

# distribution specific definitions
%define use_systemd (0%{?fedora} && 0%{?fedora} >= 18) || (0%{?rhel} && 0%{?rhel
} >= 7) || (0%{?suse_version} == 1315)

%if 0%{?rhel} == 5
%define _group System Environment/Daemons
Requires(pre): shadow-utils
Requires: initscripts >= 8.36
Requires(post): chkconfig
Requires: openssl
BuildRequires: openssl-devel
%endif

%if 0%{?rhel} == 6
%define _group System Environment/Daemons
Requires(pre): shadow-utils
Requires: initscripts >= 8.36
Requires(post): chkconfig
Requires: openssl >= 1.0.1
BuildRequires: openssl-devel >= 1.0.1
%endif

%if 0%{?rhel} == 7
%define _group System Environment/Daemons
%define epoch 1
Epoch: %{epoch}
Requires(pre): shadow-utils
Requires: systemd
Requires: openssl >= 1.0.1
BuildRequires: systemd
BuildRequires: openssl-devel >= 1.0.1
BuildRequires: GeoIP-devel
BuildRequires: expat-devel
%endif

%if 0%{?suse_version} == 1315
%define _group Productivity/Networking/Web/Servers
%define nginx_loggroup trusted
Requires(pre): shadow
Requires: systemd
BuildRequires: libopenssl-devel
BuildRequires: systemd
%endif

# end of distribution specific definitions

%define main_version 1.12.1
%define main_release 1%{?dist}.ngx

%define bdir %{_builddir}/%{name}-%{main_version}

%define WITH_CC_OPT $(echo %{optflags} $(pcre-config --cflags)) -fPIC
%define WITH_LD_OPT -Wl,-z,relro -Wl,-z,now -pie
%define BASE_CONFIGURE_ARGS $(echo "--prefix=%{_sysconfdir}/nginx --sbin-path=%{
_sbindir}/nginx --modules-path=%{_libdir}/nginx/modules --conf-path=%{_sysconfdi
r}/nginx/nginx.conf --error-log-path=%{_localstatedir}/log/nginx/error.log --htt
p-log-path=%{_localstatedir}/log/nginx/access.log --pid-path=%{_localstatedir}/r
un/nginx.pid --lock-path=%{_localstatedir}/run/nginx.lock --http-client-body-tem
p-path=%{_localstatedir}/cache/nginx/client_temp --http-proxy-temp-path=%{_local
statedir}/cache/nginx/proxy_temp --http-fastcgi-temp-path=%{_localstatedir}/cach
e/nginx/fastcgi_temp --http-uwsgi-temp-path=%{_localstatedir}/cache/nginx/uwsgi_
temp --http-scgi-temp-path=%{_localstatedir}/cache/nginx/scgi_temp --user=%{ngin
x_user} --group=%{nginx_group} --with-compat --with-file-aio --with-threads --wi
th-http_addition_module --with-http_auth_request_module --with-http_dav_module -
-with-http_flv_module --with-http_gunzip_module --with-http_gzip_static_module -
-with-http_mp4_module --with-http_random_index_module --with-http_realip_module 
--with-http_secure_link_module --with-http_slice_module --with-http_ssl_module -
-with-http_stub_status_module --with-http_sub_module --with-http_v2_module --wit
h-mail --with-mail_ssl_module --with-stream --with-stream_realip_module --with-s
tream_ssl_module --with-stream_ssl_preread_module --with-http_geoip_module --add
-module=./nginx-dav-ext-module --with-openssl=/tmp/openssl-1.0.2l")

Summary: High performance web server
Name: nginx
Version: %{main_version}
Release: %{main_release}
Vendor: Nginx, Inc.
URL: http://nginx.org/
Group: %{_group}

Source0: http://nginx.org/download/%{name}-%{version}.tar.gz
Source1: logrotate
Source2: nginx.init.in
Source3: nginx.sysconf
Source4: nginx.conf
Source5: nginx.vh.default.conf
Source7: nginx-debug.sysconf
Source8: nginx.service
Source9: nginx.upgrade.sh
Source10: nginx.suse.logrotate
Source11: nginx-debug.service
Source12: COPYRIGHT
Source13: nginx.check-reload.sh

License: 2-clause BSD-like license

BuildRoot: %{_tmppath}/%{name}-%{main_version}-%{main_release}-root
BuildRequires: zlib-devel
BuildRequires: pcre-devel

Provides: webserver

%description
nginx [engine x] is an HTTP and reverse proxy server, as well as
a mail proxy server.

%if 0%{?suse_version} == 1315
%debug_package
%endif

%prep
%setup -q
cp %{SOURCE2} .
sed -e 's|%%DEFAULTSTART%%|2 3 4 5|g' -e 's|%%DEFAULTSTOP%%|0 1 6|g' \
    -e 's|%%PROVIDES%%|nginx|g' < %{SOURCE2} > nginx.init
sed -e 's|%%DEFAULTSTART%%||g' -e 's|%%DEFAULTSTOP%%|0 1 2 3 4 5 6|g' \
    -e 's|%%PROVIDES%%|nginx-debug|g' < %{SOURCE2} > nginx-debug.init
git clone https://github.com/arut/nginx-dav-ext-module.git

%build
./configure %{BASE_CONFIGURE_ARGS} \
    --with-cc-opt="%{WITH_CC_OPT}" \
    --with-ld-opt="%{WITH_LD_OPT}" \
    --with-debug --with-openssl-opt="-fPIC"
make %{?_smp_mflags}
%{__mv} %{bdir}/objs/nginx \
    %{bdir}/objs/nginx-debug
./configure %{BASE_CONFIGURE_ARGS} \
    --with-cc-opt="%{WITH_CC_OPT}" \
    --with-ld-opt="%{WITH_LD_OPT}" --with-openssl-opt="-fPIC"
make %{?_smp_mflags}

(以下略)

5. ビルド、インストール

ビルドを実行する。
$ rpmbuild -ba rpmbuild/SPECS/nginx.spec

出来上がったら、RPMをインストールする。
$ sudo yum localinstall rpmbuild/RPMS/x86_64/nginx-1.12.1-1.el7.centos.ngx.x86_64.rpm

展開した openssl ソースを掃除しておく。
$ rm -r /tmp/openssl-1.0.2l

6. 起動

デーモンを起動する。
$ sudo systemctl enable nginx
$ sudo systemctl start nginx

参考URL:
HTTP/2対応nginxのrpmパッケージ作成とインストール

CentOS7でmastodon自分インスタンスを立てる

VPS上に自分用のインスタンスを立ててみた。

1. dockerインストール

dockerをパッケージでインストールする。レポジトリとしては、dockerの公式を使う。
$ sudo yum install yum-utils
$ sudo yum-config-manager --add-repo https://download.docker.com/linux/centos/docker-ce.repo
$ sudo yum-config-manager --disable docker-ce-edge
$ sudo yum-config-manager --disable docker-ce-stable

docker-ce-edgeレポジトリで最新のバージョン名を取得してインストールする。
$ yum --enablerepo=docker-ce-edge list docker-ce.x86_64 --showduplicates | sort -r
docker-ce.x86_64 17.05.0.ce-1.el7.centos docker-ce-edge
docker-ce.x86_64 17.04.0.ce-1.el7.centos docker-ce-edge
$ sudo yum --enablerepo=docker-ce-edge install docker-ce-17.05.0.ce-1.el7.centos

dockerデーモンを起動する。
$ sudo systemctl enable docker
$ sudo systemctl start docker

docker-composeをgithubからダウンロードして/usr/bin以下に配置する。
$ sudo -i
# curl -L https://github.com/docker/compose/releases/download/1.12.0/docker-compose-`uname -s`-`uname -m` > /usr/bin/docker-compose
# chmod +x /usr/bin/docker-compose
$ exit

2. mastodon

mastodonのソースツリーを用意する。

最初に、mastodon用の作業用一般ユーザを追加する。
$ sudo useradd mastodon
$ sudo passwd mastodon
$ sudo usermod -aG docker mastodon

mastodonのソースツリーを/home/mastodon/liveに展開する。これ以降はmastodonユーザで作業する。
$ sudo -i -u mastodon
$ git clone https://github.com/tootsuite/mastodon.git live
$ cd live
$ git tag
バージョンタグの一覧が表示されるので、最新のリリースタグを選ぶ。
$ git checkout v1.3.3

ソースツリーに付属している、dockerコンテナの設定ファイル docker-compose.yml を編集する。
$ vi docker-compose.yml

version: '2'
services:

  db:
    restart: always
    image: postgres:alpine
### Uncomment to enable DB persistance
    volumes: ←ここの行頭コメント記号を外す
      - ./postgres:/var/lib/postgresql/data ←ここの行頭コメント記号を外す

  redis:
    restart: always
    image: redis:alpine
### Uncomment to enable REDIS persistance
    volumes: ←ここの行頭コメント記号を外す
      - ./redis:/data ←ここの行頭コメント記号を外す

  web:
    restart: always
    build: .
    image: gargron/mastodon
    env_file: .env.production
    command: bundle exec rails s -p 3000 -b '0.0.0.0'
    ports:
      - "3000:3000"
    links: ←depends_onをlinksに変更する
      - db
      - redis
    volumes:
      - ./public/assets:/mastodon/public/assets
      - ./public/system:/mastodon/public/system

  streaming:
    restart: always
    build: .
    image: gargron/mastodon
    env_file: .env.production
    command: npm run start
    ports:
      - "4000:4000"
    links: ←depends_onをlinksに変更する
      - db
      - redis

  sidekiq:
    restart: always
    build: .
    image: gargron/mastodon
    env_file: .env.production
    command: bundle exec sidekiq -q default -q mailers -q pull -q push
    links: ←depends_onをlinksに変更する
      - db
      - redis
    volumes:
      - ./public/system:/mastodon/public/system

次に、.env.productionを編集する。
$ cp -p .env.production.sample .env.production
$ vi .env.production

以下のような行を編集する。

DB_USER=mastodon ←この後PostgreSQLで設定する
DB_NAME=mastodon ←同上
DB_PASS=password ←同上
LOCAL_DOMAIN=mastodon.example.com ←mastodonサーバのFQDN
SMTP_SERVER=mail.example.com ←メールサーバのホスト名
SMTP_PORT=587 ←メールサーバのポート SMTP AUTHが使えるポートを指定
SMTP_LOGIN=mastodon ←SMTP AUTHのユーザ名
SMTP_PASSWORD=password ←SMTP AUTHのパスワード
SMTP_FROM_ADDRESS=postmaster@example.com

dockerコンテナをダウンロードし、ビルドする。ここは時間がかかる。
$ docker-compose build

次に、同じコマンドを3回実行してキーを作成する。
$ docker-compose run --rm web rake secret
3d3748d778c215f269c18c4c46dc2fb94da50ec569b2bc0c593353b5f54f2f4b6e4307978bc0304042f8d086716f1896046751d4b0fc8b9420a79c33454caa81
$ docker-compose run --rm web rake secret
5377ae140e0c1eaf857b5423067c4295029c9cdb23feefa9f382c7aa94753f224ed097834f15447c419d31065ce0dc816ef6efeec594de8996b776910b2e3326
$ docker-compose run --rm web rake secret
772fab57e3e71fa6c57f14e8ab42e986daf0aaf67a1ebe469d04fc3187f989ec77bd8bebdc08b62c4a456e8851755140000286c8babc1b8e4c9203782aadd6f2

出力された鍵文字列を、.env.production設定ファイルに記述する。
$ vi .env.production

PAPERCLIP_SECRET=3d3748d778c215f269c18c4c46dc2fb94da50ec569b2bc0c593353b5f54f2f4b6e4307978bc0304042f8d086716f1896046751d4b0fc8b9420a79c33454caa81
SECRET_KEY_BASE=5377ae140e0c1eaf857b5423067c4295029c9cdb23feefa9f382c7aa94753f224ed097834f15447c419d31065ce0dc816ef6efeec594de8996b776910b2e3326
OTP_SECRET=772fab57e3e71fa6c57f14e8ab42e986daf0aaf67a1ebe469d04fc3187f989ec77bd8bebdc08b62c4a456e8851755140000286c8babc1b8e4c9203782aadd6f2

コンテナを起動する。
$ docker-compose up -d

dbコンテナ内のPostgreSQLに、ユーザとデータベースを作成する。
$ docker exec -it live_db_1 bash
# su - postgres
43e296a2871c:~$ createuser -P mastodon
Enter password for new role: password
Enter it again: password
43e296a2871c:~$ createdb mastodon -O mastodon
43e296a2871c:~$ exit
# exit

dbコンテナの変更部分をアップデートする。また、assetsファイル(静的コンテンツ)を生成する。
$ docker-compose run --rm web rails db:migrate
$ docker-compose run --rm web rails assets:precompile

いったんコンテナを再起動する。
$ docker-compose stop
$ docker-compose up -d

3. certbot (letsencrypt)

Let’s EncryptプロジェクトCAに、証明書を発行してもらう。

certbotソースツリーを、/opt以下に展開してcertbot-autoを実行する。
$ sudo -i
# cd /opt
# chgrp wheel .
# chmod g+w .
# exit
$ cd /opt
$ git clone https://github.com/certbot/certbot
$ cd certbot
$ ./certbot-auto certonly -n --standalone --agree-tos -m 管理者メールアドレス -d www.example.com,mail.example.com,mastodon.example.com

今回は直接関係ないが、-dオプションで SubjectAltNameを指定することで、他のバーチャルホストと証明書を共用する。

4. nginx のインストールと設定

nginxはpuma+railsのリバースプロキシ兼、静的コンテンツを自前で返すWebサーバとなる。

nginx のインストール用 repo を追加する。
$ sudo vi /etc/yum.repos.d/nginx.repo

[nginx]
name=nginx repo
baseurl=http://nginx.org/packages/centos/$releasever/$basearch/
gpgcheck=0
enabled=0

nginxをインストールする。
$ sudo yum --enablerepo=nginx install nginx

nginxの設定
$ sudo vi /etc/nginx/conf.d/mastodon.conf

map $http_upgrade $connection_upgrade {
  default upgrade;
  ''      close;
}

server {
  listen 80;
  listen [::]:80;
  server_name mastodon.example.com;
  location / { return 301 https://$host$request_uri; }
}

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

  ssl_protocols TLSv1.2;
  ssl_ciphers EECDH+AESGCM:EECDH+AES;
  ssl_ecdh_curve prime256v1;
  ssl_prefer_server_ciphers on;
  ssl_session_cache shared:SSL:10m;

  ssl_certificate     /etc/letsencrypt/live/example.com/fullchain.pem;
  ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
  ssl_dhparam         /etc/pki/tls/dhparam.pem;

  keepalive_timeout    70;
  sendfile             on;
  client_max_body_size 0;

  root /home/mastodon/live/public;

  gzip on;
  gzip_disable "msie6";
  gzip_vary on;
  gzip_proxied any;
  gzip_comp_level 6;
  gzip_buffers 16 8k;
  gzip_http_version 1.1;
  gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

  add_header Strict-Transport-Security "max-age=31536000";

  location / {
    try_files $uri @proxy;
  }

  location /assets {
    add_header Cache-Control "public, max-age=31536000, immutable";
  }

  location @proxy {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Proxy "";
    proxy_pass_header Server;

    proxy_pass http://127.0.0.1:3000;
    proxy_buffering off;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    tcp_nodelay on;
  }

  location /api/v1/streaming {
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto https;
    proxy_set_header Proxy "";

    proxy_pass http://localhost:4000;
    proxy_buffering off;
    proxy_redirect off;
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $connection_upgrade;

    tcp_nodelay on;
  }

  error_page 500 501 502 503 504 /500.html;
}

nginxを起動する。
$ sudo openssl dhparam 2048 -out /etc/pki/tls/dhparam.pem
$ sudo systemctl enable nginx
$ sudo systemctl restart nginx

5. 起動後の設定

mastodonの画面にWebブラウザでアクセスし、最初のユーザを作成する。

mastodon上の最初のユーザを作成してから、以下のコマンドで管理者ユーザ化する
$ docker-compose run --rm web rails mastodon:make_admin USERNAME=firstusername

さらにシングルユーザーモード化して、ほかのユーザではアクセスできなくする
$ vi .env.production
SINGLE_USER_MODE=true

設定を反映するため、再起動する。
$ docker-compose stop
$ docker-compose up -d

systemd起動スクリプトを作成して、VPSを再起動したときも自動でmastodon用コンテナが起動するようにする。
$ sudo vi /etc/systemd/system/mastodon.service

[Unit]
Description=Mastodon
Requires=docker.service
After=network.target
After=docker.service

[Service]
Type=simple
User=mastodon
Group=mastodon
WorkingDirectory=/home/mastodon/live
ExecStart=/usr/bin/docker-compose up
ExecStop=/usr/bin/docker-compose stop

[Install]
WantedBy=multi-user.target

systemctlを使ってmastodonコンテナを再起動してみる。
$ sudo systemctl enable mastodon
$ sudo systemctl stop mastodon
$ sudo systemctl start mastodon

以上で完了である。