[chef] Re: RE: Re: /etc/hosts from template, instead of hostsfile and fqdn cookbooks


Chronological Thread 
  • From: Peter Burkholder < >
  • To: " " < >
  • Subject: [chef] Re: RE: Re: /etc/hosts from template, instead of hostsfile and fqdn cookbooks
  • Date: Thu, 29 Jan 2015 16:38:52 -0500

Fair enough. True that if each entry is managed as a resource then you have to manage entry removal.

You may not want/need the overhead of a 'community' cookbook but do a hash unpack into a template. e.g https://code.facebook.com/posts/1615663495327304/facebook-configuration-management-community-and-open-source/

Cheers,

Peter

On Thu, Jan 29, 2015 at 4:32 PM, Nico Kadel-Garcia < " target="_blank"> > wrote:

The hostsfile cookbook works very well for exactly what it is designed to do: provide powerful LWRP’s for editing individual /etc/hosts entries. However, to use it, one has to wrap it with or into another cookbook that manages all possible relevant hosts, including loopback addresses. And when one *changes* a host to another IP address, your recipe has to know enough to delete the old address and set the new address. You also have to build a complete structure to both add your entries, and to delete whatever old entries may be in place, to build a complete /etc/hosts. This can be awkward to manage. I suggest that it would be much cleaner and faster to configure for most environments to work from a template with a few entries for loopback addresses, some options for enabling the fqdn as a loopback and/or as the chef detected IP address, and a simple hash of IP addresses and text fields to populate a complete /etc/hosts.

 

This would not replace hostsfile: using hostsfile would either mandate separately publishing the same entries hostsfile would generate in various recipes, , but it could be quite useful especially for initial system configuration. It’s particularly more stable than the current ‘fqdn’ cookbook, which tries to set up the loopback addresses but has a number of longstanding issues I reported from a previous role.

 

Nico Kadel-Garcia

Lead DevOps Engineer

" target="_blank">

 

 

From: Peter Burkholder [mailto: " target="_blank"> ]
Sent: Wednesday, January 28, 2015 2:34 PM
To: " target="_blank">
Subject: [chef] Re: /etc/hosts from template, instead of hostsfile and fqdn cookbooks

 

This cookbook? https://github.com/customink-webops/hostsfile

 

There's a lot of history behind that cookbook:

 

 

and there are 0 open issues with the project. If it's not working for you then you should open an issue with more specific, esp. if there are problems with its dependencies on other cookbooks. Example code that you would like to have working, or that fails, would be helpful in the issue.

 

If I'm missing the point, let me know.

 

Cheers,

 

Peter

 

 

 

On Wed, Jan 28, 2015 at 11:25 AM, Nico Kadel-Garcia < " target="_blank"> > wrote:

I'm dealing with some systems that need internal /etc/hosts entries. I've noticed privously that the hostsfile cookbook is powerful, and flexible, but it really deals with one entry at a time, and that entry is based on the IP address. It can be awkward to clear other entries. And combined with the incomplete and hard-coded settings for the fqdn cookbook, it makes complete control of the /etc/hosts file very awkward.

I think this should, ideally, be a template based cookbook with these features:

    * Several entries for normal loopbacks.
    * A separate and optional line for an FQDN based loopback
    * A separate and optional line for host IP based FQDN addresses.
    * A hash or array of IP addresses with a plain stored text field of hostnames and, if desired, comments

That's easy and straightforward to reprogram on an environment or role basis. The difficulty I see is where, for whatever reason, dozens or hundreds of hosts have the same IP address. This is typically tiled to a loopback address used for local filtering, and can often be done more simply than via DNS. In that case, I'd need to have an index for the hash based on some other field, or the IP based index will have hostname fields that are much too large.

This would also make the current 'fqdn' cookbook a lot easier,

So I've wound up with some questions:

    1) Has someone else already done this? I can't seem to find a workable such cookbook elsewhere.
    2) Is it worth the effort to write and publish?
    3) Is it worth the effort to have an index other than the IP address?


Nico Kadel-Garcia
Lead DevOps Engineer
" target="_blank">



 

--

Peter Burkholder — Customer Success Engineer

Availability: no travel/OOO scheduled

301-204-5767 –  " target="_blank">  – my: Linkedin  Twitter  Calendar

CHEF

CHEF.IO

TM

chef.io   Blog   Facebook   Twitter   Youtube  

 




--

Peter Burkholder — Customer Success Engineer

Availability: no travel/OOO scheduled

301-204-5767 –  " target="_blank">  – my: Linkedin  Twitter  Calendar

CHEF

CHEF.IO

TM

chef.io   Blog   Facebook   Twitter   Youtube  





Archive powered by MHonArc 2.6.16.

§