Les fichiers de configuration, qui incluent d'autres fichiers, ne sont pas nouveaux. Placer ces fichiers inclus dans des sous-répertoires est également une option depuis le début. Passons en revue les cas d'utilisation et voyons comment tirer le meilleur parti de cette méthode d'organisation.
Certaines personnes trouvent qu'un seul fichier de configuration est l'approche "simple" et qu'un arbre entier de fichiers est plus complexe. Cependant, arrêtez-vous et réfléchissez à la taille de certains fichiers de configuration ou au nombre de personnes ou de programmes différents qui doivent les modifier. Il peut vraiment être plus simple d'autoriser chaque sous-projet à déposer sa configuration dans son propre fichier dans un sous-répertoire. Récemment, comme dans systemd documentation, ces fichiers sont parfois appelés fichiers "drop-in".
Au fil du temps, et surtout ces dernières années, l'utilisation de sous-répertoires dans /etc a augmenté. Deux situations importantes sont à l'origine de ce mouvement :
- Les programmes plus importants ont divisé les fichiers de configuration complexes en plusieurs fichiers plus petits.
- De nombreux autres programmes sont devenus dépendants d'un seul utilitaire. Chacun de ces utilitaires doit gérer une partie de la configuration.
Remplir par paquet
Certaines des premières utilisations de *.d les répertoires que j'ai rencontrés étaient destinés à la journalisation et à la planification. Regardons le logrotate utilitaire. Le fichier de configuration principal est /etc/logrotate.conf . Ce n'est pas très compliqué, mais chaque fichier à faire pivoter doit être spécifié. Chaque fichier peut également nécessiter des options de configuration différentes. Au lieu de modifier ce fichier unique chaque fois qu'une application est ajoutée ou mise à jour sur le système, nous séparons la configuration de chaque application dans un fichier spécifique.
$ grep ^include /etc/logrotate.conf
include /etc/logrotate.d Le fichier de configuration principal inclut tous les fichiers d'un autre répertoire. Les fichiers du répertoire peuvent provenir de différents packages 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
Le propriétaire de chaque paquet sait ce qui doit être changé et à quelle fréquence. Ils fournissent un fichier de configuration spécifique à leur application et l'ajoutent à logrotate.d répertoire lors de l'installation. Il est également supprimé de logrotate.d répertoire lorsque le package est désinstallé du système.
D'autres exemples de ce cas d'utilisation sont la planification avec cron dans le cron.d configuration du répertoire et de l'authentification avec PAM dans le pam.d annuaire. En utilisant des fichiers séparés, l'administrateur système n'a pas besoin de gérer les écritures conflictuelles dans un seul fichier.
Organiser par fonction
Le serveur Web Apache est un programme complet avec de nombreuses options de configuration. Apache utilise un conf.d répertoire pour l'organisation. Lorsque j'ai commencé avec Apache, il était courant d'avoir un seul serveur hébergeant plusieurs sites virtuels. Chacun de ces hôtes virtuels avait son propre fichier de configuration. Cette approche nous a permis de partager les tâches d'administration des fichiers ainsi que de partager les fichiers sur différents systèmes lors de la migration, de la récupération et de l'équilibrage de charge. Aujourd'hui, je vois plus de cas où la configuration est séparée par fonction.
Un autre facteur est si la fonctionnalité est installée en tant que module séparé.
$ rpm -qf /etc/httpd/conf.d/ssl.conf
mod_ssl-2.4.43-1.fc31.x86_64
Le ssl.conf la configuration n'est disponible que lorsque le mod_ssl le paquet est installé. D'autres modules peuvent également déposer des fichiers dans le conf.d annuaire. Certaines applications, comme le mod_auth_kerb package, fournissez un exemple dans un /usr/share/doc annuaire. Il appartient à l'administrateur Web de créer ou de gérer les fichiers de production.
[ Besoin d'aide supplémentaire pour apprendre Linux ? Cours en ligne gratuit :Présentation technique de Red Hat Enterprise Linux. ]
Gestion centralisée
Comme je l'ai suggéré avec les fichiers de configuration Web, une autre utilisation des fichiers de configuration distincts consiste à faciliter la gestion centralisée de ces fichiers et à ne distribuer que les composants pertinents à chaque nœud géré.
Les modules.d Le répertoire contient la configuration des paramètres du module du noyau et le sysctl.d contient les paramètres de réglage du noyau. Ces paramètres peuvent n'être nécessaires que sur certains systèmes ou peuvent nécessiter des paramètres spécifiques au matériel. Les paramètres peuvent être organisés par matériel, fonction ou une combinaison.
Les programmes de gestion de la configuration peuvent transférer uniquement les fichiers pertinents vers des hôtes gérés spécifiques ou générer les fichiers sur chaque hôte en fonction d'un modèle. Si vous distribuez ces fichiers avec une solution de gestion de configuration telle qu'Ansible, utilisez quelque chose comme ansible_managed variable pour inclure un commentaire indiquant que le fichier est géré à distance.
Déterminez un nom et un lieu
Bien que les répertoires point-d aient des cas d'utilisation courants pour aider à l'organisation et à la distribution, il existe de nombreuses façons différentes de gérer les inclusions. Pour chaque application ou utilitaire, nous devons déterminer comment nommer au mieux nos fichiers. Certaines configurations ne reconnaissent que les fichiers avec une extension spécifique, comme .conf , tandis que d'autres font référence à tous les fichiers du répertoire.
L'man pages pour le fichier de configuration principal, comme man logrotate.conf , décrit généralement les options. Pourtant, je commence par chercher une instruction include dans le fichier de configuration.
Lorsque je recherche des inclusions, je vois une variété de méthodes (formatées pour la lisibilité) :
$ 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")
Le ld.so et rsyslog les configurations s'attendent toutes deux à ce que les fichiers inclus se terminent par .conf . Les autres semblent inclure tous les fichiers, mais une enquête plus approfondie peut montrer une méthode pour exclure des fichiers. Par exemple, man logrotate.conf montre que tabooext et taboopat peut être utilisé pour filtrer .orig , .bak , .rpmnew , ou d'autres fichiers pouvant résulter de la gestion des versions ou des mises à jour. Pour le krb5.conf fichier, il y a à la fois un include et includedir directif. La page de manuel indique que le includedir couvre "tous les fichiers du répertoire dont les noms se composent uniquement de caractères alphanumériques, de tirets ou de traits de soulignement". Il précise ensuite que les fichiers commençant par un point (.) sont ignorés.
Une autre considération pour les fichiers inclus est l'ordre de lecture et de fusion. J'en ai vu quelques-uns qui se lisent dans un ordre aléatoire, mais la plupart incluent les fichiers dans l'ordre dans lequel ils se trouvent dans le répertoire. Si la séquence est particulièrement importante, comme pour les modules ou les scripts de démarrage, il est courant de commencer les noms de fichiers par un nombre. D'autres normes de nommage telles que "pré" ou "post" sont également courantes.
$ ls /etc/NetworkManager/dispatcher.d/
04-iscsi 20-chrony no-wait.d pre-down.d pre-up.d
Quelques utilitaires peuvent même avoir des symboles d'extension qui aident à gérer et à distribuer des fichiers centralisés. Les sudoers configuration est un exemple où un %h représente la forme abrégée du nom d'hôte.
include /etc/sudoers.d/sudoers.%h
La ligne d'inclusion ci-dessus spécifie le fichier de configuration de l'hôte actuel, même si le répertoire contient d'autres fichiers. Voir man sudoers pour plus d'exemples.
Vérifier les fichiers
Un autre danger lié à l'utilisation des répertoires point-d est que vous devrez peut-être modifier vos commandes de vérification de la syntaxe.
Dans certains cas, tous les fichiers de configuration doivent être vérifiés en même temps. Par exemple, avec Apache, le apachectl configtest La commande vérifie toujours le fichier de configuration principal, qui peut inclure d'autres fichiers. Il utilise les options par défaut. Vous pouvez exécuter le httpd -t commande avec des options supplémentaires. Par exemple, il existe une option pour lister tous les fichiers inclus.
$ 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
Le httpd la commande prend également un -f option pour spécifier un fichier particulier. Cependant, ce fichier doit passer toutes les vérifications de configuration, donc la vérification d'un fichier inclus peut ne pas donner les résultats souhaités. L'erreur suivante se produit lors de la vérification du ssl.conf par défaut fichier de configuration fourni par le mod_ssl paquet.
$ httpd -t -f /etc/httpd/conf.d/ssl.conf
AH00534: httpd: Configuration error: No MPM loaded.
D'autres applications ont des méthodes de vérification de la syntaxe d'un fichier inclus. Le sudo la configuration est normalement modifiée en utilisant le visudo commande afin qu'une validation de la syntaxe puisse être effectuée avant d'enregistrer et de quitter. Cet utilitaire édite le /etc/sudoers fichier par défaut mais prend également en charge un -f option pour spécifier un fichier différent.
$ 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
La même commande prend également en charge un --check option pour valider uniquement un fichier sans modification.
$ visudo -c demo.sudo
>>> demo.sudo: syntax error near line 1 <<<
parse error in demo.sudo near line 1
Combinez cela avec une option de validation dans votre programme de gestion de configuration pour vous assurer que les extensions de modèle ne cassent pas un fichier de configuration. Il existe des exemples dans la documentation pour les modules de copie et de modèle Ansible. J'ai également fourni l'exemple suivant de ansible-doc template pour 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 Un peu de recherche dans les lignes commentées et les pages de manuel vous aidera à tirer le meilleur parti de cette méthode d'organisation en affichant les options de distribution, les conventions de dénomination et les informations de validation de la syntaxe.
Conclusion
L'organisation des fichiers de configuration dans des répertoires peut faciliter la gestion et la délégation de l'administration. Les fichiers peuvent être organisés par package ou par fonction et les solutions de gestion de configuration telles qu'Ansible peuvent même bénéficier de fichiers modèles plus petits. Vous devrez peut-être normaliser les noms et les emplacements des fichiers, et vous devrez peut-être mettre à jour les outils de vérification des fichiers, mais l'utilisation d'un dossier point d pour héberger plusieurs fichiers de configuration peut vous faire économiser beaucoup d'efforts.
[ Voulez-vous essayer Red Hat Enterprise Linux ? Télécharge le maintenant gratuitement. ]