Re: Single slave zone definition for two view (cache file name problem)
On 18.03.2015 11:56, Matus UHLAR - fantomas wrote:
On 18.03.15 11:48, Constantin Stefanov wrote:
But in fact the configuration with only one writable file referenced
several times is suported now. If I write:
view view1 {
zone aaa.exampe.org {
masters {IP;};
file slave/aaa.exmaple.org;
};
};
view view2 {
zone aaa.exampe.org {
in-view view1;
};
};
then both views will refernce ther same writable file, won't they? Or am
I missing something about in-view directive?
And if I'm right, the only question is how to simplify the configuration
so not to have two definitions in two files for every slave zone which
is shared between views.
maybe you could put all those zone definitions into one file and include it
in each view.
I can't. It stopped working after upgrade to 9.10, but worked before
with 9.6. And the question is how to keep the config as simple as it was
before upgrade.
the only other way is stop using views...
--
Konstantin Stefanov,
Research Computing Center
M.V Lomonosov Moscow State University
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
I see why it may lead to problems.
But in fact the configuration with only one writable file referenced
several times is suported now. If I write:
view view1 {
zone aaa.exampe.org {
masters {IP;};
file slave/aaa.exmaple.org;
};
};
view view2 {
zone aaa.exampe.org {
in-view view1;
};
};
then both views will refernce ther same writable file, won't they? Or am
I missing something about in-view directive?
And if I'm right, the only question is how to simplify the configuration
so not to have two definitions in two files for every slave zone which
is shared between views.
On 18.03.2015 1:25, Mark Andrews wrote:
Referencing the same writable file in multiple places in named can:
* lead to corrupted journals
* the wrong zone content being published in the wrong view
* named not being able to serve zone content when restarted when the
master is down
* content not showing up in a timely manner
* extra zone transfers recovering from the above
If you failed to experience one or more of these you were lucky.
There is a good chance that some of these things were happening and
you were not even aware.
We got bug reports about all of these events that were caused by
the same writable file being referenced multiple times.
Referencing the same writeable file multiple times has never been
a supported configuration. This is now being caught.
Mark
--
Константин Стефанов,
Лаборатория параллельных информационных технологий НИВЦ МГУ
тел. +7 (495) 939-23-41
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
On 17.03.2015 19:34, Tony Finch wrote: Constantin Stefanov cs...@parallel.ru wrote: I found 'in-view' option, but again it requires two definitions for every zone: one with file and masters directives, and another with in-view option. Moreover, these two definitions must be in different files, as I have to include one in first view, and another (with 'in-view') in all other views, so I have to keep two separate files synced with one another. I have a similar situation on my workstation server, except in my case the recursive view needs static-stub configurations for each zone in the authoritative view. I have a script called named-listzones (attached) which reads named.conf and outputs a list of zone name, view, and type. A bit of seddery in the rc script re-generates the static-stub zone configuration whenever named is started or reloaded. Tony, thanks for the script. I am doing something like that myself now, and using make as suggested in neighbour letter is a way, too. My grievance is that previously it worked without any scripting, and now the scripting is required. Maybe I do not see something? -- Konstantin Stefanov, Research Computing Center M.V Lomonosov Moscow State University ___ Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from this list bind-users mailing list bind-users@lists.isc.org https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
On 17.03.2015 18:32, /dev/rob0 wrote:
On Tue, Mar 17, 2015 at 05:36:57PM +0300, Constantin Stefanov wrote:
After upgrading from BIND 4.6 to 4.10.2, named requires that
different slave zone have separate file for cache.
Surely you mean s/4/9/g, and yes, this is true.
Of course, sorry.
With 4.6 I had the following config:
named.conf:
view internal {
match /* match condition */;
include common.zones;
};
view external {
match /* match condition */;
include common.zones;
};
common.zones:
zone aaa.example.org {
type slave;
file slave/aaa.example.org;
masters {MASTERIP;};
};
It worked fine with 4.6 (although it was considered incorrect).
After upgrade to 4.10 named started complaining:
common.zones:3: writeable file 'slave/aaa.example.org': already in
use: common.zones:3
As I understand, now I need to have separate files for different
views.
But is there a way to have them automatically assigned and to write
something like:
file slave/aaa.example.org.${view_name}
or any other way to have only one defininition for common zones?
Here is an easy suggestion:
view common {
match-clients { none; };
zone example.com {
type slave;
file common/example.com;
masters { example.com-masters; };
};
// repeat for other common zones
};
And then your other views can be defined and use the include file as
before, with each zone being:
in-view common;
I found 'in-view' option, but again it requires two definitions for
every zone: one with file and masters directives, and another
with in-view option. Moreover, these two definitions must be in
different files, as I have to include one in first view, and
another (with 'in-view') in all other views, so I have to keep two
separate files synced with one another.
So is it possible to have only one definition for slave zones that
are shared between different views?
Hmmm. I am not sure if there is a good workaround for that. But
there are tools like make(1) which can do this for you? I would
suggest a script to generate the common.zones file from whatever
you're using for the common view.
Maybe someone else will have a better suggestion?
Well, using make and scripting is certainly an option, but not having to
use it is better in my opinion. And as I said in another letter, with
9.6 there was no need for scripting.
I do not generate common.zones, I write it by hand. And now I have to
make a script that generates another common.zones.internal from
previous common.zones or generate them both from comon source.
I any case it is unnecessary (in my view) complication caused by
upgrade, I would call it a regression, as I used this config for at
least five years, and now I have to invent something.
So I am asking for better solution, too. But reading docs and googling
did not give me a clue.
--
Konstantin Stefanov,
Research Computing Center
M.V Lomonosov Moscow State University
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Re: Single slave zone definition for two view (cache file name problem)
On 17.03.2015 18:05, Lightner, Jeff wrote:
4.x would be quite ancient. Where are you getting those version
numbers? You should be using 9.x these days so I suspect the BIND
version isn't what you think it is.Is it possible the version
you're reporting is you OS rather than your BIND?
What is reported when you run named -v?
I mistyped, I meant 9.6, sorry.
Anyway what we do is in our views is simply name the internal zone
files the same as external and prepend internal- to the name.
e.g. myzone.com = external zone file internal-myzone.com = internal
zone file.
If they're the same you can simply copy from one to the other.
Sometimes they are not the same which is why you have views in the
first place.
These files are created by named itself, so I can't simplycopy them. The
question is not where to get the files, the question is how to simplify
config. With 9.6 I could have only one definition for a zone shared
between 2 views, although it was considered incorrect.
After upgrade to 9.10 old config does not work and I see no way to keep
the config as simple.
The question is - how to make the config simple, as was available before
upgrade.
-Original Message- From: bind-users-boun...@lists.isc.org
[mailto:bind-users-boun...@lists.isc.org] On Behalf Of Constantin
Stefanov Sent: Tuesday, March 17, 2015 10:37 AM To:
bind-users@lists.isc.org Subject: Single slave zone definition for
two view (cache file name problem)
Hello.
After upgrading from BIND 4.6 to 4.10.2, named requires that
different slave zone have separate file for cache.
With 4.6 I had the following config:
named.conf:
view internal { match /* match condition */; include
common.zones; };
view external { match /* match condition */; include
common.zones; };
common.zones:
zone aaa.example.org { type slave; file slave/aaa.example.org;
masters {MASTERIP;}; };
It worked fine with 4.6 (although it was considered incorrect).
After upgrade to 4.10 named started complaining:
common.zones:3: writeable file 'slave/aaa.example.org': already in
use: common.zones:3
As I understand, now I need to have separate files for different
views.
But is there a way to have them automatically assigned and to write
something like:
file slave/aaa.example.org.${view_name}
or any other way to have only one defininition for common zones?
I found 'in-view' option, but again it requires two definitions for
every zone: one with file and masters directives, and another
with in-view option. Moreover, these two definitions must be in
different files, as I have to include one in first view, and another
(with 'in-view') in all other views, so I have to keep two separate
files synced with one another.
So is it possible to have only one definition for slave zones that
are shared between different views?
-- Konstantin Stefanov,
Research Computing Center M.V Lomonosov Moscow State University
___ Please visit
https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
bind-users mailing list bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
___ Please visit
https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from
this list
bind-users mailing list bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
--
Konstantin Stefanov,
Research Computing Center
M.V Lomonosov Moscow State University
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
Single slave zone definition for two view (cache file name problem)
Hello.
After upgrading from BIND 4.6 to 4.10.2, named requires that different
slave zone have separate file for cache.
With 4.6 I had the following config:
named.conf:
view internal {
match /* match condition */;
include common.zones;
};
view external {
match /* match condition */;
include common.zones;
};
common.zones:
zone aaa.example.org {
type slave;
file slave/aaa.example.org;
masters {MASTERIP;};
};
It worked fine with 4.6 (although it was considered incorrect).
After upgrade to 4.10 named started complaining:
common.zones:3: writeable file 'slave/aaa.example.org': already in use:
common.zones:3
As I understand, now I need to have separate files for different views.
But is there a way to have them automatically assigned and to write
something like:
file slave/aaa.example.org.${view_name}
or any other way to have only one defininition for common zones?
I found 'in-view' option, but again it requires two definitions for
every zone: one with file and masters directives, and another with
in-view option. Moreover, these two definitions must be in different
files, as I have to include one in first view, and another (with
'in-view') in all other views, so I have to keep two separate files
synced with one another.
So is it possible to have only one definition for slave zones that are
shared between different views?
--
Konstantin Stefanov,
Research Computing Center
M.V Lomonosov Moscow State University
___
Please visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe
from this list
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
