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? 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.... -- 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/14d325de-6d68-46dc-bd2f-17f80e1378fc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
