Konfigurationsdateien, die andere Dateien enthalten, sind nicht neu. Auch das Ablegen dieser enthaltenen Dateien in Unterverzeichnissen war von Anfang an eine Option. Lassen Sie uns Anwendungsfälle durchgehen und sehen, wie Sie das Beste aus dieser Organisationsmethode herausholen können.
Einige Leute halten eine einzelne Konfigurationsdatei für den "einfachen" Ansatz und einen ganzen Baum von Dateien für komplexer. Halten Sie jedoch inne und denken Sie darüber nach, wie groß einige Konfigurationsdateien werden könnten oder wie viele verschiedene Personen oder Programme sie bearbeiten müssen. Es kann wirklich einfacher sein, jedem Unterprojekt zu erlauben, seine Konfiguration in einer eigenen Datei in einem Unterverzeichnis abzulegen. Kürzlich, wie in systemd Dokumentation werden diese Dateien manchmal als "Drop-in"-Dateien bezeichnet.
Im Laufe der Zeit und insbesondere in den letzten Jahren hat sich die Verwendung von Unterverzeichnissen in /etc ist angestiegen. Zwei wichtige Situationen treiben diese Bewegung voran:
- Größere Programme haben komplexe Konfigurationsdateien in mehrere kleinere Dateien aufgeteilt.
- Viele andere Programme sind von einem einzigen Dienstprogramm abhängig geworden. Jedes dieser Dienstprogramme muss einen Teil der Konfiguration verwalten.
Pro Paket auffüllen
Einige der ersten Verwendungen von *.d Verzeichnisse, auf die ich stieß, dienten der Protokollierung und Planung. Schauen wir uns das logrotate an Nützlichkeit. Die Hauptkonfigurationsdatei ist /etc/logrotate.conf . Es ist nicht sehr kompliziert, aber jede zu drehende Datei muss angegeben werden. Jede Datei kann auch unterschiedliche Konfigurationsoptionen benötigen. Anstatt diese einzelne Datei jedes Mal zu bearbeiten, wenn eine Anwendung auf dem System hinzugefügt oder aktualisiert wird, trennen wir die Konfiguration für jede Anwendung in einer bestimmten Datei.
$ grep ^include /etc/logrotate.conf
include /etc/logrotate.d Die Hauptkonfigurationsdatei enthält alle Dateien in einem anderen Verzeichnis. Dateien im Verzeichnis können aus verschiedenen RPM-Paketen stammen.
$ 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
Der Eigentümer jeder Verpackung weiß, was gedreht werden muss und wie oft. Sie stellen eine spezifische Konfigurationsdatei für ihre Anwendung bereit und fügen sie zu logrotate.d hinzu Verzeichnis während der Installation. Es wird auch aus logrotate.d entfernt Verzeichnis, wenn das Paket vom System deinstalliert wird.
Andere Beispiele für diesen Anwendungsfall sind die Planung mit cron in der cron.d Verzeichnis- und Authentifizierungskonfiguration mit PAM in der pam.d Verzeichnis. Durch die Verwendung separater Dateien muss der Systemadministrator widersprüchliche Schreibvorgänge in eine einzelne Datei nicht verwalten.
Nach Funktion organisieren
Der Apache-Webserver ist ein umfangreiches Programm mit vielen Konfigurationsmöglichkeiten. Apache verwendet eine conf.d Verzeichnis für Organisation. Als ich mit Apache anfing, war es üblich, dass ein einzelner Server mehrere virtuelle Sites hostete. Jeder dieser virtuellen Hosts hatte seine eigene Konfigurationsdatei. Dieser Ansatz ermöglichte es uns, die Verwaltungsaufgaben der Dateien zu teilen sowie die Dateien während der Migration, Wiederherstellung und des Lastausgleichs auf verschiedenen Systemen zu teilen. Heute sehe ich mehr Fälle, in denen die Konfiguration nach Funktionen getrennt ist.
Ein weiterer Faktor ist, ob das Feature als separates Modul installiert ist.
$ rpm -qf /etc/httpd/conf.d/ssl.conf
mod_ssl-2.4.43-1.fc31.x86_64
Die ssl.conf Konfiguration wird nur verfügbar gemacht, wenn mod_ssl Paket installiert ist. Andere Module können auch Dateien in conf.d ablegen Verzeichnis. Einige Anwendungen wie mod_auth_kerb Paket, stellen Sie ein Beispiel in /usr/share/doc bereit Verzeichnis. Es obliegt dem Webadministrator, die Produktionsdateien zu erstellen oder zu verwalten.
[ Benötigen Sie weitere Hilfe beim Erlernen von Linux? Kostenloser Online-Kurs:Technischer Überblick zu Red Hat Enterprise Linux. ]
Zentralisierte Verwaltung
Wie ich bei Webkonfigurationsdateien vorgeschlagen habe, besteht eine weitere Verwendung separater Konfigurationsdateien darin, die zentrale Verwaltung dieser Dateien zu vereinfachen und nur relevante Komponenten an jeden verwalteten Knoten zu verteilen.
Die modules.d Verzeichnis enthält die Konfiguration für Kernelmoduleinstellungen und die sysctl.d Verzeichnis enthält Kernel-Tuning-Einstellungen. Diese Einstellungen sind möglicherweise nur auf einigen Systemen erforderlich oder erfordern hardwarespezifische Einstellungen. Die Einstellungen können nach Hardware, Funktion oder einer Kombination organisiert werden.
Konfigurationsverwaltungsprogramme können nur die relevanten Dateien auf bestimmte verwaltete Hosts übertragen oder die Dateien basierend auf einer Vorlage auf jedem Host generieren. Wenn Sie diese Dateien mit einer Konfigurationsverwaltungslösung wie Ansible verteilen, verwenden Sie so etwas wie ansible_managed -Variable, um einen Kommentar einzufügen, der angibt, dass die Datei remote verwaltet wird.
Legen Sie einen Namen und einen Ort fest
Während dot-d-Verzeichnisse häufige Anwendungsfälle für die Unterstützung bei der Organisation und Verteilung haben, gibt es viele verschiedene Möglichkeiten, mit den Includes umzugehen. Für jede Anwendung oder jedes Dienstprogramm müssen wir bestimmen, wie wir unsere Dateien am besten benennen. Einige Konfigurationen erkennen nur Dateien mit einer bestimmten Erweiterung, wie z. B. .conf , während andere auf alle Dateien im Verzeichnis verweisen.
Der man Seiten für die Hauptkonfigurationsdatei, wie z. B. man logrotate.conf , beschreibt normalerweise die Optionen. Trotzdem suche ich zunächst nach einer Include-Anweisung in der Konfigurationsdatei.
Wenn ich nach "includes" suche, sehe ich eine Vielzahl von Methoden (zur besseren Lesbarkeit formatiert):
$ 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")
Die ld.so und rsyslog Konfigurationen erwarten beide, dass enthaltene Dateien mit .conf enden . Die anderen sehen so aus, als ob sie alle Dateien enthalten, aber weitere Untersuchungen zeigen möglicherweise eine Methode zum Ausschließen von Dateien. Beispiel:man logrotate.conf zeigt, dass tabooext und taboopat kann verwendet werden, um .orig herauszufiltern , .bak , .rpmnew , oder andere Dateien, die aus der Versionsverwaltung oder Updates resultieren können. Für die krb5.conf Datei gibt es sowohl ein include und includedir Richtlinie. Die Manpage gibt an, dass das includedir Direktive umfasst "alle Dateien im Verzeichnis, deren Namen ausschließlich aus alphanumerischen Zeichen, Bindestrichen oder Unterstrichen bestehen." Weiter wird darauf hingewiesen, dass Dateien, die mit einem Punkt (.) beginnen, ignoriert werden.
Eine weitere Überlegung für eingeschlossene Dateien ist die Lese- und Zusammenführungsreihenfolge. Ich habe einige gesehen, die in zufälliger Reihenfolge gelesen wurden, aber die meisten enthalten Dateien in der Reihenfolge, in der sie im Verzeichnis gefunden wurden. Wenn die Reihenfolge besonders wichtig ist, z. B. bei Modulen oder Startskripten, ist es üblich, die Dateinamen mit einer Zahl zu beginnen. Andere Benennungsstandards wie „pre“ oder „post“ sind ebenfalls üblich.
$ ls /etc/NetworkManager/dispatcher.d/
04-iscsi 20-chrony no-wait.d pre-down.d pre-up.d
Einige Dienstprogramme haben möglicherweise sogar Erweiterungssymbole, die bei der Verwaltung und Verteilung zentralisierter Dateien helfen. Die sudoers Konfiguration ist ein Beispiel, bei dem ein %h steht für die Kurzform des Hostnamens.
include /etc/sudoers.d/sudoers.%h
Die obige Include-Zeile gibt die Konfigurationsdatei für den aktuellen Host an, auch wenn das Verzeichnis andere Dateien enthält. Siehe man sudoers für weitere Beispiele.
Dateien überprüfen
Eine weitere Gefahr bei der Verwendung von Punkt-d-Verzeichnissen besteht darin, dass Sie möglicherweise Ihre Befehle zur Syntaxprüfung ändern müssen.
In einigen Fällen müssen alle Konfigurationsdateien auf einmal überprüft werden. Bei Apache beispielsweise der apachectl configtest überprüft immer die Hauptkonfigurationsdatei, die andere Dateien enthalten kann. Es verwendet Standardoptionen. Sie können httpd -t ausführen Befehl mit zusätzlichen Optionen. Beispielsweise gibt es eine Option, um alle enthaltenen Dateien aufzulisten.
$ 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
Der httpd Befehl akzeptiert auch ein -f Option, um eine bestimmte Datei anzugeben. Diese Datei muss jedoch alle Konfigurationsprüfungen bestehen, sodass die Überprüfung einer enthaltenen Datei möglicherweise nicht die gewünschten Ergebnisse liefert. Der folgende Fehler tritt auf, wenn die standardmäßige ssl.conf überprüft wird Konfigurationsdatei, die von mod_ssl bereitgestellt wird Paket.
$ httpd -t -f /etc/httpd/conf.d/ssl.conf
AH00534: httpd: Configuration error: No MPM loaded.
Andere Anwendungen verfügen über Methoden zum Überprüfen der Syntax für eine enthaltene Datei. Das sudo Die Konfiguration wird normalerweise mit visudo geändert Befehl, damit vor dem Speichern und Beenden eine Syntaxprüfung durchgeführt werden kann. Dieses Dienstprogramm bearbeitet die Datei /etc/sudoers Datei standardmäßig, unterstützt aber auch ein -f Option, um eine andere Datei anzugeben.
$ 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
Derselbe Befehl unterstützt auch ein --check Option, um eine Datei nur ohne Bearbeitung zu validieren.
$ visudo -c demo.sudo
>>> demo.sudo: syntax error near line 1 <<<
parse error in demo.sudo near line 1
Kombinieren Sie dies mit einer Validierungsoption in Ihrem Konfigurationsverwaltungsprogramm, um sicherzustellen, dass Vorlagenerweiterungen eine Konfigurationsdatei nicht beschädigen. In der Dokumentation finden Sie Beispiele für die Module Copy und Template von Ansible. Ich habe auch das folgende Beispiel aus der ansible-doc template bereitgestellt für 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 Ein wenig Stöbern in kommentierten Zeilen und Handbuchseiten wird Ihnen helfen, das Beste aus dieser Organisationsmethode herauszuholen, indem Sie Verteilungsoptionen, Namenskonventionen und Informationen zur Syntaxüberprüfung anzeigen.
Schluß
Das Organisieren von Konfigurationsdateien in Verzeichnissen kann die Verwaltung und Delegierung der Verwaltung vereinfachen. Dateien können nach Paket oder Funktion organisiert werden, und Konfigurationsmanagementlösungen wie Ansible können sogar von kleineren Vorlagendateien profitieren. Möglicherweise müssen Sie Dateinamen und Speicherorte standardisieren und Dateiüberprüfungstools aktualisieren, aber die Verwendung eines Punkt-d-Ordners zum Speichern mehrerer Konfigurationsdateien kann Ihnen viel Aufwand ersparen.
[ Möchten Sie Red Hat Enterprise Linux ausprobieren? Laden Sie es jetzt kostenlos herunter. ]