[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: /etc/init.d/network is too simple?



Adam, I'm Cc'ing you directly because you've been one of the bigger
agitators for roving profiles, and I'm curious as to your opinion on
how well/badly the following would work.

On Sat, Apr 17, 1999 at 06:43:54PM -0400, Brian Mays wrote:
>     Avery> That would be pretty neat.  Of course, the ip-up directories
>     Avery> need to know how to bring up and interface, not just what to
>     Avery> do once we're connected.
>     Avery> I think?
> Nope.  These are things to run after the interface has been brought up and
> after it goes down.  Of course, we should pass to these scripts what
> kind of interface it is being called for, such as eth0 or ppp0.

Okay. The goals for reworking networking config are:

	* Simple configuration files
	* Support static ethernet cards with minimal configuration
	* Support sound modems and other weird interfaces
	* Support IPv6, AX25, Appletalk and other weird protocols
	* Support dynamic configuration of interfaces
	* Support routing, and dynamic configuration thereof
	* Support roving profiles (a la PCMCIA schemes)

For the first bunch of those, I'm envisaging an /etc/interfaces file
something akin to:

] lo inet
]   loopback
] eth0 inet
]   dhcp
] sm0 inet noauto
]   address 192.168.1.1/24
]   up sethdlc -i sm0 -p mode sbc:afsk1200 io 0x220 irq 5 dma 1 serio 0x2f8
]   up setserial /dev/ttyS1 uart none
]   up smmixer s=line
]   up smmixer i=-10
] sm0 ax25
]   callsign VK3TYD

The format's essentially:

	iface addr-type
		addr-param arguments...
		addr-param arguments...

with ifup/ifdown programs that will up/down any particular interface. "dhcp"
means run the dhcpcd program with appropriate options and base the address
on that, "up" means run these programs before doing whatever you'd normally
do, and so on.

All in all, I think this bit works pretty sweetly.

The more confusing part is getting roving profiles done properly -- the idea
here is that you ought to be able to just plug your laptop in to any network
and have it "just work", no matter what DNS, proxy, mail, ntp, NIS, CODA,
NFS or whatever settings may be required/desirable.

To get this right, we need two things: one, we need to know what the
right settings are. These come either from DHCP or similar, or a hard
coded setting somewhere (like /etc/pcmcia/network.opts). Two, we need to
have some reasonable way of changing them -- adding to /etc/resolv.conf
or changing /var/named/boot.options, rerunning bindconfig and restarting
named, eg.

So what I'm currently thinking of is something like this:

For every service you want some control of, you need to make a script
like,
	/etc/ip-up.d/foo
	/etc/ip-down.d/foo
that does whatever you need done. [0]

Then, for every parameter you'd like to vary, you have a setting in
/etc/interfaces something like

] home inet
]   interface eth0
]   dhcp
]   X-proxy proxy.dynamic 8080
] uni inet
]   interface eth0
]   address 100.101.102.103/24
]   X-proxy resproxy.uq.edu.au 80

[1] [2]

The shell variable PROXY would then be set before /etc/ip-up.d/foo was called
at which point foo could behave suitably.

For variables like DNS, either something like:

]   X-dns 1.2.3.1
]   X-dns 1.2.3.2
]   X-dns 1.2.4.1

DNS = 1.2.3.1
DNS_2 = 1.2.3.2
DNS_3 = 1.2.4.1

or

DNS = "1.2.3.1 1.2.3.2 1.2.4.1"

could be made to work.

The real problem is getting this to work for both static addresses and
DHCP and kin. For static addressing one of Debian's utilities needs
to handle this itself as soon as the interface is up. For dhcp, dhcpcd
has to handle this itself, since the address, nameservers, proxies or
whatever can change dynamically. It might work just to say "Well, sure,
ifup will call all those programs itself, but it won't have set any
environment variables, so it won't matter; dhcpcd will call them with
env variables and everything'll be dandy". I'm not quite sure.

OTOH, this requires modifying dhcpcd and bootp and friends. This might
be a pain, but I have a suspicion it's not avoidable.

> Nevertheless, I agree 100% that the configuration of static network
> connections should remain as simple as possible.  I just don't see the
> need for the extra complexity.

FWIW, with the above this should end up being something like:

] lo inet
]   loopback
] eth0 inet
]   address 192.168.1.57/24
]   gateway 192.168.1.1

Cheers,
aj

[0] /etc/ip-up.d might be better just being runlevel 3 instead of runlevel
    3; or it might not. This is doing a similar job to runlevels, but in a
    more fine grained way, which might cause problems. We'll see.

[1] The "script" I use to change proxies for PCMCIA, btw, is:

	[ ! "$WEBCACHE_SERVER" ] || /usr/local/sbin/start-stop-daemon \
		--start --daemonize --pidfile /var/run/redir.webcache \
		--exec /usr/bin/redir -- $WEBCACHE_SERVER 8080 $WEBCACHE_PORT

    and

	[ ! "$WEBCACHE_SERVER" ] || /usr/local/sbin/start-stop-daemon \
		--stop --pid /var/run/redir.webcache

    Netscape and lynx point to localhost:8080 as their proxy. It needed some
    hacks to start-stop-daemon (Bug#35117) because cardmgr/popen() is borked,
    but still.

[2] I'm not quite sure what a good way of representing "schemes" is atm.
    Something like

	[scheme] ...
	  interface [iface]
	  ...
    or
	[iface] ...
	  scheme [scheme]
	  ...

    is probably the way to go for this file, but how you choose a
    scheme, and how you have one of them come up at boot time could be
    a bit dicey.  For now, just assume that it works like this.

-- 
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. PGP encrypted mail preferred.

``Like the ski resort of girls looking for husbands and husbands looking
  for girls, the situation is not as symmetrical as it might seem.''

Attachment: pgpn_pFMMFUvn.pgp
Description: PGP signature


Reply to: