Before you reply that I should just give the node the right name in the first place… The scenario is that I’m bootstrapping brand new machines via a hosting provider api, and when the machine first starts the only name it has is its ip address. Via that I get the RDNS provided by the hosting provider, and use that as the initial node name. Then chef runs and registers the client/node. Then the appropriate roles are applied to the node and the machine is configured and starts doing its designated job. But… the node now has a silly machine generated name… it’d be nice if I could easily rename them easily.
It sounds like you are talking about changing the hostname on the
nodes? Here is how I do that:
On Fri, Apr 2, 2010 at 1:16 PM, John Merrells john@merrells.com wrote:
How would I go about renaming a node?
Before you reply that I should just give the node the right name in the first place... The scenario is that I'm bootstrapping brand new machines via a hosting provider api, and when the machine first starts the only name it has is its ip address. Via that I get the RDNS provided by the hosting provider, and use that as the initial node name. Then chef runs and registers the client/node. Then the appropriate roles are applied to the node and the machine is configured and starts doing its designated job. But... the node now has a silly machine generated name.... it'd be nice if I could easily rename them easily.
But is there a way to rename the node object that lives within the chef sever?
I was expecting to find this....
knife node rename node_before node_after
But it seems that I'd have to get, create, delete to simulate a rename, having
copied the run_list over.
The other thing I don't grok yet is the relationship between the client name,
the node name, and the hostname. When chef client registers itself it creates
a client and a node with the hostname for their name and creates a certificate
for the client.... but.... if i change the hostname of the machine is it going to
break the authentication of the client using the client certificate? Hmm...
thinking out load really.
The other thing I don't grok yet is the relationship between the
client name,
the node name, and the hostname. When chef client registers itself
it creates
a client and a node with the hostname for their name and creates a
certificate
for the client.... but.... if i change the hostname of the machine
is it going to
break the authentication of the client using the client certificate?
Hmm...
thinking out load really.
Chef uses the "node_name" value for the "client_name" when it
registers the new client with the API.
By default, the "node_name" comes from the FQDN as detected by ohai
(via hostname -f). You can override this setting in the client.rb by
setting node_name explicitly:
On Apr 2, 2010, at 10:46 AM, Joshua Timberman wrote:
On Apr 2, 2010, at 11:42 AM, John Merrells wrote:
The other thing I don't grok yet is the relationship between the client name,
the node name, and the hostname. When chef client registers itself it creates
a client and a node with the hostname for their name and creates a certificate
for the client.... but.... if i change the hostname of the machine is it going to
break the authentication of the client using the client certificate? Hmm...
thinking out load really.
Chef uses the "node_name" value for the "client_name" when it registers the new client with the API.
By default, the "node_name" comes from the FQDN as detected by ohai (via hostname -f). You can override this setting in the client.rb by setting node_name explicitly:
This isn't easily managable or scalable but for a one-off system it's okay.
Thanks.
I think that only helps me if I know what the hostname is going to be before chef-client runs for the first time. Currently, as a quirk of the hosting provider API the machine doesn't know that. I should probably push on that.
btw - does chef require that the hostname be resolvable? Or does it just have to look like a fqdn?
Your FQDN doesn't need to resolve via DNS. Even just 'localdomain'
will get the job done.
Dan DeLeo
On Fri, Apr 2, 2010 at 10:54 AM, John Merrells john@merrells.com wrote:
On Apr 2, 2010, at 10:46 AM, Joshua Timberman wrote:
On Apr 2, 2010, at 11:42 AM, John Merrells wrote:
The other thing I don't grok yet is the relationship between the client
name,
the node name, and the hostname. When chef client registers itself it
creates
a client and a node with the hostname for their name and creates a
certificate
for the client.... but.... if i change the hostname of the machine is it
going to
break the authentication of the client using the client certificate? Hmm...
thinking out load really.
Chef uses the "node_name" value for the "client_name" when it registers the
new client with the API.
By default, the "node_name" comes from the FQDN as detected by ohai (via
hostname -f). You can override this setting in the client.rb by setting
node_name explicitly:
This isn't easily managable or scalable but for a one-off system it's okay.
Thanks.
I think that only helps me if I know what the hostname is going to be before
chef-client runs for the first time. Currently, as a quirk of the hosting
provider API the machine doesn't know that. I should probably push on that.
btw - does chef require that the hostname be resolvable? Or does it just
have to look like a fqdn?
John
On Apr 2, 2010, at 10:46 AM, Joshua Timberman wrote:
On Apr 2, 2010, at 11:42 AM, John Merrells wrote:
The other thing I don't grok yet is the relationship between the client name,
the node name, and the hostname. When chef client registers itself it creates
a client and a node with the hostname for their name and creates a certificate
for the client.... but.... if i change the hostname of the machine is it going to
break the authentication of the client using the client certificate? Hmm...
thinking out load really.
Chef uses the "node_name" value for the "client_name" when it registers the new client with the API.
By default, the "node_name" comes from the FQDN as detected by ohai (via hostname -f). You can override this setting in the client.rb by setting node_name explicitly:
This isn't easily managable or scalable but for a one-off system it's okay.
I'm still stuck with this.
If the machine starts with fqdn A and the chef client registers a new node on the chef server with name A, then the client starts fine. If I then create a chef server node named B, with the webui, and then change the hostname of the machine from A to B, in /etc/hosts and /etc/hostnames and reboot, then the client silently fails to connect to the server. If I then go into client.rb and set node_name=A then all is happy again. If I go ohai | grep fqdn then I do get back B.....
The only thing I can think of is that the silence is a feature of the security system.... so the client cert is now busted in some way... so the client cert must be connected to the hostname somehow?
If the machine starts with fqdn A and the chef client registers a new node on the chef server with name A, then the client starts fine. If I then create a chef server node named B, with the webui, and then change the hostname of the machine from A to B, in /etc/hosts and /etc/hostnames and reboot, then the client silently fails to connect to the server. If I then go into client.rb and set node_name=A then all is happy again. If I go ohai | grep fqdn then I do get back B.....
The only thing I can think of is that the silence is a feature of the security system.... so the client cert is now busted in some way... so the client cert must be connected to the hostname somehow?
Worked it out. So, yes, the client key includes the node_name, so I had to delete /etc/chef/client.pem, making sure that the validation.pem was there, and then I restarted the chef client, which caused it to create a new client key for the new node name.
This means that the cookbook that Michael Hale pointed out...
...probably only works if the client.rb already contains the node_name declaration.