Migrazione dei client fantoccio verso il nuovo burattinaio

Come posso migrare i nostri client fantoccio esistenti per puntare a un nuovo server fantoccio? Preferirei non andare manualmente in ogni casella client e generare un nuovo certificato.

Quando proviamo l'ovvio - rsincronizza tutti i file da / etc / puppet e / var / lib / puppet sul nuovo server - otteniamo l'errore del certificato

/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

Sono stato in grado di ovviare a questo copiando i file /var/lib/ssl/certse /var/lib/ssl/private_keyda old_hostnamea new_hostname, che è fondamentalmente ciò che è suggerito nella migrazione dei client fantoccio a un nuovo master fantoccio (il vecchio server fantoccio è andato, usando solo il backup)

Sfortunatamente, i miei clienti sanno ancora che c'è qualcosa che non va e mi danno il seguente errore:

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

Quindi immagino che i certificati client conoscano ancora il nome host a cui sono associati e non sono contenti di un passaggio.

Esiste un modo per utilizzare il pupazzo (indicando il burattinaio legacy) per distribuire nuovi certificati o in qualche modo automatizzare il processo di firma?

SINTESI: sono state presentate due soluzioni: 1) accendere autosignil master, saltando così completamente la certificazione, oppure 2) impostare il vecchio CNAME in modo che punti al nuovo master, poiché i certificati sono associati al nome host del master. Ho scelto il n. 2 perché la progettazione automatica sembrava solo disattivare la sicurezza (anche se per un tempo limitato).

Stai cercando di mantenere entrambi i burattinai attivi e funzionanti per un po 'e migrare i clienti un po' alla volta?

In tal caso, sei bloccato a toccare ciascun sistema client a prescindere; se si tratta di puntare a un nuovo master o aggiungere una voce al file hosts o qualcosa del genere. In tal caso, potresti anche semplicemente avviare il nuovo master e firmare nuovamente ogni client (è meglio di un hack del file host per aggirare i problemi di convalida).

In caso contrario (se stai pianificando di eliminare il vecchio server e tagliare tutto in una volta), prendi semplicemente il nome host del vecchio server con il nuovo server; il certificato verrà riconosciuto valido se i client si stanno connettendo al nuovo server con il vecchio nome (il nome che si trova sul certificato).

Puoi semplicemente usare il $ssldirvecchio burattinaio e usarlo nel nuovo burattinaio.

Oltre a ciò, dovrebbe essere possibile distribuire uno script che:

• (Non correlato allo script client: eventualmente attivare la firma automatica sul nuovo server fantoccio)
• corri un po 'più tardi
• ferma client fantoccio
• ripulire il client ssldir
• modifica il puppet.conf sul client per puntare al nuovo server
• creare un file di blocco per assicurarsi che non causi un ciclo di riconfigurazione senza fine
• ricomincia il burattino

Brutto ma finché il modulo di migrazione do è solo sul vecchio server e assicurati che non ci sia un modulo di migrazione solo sul nuovo server è una cosa da fare e dovrebbe fare solo la magia ...