Ask Your Question
0

Switching to/from SRV REC for Puppet Server / CA Discovery [closed]

asked 2016-03-19 11:50:18 -0500

DroidBurgundy gravatar image

updated 2016-03-19 12:49:50 -0500

I have a medium sized infrastructure of 231 nodes being serviced by one main Puppet Server / CA. All nodes are running CentOS 7.

Puppet Server:

  • puppetserver version: 1.1.3
  • puppet version: 3.8.6
  • ruby version: 2.0.0p598

Puppet Agents:

  • puppet version: 3.8.5
  • ruby version: 2.0.0p598

All of the agents use srv records to know which CA and puppet server to contact (agent's puppet.conf):

[agent]
    use_srv_records = true
    srv_domain = aws.domain.com

I needed to change the PuppetCA that was servicing all of the agents so I began by setting all puppet agents to no longer use srv records and set them to use a newly built puppet CA / server instead. Set the new Puppet Server / CA to autosign all and set a different ssldir for puppet agent use so that the new Puppet Server / CA would sign and issue new valid certs (agent's puppet.conf):

[agent]
-   use_srv_records = true
-   srv_domain = aws.domain.com

[main]
+   server = puppetca2.aws.domain.com
+   ssldir = /etc/puppet/ssl2

These first batch of changes went out and all of the puppet agents received new certificates and I could see them getting catalogs from the new Puppet Server/ CA "puppetca2.aws.domain.com". The next step was to copy over the new ssl certs & keys to the default dir so I added the following to all nodes in their puppet provisioning:

file { '/etc/puppet/ssl':
  source  => 'file:///etc/puppet/ssl2',
  recurse => true,
  purge   => true,
  force   => true,
}

This ran for a while on all nodes, and eventually the two ssl dirs on every puppet agent were identical. I then ran the following to remove the ssl2 dir:

file {'/etc/puppet/ssl2':
  ensure  => absent,
  recurse => true,
  purge   => true,
  force   => true,
}

and I removed the entry in their puppet.conf file to use that ssl dir to allow all puppet agents to use the default "/etc/puppet/ssl" which now contained the new certs from "puppetca2.aws.domain.com" (agent's puppet.conf):

[main]
-   ssldir = /etc/puppet/ssl2

At this point each puppet agent was pointing to the new Puppet Server / CA box and all seemed well. I then went to update the SRV RECS in route53 for puppet and thats when things got weird.

I set the following SRV RECS the domain of the Puppet Agents:

_x-puppet-ca._tcp.aws.domain.com 0 100 8140 puppetca2.aws.domain.com
_x-puppet._tcp.aws.domain.com 0 100 8140 puppetca2.aws.domain.com

I can confirm that the SRV RECS are set in DNS locally on one of the nodes:

[root@pupagent001 ~]# host -t SRV _x-puppet-ca._tcp.aws.domain.com
_x-puppet-ca._tcp.aws.domain.com has SRV record 0 100 8140 puppetca2.aws.domain.com.
[root@pupagent001 ~]# host -t SRV _x-puppet._tcp.aws.domain.com
_x-puppet._tcp.aws.domain.com has SRV record 0 100 8140 puppetca2.aws.domain.com.

I then removed the server setting form the Puppet Agent's puppet config and added in the srv records again.

agent's puppet.conf ... (more)

edit retag flag offensive reopen merge delete

Closed for the following reason the question is answered, right answer was accepted by DroidBurgundy
close date 2016-03-19 15:01:43.433777

Comments

Notices on PuppetLabs docs that "SRV records don’t interact well with static servers set in the config file" hopefully this doesn't mean you can't switch back and forth between the two methods? https://docs.puppetlabs.com/guides/scaling_multiple_masters.html#option-4-dns-srv-records

DroidBurgundy gravatar imageDroidBurgundy ( 2016-03-19 12:03:03 -0500 )edit

1 Answer

Sort by » oldest newest most voted
0

answered 2016-03-19 14:59:43 -0500

DroidBurgundy gravatar image

sigh DNS spelling error was the cause of this dilemma :(

edit flag offensive delete link more

Question Tools

1 follower

Stats

Asked: 2016-03-19 11:50:18 -0500

Seen: 187 times

Last updated: Mar 19 '16