[chef] Re: managing system files with Chef

[Bryan McLellan < >]

On Thu, May 5, 2011 at 9:03 AM, Sascha Bates 
<
 >
 wrote:
> Chef wants to manage config files as templates.  I get that.  I'm wondering
> how people are handling system configuration files that are large and
> sometimes unwieldy?  For example, in Red Hat, the /etc/sendmail.cf  is 700
> lines and we update just one.  Should I really keep a template or cookbook
> file for something like that?  We are running primarily RH4 and RH5 and have
> identified the following choices for system configuration files:

If there is a variable that I'm setting, I'll usually use a template.
If I'm patching a file, for instance I recently had to make a one line
change to a Wordpress file, I'll use cookbook_file.

> Appropriate them as templates or manage them with complex string
> substitution in ruby/bash blocks and manual checks to enforce idempotence.

I think the fact that you used the word "complex" there makes it the
losing choice. At least with templates you can follow the code and it
should be more straightforward.

> The first has pitfalls.  We shouldn't be managing system files at that
> level.  Patching should be an automated process, and trying to keep an eye
> on system files during the patch process is not something I'm interested in.

Can you give a use case? I'm not sure exactly what you mean by
managing system files.

In the case of my wordpress example, I consider it a temporary hack
and that the fix should be upstreamed. I tied the cookbook file to the
wordpress release using only_if. My rule of thumb is that managing any
file with Chef that comes out of a deb package that isn't recognized
as a config file by the package should be temporary.

sendmail.cf is a configuration file though, I don't see why you
wouldn't want to manage it with Chef as a template.

>  Also it means that only one recipe can ever manage that file.  In most
> cases that's fine, but in others, it won't work.  Example: I have two
> different cookbooks that add keys to the root authorized_keys file in some
> cases.  Or what if two different things want to insert things in the
> modprobe.conf?  I have a system config recipe that inserts lines into the
> modprobe.conf to disable IPv6 and a KVM recipe that inserts the kvm module
> lines.

In both cases, you want to upfactor the code to another cookbook and
have either a definition or an LWRP that you call from the other
cookbooks to make the change. How you do this depends on a couple
things, like if you have '.d' functionality for what you're changing.
In the case of modprobe on Ubuntu, I would have a definition that
creates a modprobe.d/resource.conf file for each call, similar to the
iptables_rule definition [1]. In the case of an authorized_keys file,
you could have a definition that walks the file when called to ensure
that the line is there and appends if it is not.

On Thu, May 5, 2011 at 9:22 AM, Sascha Bates 
<
 >
 wrote:
> Yes, but I won't necessarily know that one of my system files was patched
> and then overwritten by a template will I?  So that goes both ways.

If Chef manages the file, then your process needs to be that all
changes go through Chef. It becomes the authoritative source for the
file. You should always avoid one-offs by changing files manually
anyway.

Bryan

[1] 
https://github.com/opscode/cookbooks/blob/master/iptables/definitions/iptables_rule.rb