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

Lawrence K. Chen, P.Eng. lkchen at ksu.edu
Tue Aug 4 03:36:25 UTC 2015


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 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...)

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.  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....

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.

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.

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?  To hold us/me over until they decide if its going to be 
BlueCat or Infoblox that replaces everything.

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 ;)

There were a couple of other interruptions in my upgrading my 20 servers, but 
I don't recall what the issue was with those now.

-- 
Who: Lawrence K. Chen, P.Eng. - W0LKC - Sr. Unix Systems Administrator
                                    with LOPSA Professional Recognition.
For: Enterprise Server Technologies (EST) -- & SafeZone Ally


On 2015-08-03 10:06, Reindl Harald wrote:
> Am 03.08.2015 um 16:59 schrieb Anand Buddhdev:
>> On 03/08/15 16:50, Heiko Richter wrote:
>> 
>> Hi Heiko,
>> 
>>> Why use the "file" option at all on a slave?
>> 
>> If you don't use the "file" option on a slave, then BIND does not write
>> the zone to disk. This is okay for a small number of small zones. But if
>> you have many zones, or they are large, then you usually want to save a
>> copy of the zone to disk, so that at restart, BIND can load the zones in
>> quickly
> 
> and load them at all in a acceptable timeframe
> 
> if it doesn ot save them to disk as you said and you have some hundret zones
> you likely exceed transfer ratelimits and it takes unacceptable long until
> you slave responds while clients already ask him
> 
> the next problem with not having them on disk is: god beware if your master
> is down and due analyzes or before you recognize the problem you restart
> your slave named or the server
> 
> 
> _______________________________________________
> Please visit https://lists.isc.org/mailman/listinfo/bind-users to
> unsubscribe from this list
> 
> bind-users mailing list
> bind-users at lists.isc.org
> https://lists.isc.org/mailman/listinfo/bind-users


More information about the bind-users mailing list