uwsgi と nginx を、ユーザー ホーム ディレクトリにあるソケット (chmod 777) を介して動作するように構成しましたが、nginx はソケットにアクセスできません (13: でアクセスが拒否されましたerror.log)。777 chmod を使用してソケットを /tmp/ に移動しようとしましたが、エラーが発生しました。2: No such file or directory
2021/09/21 19:40:16 [crit] 68278#0: *17 connect() to unix:///tmp/my.sock failed (2: No such file or directory) while connecting to upstream, client: ***, server: ***, request: "GET / HTTP/1.1", upstream: "uwsgi://unix:///tmp/my.sock:", host: "****"
2021/09/21 20:10:16 [crit] 517#0: *1 connect() to unix:/home/***/.deploy/my.sock failed (13: Permission denied) while connecting to upstream, client: ***, server: ***, request: "GET / HTTP/1.1", upstream: "uwsgi://unix:/home/***/.deploy/my.sock:", host: "***"
PS selinux 無効
答え1
答えにたどり着く前に、chmod 777 を使用したり、SELinux を無効にしたりするといったセキュリティ上の悪い習慣を断ち切るよう全力を尽くすべきです。むしろ、UNIX の権限モデルを完全に学習して常に適切な権限を把握し、SELinux で動作するようにサービスを設定し、SELinux が提供する追加のセキュリティ レイヤーのメリットを享受すべきです。
ユーザーのホームディレクトリの奥深くに埋め込まれたソケットが機能しない理由は、親ディレクトリの権限により、必要なアクセス (この場合は、検索x) が禁止されています。 を使用して、namei -l /home/***/.deploy/my.sockすべての親ディレクトリの権限を一度に確認し、検索権限を許可していないディレクトリ (ほとんどの場合、/home/***) を修正します。
chmod +x /as/needed
また、必要に応じてソケット自体の権限と所有権を修正することを忘れないでください。
/tmp完全を期すために、ソケットが見つからなかった理由は、システム サービスとして実行されている nginx がシステム/tmpディレクトリにアクセスできないためです。Systemd はこれを起動してPrivateTmp=true、一意のプライベート ディレクトリを作成し、そのディレクトリに nginx の/tmp名前空間を割り当てます。これが、これらすべての/tmp/xxx-systemd-private-fooディレクトリの目的です。