default puppetmaster is highly unusual

[anarcat]

I was surprised to find that this module configures nodes to connect to themselves by default. For example, this configuration:

include puppet

will (correctly) configure a puppet agent to run on the given node, but will (incorrectly, IMHO) tell it to connect to $fqdn. In my case, this yields the error:

Error: Could not request certificate: Failed to open TCP connection to curie.anarc.at:8140 (Connection refused - connect(2) for "curie.anarc.at" port 8140)

curie.anarc.at is my workstation here. it should instead try to connect to puppet or puppet.$DOMAIN which is puppet.anarc.at in my case.

this change from standard breaks over a decade of convention in the puppet discovery process. i find it quite surprising and can't think of a reason for it.

i believe it should be changed to just nothing: no server line should be added to puppet.conf unless provided by the user, in which case the upstream puppet agent defaults will apply (as they should).

(mistakenly filed against theforeman/puppet-foreman#864 originally)

[anarcat]

i believe this is the code in question:

puppet-puppet/manifests/config.pp

Lines 53 to 55 in f63fdaa

	puppet::config::main {
	'server': value => pick($puppetmaster, $facts['networking']['fqdn']);
	}

[ekohl]

this change from standard breaks over a decade of convention in the puppet discovery process. i find it quite surprising and can't think of a reason for it.

I think the reason is simply historical. 8dfda8a is the first that did it this way and it looks like we didn't change this (other can coding style) since 2012.

I'm open to changing this, but need some time to think about how to best deal with this in our installer. In the short term, I think the best workaround is passing an empty string to the puppetmaster parameter.

[anarcat]

I think the reason is simply historical. 8dfda8a is the first that did it this way and it looks like we didn't change this (other can coding style) since 2012.

This begs the question of why you had to talk to fqdn in the first place...?

I'm open to changing this, but need some time to think about how to best deal with this in our installer. In the short term, I think the best workaround is passing an empty string to the puppetmaster parameter.

For now i passed 'puppet', but i guess that would work as well?

[ekohl]

This module was typically used in an ENC where the puppetmaster was provided. That meant that the fqdn fallback was only used on the master itself. That was used on fresh installs and made a sane default in the bootstrap process.

[anarcat]

well that's the thing - if you do this on the master, the default puppet would also probably work, unless DNS is misconfigured (in which case fqdn might fail too anyways)... so i think it could be safely flipped back...

[ekohl]

That's not true for most environments we deploy in. The unqualified puppet has never resolved in environments where I worked while FQDN pretty much always works.

[anarcat]

That's not true for most environments we deploy in. The unqualified puppet has never resolved in environments where I worked while FQDN pretty much always works.

how do nodes find their master then?

[ekohl]

We always provisioned and made sure the correct puppet.conf was set up during kickstart/preseed. Foreman has the correct value.

[nod0n]

I fell in the trap to and did set it to 'puppet' and this works for me as I would expect it.

[sshipway]

I'm late to this discussion, but we avoided this by just enabling SRV records for our domain and setting puppet::use_srv_records:true.
I agree that a more sensible default than $::fqdn would be "puppet"