Migration de clients de marionnettes vers un nouveau maître de marionnettes

8

Comment puis-je migrer nos clients puppetmaster existants pour pointer vers un nouveau serveur puppetmaster? Je préfère ne pas aller manuellement dans chaque boîte client et générer un nouveau certificat.

En essayant l'évidence - rsync tous les fichiers de / etc / puppet et / var / lib / puppet vers le nouveau serveur - nous avons eu l'erreur de certificat

/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

J'ai pu contourner cela en copiant les fichiers /var/lib/ssl/certset /var/lib/ssl/private_keyde old_hostnameà new_hostname, ce qui est essentiellement ce qui est suggéré dans la migration des clients de marionnettes vers un nouveau maître de marionnettes (l'ancien serveur maître de marionnettes a disparu, en utilisant uniquement la sauvegarde)

Malheureusement, mes clients savent toujours qu'il y a quelque chose qui ne va pas et me donnent l'erreur suivante:

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

Je suppose donc que les certificats clients connaissent toujours le nom d'hôte auquel ils sont associés et ne sont pas satisfaits d'un commutateur.

Existe-t-il un moyen d'utiliser marionnette (pointant vers l'ancien marionnettiste) pour déployer de nouveaux certificats ou automatiser le processus de signature d'une manière ou d'une autre?

RÉSUMÉ: Deux solutions ont été présentées: 1) allumez le autosignmaître, ignorant ainsi complètement la certification, ou 2) définissez l'ancien CNAME pour pointer vers le nouveau maître, car les certificats sont liés au nom d'hôte du maître. J'ai choisi # 2 parce que la signature automatique avait l'impression de désactiver la sécurité (quoique pour une durée limitée).

ssl-certificate puppet

— monsieur
source

3

Cherchez-vous à garder les deux maîtres de marionnettes opérationnels et à migrer les clients un peu à la fois?

Si c'est le cas, vous êtes bloqué de toucher chaque système client indépendamment; que ce soit pour pointer vers un nouveau maître, ou ajouter une entrée de fichier d'hôtes, ou quelque chose du genre. Si c'est le cas, vous pouvez tout aussi bien démarrer le nouveau maître à nouveau et signer à nouveau chaque client (c'est mieux qu'un hack de fichier hosts pour contourner les problèmes de validation).

Si ce n'est pas le cas (si vous prévoyez de supprimer l'ancien serveur et de tout couper en une seule fois), alors prenez simplement le nom d'hôte de l'ancien serveur avec le nouveau serveur; le certificat sera reconnu comme valide si les clients se connectent au nouveau serveur sur l'ancien nom (le nom qui figure sur le certificat).

— Shane Madden
source

Oui, la question était de savoir s'il était possible d' automatiser la re-signature de chaque client. Je pense que vous y avez répondu en soulignant que les certificats sont liés au nom d'hôte que le client utilise pour atteindre un serveur particulier, donc si je réutilise le nom d'hôte, je pourrai réutiliser les certificats. Merci!

— mrisher

Eh bien, un simple puppetca --sign --allfera l'affaire pour les certificats clients; celui du serveur est celui qui vous pose des problèmes avec les erreurs de non-concordance.

— Shane Madden

3

Vous pouvez simplement utiliser celui $ssldirde l'ancien marionnettiste et l'utiliser dans le nouveau marionnettiste.

À part cela, il devrait être possible de déployer un script qui:

(Sans rapport avec le script client: activer éventuellement la signature automatique sur le nouveau serveur de marionnettes)
courir un peu plus tard
arrêter le client marionnette
nettoyer le client ssldir
modifier le puppet.conf sur le client pour pointer vers le nouveau serveur
créez un fichier de verrouillage pour vous assurer qu'il ne provoque pas une boucle de reconfiguration sans fin
recommencer la marionnette

Moche mais tant que le module de migration ne se trouve que sur l'ancien serveur et qu'il n'y a pas de module de migration uniquement sur le nouveau serveur, c'est une chose unique et devrait faire la magie ...

— Martin M.
source

Salut: L' autosignastuce est bonne, mais semble risquée. Sans elle, cette solution résout-elle réellement le problème de non-concordance du certificat client?

— mrisher

C'est le cas, la signature automatique est juste la façon paresseuse de ne pas avoir à traiter avec des milliers de clients qui seront nouveaux sur le marionnettiste. Le concept est le même, la différence est que les clients qui ont migré vers le nouveau maître ne feront aucun travail à moins d'être signés

— Martin M.