FAQ
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.

Search Discussions

  • Justin Ellison at Sep 5, 2012 at 2:12 pm
    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.
  • Stefan Heijmans at Sep 5, 2012 at 3:30 pm
    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.
  • Ramin K at Sep 5, 2012 at 9:22 pm

    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.
  • Matthew Morgan at Sep 5, 2012 at 11:53 pm
    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.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedSep 5, '12 at 9:26a
activeSep 5, '12 at 11:53p
posts5
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase