Mark Andrews wrote:
In message <4adb44a5.2060...@htt-consult.com>, Robert Moskowitz writes:
Chris Thompson wrote:
On Oct 18 2009, Joseph S D Yao wrote:

On Sat, Oct 17, 2009 at 10:33:37PM -0400, Robert Moskowitz wrote:
I am trying to build up an environment where the user can maintain custom files and leave the basic files alone.

So I have a named.acl that works, I add an include line:

acl "hdanets" {
        192.168.1.0/24; // hda network
        include "custom.acl";
};


and get the error:

Starting named:
Error in named configuration:
named.acl:3: missing ';' before '"'
...


Glancing through the 9.6 ARM <https://www.isc.org/files/Bv9.6ARM.pdf>,
it seems to me that "include" is a statement, and needs to be parsed
outside of any other statements, not inside a statement.
That's what it *says* ... but it is being economical with the truth!

                                                         Inside the
"acl" statement the parser would expect to see IP addresses, networks in
the ip.ad.dr.ess/xx format, keys with the name prepended by the keyword
"key", and the names of other ACLs.  When it encounters the word
"include" in this context, it parses it as the name of an ACL - after
which, the '"' is out of place.
As long ago as BIND 9.2, you'll find this in the CHANGES file:

764.   [func]          Configuration files now allow "include" directives
in more places, such as inside the "view" statement.
                       [RT #377, #728, #860]

Roughly, "include" can occur instead of a keyword in any list where all
list elements are introduced by keywords; e.g. "view", "options", "logging", "zone". But not "acl" because the elements there do not (in general) start
with keywords.
Oh, fiddlesticks!!!!  ;)'

This complicates matters. It would have made it very easy to bootstrap into this process if this was supported.

acl's can include other acls.
I'm having a hard time seeing why you need to include a file here.

include "custom.acl"; // defines acl "customacl"

acl "hdanets" {
        92.168.1.0/24; // hda network
        customacl;
};

Neat.

Though I solved the problem by having 2 includes in named.conf, for named.acl and custom.acl. Then in the view, I listed two variables: hdanets; customnets

So is the case of six of one, half-a-dozen of the other? That is they are equal solutions to this situation?

As for why I am doing this, hdanets.acl is built by the system's script that I have no control over. It will contain what the script has on my internal networks. It only supports one network. But some users of this system (like me) have a number of internal networks that we want to be able to access this system, so custom.acl is outside of the controlling script and can be maintained by an informed installer, like me. There is also a custom-zone.conf and custom-n2a.zone and custom-a2n.zone...

As we improve the system, there will be less need for these, but I believe they will always be needed.

Oh, the system this is for is AMAHI.ORG.

For the whole truth, you need to look at lib/isccfg/namedconf.c and
lib/isccfg/parser.c and work out in exactly which cases cfg_parse_mapbody
in the latter gets called :-(
I am not much into reading c code. I never really programmed in c. Did do some programming in b....

So reading someone elses script and recommending changes has been challenging enough!


_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users
_______________________________________________
bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Reply via email to