この記事は、昨日投稿したぐすくまさん主催のアドベントカレンダーに投稿した記事の続きです。前編はこちら。後編は、S.H.さん主催の、Mastodon Advent Calendar 2018のための記事として投稿します。
マストドンに関するアドベントカレンダーとしては、他にも色々ありますので、興味ある人は見てみるといいと思います（ぐすくまさん主催のもののページに便利なリンクがあります）。
なお、本日、ぐすくまさん主催の方では、localyouserさんによって「ウチのインスタンスを支える技術からなんか一つ」というテーマの記事が投稿されているはずです。宜しければそちらもご覧ください。
前回までのあらすじ
鯖缶工場の皆様のご協力を得て、お名前.comのVPSを借り、 Ubuntuを導入。GitHubにもユーザー登録し、いよいよマストドン本体の設定に入っていきます。
4日目：Mastodonの設定
ついに、Mastodon本体の設定に移ります（わくわく
まず、DBを作成します。もちろん、cd ~/liveでフォルダを移動することをお忘れなく。
sudo docker-compose run --rm web bundle exec rake db:setup SAFETY_ASSURED=1
末尾のSAFETY_ASSURED=1を飛ばすと、セーフティーが働き、実行できません。
次は、JS、CSSの準備ですが、
sudo docker-compose run --rm web bundle exec rake assets:precompile
このコマンドを入れた所、「(See full trace by running task with --trace)」とか表示されてエラーになりました。Docker内のMastodon権限に書き換えてから再度やります。
sudo chown -R 991.991 ./public
sudo docker-compose run --rm web bundle exec rake assets:precompile
Compiling...ってなり、しばらく待つと、「Compiled all packs in /mastodon/public/packs」と表示されました。これで基本部分は完成です。
早速、マストドンの管理者垢を作ってしまいます。
2つ方法があります。
自分でコマンドを合わせてユーザを作成する場合：
User.new(admin: true, email: "メールアドレス", password: "パスワード", confirmed_at: Time.now.utc, account_attributes: { username: "ユーザー名" }).save(validate: false)をsudo docker-compose run --rm web bundle exec rails c上で実行タスクを利用してユーザを作成する場合：
sudo docker-compose run --rm web bundle exec rails mastodon:add_user
タスクを使う場合、ウィザードで設定を進めていきますが、その中で、「管理者にする？」って訊かれます。パスワードは自動で物凄く長いランダム英数字が初期パスワードとして与えられます。
ちなみに、タスクを使う方法で、一般ユーザーを管理者へ昇格させる際は、
sudo docker-compose run --rm web bundle exec rails mastodon:make_admin USERNAME=ユーザー名
権限剥奪は、
sudo docker-compose run --rm web bundle exec rails mastodon:revoke_staff USERNAME=ユーザー名
です。
admin、support、help、root、webmaster、administratorというユーザー名のアカウントを作りたい場合は、コマンドから作る必要があります。逆に言えば、これらのユーザー名を持っているアカウントは、管理者が作ったものです。
……adminという名前で管理者権限持ってないっていうシュールなアカウントとかも作れちゃいますけど。
nginxをインストールする
Web上で公開するために、nginxをインストールします。 Ubuntu版とNGINX Inc.版とがありますが、Ubuntu版の方が安定してるそうなので、Ubuntu版にします。
sudo apt install nginx
現在のサーバで実行する場合はcurl http://localhost/、手元のパソコンから確認する場合はhttp://サーバのIPアドレス/へアクセスすると、「nginxのへようこそ！」って出るはずです。これでngixが動いていることを確認できました。
certbotを入れる
続いてSSLの発行の準備もします。よく、SSLの期限切れで止まってるインスタンスがありますが、公式のドキュメント通りにやれば期限切れしないはずだそう。
certbotを入れます。
sudo apt-get update
sudo apt-get install software-properties-common
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install certbotsudo certbot --version
最後の行のやつで、バージョンが表示されたらOKです。
cartbotで証明書を発行するために、ドメイン名とサーバーIPの関連付けを行います。
お名前.comのレコード追加画面で、ホスト名は無記入、TYPEはA、VALUEはVPSのIPアドレスをそれぞれ入れていきます。TTLは3600のままです。最後の登録ボタンもお忘れなく。
画像サーバーは別ドメインなので、それも入れます。ホスト名はmedia、TYPEはCNAME、VALUEはamemiya.work。
CNAMEはValueのドメインが持つ情報を全て引き継ぐエイリアスだと思ってください。
で、「media.amemiya.workにアクセスする場合はamemiya.workにアクセスするのと同じ名前解決をしてね」という情報がDNSのレコードに書き込まれます。（by. ikuradonさん）
反応するまでしばらく待って、一度nginxを止め、cartbotで自動発行します。
sudo systemctl stop nginx
sudo certbot certonly --standalone -d amemiya.work -d media.amemiya.work
Enter email addressって出ますが、更新忘れがあった時に教えてくれるメールアドレスです。受信できるものを登録します。「ほかのEFFのお知らせ送ってもいい？」ってのが出ますが、これはNoでもかまいません。広告だそうです。
充分反応ができてないと、「重要なノート」で教えてくれます。もちっと待ちましょう。
nginxの設定
反映を待っている間、nginxの設定をします。
ここの、「nginx Configuration」に書いてある長文を入れます。本来は。
今回は、ikuradonさんが書き換えたファイルを用意してくださりました。
sudo ln -s /etc/nginx/sites-{available,enabled}/amemiya.work.conf
で、有効化させます。
SSL更新を自動化
では、nginxが稼働しててもSSL更新ができるようにします。
sudo nginx -t
で、nginxの構文に問題が無いか確認します。
sudo systemctl start nginx
で、nginxを起動します。
この段階でブラウザでアクセスすると、荒ぶる象さんが見れます。
これは
ユーザ<=>nginx<=>Mastodon
のnginx<=>Mastodonで通信が出来ていないのでちゃんとエラーページを表示してくれているのです。（by. ikuradonさん）
閑話休題。
sudo certbot certonly --webroot -d amemiya.work -d media.amemiya.work -w /home/miha/live/public/
選択肢が出たら、2の強制更新を選択します。これでインスタンスを止めることなくSSLの更新ができるようになったわけですが、更新後にnginxを順次再起動しないといけないので、その設定を書きます。
sudo vim /etc/cron.daily/letsencrypt-renew
cron.dailyは一日一回自動的にcronというソフトが中身を見て、片っ端から実行していくフォルダだそう。
エディタを開いたら、以下の文をINSERTモードにしてから貼り付けます。
これはどういう意味かというと、
1行目： これはbashスクリプトですよーというマーカー
2行目：certbot renewを起動して、更新が必要だったら自動更新
3行目：systemctl reload nginxを実行して、接続がなくなったnginxを順次再起動（by. ikuradonさん）
最後に、このスクリプトに実行権限を与え、CRONがちゃんとこのシェルスクリプトを読み込むように一度再起動します。
sudo chmod +x /etc/cron.daily/letsencrypt-renew
sudo systemctl restart cron
マストドンのアップデート
実は、この作業をやっていたのは、8月26日。つい前日にはマストドンのアップデートがきていました。早速アップデートします。アップデートが行われた際には、リリースノートにアップデートの方法が掲載されます。今回は、新しいバージョンが出る前にフォークしてたので、
git remote add upstream https://github.com/tootsuite/mastodon.git
git fetch --all
これを先にやります。……でないと、git fetchで新しいバージョンが出ません。これは初回だけです。
あとは、公式のドキュメントやさっきのリリースノート通りにやります。
やらかした
ここで、git statusしてdocker-compose.ymlだけ居ればOKなんですが、どうも様子がおかしい。docker-compose.ymlに書き込んだ設定も飛んでしまってます。
実は私、さっきのgitのコマンドをsudoでやっちゃったんですね。それで、色々壊れてしまったよう。
消えた文字列を書き直し、権限も自分に戻しておきます。
sudo chown -hR miha.miha ./
sudo chown 991.991 public
改めて、アップデートしていきます。
sudo docker-compose build
sudo docker-compose run --rm web rails db:migrate
sudo docker-compose run --rm web rails assets:precompile
で、マストドン起動です。
sudo docker-compose up -d
……がっ。起動しない(´・ω・｀)
sudo docker-compose logs web
これでログを追います。どうも、権限がおかしくなってる模様。
sudo chown -hR 70 postgres
sudo chown -R 100 redis
sudo chown 100.101 redis/dump.rdb
sudo chown -hR 0.0 minio/data/.minio.sys
これで権限を直します。
改めてマストドンを起動します。
sudo docker-compose stop
sudo docker-compose run --rm web rails db:migrate
sudo docker-compose run --rm web rails assets:precompile
sudo docker-compose up -d
これで、無事に起動できました。ちょっと涙出てきます。
メールサーバーの設定やり直し
しかし、この段になってもなお、アカウント登録を知らせるメールが来ません。どうも、そもそもDNSの認証が上手くいってないようです。お名前.comの設定から、
ホスト名: ars._domainkey.mail
TYPE: TXT
Value: Enter this valueのところに書かれているk=rsaから始まる文字列
を登録します。
他にも色々間違えていたので、直しました。……が、この辺りの設定は、大幅に書き換えることになります。
【宮原丼（仮） 進捗】
## 4日目
※DNS浸透待ちで設定を行ったり来たりしたので、少々順序を直しています。
- Mastodonアプリケーション設定
db:setup
assets:precompile- Mastodonユーザー作成
mastodon:adduser- DNSにAレコード設定
- nginxの導入・設定
パッケージインストール
sites-availableにconfファイル用意
sites-enableにシンボリックリンク作成
- Let's Enclyptの導入・設定
証明書取得
cron設定
- マストドン v2.4.5にアップデート
upstream設定
通常のアップデート操作- キャプチャ画面越しではログが追いづらくなってきたので、tmateの導入
mailgunのメール認証でコケているらしく、DNSレコードの再設定- ブラウザでインスタンス表示されていることを確認！
※誤ってgitをsudo操作してしまったときの戻し手順memo
sudo chown -hR [user].[group] ./
sudo chown 991.991 public
sudo chown -hR 70 postgres
sudo chown -R 100 redis
sudo chown 100.101 redis/dump.rdbあとはメールと画像サーバができれば一通り。という話でとりあえず終わってましたね。
画像サーバと言ってもminio入れてるからもう殆どすることもないと思いますが。あとは、セキュリティ面強化してもらえれば公開チャンネルの方でも宣伝できると思います！
セキュリティ周りについては、あしゅふぃさんの上げてくれたガイドラインを参照していただきたく。http://ashphy.hateblo.jp/entry/mastodon-securit-guidelines
DNS「浸透」はちゃんと理解して使おうね！
（by. ぐずくまさん）
5日目：セキュリティーとか
Mixed-Contentsの解消
前日、WebブラウザでアクセスできるようになったAmemiya.workのマストドンですが、試しに画像をアップしてみたところ、上手くサムネが表示されませんでした。
マストドン本体はhttpsなんですが、どうも画像のURLはhttpになっている模様。
.env.productionの中身を見ます。
sudo vim .env.production
で、S3_PROTOCOLをhttpsへ変えます。
S3_PROTOCOL=https
できたら、保存して再起動します。
sudo docker-compose up -d
これで、マストドンの準備としてはほぼ完了です。
マストドンセキュリティーガイドライン
これをやっていきます。
最初から情報隠されてました。日本では、もともと、企業以外は情報結構隠してるんだそうで、今回はそれが働いたみたいです。
HTTPSの設定確認には Qualys SSL LABS SSL Server Test が便利です。レーティングがA以上になれば問題ありません。
やってみた所、A+でした。
HTTPヘッダ
securityheaders.comではサーバが送信してくるヘッダの一覧を確認することができます。
ヘッダ情報、何も出てきませんでした。標準だと何も書いてないそう。
ただ、「コンテンツセキュリティーポリシー（CSP）」がバツになってました。
/etc/nginx/sites-available/amemiya.work.confの「add_header Strict-Transport-Security "max-age=31536000";」の下辺りに必要な設定を記載します。
add_headerは2カ所記載があって、amemiya.workの処理をしているブロックと、media.amemiya.workの処理をしているブロック二つに記載がありますが、amemiya.workの方に書きます。media.amemiya.workの方に書いてしまうと、エラーになります。これはJavascriptとかを埋め込まれても大丈夫なようにするやつなので、media.の方では不要です。
sudo vim /etc/nginx/sites-available/amemiya.work.conf
で、記載する内容は以下の通り。
add_header Strict-Transport-Security "max-age=31536000";
add_header Content-Security-Policy "style-src 'self' 'unsafe-inline'; script-src 'self'; object-src 'self' https://media.amemiya.work; img-src data: https: blob:; media-src data: https:; font-src 'self' data:; connect-src 'self' blob: wss:; upgrade-insecure-requests";
add_header X-Content-Security-Policy "style-src 'self' 'unsafe-inline'; script-src 'self'; object-src 'self' https://media.amemiya.work; img-src data: https: blob:; media-src data: https:; font-src 'self' data:; connect-src 'self' blob: wss:; upgrade-insecure-requests";
add_header X-WebKit-CSP "style-src 'self' 'unsafe-inline'; script-src 'self'; object-src 'self' https://media.amemiya.work; img-src data: https: blob:; media-src data: https:; font-src 'self' data:; connect-src 'self' blob: wss:; upgrade-insecure-requests";
これ、画像サーバやアセットサーバの実装方法によって記述方法がころころ変わるそう。
できたら、設定ファイルを確認して再起動します。
sudo nginx -t
sudo systemctl reload nginx
これで反映されました。
では次。
管理用にSSHを有効にすると思いますが、パスワード認証は絶対に使わないようにしましょう。絶対に破られます。 公開鍵認証を設定し、十分に長い鍵を利用しましょう。
これは最初のうちにやってしまいましたね。
ポートスキャン
これやっていきましょう。
sudo apt install nmap
sudo nmap -v -sS -oA nmap_outout --port-ratio=0.0 example.jp
開いてるポートとして、22、80、443が出ました。問題無さそうですね。
一般的にメールサーバを運用することはかなり難しく、また手間もかかります。 Mailgun や Amazon SES を利用するのがおすすめです。
もともと、既存のメールサーバー使うのが前提です。
ちなみに、Mailgunの場合、Microsoft系のメールとは相性が悪いみたい。インスタンスの説明文に「MS系メールには送信出来ない可能性があるので何かあっても無保証です」ぐらい書いといた方がいいかもしれません。
削除依頼があったらすぐ削除しないといけないとか、そういうやつ。ログ開示とか求められる可能性があるので、ログファイルの場所を確認しておきます。今は、標準状態なので/var/log/nginx/access.logですね。
tail -f /var/log/nginx/access.log
POSTって入ってるやつが送信を行ったユーザー。この送信はユーザーが投稿した場合にも表示されますし、サーバー間の投稿でも表示されます。
Ctrl+Cで終了できます。
DDoS
「田代砲」や「F5アタック」というと、2010年代以前からインターネットをやってる人には、お馴染みかもしれません。こういったものはDoS攻撃というもので、要は、特定のウェブサイト（タイム誌の投票ページとか2chとか）に対してあまりに多すぎるアクセスを行うことで、サーバーをアクセス不能な状態に追い込むという攻撃です。
DDoSはそれを発展（？）させたもので、要は数千人単位で一斉にやる田代砲みたいなモンです。
……まあ、ウチみたいな零細を狙うほど暇でもないとは思いますが、せっかくお金払って借りてるVPSを止められたり、ここまで苦労して作ったマストドンを吹き飛ばされると泣いちゃうので、CloudFlareで対策します。
CloudFlare
無料プランでサインアップします。
wwwサブドメインのA、AAAA、またはCNAMEレコードが見つかりませんでした。www.amemiya.workのサブドメインは解決されません。
ルートドメインでMXレコードが見つかりませんでした。メールが@ amemiya.workアドレスに到達するには、MXレコードが必要です。
という警告が。
前者は、そもそもWWWが付いてないので問題ないです。
なんか、一部の設定が上手く反映されなかったので、見比べながら手動で追記していきます。
コンティニューしたら、お名前.com側の設定です。「ネームサーバーの変更」を開き、01.dnsv.jpをcoby.ns.cloudflare.comへ。そして、02.dnsv.jpをlorna.ns.cloudflare.comへ、それぞれ変更します。
再びCloudFlareへ戻り、「Crypto」をクリック。
SSLはFull
Edge Certificatesはそのまま
Always use HTTPSはOff（これ重要）
HSTSはOn/期間は6Month/サブドメインもOn/PreloadもOn/No-sniffもOn
Authenticated Origin PullsはOff
Minimum TLS VersionはTLS 1.0以上（TLS 1.2がおすすめ)
Opprtunistic EncryptionはOn
TLS 1.3はEnabled
Automatic HTTPS RewritesはOn
と、設定します。
続いて、「Scrape Shield」をクリック。こちらはすべてOff。これでひとまず、DNS設定は終了。
nginxの設定をします。
sudo vim /etc/nginx/conf.d/CloudFlare.conf
これで出てきたものに、以下のものを入れます。
set_real_ip_from 103.21.244.0/22;
set_real_ip_from 103.22.200.0/22;
set_real_ip_from 103.31.4.0/22;
set_real_ip_from 104.16.0.0/12;
set_real_ip_from 108.162.192.0/18;
set_real_ip_from 131.0.72.0/22;
set_real_ip_from 141.101.64.0/18;
set_real_ip_from 162.158.0.0/15;
set_real_ip_from 172.64.0.0/13;
set_real_ip_from 173.245.48.0/20;
set_real_ip_from 188.114.96.0/20;
set_real_ip_from 190.93.240.0/20;
set_real_ip_from 197.234.240.0/22;
set_real_ip_from 198.41.128.0/17;
set_real_ip_from 2400:cb00::/32;
set_real_ip_from 2606:4700::/32;
set_real_ip_from 2803:f800::/32;
set_real_ip_from 2405:b500::/32;
set_real_ip_from 2405:8100::/32;
set_real_ip_from 2c0f:f248::/32;
set_real_ip_from 2a06:98c0::/29;# use any of the following two
real_ip_header CF-Connecting-IP;
#real_ip_header X-Forwarded-For;
続いて、
sudo vim /etc/nginx/conf.d/security.conf
で、
server_tokens off;
に。
終わったらsudo nginx -t && sudo systemctl reload nginxを忘れずに
CloudFlare.confはCloudFlareが公表している、接続元IPを元に作っています。
この接続元IPの場合は、実際のIPアドレスはCF-Connecting-IPというヘッダから取り出してね！という設定です。
もう一つ、
security.confはnginxが出力するサーバ情報をなしにする設定です。
表示してもそのバージョンに対する攻撃が生まれるだけなので、百害あって一利なしです。（by. ikuradonさん）
最後、CAAの追加。
@ 1 IN CAA 0 issue comodoca.com
@ 1 IN CAA 0 issue digicert.com
@ 1 IN CAA 0 issue globalsign.com
@ 1 IN CAA 0 issue letsencrypt.org
@ 1 IN CAA 0 issuewild comodoca.com
@ 1 IN CAA 0 issuewild digicert.com
@ 1 IN CAA 0 issuewild globalsign.com
@ 1 IN CAA 0 issuewild letsencrypt.org
こういった内容のCAA.txtを、DNS→DNS Records→Advanced（右下）→Upload DNS Fileでアップロードして完了。
永続化できてない！
ここで、docker-composeを確認した所、コメントアウト外ししたものが戻っていました。どうも、DBとRadisがDockerの外に出ておらず、Dockerの「変更点があってもコンテナが再起動した時点で消失する」ルール的なのに巻き込まれてしまったそう。
この時点で、ローカルルールとか書いていましたが、控えれるものだけ控えて吹き飛ばします。
sudo docker-compose down
sudo docker-compose build
sudo chown -R 991:991 public
sudo docker-compose run --rm web bundle exec rake db:migrate
sudo docker-compose run --rm web bundle exec rake assets:precompilesudo docker-compose up -d
これで、DBがDockerの外に出た（ハズ）。
SendGrid
しかし、ここにきてユーザー登録のメールが届かないという謎トラブルが。
よくよく調べてみると、Mailgunは、無料ユーザーであってもクレカ登録が必須とのこと。しかし、クレカって、借金みたいなイメージが強すぎるので、あまり持ちたくないんですよね。できるだけ、プリペイドカードとかで済ませたい。
そこで、クレカ要求してくるMailgunは諦め、クレカ必要のないSendGridを使うことにしました。
国内代理店のサービスもありますが、審査があるようです。本家のものをそのまま使っちゃえばいいと思います。
会社名は「Individual（個人）」を選択し、アカウントを作成します。作成し終えたら、独自ドメイン使用の設定をします。APIキーを作成（名前は任意。「Mastodon」とか）し、生成されたパスワードが消える前に、vim .env.productionで設定を書き換えてしまいます。
SendGridの設定に戻ります。Settings→Sender Authenticationを開き、Domain Authenticationをクリック。あとは、必要事項をフォームに入力していきます。サブドメインは適当（ただの踏み台なので）。DKIM Selectorは空欄です。
レコードが出てくるので、CloudFlareにCNAMEで追加していきます。これは保護する必要無いので、雲のマークはクリックして灰色にします（mailレコードの部分だけはオレンジ色のままに）。あと、
レコード種類：SPF (TXT)
Name：@
Value：v=spf1 include:sendgrid.net ~all
これも追加します。追加し終えたら、Mailgunのレコードは削除します。使わないので。
これは、
v=spf1: spfのデータとして見てね
include:sendgrid.net: sendgrid.netからspfデータを持ってくる
~all: 他のアドレスから送られたメールに関しては自分は関与していないよ
って意味です。（by.ikuradonさん）
入力が終わったら、SendoGridでチェックボックスにチェックを入れて、Verify。うまくいったら、「It's workd」と出るはずです。
サーバーを再起動させます。
sudo docker-compose up -d
これでしばらく待ちます。パスワード再設定のメールを送らせてみて、無事届けば成功です。
永続化テスト
DBとかがきちんとDockerの外に出ていて、永続化できているか、テストします。
sudo docker-compose down
sudo docker-compose build
sudo docker-compose up -d
永続化できてなかったら、これでDBが消えます。きちんと外出しできていれば、消えないはずです。結果は……問題ありませんでした。
かくして、鯖缶工場でしそのはさんに続く2人目の鯖缶として、無事出荷と相成りました。
とはいえ、これから、きちんとバージョンアップを行っていく必要がありますので、やらないといけない事も学ばないといけない事も沢山あります。
スタートラインに立ったばかりと気を引き締め、がんばっていきたいと思います。……どうしてもトライアンドエラーになるでしょうし、書いてるそばから早速やらかしましたけど。
日常のメンテナンス
容量チェック
df -h
これで、今、どのドライブがどれだけ使われているかがわかります。DBが置かれている所が一杯になると、インスタンスが止まってしまいますので、適宜様子を見る必要があります。
free -h
これで、どれだけメモリーが使われているかなどがわかります。カツカツなようなら、色々なものを見直さなくてはいけなくなるかも。
Sidekiq
お恥ずかしい話、ムトーの無料インスタンスを借りていた頃から、Sidekiqの見方（使い方）ってよくわかってなかったんですよね（＾＾；）
色々な項目がありますが、大切なのは「待機状態」。これが50を超えているのが常態化してると、捌き切れてないということです。ジョブを増やさなくてはいけません。
今の所、Amemiya.workの場合は、別段何かやらなくても問題なく流れているようです。
バージョンアップ
先に述べたように、バージョンアップのやり方はリリースノートを見れば、だいたい書かれています。ただ、もう少し多くのコマンドを打つ必要があります。
時々、バックアップをしてくれとリリースノートで求められることがあります。
Dockerでのバックアップは、
sudo docker exec mastodon_db_1 pg_dump -Fc -U postgres postgres > name_of_the_backup.dump
です。
バックアップが終わったら、バージョンアップをしていきます。
sudo docker-compose stop web
sudo docker-compose stop sidekiq
まず、サービスを止めます。
git fetch --all
git stash
git checkout v2.6.2
git stash pop
ソースコードを進めます。「git checkout」の後には、アップグレード後のバージョンを書きます。
なお、ここで、「git stash --all」なんてやると、色々なものが滅茶苦茶になります。
sudo docker-compose build
sudo docker-compose run --rm web rails db:migrate
ビルドします。
sudo docker-compose up -d
sudo docker-compose run --rm web rails db:migrate
起動させ、後追いでmigrate。これで終わり。
おわりに
かくして、2018年9月1日、無事にユーザー登録を開放し、Amemiya.workのサービスを開始することができました。鯖缶工場の皆様には本当に頭が上がりません。重ね重ね御礼申し上げます。
また、こんな長文の記事を最後まで読んでいただいたあなたにも感謝を申し上げます。
明日、ぐすくまさん主催のアドベントカレンダーでは、noellaboさんが連合リレーに関する記事を投稿されるようです。S.H.さんの方でも、h3_potetoさんが寄稿されるようです。お楽しみに。
