Re: [PROPOSAL] New Network Startup Procedure
>Hi everyone,
>
>The New Plan
>+++++++++++
>
>The new plan provides a much cleaner procedure for starting up the
>network. Essentially there are two scripts. One symbolically linked to
>rcS.d called local_network which simply initializes the loopback
>networking (127.0.0.1) and a slightly more complicated script,
Separating out loopback setup is probably good since loopback always needs
to be there no matter what other network interfaces are enabled...
>network_init, that would be symbolically linked to the separate run
>level directories, which will perform any other networking
>initialization as required. The main advantage of this new method is
>that neither of these scripts need be touched. All networking
>configuration changes are made in a configuration file that is parsed by
>network_init using Corel?s etcdev program. This configuration file /
>network_init combination also facilitates the use of multiple network
>cards and the combination of dynamic / static configurations. It also
>lets the user select which network interface they wish to use and which
>method of selecting IP address they prefer.
This all sounds nice in theory--but will it be extensible, or will all
enhancements of this method have to be implemented in Corel's network-setup
(or whatever) package?
>Network Configuration File
>--------------------------------
>
>[network.<1..n>]
> device = <name> # i.e. eth0, eth1, etc
If you're doing enhancements, maybe it'd be nice to have a more robust (in
terms of hardware changes or kernel recompiles) way to specify this. For
Ethernet, maybe MAC address or driver would be good. OTOH, 'eth0' is good
for single-interface (or single-ethernet) machines since it makes it easy
to change cards.
Filfre to say 'show me the code' if you think this would be too much work
to implement...
> type = <type> # i.e. dynamic or static
There are several kinds of dynamic ip address assignment--rarp, bootp,
dhcp, as well as separate methods used for slip and ppp. Hopefully this
method won't be limited to just dhcp.
Perhaps separate packages could choose to implement arbitrary network types
... it could become a useful hook like the menu system.
> status = <net status> # i.e. up or down
good idea
> ipaddr = <xxx.yyy.zzz.nnn>
> netmask = <xxx.yyy.zzz.nnn>
> broadcast = <xxx.yyy.zzz.nnn>
> gateway = <xxx.yyy.zzz.nnn>
>
>Each network card will have its own [network.n] configuration block
maybe also have a 'name =' field so that people can use friendly names
(like 'inside', 'outside', 'dmz', 'sales', 'production', etc) if/when
routing and forwarding configuration tools are built that work on top of
this scheme?
--
James Deikun, Techie(tm), CSI Multimedia
The opinions expressed &c.
Reply to: