[svlug] Writing start-up scripts...

Dagmar d'Surreal dagmar at dsurreal.org
Sun Mar 18 20:45:01 PST 2001

On Sun, 18 Mar 2001, Rick Moen wrote:

> begin  Dagmar d'Surreal quotation:
> > Ships with _what_... (rhetorical question)  
> After Red Hat Software incorporated the TheNextLevel m4-based desktop
> autoconfigurator (which won its X desktop softare contest), in, what, v.
> 5.0? , and then followed that up with AnotherLevel in more recent
> versions, you may have noticed that it became really difficult to read
> and comprehend one's X setup.  
> Since they started doing that, I've had several Linux newcomers ask me
> to explain to them how their new Red Hat desktop configurations worked,
> found that I couldn't, and found that (relative) blessed simplicity
> returns if you bypass those Red Hat-isms using a ~/.xinitrc file.

Welcome to one of the reasons I hate RedHat.  Most of their attempts at
advancement create more problems than they solve.  I'll have to take your
word on the RedHat X configuration, because my usual solution for those
machines is to nuke it all and rebuild from source and _still_ just run
xf86config.  I gave up trying to deal with what they were doing to X
several releases ago.
> > The design goal is _portability_ regardless of platform.
> I honestly can't see the gain in having network configuration files have
> the exact same syntax between Solaris and Linux.  However, if I truly
> _did_ need that, I might seek to write wrappers for Linux's ifconfig and
> route functions that accepted Solaris syntax.

So you have no problems with digging through an /etc/netmasks file?  :)

> > I do not feel that a system administrator should have to be performing
> > the role of a software developer (even though shell scripts don't
> > require much "development" compared to other languages) when they're
> > configuring a system, and why on earth would one want to go and edit a
> > shell script and run the entire thing twice (or two different ones)
> > when they can invoke just one script with a few simple and obvious
> > arguments to administratively disable an interface or particular
> > features of an interface on demand. 
> I fail to see that editing a simple, self-documenting pair of ifconfig
> and route statements is in any way comparable to being a "software
> developer" -- nor that having to contend with a ridiculously baroque
> set of sed and awk invocations to dereference some bizarre ASCII network
> configuration files would be seen as an improvement in that area.
> But, of course, if one's design aims don't include readability, perhaps
> that's not a problem.

You apparently don't have people working with and for you who understand
network architechture, but can't write a shell script.  Putting a machine
on a different IP should not require programming skills.

> > Why bother?  I'd have to put them back in afterwards.
> No, that's _not_ what I meant.  We appear to have miscommunicated.  By
> "take them out", I meant disable them, programmatically.  And _then_
> "ifconfig ethN down."  Much simpler.
> > Not in this case.
> Oh, foo.  Try to sell that to some credulous novice, because I'm not
> buying.

Try dealing with dropping and reconfiguring interfaces while the equipment
in question is in the middle of a crushing DDoS attack.  You'll gain new
appreciation for having to conserve every clockcycle possible.

> > Damn, you _are_ incapable of rational debate.
> One cannot help noticing that you conspicuously avoided answering the
> question:  Are you insisting on taking a technical discussion personally
> because you _created_ that pile of mush Red Hat ships in lieu of a
> proper network init script?  (Not that that would be a good -- let alone 
> rational -- reason, but a poor motive is better than none at all.)

I'll enumerate my response in hopes that you'll be able to keep the
various points straight in your head.

1. I am not taking this personally.

2. You opened with a personal insult in this debate, after I stated that I
felt using an /etc/sysconfig directory to store network configuration
information was a reasonable idea.

3. The last time I checked, RedHat was not using any of my code, unless
they shipped an eggdrop rpm in their last set, in which case I am forced
to accept the responsibility of having written a few lines of patches for.

4. Never once did I take credit for anything RedHat has done. ...and don't
even try and blame me for it.

More information about the svlug mailing list