Los archivos de configuración, que incluyen otros archivos, no son nuevos. Colocar esos archivos incluidos en subdirectorios también ha sido una opción desde el principio. Revisemos los casos de uso y veamos cómo aprovechar al máximo este método de organización.
Algunas personas encuentran que un solo archivo de configuración es el enfoque "simple" y que todo un árbol de archivos es más complejo. Sin embargo, deténgase y piense cuánto pueden crecer algunos archivos de configuración, o cuántas personas o programas diferentes necesitan editarlos. Realmente puede ser más fácil permitir que cada subproyecto coloque su configuración en su propio archivo en un subdirectorio. Recientemente, como en systemd documentación, estos archivos a veces se denominan archivos "drop-in".
Con el tiempo, y especialmente en los últimos años, el uso de subdirectorios en /etc ha aumentado. Dos situaciones significativas están impulsando este movimiento:
- Los programas más grandes han dividido archivos de configuración complejos en varios archivos más pequeños.
- Muchos otros programas se han vuelto dependientes de una sola utilidad. Cada una de esas utilidades necesita administrar una parte de la configuración.
Rellenar por paquete
Algunos de los primeros usos de *.d Los directorios que encontré eran para registro y programación. Veamos el logrotate utilidad. El archivo de configuración principal es /etc/logrotate.conf . No es muy complicado, pero hay que especificar cada archivo a rotar. Cada archivo también puede necesitar diferentes opciones de configuración. En lugar de editar este único archivo cada vez que se agrega o actualiza una aplicación en el sistema, separamos la configuración de cada aplicación en un archivo específico.
$ grep ^include /etc/logrotate.conf
include /etc/logrotate.d El archivo de configuración principal incluye todos los archivos en otro directorio. Los archivos en el directorio pueden tener su origen en diferentes paquetes 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
El propietario de cada paquete sabe qué se debe rotar y con qué frecuencia. Proporcionan un archivo de configuración específico para su aplicación y lo agregan a logrotate.d directorio durante la instalación. También se elimina de logrotate.d directorio cuando se desinstala el paquete del sistema.
Otros ejemplos de este caso de uso son la programación con cron en el cron.d directorio y configuración de autenticación con PAM en el pam.d directorio. Al usar archivos separados, el administrador del sistema no necesita administrar escrituras conflictivas en un solo archivo.
Organizar por función
El servidor web Apache es un programa extenso con muchas opciones de configuración. Apache utiliza un conf.d directorio para la organización. Cuando comencé con Apache, era común tener un solo servidor que albergara varios sitios virtuales. Cada uno de esos hosts virtuales tenía su propio archivo de configuración. Este enfoque nos permitió compartir las tareas de administración de los archivos, así como compartir los archivos en diferentes sistemas durante la migración, la recuperación y el equilibrio de carga. Hoy, veo más casos donde la configuración está separada por función.
Otro factor es si la característica se instala como un módulo separado.
$ rpm -qf /etc/httpd/conf.d/ssl.conf
mod_ssl-2.4.43-1.fc31.x86_64
El ssl.conf la configuración está disponible solo cuando mod_ssl el paquete está instalado. Otros módulos también pueden colocar archivos en el conf.d directorio. Algunas aplicaciones, como mod_auth_kerb paquete, proporcione una muestra en un /usr/share/doc directorio. Depende del administrador web crear o administrar los archivos de producción.
[ ¿Necesita más ayuda para aprender Linux? Curso en línea gratuito:Descripción general técnica de Red Hat Enterprise Linux. ]
Gestión centralizada
Como sugerí con los archivos de configuración web, otro uso de los archivos de configuración separados es facilitar la administración centralizada de estos archivos y distribuir solo los componentes relevantes a cada nodo administrado.
Los modules.d El directorio contiene la configuración del módulo del núcleo y el sysctl.d El directorio contiene la configuración de ajuste del kernel. Es posible que esta configuración solo sea necesaria en algunos sistemas o que requiera una configuración específica del hardware. La configuración se puede organizar por hardware, función o una combinación.
Los programas de administración de la configuración pueden enviar solo los archivos relevantes a hosts administrados específicos o generar los archivos en cada host en función de una plantilla. Si está distribuyendo estos archivos con una solución de administración de configuración como Ansible, use algo como ansible_managed variable para incluir un comentario que indique que el archivo se administra de forma remota.
Determina un nombre y una ubicación
Si bien los directorios dot-d tienen casos de uso comunes para ayudar con la organización y distribución, existen muchas formas diferentes de manejar los include. Para cada aplicación o utilidad, debemos determinar cuál es el mejor nombre para nuestros archivos. Algunas configuraciones solo reconocen archivos con una extensión específica, como .conf , mientras que otros hacen referencia a todos los archivos del directorio.
El man páginas para el archivo de configuración principal, como man logrotate.conf , generalmente describirá las opciones. Aún así, empiezo buscando una declaración de inclusión en el archivo de configuración.
Cuando busco incluye, veo una variedad de métodos (formateados para facilitar la lectura):
$ 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")
El ld.so y rsyslog ambas configuraciones esperan que los archivos incluidos terminen en .conf . Parece que los otros incluyen todos los archivos, pero una investigación más profunda puede mostrar un método para excluir archivos. Por ejemplo, man logrotate.conf muestra que tabooext y taboopat se puede usar para filtrar .orig , .bak , .rpmnew , u otros archivos que puedan resultar del control de versiones o actualizaciones. Para krb5.conf archivo, hay un include y includedir directiva. La página man indica que el includedir La directiva cubre "todos los archivos dentro del directorio cuyos nombres consisten únicamente en caracteres alfanuméricos, guiones o guiones bajos". Continúa señalando que los archivos que comienzan con un punto (.) se ignoran.
Otra consideración para los archivos incluidos es el orden de lectura y combinación. He visto algunos que se leen en un orden aleatorio, pero la mayoría incluye archivos en el orden en que se encuentran en el directorio. Si la secuencia es particularmente importante, como para módulos o scripts de inicio, es común comenzar los nombres de archivo con un número. Otros estándares de nomenclatura como "pre" o "post" también son comunes.
$ ls /etc/NetworkManager/dispatcher.d/
04-iscsi 20-chrony no-wait.d pre-down.d pre-up.d
Algunas utilidades pueden incluso tener símbolos de expansión que ayuden a administrar y distribuir archivos centralizados. Los sudoers la configuración es un ejemplo donde un %h representa la forma abreviada del nombre de host.
include /etc/sudoers.d/sudoers.%h
La línea de inclusión anterior especifica el archivo de configuración para el host actual, incluso si el directorio contiene otros archivos. Ver man sudoers para más ejemplos.
Verificar archivos
Otro riesgo de usar directorios punto-d es que puede que tenga que modificar sus comandos de verificación de sintaxis.
En algunos casos, todos los archivos de configuración deben verificarse a la vez. Por ejemplo, con Apache, el apachectl configtest El comando siempre comprueba el archivo de configuración principal, que puede incluir otros archivos. Utiliza opciones predeterminadas. Puede ejecutar httpd -t comando con opciones adicionales. Por ejemplo, hay una opción para listar todos los archivos incluidos.
$ 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
El httpd el comando también toma un -f opción para especificar un archivo en particular. Sin embargo, ese archivo debe pasar todas las comprobaciones de configuración, por lo que la comprobación de un archivo incluido puede no dar los resultados deseados. Se produce el siguiente error al comprobar el ssl.conf predeterminado archivo de configuración proporcionado por mod_ssl paquete.
$ httpd -t -f /etc/httpd/conf.d/ssl.conf
AH00534: httpd: Configuration error: No MPM loaded.
Otras aplicaciones tienen métodos para verificar la sintaxis de un archivo incluido. El sudo la configuración normalmente se modifica usando el visudo comando para que se pueda realizar una validación de sintaxis antes de guardar y salir. Esta utilidad edita el /etc/sudoers archivo de forma predeterminada, pero también admite un -f opción para especificar un archivo diferente.
$ 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
El mismo comando también admite un --check opción para validar solo un archivo sin editar.
$ visudo -c demo.sudo
>>> demo.sudo: syntax error near line 1 <<<
parse error in demo.sudo near line 1
Combine esto con una opción de validación en su programa de gestión de configuración para asegurarse de que las expansiones de plantilla no rompan un archivo de configuración. Hay ejemplos en la documentación para los módulos de copia y plantilla de Ansible. También proporcioné el siguiente ejemplo de ansible-doc template para 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 Explorar un poco las líneas comentadas y las páginas del manual lo ayudará a aprovechar al máximo este método organizativo al mostrar opciones de distribución, convenciones de nombres e información de validación de sintaxis.
Terminar
Organizar los archivos de configuración en directorios puede hacer que la administración sea más fácil de administrar y delegar. Los archivos se pueden organizar por paquete o función y las soluciones de administración de configuración como Ansible pueden incluso beneficiarse de archivos de plantilla más pequeños. Es posible que deba estandarizar los nombres y las ubicaciones de los archivos, y es posible que deba actualizar las herramientas de verificación de archivos, pero usar una carpeta dot d para albergar varios archivos de configuración puede ahorrarle mucho esfuerzo.
[ ¿Quiere probar Red Hat Enterprise Linux? Descárgalo ahora gratis. ]