Le .dsignifie répertoire. C'est une convention pour distinguer la configuration basée sur l'annuaire d'une configuration basée sur un seul fichier de configuration. Souvent, vous aurez les deux à la fois, par exemple /etc/logrotate.confet /etc/logrotate.d/.
Il arrive aussi généralement que tous les fichiers (de nom raisonnable) dans un tel répertoire soient automatiquement combinés en une seule configuration. Les packages peuvent ensuite installer des fichiers dans un répertoire comme celui-ci, et ils seront utilisés automatiquement. Encore /etc/logrotate.d/une fois, c'est un bon exemple. Par contraste, un répertoire de fichiers de configuration qui ne se termine pas .dcontient probablement simplement un classement aléatoire des fichiers de configuration appartenant au même package, et vous ne pouvez rien déduire de la façon dont ils sont traités, par exemple /etc/zsh/.
Pour développer un peu la réponse de Peter, ce modèle .d permet l'ajout et la suppression plus simples des fichiers de configuration: pour un programme .d donné, l'administrateur a la possibilité de simplement copier ou supprimer un fichier dans le répertoire .d sans avoir à modifier un fichier de configuration existant.
Par exemple, si vous souhaitez ajouter un travail cron à votre système, vous pouvez éditer / etc / crontab avec votre nouveau travail planifié en utilisant votre éditeur de texte préféré. C'est bien pour un seul serveur ou une poignée de serveurs, mais essayez de le faire sur 100 serveurs si vous travaillez dans un environnement de centre de données / cloud. Dans ce dernier cas, vous pouvez utiliser quelque chose comme sed avec un fichier temporaire ou un outil comme ex pour écrire le fichier en place, mais il y a un peu de risque ici si vous n'avez pas conçu votre commande correctement. En effet, j'ai vu des fichiers de configuration complètement supprimés en raison d'une faute de frappe dans ces commandes d'édition.
Comparez maintenant cela au placement d'un fichier avec vos tâches planifiées dans /etc/cron.d. Il vous suffit de copier le fichier dedans, et la prochaine fois que cron s'exécute (généralement toutes les minutes), il verra le nouveau fichier et le source / le traitera en conséquence. C'est très bien comme Peter le dit si vous souhaitez rouler vos propres paquets: le fichier /etc/cron.d est juste un autre fichier dans l'archive des paquets qui est installé. Lors de la suppression du package, le fichier cron.d est supprimé et votre cron ne s'exécute plus.
Enfin, chaque programme qui possède un répertoire .d peut avoir sa propre implémentation en ce qui concerne la source des fichiers, comme inclure l'ordre et la configuration. Donc, chaque fois que vous décidez de placer un fichier dans un répertoire .d, vérifiez toujours qu'il fait ce que vous voulez et ne présumez pas simplement qu'il fonctionne comme il le fait pour un autre programme qui a un répertoire .d.
Réponses:
Le
.dsignifie répertoire. C'est une convention pour distinguer la configuration basée sur l'annuaire d'une configuration basée sur un seul fichier de configuration. Souvent, vous aurez les deux à la fois, par exemple/etc/logrotate.confet/etc/logrotate.d/.Il arrive aussi généralement que tous les fichiers (de nom raisonnable) dans un tel répertoire soient automatiquement combinés en une seule configuration. Les packages peuvent ensuite installer des fichiers dans un répertoire comme celui-ci, et ils seront utilisés automatiquement. Encore
/etc/logrotate.d/une fois, c'est un bon exemple. Par contraste, un répertoire de fichiers de configuration qui ne se termine pas.dcontient probablement simplement un classement aléatoire des fichiers de configuration appartenant au même package, et vous ne pouvez rien déduire de la façon dont ils sont traités, par exemple/etc/zsh/.la source
Pour développer un peu la réponse de Peter, ce modèle .d permet l'ajout et la suppression plus simples des fichiers de configuration: pour un programme .d donné, l'administrateur a la possibilité de simplement copier ou supprimer un fichier dans le répertoire .d sans avoir à modifier un fichier de configuration existant.
Par exemple, si vous souhaitez ajouter un travail cron à votre système, vous pouvez éditer / etc / crontab avec votre nouveau travail planifié en utilisant votre éditeur de texte préféré. C'est bien pour un seul serveur ou une poignée de serveurs, mais essayez de le faire sur 100 serveurs si vous travaillez dans un environnement de centre de données / cloud. Dans ce dernier cas, vous pouvez utiliser quelque chose comme sed avec un fichier temporaire ou un outil comme ex pour écrire le fichier en place, mais il y a un peu de risque ici si vous n'avez pas conçu votre commande correctement. En effet, j'ai vu des fichiers de configuration complètement supprimés en raison d'une faute de frappe dans ces commandes d'édition.
Comparez maintenant cela au placement d'un fichier avec vos tâches planifiées dans /etc/cron.d. Il vous suffit de copier le fichier dedans, et la prochaine fois que cron s'exécute (généralement toutes les minutes), il verra le nouveau fichier et le source / le traitera en conséquence. C'est très bien comme Peter le dit si vous souhaitez rouler vos propres paquets: le fichier /etc/cron.d est juste un autre fichier dans l'archive des paquets qui est installé. Lors de la suppression du package, le fichier cron.d est supprimé et votre cron ne s'exécute plus.
Enfin, chaque programme qui possède un répertoire .d peut avoir sa propre implémentation en ce qui concerne la source des fichiers, comme inclure l'ordre et la configuration. Donc, chaque fois que vous décidez de placer un fichier dans un répertoire .d, vérifiez toujours qu'il fait ce que vous voulez et ne présumez pas simplement qu'il fonctionne comme il le fait pour un autre programme qui a un répertoire .d.
la source