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! ////
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.
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?
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 ? "
could you post an example what is your generated named.conf looks like? it would be easier to answer your question...
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; }; }; };
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...
no what i want to do is ispconfig to place the zone in the two different views. it's not very complicated to understand how views and acl works on bind ! actualy ispconfig does the stuff but it make it TWICE in EACH view.
Ah, that's the problem. You can check /root/ispconfig/scripts/lib/classes/ispconfig_bind.lib.php to find out why this is happpening.
