Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

I installed chef-client on a Linux node, and it seems to have successfully connected to my chef server. However, when I do: chef node list, it appears as "localhost".

Why doesn't chef pick up the proper name of the node? If I ask for more details, I see:

$ chef node show localhost
node Name:   localhost
Environment: _default
FQDN:        localhost
IP:          192.168.1.5
Run List:    
Roles:       
Recipes:     
Platform:    ubuntu 11.10

It has a proper domain name set up. For example, if I do: hostname, it returns "mynodename", not "localhost".

How is chef determining the name of the node? And why does it have the proper name showing in FQDN?

EDIT: In response to cjc below, here's some of the output from ohai | grep host:

(Note: this node is running on EC2)

"fqdn": "localhost",
"hostname": "mynodename",
"public_hostname": "ec2-...-.amazonaws.com",
"local_hostname": "ip-...ec2.internal",
"hostname": "ip-...ec2.internal",

Also, hostname -s is giving the expected output:

$ hostname -s
mynodename
share|improve this question

4 Answers 4

up vote 5 down vote accepted

The reason seems to be that ohai is running hostname --fqdn, which does give "localhost".

The root cause of the problem seems to be that I set the hostname as "mynodename" instead of "mynodename.example.com". If I do:

sudo hostname mynodename.example.com

Then it does the right thing when I do: hostname --fqdn

share|improve this answer

I have the same problem. It does seem to be the ohai thing. But it is a bit deeper. The best test is to see whether hostname --fqdn returns something reasonable.

It comes down to the hosts file. Setting hostname with sudo hostname my.fqdn won't work. Strictly speaking this should not be necessary because system names are distinct from domain names. But systems that do reverse lookup easily get confused. bottom line, in your etc/hosts file your fqdn should be the first entry after the ip address if that is what you want returned, e.g.

127.0.0.1 myserver.mydomain.com myserver localhost # works, return fqdn

127.0.0.1 localhost myserver.mydomain.com myserver # this will return localhost

127.0.0.1 myserver myserver.mydomain.com localhost # this will return myserver

If you look in the default etc/hosts file you will see that ubuntu uses 127.0.1.1 as well as 127.0.0.1. that is because of situations like this. Having the host name on a separate ip address (which is still loopback valid) ensures a clean mapping between the system name and the domain name.

share|improve this answer

On Amazon AMI instances based on RHEL 5 and 6. In that case, look at:

/etc/sysconfig/network

I suspect the is configured as such with:

HOSTNAME=localhost
DOMAINNAME=localhost

In that case, make the correction with:

HOSTNAME=mynodename
DOMAINNAME=mynodename.example.com

On Debian-type Linux instances (such as Ubuntu), you would look at the following file for the hostname:

/etc/hostname

And make the change there.

share|improve this answer
    
This was an Ubuntu instance. –  Lorin Hochstein Jan 24 '12 at 19:54
    
My mistake. Updated answer. –  Rilindo Jan 24 '12 at 19:58

chef-client uses ohai when setting up the node. What do you get when you run ohai |grep host ?

Glancing through the ohai source in lib/ohai/plugins, for the linux provider, I see that it basically runs "hostname -s", so that's a bit mysterious, given your results.

Could the hostname have been set after chef-client ran?

share|improve this answer
    
No, hostname was definitely set before chef-client ran. Node was up and running with hostname set before chef-client was installed. –  Lorin Hochstein Jan 24 '12 at 18:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.