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] GitHub - bryanwb/chef-rewind: monkeypatch chef to edit existing resources in place
On 20 March 2013 04:26, Kevin Keane Subscription
subscription@kkeane.com 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 michael.della.bitta@appinions.com
Sent: Tuesday 19th March 2013 7:29
To: chef@lists.opscode.com
Subject: [chef] Re: Re: Appending to an existing file, i.e nginx site
On Mon, Mar 18, 2013 at 4:24 PM, AJ Christensen aj@junglist.gen.nz
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