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

[Craig Sanders <cas@taz.net.au>]

On Thu, Feb 11, 1999 at 01:13:55PM +0900, Richard G. Roberto wrote:
> 
> Craig Sanders writes:
> > 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.
>
> I don't see how this will automatically do the right thing if I
> manually set up an alias.

it handles it exactly the same as a reboot would....i.e. not at all.

there's nothing stopping anyone from creating alias interfaces manually,
but if you want that alias interface to come up again after a reboot
(which is generally exactly what you DO want), then you have to add it
to a config file or script.

> Perhaps the safe thing to do is to provide behavior that rejects
> a manually configured interface that conflicts with a previously
> autoconfigured alias, but this behavior could be overridden (or
> optionally not employed) in which case the virtual service aliases all
> get bumped up.  The behavior should be consistent though, e.g. if I
> manually configure eth0:1 and then eth0:11, the first interface alias
> defined should be eth0:12, etc.

i see cleaning up the cruft of manual config as one of the advantages
of knowing that /etc/init.d/network will blow away all interfaces and
re-create them in a known "correct" order.

this may not always be exactly what you want, but at least you have a
defined starting point to return to so you have predictable behaviour.
predictability is a virtue.

being able to easily get to (or revert to) a known good working state is
very useful - i'd class it as being vital, especially if you have paying
customers who expect minimal disruption and downtime.


> I don't believe the auto-install tool we've been discussing is
> intended to be useful for this sort of thing, but it would be good to
> have a generic way of snapshotting config data (especailly for more
> dynamic, or potentially dynamic data) for later reference.

maybe. in some ways it could be a good thing - but i think it would tend
to encourage sloppiness and, over time, a heap of ugly cruft would creep
into the "snapshot" config files.

i strongly prefer tools which encourage a disciplined approach by making
it easy to be disciplined, and providing numerous obvious benefits in
return.

i.e. encourage admins to do the Right Thing by making it easier and
significantly better than doing the Wrong Thing.

craig

--
craig sanders