☰

nginx ファイルの最適なパス

tag-icon • tag-icon nginx ssh permissions shell-scripting path
nginx ファイルの最適なパス

私はいつも、さまざまなファイルとその配置場所に苦労してきましたpaths。nginxご存知のように、両方の配置場所を変更することができます。wwwのディレクトリweb appと関連logファイル。

私が見つけた問題は、呼び出し用のユーザー スクリプトbashと、これらのファイルのさまざまな部分にアクセスする必要があるスクリプト、さまざまなファイルのスケジュールされたネットワーク コピー、さらにはこれらのファイルの更新の両方があることです。RubySSHcrontabnginx

nginx私は、さまざまなディストリビューションのパッケージ インストールで推奨されている静的パスに従ってきましたが、アクセシビリティの点では最適ではなかったpermissionsため、問題に遭遇することがよくありました。そこで、さまざまなメイン パスを調査し、これらすべてを考慮して設計されたものを選択し、セキュリティ レベルを高く維持するようにしました。さまざまな場所を確認しましたが、今回再びこの問題に直面したので (動作しない、さまざまな項目に問題があるなど)、これらすべてをどこに配置すればよいのか尋ねようと思いました。pathlinuxcrontabspermissions

static私のアプリは標準のHTML アプリケーションではありません。実行中Rackの、および受信アップロードなどがあるアプリケーションがあります。app serverGemfile

私が評価している 2 つの場所は次のとおりです。

しかし...ディレクトリについては次のように読みました/usr:

/usr はファイルシステムの 2 番目の主要セクションです。/usr は共有可能な読み取り専用データです。つまり、/usr はさまざまな FHS 準拠ホスト間で共有可能で、書き込み不可である必要があります。ホスト固有の情報や時間とともに変化する情報は、他の場所に保存されます。

大規模なソフトウェア パッケージでは、/usr 階層の直下のサブディレクトリを使用しないでください。

それで、私は困惑しています。スクリプトを試行する際に最小限の手間で済む、読み取り/書き込み可能なファイルの場所を誰かお勧めできますかcron?

答え1

ウェブサイトのファイルをホストするための「絶対に」適切な場所は です/srv/www。そこから、通常はこれをドメイン関連のディレクトリに「パーティション分割」します。

つまり、全体として、/srv/www/example.com次の構造/サブディレクトリになります。

  • publicそのドメイン/ウェブサイトにバインドされた公開アクセス可能なファイルを保存します
  • logsそのドメインにバインドされたログファイル（NGINX、PHP-FPMなど）を保存します。
  • sessionsユーザー固有のセッション（PHPセッションなど）を保存します。

PHP-FPMを使用する場合でも、他の「スクリプトデーモン」を使用する場合でも、デーモンの設定を調整し、ファイルを正しくchmod/chownして、権限を正しく設定する必要があります。権限モデルを構成する。 見るNGINX と PHP-FPM。権限はどうすればよいですか?- これは、PHP-FPM に関係なく、ほとんどの Web サイト設定に当てはまります。

  • 適切な分離のために、各ウェブサイトに個別のユーザーを追加します。例:example
  • スクリプトデーモンをそのユーザーとして実行するように設定する
  • ウェブサーバー（NGINX）ユーザーをサイトユーザーのグループメンバーにします。 usermod -a -G example nginxこれにより、NGINXはグループ権限が読み取りに設定されているファイルを読み取ることができるようになり、読み取りたくないファイル（設定ファイル）は、グループ権限ビットを削除するだけで保護できます。chmod

結局のところ、権限の問題は発生しません。すべてが同じユーザーによって所有され、「実行」されます。

答え2

質問が非常に漠然としているため、これをクローズすることに投票します。また、問題の原因ではないツールを状況のせいにしようとしています。ある程度、MAC サブシステムによってできること/すべきこと、およびパッケージ管理システムが構成ファイルを処理する方法によって制約を受けます。ただし、これがどのディストリビューションであるかを教えていただけないため、それが関連しているかどうかはわかりませんし、ましてや提案できる立場にもありません。

この問題に対処する際に最初に行うべきことは、どのユーザー アカウントがどのファイルにアクセスする必要があるかの包括的なリストを作成し (それらのファイルがどこにあるかを考慮する前に)、適切なアクセス許可モデルを作成することです。

確かに、スクリプトやコンテンツを/usrの下に置くのは適切ではない可能性が非常に高いです。

関連情報