構成フォルダーを debian サーバーに移動し、最も合理的で論理的な場所に保存しようとしています。私は家にすべてを捨てていましたが、今は次のようになります。
ソフトウェア: /opt/
Web ファイル:/var/www
ただし、ソフトウェア構成フォルダーをサーバー上の場所に移動して、適切な場所にシンボリック リンクできるようにする必要があります。これを行うのに最も適した場所は次のうちどれですか。
/home/configs
/var/cfgs
それとも別の？
これが衒学的に見える場合は申し訳ありませんが、あなたは彼らが言うことを知っています、その場所にはすべてとすべてのための場所があります;）
FHS/etcによると、ホスト固有のシステム全体の構成を配置する場所である を使用することをお勧めします。
これは、構成がサーバーアプリケーション用であることを前提としています (人間のユーザーが実行するアプリケーションではありません)。
たとえば、設定ファイルがある zope の複数のインスタンスを実行しています。
/etc/zope/instanceA/
/etc/zope/instanceB/
/etc/zope/test/
それは好みの問題です...マシンのユーザーはあなただけですか？
それでも問題ない場合は、すべてを家の下に置くことができます。
サーバーの場合は、構成ディレクトリに適切なアクセス許可があることを確認する必要があります。したがって、$HOME は適切ではありません。
もう 1 つ、Debian マシンの場合はそのまま/var/wwwにしておいてください。これは、多くの Web 関連パッケージがインストールされる場所です。物事を動かし始めた場合、後でこれらのパッケージをアップグレードするときに問題が発生する可能性があります。
ソフトウェアごとにユーザーを作成することも好みの問題です...これらのサービスユーザーはログインしないと想定しているため、$ HOMEを設定することさえ本当の目的ではありません。nologinこれらのソフトウェアが他のマシンからアクセス可能であり、誰かがこれらのユーザーを侵害するのを避けたい場合は、セキュリティ手段としてそれらを設定することさえあります.
システム全体の構成ファイルは、ユーザーのホーム ディレクトリに配置しないでください。簡単に上書きしたり、誤って変更したり、権限を不適切に変更したりします。
/etc は、複数のシステムを管理している場合に問題になります。ベスト プラクティス: コピーを別のディレクトリに保持し、必要に応じて scp を介してすべての適切なシステムにプッシュします。
また、ソース コードからインストールされたなど、システムのパッケージ マネージャーによって管理されていないパッケージがある場合も困難になります。複数のバージョンのソフトウェアを実行している場合は、さらに困難になります。
システムの数と種類、およびパッケージとバージョンの数が増えるにつれて、管理はより複雑になります。ユーザー数が少ない 1 台のマシンの場合、/etc に構成を設定しても問題ありません。
反例: fooのインストールをカスタマイズするかどうかを検討してください。これはディストリビューションが提供するパッケージですが、多少異なるバージョンが必要であるとします。
設定ファイルをデフォルトの場所にインストールすると、次のシステム アップグレードで上書きされる可能性があります。(おそらく /usr/bin 内の変更されたバージョンと一緒に)
一般的な方法の 1 つは、追加/変更するものをシステム ファイル ツリーから完全に分離しておくことです。私が実践的なシステム管理者だったとき、私はすべての特別なものを /opt に常駐させました。
/opt
/opt/bin
/opt/sbin
/opt/usr/bin
/opt/usr/sbin
/opt/man
/opt/etc
これにより、システムの邪魔にならないようになりますが、どのファイルがどのパッケージに属しているかが常に明確であるとは限りません。
多くの実行可能ファイルと man ページを含むパッケージは、独自のディレクトリを取得する場合があります。Netpbm と ImageMagic、gnu utils、perl (モジュール) が良い例です。これにより、ディレクトリ ツリーにレベルが追加されます。
/opt/misc/bin #Contained anything that was one program, one man page
/opt/netpbm_2.1/bin
/opt/imagemagick_3.2/...
/opt/gnu_1.1/...
他のすべてのディレクトリと一緒に。例: /opt/{package-version}/{bin|sbin|man|etc|var} の完全なセット
This is especially true for packages where you need to keep multiple versions. e.g.
/opt/perl4.023...
/opt/perl5.8...
大きなパッケージに対して個別のツリーを維持することで、切り替えが容易になります。不適切な変更をすばやく取り消すことができます。ほとんどの場合、ユーザーのデフォルト パスにシンボリック リンクを保持して、実際のバイナリを指すようにします。例: /usr/bin/perl -> /opt/perl5.8/bin/perl. ここでの良い習慣は、特定のバージョンへのリンクを残すことです。例 /usr/bin/perl4 -> /opt/perl4.023/bin/perl
いくつかの場所では、複数のアーキテクチャに対処する必要があります。(ある場所には 11 の UNIX バリアントがありました...) これにより、ツリーにさらに別のレベルを追加できます。
/opt/hpux/...
/opt/irix/...
/opt/sysv/...
/opt/solaris/...
通常、私は NFS ファイル共有でのみこの方法を維持し、ローカル コピーは個々のマシンに作成されました。
複雑な階層の利点は、メンテナンスが容易なことです。/opt/apache にすべてのバイナリ、man ページ、および構成ファイルが含まれている場合、lighttpd に変更する場合でも、lighttpd が apache の構成ファイルと混同されることはありません。(どちらも httpd.conf と呼ばれます)
また、パッケージを試して削除するときに、あちこちにゴミを残さないことも意味します。
一般に、アプリケーションのデータが /opt/application ツリーに存在することは望ましくありません。
欠点があります：
構成ファイルと var を /opt から分離できる場合、/opt はアップグレードを除いて読み取り専用にすることができます。これにより、バックアップが簡素化されます。
これの副作用の 1 つは、実行可能パスのメンテナンスの問題です。ユーザーの大部分が変更を認識しないように、必要なパスの変更を行うシステム全体のドット ファイル (.cshrc、.tcshrc、.bashrc) を保持します。これらのファイルは、デフォルトのドット ファイルから取得されます。