vários mestres de marionetes configurados usando inventário

2

Consegui configurar vários mestres de marionetes com um mestre de marionetes agindo como uma autoridade de certificação e os clientes podem obter um certificado desse servidor de autoridade de certificação, mas usam o mestre de marionetes designado para obter seus manifestos. Veja esta pergunta para mais informações. vários mestres de marionetes . No entanto, há algumas coisas que tive que fazer para que isso funcionasse corretamente e com um erro que ocorreria.

Primeiro de tudo, para obter inventário trabalhando para um cliente-fantoche (PC) conectando-se ao seu mestre-fantoche designado (PM), eu tive que copiar os certificados da CA na PM1 para o diretório ca PM2. Eu corri este comando:

scp [email protected]:/var/lib/puppet/ssl/ca/ca_cr*.pem  [email protected]:/var/lib/puppet/ssl/ca/.

Depois de fazer isso, consegui remover o comentário da seção SSLCertificateChainFile, SSLCACertificateFile & SSLCARevocationFile do meu arquivo VH rack.conf no PM2. Depois que fiz isso, o inventário começou a funcionar. Isso soa como uma maneira aceitável de fazer as coisas?

Em segundo lugar, no arquivo puppet.conf, estou configurando o servidor PM designado para o cliente, por exemplo, server = puppet-master2.test.net . A menos que haja uma maneira melhor, é assim que funcionará na minha configuração de produção. Então o PC1 irá falar com o PM1 e o PC2 irá falar com o PM2. É aqui que eu tenho um erro. Quando o PC2 primeiro solicita um certificado da CA na PM1, o certificado aparece e, em seguida, assino o certificado na CA na PM1. Quando faço um agente de marionetes - teste no PC2 (que tem server = puppet-master2.test.net no puppet.conf), recebo este erro:

Warning: Unable to fetch my node definition, but the agent run will continue:
Warning: Error 403 on SERVER: Forbidden request: puppet-master2.test.net(10.1.1.161) access to /certificate_revocation_list/ca [find] at :112

No entanto, se eu alterar o arquivo puppet.conf do PC2 e especificar server = PM1 e o agente-puppet da rerun - test, não receberei nenhum erro. Eu posso então reverter a mudança no arquivo puppet.conf de volta para server = PM2 e tudo parece rodar normalmente.

Preciso configurar algum tipo de ProxyPassMatch na PM2 para solicitações feitas de clientes para / certificate_revocation_list / * e redirecioná-las para a PM1? Ou como posso corrigir esse erro?

Felicidades, Oli

    
por Oli 19.12.2012 / 17:12

1 resposta

1

Once i have done that, I was able to uncomment the SSLCertificateChainFile, SSLCACertificateFile & SSLCARevocationFile section of my rack.conf VH file on the PM2. Once I had done this, inventory started to work. Does this sound an acceptable way to do things?

Não precisa fazer isso - a lista de revogação e o certificado raiz já devem estar no mestre secundário. Tente estes locais de arquivo no PM2:

SSLCertificateChainFile /var/lib/puppet/ssl/certs/ca.pem
SSLCACertificateFile    /var/lib/puppet/ssl/certs/ca.pem
SSLCARevocationFile     /var/lib/puppet/ssl/crl.pem

Secondly, in the puppet.conf file, I am setting the designated PM server for the client, for example server = puppet-master2.test.net. Unless there is a better way, this is how it'll work in my production setup.

Qual versão de fantoches você está? O recurso de registro SRV da 3.0 é uma excelente solução para esse problema, permitindo que você ofereça aos clientes um conjunto de mestres que eles podem escolher, com pesos e prioridades.

Do I have to set up some kind of ProxyPassMatch on PM2 for requests made from clients to /certificate_revocation_list/* and redirect them to PM1? Or how can I fix this error?

Este é um padrão ruim em auth.conf - a conexão com proxy não é autenticada e o padrão é forçar a autenticação para a CRL (que não é sensível). Adicione isto ao seu auth.conf na PM1:

path /certificate_revocation_list
auth any
method find
allow *
    
por 20.12.2012 / 06:10