amotl
2019 年 12 月 11 日午前 3:08
121
おそらく、[1, 2, 3] のような事象に何度か見舞われた後に、「コンテナの停止 → git pull → launcher の再構築」というアップグレード手順を使い始めたため、オフラインページを実装しただけかもしれません。
もしかすると、アップグレードプロセスを円滑に進めるために、PostgreSQL が時間内にシャットダウンしなかった場合に強制的に終了させる処理の堅牢性が何かしらの変更を受けたのかもしれません。
いずれにせよ、オンラインアップグレード（再び）は、今すぐ再度試したところ、私どもにとって問題なく機能しました。そのため、お騒がせして申し訳ありませんでした。無視してください。
[1] Discourse stuck on "Currently Upgrading" - #15 by amotl Upgrade failed due to unclean database shutdown https://meta.discourse.org/t/upgrade-failed-due-to-unclean-database-shutdown-ii/103268
「いいね！」 3
mcdanlj
2020 年 7 月 26 日午前 3:19
122
その直後にコンテナの外で nginx をインストールおよび設定するためのガイドが続くため、少し混乱を招くかもしれません。
いずれにせよ、今日はこの外部 nginx 設定の追加的な利点に気づきました。登録やログイン時の IP アドレスとして、127.0.0.1 や Docker アドレス（おそらく 172. で始まるもの）が表示されることに慣れている場合、IPv4 とは異なり、コンテナに転送される IPv6 トラフィックが IPv6 アドレスを保持していなかったことが原因だった可能性があります。この設定により、ローカルアドレスの代わりに正しい IPv6 アドレスが表示されるようになります。
つまり、この設定は、ますます IPv6 化が進むインターネット上で、有用な管理ツールが正しく機能するために本質的に「必要不可欠」です（米国では、多くのモバイルトラフィックが含まれます）。
「いいね！」 4
この非常に役立つガイドをありがとうございます！いくつかのコメントがあります。
sudo apt-get install letsencrypt は sudo apt-get install certbot に置き換わったと思います。前者を実行すると、「‘letsencrypt’ の代わりに ‘certbot’ を選択します」という通知が表示されます。
友人が、Facebook でサイトを共有すると「301 moved permanently」のプレビューが表示されていることに気づきました。
編集：当初、ポート 80 のサーバーブロックの location / セクションを、ポート 443 のサーバーブロックの location / セクションに置き換えていました。しかし、それは冗長だったと思います。代わりに、リダイレクト用として機能していたポート 80 のサーバーブロックを削除し、メインのサーバーブロックの適切なセクションに以下を追加しました：
listen [::]:80;
listen 80;
また、Discourse の設定から https リダイレクトを有効にしました（これが必須かどうかはわかりません）。
これで Facebook 共有の問題が解決し、通常の HTTP リクエストが HTTPS にリダイレクトされているようです。他にもっと良い方法があれば、お知らせください。
「いいね！」 2
datvnn
2020 年 11 月 1 日午後 3:24
124
チュートリアルをありがとうございます。とても素晴らしいです。これで私の 502 ページがぐっと見栄えが良くなりました。/etc/nginx/sites-enabled/discourse.conf ファイルに追加する必要があります。
「いいね！」 2
mcdanlj
2021 年 4 月 30 日午前 1:50
125
このガイドに従ってインストールした際、nginx が更新された証明書を知っていなかったという問題に遭遇しました。私の場合、解決策は以下の通りです。
systemctl edit certbot
そして、以下の 2 行を追加しました。
[Service]
ExecStartPost=/bin/systemctl reload nginx
あるいは、システムから証明書を共有する別の mail-receiver コンテナを使用しているシステムでは、
[Service]
ExecStartPost=/bin/systemctl reload nginx
ExecStartPost=/bin/sh -c 'cd /var/discourse && ./launcher restart mail-receiver'
「いいね！」 3
チュートリアルをありがとうございます。私の環境では問題なく動作しています。
一点だけ気になったのですが、例えば Googlebot がそのエラーページを表示した場合、それが一時的なページだと認識してくれるのでしょうか？それとも、変更が一時的であることを伝えるために、何らかのエラーコードを送信する必要がありますか？
かっこいいエラーページのために、私のフォーラムへのインデックスがすべて削除されてしまうのは避けたいと考えています。
「いいね！」 1
ashs
2021 年 6 月 10 日午前 9:41
127
Google は 500/502 エラーを「後で再来する」べきだというシグナルとして捉えるべきです。サイトを頻繁に再構築していない限り、問題が生じることはありません。
私は長期間にわたり自社のフォーラムを nginx の裏で運用していますが、検索順位に悪影響は出ていません。
「いいね！」 5
はい、502 がまだ送信されているかどうかが不明でした。
「いいね！」 1
mcdanlj
2021 年 7 月 7 日午前 11:18
129
まだ送信されています。確認方法は以下の通りです。
nginx ドキュメント より：
構文: error_page code … [ = [ response ]] uri ;
設定からのスニペットは以下の通りです。
error_page 502 =502 /errorpages/discourse_offline.html;
これは、「502 Bad Gateway レスポンスコードが発生（または送信）された際、/errorpages/discourse_offline.html ファイルの内容を 502 Bad Gateway レスポンスコードで送信する」という意味です。= は、どの HTTP レスポンスコードを送信するかを指定するものです。
問題ありません！
@ashs の意見にも賛成です。月に 1〜2 回、1 分未満の 502 エラーが検索に悪影響を及ぼすことはありません。Google の検索結果に最近の投稿が表示されているのをよく見かけます。
「いいね！」 2
EddieT
2021 年 8 月 3 日午後 8:51
130
これを行っても、Cloudflare から 502 Bad Gateway エラーが表示されたままです。
「いいね！」 1
fefrei
2021 年 8 月 4 日午前 8:29
131
502 エラーは、おそらく設定エラーにより Nginx が起動していないことを示しています。nginx -t を実行すると、設定ファイルに問題がないか確認できます。エラーがない場合は、systemctl status nginx.service を実行して Nginx サービスのステータスを確認してください。
「いいね！」 5
EddieT
2021 年 8 月 4 日午後 1:26
132
nginx は動作するようになりましたが、その後すべてが404エラーになります。ファイルを正しい場所に配置したはずなのに、表示されるべきものが表示されません。
「いいね！」 1
私の質問はトピックのタイトルに直接関連していますが、このトピックで用いられている手法には関連しないため、このディスカッションに残しても問題ないかと存じます。
この問題を解決するために非常にシンプルな設定を行い、具体的な質問があります。
DigitalOcean に別のドロプレットをセットアップし、マーケットプレイス経由で LAMP サーバーをインストールしました。その後、サーバーがメンテナンス中であることを示す基本的な HTML ページと画像をアップロードしました。必要に応じて、通常の Discourse サーバーとこのメンテナンスサーバーの間で IP アドレスを切り替える（フローティングさせる）計画です。
ここで質問です：「メンテナンス」サーバーが正しく読み込まれるためには、メインの Discourse インスタンス用に既に取得済みの証明書に加えて、そのサーバー用に Certbot で証明書を取得する必要がありました。つまり、同じドメインに対して異なるサーバーで 2 つの証明書を持つことになります。これは機能しましたが、将来的に何か問題を引き起こすのではないかと常に懸念していました。オンラインで読んだ限りでは、この構成は問題ないようですが、実際にこの経験がある方がいればご教示いただきたいです。
「いいね！」 2
fefrei
2021 年 8 月 5 日午前 7:24
134
これは完全に有効な手順です。ただし、検証の方法によっては、証明書の更新が機能しない場合があります。たとえば、「メンテナンス」サーバーが HTTP ベースの検証を使用している場合、ドメインがそのサーバーを指していない間は検証が失敗し、おそらく目的が果たされなくなります。その場合、Let’s Encrypt から証明書を要求するのではなく、メンテナンスサーバーが定期的にメインサーバーから最新の証明書をコピーする方が合理的かもしれません。
「いいね！」 3
返信とご提案をいただき、ありがとうございます、フェリックスさん。
私のサーバーが HTTP ベースの検証を使用しているかどうかは、正直なところ分かりません（すべてあの素晴らしい Certbot を通じて設定しました）。しかし、ご懸念は完全に論理的です。少し調べてみましたが、ご提案のように証明書をコピーする方法に関するリソースは見つかりませんでした。また、何らかの cron ジョブの設定が必要になるとも推測しています。さらにご提案があれば、大変助かります。なければ、改めてご支援いただきありがとうございました。
「いいね！」 1
fefrei
2021 年 8 月 5 日午後 7:05
136
サーバーからサーバーへ直接ファイルをコピーするには、scp または rsync が有効なツールです。始めるには、こちら が参考になるかもしれません。
私の提案は、メインサーバーからメンテナンスサーバーへ定期的に証明書をコピーする cron ジョブを設定することです。
あわせて、HTTP ベースの検証の背景について説明します。ドメインが本当にあなたに属しているか確認するため、Let’s Encrypt はあなたのサーバーから特定のファイルを要求し、特定の応答を期待します。Certbot はこれを自動的に処理できます（検証リクエストに対して一時的にこのファイルを返すようにサーバーを設定する）が、もちろん、リクエストが実際にあなたのサーバーに到達しなければ機能しません。DNS があなたのサーバーを指していない場合、または IP アドレスを別の場所に変更した場合、リクエストは間違ったサーバーに送られ、Let’s Encrypt は期待した応答を得られないため、証明書の署名を拒否します。
「いいね！」 3
さらに調査いたします。リンクとご支援をいただき、改めてありがとうございます。
「いいね！」 1
pfaffman
2022 年 4 月 4 日午後 8:50
139
サイトの再構築中に「工事中」ページが必要な場合は、上記の手間のかかる手順を実行する必要があります。2コンテナのインストールに切り替えることをお勧めします。これは、保守がやや困難ですが（データコンテナをいつ再構築する必要があるかを知る必要がある）、新しいコンテナが起動するまでのダウンタイムは約30秒で済みますが、現時点ではかなりの量のRAMが必要です（2GBでは不十分かもしれませんが、確信はありません）。
「いいね！」 4
mcdanlj
2022 年 9 月 25 日午後 11:28
140
letsencrypt パッケージは、一般的に certbot と呼ばれるようになりました。
「いいね！」 1
