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