他のファイルを含む構成ファイルは新しいものではありません。これらのインクルードされたファイルをサブディレクトリに配置することも、最初からオプションでした。ユースケースを確認し、この編成方法を最大限に活用する方法を見てみましょう。
一部の人々は、単一の構成ファイルが「単純な」アプローチであり、ファイルのツリー全体がより複雑であると感じています。ただし、一部の構成ファイルがどれだけ大きくなる可能性があるか、またはそれらを編集する必要があるさまざまな人やプログラムの数について考えてみてください。各サブプロジェクトが構成をサブディレクトリ内の独自のファイルにドロップできるようにする方が、実際には簡単です。最近、systemd
など ドキュメントでは、これらのファイルは「ドロップイン」ファイルと呼ばれることもあります。
時間の経過とともに、特に過去数年間で、/etc
でのサブディレクトリの使用 増加しています。この動きを推進している2つの重要な状況:
- より大きなプログラムでは、複雑な構成ファイルが複数のより小さなファイルに分割されています。
- 他の多くのプログラムが単一のユーティリティに依存するようになりました。これらの各ユーティリティは、構成の一部を管理する必要があります。

パッケージごとに入力
*.d
の最初の使用法のいくつか 私が遭遇したディレクトリは、ロギングとスケジューリング用でした。 logrotate
を見てみましょう 効用。メインの構成ファイルは/etc/logrotate.conf
です。 。それほど複雑ではありませんが、ローテーションする各ファイルを指定する必要があります。各ファイルには、異なる構成オプションが必要な場合もあります。システムでアプリケーションが追加または更新されるたびにこの単一のファイルを編集する代わりに、各アプリケーションの構成を特定のファイルに分割します。
$ grep ^include /etc/logrotate.conf
include /etc/logrotate.d
メイン構成ファイルには、別のディレクトリにあるすべてのファイルが含まれます。ディレクトリ内のファイルは、異なるRPMパッケージからのものである可能性があります。
$ rpm -qf /etc/logrotate.d/aide
aide-0.16-12.fc31.x86_64
$rpm -qf /etc/logrotate.d/rsyslog
rsyslog-8.2002.0-1.fc31.x86_64
$ rpm -qf /etc/logrotate.d/chrony
chrony-3.5-4.fc31.x86_64
各パッケージの所有者は、何をローテーションする必要があり、どのくらいの頻度でローテーションする必要があるかを知っています。アプリケーションに固有の構成ファイルを提供し、それをlogrotate.d
に追加します。 インストール中のディレクトリ。 logrotate.d
からも削除されます パッケージがシステムからアンインストールされたときのディレクトリ。
このユースケースの他の例は、cron
を使用したスケジューリングです。 cron.d
内 pam.d
内のPAMを使用したディレクトリと認証の構成 ディレクトリ。個別のファイルを使用することで、システム管理者は単一のファイルへの競合する書き込みを管理する必要がなくなります。
機能別に整理
Apacheウェブサーバーは、多くの設定オプションを備えた広範なプログラムです。 Apacheはconf.d
を利用します 組織のディレクトリ。 Apacheを使い始めたとき、単一のサーバーで複数の仮想サイトをホストするのが一般的でした。これらの各仮想ホストには、独自の構成ファイルがありました。このアプローチにより、ファイルの管理業務を共有できるだけでなく、移行、リカバリ、および負荷分散中にさまざまなシステムでファイルを共有することができました。今日、構成が機能によって分離されているケースが増えています。
もう1つの要因は、機能が別のモジュールとしてインストールされているかどうかです。
$ rpm -qf /etc/httpd/conf.d/ssl.conf
mod_ssl-2.4.43-1.fc31.x86_64
ssl.conf
構成は、mod_ssl
の場合にのみ使用可能になります パッケージがインストールされます。他のモジュールもファイルをconf.d
にドロップする場合があります ディレクトリ。 mod_auth_kerb
などの一部のアプリケーション パッケージ、/usr/share/doc
でサンプルを提供します ディレクトリ。本番ファイルを作成または管理するのはウェブ管理者の責任です。
[Linuxの学習についてさらにサポートが必要ですか?無料のオンラインコース:Red HatEnterpriseLinuxの技術概要。 ]
一元管理
Web構成ファイルで提案したように、個別の構成ファイルの別の使用法は、これらのファイルの集中管理を容易にし、関連するコンポーネントのみを各管理対象ノードに配布することです。
modules.d
ディレクトリは、カーネルモジュール設定とsysctl.d
の構成を保持します ディレクトリには、カーネルチューニング設定が含まれています。これらの設定は、一部のシステムでのみ必要な場合や、ハードウェア固有の設定が必要な場合があります。設定は、ハードウェア、機能、または組み合わせによって整理できます。
構成管理プログラムは、関連するファイルだけを特定の管理対象ホストにプッシュしたり、テンプレートに基づいて各ホストでファイルを生成したりできます。これらのファイルをAnsibleなどの構成管理ソリューションで配布する場合は、ansible_managed
のようなものを使用してください。 ファイルがリモートで管理されていることを示すコメントを含める変数。
名前と場所を決定する
dot-dディレクトリには、編成と配布を支援するための一般的なユースケースがありますが、インクルードを処理する方法は多数あります。アプリケーションまたはユーティリティごとに、ファイルに最適な名前を付ける方法を決定する必要があります。一部の構成では、.conf
などの特定の拡張子を持つファイルのみが認識されます。 、他の人はディレクトリ内のすべてのファイルを参照します。
man
man logrotate.conf
などのメイン構成ファイルのページ 、通常はオプションについて説明します。それでも、構成ファイルでincludeステートメントを探すことから始めます。
インクルードを検索すると、さまざまな方法が表示されます(読みやすくするためにフォーマットされています):
$ grep ^include /etc/*conf
krb5.conf : includedir /etc/krb5.conf.d/
ld.so.conf : include ld.so.conf.d/*.conf
logrotate.conf : include /etc/logrotate.d
rsyslog.conf : include(file="/etc/rsyslog.d/*.conf" mode="optional")
ld.so
およびrsyslog
どちらの構成でも、含まれるファイルは.conf
で終わる必要があります 。その他はすべてのファイルが含まれているように見えますが、さらに調査すると、ファイルを除外する方法が示される可能性があります。たとえば、man logrotate.conf
tabooext
およびtaboopat
.orig
を除外するために使用できます 、.bak
、.rpmnew
、またはバージョン管理や更新の結果として生じる可能性のあるその他のファイル。 krb5.conf
の場合 ファイルには、include
の両方があります およびincludedir
指令。マニュアルページには、includedir
が示されています ディレクティブは、「名前が英数字、ダッシュ、またはアンダースコアのみで構成されているディレクトリ内のすべてのファイル」を対象としています。さらに、ドット(。)で始まるファイルは無視されることを指摘します。
インクルードファイルに関するもう1つの考慮事項は、読み取りとマージの順序です。ランダムな順序で読み取るものをいくつか見ましたが、ほとんどの場合、ディレクトリにある順序でファイルが含まれています。モジュールや起動スクリプトなど、シーケンスが特に重要な場合は、ファイル名を数字で始めるのが一般的です。 「pre」や「post」などの他の命名基準も一般的です。
$ ls /etc/NetworkManager/dispatcher.d/
04-iscsi 20-chrony no-wait.d pre-down.d pre-up.d
一部のユーティリティには、一元化されたファイルの管理と配布に役立つ拡張シンボルが含まれている場合もあります。 sudoers
構成は、%h
の例です。 ホスト名の短縮形を表します。
include /etc/sudoers.d/sudoers.%h
上記のインクルード行は、ディレクトリに他のファイルが含まれている場合でも、現在のホストの構成ファイルを指定します。 man sudoers
を参照してください その他の例については。
ファイルを確認する
dot-dディレクトリを使用することのもう1つの危険は、構文チェックコマンドを変更しなければならない可能性があることです。
場合によっては、すべての構成ファイルを一度にチェックする必要があります。たとえば、Apacheの場合、apachectl configtest
コマンドは常にメイン設定ファイルをチェックします。メイン設定ファイルには他のファイルを含めることができます。デフォルトのオプションを使用します。 httpd -t
を実行できます 追加オプション付きのコマンド。たとえば、含まれているすべてのファイルを一覧表示するオプションがあります。
$ httpd -t -D DUMP_INCLUDES
Included configuration files:
(*) /etc/httpd/conf/httpd.conf
(59) /etc/httpd/conf.modules.d/00-base.conf
(59) /etc/httpd/conf.modules.d/00-dav.conf
httpd
コマンドも-f
を取ります 特定のファイルを指定するオプション。ただし、そのファイルはすべての構成チェックに合格する必要があるため、含まれているファイルをチェックしても、望ましい結果が得られない場合があります。デフォルトのssl.conf
をチェックすると、次のエラーが発生します mod_ssl
によって提供される構成ファイル パッケージ。
$ httpd -t -f /etc/httpd/conf.d/ssl.conf
AH00534: httpd: Configuration error: No MPM loaded.
他のアプリケーションには、インクルードされたファイルの構文を検証するメソッドがあります。 sudo
構成は通常、visudo
を使用して変更されます 保存して終了する前に構文検証を実行できるようにするコマンド。このユーティリティは、/etc/sudoers
を編集します デフォルトではファイルですが、-f
もサポートしています 別のファイルを指定するオプション。
$ sudo visudo -f /etc/sudoers.d/demo
>>> /etc/sudoers.d/demo: syntax error near line 1 <<<
What now? q
Options are:
(e)dit sudoers file again
e(x)it without saving changes to sudoers file
(Q)uit and save changes to sudoers file (DANGER!)
What now? x
同じコマンドは、--check
もサポートします 編集せずにファイルのみを検証するオプション。
$ visudo -c demo.sudo
>>> demo.sudo: syntax error near line 1 <<<
parse error in demo.sudo near line 1
これを構成管理プログラムの検証オプションと組み合わせて、テンプレートの拡張によって構成ファイルが破損しないようにします。ドキュメントには、Ansibleコピーおよびテンプレートモジュールのサンプルがあります。 ansible-doc template
から次の例も提供しました sshd
の場合 :
- name: Update sshd configuration safely, avoid locking yourself out
template:
src: etc/ssh/sshd_config.j2
dest: /etc/ssh/sshd_config
owner: root
group: root
mode: '0600'
validate: /usr/sbin/sshd -t -f %s
backup: yes
コメント行とマニュアルページを少し掘り下げると、配布オプション、命名規則、構文検証情報を表示することで、この編成方法を最大限に活用するのに役立ちます。
まとめ
構成ファイルをディレクトリーに編成すると、管理の管理と委任が容易になります。ファイルはパッケージまたは機能ごとに整理でき、Ansibleなどの構成管理ソリューションは小さなテンプレートファイルの恩恵を受けることもできます。ファイル名と場所を標準化する必要がある場合や、ファイル検証ツールを更新する必要がある場合がありますが、ドットdフォルダーを使用して複数の構成ファイルを格納すると、多くの労力を節約できます。
[Red Hat Enterprise Linuxを試してみませんか?今すぐ無料でダウンロードしてください。 ]