On Tuesday, January 28, 2014 11:42:18 AM UTC-6, Jose Luis Ledesma wrote:
>
> I dont know if this may work, just an idea ( but I think it is really an
> ugly idea)
>
> Setup a dummy file for printers.conf anywhere I the filesystem
>
> Make it to notify the exec stop cups( setting refreshonly=true) chain it
> with the right file printers.conf and notify from here the cups service.
>
In the same vein, but perhaps slightly nicer, might be to sync the conf
file just once, with a secondary file on the target node as Jose suggests,
and to use that to signal an Exec that does a stop; file copy; start
sequence on the service. Something like this:
file { '/var/lib/site/cupsd.conf':
ensure => 'file',
content => template('cupsd.conf.erb')
}
exec { 'install-cupsd.conf-update':
command => '/sbin/service cups stop && cp /var/lib/site/cupsd.conf
/etc/cups.d/ && /sbin/service/cups start',
provider => 'shell',
refreshonly => true,
subscribe => File['/var/lib/site/cupsd.conf'']
}
The main problem with an approach along these lines is that it fails to
notice local changes to the real target config file. It will modify the
true target file only when the computed content differs from the content of
the *proxy* file (i.e. /var/lib/site/cupsd.conf), but if local changes are
applied to /etc/cups.d/cupsd.conf then Puppet will not recognize the need
to sync.
I suppose one could use an 'onlyif' parameter to the Exec instead of
'refreshonly' / 'subscribe', and roll in a comparison of the proxy config
file with the real target. That all will get very complicated very
quickly, though, if you want to manage anything about the real config file
other than its contents.
The idea of declaring a predicate as a separate resource that will be
synced only if some other resource needs to be synced is not implemented in
Puppet, and does not fit well into the Puppet model. Each declared
resource determines for itself whether it is in sync, and what to do if it
isn't.
Therefore, the most correct way to do this in Puppet is to create a custom
type / provider to handle it. The first hint was that we were whipping up
solutions around Execs. The fact that the service and the config file need
to be managed in concert, the latter *around* the former, is the real
indication that the whole thing ought to be modeled as a single resource,
however.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/560499ff-14b1-4534-98ae-223fb81571e2%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
