On Friday, May 4, 2018 at 3:13:41 PM UTC+2, jcbollinger wrote: > > > > On Thursday, May 3, 2018 at 9:54:11 AM UTC-5, buoyant_puppy wrote: >> >> >> >> On Wednesday, May 2, 2018 at 2:59:33 PM UTC+2, jcbollinger wrote: >>> >>> >>> >>> On Wednesday, May 2, 2018 at 6:25:37 AM UTC-5, Gavin Williams wrote: >>>> >>>> 'dns_alt_names' is the config you're looking for... >>>> >>>> >>>> https://puppet.com/docs/puppetserver/5.1/scaling_puppet_server.html#creating-and-configuring-compile-masters >>>> >>>> provides more info on running multiple Puppet servers. >>>> >>> >>> It is covered in the referenced doc (scroll both up and down), but it's >>> worth highlighting that using a single CA for the whole site is a key >>> detail, too. >>> >>> >>> John >>> >> >> >> Thanks, however that seems to be only part of the solution. To clarify, >> I'm trying to make my monolithic puppet installation restoreable to a new >> server. For DR scenarios, or future migration for example. >> Agent connection SSL issues should be solved with the dns_alt_names, but >> there are other issues. >> >> I hoped I could simply set the certname and servername to my dns alias, >> puppet.example.com. My host's actual name, host1.example.com, would not >> be used anywhere (except as one of the dns_alt_names), and I'd configure >> everything in puppet to point to puppet.example.com. This generates keys >> named after that hostname (as one would expect), like >> puppet.example.com.pem. However, on startup, both puppetserver and puppetdb >> look for keys host1.example.com.pem, and so they fail to start (ssl-cert >> not found). >> "puppet config print" shows it should look for certs named after >> puppet.example.com - under both agent and master sections (I tried every >> which way), so I don't get why this happens. So my first question: is there >> any way to make this work? >> > > > It sounds like you may be trying to be too clever. Have you tried just > generating a new cert for the new master (preserving the original CA > cert)? I'm shooting a bit from the hip, here, but that's what I would > expect to be required given your clarification that you are changing the > identity of the master (in the form of changing its hostname). > > This is very much like adding a new master to a pool, as described in the > doc Gavin pointed you toward. It just happens that you are also removing > the original master from the pool. This is no big deal if you are set up > properly for pooling in the first place -- which is where dns_alt_names and > a shared CA come in -- except that you must transfer the CA to the new > master. If this is something you want to accommodate more easily, however, > then it might make sense to move the CA off to its own dedicated machine. > > What you describe is exactly what I thought I was doing (in my second approach, starting from the line "Another option" in my earlier mail). The doc Gavin sent doesn't help here, because that's just about getting the puppet server working on a new hostname - that part is fine. The current issue (and with luck it's maybe the last issue) is puppetdb. In the doc on compile masters, the puppetdb (and CA, and other components) are not covered, because they remain on the original master.
-- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/e050e8fa-6388-4df7-8419-d7e95c8699a3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
