Re: RFC: new network config (was: Re: network configuration)
On Sat, Feb 13, 1999 at 12:47:05PM +0900, Richard G. Roberto wrote:
> 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.
it sounded like what you were describing was a system which saved the
current state of the network interfaces upon a shutdown and restored
them automagically at reboot. sort of like an automatic "copy running
startup" on a cisco.
personally, i think that's brain-damaged. manually changing interfaces
is for trial-and-error style experimentation - to find out what works,
and/or what needs to be done. when you've determined that, you (the
system admin) deliberately make changes to script or config files to
reflect that.
trying to automatically save them requires the computer to do some kind
of mind-reading to tell the difference between good experiments that
the admin wants to keep vs bad experiments that the admin doesn't want
to keep (and indeed, may be bad enough that they are the reason WHY the
machine is being rebooted right now).
> I just think taking a hard line either way is going to alienate some
> of us (myself included).
my "hard line" is 'whatever the system admin puts in the config files is
correct even if it's brain-damaged and just plain wrong' - i.e. i don't
presume to know better than the local admin, my program does exactly
what it is told to do and nothing more.
> 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).
what i'm writing is the opposite of that. it makes no assumptions. it
does exactly what it is told to do, and doesn't attempt to second-guess
the admin's intentions. if you tell it to configure a vhost, it does it.
if you forget to tell it, then that's your tough luck - the mistake may
teach you some discipline.
> > 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.
what else can you do? always assume the admin has screwed up?
what you are suggesting is to presume that all of a sysadmin's manual
experimentation is known and good and deserves to be saved into the
config files automagically.
my approach is to presume that the admin knows what s/he is doing and
anything that they have deliberately put into the config 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
fine. explicit control = edit the scripts or config files.
> > > 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?
you are over-generalising from what i said. try reading it again, but
this time read back through the thread and look at it in the context
of what i actually said i am writing (a package to help automate some
common tasks associated with virtual hosting).
> > 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.
you've got me...i have no idea how you've managed to survive if you
haven't realised basic things like this.
> 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?
not at all.
i write to satisfy my own muse - if it's useful to others, good luck to
them. if others have contributions to make which improve it, then i am
happy to accept patches.
i do NOT write things which i think are evil and stupid. if you want
that, you can write it yourself.
> Shouldn't the local sysadmin be able to make the decisions that
> directly affect him (and his bonus)?
if someone thinks my approach is wrong, then they should feel free to
implement their own virtual host system.
i have absolutely no interest in implementing something as insanely
brain-damaged as automatically doing the equivalent of "copy
running-config startup-config".
i am writing a generic version of stuff that i have found useful over
the years in the hope that it is useful to others. it is not trying to
be all things to all people, it is implementing a few very specific and
useful functions which make it easier to do certain repetitive tasks.
> 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.
to the contrary, it is making no assumptions and doesn't do anything it
isn't explicitly told to.
> If it can't be flexible, then why not just use linuxconf?
i am not writing anything that even pretends to be remotely like
linuxconf.
> 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?
to gain control over my virtual-services package, you edit config
file(s) in the usual way.
i think you are arguing about something you haven't even bothered to
research first.
> 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.
automagically saving a running config over your startup config is not
"flexible", it is broken.
craig
--
craig sanders
Reply to: