20

I seem to be running into a little bit of a problem understanding how to get this to work. I have a new server I'm building sitting behind the office NAT at work, its reverse dns maps to office.mydomain.com, but I want the machine to be ns2.mydomain.com for the sake of puppet.

nodes.pp snippet:

node 'ns2.mydomain.com' inherits basenode {
  info('ns2.mydomain.com')
}

node 'office.mydomain.com' inherits basenode {
  info('office.mydomain.com')
}

And my 'puppet.conf' on the client:

[main]
#was node_name=ns2.mydomain.com
#was fqdn=ns2.mydomain.com
certname=ns2.mydomain.com
node_name=cert

My syslog on the server reports:

Sep 16 22:59:12 support puppetmasterd[2800]: Host is missing hostname and/or domain: office.mydomain.com
Sep 16 22:59:12 support puppetmasterd[2800]: (Scope(Node[office.mydomain.com])) office.mydomain.com
Sep 16 22:59:12 support puppetmasterd[2800]: Compiled catalog for office.mydomain.com in 0.03 seconds
Sep 16 22:59:12 support puppetmasterd[2800]: Caching catalog for ns2.mydomain.com

How can I make it grab the config for ns2.mydomain.com without doing something like this:

node 'ns2.mydomain.com' inherits basenode {
  info('ns2.mydomain.com')
}

node 'office.mydomain.com' inherits 'ns2.mydomain.com' {
  info('office.mydomain.com')
}

UPDATE: This problem seems to be causing other issues as well. For instance if I info("$fqdn") while the machine is sitting behind office.mydomain.com the fqdn fact is empty, as well as the $operatingsystem. Its almost like the facts aren't being discovered properly. Is there perhaps a NAT issue? Are there any suggestions for tracking down this cause of this problem?

gnarf
  • 713

2 Answers2

25

Aaah, Puppet hostname detection. What a nightmare...

By default, what name will be used to find which node definition to use is based on the contents of the fqdn fact. What that actually maps to is dependent on a few different things, and yes, reverse DNS is one of them -- and it's preferred over the machine's own hostname!

However, this name (usually) only applies at certificate generation time. You're actually misusing the node_name variable -- it should be set to one of 'cert' or 'facter'. The fqdn parameter is also deprecated.

What you actually want to do is set the certname parameter on the client to the node name you want to use, and then set node_name to cert (or just leave it out, since cert is the default). This will take the node name from the CN of the certificate that the client presents, and the certname parameter makes sure that's set to something reasonable rather than whatever facter decides to come up with on it's own. Unfortunately, since you've already got "wrong" certs created, you'll need to regenerate those certs (rm -rf /var/lib/puppet/ssl on the client and re-run Puppet) after you've setup the config, so that the right certs get created and used.

If this all sounds a little complicated, you're right -- it is. Welcome to Puppet.

womble
  • 97,049
  • Hey there - so looking at puppetmaster and puppet - both have node_name=cert, updated cert_name=ns1.mydomain.com and facter fqdn returns ns1.mydomain.com on the client but I am still ending up with the same error messages about office.mydomain.com. – gnarf Sep 17 '09 at 14:44
  • 1
    re: certname, you're right, I misremembered and didn't check the docs like I should have. Regarding the lack of fixination, you need to regenerate the client cert; I've updated my answer to cover that. – womble Sep 17 '09 at 20:26
  • 1
    Actually - my cert file is ns1.mydomain.com.pem and its CN is also ns1... That is "correct" right? office.mydomain.com is what it is using as its node name, and apparently whenever its trying to grab facts when parsing, instead of using the cert name as the node name. Perhaps I'm missing something else? None of my facts seem to be transmitted through to the parser either info($fqdn) just shows an empty line in the scope I put it in. – gnarf Sep 17 '09 at 20:49
  • I don't know what you've done, but you managed to bone something up reaaaaally good. I think you're on your own. – womble Sep 17 '09 at 22:27
  • Another update: I managed to get all the stuff "pre-setup" from behind the office lan and put the new nameserver live - as soon as it started using the correct reverse DNS, all the facts showed up properly... – gnarf Sep 18 '09 at 19:00
5

I seem to be having good luck (although there are still a few test cases I want to see) in editing /etc/hosts to list the desired fqdn under 127.0.0.1 as the first option. It seems to be detecting it correctly / passing facts then. Although it seems I still need to create a node called office.mydomain.com that inherits the node I want.

gnarf
  • 713