問題タブ [fhs]

というプログラムがあるとしfooます。

絶対パスを使用する場合:

そしてfoo$ python setup.py --prefix=/usr/local、私たちは持ってい/etc/foo.cfgます。しかし、 FHS/usr/local/etc/foo.cfgによると、代わりに持つべきです。

相対パスを使用するとどうなりますか?

次に、デフォルトのインストール パス、つまり /usr へのインストールを使用すると、/usr/etc/foo.cfg. また不運。

では、それを正しく行う方法は？

PS 問題が複雑になるのを避けるため、このプログラム fooは非 UNIX 環境では実行できないと想定しています。

必要なものはすべて/binに入れることができるようですが、なぜ/ usr/binディレクトリを気にする必要があるのでしょうか。

Unix ドメイン ソケットへのエンド ポイントを表す「ファイル」を配置する規則はありますか?

に置きがち/tmp/some-application-specific-subdir-name/ですが、もっと一般的な場所があるのではないでしょうか。

背景は、そのような「ファイル」にアクセスするための最大パス長についてPOSIXが明確ではないということです。

sun_path のサイズは、意図的に未定義のままになっています。これは、異なる実装が異なるサイズを使用するためです。たとえば、4.3 BSD はサイズ 108 を使用し、4.4 BSD はサイズ 104 を使用します。ほとんどの実装は BSD バージョンに由来するため、サイズは通常 92 から 108 の範囲です。

アプリケーションは、sun_path に特定の長さを想定したり、{_POSIX_PATH_MAX} バイト (256) を保持できると想定したりしないでください。

したがって、パスの長さに関するこの「制限」は、アプリケーションのファイル/パス名の構成から除外する必要があります。

HTML コンテンツを生成するために特定のファイルを必要とする LAMP サーバーで PHP スクリプトを実行しています。スクリプトは誰でもアクセスできますhttp://example.com/script.phpが (つまり )、スクリプトに必要なファイルは保護する必要があります。ファイルはおそらく 以外のディレクトリに配置でき、比較的安全ですが、Linux ファイルシステムを学習しようとしており、最も適切な/var/www場所を使用したいと考えています(FHS によると)。どんな助けでも素晴らしいでしょう。

$HOME/src私のホームディレクトリには、通常、FHSに少し触発されたソースコード（解凍されたtarボールまたはGit / Subversion作業コピーとして）を保存します。裸のGitリポジトリをそれらから分離したい。

ベアGitリポジトリをホームディレクトリに保存する規則はありますか？

Linux Filesystem Standard Hierarchy（FHS）に従って現在インストールされているPythonアプリケーションがあります。それはにインストールされています：

• / usr / bin /（実行可能）
• /usr/lib/python2.x/site-packages/ {appname} /（Python libs）
• / etc / {appname} /（confファイル）
• / usr / share / man /（手動ファイル）

ここで、このアプリケーションをインストールする非rootユーザーが、root権限なしでアプリをインストールでき、このユーザーのみがアプリを実行できることが望まれます。ユーザーのホームディレクトリにアプリをインストールするのが最善だと考えました。アプリがに構成ファイルをインストールしたので、ユーザーごとの構成ファイルを保持するため
のディレクトリがユーザーホームにすでにあります。ディレクトリに。が事前に追加されているため 、dirを使用してすべてのアプリケーションファイルを保持することはお勧めできません。構成ファイルのみを保持します。アプリケーション全体がユーザーごとにインストールされるため、おそらくディレクトリを削除します。.{appname}/etc
.{appname}.{appname}

2つのアイデア：

• dirを作成{appname}し、subdirs binなど、libおよびshare/manを作成します。
• Linux FHSをホームで複製し、{app-name}libなどの下 にサブディレクトリを作成します
  • 〜/ bin /
  • 〜/ lib / {appname}
  • 〜/ share / man /
  • 〜/ etc / {appname}

