RE: RFC: new network config (was: Re: network configuration)
Craig Sanders writes:
> 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.
Hmmm, that's not quite what I had in mind, but rather having the ability reconcile between
autogenerated alias interfaces via foo.bar.com associations and direct eth0:x syntax. It should
be doable any time (not at shutdown) and have nothing to do with the actual state of the
interfaces, but rather the two coexisting config files.
> personally, i think that's brain-damaged. manually changing interfaces
Again, your expert advice is a real eye opener. Did you take condescension lessons or something?
> 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.
I think this is exactly the point -- where to make the manual change so its preserved at next boot.
If there's a way to do it using your package, that's good. I must have mis-interpreted what you wrote.
I thought you were saying that manual changes get blown away at every reboot, which would put your
package in the "no thanks" category.
> 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).
This is absurd, but whatever. I have no trouble managing thousands of sun systems using methods
like the ones I describe on this list, but there's no point in arguing nonsense. If your package provides
an admin with control over the configuration of aliases, that's good enough.
> > 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.
Done deal then -- I obviously misinterpreted it when you said it wouldn't deal with manually configured
interfaces at all, and that it would blow them away and recreate them "correctly". You obviously
meant that interfaces created at the command line would get blown away and stuff in the config files
would be preserved as is (even if its broken -- which is fine by me. I'd rather be the one to do the
breaking than an autoconfigure script).
> >
> > 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?
Huh? You lost me here, but nevermind. How about always assuming the admin is right? Oh well.
> 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.
Hmmm, this sounds interesting too. Are there plans to have a script capture the current live config
and generate config files for it? That would be useful for the kind of experimentation you keep
alluding to.
> > > 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
^^^^^^^^^^^^^^^^^^^
Um, one of the purposes of this list is to try to generalize common admin tasks and come up
with a centralized common tool set to automate them. I think I was doing that, and you seem
to agree. How is this a bad thing?
> > > 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.
Hmm, maybe I've just been lucky. Then again, maybe your ideas aren't he only right ones.
Even if they themselves are, there may be others that are as well. Indeed, situational correctness
is a reality, which is why flexibility is so important. Zen administration baby -- listen to the network ;-)
Cheers,
Rich
Reply to: