On Monday, May 7, 2018 at 4:23:35 AM UTC-5, buoyant_puppy wrote: > > > > 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. >
Looking more carefully at your clarifications, I see that Postgres logs a successful connection, and then reports that the connection was reset by the peer. If we are to believe that this characterization of the interaction is accurate, then, in light of the other information you've provided, my interpretation is that *PuppetDB* closes the connection, not PG. Combining that with the exception message leads me to conclude that the PG server is still using a cert that was issued to the original host(name), not the new one. It's unclear to me whether that should be surprising given the steps you describe performing. I am not sufficiently conversant with the details of configuring Postgres for PuppetDB to confidently recommend a way forward from this point, but inasmuch as you are referencing PE docs, I infer that as a paying customer you have access to Puppet, Inc. technical support. In addition to helping you complete the recovery, they may be able to recommend a mechanism that renders this overall recovery process easier in this regard, maybe along the lines of dns_alt_names but for the Postgres cert. John -- 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/06963a96-f8b5-4246-b25b-906f38bd5fa7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
