I have the following test case:
file { sendmail-conf:
path => "/etc/mail/${fqdn}.mc",
owner => "root",
group => "wheel",
mode => 0644,
links => follow,
source => "puppet:///sendmail/${hostname}.mc"
}
$mail_dir = "/etc/mail"
$cf_dir = "/usr/share/sendmail/cf/"
exec { build-conf:
command => "/usr/bin/m4 -D_CF_DIR_=${cf_dir} ${cf_dir}/m4/cf.m4
${fqdn}.mc > sendmail.cf",
cwd => "$mail_dir",
logoutput => true,
subscribe => File[sendmail-conf],
creates => "${maildir}/sendmail.cf"
}
This does exactly what the documentation says it will; it will only run when the
file
specified by creates does not exist. I''m wondering if it
wouldn''t be better if the
behavior was be modified so that it would run when a refresh event occurs. This
would be
similar to refreshonly except that it would also ensure the target is present;
however,
I''m not sure if this is the intended purpose of "creates".
I can''t see any other way to make sure a file generated by an exec
exists and regenerate
it when the source changes. I have had several incidences occur where
sendmail.cf was
deleted and was never recreated because the source file didn''t change
which then broke the
box when sendmail was later restarted.
--
Russell A. Jackson <raj@csub.edu>
Network Analyst
California State University, Bakersfield
One of the pleasures of reading old letters is the knowledge that they
need no answer.
-- George Gordon, Lord Byron
On 04/09/07, Russell Jackson <raj@csub.edu> wrote:> I have the following test case: > > file { sendmail-conf: > path => "/etc/mail/${fqdn}.mc", > owner => "root", > group => "wheel", > mode => 0644, > links => follow, > source => "puppet:///sendmail/${hostname}.mc" > } > > $mail_dir = "/etc/mail" > $cf_dir = "/usr/share/sendmail/cf/" > exec { build-conf: > command => "/usr/bin/m4 -D_CF_DIR_=${cf_dir} ${cf_dir}/m4/cf.m4 ${fqdn}.mc > sendmail.cf", > cwd => "$mail_dir", > logoutput => true, > subscribe => File[sendmail-conf], > creates => "${maildir}/sendmail.cf" > } > > This does exactly what the documentation says it will; it will only run when the file > specified by creates does not exist. I''m wondering if it wouldn''t be better if the > behavior was be modified so that it would run when a refresh event occurs. This would be > similar to refreshonly except that it would also ensure the target is present; however, > I''m not sure if this is the intended purpose of "creates". > > I can''t see any other way to make sure a file generated by an exec exists and regenerate > it when the source changes. I have had several incidences occur where sendmail.cf was > deleted and was never recreated because the source file didn''t change which then broke the > box when sendmail was later restarted. >I''m not sure I understand you entirely You''re saying that with the above code, if you remove the file from the target location, a rerun of puppet does not recreate the file? That''s a bug. The exec should always be touched on every puppet run according to the above code, and the check to see if the file exists (the ''creates'' parameter) will determine whether it should actually run the command or not. The subscribe does not factor into it (and I think you could just leave that out). At least, that is how I interpret the code you give to work. And if that''s not how it works, there are hidden factors, which I would advocate be removed. Thijs> -- > Russell A. Jackson <raj@csub.edu> > Network Analyst > California State University, Bakersfield > > One of the pleasures of reading old letters is the knowledge that they > need no answer. > -- George Gordon, Lord Byron > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
Thijs Oppermann wrote:> On 04/09/07, Russell Jackson <raj@csub.edu> wrote: >> I have the following test case: >> >> file { sendmail-conf: >> path => "/etc/mail/${fqdn}.mc", >> owner => "root", >> group => "wheel", >> mode => 0644, >> links => follow, >> source => "puppet:///sendmail/${hostname}.mc" >> } >> >> $mail_dir = "/etc/mail" >> $cf_dir = "/usr/share/sendmail/cf/" >> exec { build-conf: >> command => "/usr/bin/m4 -D_CF_DIR_=${cf_dir} ${cf_dir}/m4/cf.m4 ${fqdn}.mc > sendmail.cf", >> cwd => "$mail_dir", >> logoutput => true, >> subscribe => File[sendmail-conf], >> creates => "${maildir}/sendmail.cf" >> } >> >> This does exactly what the documentation says it will; it will only run when the file >> specified by creates does not exist. I''m wondering if it wouldn''t be better if the >> behavior was be modified so that it would run when a refresh event occurs. This would be >> similar to refreshonly except that it would also ensure the target is present; however, >> I''m not sure if this is the intended purpose of "creates". >> >> I can''t see any other way to make sure a file generated by an exec exists and regenerate >> it when the source changes. I have had several incidences occur where sendmail.cf was >> deleted and was never recreated because the source file didn''t change which then broke the >> box when sendmail was later restarted. >> > > I''m not sure I understand you entirely You''re saying that with the > above code, if you remove the file from the target location, a rerun > of puppet does not recreate the file? That''s a bug. The exec should > always be touched on every puppet run according to the above code, and > the check to see if the file exists (the ''creates'' parameter) will > determine whether it should actually run the command or not. The > subscribe does not factor into it (and I think you could just leave > that out). > > At least, that is how I interpret the code you give to work. And if > that''s not how it works, there are hidden factors, which I would > advocate be removed. >It will recreate the generated file if and only if I remove it which is the problem. I want it to both make sure that the generated file exists AND refresh it when the source (subscribed) file changes. I can see in the debug output that the Exec gets a refresh event when the subscribed file changes, but it doesn''t run the command unless the output file is absent. I surely can''t be the first and only person to have this problem, and I suspect there is a (non-obvious) way to get the behavior I want. Using refreshonly gets me most of the way there, and that''s what I''ve been using; however, it doesn''t ensure that the generated file is present when the source file hasn''t changed. -- Russell A. Jackson <raj@csub.edu> Network Analyst California State University, Bakersfield We call our dog Egypt, because in every room he leaves a pyramid. _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On Sep 4, 2007, at 2:17 PM, Russell Jackson wrote:> It will recreate the generated file if and only if I remove it > which is the problem. I > want it to both make sure that the generated file exists AND > refresh it when the source > (subscribed) file changes. > > I can see in the debug output that the Exec gets a refresh event > when the subscribed file > changes, but it doesn''t run the command unless the output file is > absent. > > I surely can''t be the first and only person to have this problem, > and I suspect there is a > (non-obvious) way to get the behavior I want. Using refreshonly > gets me most of the way > there, and that''s what I''ve been using; however, it doesn''t ensure > that the generated file > is present when the source file hasn''t changed.Look into the ''refreshonly'' parameter to exec. It should provide what you want. -- I don''t want any yes-men around me. I want everybody to tell me the truth even if it costs them their jobs. -- Samuel Goldwyn --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
Luke Kanies wrote:> On Sep 4, 2007, at 2:17 PM, Russell Jackson wrote: > >> It will recreate the generated file if and only if I remove it >> which is the problem. I >> want it to both make sure that the generated file exists AND >> refresh it when the source >> (subscribed) file changes. >> >> I can see in the debug output that the Exec gets a refresh event >> when the subscribed file >> changes, but it doesn''t run the command unless the output file is >> absent. >> >> I surely can''t be the first and only person to have this problem, >> and I suspect there is a >> (non-obvious) way to get the behavior I want. Using refreshonly >> gets me most of the way >> there, and that''s what I''ve been using; however, it doesn''t ensure >> that the generated file >> is present when the source file hasn''t changed. > > Look into the ''refreshonly'' parameter to exec. It should provide > what you want.Gah! "refreshonly" doesn''t ensure that the file resulting from the exec is present! -- Russell A. Jackson <raj@csub.edu> Network Analyst California State University, Bakersfield We call our dog Egypt, because in every room he leaves a pyramid. _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
On 04/09/07, Russell Jackson <raj@csub.edu> wrote:> > Luke Kanies wrote: > > On Sep 4, 2007, at 2:17 PM, Russell Jackson wrote: > > > >> It will recreate the generated file if and only if I remove it > >> which is the problem. I > >> want it to both make sure that the generated file exists AND > >> refresh it when the source > >> (subscribed) file changes. > >> > >> I can see in the debug output that the Exec gets a refresh event > >> when the subscribed file > >> changes, but it doesn''t run the command unless the output file is > >> absent. > >> > >> I surely can''t be the first and only person to have this problem, > >> and I suspect there is a > >> (non-obvious) way to get the behavior I want. Using refreshonly > >> gets me most of the way > >> there, and that''s what I''ve been using; however, it doesn''t ensure > >> that the generated file > >> is present when the source file hasn''t changed. > > > > Look into the ''refreshonly'' parameter to exec. It should provide > > what you want. > > Gah! "refreshonly" doesn''t ensure that the file resulting from the exec is > present!Remove the creates parameter and add refreshonly=>true. Now the exec will only ever run if it gets a heads-up from the subscribed file. The ''creates'' parameter is only needed to stop an exec running on every puppet run, but that job is now done by ''refreshonly''... Thijs --> Russell A. Jackson <raj@csub.edu> > Network Analyst > California State University, Bakersfield > > We call our dog Egypt, because in every room he leaves a pyramid. > > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users > > >_______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
Thijs Oppermann wrote:> On 04/09/07, *Russell Jackson* <raj@csub.edu <mailto:raj@csub.edu>> wrote: > > Luke Kanies wrote: > > On Sep 4, 2007, at 2:17 PM, Russell Jackson wrote: > > > >> It will recreate the generated file if and only if I remove it > >> which is the problem. I > >> want it to both make sure that the generated file exists AND > >> refresh it when the source > >> (subscribed) file changes. > >> > >> I can see in the debug output that the Exec gets a refresh event > >> when the subscribed file > >> changes, but it doesn''t run the command unless the output file is > >> absent. > >> > >> I surely can''t be the first and only person to have this problem, > >> and I suspect there is a > >> (non-obvious) way to get the behavior I want. Using refreshonly > >> gets me most of the way > >> there, and that''s what I''ve been using; however, it doesn''t ensure > >> that the generated file > >> is present when the source file hasn''t changed. > > > > Look into the ''refreshonly'' parameter to exec. It should provide > > what you want. > > Gah! "refreshonly" doesn''t ensure that the file resulting from the > exec is present! > > > Remove the creates parameter and add refreshonly=>true. Now the exec > will only ever run if it gets a heads-up from the subscribed file. The > ''creates'' parameter is only needed to stop an exec running on every > puppet run, but that job is now done by ''refreshonly''...I think he is looking to trigger the exec: * if the subscribed file changes and also: * if the file created by the exec is not present (even if the subscribed file is not changed) Jordan
On 05/09/07, Jordan Share <jshare@krotus.com> wrote:> > I think he is looking to trigger the exec: > * if the subscribed file changes > and also: > * if the file created by the exec is not present (even if the subscribed file is not changed)So add another file resource monitoring the file that notifies the exec: file { "${maildir}/sendmail.cf": ensure => present, notify => Exec[build-conf], }> > Jordan > _______________________________________________ > Puppet-users mailing list > Puppet-users@madstop.com > https://mail.madstop.com/mailman/listinfo/puppet-users >
Thijs Oppermann wrote:> On 05/09/07, Jordan Share <jshare@krotus.com> wrote: >> I think he is looking to trigger the exec: >> * if the subscribed file changes >> and also: >> * if the file created by the exec is not present (even if the subscribed file is not changed) > > So add another file resource monitoring the file that notifies the exec: > > file { "${maildir}/sendmail.cf": > ensure => present, > notify => Exec[build-conf], > } >Aye. That works. For some reason I thought you must have a "source" for a file. Thanks, -- Russell A. Jackson <raj@csub.edu> Network Analyst California State University, Bakersfield One of the pleasures of reading old letters is the knowledge that they need no answer. -- George Gordon, Lord Byron
Russell Jackson wrote:> Aye. That works. For some reason I thought you must have a "source" > for a file.Files for subscription have to be specified in the manifest, but that''s about it. I''ve got two tripwire-style entries right up at the top of my site.pp with no source, and they get applied to every system that runs puppet, regardless of anything else: # Once, Mike screwed up permissions on /tmp, rendering the plotter # queue manager very confused. file { "/tmp": ensure => directory, owner => root, group => root, mode => 1777, } # Xen instances never seem to get Amanda-compatible permissions on # their disk devices. file { "/dev/sda1": owner => root, group => disk, }