Puppet users - Sep 2012 - How to automatically implement default configuration changes made by a package upgrade

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

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/RRXJ0p22e90J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi Matthew,

Some of this depends on your package manager.  For example, on RedHat, if 
you take puppet completely out of the picture:
1) I install mysql from yum
2) I modify my.cnf
3) I upgrade mysql via yum

In this case, if there was a configuration change to my.cnf by redhat, I 
won''t get them.  Instead, the new configuration file will be created at
/etc/mysql/my.cnf.rpmnew, and it''s up to me to do the diffing and
merging
on my own. I''m not for sure what Debian/Ubuntu do in these cases.  So
you
see, it''s more of a package management question.

However....

Puppet will support you if you choose to implement your configurations in a 
certain way.

Example:
1) I install mysql via yum
2) I make my configuration changes in /etc/mysql.d/network.conf

This is considered best practice by most exactly because of this reason -- 
your changes are in a file that is separate from, and overrides the shipped 
configuration file.  When using puppet, it''s not different from doing
it
yourself.

Also, some daemons support ".d includes" like that, but the actual
"Include
/etc/mysql.d" statement isn''t enabled in the default configuration
file
shipped by the upstream maintainer.  In cases such as that, I either use 
file_line() from puppetlabs-stdlib, or if it''s more involved, augeas 
resources will handle that too.  Both of those are better than resorting to 
exec + sed.

Hope that helps,

Justin

On Tuesday, September 4, 2012 7:01:06 PM UTC-5, 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
>
-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/8aNJz4MmCnAJ.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Hi Matthew,

We are on Red Hat and do the following with config files which will be 
updated after yum update.

- our own customized config files of the rpm are in Puppet with an addon 
for rpm name&version (for instance; files/lvm.conf_lvm2-2.02.88-7.el5)
- we have a custom facter which determines this version (for instance; 
facter lvm2version)
- when we do an update in our sandbox environment the new rpm will create 
rpmnew (for instance; /etc/lvm/lvm.conf.rpmnew)
- after update we check on all created rpmnew/rpmsave files
- do a puppet run with noop, it will stop as there is no new version of the 
config file in Puppet available
- we merge the current and rmpnew into a new config file in Puppet 
(files/lvm.conf_lvm2-3.02.88-7.el5)
- do a puppet run and should be fine, new config file with Red Hat changes 
and our own changes.

Stefan


 

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/tAnhkbEAVd4J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

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+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

I can''t believe I didn''t think about the conf.d directory.  I
have it set
up for that and just skipped over that last line.

Ramin, I agree with you about wanting to control introducing change into 
the system. We have grown from a very small team with only a couple servers 
to what we are today rather quickly. So now taking that control away from 
certain members of the team shall be an interesting challenge. I will have 
to formulate an argument around those ideas before trying to takle that 
one.  In the meantime I have a sandbox environment set up for just such 
things and will be quietly doing something similar anyway.

Thanks heaps for the help all.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/RJ67TnI26Y8J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.