> For what it is worth, for an extremely well known interface like > /etc/resolv.conf I would subscribe to the file resource, but for most > cases I prefer to depend on the class. So, I think both answers are > right, and I didn't explain why I chose the apparently tighter binding > this time around.
FWIW, we've chosen to do both, if for no other reason than so that the app in question won't be "processed" until after the resolv.conf is updated, so we can minimize the number of restarts, etc., as necessary. The next issue which follows, for me, is that "random_app" is "puppet-agent", because it refuses to notice changes to resolv.conf, and has to be restarted to pick them up. Likely this is because it's using its own resolver library instead of the system calls, but this is a real PITA, since the only "clean" way to restart the puppet agent, from within puppet, essentially amounts to issuing `/etc/init.d/puppet restart`in the middle of a catalog-run, which sucks for all the obvious reasons you would think it does. D -- 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.
