RE: RFC: new network config (was: Re: network configuration)
Craig Sanders writes:
> 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.
I think I was describing a method of guarenteeing a working system that behaved predictably while still allowing
an admin to manually configure stuff if he/she chooses. I just think taking a hard line either way is going
to alienate some of us (myself included). Flexibility should be a required design goal so people can choose
which state is the preferred state to return to at reboot time (i.e. the one the just manually configured or
the potentially broken auto-configured state -- HP/UX has far to omuch "automagically" configure rubbish
for my taste that's impossible to get around, for example).
> 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.
You are also presuming that the auto-configured state is a) known and b) good. There are numerous
times as an admin that I much prefer that I explicitly control certain things on a system and I should be able
to choose when that is. I work in the financial markets and there is no place on earth where downtime is less
acceptable except an emergency room or IC unit.
> > 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.
Again, you have a unique interpretation of this. How is having a standard tool for storing configuration
data "undisciplined"? Shouldn't a proper tool make storing such data very disciplined? at least conceptually?
> i.e. encourage admins to do the Right Thing by making it easier and
> significantly better than doing the Wrong Thing.
That's great Craig. I wonder how I've managed to survive in this industry for 10 years without hearing that before.
Has it occurred to you that your idea of the right thing or wrong thing is less significant than the guy whose arse is
on the line? Shouldn't the local sysadmin be able to make the decisions that directly affect him (and his bonus)?
I think that deciding in advance for someone else about what they "should" do is making the same mistake that
every other similar tool makes. If it can't be flexible, then why not just use linuxconf? That's a very mature, but
inflexible configuration solution (that I believe deals with IP aliases out of the box, or could easily be extended to).
If the only way I get control over the boot process is to not use the package at all then I think its in the same boat
as linuxconf so what's the difference?
I guess I just don't understand why having flexibility becomes so undesireable when you're solving everyone else's problem since its all that matters when I'm solving my own.
Rich
Reply to: