[svlug] Writing start-up scripts...
dagmar at dsurreal.org
Sun Mar 18 16:39:02 PST 2001
On Sun, 18 Mar 2001, Rick Moen wrote:
> begin Dagmar d'Surreal quotation:
> > You know, in some parts of the country parents teach their children to
> > not deliberately insult strangers.
> Mine taught me to never _accidentally_ insult strangers. I mean, that
> would be just sloppy workmanship.
> > ...and that's great if you have a box that never changes, or you're
> > just configuring one machine and not expecting to replicate your work
> > to others. Of course if you happen to replicate your work to more
> > than one machine, writing everything into one shell script with
> > hardcoded values is _inexcuseably_ incompetent.
> There is, of course, no reason why simple ifconfig and route statements
> cannot (1) replicate to multiple deployments and (2) be equally
> parseable as all that baroque crap. If you have a problem figuring out
> how, I can recommend a few good tutorial books.
> And, as much as you're theatrically scandalised by my derision of those
> idiotic network configuration files, you should hear how I characterise
> the window manager configuration setup that ships with it -- which
> fortunately can be bypassed even more easily, with a simple .xinitrc
Ships with _what_... (rhetorical question)
> However, I should take the trouble to amend what I said earlier. The
> network setup would be "painfully incompetent" if the design aims
> included simplicity, elegance, and comprehensibility. However, on
> reflection, I infer that, for that product (and the company's work,
> generally), those who aspire to understand and _like_ their systems'
> designs are just not part of the target market.
The design goal is _portability_ regardless of platform. I've gotten the
same thing working on Solaris, and you can't possibly expect anyone to
believe that Solaris network initialization scripts don't need to be
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.
> > No, I happen to occasionally need to bring down interfaces for
> > extended periods of time and don't feel like leaving all the old
> > firewalling rules and whatnot taking up memory in the meantime.
> So, take them out first, genius.
Why bother? I'd have to put them back in afterwards. I'll stick with a
mechanism that's more amenable to using a simple shell command to turn it
off, and another to turn it back on (or simply reboot and everything comes
back up like it's supposed to, regardless of whether or not the
administrator remembers to re-enable the interface).
> > _Some_ of us understand that modularity in design allows one to
> > leverage previous work against current problems, and that putting
> > together a ton of one-time use solutions is simply wasteful.
> _Some_ of us understand that straightforward methods can be
> mass-deployed as easily as poorly-written one, if not better.
Not in this case.
> > I've had enough of arguing with you and Raffi about this.
> What a coincidence! I'm bloody tired of your empty posturing on the
> > ...but insulting me....
> Excuse me, but who are _you_ again? I don't remember mention you in
> this conversation, sir, at all.
> Are you telling me that _you personally_ concocted that steaming pile of
> rubbish I was speaking of, earlier? If so, you're welcome to take
> personal offence if that makes you happy. (This _is_ California, after
> all: Taking offence when convenient is probably in the state Bill of
> Rights.) But I most certainly did not have you in mind -- nor do I have
> any idea who or what you are, or particular care, either.
Damn, you _are_ incapable of rational debate.
More information about the svlug