|
(0001100)
|
|
user4
|
|
2009-02-12 07:19
|
|
In fact, I implemented this behavior by purpose for now ...
Here's my reasoning: the 'networks' are needed only in a small part of installations, i.e. when remote networks are routed to the PF machine and PF should provide DNS and/or DHCP services to them. So, I didn't want to confuse users by showing this in the web admin GUI ... unless they had already configured at least one network 'by hand', i.e. by editing manually conf/networks.conf.
Here's an example config for networks.conf:
[192.168.42.0]
netmask=255.255.255.0
gateway=192.168.42.1
domain-name=registration.example.com
dns=192.168.42.1
dhcp_start=192.168.42.100
dhcp_end=192.168.42.175
dhcp_default_lease_time=300
dhcp_max_lease_time=600
|
|
|
(0001104)
|
|
maikel
|
|
2009-02-12 08:02
|
|
Ok that makes sense now.
The issue is, when enabling the vlan.named and vlan.dhcp code, there should be a popup informing a user then. Then in services.pm the parser can then be altered to use networks.conf.
# This file is generated from a template at %%template%%
# Any changes made to this file will be lost on restart
$TTL 3600
. IN SOA %%hostname%%. %%incharge%% (
2009020901 ; serial
10800 ; refresh
3600 ; retry
604800 ; expire
86400 ; default_ttl
)
IN NS %%hostname%%.
*. IN A 192.168.3.1
IN MX 5 %%hostname%%.
1.3.168.192.in-addr.arpa. IN PTR %%hostname%%
the ip address can be parsed from networks.conf then, making the template totally transparent. Now the user needs to give in information in more places, it makes it nicer and more compact then. |
|