Is it possible to disable hosts file editing with hostname resource? (chef-client 14)
I edit hosts file with template.
set the ipaddress on the resource to nil
Hosts file is still being edited.
hostname node.name do
ipaddress nil
end
@coul if you are managing /etc/hosts from your templates, hostname resource is not required. it will overwrite your /etc/hosts when ohai reload. just make sure you use node["ipaddress"] value collected by ohai with your template.
Managing /etc/hosts with a template is probably the most effective way to manage it. The hostname cookbook is not so much your friend. It does not clear mismatched or obsolete lines from /etc/hosts, it adds designated entries line by line.
I published some tools a ways back at an old workplace, visible at https://github.com/nkadel-skyhook/nkadel-chef-hosts . It was published under an Apache v2.0 license, so it’s open for use. I no longer work at that company, so getting fresh licensing to publish it as an official cookbook is something I’ve not pursued as I’ve found new work. But it’s a solid small cookbook and supports “roles” or wrapper programs, with hashes, to pupulate /etc/hosts from a simple template.
@suthir I am managing /etc/hosts with my template and I don’t need hostname resource for it. But I need it (hostname resource) to set my servers hostname and to be sure it won’t change.
Best solution is to fix your DNS. managing /etc/hosts can become a nightmare. But I concur with the group, best means is via a template. https://supermarket.chef.io/cookbooks/hostsfile/versions/0.1.1 will let you add and remove entries. I would probably create a wrapper cookbook to initialize the /etc/hosts they way I wanted it then use the hostfile cookbook to manage it.
Robust, fully enabled DNS is an ideal solution. So are pretty pink angels to guide the electrons to form the right signals magically, in many working environments. Cloud environments, like AWS instances require some out-of-band system to either create node configurations with hard-coded hostnames in them as new nodes are deployed, or require successful node registration in chef to provide a basis for configuring the new DNS based on node discovery, and you wind up with a chicken and egg problem. Deploying virtual images of similar hosts that may have been previously chef registered presents a similar issue: the node has the old hostname, or a cloud provider issued hostname based on the IP address such as those used by AWS EC2 instances. Admittedly, those are in Amazon’s internal DNS with forward and reverse DNS already, and it’s possible to register those as chef nodes, but it’s difficult to read such names and to track sets of servers with such names.
You can set up CNAME’s and set a hostname on the instance, but that still doesn’t get the hostname reported usably to “hostname --fqdn”, which is effectively what chef uses. And updating DNS takes time. Even with tools like Amazon’s “Route53”, it can take 15 minutes to publish the new DNS. amd “hostname --fqdn” won’t work until that is propagated. Neither does registering the new chef clients.
Do you really want to have to wait 15 minutes or so, every time you build a new AWS image before you can reliably run chef-client? I thought not. That’s why the very quick and dirty hack of checking the value of $HOSTNAME, and dropping it into /etc/hosts with this command works so well when DNS is not pre-set robustly, buth forward and reverse, before deployment.
echo "127.0.0.1 $HOSTNAME" >> /etc/hosts
Then you can bootstrap the host, quite successfully and consistently, and have the other chef components work much more sanely based on hostname. There are other ways to do this, but I’ve found this effective for years. If desired, you can even use it with the chef server to audit an AWS VPC or a local otherwise determined list of hosts to generate a role for the “hosts” cookbook I publish and use it to avoid the need for split DNS or a local DNS server in a small environment.