HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials

HowtoForge Forums | HowtoForge - Linux Howtos and Tutorials (http://www.howtoforge.com/forums/index.php)
-   Installation/Configuration (http://www.howtoforge.com/forums/forumdisplay.php?f=16)
-   -   problem with named.conf.master (http://www.howtoforge.com/forums/showthread.php?t=5865)

tetsuo44 28th July 2006 17:45

problem with named.conf.master
 
i've modified the named.conf.master to add support off view.
problem : when i save configuration zone are duplicated in each view......
so if i create a zone toto.titi.org it appears twice in both external and internal view.... any idea ?

here is the template :
Code:

acl "xfer" {
        127.0.0.1;
};

acl "trusted" {
        127.0.0.1;
};

options {
        pid-file "/var/run/bind/run/named.pid";
        directory "{BINDDIR}";
        auth-nxdomain no;
        /*
        * If there is a firewall between you and nameservers you want
        * to talk to, you might need to uncomment the query-source
        * directive below.  Previous versions of BIND always asked
        * questions using port 53, but BIND 8.1 uses an unprivileged
        * port by default.
        */
        // query-source address * port 53;

        allow-transfer {
                xfer;
        };

        allow-query {
                trusted;
        };

};

view "internal-in" in {
        // Our internal (trusted) view. We permit the internal networks
        // to freely access this view. We perform recursion for our
        // internal hosts, and retrieve data from the cache for them.

        match-clients { trusted; };
        recursion yes;
        additional-from-auth yes;
        additional-from-cache yes;
        allow-query {
                any;
        };

        allow-transfer {
                any;
        };

        // prime the server with knowledge of the root servers
        zone "." {
                type hint;
                file "db.root";
        };

        // be authoritative for the localhost forward and reverse zones, and for
        // broadcast zones as per RFC 1912

        zone "localhost" {
                type master;
                file "db.local";
        };

        zone "127.in-addr.arpa" {
                type master;
                file "db.127";
        };

        zone "0.in-addr.arpa" {
                type master;
                file "db.0";
        };

        zone "255.in-addr.arpa" {
                type master;
                file "db.255";
        };

        <!-- BEGIN DYNAMIC BLOCK: named_reverse -->
        zone "{ZONE}.in-addr.arpa" {
                type master;
                file "pri.{ZONE}.in-addr.arpa";
        };
        <!-- END DYNAMIC BLOCK: named_reverse -->

        <!-- BEGIN DYNAMIC BLOCK: named -->
        zone "{DOMAIN}" {
                type master;
                file "pri.{DOMAIN}";
                allow-query { any; };
        };
        <!-- END DYNAMIC BLOCK: named -->

        <!-- BEGIN DYNAMIC BLOCK: named_slave -->
        zone "{DOMAIN}" {
                type slave;
                file "sec.{DOMAIN}";
                masters { {MASTERS}; };
        };
        <!-- END DYNAMIC BLOCK: named_slave -->
};

view "external-in" in {
        // Our external (untrusted) view. We permit any client to access
        // portions of this view. We do not perform recursion or cache
        // access for hosts using this view.

        match-clients { any; };
        recursion no;
        additional-from-auth no;
        additional-from-cache no;
        // Link in our zones
        // prime the server with knowledge of the root servers
        zone "." {
                type hint;
                file "db.root";
        };

        // be authoritative for the localhost forward and reverse zones, and for
        // broadcast zones as per RFC 1912

        <!-- BEGIN DYNAMIC BLOCK: named_reverse -->
        zone "{ZONE}.in-addr.arpa" {
                type master;
                file "pri.{ZONE}.in-addr.arpa";
        };
        <!-- END DYNAMIC BLOCK: named_reverse -->

        <!-- BEGIN DYNAMIC BLOCK: named -->
        zone "{DOMAIN}" {
                type master;
                file "pri.{DOMAIN}";
                allow-query { any; };
        };
        <!-- END DYNAMIC BLOCK: named -->

        <!-- BEGIN DYNAMIC BLOCK: named_slave -->
        zone "{DOMAIN}" {
                type slave;
                file "sec.{DOMAIN}";
                masters { {MASTERS}; };
        };
        <!-- END DYNAMIC BLOCK: named_slave -->
};

//// MAKE MANUAL ENTRIES BELOW THIS LINE! ////


falko 29th July 2006 13:54

This happens because you put this block:

Code:

<!-- BEGIN DYNAMIC BLOCK: named_reverse -->
        zone "{ZONE}.in-addr.arpa" {
                type master;
                file "pri.{ZONE}.in-addr.arpa";
        };
        <!-- END DYNAMIC BLOCK: named_reverse -->

        <!-- BEGIN DYNAMIC BLOCK: named -->
        zone "{DOMAIN}" {
                type master;
                file "pri.{DOMAIN}";
                allow-query { any; };
        };
        <!-- END DYNAMIC BLOCK: named -->

        <!-- BEGIN DYNAMIC BLOCK: named_slave -->
        zone "{DOMAIN}" {
                type slave;
                file "sec.{DOMAIN}";
                masters { {MASTERS}; };
        };
        <!-- END DYNAMIC BLOCK: named_slave -->

in both views... It causes ISPConfig to write exactly the same information in both views.

tetsuo44 29th July 2006 15:09

right but this is exactly what i need.
If you use view (to manage acl) you have to write the zone in both view.
The problem is that ispconfig write two time the same zone in both view.
I guess you undestand what i mean.

falko 30th July 2006 17:25

Quote:

Originally Posted by tetsuo44
right but this is exactly what i need.
If you use view (to manage acl) you have to write the zone in both view.
The problem is that ispconfig write two time the same zone in both view.
I guess you undestand what i mean.

Yes, I understand, but by putting the same block in both views ISPConfig writes the same data to both views. How is ISPConfig supposed to know which data it should write to which view?

tetsuo44 30th July 2006 19:14

mmmh ... yes i understand, but a block is nothing more than a target for a search and replace action made by the php script. If the replace is global this should not happen. Anyway, the question is "how can i do what i want to do ? " :confused:

todvard 30th July 2006 20:28

could you post an example what is your generated named.conf looks like? it would be easier to answer your question...

tetsuo44 30th July 2006 21:31

here is a samble of my named.conf

Code:

view "internal-in" in {
        // Our internal (trusted) view. We permit the internal networks
        // to freely access this view. We perform recursion for our
        // internal hosts, and retrieve data from the cache for them.

        match-clients { trusted; };
        recursion yes;
        additional-from-auth yes;
        additional-from-cache yes;
        allow-query {
                any;
        };

        allow-transfer {
                any;
        };

        // prime the server with knowledge of the root servers
        zone "." {
                type hint;
                file "db.root";
        };

        // be authoritative for the localhost forward and reverse zones, and for
        // broadcast zones as per RFC 1912

        zone "localhost" {
                type master;
                file "db.local";
        };

        zone "127.in-addr.arpa" {
                type master;
                file "db.127";
        };

        zone "0.in-addr.arpa" {
                type master;
                file "db.0";
        };

        zone "255.in-addr.arpa" {
                type master;
                file "db.255";
        };

        zone "XX.191.88.in-addr.arpa" {
                type master;
                file "pri.XX.191.88.in-addr.arpa";
        };
        zone "XX.191.88.in-addr.arpa" {
                type master;
                file "pri.XX.191.88.in-addr.arpa";
        };


        zone "sd-XXXX.dedibox.fr" {
                type master;
                file "pri.sd-XXXX.dedibox.fr";
                allow-query { any; };
        };
        zone "sd-XXXX.dedibox.fr" {
                type master;
                file "pri.sd-XXXX.dedibox.fr";
                allow-query { any; };
        };


};

view "external-in" in {
        // Our external (untrusted) view. We permit any client to access
        // portions of this view. We do not perform recursion or cache
        // access for hosts using this view.

        match-clients { any; };
        recursion no;
        additional-from-auth no;
        additional-from-cache no;
        // Link in our zones
        // prime the server with knowledge of the root servers
        zone "." {
                type hint;
                file "db.root";
        };

        // be authoritative for the localhost forward and reverse zones, and for
        // broadcast zones as per RFC 1912

        zone "XX.191.88.in-addr.arpa" {
                type master;
                file "pri.XX.191.88.in-addr.arpa";
        };
        zone "XX.191.88.in-addr.arpa" {
                type master;
                file "pri.XX.191.88.in-addr.arpa";
        };


        zone "sd-XXXX.dedibox.fr" {
                type master;
                file "pri.sd-XXXX.dedibox.fr";
                allow-query { any; };
        };
        zone "sd-XXXX.dedibox.fr" {
                type master;
                file "pri.sd-XXXX.dedibox.fr";
                allow-query { any; };
        };


};


falko 31st July 2006 17:16

Quote:

Originally Posted by tetsuo44
mmmh ... yes i understand, but a block is nothing more than a target for a search and replace action made by the php script. If the replace is global this should not happen.

Again: How is ISPConfig supposed to know which data it should write to which view?

tetsuo44 31st July 2006 19:03

tou do no read my comments falko ? i've answered with a fragment of my named.conf

falko 1st August 2006 14:35

I don't understand what you want. You copy the same code fragment into the template file, and then you want ISPConfig to replace the same code fragment with different data??? This cannot work...


All times are GMT +2. The time now is 17:27.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2014, vBulletin Solutions, Inc.