Re: Proposal: Network configuration file format
Inaky Perez Gonzalez wrote:
>
> >>>>> "Rene" == Rene Mayrhofer <rmayr@vianova.at> writes:
>
> Hi
>
> Pretty interesting ... describing the lay out of the network,
> sound really good; my comments follow
>
> On splitting the files, I think the sollutions is KISS: an
> 'include' directive. This would allow people to have the choice, and
> perhaps, multiple files are wise for some, whereas not for
> others. Using the include directive, the application which processes
> it to configure the network only has to read one file (aka
> /etc/network/conf) and do the work.
But in this case all the "included" config files must have the same
grammer. If this is OK with everybody, I have no objection.
> Rene> 1. Global: All definitions that are valid for the whole host.
> Rene> Any ideas what entries should belong here ?
>
> Well, the main host and fqdn. However, other interfaces
> (real/virtual) should be able to be called by it's name and fqdn.
I did not want to take them out of the usual places.
> Rene> All interfaces in one network entry share the same netmask and
> Rene> broadcast and network address as they are on the same physical
> Rene> network.
>
> I don't agree to this. As it is possible to have different
> interfaces plugged to the same physical network, this should be ok,
> but you may want to make different logical networks on the same
> physical network, and thus, allow the possiblity to make each
> interface have it's netmask and broadcast.
Different interfaces on the same physical network are no problem with
the structure. Just give another "network" definition where you specify
the second interface, but with the same netmask and network address. I
called it network to make it more understandable for the the beginners.
The only thing that is not possible (now - this could also be changed),
is that you have interface aliases on different netmasks and network
adresses. Does somebody really need that ?
> I've done this before (this setup), not now. Perhaps it's not
> a _big_ point, but I think offering the choice would be ok.
When you have eth0 and eth1, no problem.
> Rene> [Interfaces] Optional parameters:
>
> I'd also add more ifconfig's stuff, like setting MAC addresses
> and such (in the sam fashion as ifconfig 'hardware-address ether
> de:ad:be:ef:00:32', for example).
Sure. I want to have nearly all options in it (but I would go for "ip",
not for "ifconfig").
> Rene> # The ISDN connection to the outside
> Rene> network "isdn" { ...
> Rene> # Maybe we should put in the ISDN settings here too (telephone
> Rene> # number, protocol, ...)
>
> I think it should do. Having all the info centralized
> somewhere helps making it easy. However, I don't know the case of
> ISDN, but on PPP (dialout) there's currently a nice setup to have
> different chatscripts and peers to login. If ISDN has something
> similar [I'm sure], it'd be nice to be able to define, somewhere
> inside the ISDN/PPP stuff, or perhaps outside, as it is done now (as
> /etc/chatscripts) stuff like this:
>
> chatscript "provider0"
> {
> # Two setups, the fast one and a detailed one. This is a detailed one
> timeout = 30
> abort_on = { BUSY, "NO CARRIER", VOICE, "NO DIALTONE" }
> chatsequence = { "", ATZ0, OK, ATDT342232324, CONNECT }
>
> # A fast one
> telephone = 3223245
> }
>
> some stuff should be added for more advanced chat features and
> logging.
>
> As well, for the peers (actually /etc/ppp/peers), I think that should
> go into the ppp section which would get all the global PPP options
> /etc/ppp/options, and inside, each peer would have a similar
> structure:
>
> ppp-dialouts
> {
> # Global PPP options
> option1
> option2
> ....
> peer "my provider"
> {
> options ...
> chatscript "whatever"
> link-up
> {
> # per-provider actions to do on link-up
> execute = "programs to execute on up link"
> ...
> }
> # Similarly with link-down
> }
> ...
> ...
>
> link-up
> {
> # Global actions to do on link-up
> execute = "programs to execute on up link"
> ...
> }
> # Similarly with link-down
> }
>
> and so on; the thing is there's no need to change the actual PPP
> structure, as a set of update-network-* scripts or your config program
> would translate that information into the actual /etc/chatscripts and
> /etc/ppp/* files.
>
> You may object this would interfere or step over the toes of
> network definitions. I'm trying to build up how this should work
> together, but I'm thinking of something like:
>
> # The PPP connection to the outside [shamelessly copied from your ISNDs]
> network "ppp" {
> interface "ppp0" { ppp "my provider" }
> # some stuff more?
> }
>
> perhaps something like this would allow the two methods to co-exist
> and ease it's configuration. I see problems, for example, that the
> newtork "ppp" section may refer to interface "ppp0" and ppp "my
> provider" could use interface ppp1. This is a consistency problem
> which should be addressed by the configuration tool or the wise
> administrator :)
I think this is a very good idea. At the first stage I did not want to
go this far (when I was alone ;-) ), but it is an option. We should
discuss this with the maintainers of isdnutils and ppp.
> Well, just more ideas to confuse. I'm willing to do something
> useful for Debian, and I'd love to help you out with this. Have free
> time [not too much, but guess enough], so please count with me for
> coding stuff for this. The only thing I don't know too much is
> firewalling, but on the ppp side and easing stuff for novices I'd like
> to help.
Be careful with such things, I might take your offer :-). I would be
happy, because I do not have very much experience with ppp setups
(however I did a few firewalls).
Rene
Reply to: