Here's what I did, and it seems to be working for now:
service { 'cups':
ensure => running,
enable => true,
}
file { '/etc/cups/printers.conf':
require => Package['cups'],
ensure => present,
source => 'puppet:///modules/printers/printers.conf',
mode => '0600',
owner => 'root',
group => 'lp',
notify => Exec['replace-restart-cups'],
}
exec { 'replace-restart-cups':
path => '/usr/bin:/usr/sbin',
command => 'cp /etc/cups/printers.conf /tmp && systemctl
stop cups.service && cp /tmp/printers.conf /etc/cups/',
logoutput => true,
refreshonly => true,
notify => Service['cups'],
}
Basically, the file replacement (in its original location) triggers a
copy-shutdown-recopy sequence which is an unabashed hack. But since cups
doesn't clobber the replaced file until the service shuts down, and we make
a copy before we shut it down, this works. So far. But it's definitely
kludgey.
Bret
On Tuesday, January 28, 2014 3:48:01 PM UTC-5, jcbollinger wrote:
>
>
>
> 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 [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/e48be422-6b1c-4f5d-977d-ad690d20c0ab%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
