最近投稿をしていませんでしたが、バイトとサーバ移転作業に明け暮れていました。
今回はサーバ移転作業がある程度落ち着いたので、サーバ移転作業で失敗したことをまとめたいと思います。失敗談なので、丁寧語かつ軽い感じで。
3月末から所属する研究室のサーバ移転で作業をしていました。内容としては、Webサーバ、メールサーバ、メーリングリストサーバの構築や、Sambaでのファイル共有などです。
2ヶ月という時間をかけ、最終的にはサーバ移転が無事完了しました。
通常、サーバ移転には長くて1ヶ月前後だと思います。個人の予測ですが。
なぜ2ヶ月も時間がかかったのか。大きな失敗といえば以下の3つだと思います。
- Let's encrypt でのSSL証明書が発行できなかったこと
- ポートを全閉じしてしまいSSH接続できなくなったこと
- 異常なリクエスト数でSSH接続が何度も途切れてしまっていたこと
まずはポート開放の話から。
Let's encrypt でのSSL証明書が発行できなかったこと
Certbotを使って、SSL証明書を発行しようとしていましたが、それに失敗していました。
原因としては、マシン側のポートは開放したのに大学側にポート開放の申請をしていなかったので、HTTP-01 チャレンジに失敗していたためでした。
CertbotはLet's encryptを認証局として、検証用のページをトークン名と同じ名前で作成してHTTP通信が有効かの検証、CSRやKEYファイルの自動作成、3ヶ月で有効期限が切れるところを、cron（定期実行）で証明書の更新をするものです。
ブラウザにもよりますが、SSL証明書が未発行のページにアクセスする際に、Google Chromeだと「保護されていないページです」などの赤い警告画面が出ますね。HTTPSに強制リダイレクトする設定がされていなければ、警告を無視してアクセスできる、皆さんも見たことがあるページが表示されます。
通信データを暗号化するために発行するのですが、先述の通り、HTTP通信ができるかの検証（HTTP-01 チャレンジ）が行われます。
HTTPS-01 チャレンジ(https://letsencrypt.org/ja/docs/allow-port-80/)
HTTP通信からHTTPS通信にリダイレクトできるかどうかを検証するものなので、80番および443番ポートを開けないといけないと。
ufw環境では、以下のコマンドでポート開放できます。
sudo ufw allow 'Apache Full'
もしくは、80番と443番を指定して開けるかですね。とにかく、マシン側のポートは開けることに成功したと。
証明書発行のコマンドを入力したのですが、ポート関連がいけないかもというエラーが出ました。
Certbot failed to authenticate some domains (authenticator: apache). The Certificate Authority reported these problems:
Domain: <省略>
Type: connection
Detail: <IPアドレス>: Fetching <httpsのURL>/.well-known/acme-challenge/<トークン>: Timeout during connect (likely firewall problem)
Hint: The Certificate Authority failed to verify the temporary Apache configuration changes made by Certbot. Ensure that the listed domains point to this Apache server and that it is accessible from the internet.
色々と問題を探っていたところ、大学側でしかるべきところへ申請を行わないと、学外からのアクセスができないらしいことがわかりました。Let's encryptからのアクセスに対して、仕事を果たして接続拒否していたわけですね。
同じような状況の人がいるかもしれません。困っている場合は確認してみてください。
ポートを全閉じしてしまいSSH接続できなくなったこと
SSH接続ができなくなってしまい、サーバ関連の作業が全停止した期間がありました。
原因としては、ufw環境下でfirewalldをインストールし、競合したためでした。
以下の記事でもあるように、Ubuntuでは初期状態でufwパッケージがインストールされており、ポート関連の操作をこのパッケージで行います。
(https://qiita.com/uyaaaaaa/items/3ab5652d4aae16b58bdc)
参考にしていた資料がCentOSのものであり、支障ないだろうと軽く考えて以下のコマンドを入力。
sudo apt install firewalld
ダウンロードが始まり、98%のところで動きが止まりました。
様子がおかしいので、ターミナルを終了し、SSH接続をやり直そうとしたところ、22番ポートが閉じられていたため、SSH接続ができなくなっていました。
ufw環境とfirewalld環境が両立せず、ポート全閉じという偉業を成し遂げ、思わずちいかわみたいな顔になっていました。
「わ、わァ……！」
「泣いちゃった！！！」
って感じ。幸いにも、情報基盤センターにご連絡を差し上げ、apt purgeコマンドでfirewalldをアンインストールしてもらいました。ご迷惑をおかけしました。
異常なリクエスト数でSSH接続が何度も途切れてしまっていたこと
これが最後の難関でした。
ほぼすべての設定が終わり、ようやく運用しようとしたときに、15秒も経たずにSSH接続が切れるようになりました。
かれこれ1ヶ月強も作業し続けてこの状態で、この間には一度もなかった現象でした。
これに関しては、自力で解決することはついにできませんでした。
またしても情報基盤センターの方に連絡を差し上げ、解決していただきました。
というのも、SSH接続でなら作業ができるという状態で、そのSSH接続がすぐに途切れるので、ろくに調査ができないという状況でした。
わかったことといえば、朝4時が一番接続が安定する時間であるということでした。
1時間ごとにSSH接続を検証するという強硬策に打って出ましたが、結局この時間でも30分もちませんでした。
さて、その原因なのですが、AppleのTime Capsuleでした。
(おそらくTime Capsule自体が悪いわけではないとは思います)
無線Wi-Fiルータとして使っていたのですが、聞いたところによると、これが大量にリクエストを送っていたため、SSH接続が不安定になっていたとのこと。
確かに、電源を切ってみるとSSH接続が安定するようになりました。
コンフィグファイルをいじったりして、応答回数などの設定を変えても改善しない。接続はすぐ切れる。限られた時間で保存したログを見直しても異常が見つからない、と手も足も出なかった状態だったので、本当に助かりました。
2週間近くかかったため、本当にご迷惑をおかけしました。心苦しい限りです。
学んだこと
失敗談としては以上で、大切なのはここから学ぶことです。
学んだことは、頑張って頑張ってダメなら人に頼るということです。
結局他人頼りかよ、と思うかもしれません。ただ、失敗したまま解決せず時間が経ち、周囲に不便を強いることも迷惑であることには間違いありません。であれば、素直に人に頼るべきであることを痛感しました。
現在の状態、改善後にどういう状態にしたい、使っているパッケージなど、必要な情報を可能な限り集め、せめてお聞きする相手が原因にたどりつきやすくすることを心がけました。
実際、先に挙げた3つの失敗は、原因の特定が難しいもの(SSH接続の話)や、自分ではどうにもならないこと(SSL証明書の話。ちなみに学生では申請ができないらしい)です。
ポート全閉じは全面的に私が悪かったわけですが、その問題が起こってからはSSH接続ができないわけですから、もうその時点で自分だけで解決することは不可能なわけです。
そういう意味では、ポート全閉じの話は、下調べが足りなかったとも言えます。
なので、これは自分だけでは解決できそうにない、と感じるまで調べることも大事ですね。
そして、相手への伝え方も同様です。
まとめとしては、助けが必要であるとわかるまで調べ、必要な情報を収集し、適切に情報を伝えた上で人に頼りましょう、ということでした。
サーバ構築の技術的な経験もそうでしたが、コミュニケーションという面でも成長できた気がしました。
総じていい経験ができたと、振り返って思います。
長くなりましたが、記事は以上です。