Yes, Puppet is perfect for your file-copy-and-hook scenario. In Puppet
speak it's "notify" and "subscribe" between resources, here's a very
quick example that will restart Some Daemon if /etc/resolv.conf
changes:
node 'somehost' {
class { 'resolv': }
}
class resolv {
$resolv_conf = '/etc/resolv.conf'
$service_name = 'some-daemon'
file { $resolv_conf:
source => "puppet:///modules/${module_name}/${resolv_conf}",
notify => Service[$service_name],
}
service { $service_name:
hasrestart => true,
ensure => running,
enable => true,
require => File[$resolv_conf],
}
}
The module design of Puppet pushes you in the direction of keeping
your Puppet controlled config files inside the module that controls
them, but it *is* possible to reference other paths on the file system
(like your existing rdist tree) if you want, but I wouldn't mix the
two to save confusion.
Generally you'd put your master resolv.conf file on your Puppet Master
somewhere like: /etc/puppet/modules/resolv/files/etc/resolv.conf
I would start with converting all your config files over first. Once
you realise how easy it is to write modules you might be able to
convince some of your admins to start packaging your code, then you
can introduce package hooks to restart services or run scripts when
software updates and maybe by then you'll have everyone hooked ;-)
The Puppet Package type supports a lot of different providers and OS':
http://docs.puppetlabs.com/references/2.7.0/type.html#package
On Apr 27, 5:40 pm, Philip Brown <p...@bolthole.com> wrote:
> On Friday, April 27, 2012 8:28:32 AM UTC-7, Luke Bigum wrote:
>
> > What problem are you trying to solve that you think you need Puppet? The
> > recommended Puppet way would be to package your binaries and use Puppet
> > to enforce new versions of the package. You said your Admins are used to
> > just getting on the rdist master, make changes and then practically an
> > rsync? If that's the way you work and the way you want to continue to
> > work then I don't think Puppet's going to beat rdist for this use case.
>
> I was afraid of that. Well, even if we continue doing rdisted binary
> distribs,
> the additional "run if changed" hooks, I think might be better served by
> puppet. yes?
> The current triggers are a bit quirky. And, we do many configs by symlinks
> on individual machines, to the "standard" configs in the rdisted common
> tree. I'd rather have that stuff handled by puppet configs.
> There are "only" about 15 triggers, and 10-ish symlinks per machine.
> For symlinks, I mean stuff like
>
> /etc/resolv.conf -> /shared/path/resolv/resolv.conf-machinetype
>
> I'd rather puppet do actual COPIES of files. That works better with solaris
> patches. So I'm thinking some kind of
> puppet class, that autocopies
> /shared/path/resolv/resolv.conf-machinetype to /etc/resolv.conf
> whenever the /shared/path version gets changed by rdist.
> Is that going to work reliably?
>
> Triggers do things like, "if config file target has changed, restart
> demon". So, perfect puppetness there.
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
