Migrando clientes de marionetes para o novo mestre de marionetes

Como posso migrar nossos clientes fantoches existentes para apontar para um novo servidor puppetmaster? Prefiro não ir manualmente a cada caixa do cliente e gerar um novo certificado.

Ao tentar o óbvio - rsync todos os arquivos de / etc / puppet e / var / lib / puppet para o novo servidor - obtivemos o erro de certificado

/etc/init.d/puppetmaster start 
* Starting puppet master                
Could not run: Retrieved certificate does not match private key; please remove certificate from server and regenerate it with the current key

Consegui contornar isso copiando os arquivos /var/lib/ssl/certse /var/lib/ssl/private_keyde old_hostnamepara new_hostname, o que é basicamente o que é sugerido na migração de clientes fantoches para um novo mestre fantoche (antigo servidor mestre fantoche desaparecido, apenas usando backup)

Infelizmente, meus clientes ainda sabem que há algo errado e me dão o seguinte erro:

sudo puppetd --test --server newservername.example.net --noop 
info: Retrieving plugin
err: /File[/var/lib/puppet/lib]: Failed to generate additional resources using 'eval_generate': hostname was not match with the server certificate
err: /File[/var/lib/puppet/lib]: Could not evaluate: hostname was not match with the server certificate Could not retrieve file metadata for puppet://newservername.example.net/plugins: hostname was not match with the server certificate
err: Could not retrieve catalog from remote server: hostname was not match with the server certificate
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run

Portanto, acho que os certificados de clientes ainda sabem o nome do host ao qual estão associados e não estão satisfeitos com uma mudança.

Existe uma maneira de usar o puppet (apontando para o puppetmaster legado) para implantar novos certificados ou automatizar o processo de assinatura?

RESUMO: Duas soluções foram apresentadas: 1) ligue autosigno mestre, ignorando completamente a certificação ou 2) defina o CNAME antigo para apontar para o novo mestre, pois os certificados estão vinculados ao nome do host do mestre. Eu escolhi o nº 2 porque o autosign parecia estar desativando a segurança (embora por um tempo limitado).

Você deseja manter os mestres de marionetes em funcionamento por um tempo e migrar clientes pouco a pouco?

Nesse caso, você está preso ao tocar em cada sistema do cliente, independentemente; se é para apontar para um novo mestre ou adicionar uma entrada de arquivo de hosts ou algo parecido. Se for esse o caso, é melhor iniciar o novo mestre novamente e assinar novamente cada cliente (é melhor que um arquivo de host hackear para solucionar os problemas de validação).

Caso contrário (se você estiver planejando derrubar o servidor antigo e cortar tudo de uma vez), basta substituir o nome do host do servidor antigo com o novo servidor; o certificado será reconhecido como válido se os clientes estiverem se conectando ao novo servidor no nome antigo (o nome que está no certificado).

Você pode simplesmente usar o $ssldirantigo mestre de marionetes e usá-lo no novo mestre de marionetes.

Fora isso, deve ser possível implantar um script que:

• (Não relacionado ao script do cliente: possivelmente ative a assinatura automática no novo servidor fantoche)
• corre um pouco mais tarde
• parar cliente fantoche
• limpar o ssldir do cliente
• modifique o puppet.conf no cliente para apontar para o novo servidor
• crie um arquivo de bloqueio para garantir que ele não cause um loop infinito de reconfiguração
• comece o fantoche novamente

Feio, mas desde que o módulo de migração esteja apenas no servidor antigo e verifique se não há módulo de migração apenas no novo servidor, é algo único e deve fazer a mágica ...