I file di configurazione, che includono altri file, non sono nuovi. Anche l'inserimento dei file inclusi nelle sottodirectory è stata un'opzione sin dall'inizio. Esaminiamo i casi d'uso e vediamo come ottenere il massimo da questo metodo di organizzazione.
Alcune persone trovano che un singolo file di configurazione sia l'approccio "semplice" e un intero albero di file sia più complesso. Tuttavia, fermati e pensa a quanto potrebbero crescere alcuni file di configurazione o quante persone o programmi diversi hanno bisogno di modificarli. Può essere davvero più semplice consentire a ciascun sottoprogetto di rilasciare la propria configurazione nel proprio file in una sottodirectory. Di recente, ad esempio in systemd documentazione, questi file sono talvolta chiamati file "drop-in".
Nel tempo, e soprattutto negli ultimi anni, l'uso di sottodirectory in /etc è aumentato. Due situazioni significative stanno guidando questo movimento:
- Programmi più grandi hanno suddiviso file di configurazione complessi in più file più piccoli.
- Molti altri programmi sono diventati dipendenti da una singola utilità. Ciascuna di queste utilità deve gestire una parte della configurazione.
Popola per pacchetto
Alcuni dei primi utilizzi di *.d le directory che ho incontrato erano per la registrazione e la pianificazione. Diamo un'occhiata al logrotate utilità. Il file di configurazione principale è /etc/logrotate.conf . Non è molto complicato, ma ogni file da ruotare deve essere specificato. Ogni file potrebbe anche richiedere diverse opzioni di configurazione. Invece di modificare questo singolo file ogni volta che viene aggiunta o aggiornata un'applicazione sul sistema, separiamo la configurazione di ciascuna applicazione in un file specifico.
$ grep ^include /etc/logrotate.conf
include /etc/logrotate.d Il file di configurazione principale include tutti i file in un'altra directory. I file nella directory possono provenire da diversi pacchetti 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
Il proprietario di ogni pacchetto sa cosa deve essere ruotato e con quale frequenza. Forniscono un file di configurazione specifico per la loro applicazione e lo aggiungono a logrotate.d directory durante l'installazione. Viene anche rimosso da logrotate.d directory quando il pacchetto viene disinstallato dal sistema.
Altri esempi di questo caso d'uso sono la pianificazione con cron nel cron.d directory e configurazione dell'autenticazione con PAM nel pam.d directory. Utilizzando file separati, l'amministratore di sistema non ha bisogno di gestire le scritture in conflitto su un singolo file.
Organizza per funzione
Il server Web Apache è un programma completo con molte opzioni di configurazione. Apache utilizza un conf.d directory per l'organizzazione. Quando ho iniziato con Apache, era comune avere un unico server che ospitava più siti virtuali. Ciascuno di quegli host virtuali aveva il proprio file di configurazione. Questo approccio ci ha consentito di condividere i compiti di amministrazione dei file e di condividere i file su diversi sistemi durante la migrazione, il ripristino e il bilanciamento del carico. Oggi vedo più casi in cui la configurazione è separata dalla funzione.
Un altro fattore è se la funzione è installata come modulo separato.
$ rpm -qf /etc/httpd/conf.d/ssl.conf
mod_ssl-2.4.43-1.fc31.x86_64
Il ssl.conf la configurazione è resa disponibile solo quando il mod_ssl pacchetto è installato. Altri moduli possono anche rilasciare file in conf.d directory. Alcune applicazioni, come mod_auth_kerb pacchetto, fornisci un esempio in un /usr/share/doc directory. Spetta all'amministratore web creare o gestire i file di produzione.
[ Hai bisogno di ulteriore aiuto per imparare Linux? Corso online gratuito:panoramica tecnica di Red Hat Enterprise Linux. ]
Gestione centralizzata
Come ho suggerito con i file di configurazione Web, un altro utilizzo di file di configurazione separati consiste nel semplificare la gestione centralizzata di questi file e distribuire solo i componenti pertinenti a ciascun nodo gestito.
Il modules.d contiene la configurazione per le impostazioni del modulo del kernel e il sysctl.d contiene le impostazioni di ottimizzazione del kernel. Queste impostazioni potrebbero essere necessarie solo su alcuni sistemi o potrebbero richiedere impostazioni specifiche dell'hardware. Le impostazioni possono essere organizzate per hardware, funzione o una combinazione.
I programmi di gestione della configurazione possono inviare solo i file pertinenti a host gestiti specifici o generare i file su ciascun host in base a un modello. Se stai distribuendo questi file con una soluzione di gestione della configurazione come Ansible, usa qualcosa come ansible_managed variabile per includere un commento che indica che il file è gestito in remoto.
Determina un nome e una posizione
Sebbene le directory punto-d abbiano casi d'uso comuni per l'assistenza con l'organizzazione e la distribuzione, esistono molti modi diversi per gestire le inclusioni. Per ogni applicazione o utilità, dobbiamo determinare il modo migliore per denominare i nostri file. Alcune configurazioni riconoscono solo i file con un'estensione specifica, come .conf , mentre altri fanno riferimento a tutti i file nella directory.
L'man pagine per il file di configurazione principale, come man logrotate.conf , di solito descrive le opzioni. Tuttavia, inizio cercando un'istruzione include nel file di configurazione.
Quando cerco include, vedo una varietà di metodi (formattati per la leggibilità):
$ 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")
Il ld.so e rsyslog entrambe le configurazioni prevedono che i file inclusi finiscano con .conf . Gli altri sembrano includere tutti i file, ma ulteriori indagini potrebbero mostrare un metodo per escludere i file. Ad esempio, man logrotate.conf mostra che tabooext e taboopat può essere utilizzato per filtrare .orig , .bak , .rpmnew o altri file che potrebbero derivare dal controllo delle versioni o dagli aggiornamenti. Per il krb5.conf file, c'è sia un include e includedir direttiva. La pagina man indica che includedir la direttiva copre "tutti i file all'interno della directory i cui nomi sono costituiti esclusivamente da caratteri alfanumerici, trattini o trattini bassi". Continua sottolineando che i file che iniziano con un punto (.) vengono ignorati.
Un'altra considerazione per i file inclusi è l'ordine di lettura e unione. Ne ho visti alcuni che leggono in ordine casuale, ma la maggior parte include file nell'ordine in cui si trovano nella directory. Se la sequenza è particolarmente importante, ad esempio per moduli o script di avvio, è comune iniziare i nomi dei file con un numero. Sono comuni anche altri standard di denominazione come "pre" o "post".
$ ls /etc/NetworkManager/dispatcher.d/
04-iscsi 20-chrony no-wait.d pre-down.d pre-up.d
Alcune utilità possono anche avere simboli di espansione che aiutano con la gestione e la distribuzione di file centralizzati. I sudoers la configurazione è un esempio in cui un %h rappresenta la forma abbreviata del nome host.
include /etc/sudoers.d/sudoers.%h
La riga di inclusione sopra specifica il file di configurazione per l'host corrente, anche se la directory contiene altri file. Vedi man sudoers per altri esempi.
Verifica i file
Un altro pericolo nell'usare le directory dot-d è che potrebbe essere necessario modificare i comandi di controllo della sintassi.
In alcuni casi, tutti i file di configurazione devono essere controllati contemporaneamente. Ad esempio, con Apache, il apachectl configtest comando controlla sempre il file di configurazione principale, che può includere altri file. Utilizza le opzioni predefinite. Puoi eseguire httpd -t comando con opzioni aggiuntive. Ad esempio, c'è un'opzione per elencare tutti i file inclusi.
$ 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
Il httpd il comando accetta anche un -f opzione per specificare un file particolare. Tuttavia, quel file deve superare tutti i controlli di configurazione, quindi il controllo di un file incluso potrebbe non fornire i risultati desiderati. Il seguente errore si verifica durante il controllo del ssl.conf predefinito file di configurazione fornito da mod_ssl pacchetto.
$ httpd -t -f /etc/httpd/conf.d/ssl.conf
AH00534: httpd: Configuration error: No MPM loaded.
Altre applicazioni hanno metodi per verificare la sintassi per un file incluso. Il sudo la configurazione viene normalmente modificata utilizzando il visudo comando in modo che sia possibile eseguire una convalida della sintassi prima del salvataggio e dell'uscita. Questa utility modifica il /etc/sudoers per impostazione predefinita, ma supporta anche un -f opzione per specificare un file diverso.
$ 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
Lo stesso comando supporta anche un --check opzione per convalidare solo un file senza una modifica.
$ visudo -c demo.sudo
>>> demo.sudo: syntax error near line 1 <<<
parse error in demo.sudo near line 1
Combina questo con un'opzione di convalida nel tuo programma di gestione della configurazione per assicurarti che le espansioni del modello non interrompano un file di configurazione. Ci sono esempi nella documentazione per i moduli Ansible copy e template. Ho anche fornito il seguente esempio da ansible-doc template per 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 po' di ricerca nelle righe commentate e nelle pagine man ti aiuterà a ottenere il massimo da questo metodo organizzativo visualizzando le opzioni di distribuzione, le convenzioni di denominazione e le informazioni sulla convalida della sintassi.
Concludi
L'organizzazione dei file di configurazione in directory può semplificare la gestione e la delega dell'amministrazione. I file possono essere organizzati per pacchetto o funzione e soluzioni di gestione della configurazione come Ansible possono anche trarre vantaggio da file modello più piccoli. Potrebbe essere necessario standardizzare i nomi e le posizioni dei file e potrebbe essere necessario aggiornare gli strumenti di verifica dei file, ma l'utilizzo di una cartella punto d per ospitare più file di configurazione può farti risparmiare un sacco di fatica.
[ Vuoi provare Red Hat Enterprise Linux? Scaricalo ora gratuitamente. ]