FAQ
Hello,

I work at a university and my colleagues and I are considering Puppet for
installing and configuring our linux workstations. Being a university we
have a great variety in users, some very adept at maintaining their own
system and some not so much. Now we were wondering(and I can't find it in
the documentation or on the intarwebz), can Puppet detect if a user has
changed a *.conf file him(her)self and NOT do anything to that *.conf file?
Since we have about 200 users now, which will probably grow to almost a
1000, we don't want to create different nodes which we than have to fill
manually for the users who do know what they're doing.
So my question is, can Puppet detect a user change on a file and in that
case don't do anything, where it would normally replace the file?

Tanks in advance.

--
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/-/PWG44Y9LnTQJ.
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

  • Nan Liu at Jun 14, 2012 at 4:31 pm

    On Thu, Jun 14, 2012 at 6:00 AM, PorkCharSui wrote:
    I work at a university and my colleagues and I are considering Puppet for
    installing and configuring our linux workstations. Being a university we
    have a great variety in users, some very adept at maintaining their own
    system and some not so much.  Now we were wondering(and I can't find it in
    the documentation or on the intarwebz), can Puppet detect if a user has
    changed a *.conf file him(her)self and NOT do anything to that *.conf file?
    Since we have about 200 users now, which will probably grow to almost a
    1000, we don't want to create different nodes which we than have to fill
    manually for the users who do know what they're doing.
    So my question is, can Puppet detect a user change on a file and in that
    case don't do anything, where it would normally replace the file?
    If you just care about when content changes.

    file { '/etc/sudoers':
    audit => content,
    }

    Upon changes you will see:
    notice: /Stage[main]//File[/etc/sudoers]/content: audit change:
    previously recorded value {md5}d41d8cd98f00b204e9800998ecf8427e has
    been changed to {md5}c157a79031e1c40f85931829bc5fc552

    If you have content you want to compare but not change the file:

    file { '/etc/sudoers':
    source => 'puppet:///...',
    noop => true,
    }

    HTH,

    Nan

    --
    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.
  • Nick Fagerlund at Jun 14, 2012 at 6:09 pm

    On Thursday, June 14, 2012 6:00:21 AM UTC-7, PorkCharSui wrote:
    ... can Puppet detect if a user has changed a *.conf file him(her)self and
    NOT do anything to that *.conf file?
    Nope! Puppet has no good way to tell the difference between:

    - A user using sudo to deliberately change a file,
    - A rogue or malicious process overwriting the file,
    - A package update replacing the file with a boilerplate one that lacks
    the modifications you need

    As far as I know, that kind of knowledge always has to come from
    out-of-band; there's nothing intrinsic in the file that can tell you about
    intent.

    But so anyway. Some possible approaches:

    - Investigate the file type's replace => false capability, for
    initializing files and then not managing content afterwards.
    - If you're comfortable having users able to edit their puppet.conf
    files, use environments. If a user changes their environment from
    "production" to "manual," you can have a selector statement in all of your
    conf file resources that sets the source (or content) to undef, which makes
    it unmanaged. This is good because environments show up in reports, so you
    can tell how many of your users have switched into manual mode.
    - If you aren't comfortable with opening up puppet.conf, you could also
    do the same thing with a fact, using the facts.d plugin in the
    puppetlabs-stdlib module. (Facts.d lets you treat the contents of a plain
    text file as a custom fact, and then expose that text files to users as a
    config file.)


    --
    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/-/nSkZNChOpokJ.
    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.
  • Brian Gallew at Jun 14, 2012 at 10:32 pm
    I had exactly this situation: I wanted to manage application configuration,
    but developers wanted to be able to alter the configs as necessary, yet
    still revert to the "real" config when they wanted. It's a snap with a
    define{}:

    <pre>
    # We would like to both distribute configuration files as well as
    # enable the developers to make their own changes without having them
    # overriden. This define is for doing that. You probably want to
    # have good defaults set with File{} so that the file is created with
    # the appropriate permissions.
    #
    # Usage:
    #
    # managed_file { "/export/home/geek/festus": source =>
    "puppet:///modules/foo/bar" }
    #
    # In /export/home/geek, two files will be create: README.festus and
    # festus-puppet. The README file will contain a message telling the
    # reader to touch festus.noupdate to prevent Puppet from updating the
    # file. As long as the festus.noupdate file does NOT exist, Puppet
    # will ensure that festus matches festus-puppet.
    #
    define managed_file($source = undef, $content = undef) {
    $pdir = inline_template("<%= name.reverse().split('/',2)[1].reverse() %>")
    $basename = inline_template("<%= name.split('/')[-1] %>")

    file {
    "${name}-puppet":
    source => $source, content => $content, ensure => present;
    "${pdir}/README-${basename}":
    ensure => present,
    content => "${name} is managed by Puppet.\n\nIf you need to
    edit\n${name}\nand have your changes persist, touch\n${name}.noupdate\nand
    Puppet will ignore that file. When you are done with your\ntesting, please
    have your changes put in Puppet and delete the\n${name}.noupdate\nfile.
    Thanks.\n\n";
    }

    exec {
    "${name}-sync":
    unless => "test -f ${name}.noupdate || cmp -s ${name} ${name}-puppet",
    command => "/usr/local/bin/rsync -a ${name}-puppet ${name}",
    require => File["${name}-puppet"];
    }
    }
    </pre>
    On Thu, Jun 14, 2012 at 11:09 AM, Nick Fagerlund wrote:


    On Thursday, June 14, 2012 6:00:21 AM UTC-7, PorkCharSui wrote:

    ... can Puppet detect if a user has changed a *.conf file him(her)self
    and NOT do anything to that *.conf file?
    Nope! Puppet has no good way to tell the difference between:

    - A user using sudo to deliberately change a file,
    - A rogue or malicious process overwriting the file,
    - A package update replacing the file with a boilerplate one that
    lacks the modifications you need

    As far as I know, that kind of knowledge always has to come from
    out-of-band; there's nothing intrinsic in the file that can tell you about
    intent.

    But so anyway. Some possible approaches:

    - Investigate the file type's replace => false capability, for
    initializing files and then not managing content afterwards.
    - If you're comfortable having users able to edit their puppet.conf
    files, use environments. If a user changes their environment from
    "production" to "manual," you can have a selector statement in all of your
    conf file resources that sets the source (or content) to undef, which makes
    it unmanaged. This is good because environments show up in reports, so you
    can tell how many of your users have switched into manual mode.
    - If you aren't comfortable with opening up puppet.conf, you could
    also do the same thing with a fact, using the facts.d plugin in the
    puppetlabs-stdlib module. (Facts.d lets you treat the contents of a plain
    text file as a custom fact, and then expose that text files to users as a
    config file.)

    --
    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/-/nSkZNChOpokJ.

    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.
    --
    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.
  • PorkCharSui at Jun 15, 2012 at 8:05 am
    Wow... thanks all,

    Very nice to see there such an active community! You've all given me some
    great things to work with and ponder about. But the define seems exactly
    what we need here Brian, although environments have the nice advantage of
    being registered. Well... I know I'll be experimenting for a while :).

    Thanks again!


    On Friday, June 15, 2012 12:32:36 AM UTC+2, Brian Gallew wrote:

    I had exactly this situation: I wanted to manage application
    configuration, but developers wanted to be able to alter the configs as
    necessary, yet still revert to the "real" config when they wanted. It's a
    snap with a define{}:

    <pre>
    # We would like to both distribute configuration files as well as
    # enable the developers to make their own changes without having them
    # overriden. This define is for doing that. You probably want to
    # have good defaults set with File{} so that the file is created with
    # the appropriate permissions.
    #
    # Usage:
    #
    # managed_file { "/export/home/geek/festus": source =>
    "puppet:///modules/foo/bar" }
    #
    # In /export/home/geek, two files will be create: README.festus and
    # festus-puppet. The README file will contain a message telling the
    # reader to touch festus.noupdate to prevent Puppet from updating the
    # file. As long as the festus.noupdate file does NOT exist, Puppet
    # will ensure that festus matches festus-puppet.
    #
    define managed_file($source = undef, $content = undef) {
    $pdir = inline_template("<%= name.reverse().split('/',2)[1].reverse()
    %>")
    $basename = inline_template("<%= name.split('/')[-1] %>")

    file {
    "${name}-puppet":
    source => $source, content => $content, ensure => present;
    "${pdir}/README-${basename}":
    ensure => present,
    content => "${name} is managed by Puppet.\n\nIf you need to
    edit\n${name}\nand have your changes persist, touch\n${name}.noupdate\nand
    Puppet will ignore that file. When you are done with your\ntesting, please
    have your changes put in Puppet and delete the\n${name}.noupdate\nfile.
    Thanks.\n\n";
    }

    exec {
    "${name}-sync":
    unless => "test -f ${name}.noupdate || cmp -s ${name}
    ${name}-puppet",
    command => "/usr/local/bin/rsync -a ${name}-puppet ${name}",
    require => File["${name}-puppet"];
    }
    }
    </pre>

    On Thu, Jun 14, 2012 at 11:09 AM, Nick Fagerlund <
    nick.fagerlund@puppetlabs.com> wrote:
    On Thursday, June 14, 2012 6:00:21 AM UTC-7, PorkCharSui wrote:

    ... can Puppet detect if a user has changed a *.conf file him(her)self
    and NOT do anything to that *.conf file?
    Nope! Puppet has no good way to tell the difference between:

    - A user using sudo to deliberately change a file,
    - A rogue or malicious process overwriting the file,
    - A package update replacing the file with a boilerplate one that
    lacks the modifications you need

    As far as I know, that kind of knowledge always has to come from
    out-of-band; there's nothing intrinsic in the file that can tell you about
    intent.

    But so anyway. Some possible approaches:

    - Investigate the file type's replace => false capability, for
    initializing files and then not managing content afterwards.
    - If you're comfortable having users able to edit their puppet.conf
    files, use environments. If a user changes their environment from
    "production" to "manual," you can have a selector statement in all of your
    conf file resources that sets the source (or content) to undef, which makes
    it unmanaged. This is good because environments show up in reports, so you
    can tell how many of your users have switched into manual mode.
    - If you aren't comfortable with opening up puppet.conf, you could
    also do the same thing with a fact, using the facts.d plugin in the
    puppetlabs-stdlib module. (Facts.d lets you treat the contents of a plain
    text file as a custom fact, and then expose that text files to users as a
    config file.)

    --
    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/-/nSkZNChOpokJ.

    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.
    --
    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/-/ptTpLliKm9YJ.
    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
postedJun 14, '12 at 1:14p
activeJun 15, '12 at 8:05a
posts5
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase