[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: init script config files



On Sat, Jul 08, 2000 at 10:38:30PM -0400, Christopher W. Curtis wrote:

> 
> If I wanted to persue 'my way', you could put all your custom code into
> the defaults.d file, leave the init script alone, and have it preserved
> without the init script being a conf file.

nope, because in the case of bind i had to alter the way it was
stopped and restarted, because the built in methods broke with the
chroot setup.  no way to do that without rewriting the initscript itself.

> Point is things don't start to get complicated without reason. 
> /etc/passwd was fine for a long time, then there was a "+" hack, now the
> nsswitch is a mess.  Deterioration by adding hack upon hack.  You may
> view this the same way, I don't.

i view this initscript obfuscation as deterioration.

> Not trying and never said I was trying to enforce anything.  I said I
> was trying to make consistency easier.

which your proposal will not do.

> I never said anything of the sort.  I said that instead of one file,
> make it two - one full of defaults, the other with overrides. 
> Additionally, if it is included by using this file (defaults), it can do
> the error checking that every script should also properly do.  As a side
> effect, those scripts would all have consistent error reporting, but to
> be more comprehensive, it needs to be expanded to error reporting for
> starting and stopping the deamon, and for actually displaying those
> messages.  And that is what I posted.

you want initscripts rewritten to use a bunch of functions held
elsewhere.  that is plain wrong.

start-stop-daemon already uses exit status error reporting, what more
do you need.  

> I didn't set out to rewrite s-s-d, as said before.  Consider it an

that is what you ended up doing, reimplementing start-stop-daemon,
poorly.

> "initscript helper".  It does all the proper checking (I'm not claiming
> it does this now) and implements the major functions that
> daemon-managing initscripts do.  It's not designed to be everything -
> just to make writing the basic initscript easier, provide consistent
> error checking and reporting, and support moving configuration changes

these items belong in individual initscripts.  initscripts should not
source other scripts, ever.  

> out of the files that get overwritten on a package upgrade.

you don't solve any problems, the config files will have to be
upgraded too same deal.

> Not the status I mean.  Just that the same error always returns the same
> error code.  This makes doing the color status thing easy when doing a

sucess == 0  failure == 1+  that is how it works now and its fine.

> 'foo start' or 'foo stop'.  Merely eye-candy, but some people like it;
> and there's no bad side to errors being consistent.  There's also talk
> about LSB wanting to make a standard initscript error code - if so and
> debain wanted to support it, the initscripts that use 'defaults' (in
> many cases) won't even need to be changed.

you don't need some obfuscated script full of functions to implement
exit codes, that should be done in individual initscripts.

> Now what happens when /etc/default/sysklogd.conf doesn't exist?

true, good reason to scrap the whole idea.  i have since decided this
config.d idea sucks anyway.

> > +. /etc/init.d/defaults sysklogd
> and all the needed checking (and consistent error reporting) is done
> there.

only if the rest of the script is rewritten to use all the functions
in your script, making the life of the admin hell.

> [being prompted about replacing a changed conffile]
> > > never said it was a bug.
> > no you just said it should go away.
> 
> And I still say that.

ok let me get this straight, asking permission to replace an altered
config file is not a bug but it should go away?  wtf.

> > ok so your saying that your lack of experience in redhat is why you
> > fail to see that your proprosed initscript system is flawed?
> 
> Sure.  What I tried to figure out when getting my network setup under
> redhat was *far* more complicated than what I've proposed.  I never

irrlevant, your proposal takes us down that redhat road.  a very bad
place to be.

> looked at the initscripts explicity.  For me, for what little I've used
> the initscripts, they've worked flawlessly (except that the damn 'modem'
> link is always set to /dev/cua2 after rebooting).

i have had numerous problems with redhats initscripts, they are quite
unreliable and broken.

> Redhat is completely screwy when it comes to configuring the network,

redhat is completely screwy about just about everything, they should
only be used as an example of what NOT to do.

-- 
Ethan Benson
http://www.alaska.net/~erbenson/

Attachment: pgp7kYc33aPic.pgp
Description: PGP signature


Reply to: