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?
-
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'. Thefqdn
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 setnode_name
tocert
(or just leave it out, sincecert
is the default). This will take the node name from the CN of the certificate that the client presents, and thecertname
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.
gnarf : 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`.womble : 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.gnarf : 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.womble : I don't know what you've done, but you managed to bone something up reaaaaally good. I think you're on your own.gnarf : 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...From womble -
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 calledoffice.mydomain.com
that inherits the node I want.From gnarf
0 comments:
Post a Comment