O servidor de arquivos Puppet
Este guia aborda o uso da capacidade de exibição de arquivos do Puppet.
O serviço master de fantoches inclui um servidor de arquivos para transferir arquivos estáticos. Se uma declaração de recurso de arquivo contiver um fantoche: URI em seu atributo de origem, os nós recuperarão esse arquivo do servidor de arquivos do mestre:
# copy a remote file to /etc/sudoers
file { "/etc/sudoers":
mode => 440,
owner => root,
group => root,
source => "puppet:///modules/module_name/sudoers"
}
Todos os URIs do servidor de arquivos fantoche estão estruturados da seguinte forma:
puppet://{server hostname (optional)}/{mount point}/{remainder of path}
Se um nome de host do servidor for omitido (por exemplo, puppet:///{mount point}/{path} ; observe a barra tripla), o URI será resolvido para qualquer servidor que o nó de avaliação considere ser seu mestre. Como isso torna o código de manifesto mais portátil e reutilizável, nomes de host devem ser omitidos sempre que possível.
O restante do fantoche: o URI é mapeado para o sistema de arquivos do servidor de duas maneiras, dependendo de os arquivos serem fornecidos por um module ou expostos por meio de custom mount point .
Envio de arquivos do módulo
Como a grande maioria da entrega de arquivos deve ser feita através de módulos, o servidor de arquivos Puppet fornece um ponto de montagem especial e semi-mágico chamado módulos, que está disponível por padrão. Se o ponto de montagem de um URI for módulos, o Puppet irá:
- Interprete o próximo segmento do caminho como o nome de um módulo…
- ... localize esse módulo no modulepath do servidor (conforme descrito aqui em "Pesquisa de módulo" ...
- ... e resolva o restante do caminho que começa nos arquivos / diretório desse módulo.
-
Ou seja, se um módulo chamado test_module estiver instalado no diretório
/etc/puppet/modulesdo servidor central, o seguinte fantoche: URI ...puppet:///modules/test_module/testfile.txt... resolverá o seguinte caminho absoluto:
/etc/puppet/modules/test_module/files/testfile.txtSe
test_modulefoi instalado em/usr/share/puppet/modules, o mesmo URI será resolvido como:/usr/share/puppet/modules/test_module/files/testfile.txt
Embora nenhuma configuração adicional seja necessária para usar o ponto de montagem de módulos, alguns controles de acesso podem ser especificados na configuração do servidor de arquivos, incluindo um bloco de configuração [modules] ; veja Segurança.
Envio de arquivos a partir de pontos de montagem personalizados
O Puppet também pode exibir arquivos de pontos de montagem arbitrários especificados na configuração do servidor de arquivos do servidor (veja abaixo). Ao servir arquivos de um ponto de montagem personalizado, o Puppet não executa a abstração de URI adicional usada na montagem dos módulos e resolverá o caminho após o nome da montagem como uma estrutura de diretório simples.
Configuração do servidor de arquivos
O local padrão para os dados de configuração do servidor de arquivos é /etc/puppet/fileserver.conf ; isso pode ser mudado passando a bandeira --fsconfig para o mestre de marionetes.
O formato do arquivo fileserver.conf é quase exatamente igual ao de rsync e lembra aproximadamente um arquivo INI:
[mount_point]
path /path/to/files
allow *.domain.com
deny *.wireless.domain.com
As opções a seguir podem ser atualmente especificadas para um determinado ponto de montagem:
- O caminho para a localização da montagem no disco
- Qualquer número de diretivas de permissão
- Qualquer número de diretivas de negação
é a única opção necessária, mas como a configuração de segurança padrão é negar todo o acesso, um ponto de montagem sem diretivas de permissão não estaria disponível para nenhum nó.
O caminho pode conter um ou todos os %h , %H e %d , que são substituídos dinamicamente pelo nome do host do cliente, seu nome de domínio totalmente qualificado e seu nome de domínio, respectivamente. Todos são retirados do certificado SSL do cliente (por isso, tenha cuidado se você tiver incompatibilidades de nome de host / certname). Isso é útil na criação de módulos nos quais os arquivos de cada cliente são mantidos completamente separados, por exemplo, para chaves de host ssh privadas. Por exemplo, com a configuração
[private]
path /data/private/%h
allow *
a solicitação para o arquivo /private/file.txt do cliente client1.example.com procurará um arquivo /data/private/client1/file.txt , enquanto a mesma solicitação de client2.example.com tentará recuperar o arquivo /data/private/client2/file.txt no servidor de arquivos.
No momento, os caminhos não podem conter barras à direita ou ocorrerá um erro. Também tome cuidado para que, em puppet.conf , você não esteja especificando locais de diretório que possuam barras finais.
Segurança
Proteger o servidor de arquivos Puppet consiste em permitir e negar acesso (em níveis variáveis de especificidade) por ponto de montagem. Grupos de nós podem ser identificados para permissão ou negação de três maneiras: por endereço IP, por nome ou por um único curinga global (*). Pontos de montagem personalizados padrão para negar todo o acesso.
Além dos pontos de montagem personalizados, há dois pontos de montagem especiais que podem ser gerenciados com fileserver.conf : modules e plugins . Nenhum desses pontos de montagem deve ter uma opção de caminho especificada. O comportamento do ponto de montagem dos módulos é descrito em Serving Files From Custom Mount Points. A montagem de plugins não é um verdadeiro ponto de montagem, mas é um gancho para permitir que o fileserver.conf especifique quais nós têm permissão para sincronizar plugins do Puppet Master.Ambos os pontos de montagem existem por padrão e ambos padrão para permitir todo o acesso; se qualquer diretiva de permissão ou negação for definida para uma dessas montagens especiais, suas configurações de segurança se comportarão como as de uma montagem normal (ou seja, o padrão será negar todo o acesso). Observe que esses são os únicos pontos de montagem para os quais deny * não é redundante.
Se os nós não estiverem se conectando diretamente ao servidor de arquivos Puppet, por exemplo, Usando um proxy reverso e Mongrel (consulte Usando o Mongrel), o servidor de arquivos verá todas as conexões como provenientes do endereço IP do servidor proxy, em vez do endereço do nó do Agente Puppet. Nesse caso, é melhor restringir o acesso com base no nome do host. Além disso, as máquinas que atuam como proxy reverso (geralmente 127.0.0.0/8) precisarão ter permissão para acessar os pontos de montagem aplicáveis.
Prioridade
Declarações de negação e permissão mais específicas têm precedência sobre declarações menos específicas; isto é, uma instrução allow para node.domain.com permitiria a conexão, apesar de uma declaração de negação para * .domain.com. Em um determinado nível de especificidade, as declarações de negação têm precedência sobre as instruções de permissão.
Comportamento imprevisível pode resultar da mistura de diretivas de endereço IP com diretivas de nome de host e nome de domínio, portanto, tente evitar fazer isso. (Atualmente, se o endereço IP do node.domain.com for 192.168.1.80 e o fileserver.conf contiver 192.168.1.80 e negar node.domain.com, a diretiva de permissão baseada em IP terá precedência. Esse comportamento pode ser alterado no futuro e não deve ser invocado.)
Nomes de host
Os nomes dos hosts podem ser especificados usando um nome de host completo ou especificando um domínio inteiro usando o caractere curinga *:
[export]
path /export
allow host.domain1.com
allow *.domain2.com
deny badhost.domain2.com
Endereços IP
O endereço IP pode ser especificado de forma semelhante aos nomes de host, usando endereços IP completos ou curingas. Você também pode usar a notação no estilo CIDR:
[export]
path /export
allow 127.0.0.1
allow 192.168.0.*
allow 192.168.1.0/24
Permitir global
A especificação de um único caractere curinga permitirá que qualquer nó acesse um ponto de montagem:
[export]
path /export
allow *
Observe que o comportamento padrão para pontos de montagem personalizados é equivalente a negar *.