/etc/hosts from template, instead of hostsfile and fqdn cookbooks


#1

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.com


#2

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.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.com

Peter Burkholder — Customer Success Engineer

Availability: no travel/OOO scheduled

301-204-5767 – pburkholder@chef.io – *my: *Linkedin
http://www.linkedin.com/in/pburkholder Twitter
http://www.twitter.com/pburkholder Cal
https://www.google.com/calendar/embed?src=pburkholder%40chef.io&mode=WEEK
endar

CHEF

CHEF.IO http://www.chef.io/

TM

chef.io http://www.chef.io/ Blog http://www.chef.io/blog/ Facebook
https://www.facebook.com/getchefdotcom Twitter
https://twitter.com/chef Youtube https://www.youtube.com/getchef


#3

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

From: Peter Burkholder [mailto:pburkholder@chef.io]
Sent: Wednesday, January 28, 2015 2:34 PM
To: 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-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


#4

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

Cheers,

Peter

On Thu, Jan 29, 2015 at 4:32 PM, Nico Kadel-Garcia <
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.com

From: Peter Burkholder [mailto:pburkholder@chef.io]
Sent: Wednesday, January 28, 2015 2:34 PM
To: 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:

https://www.youtube.com/watch?v=3JTlcnEpWD4

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.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.com

Peter Burkholder — Customer Success Engineer

Availability: no travel/OOO scheduled

301-204-5767 – pburkholder@chef.io – *my: *Linkedin
http://www.linkedin.com/in/pburkholder Twitter
http://www.twitter.com/pburkholder Cal
https://www.google.com/calendar/embed?src=pburkholder%40chef.io&mode=WEEK
endar

CHEF

CHEF.IO http://www.chef.io/

TM

chef.io http://www.chef.io/ Blog http://www.chef.io/blog/
Facebook https://www.facebook.com/getchefdotcom Twitter
https://twitter.com/chef Youtube https://www.youtube.com/getchef

Peter Burkholder — Customer Success Engineer

Availability: no travel/OOO scheduled

301-204-5767 – pburkholder@chef.io – *my: *Linkedin
http://www.linkedin.com/in/pburkholder Twitter
http://www.twitter.com/pburkholder Cal
https://www.google.com/calendar/embed?src=pburkholder%40chef.io&mode=WEEK
endar

CHEF

CHEF.IO http://www.chef.io/

TM

chef.io http://www.chef.io/ Blog http://www.chef.io/blog/ Facebook
https://www.facebook.com/getchefdotcom Twitter
https://twitter.com/chef Youtube https://www.youtube.com/getchef


#5

On Fri, Jan 30, 2015 at 8:32 AM, Nico Kadel-Garcia <
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.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.io]
Sent: Wednesday, January 28, 2015 2:34 PM
To: 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:

https://www.youtube.com/watch?v=3JTlcnEpWD4

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.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.com

Peter Burkholder — Customer Success Engineer

Availability: no travel/OOO scheduled

301-204-5767 – pburkholder@chef.io – *my: *Linkedin
http://www.linkedin.com/in/pburkholder Twitter
http://www.twitter.com/pburkholder Cal
https://www.google.com/calendar/embed?src=pburkholder%40chef.io&mode=WEEK
endar

CHEF

CHEF.IO http://www.chef.io/

TM

chef.io http://www.chef.io/ Blog http://www.chef.io/blog/
Facebook https://www.facebook.com/getchefdotcom Twitter
https://twitter.com/chef Youtube https://www.youtube.com/getchef


#6

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-5767pburkholder@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


#7

On Tue, Jun 2, 2015 at 12:36 AM, Nico Kadel-Garcia <
nkadel@skyhookwireless.com> wrote:

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.

Generally its not a good practice to make the FQDN point to localhost, but
people love to do it!
What I preferred to address was ‘permanent ip support’ via the permanent_ip
attribute (
http://www.debian.org/doc/manuals/debian-reference/ch05.en.html#_the_hostname_resolution
).

Nico Kadel-Garcia
Email: nkadel@gmail.com
Sent from iPhone

On May 27, 2015, at 19:51, “Chris Fordham” chris@fordham-nagy.id.au
wrote:

On Fri, Jan 30, 2015 at 8:32 AM, Nico Kadel-Garcia <
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.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.io]
Sent: Wednesday, January 28, 2015 2:34 PM
To: 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:

https://www.youtube.com/watch?v=3JTlcnEpWD4

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.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.com

Peter Burkholder — Customer Success Engineer

Availability: no travel/OOO scheduled

301-204-5767 – pburkholder@chef.io – *my: *Linkedin
http://www.linkedin.com/in/pburkholder Twitter
http://www.twitter.com/pburkholder Cal
https://www.google.com/calendar/embed?src=pburkholder%40chef.io&mode=WEEK
endar

CHEF

CHEF.IO http://www.chef.io/

TM

chef.io http://www.chef.io/ Blog http://www.chef.io/blog/
Facebook https://www.facebook.com/getchefdotcom Twitter
https://twitter.com/chef Youtube https://www.youtube.com/getchef