Hi,
how may I do something like:
file { "/usr/local/sbin/*":
ensure => file,
owner => "root",
group => "root",
mode => "700",
source =>
"puppet://gridinstall01.pic.es/files/usr/local/sbin/",
}
Cause it creates a wildcard:
#ls /usr/local/sbin/\*/
Do I have to manage file by file? Is there any possibility os copying
recursively?
TIA,
Arnau
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
Hi> how may I do something like: > > > file { "/usr/local/sbin/*": > ensure => file, > owner => "root", > group => "root", > mode => "700", > source => "puppet://gridinstall01.pic.es/files/usr/local/sbin/", > } > > Cause it creates a wildcard: > > #ls /usr/local/sbin/\*/ > > Do I have to manage file by file? Is there any possibility os copying > recursively? >no, just remove the wildcard from your file definition, as well the the "ensure => file". You want to manage the directory, if you want to manage every file in this directory. greets pete --~--~---------~--~----~------------~-------~--~----~ 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 Wed, 05 Nov 2008 17:37:45 +0100 Peter Meier wrote:> > HiHi pete,> > how may I do something like: > > file { "/usr/local/sbin/*": > > ensure => file, > > owner => "root", > > group => "root", > > mode => "700", > > source => > > "puppet://gridinstall01.pic.es/files/usr/local/sbin/", } > > > > Cause it creates a wildcard: > > > > #ls /usr/local/sbin/\*/ > > > > Do I have to manage file by file? Is there any possibility os > > copying recursively? > > > > > no, just remove the wildcard from your file definition, as well the > the "ensure => file". You want to manage the directory, if you want to > manage every file in this directory.Sorry, I don''t get you... I want to manage each file in the directory, and, obviously, the directoy itself. (Maybe a scp example will clarify my problem: scp server:/path/* /path/*) So, you say something like: file { "/usr/local/sbin/": ensure => directory, owner => "root", group => "root", mode => "755", source => "puppet://gridinstall01.pic.es/files/usr/local/sbin/", } cause it does nothing. Neither if I try file { "/usr/local/sbin/": owner => "root", group => "root", mode => "755", source => "puppet://gridinstall01.pic.es/files/usr/local/sbin/", } source: # ls usr/local/sbin/ autofs.sh kill_orphans.pl ssh_sensor.sh wn_mem.sh dest: # ls -lsa /usr/local/sbin/ total 16 8 drwxr-xr-x 2 root root 4096 Nov 5 17:45 . 8 drwxr-xr-x 13 root root 4096 Nov 5 14:32 ..> greets peteThanks for your reply, Arnau --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Hi>>> how may I do something like: >>> file { "/usr/local/sbin/*": >>> ensure => file, >>> owner => "root", >>> group => "root", >>> mode => "700", >>> source => >>> "puppet://gridinstall01.pic.es/files/usr/local/sbin/", } >>> >>> Cause it creates a wildcard: >>> >>> #ls /usr/local/sbin/\*/ >>> >>> Do I have to manage file by file? Is there any possibility os >>> copying recursively? >>> >> >> no, just remove the wildcard from your file definition, as well the >> the "ensure => file". You want to manage the directory, if you want to >> manage every file in this directory. > > Sorry, I don''t get you... > > I want to manage each file in the directory, and, obviously, the > directoy itself. > (Maybe a scp example will clarify my problem: scp > server:/path/* /path/*) > > So, you say something like: > file { "/usr/local/sbin/": > ensure => directory, > owner => "root", > group => "root", > mode => "755", > source => "puppet://gridinstall01.pic.es/files/usr/local/sbin/", > } > > cause it does nothing. Neither if I try > file { "/usr/local/sbin/": > owner => "root", > group => "root", > mode => "755", > source => "puppet://gridinstall01.pic.es/files/usr/local/sbin/", > } > source: > # ls usr/local/sbin/ > autofs.sh kill_orphans.pl ssh_sensor.sh wn_mem.sh > > > dest: > # ls -lsa /usr/local/sbin/ > total 16 > 8 drwxr-xr-x 2 root root 4096 Nov 5 17:45 . > 8 drwxr-xr-x 13 root root 4096 Nov 5 14:32 ..http://reductivelabs.com/trac/puppet/wiki/FrequentlyAskedQuestions#how-can-i-manage-whole-directories-of-files-without-explicitly-listing-the-files greets pete --~--~---------~--~----~------------~-------~--~----~ 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 Wed, 05 Nov 2008 18:48:12 +0100 Peter Meier wrote: [...]> http://reductivelabs.com/trac/puppet/wiki/FrequentlyAskedQuestions#how-can-i-manage-whole-directories-of-files-without-explicitly-listing-the-filesmy god, I did some search on the wiki, but did not find that link. many thanks!> greets peteArnau --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
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 On Nov 5, 1:55 pm, Arnau Bria <arnaub...@pic.es> wrote:> On Wed, 05 Nov 2008 18:48:12 +0100 > > Peter Meier wrote: > > [...] > > >http://reductivelabs.com/trac/puppet/wiki/FrequentlyAskedQuestions#ho... > > my god, I did some search on the wiki, but did not find that link. > > many thanks! > > > greets pete > > Arnau--~--~---------~--~----~------------~-------~--~----~ 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 Wed, Nov 5, 2008 at 6:19 PM, joe <lavaman@gmail.com> 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 puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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" <ehi...@gmail.com>
wrote:> On Wed, Nov 5, 2008 at 6:19 PM, joe <lava...@gmail.com> 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
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
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 <lavaman@gmail.com> 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" <ehi...@gmail.com> wrote: >> On Wed, Nov 5, 2008 at 6:19 PM, joe <lava...@gmail.com> 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 puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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 <a...@junglist.gen.nz> 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 <lava...@gmail.com> 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" <ehi...@gmail.com> wrote: > >> On Wed, Nov 5, 2008 at 6:19 PM, joe <lava...@gmail.com> 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 puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
No, there is no way. On 7/11/2008, at 1:01 PM, joe <lavaman@gmail.com> 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 <a...@junglist.gen.nz> 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 <lava...@gmail.com> 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" <ehi...@gmail.com> wrote: >>>> On Wed, Nov 5, 2008 at 6:19 PM, joe <lava...@gmail.com> 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 puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Thu, Nov 6, 2008 at 4:01 PM, joe <lavaman@gmail.com> wrote:> > > Is there a way to have puppet monitor files it isn''t sourcing? > >There is no way for puppet to do anything with a file it doesn''t know about. That doesn''t mean you have to define a source for the file, or even specify any other attribute. eg: file { "/tmp/foobar": } .r'' --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
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 <aj@junglist.gen.nz> wrote:> > No, there is no way. > > On 7/11/2008, at 1:01 PM, joe <lavaman@gmail.com> 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 <a...@junglist.gen.nz> 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 <lava...@gmail.com> 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" <ehi...@gmail.com> wrote: >>>>> On Wed, Nov 5, 2008 at 6:19 PM, joe <lava...@gmail.com> 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 puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
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" <p...@tertiusfamily.net>
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 <a...@junglist.gen.nz> wrote:
>
> > No, there is no way.
>
> > On 7/11/2008, at 1:01 PM, joe <lava...@gmail.com> 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 <a...@junglist.gen.nz> 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 <lava...@gmail.com> 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"
<ehi...@gmail.com> wrote:
> >>>>> On Wed, Nov 5, 2008 at 6:19 PM, joe
<lava...@gmail.com> 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
puppet-users+unsubscribe@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
No, not a bug at all. Why do you think it might be? There is no reason to be concerned by the multiple notifications, either; Puppet is smart enough to only refresh the service once. --Paul On Fri, Nov 7, 2008 at 12:52 PM, joe <lavaman@gmail.com> wrote:> > 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" <p...@tertiusfamily.net> 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 <a...@junglist.gen.nz> wrote: >> >> > No, there is no way. >> >> > On 7/11/2008, at 1:01 PM, joe <lava...@gmail.com> 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 <a...@junglist.gen.nz> 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 <lava...@gmail.com> 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" <ehi...@gmail.com> wrote: >> >>>>> On Wed, Nov 5, 2008 at 6:19 PM, joe <lava...@gmail.com> 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 puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
I don''t think it''s a bug that puppet sees two reasons to bounce the service, I think it''s a bug that it''s only doing it when I change the checksum to mtime. The default is md5 (I think) and it would appear that when you define a file resource that is a directory with recurse => true, puppet should generate md5s on all the files in that dir on the first run, so it can keep track of them later, regardless of whether puppet is copying the files into that directory or not. It seems to only work if puppet is sourcing the files in the directory. It should work either way. On Nov 7, 3:59 pm, "Paul Lathrop" <p...@tertiusfamily.net> wrote:> No, not a bug at all. Why do you think it might be? > > There is no reason to be concerned by the multiple notifications, > either; Puppet is smart enough to only refresh the service once. > > --Paul > > On Fri, Nov 7, 2008 at 12:52 PM, joe <lava...@gmail.com> wrote: > > > 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" <p...@tertiusfamily.net> 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 <a...@junglist.gen.nz> wrote: > > >> > No, there is no way. > > >> > On 7/11/2008, at 1:01 PM, joe <lava...@gmail.com> 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 <a...@junglist.gen.nz> 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 <lava...@gmail.com> 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" <ehi...@gmail.com> wrote: > >> >>>>> On Wed, Nov 5, 2008 at 6:19 PM, joe <lava...@gmail.com> 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 puppet-users+unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Paul Lathrop writes: > 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. The mtime on the directory won''t change unless some kind of manipulation of the directory itself occurs in the process of changing a file within the directory. This happens with a lot of editors that create temporary or backup files in the same directory as the file being edited, but isn''t absolutely assured. For example: drwxr-xr-x 3 root root 4096 Oct 27 17:39 . drwxr-xr-x 5 root root 4096 Aug 17 2007 .. -rw-r--r-- 1 root root 75576 Nov 7 11:54 access In particular this is actually what a directory in our Puppet subversion repository looks like; as no new files have been added or removed in the repository since October 27, subversion hasn''t had to manipulate the directory itself, so the directory mtime hasn''t changed even though many files have been updated frequently since. If Puppet''s "mtime" tracking looks only at the mtime of the directory and not at the mtime of anything underneath it, you wouldn''t be able to depend on that to track changes to files within the directory, unless you also happen to do something to the directory every time you change a file underneath it. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Sorry, I wasn''t clear on the mechanism of why this works. Thanks for the correction. On Fri, Nov 7, 2008 at 1:24 PM, Steven VanDevender <stevev@uoregon.edu> wrote:> > Paul Lathrop writes: > > 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. > > The mtime on the directory won''t change unless some kind of manipulation > of the directory itself occurs in the process of changing a file within > the directory. This happens with a lot of editors that create temporary > or backup files in the same directory as the file being edited, but > isn''t absolutely assured. For example: > > drwxr-xr-x 3 root root 4096 Oct 27 17:39 . > drwxr-xr-x 5 root root 4096 Aug 17 2007 .. > -rw-r--r-- 1 root root 75576 Nov 7 11:54 access > > In particular this is actually what a directory in our Puppet subversion > repository looks like; as no new files have been added or removed in the > repository since October 27, subversion hasn''t had to manipulate the > directory itself, so the directory mtime hasn''t changed even though many > files have been updated frequently since. > > If Puppet''s "mtime" tracking looks only at the mtime of the directory > and not at the mtime of anything underneath it, you wouldn''t be able to > depend on that to track changes to files within the directory, unless > you also happen to do something to the directory every time you change a > file underneath it. > > > >--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
Though with recurse => true, puppet does look at the mtime of the individual files, per my output sample from previous email. My last question was really why won''t it do default checksum (md5) on the files in the directory when I have recurse => true. It only looks at the files in the directory when I change the checksum type (in my case to mtime, not sure what other options would work). On Nov 7, 4:48 pm, "Paul Lathrop" <p...@tertiusfamily.net> wrote:> Sorry, I wasn''t clear on the mechanism of why this works. Thanks for > the correction. > > On Fri, Nov 7, 2008 at 1:24 PM, Steven VanDevender <ste...@uoregon.edu> wrote: > > > Paul Lathrop writes: > > > 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. > > > The mtime on the directory won''t change unless some kind of manipulation > > of the directory itself occurs in the process of changing a file within > > the directory. This happens with a lot of editors that create temporary > > or backup files in the same directory as the file being edited, but > > isn''t absolutely assured. For example: > > > drwxr-xr-x 3 root root 4096 Oct 27 17:39 . > > drwxr-xr-x 5 root root 4096 Aug 17 2007 .. > > -rw-r--r-- 1 root root 75576 Nov 7 11:54 access > > > In particular this is actually what a directory in our Puppet subversion > > repository looks like; as no new files have been added or removed in the > > repository since October 27, subversion hasn''t had to manipulate the > > directory itself, so the directory mtime hasn''t changed even though many > > files have been updated frequently since. > > > If Puppet''s "mtime" tracking looks only at the mtime of the directory > > and not at the mtime of anything underneath it, you wouldn''t be able to > > depend on that to track changes to files within the directory, unless > > you also happen to do something to the directory every time you change a > > file underneath it.--~--~---------~--~----~------------~-------~--~----~ 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 Nov 7, 2008, at 1:07 PM, joe wrote:> I don''t think it''s a bug that puppet sees two reasons to bounce the > service, I think it''s a bug that it''s only doing it when I change the > checksum to mtime. The default is md5 (I think) and it would appear > that when you define a file resource that is a directory with recurse > => true, puppet should generate md5s on all the files in that dir on > the first run, so it can keep track of them later, regardless of > whether puppet is copying the files into that directory or not. It > seems to only work if puppet is sourcing the files in the directory. > It should work either way.There is no default for checksum. If you use file sources, then the source parameter makes sure checksums are checked, but otherwise, you need to add ''checksum => md5'' or ''check => checksum'' to your resources. If you add ''checksum => md5'' you''ll get the behaviour you want. -- It has recently been discovered that research causes cancer in labratory rats. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
That makes sense, though I would think if you have recurse => true and a subscribe/notify, then checksumming should be enabled by default in that scenario also. It may not be feasible depending on the internal workings of puppet, but that would seem to be the expected behavior. On Nov 12, 7:20 pm, Luke Kanies <l...@madstop.com> wrote:> On Nov 7, 2008, at 1:07 PM, joe wrote: > > > I don''t think it''s a bug that puppet sees two reasons to bounce the > > service, I think it''s a bug that it''s only doing it when I change the > > checksum to mtime. The default is md5 (I think) and it would appear > > that when you define a file resource that is a directory with recurse > > => true, puppet should generate md5s on all the files in that dir on > > the first run, so it can keep track of them later, regardless of > > whether puppet is copying the files into that directory or not. It > > seems to only work if puppet is sourcing the files in the directory. > > It should work either way. > > There is no default for checksum. If you use file sources, then the > source parameter makes sure checksums are checked, but otherwise, you > need to add ''checksum => md5'' or ''check => checksum'' to your resources. > > If you add ''checksum => md5'' you''ll get the behaviour you want. > > -- > It has recently been discovered that research causes cancer in > labratory rats. > --------------------------------------------------------------------- > Luke Kanies |http://reductivelabs.com|http://madstop.com--~--~---------~--~----~------------~-------~--~----~ 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 Nov 12, 2008, at 4:51 PM, joe wrote:> > That makes sense, though I would think if you have recurse => true and > a subscribe/notify, then checksumming should be enabled by default in > that scenario also. It may not be feasible depending on the internal > workings of puppet, but that would seem to be the expected behavior.I guess I''m of two minds, but this doesn''t really come up very often -- most people don''t seem to want to do recursive checking without having a remote source. Anyone else have an opinion?> > On Nov 12, 7:20 pm, Luke Kanies <l...@madstop.com> wrote: >> On Nov 7, 2008, at 1:07 PM, joe wrote: >> >>> I don''t think it''s a bug that puppet sees two reasons to bounce the >>> service, I think it''s a bug that it''s only doing it when I change >>> the >>> checksum to mtime. The default is md5 (I think) and it would appear >>> that when you define a file resource that is a directory with >>> recurse >>> => true, puppet should generate md5s on all the files in that dir on >>> the first run, so it can keep track of them later, regardless of >>> whether puppet is copying the files into that directory or not. It >>> seems to only work if puppet is sourcing the files in the directory. >>> It should work either way. >> >> There is no default for checksum. If you use file sources, then the >> source parameter makes sure checksums are checked, but otherwise, you >> need to add ''checksum => md5'' or ''check => checksum'' to your >> resources. >> >> If you add ''checksum => md5'' you''ll get the behaviour you want. >> >> -- >> It has recently been discovered that research causes cancer in >> labratory rats. >> --------------------------------------------------------------------- >> Luke Kanies |http://reductivelabs.com|http://madstop.com > >-- Don''t hit at all if it is honorably possible to avoid hitting; but never hit soft! -- Theodore Roosevelt --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
2008/11/13 Luke Kanies <luke@madstop.com>> > On Nov 12, 2008, at 4:51 PM, joe wrote: > > > > > That makes sense, though I would think if you have recurse => true and > > a subscribe/notify, then checksumming should be enabled by default in > > that scenario also. It may not be feasible depending on the internal > > workings of puppet, but that would seem to be the expected behavior. > > I guess I''m of two minds, but this doesn''t really come up very often > -- most people don''t seem to want to do recursive checking without > having a remote source. > > Anyone else have an opinion? > >I''d rather not checksum recursively without explicitly stating to do so. .r'' --~--~---------~--~----~------------~-------~--~----~ 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 Nov 13, 2008, at 11:53 AM, RijilV wrote:> 2008/11/13 Luke Kanies <luke@madstop.com> > > On Nov 12, 2008, at 4:51 PM, joe wrote: > > > > > That makes sense, though I would think if you have recurse => true > and > > a subscribe/notify, then checksumming should be enabled by default > in > > that scenario also. It may not be feasible depending on the > internal > > workings of puppet, but that would seem to be the expected behavior. > > I guess I''m of two minds, but this doesn''t really come up very often > -- most people don''t seem to want to do recursive checking without > having a remote source. > > Anyone else have an opinion? > > > I''d rather not checksum recursively without explicitly stating to do > so.*whew* :) -- Always read stuff that will make you look good if you die in the middle of it. -- P. J. O''Rourke --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
I can see myself being in the minority on this. I think it comes from my intense aversion toward data replication :) On Nov 13, 3:05 pm, Luke Kanies <l...@madstop.com> wrote:> On Nov 13, 2008, at 11:53 AM, RijilV wrote: > > > > > 2008/11/13 Luke Kanies <l...@madstop.com> > > > On Nov 12, 2008, at 4:51 PM, joe wrote: > > > > That makes sense, though I would think if you have recurse => true > > and > > > a subscribe/notify, then checksumming should be enabled by default > > in > > > that scenario also. It may not be feasible depending on the > > internal > > > workings of puppet, but that would seem to be the expected behavior. > > > I guess I''m of two minds, but this doesn''t really come up very often > > -- most people don''t seem to want to do recursive checking without > > having a remote source. > > > Anyone else have an opinion? > > > I''d rather not checksum recursively without explicitly stating to do > > so. > > *whew* :) > > -- > Always read stuff that will make you look good if you die in the > middle of it. -- P. J. O''Rourke > --------------------------------------------------------------------- > Luke Kanies |http://reductivelabs.com|http://madstop.com--~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---