Re: [Puppet Users] Can Puppet detect if a user has changed a *.conf file and not do anything to that *.conf file?

[Nan Liu]

On Thu, Jun 14, 2012 at 6:00 AM, PorkCharSui <cnos...@gmail.com> 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

[Nick Fagerlund]

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

[Brian Gallew]

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>

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

[PorkCharSui]

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!

To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.