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

Re: RFC: new network config (was: Re: network configuration)

On Wed, Feb 10, 1999 at 09:03:30PM +1000, Anthony Towns wrote:
> On Tue, Feb 09, 1999 at 08:27:10AM +1100, Craig Sanders wrote:
> > i'm against hardcoding the eth0:n alias number into a config file. it
> > gets clumsy when you've got a few hundred aliases on a machine. let a
> > script count it.
> > 
> > i.e. ip-aliases should have their own config file, rather than clutter
> > up the main /etc/interfaces. whether this is done in netbase or a
> > virtual-services package doesn't really matter.
> What do you think of virtual-services.deb adding
> ### aliases for virtual-services ####
> eth0:0  ip=
> eth0:1  ip=
> eth0:2  ip=
> eth0:3  ip=
> eth0:4  ip=
> ### aliases for virtual-services ####
> ...to /etc/interfaces? Is that enough?

i'd rather not touch (write to) /etc/interfaces at all...i'd prefer to
find an alternative, less potentially destructive way of doing it.

> Basically, I'm wondering if there's still any need to add extra fields
> to /etc/interfaces or similar to support this?

probably not. how about if we think of alias interfaces as belonging to
one of two classes?

the first class is "static" aliases, created by the system admin for
special purposes...these get defined in /etc/interfaces.

the second class is "dynamic" or "virtual-host" aliases, created
automagically by the virtual-services package. these get defined in

> Oh, there are two reasons why I, personally, have used aliases in the
> past -- once, because I was a dialup machine and wanted to have my
> dialed-up IP always available because that was the one with the nice
> hostname, and I preferred nice.hostname:80 as my home page, rather
> than localhost:80, or whatever. The other is miscellaneous testing
> purposes.

yep, i've done that too. it's also useful when the machine is an
internet gateway box running apache...having an eth0:0 alias for their
real internet address allows the local client machines to access
www.domainname whether they are currently connected to the internet or
not.  and mail clients can connect to mail.domainname, etc etc.

> So it'd be nice if virtual-services coped with starting counting from
> $last+1, or whatever.


do you know how to get a list of alias interfaces? with the old ifconfig
under 2.0.x kernels, "ifconfig" or "ifconfig -a" would display all of
the interfaces, including aliases.

under 2.1.x or 2.2.x kernel, it doesn't display the aliases...and i
can't seem to find anything in /proc or /proc/net which lists them.

this is probably a case of RTFM, but if someone has already figured out
how to do it i'd appreciate being clued in :-)

i'll have to think about this a bit as doing this will complicate
things a lot. i usually just blow away and re-create(*) all of the
alias interfaces each time my alias ifconfig script is run...but this
is only a good thing to do if it is the only thing which creates alias

(*) this is useful to do when the details of an alias interface have
changed - i.e. correcting a mistake like a mis-typed IP address. it's
nice to know that you can just re-run the alias iface creation script
and all mistakes will be corrected.

maybe the simplest thing to do would be to count the number of alias
interfaces defined in /etc/interfaces, and start creating them from
n+1...but this doesn't correctly cover the situation when a new alias
has been added to /etc/interfaces AFTER virtual-services has been run.

needs some thought figuring out all the possible things that could go
wrong and catering for them...

hmmm. maybe the "correct" (safest) way to do it is for
/etc/init.d/interfaces to call my virtual-services interface creation
script if it exists. then the Right Way<tm> for a system admin to create
*ALL* of the interfaces is always to run /etc/init.d/interfaces - that
way, all interfaces, including aliases, will always be created in the
correct order.

this means that i will have to write my alias creation script in sh,
rather than perl. ok, no big deal.


craig sanders

Reply to: