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 puppet-users+unsubscr...@googlegroups.com.
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.
