This is interesting. What you describe does work, but it appears
there's a bug somewhere. I'm getting 2 reasons to bounce the service
out of the single file definition when checksum is mtime. Here is the
output:
# puppetd --test
info: Caching catalog at /var/lib/puppet/localconfig.yaml
notice: Starting catalog run
notice: //Node[removed]/dns/File[/opt/management/dns/zones]/checksum:
checksum changed '{mtime}Fri Nov 07 15:46:17 -0500 2008' to
'{mtime}Fri Nov 07 15:47:02 -0500 2008'
notice: //Node[removed]/dns/File[/opt/management/dns/zones/removed-
ext.zone]/checksum: checksum changed '{mtime}Fri Nov 07 15:46:17 -0500
2008' to '{mtime}Fri Nov 07 15:47:02 -0500 2008'
info: //Node[removed]/dns/File[/opt/management/dns/zones]: Scheduling
refresh of Service[named]
info: //Node[removed]/dns/File[/opt/management/dns/zones]: Scheduling
refresh of Service[named]
notice: //Node[removed]/dns/Service[named]: Triggering 'refresh' from
2 dependencies
notice: Finished catalog run in 6.72 seconds
It appears from this output that puppet should be checksumming files
on recurse => true regardless of the checksumming scheme. Is this a
bug?
On Nov 7, 3:11 pm, "Paul Lathrop" <[EMAIL PROTECTED]> wrote:
> Wrong. Set the checksum property to "mtime" on the directory resource.
> When a file in the directory changes, it will change the mtime of the
> directory which will trigger an event on any resources which subscribe
> to the directory.
>
> I have used this method a number of times to great success.
>
> --Paul
>
> On Thu, Nov 6, 2008 at 6:03 PM, Aj <[EMAIL PROTECTED]> wrote:
>
> > No, there is no way.
>
> > On 7/11/2008, at 1:01 PM, joe <[EMAIL PROTECTED]> wrote:
>
> >> I just added the require after subscribe alone didn't work.
>
> >> I thought that if I specified the directory with recurse => true, it
> >> would monitor all the files in the directory as well.
>
> >> Is there a way to have puppet monitor files it isn't sourcing?
>
> >> On Nov 6, 3:41 pm, Aj <[EMAIL PROTECTED]> wrote:
> >>> This notification will only fire if the managed parameters for the
> >>> directory are out of sync, e.g. Owner/group/modes/file type (link,
> >>> file).
>
> >>> Subscribe also implies require, FYI =)
>
> >>> On 7/11/2008, at 8:38 AM, joe <[EMAIL PROTECTED]> wrote:
>
> >>>> It's a defined file resource without a source parameter. Here is
> >>>> the
> >>>> syntax:
>
> >>>> file { "/opt/management/dns/zones":
> >>>> owner => "root",
> >>>> group => "root",
> >>>> mode => "644",
> >>>> ensure => directory,
> >>>> recurse => true }
>
> >>>> Then there is a service resource that subscribes to that file:
>
> >>>> service { "named":
> >>>> enable => true,
> >>>> ensure => running,
> >>>> require => File["/etc/named.conf"],
> >>>> require => File["/opt/dns/management/zones"],
> >>>> require => Package["bind"],
> >>>> subscribe => File["/etc/named.conf"],
> >>>> subscribe => File["/opt/management/dns/zones"] }
>
> >>>> But the service never restarts when files in that directory
> >>>> change. I
> >>>> would think it's because I'm not sourcing those files, but I'm not
> >>>> sure.
>
> >>>> On Nov 6, 12:37 pm, "Evan Hisey" <[EMAIL PROTECTED]> wrote:
> >>>>> On Wed, Nov 5, 2008 at 6:19 PM, joe <[EMAIL PROTECTED]> wrote:
>
> >>>>>> I'm having a similar issue that that wiki entry does not directly
> >>>>>> address.
>
> >>>>>> I'm trying to do a subscribe on a file definition that is a
> >>>>>> directory.
>
> >>>>>> I have ensure => directory and recurse => true.
>
> >>>>>> I do not use puppet to source the files (they are on nfs shared to
> >>>>>> all
> >>>>>> servers that use them).
>
> >>>>>> Puppet will not restart a service subscribed to this file
> >>>>>> definition.
> >>>>>> It does not seem to look at whether the files in the directory
> >>>>>> have
> >>>>>> changed.
>
> >>>>>> How do others make such a scenario work?
>
> >>>>>> Thanks
>
> >>>>> Is puppet actually managing the directory? Unless puppet manages
> >>>>> the
> >>>>> directory it can't know to handle a restart.
>
> >>>>> Evan
--~--~---------~--~----~------------~-------~--~----~
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 [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
