[chef-dev] Re: Re: Re: Re: Re: Re: edit a file using chef


Chronological Thread 
  • From: Bryan McLellan < >
  • To: Aaron Peterson < >
  • Cc: Adam Jacob < >, Christopher Brown < >, AJ Christensen < >, Bryan Berry < >, " " < >, " " < >
  • Subject: [chef-dev] Re: Re: Re: Re: Re: Re: edit a file using chef
  • Date: Mon, 18 Jun 2012 11:54:47 -0400

On Sun, Jun 17, 2012 at 1:40 AM, Aaron Peterson 
< >
 wrote:
> What would interest me is knowing how promoting file edit to a resource
> could perhaps help people who find themselves wanting/ needing/ thinking
> they need to use file edits.

Why Chef::Util::FileEdit:

In 2009 January, I wrote the initial cron provider. While some
distributions provide cron.d support, many don't. We knew this would
be messy, but being able to manage cron was pretty important. At the
time I needed cron to migrate some applications to Chef from another
configuration management utility (this was before I worked at
Opscode).

In 2009 April, Opscode wrote FileEdit. I wasn't part of the internal
discussion, but I recall wanting it and talking to Adam about that.

In 2010 January, I wrote the upstart service provider. Upstart has
'desktop' tinted glasses and at the time required editing a file to
disable an installed service from starting on boot [1]. I used
FileEdit for this.

The cron provider has not been updated to use FileEdit, but it should
some day. As we've found edge cases, we've gained more unit tests for
the cron provider, which should help a lot with the refactoring.
Obviously there is strength in reusing code to handle all the edge
cases of a dangerous operation like editing a file in place.

Why file_edit:

The system crontab is a good example of the utility of FileEdit. You
could provide it as a template, but you'll need to write an LWRP to
manage the entries provided by different cookbooks as well as a way to
get the distributions entries in there. If the cron provider didn't
exist, you could use a file_edit provider [if it existed] to keep
moving along. There are likely additional use cases, particularly on
legacy systems.

I've used software packages in the past with huge and daunting
configuration files which act as defaults but they're sometimes not
clearly organized and commented. Then their diffs change drastically
between revisions. Managing these in Chef can be more of an
undertaking than one desires.

The apt cacher-client recipe has to update the apt.conf file:
https://github.com/opscode-cookbooks/apt/blob/master/recipes/cacher-client.rb#L22

There are plenty of use cases off on the edges. As we find big ones we
have been adding resources for them.

As far as idempotency goes, we will have to write the provider to
handle this for a few use cases and add more as they come along.

# Hack to make Pluto Service work
file_edit "/etc/rc.local" do
  action :add
  string "/use/local/plutod real_planet=1"
end
## Should add the line if it doesn't exist

# sometimes the advisory board of planets breaks this planet
file_edit "/usr/local/etc/pluto.conf" do
  action :edit
  matches "real_planet="
  string "real_planet=1"
end
## Should edit the line if it matches and isn't equal

The cron provider puts in a comment with the resource name as an index
rather than using a particular field, there might be a use case for
similar functionality in file_edit.

Bryan


[1] https://bugs.launchpad.net/upstart/+bug/94065



Archive powered by MHonArc 2.6.16.

§