[9fans] ip/ipconfig

[9fans] ip/ipconfig

[baldwin]

pardon, but does anyone else think that ipconfig maybe should
figure out the ip stuff all by itself?  these elaborate ipquery
dances seem a bit tedious.

Re: [9fans] ip/ipconfig

[Scott Schwartz]

| pardon, but does anyone else think that ipconfig maybe should
| figure out the ip stuff all by itself?  these elaborate ipquery
| dances seem a bit tedious.

I agree.  ipconfig does significant magic, but stops short in an
unexpected way.

Also, when launching ppp I find that it's easier to not use ipconfig,
which makes me believe that it needs rethinking.

Re: [9fans] ip/ipconfig

[Boyd Roberts]

From: Scott Schwartz <schwartz@bio.cse.psu.edu>

> I agree.  ipconfig does significant magic, but stops short in an
> unexpected way.

that's what i've always thought.

Re: [9fans] ip/ipconfig

[presotto]

[-- Attachment #1: Type: text/plain, Size: 818 bytes --]

You must have a fairly different situation.  I always use ipconfig
to start ppp, like now from san diego:

	ip/ipconfig -b115200 ppp /dev/eia000

Part of that may be that every situation I live in uses dhcp to
get everything I need.  Ditto for ethernet ipconfig.  Clearly
I'm missing a lot of people's situations.  I can easily change
ipconfig to use lib/ndb/* or cs to get it's info and only use
dhcp if the former fails of if specificly asked to using a flag.

I can only defend putting dhcp into ipconfig because we don't run
systems standalone at all and that's all ipconfig every does to
get info at our lab.  However, I agree that separating the funcions
might be useful.  If I ever need dhcp for anything other than configuring
IP, I'll probably do it (or someone will probably beat me  to it).

[-- Attachment #2: Type: message/rfc822, Size: 1599 bytes --]

From: Scott Schwartz <schwartz@bio.cse.psu.edu>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] ip/ipconfig
Date: Tue, 24 Oct 2000 22:52:25 -0400
Message-ID: <20001025025225.26800.qmail@g.bio.cse.psu.edu>

| pardon, but does anyone else think that ipconfig maybe should
| figure out the ip stuff all by itself?  these elaborate ipquery
| dances seem a bit tedious.

I agree.  ipconfig does significant magic, but stops short in an
unexpected way.

Also, when launching ppp I find that it's easier to not use ipconfig,
which makes me believe that it needs rethinking.

Re: [9fans] ip/ipconfig

[anothy]

//This could avoid creating conflicts between the arguments
//give ipconfig and what is in the network database.

but if the arguements to ipconfig come from from cs (which,
in turn, gets them from the ndb files), where's the risk of
conflict? you pretty much need cs anyway, and in the scheme
proposed, ipconfig now has to know how to parse the ndb
files, complete with imposed ipnet heirarchy. i'm in favor
of limiting how many places that magic gets included in.
especially since the big win seems to be saving a few lines
in /rc/bin/[term,cpu]rc.
-α.

Re: [9fans] ip/ipconfig

[Mark C. Otto]

The IP configuration notes (Getting Started With Plan 9, Documents, p. 34) say
that DHCP will configure your ethernet card if you have a network database
entry.  In my case, I just have a terminal and do not have DHCPD(8) running.  I
configured my ip address much like Anthony and Kenji
(anothy@cosym.net@cse.psu.edu and arisawa@ar.aichi-u.ac.jp@cse.psu.edu).

I have a similar question to Scott Scwartz's:  would ip/ipconfig be duplicating
the functionality of ndb/cs(8) if one could specify a network database file to
ip/ipconfig that would then match the ethernet addresses of all the machine's
ethernet cards.  Then all the information in the database would not have to be
duplicated or extracted manually.  Kenji's elegant script could be simplified:

Set ipconfig in plan9.ini:  either

ipconfig=dhcp

or

ipconfig=local

then in termrc
ndb/cs
sysname=`{cat /dev/sysname}
switch($ipconfig){
case local

# Do not need these now
#        eval `{ndb/ipquery sys $sysname ip}
#        eval `{ndb/ipquery sys $sysname ipgw}
#        eval `{ndb/ipquery sys $sysname ipmask}
#        ip/ipconfig -g $ipgw ether /net/ether0 add $ip $ipmask

# Only need, say an option (say -c for cs) to use the given network database
	ip/ipconfig -c /lib/ndb/local

case dhcp
        ip/ipconfig >/dev/null >[2=1]

This could avoid creating conflicts between the arguments give ipconfig and what
is in the network database.  The Plan 9 developers could give us a better
perspective than I.

Mark

Re: [9fans] ip/ipconfig

[anothy]

i'm unconvinced. given the different ways a system can get its
ip address, i'm not so sure i want them all in ipconfig. i'm
not even entirely comfortable with having the dhcp client in
there. but i guess there's something to be said for having _a_
automatic configuration method in there. that being said...

you probably don't want to duplicate the functionality of
ndb/cs. and if you're not using DHCP, doing cs queries seems
like the right way to get the info (whether they're done in
ipconfig or [term,cpu]rc). loads of other apps are going to
expect ndb/cs as well, so it's got to be running at _some_
point. so the only real differences are 1) where ndb/cs gets
started and 2) what does the queries.

is it really worthwhile to increase the complexity of
ipconfig, when there's an existing, more modular way to get
the same results, and most setups won't need it anyway?

and what's the issue with using ipconfig for ppp? i find that
the easiest way to go about it. but again, that's additional
magic in one program. i'd sort of rather see a /net/ppp0 or
such, and treat it like /net/ether0.
-α.