Migrando clientes de fantoches para o novo puppetmaster

Question

Como posso migrar nossos clientes de marionetes existentes para apontar para um novo servidor de puppetmaster? Prefiro não ir manualmente para 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 - nós temos 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/certs e /var/lib/ssl/private_key de old_hostname para new_hostname , que é basicamente o que é sugerido em migrar os clientes de fantoches para um novo mestre de marionetes (antigo servidor mestre de marionetes, usando apenas 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

Por isso, acredito que os certificados do cliente ainda saibam o nome do host ao qual estão associados e não estão satisfeitos com um switch.

Existe uma maneira de usar o fantoche (apontando para o mestre de fantoches legado) para implantar novos certificados ou, de alguma forma, automatizar o processo de assinatura?

RESUMO: Duas soluções foram apresentadas: 1) ative autosign no mestre, ignorando totalmente a certificação, ou 2) configure o CNAME antigo para apontar para o novo mestre, pois os certificados estão vinculados ao nome do host do mestre. Eu escolhi # 2 porque autosign parecia que estava apenas desligando a segurança (embora por um tempo limitado).

    

Answer 1

Você quer manter os mestres de marionetes funcionando por um tempo e migrar os clientes um pouco por vez?

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

Se não (se você estiver planejando derrubar o antigo servidor e cortar tudo de uma vez), então apenas pegue 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).

    

Answer 2

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

Além disso, deve ser possível implantar um script que:

• (Não relacionado ao script do cliente: possivelmente ativar autosign no novo servidor de fantoches)
• executado um pouco mais tarde
• pare o cliente de marionetes
• limpe o cliente ssldir
• 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 de reconfiguração infinito
• inicie o fantoche novamente

Feio, mas enquanto o módulo fazer migração estiver apenas no servidor antigo e certifique-se de que não há módulo de migração está apenas no novo servidor. coisa e só deve fazer a mágica ...