[chef] RE: Re: RE: Re: Keeping DNS configuration eerrors from breaking working server with bind cookboks


Chronological Thread 
  • From: "Kadel-Garcia, Nico" < >
  • To: " " < >
  • Subject: [chef] RE: Re: RE: Re: Keeping DNS configuration eerrors from breaking working server with bind cookboks
  • Date: Wed, 25 Jun 2014 18:21:20 +0000
  • Accept-language: en-US

The extent to which I do *not* want to re-invent RFC compliant BIND 
verification, in ruby, from scratch, cannot be overstated. "named-checkconf" 
and "named-checkzone" do a pretty good job.

--
Nico Kadel-Garcia
Senior Systems Consultant
Email: 

Cell Phone: +1.339.368.2428



-----Original Message-----
From: Julian C. Dunn 
[mailto:
 
Sent: Monday, June 23, 2014 4:26 PM
To: 

Subject: [chef] Re: RE: Re: Keeping DNS configuration eerrors from breaking 
working server with bind cookboks

On Mon, Jun 23, 2014 at 11:27 AM, Kadel-Garcia, Nico 
< >
 wrote:
>    From: Julian C. Dunn 
> [mailto:
>   Sent: Monday, June 23, 2014 11:20 AM
>   To: 
> 
>   Subject: [chef] Re: Keeping DNS configuration eerrors from breaking 
> working server with bind cookboks
>
>   Can you just use "ignore_failure true" on the resources you don't care 
> about?
>
>   - Julian
>
> Not as things stand, no. For example, the old bind9 cookbook doesn't even 
> support DNS slaves, only forwarding. So it has no way to configure a 
> failover server for when the upstream chef managed DNS server has an issue. 
> And various classes of errors, such as various classes typos in the data 
> bags or accidentally having two distinct data bags for the same DNS domain, 
> will attempt to be loaded to the DNS server even when they pass any 
> reasonable JSON verification tool.
>
> That kills the BIND DNS server, and services that rely on it, quite dead. 
> So getting a configuration verification as a separate step seems, to me at 
> least, quite mandatory before trying to restart a core daemon. I do seem to 
> have a handle on the problem: I'm defining a "bash" operation with "action 
> :nothing", then summoning it with a rescue wrapped operation before the 
> daemon is restarted.

It sounds like you have enough esoteric failure conditions that a set of 
helper methods to validate things before proceeding (e.g. run in a ruby_block 
or something) would be handy.

- Julian

-- 
[ Julian C. Dunn 
< >
          * Sorry, I'm    ]
[ WWW: http://www.aquezada.com/staff/julian    * only Web 1.0  ;]
gopher://sdf.org/1/users/keymaker/           * compliant!    ;]
[ PGP: 91B3 7A9D 683C 7C16 715F 442C 6065 D533 FDC2 05B9       ]



Archive powered by MHonArc 2.6.16.

§