Puppet users - Jun 2012 - Can Puppet detect if a user has changed a *.conf file and not do anything to that *.conf file?

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.

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

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

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.

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

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.