On 9/4/2012 5:01 PM, Matthew Morgan wrote:
Hi All,
Sorry if this has been asked before but I am not entirely sure what to
search for so as to get the answer I am looking for.
I have recently started using puppet to manage our servers (we have 30
at the moment) and I have been posed the question of whether I wholesale
change configs or make changes within. The reason this was asked is in
the case of the following simplified example.
Lets say I am managing the MySQL package and I would like it to stay up
to the latest stable version, this is easy to implement. Lets then say
that the latest MySQL version also makes a default change to the
/etc/mysql/my.cnf configuration file that effects performance/security.
As it stands this change would get lost because I am using a template to
create the my.cnf config.
The only way I can think of covering this problem is to essentially do a
sed style operation and make all the changes I require in the my.cnf and
add the lines if they aren't there.
Is there a better way to approach this issue?
Cheers for the help, Matthew
My hypothesis is your unique and carefully balanced system is more
likely to have problems when change is introduced by package managers
that aim towards a common denominator than your locally tested configs
in Puppet. Your example of Mysql is a near perfect jumping off point for
this.
The my.cnf shipped with any distro is completely inappropriate for
anything beyond a simple dev server. My my.cnf has a single line
'!includedir /etc/mysql/conf.d/' and then I set the behavior I want in
conf.d/innodb.cnf conf.d/general.cnf conf.d/replication.cnf and so forth
which are all Puppet templates. Also as late 5.0.x (IIRC) Mysql was not
guaranteed to use parse order for a setting which meant sometimes your
conf.d/ files were effectively ignored if the setting occurred in other
files.
I don't believe any package update will overwrite an existing config
even in the event of a CVE, but I haven't verified that. A normal
upgrade should also not affect the daemon config. If it does, we have
the same problem, which is adhoc/unknown/untracked changes to your
system. They may be for your own good, but they are still changes you
are not specifically introducing and could break functionality you
depend on.
Regardless of agreement to the above the question ultimately becomes
how do you introduce change into your system? Does Puppet introduce
change or another methods? Multiple methods? Do you try to manage all
things or only the parts that need it?
Managing all configs in Puppet should be the most precise solution, but
the payoff for the time involved on your system might not be worth it. I
usually make the choice based on the daemon in question though I lean
towards completely owning the config 80% of the time. It does take
slightly longer to bring a new distro or distro version into the repo
when you manage the config completely. I think the tradeoff is worth it
for the assurance that daemon configs, while possibly out of date, are
completely managed.
Ramin
--
You received this message because you are subscribed to the Google Groups "Puppet
Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
