I suspect there might simply be different philosophies (and markets) behind different distributions here. As far as I can tell, RedHat seems to do a very good job in this area, probably because of their different market. When they put Enterprise in their name, and expect people to pay for support, this is one of the areas they pay particular attention to.
Ubuntu tries to stay at the very cutting edge of technology, and targets more desktops than servers (although plenty people do use it on servers). Given this different focus, what you are saying doesn't completely surprise me.
I haven't played around with Fedora much lately, but I suspect it is more like Ubuntu; it is where these types of things get shaken out before it makes it into the Enterprise Linux version.
Another consideration is simply manpower. Can the Opscode+chef community in the long run sustain rewriting all kinds of configuration files from scratch (and maintain that across version updates!), when Canonical+Ubuntu community apprently doesn't do a good job despite close to ten times the number of employees? And RedHat has yet 10 times as many employees. That concern is why I would much rather see chef stay as close to the native configuration as possible.
-----Original message-----
> From:AJ Christensen < "> >
> Sent: Tuesday 19th March 2013 12:53
> To: chef < "> >
> Subject: [chef] Re: RE: Re: Re: Appending to an existing file, i.e nginx site
>
> 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
> >>
>
Archive powered by MHonArc 2.6.16.