Puppet-Clients auf neuen Puppetmaster migrieren


8

Wie kann ich unsere vorhandenen Puppet-Clients migrieren, um auf einen neuen Puppetmaster-Server zu verweisen? Ich möchte lieber nicht manuell zu jeder Client-Box gehen und ein neues Zertifikat generieren.

Beim Versuch des Offensichtlichen - rsync alle Dateien von / etc / puppet und / var / lib / puppet auf den neuen Server - haben wir den Zertifikatfehler erhalten

/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

Ich konnte das umgehen, indem ich die /var/lib/ssl/certsund /var/lib/ssl/private_key-Dateien von old_hostnamenach kopierte. Dies new_hostnamewird im Grunde bei der Migration von Puppet-Clients auf einen neuen Puppet-Master empfohlen (alter Puppet-Master-Server weg, nur mit Backup).

Leider wissen meine Kunden immer noch, dass etwas nicht stimmt, und geben mir den folgenden Fehler:

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

Ich vermute also, dass die Client-Zertifikate immer noch den Hostnamen kennen, mit dem sie verknüpft sind, und sich nicht über einen Wechsel freuen.

Gibt es eine Möglichkeit, mit Marionette (die auf den alten Puppenmeister verweist) neue Zertifikate bereitzustellen oder den Signaturprozess irgendwie zu automatisieren?

ZUSAMMENFASSUNG: Es wurden zwei Lösungen vorgestellt: 1) Aktivieren Sie autosignden Master, wodurch die Zertifizierung vollständig übersprungen wird, oder 2) Setzen Sie den alten CNAME so, dass er auf den neuen Master verweist, da Zertifikate an den Hostnamen des Masters gebunden sind. Ich habe mich für Nummer 2 entschieden, weil Autosign das Gefühl hatte, die Sicherheit nur auszuschalten (wenn auch nur für eine begrenzte Zeit).

Antworten:


3

Möchten Sie beide Puppenmeister eine Zeit lang am Laufen halten und Kunden nach und nach migrieren?

In diesem Fall berühren Sie nicht jedes Client-System. ob es auf einen neuen Master verweist oder einen Hosts-Dateieintrag oder einen ähnlichen hinzufügt. Wenn dies der Fall ist, können Sie den neuen Master genauso gut neu starten und jeden Client neu signieren (es ist besser als ein Host-Datei-Hack, um die Validierungsprobleme zu umgehen).

Wenn nicht (wenn Sie vorhaben, den alten Server herunterzufahren und alles auf einmal zu entfernen), übernehmen Sie einfach den Hostnamen des alten Servers mit dem neuen Server. Das Zertifikat wird als gültig erkannt, wenn die Clients unter dem alten Namen (dem Namen auf dem Zertifikat) eine Verbindung zum neuen Server herstellen.


Ja, die Frage war, ob es möglich ist, die Neuunterzeichnung jedes Clients zu automatisieren . Ich denke, Sie haben darauf geantwortet, indem Sie darauf hingewiesen haben, dass die Zertifikate an den Hostnamen gebunden sind, den der Client verwendet, um einen bestimmten Server zu erreichen. Wenn ich also den Hostnamen wiederverwendete, kann ich die Zertifikate wiederverwenden. Vielen Dank!
Mrisher

Nun, ein einfacher puppetca --sign --allwird den Trick für die Client-Zertifikate tun; Der Server ist derjenige, der Ihnen Probleme mit den Nichtübereinstimmungsfehlern gibt.
Shane Madden

3

Sie können einfach den $ssldirdes alten Puppenspielers verwenden und diesen im neuen Puppenspieler verwenden.

Ansonsten sollte es möglich sein, ein Skript bereitzustellen, das:

  • (Nicht mit dem Client-Skript verbunden: Aktivieren Sie möglicherweise das automatische Signieren auf dem neuen Puppet-Server.)
  • etwas später laufen
  • Puppenklient stoppen
  • Bereinigen Sie den Client ssldir
  • Ändern Sie die pupet.conf auf dem Client so, dass sie auf den neuen Server verweist
  • Erstellen Sie eine Sperrdatei, um sicherzustellen, dass keine endlose Rekonfigurationsschleife auftritt
  • Starten Sie die Puppe erneut

Hässlich, aber solange sich das do-Migrationsmodul nur auf dem alten Server befindet und sichergestellt ist, dass es kein Migrationsmodul gibt, befindet es sich nur auf dem neuen Server. Es ist eine One-Shot-Sache und sollte einfach die Magie machen ...


Hi: Der autosignTrick ist gut, scheint aber riskant. Behebt diese Lösung ohne sie tatsächlich das Problem der Nichtübereinstimmung von Clientzertifikaten?
Mrisher

Autosign ist nur die faule Art, nicht mit Tausenden von Kunden umgehen zu müssen, die für den Puppenspieler neu sind. Das Konzept ist das gleiche. Der Unterschied besteht darin, dass Clients, die auf den neuen Master migriert sind, nur dann arbeiten, wenn sie unterschrieben sind
Martin M.
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.