[chef] Re: RE: Re: Re: Appending to an existing file, i.e nginx site

[AJ Christensen < >]

All,

In the case of Ubuntu (and Debian, I suppose), this probably trickles
down to Mint as well, Heavy Water operations often find that the
defaults are poorly constructed examples copied straight from the
source code of the original software; even moreso could cause great
damage if deployed and used in a system without understanding the
implications of defaults.

I definitely don't hold my vendor in such high regard! Frankly; I'd
like to strip or bypass config files (& service definitions) out of
packages altogether. The asset-bundle or omnibus-stack packages we
build are generally created in this manner.

--skip-config-files --skip-services --skip-users --skip-groups
--dont-pretend-to-be-config-management

If the vendor default configuration file never existed; the service
would not start. The service would not even exist!

You wouldn't have to edit single lines of files contained in the
software you are deploying if it was part of the procedure for
deploying your software (this mirrors 90+% of ours):

- research config
- construct a configuration file
- instrument configuration for automation
- install stripped packages
- deploy users and groups
- deploy configuration
- deploy services

I hope this offers some insight in-to how we have solved countless
deployments over disparate time-zones totaling Node counts in the
thousands across the prime Unixes.

A final point I would like to make: it is possible to re-open a
template Resource in the Compile DSL and add additional data to the
'variables' parameter; in rare occasions we use this to modify a
template from multiple sources during compile phase, i.e.: credentials
for a database, additional URLs for a site, etc. You can use Bryan
Berry's chef-rewind [0] or the old-school form for this:

```
r = begin
  resources(:template => 'the_resource_name')
rescue Chef::Exceptions::ResourceNotFound
   template('the_resource_name') { .... }
end

r.variables(
 foo: 'bar',
 baz: 'bong )
```

Cheers, HTH!

AJ

[0] https://github.com/bryanwb/chef-rewind

On 20 March 2013 04:26, Kevin Keane Subscription
<
 >
 wrote:
> +1
>
> No, it's not a practical edict, and in many cases it can be very
> counterproductive and even cause security problems.
>
> The chef philosophy is that you don't edit partial files, but only generate
> a complete copy of a configuration file. I can understand where that's
> coming from. In many cases, it does make sense - but in my mind this
> approach is vastly overused in chef. In a few cases, chef itself actually
> breaks the philosophy - that's why there are resources to manage /etc/fstab
> and /etc/exports, for instance.
>
> The main issue I have with it isn't even with global files such as
> /etc/sysctl.conf or /etc/hosts.
>
> The far bigger elephant in the room is that distribution vendors usually
> provide well-tuned configuration files that shouldn't be clobbered, but
> rather surgically manipulated.
>
> That said, the surgical approach can be very difficult to implement in a
> generalized way. Multiline context-sensitive edits are non-trivial; for
> instance, the nginx configuration file. You have to be able to detect not
> just whether the appropriate entry exists with all the multiple lines in
> place, but also that it actually is in the right place; you can't just
> append it to the end of a file and expect it to work.
>
> To make matters even more complicated, nginx configuration file support
> including other files.
>
> So to make this work, you have three options:
>
> - Create a one-off solution that encodes a lot of assumptions about how your
> particular configuration file is structured.
> - Implement a complete parser that understands nginix configuration files
> and translates it into something like json/XML/DOM, then allows you to
> manipulate it, and write out only the manipulated parts.
> - Generate the complete configuration file.
>
> So, in this specific scenario, and many similar ones, I can understand where
> AJ's statement came from. It's just vastly overused.
>
>
> -----Original message-----
>> From:Michael Della Bitta 
>> <
 >
>> Sent: Tuesday 19th March 2013 7:29
>> To: 
>> 
 
>> Subject: [chef] Re: Re: Appending to an existing file, i.e nginx site
>>
>> On Mon, Mar 18, 2013 at 4:24 PM, AJ Christensen 
>> <
 >
>> wrote:
>> > Please don't edit files that already exist. Please never do this.
>>
>> Is that really a practical edict? What about files like
>> /etc/sysctl.conf needing to be written to by multiple recipes?
>>
>> FileEdit works, but it gets a bad rap on this list. Chef's going to
>> need a canonical and supported way to do this...
>>
>>
>> Michael Della Bitta
>>
>> ------------------------------------------------
>> Appinions
>> 18 East 41st Street, 2nd Floor
>> New York, NY 10017-6271
>>
>> www.appinions.com
>>
>> Where Influence Isn’t a Game
>>