皆さん、こんにちは。
現在、フォーラムを管理できず、新しいSSLリンクの設定方法がまだわからないため、一時的にシャットダウンしたいと考えています。ユーザーの皆様がハッキングされるリスクを冒してほしくありません。
フォーラムを完全に削除せずに、一時的に全員のアクセスを禁止することは可能でしょうか?
ご協力いただけると幸いです。よろしくお願いします。
皆さん、こんにちは。
現在、フォーラムを管理できず、新しいSSLリンクの設定方法がまだわからないため、一時的にシャットダウンしたいと考えています。ユーザーの皆様がハッキングされるリスクを冒してほしくありません。
フォーラムを完全に削除せずに、一時的に全員のアクセスを禁止することは可能でしょうか?
ご協力いただけると幸いです。よろしくお願いします。
サイトを読み取り専用モードにすることを検討しましたか?これは、管理者設定のバックアップセクション your-site-name/admin/backups にあります。これにより、サイトが読み取り専用になり、ユーザーは投稿などができなくなります。
標準的なインストールであれば、再構築で新しいSSL証明書を取得できるはずです。
それができない、またはしたくない場合は、提案されたように読み取り専用モードにすることができます。
また、./launcher stop app を実行してコンテナをシャットダウンすることもできます。
こんにちは、オンドレイさん。
お返事ありがとうございます。これについては読みましたが、ユーザーがフォーラムにアクセスするのを止めることはできません。現在、フォーラムは安全ではなく(リンクの先頭にhttpsがない、つまりセキュリティ証明書がない)、問題となっています。
SSL の設定に時間がかかるため、いったん停止するのではなく、まず組み込みの SSL テンプレートを試すことをお勧めします。Discourse では Let’s Encrypt を使用した SSL の取得と利用が非常に簡単なので、停止する前に試してみる価値があるでしょう。
試す場合は、app.yml ファイルの先頭付近にある以下の行の # を削除してください。
## Uncomment these two lines if you wish to add Lets Encrypt (https)
#- "templates/web.ssl.template.yml"
#- "templates/web.letsencrypt.ssl.template.yml"
次に、同じファイルのさらに下にある #LETSENCRYPT_ACCOUNT_EMAIL: me@example.com を見つけ、ここでも # を削除し、例のメールアドレスを実際のメールアドレスに置き換えてください。
最後に、Discourse を再構築すると、Let’s Encrypt 証明書が取得され、HTTPS が設定され、HTTP からのすべてのリダイレクトが行われます。
cd /var/discourse
./launcher rebuild app
Discourseをどのようにインストールしましたか?
残念ながら、Discourseのインストール方法や、一般的な仕組みがわかりません。父が事業のためにフォーラムを設置しましたが、今年亡くなりました。Linodeにサーバーがあり、Discourseがそこにインストールされている可能性があります。
サイモンさん、詳しい説明をありがとうございます。このウェブサイトは父が作成しましたが、父は今年亡くなりました。Discourseのインストールやセットアップについては全く知識がなく、ウェブサイト全般についても分かりません。このappl.ymlファイルはどこで見つけられますか?父はDiscourseをドメインサーバーにインストールしたのでしょうか?Linodeを使用しており、そこには「Discourse」という名前の「Linode」があります。これが何を意味し、どのようにインストールにアクセスすればよいのか分かりません。
ご協力ありがとうございます。
ご愁傷様です。![]()
まず第一に、その「Discourse」Linodeで「バックアップ」が有効になっていることを確認することを強くお勧めします。これが最初に行うべき緊急のステップです。
次に、https://yoursitedomain.com/admin/backups でDiscourseのバックアップも有効になっていることを確認してください。
第三に、Webブラウザから直接、管理UIパネルからアップデートを実行してみてください。これにより、問題が解決する可能性があります: https://yoursitedomain.com/admin/upgrade
それはひどいですね。お気の毒に。そのサーバーにsshで接続する方法がわからない場合は、バックアップを作成し、新規インストールを実行してから、そこにバックアップを復元するのが最も簡単な方法です。
サーバーへのsshアクセスが可能であれば、ここに記載されているコマンドライン操作を実行できます。
理論上はLinodeのSSHパスワードをリセットできるはずです。
https://www.linode.com/docs/guides/accounts-and-passwords/#resetting-the-root-password
それは簡単そうですし、動作するメール設定を移行できるようになります。この設定は壊れているようなので、おそらくクリーンインストールするでしょう。
私はそれに同意しません。 app.yml のサンプルに含まれるデフォルトでは、web.ssl または web.letsencrypt.ssl テンプレートを使用しないことになっており、@Mads が説明した HTTP リダイレクションの欠如は、単にそのデフォルトが維持されているだけで、SSL がなかったことを示しているだけだと思います。
それは Discourse をホストしているサーバーとして有望そうです。それでもシャットダウンしたい場合は、その Linode の電源を切るだけで済みますが、セットアップ方法によっては、そのサーバーに他のものがある可能性もあります。
@sdpiowa が言ったように、彼が提供したリンクに記載されているようにパスワードをリセットできます。一番下までスクロールして Resetting the Root Password を参照してください。ただし、そのサーバーの root パスワードをすでに持っている場合は、これを行う必要はありません。
root パスワードがあれば、サーバーにアクセスする最も簡単な方法は、Linode クラウドマネージャーの LISH コンソールを使用することです。
https://www.linode.com/docs/guides/using-the-lish-console/
コンソールに login: と表示されたら、最後のステップで root と入力して Enter キーを押し、次にパスワードを入力して Enter キーをもう一度押します。これでシェルが表示され、サーバーでコマンドを実行できるようになります。ただし、間違いをしないように注意してください。ほとんどの間違いは単にエラーが発生して何も起こらないだけですが、root シェルでの間違いは深刻な副作用を引き起こす可能性があります。
さらに進む前に、必ず手動で Discourse のバックアップを作成し、それが完了したら、Linode クラウドマネージャーで手動スナップショットを作成してください。これにより、何か問題が発生した場合に復旧するために必要なものがすべて揃っていることがわかります。
まずディレクトリを変更して適切な場所に移動します。
cd /var/discourse
Linode イメージには通常 nano がインストールされており、これは非常に使いやすいテキストエディタです。app.yml ファイルを編集します。
nano containers/app.yml
マウスでカーソルを移動できない可能性があるので、矢印キーを使用してファイル内を移動し、前述の説明に従って変更を加えます。それが終わったら、CTRL+X を押して終了します。保存するかどうか尋ねられるので、Y を押して「はい」と答え、ファイル名が尋ねられたら、Enter キーを押すだけでファイルが保存され、nano が終了します。
最後に、Discourse を再構築します。これを開始した後、LISH ウィンドウを閉じないでください。
./launcher rebuild app
すべてがうまくいけば、おそらく 10〜20 分後に Discourse が SSL で再開され、実行されるはずです。
HTTPS がデフォルトになってからかなり時間が経ちました。OS もサポート終了から時間が経っている可能性が高いです。
私の意見では、初心者にとって最も簡単で安全な解決策はクリーンインストールですが、あなたは彼がこの問題を解決するのに役立つ有望な指示を親切にも提供してくれました!
皆さん、ご協力と詳しい説明をありがとうございました!この件で助けてくれる人が見つかったかもしれません。皆さんのアドバイスをぜひ見せてあげます。本当に感謝しています ![]()
素晴らしいですね!
情報提供ありがとうございます。
こちらはマッツです。Madsさんのサポートをしており、*nixやDockerにはかなり慣れている経験豊富なシステム管理者です。Dockerで少し深く掘り下げる必要がありましたが、なんとか解決しました。
Letsencryptのログには次のように表示されていました。
The CA is processing your order, please just wait. (1/30)
community.fruityknitting.com:Verify error:Fetching https://community.fruityknitting.com/.well-known/acme-challenge/9NEyZhZzZQ9FwGrqGqDNblLiwtOQQGlYr-9nSFUwKhw: Connection refused**
Nginxの設定では、ポート80からhttpsへの即時リダイレクトがあり、その後AndrewさんがDiscourseでPatreon経由で有効なアカウントを確認したのだと思います。このポート80のリダイレクトとPatreonのリダイレクトが、Letsencryptによるローカルファイルの検証を妨げていた可能性があります。
Nginxのポート80リダイレクトを停止し、Nginxを再起動して、以下を再実行しました。
/shared/letsencrypt/acme.sh --cron --home /shared/letsencrypt
そして成功しました。
皆さん、役立つコメントをありがとうございました。
では、また。
Patreonのリダイレクトはhttpsではありませんでしたか?
それはロバートでした。おそらく、より明確に述べると次のようになります。
Nginx が 80 から 443 への無条件リダイレクトを行い、その後 Discourse アプリがセッションまたは Cookie か何かを推測してすぐに Patreon に転送します…
これにより、Letsencrypt の検証が壊れるのに十分です。
これで合っていますか?
それは、HTTP経由のすべての着信通信をHTTPS経由に強制するための標準機能だと思います。
Patreonの件は少し「奇妙」に聞こえますか?
HTTPS経由でアプリケーションレイヤーで100%できなかったことを、それは何をしようとしているのですか?
リバースプロキシがなぜ気にする必要があるのですか?
ロバート、試してみて…
https://community.fruityknitting.com/