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