I’ll look at it, thank you. In the meantime, I’ve been working low priority on a fork if one of the older ‘hosts’ cookbooks. I just published a fresh tag at https://github.com/nkadel-skyhook/nkadel-chef-hosts.
That’s working very well for me, and handles ‘FQDN as loopback optional’ and ‘FQDN as ipaddress optional’ especially well. That solves a whole set of weird problems with remote clusters with local, back end IP addresses.
Nico Kadel-Garcia
Email: nkadel@gmail.commailto:kadel@gmail.com
Sent from iPhone
On May 27, 2015, at 19:51, “Chris Fordham” <chris@fordham-nagy.id.aumailto:chris@fordham-nagy.id.au> wrote:
On Fri, Jan 30, 2015 at 8:32 AM, Nico Kadel-Garcia <nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com> 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
nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com
Hi Nico,
You may be interested in my system cookbook (https://github.com/xhost-cookbooks/system) which implements this in I think a nice way.
In particular the last release I did last night, 0.6.4 is much better.
If there is a use case that’s not covered properly please let me know via raising a github issue on the repo and I’ll do my best to address it in an elegant way.
Cheers,
Chris aka flaccid
From: Peter Burkholder [mailto:pburkholder@chef.iomailto:pburkholder@chef.io]
Sent: Wednesday, January 28, 2015 2:34 PM
To: chef@lists.opscode.commailto:chef@lists.opscode.com
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 <nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com> 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
nkadel@skyhookwireless.commailto:nkadel@skyhookwireless.com
–
Peter Burkholder — Customer Success Engineer
Availability: no travel/OOO scheduled
301-204-5767tel:301-204-5767 – pburkholder@chef.iomailto:pburkholder@chef.io – my: Linkedinhttp://www.linkedin.com/in/pburkholder Twitterhttp://www.twitter.com/pburkholder Calhttps://www.google.com/calendar/embed?src=pburkholder%40chef.io&mode=WEEKendar
CHEF
CHEF.IOhttp://www.chef.io/
TM
chef.iohttp://www.chef.io/ Bloghttp://www.chef.io/blog/ Facebookhttps://www.facebook.com/getchefdotcom Twitterhttps://twitter.com/chef Youtubehttps://www.youtube.com/getchef