[{"template":"item","lang":"ja","langs":["en","ja","zh-CN","zh-TW"],"summary":{"raw":"Subversionは10年前のもののように聞こえます。特に mod_dav_svn。しかし、祖先のコードがどこに配置されているかを言うのは難しいです。要するに、あなたはすでに既製のNginxを持っていて、すでにストリーキングしているコードリポジトリにHTTPSサポートを追加したいのですが、それは proxy_passがそれを行うことができるわけではありません。","html":"

Subversionは10年前のもののように聞こえます。特に mod_dav_svn。しかし、祖先のコードがどこに配置されているかを言うのは難しいです。要するに、あなたはすでに既製のNginxを持っていて、すでにストリーキングしているコードリポジトリにHTTPSサポートを追加したいのですが、それは proxy_passがそれを行うことができるわけではありません。

\n"},"visible":true,"routable":true,"title":"NginxリバースプロキシApache Subversion","comment":{"enabled":true,"reply":true},"discuss":{"enabled":true},"keywords":[],"webmention":{"enabled":true,"accept":true,"callback":{"secret":{"hash":{"sha256":"44bb9da44b424c6dfc9233819e907029ff2ccdfaa89919d3696ddf8db7ff6647"}}}},"pingback":{"enabled":true,"accept":true},"slug":"apache-subversion-behind-nginx","taxonomy":{"category":["Software"],"tag":["Nginx","Apache","Subversion","Regexp"],"series":[]},"route":"/apache-subversion-behind-nginx/","toc":{"enabled":true},"published":{"date":"2022-01-03 00:52"},"modified":{"date":"2024-04-18T10:03:42.258Z"},"data":{},"license":"CC-BY-4.0","author":[{"email":{"value":{"encrypted":"ODgyZjdiZDg4OTVmMjllOGZkNmFmYg==","algorithm":"aes-256-gcm","iv":"067f6d66f2ba5dd50c8443be"},"hash":{"md5":"8770854a9222b6bf1ee195220793bcf1"}},"url":"https://dallas.lu","name":"Dallas Lu","lang":"en","user":"dallaslu"}],"contributor":[],"sponsor":[],"image":[],"audio":[],"video":[],"photo":[],"content":{"html":"

\n\n

例えば：

upstream subversion{\n    127.0.0.1:1080;\n}\nserver{\n    listen [::]:443;\n    server_name svn.example.com;\n\n    # SSL ...\n\n    location / {\n        proxy_pass http://subversion;\n    }\n}\n

まず、おめでとうございます。proxy_pass http://subversion/ は使用されていないため、最初のピットは回避されます。末尾の /文字により、NginxがURLを自動的にエンコードし、通常の使用に影響するためです。ただし、送信時にすぐに502エラーが発生します。

COPYおよびDELETEのサポート

Subversionは https://svn.example.com をHTTPS接続と見なし、ApacheはHTTPサービスのみを提供するため、リクエストヘッダーの Destination は http:// で始まる必要があります。

すぐに、Stackoverfollowから変更する方法を見つけました。

location / {\n    proxy_pass http://subversion;\n    set $fixed_destination $http_destination;\n    if ( $http_destination ~* ^https(.*)$ ) {\n        set $fixed_destination http$1;\n    }\n    proxy_set_header Destination $fixed_destination;\n}\n

その後、すべてがOKであることがわかりました。とても良いです、それは本当に2番目のピットに落ちました。

Nginxの紛らわしい動作

$fixed_destination は、https:// を http:// に置き換えるだけのように見えます。非常にシンプルで明確で、問題ありません。

トランクから新しいブランチを喜んでコピーするときは、ファイル名に中国語が含まれているファイルを変更し、コンパイルしてテストにスムーズに合格します。次に、トランクにマージして戻すときに、十分に注意すれば、ファイル名がurlencodedされていることがわかります。もちろん、それは中国の名前ファイルを含むだけではありません、想像してみてください、しかしブランチで提出されたすべてのファイルの名前はurlencodedです！そして、urlencodedされたファイル名は、次回ブランチがマージされるときに再びurlencodedされます！

問題は $fixed_destination にあります。http$1 は実際にはNginxによってurlencodedされています。この魔法の問題を回避するために、Destinationの変更をApacheに任せるか、それをデコードするためのluaスクリプトを作成することにしたかもしれません。ちょっと待って！別の魔法の解決策は次のとおりです。

location / {\n    proxy_pass http://subversion;\n    set $fixed_destination $http_destination;\n    if ( $http_destination ~* ^https(?<unencoded_destinaton>.*)$ ) {\n        set $fixed_destination http$unencoded_destinaton;\n    }\n    proxy_set_header Destination $fixed_destination;\n}\n

マッチングに使用する通常のグループに名前を追加するだけでOKです...

他の

このソリューションは、9年以上前のMaxim Dounin からの返信に基づいています。したがって、名前付きキャプチャグループを使用して、Nginxの正規表現を使用して変数を変更することをお勧めします。

10年前のソフトウェアアーキテクチャ、10年前の問題は、10年後もまだ存在しています。驚くべきことに、10年前のソリューションはまだ機能しています。

\n","headings":[{"level":2,"text":"COPYおよびDELETEのサポート","id":"copyおよびdeleteのサポート"},{"level":2,"text":"Nginxの紛らわしい動作","id":"nginxの紛らわしい動作"},{"level":2,"text":"他の","id":"他の"}],"meta":{"prism":true},"links":[{"href":"https://trac.nginx.org/nginx/ticket/348","type":"mention"}]},"earlier":"/use-your-primary-domain-as-an-mastodon-name/"},{"template":"item","lang":"ja","langs":["en","ja","zh-CN","zh-TW"],"summary":{"raw":"セルフホストのブログがあり、Mastodonインスタンスを設定する予定がある場合、またはすでに設定している場合は、ドメイン名を選択するという問題に直面する必要があります。ブログがexample.comであるとすると、Mastodonアカウントはyourname@example.comまたはyourname@mastodon.example.comのどちらにする必要がありますか？","html":"

セルフホストのブログがあり、Mastodonインスタンスを設定する予定がある場合、またはすでに設定している場合は、ドメイン名を選択するという問題に直面する必要があります。ブログがexample.comであるとすると、Mastodonアカウントはyourname@example.comまたはyourname@mastodon.example.comのどちらにする必要がありますか？

\n"},"visible":true,"routable":true,"title":"プライマリドメイン名をMastodonのインスタンスとして使用します","comment":{"enabled":true,"reply":true},"discuss":{"enabled":true},"keywords":[],"webmention":{"enabled":true,"accept":true,"callback":{"secret":{"hash":{"sha256":"44bb9da44b424c6dfc9233819e907029ff2ccdfaa89919d3696ddf8db7ff6647"}}}},"pingback":{"enabled":true,"accept":true},"slug":"use-your-primary-domain-as-an-mastodon-name","taxonomy":{"category":["Internet"],"tag":["Mastodon","Nginx"],"series":["Unify Your Online Accounts"]},"route":"/use-your-primary-domain-as-an-mastodon-name/","toc":{"enabled":true},"published":{"date":"2020-11-10 13:44"},"modified":{"date":"2024-06-14T07:45:13.964Z"},"data":{},"license":"CC-BY-NC-SA-4.0","author":[{"email":{"value":{"encrypted":"ODgyZjdiZDg4OTVmMjllOGZkNmFmYg==","algorithm":"aes-256-gcm","iv":"067f6d66f2ba5dd50c8443be"},"hash":{"md5":"8770854a9222b6bf1ee195220793bcf1"}},"url":"https://dallas.lu","name":"Dallas Lu","lang":"en","user":"dallaslu"}],"contributor":[],"sponsor":[],"image":[],"audio":[],"video":[],"photo":[],"content":{"html":"

\n\n

シンプルさと分かりやすさのためには、当然ながらブログとマストドンのドメイン名を同じにした方が良いでしょう。しかし、Mastodonは第2階層のディレクトリの下では動作しません。 Mastodonのウェブ部分をリバースエンジニアリングによって第二階層のドメインやディレクトリに移動させたとしても、分散型サービスである本サービスは、連邦宇宙の他のインスタンスノードとデータを交換する際に未知の問題が発生する可能性が高い。

幸い、フェデレーションノード間の通信における重要なステップは、 https://example.com/.well-known/host-metaにアクセスすることです。このファイルのコンテンツには、次のステップのURLが含まれています。また、Mastodonは LOCAL_DOMAINおよび WEB_DOMAINオプションもサポートしています。

マストドンを設定する

.env.productionを編集し、次の変更を加えます。

変更しないでください LOCAL_DOMAIN;
WEB_DOMAIN構成を追加し、mastodon.example.comなどのセカンドレベルドメイン名に設定します。

設定 mastodon.example.com

mastodon.example.comのNginxホストを構成するには、Mastodonのドキュメントを参照してください。 Mastodonのstreaming/sidekiq/webサービスを再起動し、nginx構成をリロードすると、mastodon.example.comにアクセスできるようになります。

example.comを設定する

ただし、外部インスタンスがアカウントyourname@example.comに接続しようとすると、アドレスがmastodon.example.comであることがわからないため、 https://example.com/.well-known/host-metaは、 https://mastodon.example.com/.well-known/host-metaのコンテンツを返すことができます。

しかし、あなたのアカウントに接続しようとする外部インスタンス yourname@example.com は、あなたのウェブアドレスが mastodon.example.com であることをまだ知りません。 known/host-metaはhttps://mastodon.example.com/.well-known/host-metaを返します。

example.comのNginx構成で、Mastodonの構成を削除し、次のルールのみを追加します

location = /.well-known/host-meta {\n       return 301 https://mastodon.example.com$request_uri;\n}\n

Nginxをリロードするだけです

その他の構成

上記の構成は、felxの補足ドキュメントMastodonとそれが提供するユーザーに異なるドメイン名を使用するからのものです。記事で述べたように、メインドメイン名ジャンプとWEB_DOMAIN構成は要件を満たすことができますが、インスタンスバージョンとクライアントの種類が異なるため、依然として奇妙な問題が発生することは避けられません。

また、しばらく実行されているMastodonのプライマリドメイン名からセカンダリドメイン名に切り替えると、より明白な問題が発生する可能性があります。

公式ドキュメントと経験のルートの章によると、互換性を高めるためにexample.comに次のルールを設定することをお勧めします。

## mastodon web url\nlocation ~ ^/(about/more|settings|web|pghero|sidekiq|admin|interact|explore|public|@.<em>|relationships|filters|terms|inert.css){\n        rewrite ^(.</em>) https://$mastodon_host$1 permanent.\n}\n\n## mastodon .well-known\n\nlocation ~ ^/(.well-known/(host-meta|nodeinfo|webfinger|change-password|keybase-proof-config)|nodeinfo) {\n        rewrite ^(.*) https://$mastodon_host$1 permanent.\n}\n\n## mastodonのシステムリソース\n\nlocation ~ ^/(system|headers|avatars) {\n        ## set your mastodon public folder, or just redirect to $mastodon_host\n        #rewrite ^(.*) https://$mastodon_host$1 permanent;\n        root /home/mastodon/live/public;\n}\n\n## mastodonのURL (使用可能な post)\n\nlocation ~ ^/(api/v1|inbox|actor|oauth|auth|users){\n        return 308 https://$mastodon_host$request_uri;\n}\n

さあ、yourname@example.comでおしゃべりしましょう。

\n","headings":[{"level":2,"text":"マストドンを設定する","id":"マストドンを設定する"},{"level":2,"text":"設定 mastodon.example.com","id":"設定-mastodonexamplecom"},{"level":2,"text":"example.comを設定する","id":"examplecomを設定する"},{"level":2,"text":"その他の構成","id":"その他の構成"}],"meta":{"prism":true},"links":[{"href":"https://github.com/felx/mastodon-documentation/blob/master/Running-Mastodon/Serving_a_different_domain.md","type":"mention"},{"href":"https://docs.joinmastodon.org/dev/routes/","type":"mention"}]},"newer":"/apache-subversion-behind-nginx/","earlier":"/why-firefox-chrome-kill-ev/"}]

タグ: Nginx

NginxリバースプロキシApache Subversion

2022

プライマリドメイン名をMastodonのインスタンスとして使用します

2020