これらのうち、より頻繁に使用され、より推奨されるのはどれですか？それぞれの選択肢の長所と短所は大歓迎です。多分3番目のオプション？

私は人々が推奨/home/usr/binしているのを見てきましたが、必須と非必須のバイナリ/ライブラリを区別する必要がないため/home/usr/local/bin、ここに含める必要があることを理解していません。usrミニマリストになりたいです。

前もって感謝します。

実行時に生成されるすべてのプロセスと対話するために、多くの UNIX ソケットを作成するアプリケーションがあります。/run/appname は、アプリの実行時にのみ有効なアプリからの情報に使用する必要があることを理解しているため、/run/appname は彼らが住むのに適した場所だと思いました。

しかし、私が発見したのは

では、なぜ通常のユーザーは /run にファイルを作成できないのでしょうか? それは何のために使用されますか？/tmp のままにしておくべきですか?

タイトルが尋ねるように、Linux FHS に従って、Linux オペレーティング システム上で Python 仮想環境を保存するための技術的に適切な場所はどこですか?

明確な答えを可能にする別の方法を述べます:Python仮想環境の場所を提供しているデータファイルから分離することは「技術的に正しい」ですか?

注:仮想環境にはライブラリ、バイナリ、ヘッダー ファイル、およびスクリプトが含まれているため、この質問は、私が見つけることができる最も近い、既に尋ねられた質問とは異なります。

さらに厄介なことに、私はインターネットでアクセスできるサービスをサポートするコードを書く傾向があります。ただし、これは、サービスの消費者が同じサーバー上の他のプロセスであるシナリオと私のニーズを大幅に区別するものではないと思います。コメントへの応答に「web dev」風のコンテンツが含まれている場合に備えて、この詳細について言及しています。

参考までに、Linux FHS の定義として次のドキュメントを使用しています: http://www.pathname.com/fhs/pub/fhs-2.3.html

人気のある virtualenv-wrapper スクリプトが正しいアクションを示唆しているとは思えません。デフォルトでは、ユーザーのホーム ディレクトリに仮想環境を保存するためです。これは、ディレクトリがユーザー固有のファイル用であるという暗黙の概念、および「プログラムはこの場所に依存してはならない」という声明に違反しています。

/usrファイル システムのルート レベルから、 (共有可能で読み取り専用のデータ) または/srv(このシステムが提供するサービスのデータ)に傾いていますが、これをさらに決定するのに苦労しています。

頼りになるリバース プロキシの決定に私が従うとしたら、それは/usr. Nginx は通常、/usr/share/nginx または /usr/local/nginx に配置されるようにパッケージ化されていますが、FHS によると、/usr/ は読み取り専用でマウントされることになっています。開発が非常にゆっくりと行われた単一のプロジェクトに取り組んだことがなく、「読み取り専用としてアンマウント/書き込みで再マウント、アンマウント/読み取り専用として再マウント」が努力する価値があると見なされたため、これは奇妙です。

/srvは別の可能な場所ですが、「特定のサービスのデータ ファイルの場所」として示されていますが、Python 仮想環境は、サービスを提供するライブラリとバイナリに重点を置いています (この区別がなければ、.soファイルも srv にあります)。 . また、同じ要件を持つ複数のサービスが仮想環境を共有する可能性があり、これは説明の「特定の」詳細に違反します。

正しい場所を選択するのが難しいのは、仮想環境が「環境」であり、バイナリとライブラリの両方で構成されているためだと思います (ほとんどそれ自体の小さな階層のようなものです) /usr。

私の仮定と考えを述べて、Nginx が Python アプリケーションのリバース プロキシとして機能する一般的なシナリオを考えてみましょう。仮想環境とソース コード (application.py など) を、より頻繁に変更されるファイル (「静的」アセット、画像、css など) に/usr/local/service_name/使用する場合に配置するのは正しいですか?/srv

編集：明確にするために：virtualenvを使用する理由と方法を知っています。プロジェクトのレイアウトや開発環境での作業について、私は決して混乱していません。