On Jun 29, 2011, at 9:14 AM, Brian Gallew wrote:
> On Jun 29, 2011, at 9:05 AM, Nigel Kersten wrote:
>
>> I've long wanted the equivalent of a "conffile" in Puppet.
>>
>> e.g. "replace this file if it's still the same as the one Puppet put down,
>> but if it's been modified from the default, don't replace it"
>>
>> I've wanted this in the past for things like a user .rc file, where you want
>> to be able to continually update the default, but not throw away any
>> customization the user may have done.
>
> SInce I support developer who sometimes want to control the conf files, and
> sometimes want Puppet to control them, I created a define:
>
> 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"];
> }
> }
>
>
> And you use it like so:
> managed_file {
> "${muledir}/lib/user/system-config.properties":
> content => template("jboss/system-config.properties.erb"),
> require => File["${muledir}/lib/user"],
> notify => Service["/site/mule"];
> }
>
> That will create three files in ${muledir}/lib/user:
> README-system-config.properties, system-config.properties-puppet, and
> system-config.properties. If one of the developers on a managed system needs
> to hand-edit that file, they red the instructions in the README-* and simply
> touch system-config.properties.noupdate. Removing that file re-enables
> Puppet management. As a further benefit, they can trivially see what's going
> to change when they remove the .noupdate file because the -puppet version
> will always be Puppet-managed.
----
wow, this is a keeper for sure.
In my case, I have an encrypted binary file but I think you have given me the
idea for instructing puppet to keep hands off
Thanks
Craig
--
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.
