I'm thinking the answer is to update your init script, to make sure that restart calls rndc reload, and specify "hasrestart" in your resource definition.
I suggest this because bind should ignore bad zone files, and keep serving the old zones, when reloaded via rndc. Maybe the answer is to also incorporate named-checkzone and some sort of email notification into the restart section of your init script. As always test, and you milage may vary. Cheers, Brian On Sun, Sep 11, 2011 at 10:35 AM, Dan White <y...@comcast.net> wrote: > @Jon - If you find an answer to your question, please post it to the list. > I'd like to see the answer and there are probably lots of other folks who > would benefit from the info being in the mailing list archives. > > Good luck. > > On Sep 11, 2011, at 12:00 AM, Aaron Grewell wrote: > > Perhaps just add an exec step or two to your regular run? Put the file in a > temp location then move it to the live one if it checks out? > On Sep 10, 2011 8:01 PM, "Jon Forrest" <nob...@gmail.com> wrote: > > On 9/10/2011 6:57 PM, Jonathan Stanton wrote: > >> > >> Maybe I'm missing something here, but I think Jon was asking > >> something a bit different -- he doesn't want to check the validity of > >> the erb template (i.e. ruby syntax check) but syntax check the named > >> zone file generated by the template. > > > > Precisely. Maybe later I'll face the issue of ruby syntax > > problems but right now I need to detect named syntax errors > > before they cause problems. > > > >> So the tricky bit is how to get the variables out of the puppet > >> manifests that the erb template needs to generate the output file > >> that 'would' be generated by a new puppet run for this node -- > >> without the actual puppet run (as he asks at the end of the email). > > > > Precisely again. > > > >> My first thought is that the only accurate way to do this is by doing > >> a full puppet run, as any part of the node's manifest could effect > >> the variables used in the zone file template. You should be able to > >> get away with a --noop run so the changes won't actually be applied > >> (because noop does generate files from templates, but you would need > >> to have a way to capture the newly generated zone file on the client > >> host and run the named-checkzone there. > > > > That's what I figured. I was hoping that there would be an easier way > > that could somehow do a facter run but only run the minimal amount > > of puppet. > > > > Jon > > > > > > -- > > 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. > > > > -- > 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. > > > -- > 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. > -- <http://aws.amazon.com/solutions/solution-providers/brandorr/> -- 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.
