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.