Brian Mathis wrote:

> Another reason that people use Enterprise Linux distributions is
> because they don't do silly things like overwrite config files that
> you've already edited every time you update the package.  No one would
> stand for that.  Also, they don't change the packages around so you
> suddenly have a totally new package version with a completely new
> config file scheme.

But they can still introduce work-arounds for security vulnerabilities
in new config files, that you must get into your config files to take
advantage of.  I vaguely remember some vulnerability found in sshd, which
you could mitigate by turning on or off some feature in sshd_config, and
RedHat pushed out RPM:s with that feature changed from its earlier value.
If you hadn't changed your sshd_config file locally, it got updated,
otherwise you needed to check for .rpmnew files to find what they had
changed (or track the security advisory to know it anyway).

> At some point you have to have config files that tells the system how
> to act, and you have to change them.  Any file that you didn't create
> completely by yourself at some point came out of the package system
> somewhere.  You would just have to edit them and the package system
> would have to know how to handle it.
> 
> Based on all the evidence and discussions about it, I think you should
> forget about editing files and instead keep copies as recommended.
> There are so many people doing it successfully, the market has spoken.

There are also a lot of us who think that mode of operation sucks.
If you keep entire files in your repository, you will never take advantage
of improvements that your vendor gives you.  You can't see the difference
between parameters that you actually care about, and parameters that you
don't care about, and trust the OS vendor to set to reasonable values.

In /etc/sysctl.conf in CentOS 5.2, there are 10 parameters set.  Some of
those 10 I care about (ip_forward and rp_filter), and set explicitly.  Some
I have no idea what a reasonable value is (e.g, kernel.msgmax), and I don't
want to keep track of them.  Other config files may have parameters that
matters a lot to other parts of the OS distribution, but what the correct
value should be varies between, e.g, CentOS 4, CentOS 5, Fedora 8, Fedora 10
or Debian Etch.

I have also used editfiles (in Cfengine) to make patches to startup scripts,
to work around bugs or limitations in them.

I edit /boot/grub/grub.conf to remove the "rhgb" and "quiet" flags on the
kernel lines, to remove the "hiddenmenu" directive, and to change the
timeout value.  Keeping that file as an entire file in my repository would
be disastrous!

Yes, there are advantages to copying entire files.  But there are also some
large *dis*advantages.  It varies from config file to config file which mode
works best (and of course from site to site), though.


The lack of an "editfiles" type in Puppet was to horrible to stand, so I
wrote a few custom types to do some useful file editing.  You can find them
at <http://groups.google.com/group/puppet-users/msg/203da69a6994d8e1>.
Be warned, however, that I have never tried them with puppetd/puppetmasterd,
only with standalone puppet.

Many of the problems mentioned in the "Editfiles Considered Harmful" article
stems from the Cfengine editfiles language.  In Puppet you can do better.
Not the least because you can create defines saying more specifically what
you are doing; for example, I have defines named 'portage_makeconf' for
setting options in /etc/make.conf (for Portage in Gentoo Linux),
'portage_useflags' to set USE flags for packages, gentoo_conf manipulating
options in /etc/conf.d/*, 'rh_sysconfig to set options in /etc/sysconfig/*
on RedHat/Fedora, 'sysctl' to define sysctl settings in /etc/sysctl.conf,
and 'exportfs' to edit /etc/exports.  And of course, we already have types
like 'host', 'cron', 'mailalias', 'sshkey', 'yumrepo', and an entire bunch
of 'nagios_*' types in stock Puppet.  And do you know what -- they edit files!


        /Thomas Bellman

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to