El servidor de archivos Puppet
Esta guía cubre el uso de la capacidad de servicio de archivos de Puppet.
El servicio de Puppet Master incluye un servidor de archivos para transferir archivos estáticos. Si una declaración de recursos de archivo contiene una marioneta: URI en su atributo de origen, los nodos recuperarán ese archivo del servidor de archivos del maestro:
# copiar un archivo remoto a / etc / sudoers
archivo {"/ etc / sudoers":
modo => 440,
propietario => raíz,
grupo => raíz,
source => "puppet: /// modules / module_name / sudoers"
}
Todos los URI del servidor de archivos puppet están estructurados de la siguiente manera:
puppet://{server hostname (optional)}/{mount point}/{remainder of path}
Si se omite un nombre de host del servidor (es decir puppet:///{mount point}/{path}, tenga en cuenta la triple barra), el URI se resolverá en cualquier servidor que el nodo de evaluación considere su maestro. Como esto hace que el código de manifiesto sea más portátil y reutilizable, los nombres de host deben omitirse siempre que sea posible.
El resto de la marioneta: URI se asigna al sistema de archivos del servidor de una de dos maneras, dependiendo de si los archivos son proporcionados por moduleao expuestos a través de a custom mount point.
Servir archivos de módulo
Como la gran mayoría del servicio de archivos debe realizarse a través de módulos, el servidor de archivos Puppet proporciona un punto de montaje especial y semimágico llamado módulos, que está disponible de forma predeterminada. Si el punto de montaje de un URI son módulos, Puppet:
- Interprete el siguiente segmento de la ruta como el nombre de un módulo ...
- ... ubique ese módulo en la ruta del módulo del servidor (como se describe aquí en "Búsqueda de módulos" ...
- ... y resuelva el resto de la ruta que comienza en los archivos / directorio de ese módulo.
Es decir, si un módulo llamado test_module está instalado en el /etc/puppet/modulesdirectorio del servidor central , el siguiente títere: URI ...
puppet:///modules/test_module/testfile.txt
... se resolverá a la siguiente ruta absoluta:
/etc/puppet/modules/test_module/files/testfile.txt
Si test_modulese instaló en /usr/share/puppet/modules, el mismo URI resolvería en su lugar:
/usr/share/puppet/modules/test_module/files/testfile.txt
Aunque no se requiere ninguna configuración adicional para usar el punto de montaje de los módulos, algunos controles de acceso se pueden especificar en la configuración del servidor de archivos agregando un [modules]bloque de configuración; ver Seguridad
Servir archivos desde puntos de montaje personalizados
Puppet también puede servir archivos desde puntos de montaje arbitrarios especificados en la configuración del servidor de archivos del servidor (ver más abajo). Al servir archivos desde un punto de montaje personalizado, Puppet no realiza la abstracción de URI adicional utilizada en el montaje de módulos, y resolverá la ruta que sigue al nombre de montaje como una estructura de directorio simple.
Configuración del servidor de archivos
La ubicación predeterminada para los datos de configuración del servidor de archivos es /etc/puppet/fileserver.conf; Esto se puede cambiar pasando la --fsconfigbandera a Puppet Master.
El formato del fileserver.confarchivo es casi exactamente como el de rsync, y se asemeja a un archivo INI:
[mount_point]
path /path/to/files
allow *.domain.com
deny *.wireless.domain.com
Las siguientes opciones se pueden especificar actualmente para un punto de montaje dado:
- La ruta a la ubicación del montaje en el disco
- Cualquier cantidad de directivas de permiso
- Cualquier cantidad de directivas de denegación
La ruta es la única opción requerida, pero dado que la configuración de seguridad predeterminada es negar todo acceso, un punto de montaje sin directivas de permiso no estaría disponible para ningún nodo.
La ruta puede contener cualquiera o todos %h, %Hy %d, que se sustituyen de forma dinámica por nombre de host del cliente, el nombre de dominio completo y su nombre de dominio, respectivamente. Todos se toman del certificado SSL del cliente (así que tenga cuidado si no coincide el nombre de host / certname). Esto es útil en la creación de módulos donde los archivos para cada cliente se mantienen completamente separados, por ejemplo, para las claves de host ssh privadas. Por ejemplo, con la configuración
[private]
path /data/private/%h
allow *
la solicitud de archivo /private/file.txtdel cliente client1.example.com buscará un archivo /data/private/client1/file.txt, mientras que la misma solicitud de client2.example.comintentará recuperar el archivo /data/private/client2/file.txt en el servidor de archivos.
Actualmente, las rutas no pueden contener barras diagonales finales o se producirá un error. También tenga cuidado de puppet.confno especificar ubicaciones de directorio que tengan barras diagonales finales.
Seguridad
Asegurar el servidor de archivos Puppet consiste en permitir y denegar el acceso (a diferentes niveles de especificidad) por punto de montaje. Los grupos de nodos pueden identificarse para obtener permiso o denegación de tres maneras: por dirección IP, por nombre o por un solo comodín global (*). Los puntos de montaje personalizados predeterminan la denegación de todo acceso.
Además de los puntos de montaje personalizados, hay dos puntos de montaje especiales que se pueden administrar con fileserver.conf: modulesy plugins. Ninguno de estos puntos de montaje debe tener una opción de ruta especificada. El comportamiento del punto de montaje de los módulos se describe anteriormente en Servir archivos desde puntos de montaje personalizados. El montaje de complementos no es un verdadero punto de montaje, sino que es un gancho para permitir que fileserver.conf especifique qué nodos pueden sincronizar complementos desde Puppet Master. Ambos puntos de montaje existen de manera predeterminada, y ambos predeterminan para permitir todos los accesos; Si se establecen directivas de permiso o denegación para uno de estos montajes especiales, su configuración de seguridad se comportará como la de un montaje normal (es decir, denegará de forma predeterminada el acceso total). Tenga en cuenta que estos son los únicos puntos de montaje para los que negar * no es redundante.
Si los nodos no se conectan al servidor de archivos Puppet directamente, por ejemplo, usando un proxy inverso y Mongrel (consulte Uso de Mongrel), entonces el servidor de archivos verá que todas las conexiones provienen de la dirección IP del servidor proxy en lugar de la del nodo Puppet Agent . En este caso, es mejor restringir el acceso según el nombre de host. Además, las máquinas que actúen como proxy inverso (generalmente 127.0.0.0/8) deberán poder acceder a los puntos de montaje correspondientes.
Prioridad
Las declaraciones de negar y permitir más específicas tienen prioridad sobre las declaraciones menos específicas; es decir, una declaración de permiso para node.domain.com le permitiría conectarse a pesar de una declaración de denegación para * .domain.com. En un determinado nivel de especificidad, las declaraciones de negación tienen prioridad sobre las declaraciones de permiso.
Un comportamiento impredecible puede resultar de mezclar directivas de dirección IP con directivas de nombre de host y nombre de dominio, así que trate de evitar hacerlo. (Actualmente, si la dirección IP de node.domain.com es 192.168.1.80 y fileserver.conf contiene allow 192.168.1.80 y deny node.domain.com, la directiva de permiso basada en IP realmente tendrá prioridad. Este comportamiento puede cambiar en el futuro y no se debe confiar en él)
Nombres de host
Los nombres de host se pueden especificar utilizando un nombre de host completo o especificando un dominio completo con el comodín *:
[export]
path /export
allow host.domain1.com
allow *.domain2.com
deny badhost.domain2.com
Direcciones IP
La dirección IP se puede especificar de manera similar a los nombres de host, utilizando direcciones IP completas o direcciones comodín. También puede usar la notación de estilo CIDR:
[export]
path /export
allow 127.0.0.1
allow 192.168.0.*
allow 192.168.1.0/24
Permitir global
Especificar un solo comodín permitirá que cualquier nodo acceda a un punto de montaje:
[export]
path /export
allow *
Tenga en cuenta que el comportamiento predeterminado para los puntos de montaje personalizados es equivalente a negar *.