ERROR : - writeable file 'data/udalgurijudiciarygov.hosts': already in use: /etc/nicnet2007.govdomain:15424 - loading configuration: failure

[/dev/rob0]

On Mon, Aug 03, 2015 at 10:36:25PM -0500,
   Lawrence K. Chen, P.Eng. wrote:
> This unfortunately looks like the thread for me to jump on to....
> 
> I missed installing the last two 9.9...-p# patches, first time I 
> built everything and was pretty much ready to do it, and then 
> forgot all about it due to health issues.  More recent one...I had

I hope you're well now.

> got it built for Solaris x64 and was about to work on building it 
> for Solaris SPARC when the most recent one appeared.  This one 
> carried a much strong get things patched (to me at first, then 
> higher ups started jumping around...)

It's good that you have deployed the fix for CVE-2015-5477.  Those 
who are ignorant or foolish would say this shows the problems with 
free software.  But that's opposed to the truth: these security 
reports are the strength of free software.  Anyone can hack at it 
looking for bugs.  And then those bugs get fixed.

Who knows what bugs lurk inside black-box proprietary solutions?
Worse, who knows if they'd be fixed?  Security is in openness, 
standing up to the light of scrutiny.

> But, it turned out to be a huge mess to upgrade.
> 
> The first time I ran into this error, were some really old mistakes 
> where the admin had copy and pasted a bunch of similar zones...and 
> missed adjusting some of the files.  Since on the master side they 
> all come from the same file....it probably didn't cause any 
> noticeable problems for the slaves or clients.
> 
> However, install upgrade on our master server...knocked it out, so 
> I'm here looking to see what the proper fix for my situation is.

This seems to be a bug fix (not allowing named to share writeable 
files) which has brought a lot of broken configurations out.  Oops.

Basically, no two slave zones (even nominally the same zone, in a 
different view) should EVER share the same file.  Master zones can 
get away with file sharing, but ONLY if named does not write to the 
file (no allow-update, update-policy, nor auto-dnssec.)

> Looking for a valid easy fix here ;) Partly because coming soon 
> they're going to demolish the DNS infrastructure that I got saddled 
> with and feel like I done a pretty good job at re-engineering it to 
> meet all the demands of it.  But, I'm the last legacy unix systems 
> administrator here....

Sad.  There's nothing "legacy" about Unix, though.  Sounds like the 
salesmen are winning out over the technicians, in terms of getting 
management to set policy.

> Anyways...the problem is because we had turned out existing master 
> server into doing split/stealth (started out stealth...) DNS, while 
> having it continue to serve as slave to delegated subdomains.  So 
> that those subdomains are propagated to our external facing slave 
> servers.
> 
> So that's where the problem comes in....the internal authoritative+ 
> nameservers having the master collect secondary zone data from 
> them...on the Internal view.  But, then having to send that 
> information to nameservers that hit the external view of the 
> master.

The way to select a different view on the master is to use TSIG keys.

https://kb.isc.org/article/AA-00295/

> So, until a few hours ago....it was include a file containing all 
> the delegated (sub)domains into both views....causing both sides to 
> be working off of the same file.

It would require some reworking of things, but you might be 
interested in the new BIND 9.10 feature of "in-view" zone option.
This lets you literally include a zone from another view.  See BIND 9 
ARM chapter 6, "zone Statement Definition and Usage", for details.

> WHich seemed to work fine.  As only one side is getting updates, 
> the other side is just to feed our outside facing slaves.  Well, 
> this update wouldn't go for that.
> 
> So, cloning the file and doing a global search and destroy....the 
> external view is looking zone files in a directory that is emtpy, 
> while the internal side continus as is.
> 
> To have something for the external nameservers to transfer 
> (hopefully), I'm doing a regular sync of the file 'sec' to 'ext'.
> 
> Not totally sure that's working....but nothing filing up logs
> about it.
> 
> So, is what I did something that'll hold...or is there an easy 
> proper solution to this?

Slave zones should be transferred using DNS.  In a stealth master 
case, you need to populate also-notify lists, but perhaps in your 
case you can share some of that configuration with global or view 
level settings.  (Better than having to set everything per zone.)

> To hold us/me over until they decide if its going to be
> BlueCat or Infoblox that replaces everything.

IIUC both of those are BIND under the hood. :)

> Sadly, I missed both presentations due to other issues....more sad 
> because I found my "named.iner" shirt, which I was going to wear to 
> the second presentation ;)

Haha, I have one of those also.  Really cool. :)
-- 
  http://rob0.nodns4.us/
  Offlist GMX mail is seen only if "/dev/rob0" is in the Subject: