Setting puppet up to use a dns alias as a servername

[buoyant_puppy]

Can I configure puppet to use a DNS name that would work on two different hosts? For example, I have host1 and host2.example.com.
I'd like agents to connect to "puppet.example.com" which will point to one of these. I wamt to be sure agents can connect to either without certificate errors.

How do I configure the puppet.conf certname/servername, and generate the master certificate such that agents will happily connect to host1 and host2 without complaining?

I've experimented and googled but can't seem to figure out what's the right approach.

[Gavin Williams]

'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.

HTH

Gav

[jcbollinger]

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

[buoyant_puppy]

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?

Another option was to do a normal install using host1.example.com (adding all possible names as dns_alt_names). Which works fine on host1, and agents can reach it at puppet.example.com, but I have issues when trying to restore this onto host2. All the documented restore processes seem to assume you are restoring to a host with the same original hostname (which, unfortunately, isn't something I can count on at my company).

I follow the restore process pieced from the official docs: install puppet, restore all the puppet files including puppet.conf, ssl dir, etc.
Then, I update puppet.conf certname/servername to host2.example.com instead of host1.
Then, puppet master --no-daemonize --verbose -> so that it creates host2.example.com certs

Now I do a full puppetdb restore and recreate its certs (because they too point to host1), documented at:
https://puppet.com/docs/pe/2017.3/maintenance/back_up_and_restore_a_pe_installation.html
https://puppet.com/docs/pe/2016.5/regenerate_certs_puppetdb.html

(BTW I had to do the same cert copying steps for nginx as for puppetdb, or else nginx wouldn't start).

At this point puppetserver and postgres will start, but puppetdb isn't ok. It will stay in a start loop, giving me these errors every half a minute or so:
PDBMigrationsPool - Connection is not available, request timed out after 15000ms.
Caused by: org.postgresql.util.PSQLException: The hostname host2.example.com could not be verified.

Postgres log isnt very informative either:
connection received: host=<host2.example.com's IP> port=45892
could not receive data from client: Connection reset by peer

But as far as I can tell postgres is working.

What have I missed? I feel like I'm close....

[jcbollinger]

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.

John

[buoyant_puppy]

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.

[jcbollinger]

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