O servidor de arquivos Puppet
Este guia aborda o uso do recurso de exibição de arquivos do Puppet.
O serviço mestre de marionetes inclui um servidor de arquivos para transferir arquivos estáticos. Se uma declaração de recurso de arquivo contiver um URI fantoche: em seu atributo de origem, os nós recuperarão esse arquivo do servidor de arquivos mestre:
# copia um arquivo remoto para / etc / sudoers
arquivo {"/ etc / sudoers":
mode => 440,
proprietário => raiz,
grupo => raiz,
fonte => "fantoche: /// modules / module_name / sudoers"
}
Todos os URIs do servidor de arquivos fantoche estão estruturados da seguinte maneira:
puppet://{server hostname (optional)}/{mount point}/{remainder of path}
Se um nome de host do servidor for omitido (ou seja puppet:///{mount point}/{path}, observe a barra tripla), o URI resolverá para o servidor que o nó de avaliação considerar como mestre. Como isso torna o código de manifesto mais portátil e reutilizável, os nomes de host devem ser omitidos sempre que possível.
O restante do fantoche: URI é mapeado para o sistema de arquivos do servidor de uma das duas maneiras, dependendo de os arquivos serem fornecidos por a moduleou expostos por a custom mount point.
Servindo arquivos do módulo
Como a grande maioria da veiculação de arquivos deve ser feita por meio 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 um módulo, o Puppet:
- Interprete o próximo segmento do caminho como o nome de um módulo…
- ... localize esse módulo no módulo de caminho do servidor (conforme descrito aqui em "Pesquisa de módulo" ...
- ... e resolva o restante do caminho iniciando nos arquivos / diretório desse módulo.
Ou seja, se um módulo chamado test_module estiver instalado no /etc/puppet/modulesdiretório do servidor central , o seguinte fantoche: URI ...
puppet:///modules/test_module/testfile.txt
... resolverá o seguinte caminho absoluto:
/etc/puppet/modules/test_module/files/testfile.txt
Se test_modulefosse instalado /usr/share/puppet/modules, o mesmo URI resolveria:
/usr/share/puppet/modules/test_module/files/testfile.txt
Embora nenhuma configuração adicional seja necessária para usar o ponto de montagem dos módulos, alguns controles de acesso podem ser especificados na configuração do servidor de arquivos adicionando um [modules]bloco de configuração; veja Segurança.
Servindo arquivos de pontos de montagem personalizados
O Puppet também pode servir arquivos de pontos de montagem arbitrários especificados na configuração do servidor de arquivos do servidor (veja abaixo). Ao enviar 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órios 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 alterado passando a --fsconfigbandeira para o mestre de marionetes.
O formato do fileserver.confarquivo é quase exatamente igual ao de rsynce se assemelha a um arquivo INI:
[mount_point]
path /path/to/files
allow *.domain.com
deny *.wireless.domain.com
Atualmente, as seguintes opções podem ser especificadas para um determinado ponto de montagem:
- O caminho para o local da montagem no disco
- Qualquer número de diretivas de permissão
- Qualquer número de diretivas de negação
path é 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 %h, %He %d, que são substituídas dinamicamente pelo hostname 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 (portanto, tenha cuidado se houver incompatibilidades de nome de host / nome de certificado). Isso é útil na criação de módulos em que os arquivos para 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 de arquivo /private/file.txtdo cliente client1.example.com procurará um arquivo /data/private/client1/file.txt, enquanto a mesma solicitação de client2.example.comtentará recuperar o arquivo /data/private/client2/file.txt no servidor de arquivos.
Atualmente, os caminhos não podem conter barras à direita ou ocorrerá um erro. Também verifique se puppet.confvocê não está especificando locais de diretório que possuem barras à direita.
Segurança
Proteger o servidor de arquivos Puppet consiste em permitir e negar acesso (em diferentes ní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 (*). Os pontos de montagem personalizados são padrão para negar todo o acesso.
Além dos pontos de montagem personalizados, existem dois pontos de montagem especiais que podem ser gerenciados com fileserver.conf: modulese plugins. Nenhum desses pontos de montagem deve ter uma opção de caminho especificada. O comportamento do ponto de montagem dos módulos é descrito acima em Serving Files From Custom Mount Points. A montagem dos plug-ins não é um verdadeiro ponto de montagem, mas sim um gancho para permitir que o fileserver.conf especifique quais nós têm permissão para sincronizar plug-ins do Puppet Master. Ambos os pontos de montagem existem por padrão e ambos permitem o acesso total; se alguma diretiva de permissão ou negação estiver definida para uma dessas montagens especiais, suas configurações de segurança se comportarão como as de uma montagem normal (ou seja, será padrão negar todo o acesso). Observe que esses são os únicos pontos de montagem para os quais negar * 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 o Mongrel (consulte Usando o Mongrel), o servidor de arquivos verá todas as conexões como provenientes do endereço IP do servidor proxy, e não do nó do Puppet Agent . 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) precisam ter permissão para acessar os pontos de montagem aplicáveis.
Prioridade
Instruções mais negadas e permitidas têm precedência sobre instruções menos específicas; ou seja, uma instrução de permissão para node.domain.com deixaria que ele se conectasse, apesar de uma instruçã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 declarações de permissão.
Um 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, evite fazer isso. (Atualmente, se o endereço IP do node.domain.com for 192.168.1.80 e o fileserver.conf contiver allow 192.168.1.80 e negar o node.domain.com, a diretiva de permissão baseada em IP realmente terá precedência. Esse comportamento pode ser alterado no futuro e não deve ser invocado.)
Nomes de host
Os nomes de host podem ser especificados usando um nome de host completo ou especificando um domínio inteiro usando o 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 maneira semelhante aos nomes de host, usando endereços IP completos ou endereços curinga. 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
Permissão global
A especificação de um único 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 *.