Re: init script config files
You are just being beligerant. I understand how dpkg handles it. Point
conceded that it must still be a conffile. I am not proposing a one
size fits all anything.
Ethan Benson wrote:
>
> On Sat, Jul 08, 2000 at 07:44:28PM -0400, Christopher W. Curtis wrote:
> >
> > As I said initially, and said specifically to you, it is not, cannot, is
>
> as i have said and you continue to ignore, needs of sysadmins are
> diverse, there are times when i simply want to rewrite an initscript
> from scratch to do something totally different. unless its a config
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.
> i have been told that SuSE's scripts are even more obfuscated then redhat's
>
> but who the hell cares how they do it. most distributions use RPM
> does that mean we should to?
>
> or hell most people use Windows i guess we should all use it too to be
> consistent.
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.
> consistency is not an end all goal, debian's initscripts are
> consistent enough for the most part, trying to `enforce' more
> consistency will only cause problems. as i have said and you continue
> to ignore: one size does not fit all dammit.
Not trying and never said I was trying to enforce anything. I said I
was trying to make consistency easier.
> # Options for start/restart the daemons
> # For remote UDP logging use SYSLOGD="-r"
> #
> SYSLOGD=""
>
> this could easily be moved into a seperate file sysklogd.conf which
> sysklogd sources and you get the same thing. when this topic first
> came up i argued that this perhaps would be a useful thing to do but
> *ONLY* if the config files contained nothing more then variables like
> the above SYSLOGD=""
>
> your the one who comes along and says the only way to do this is to
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 are sugessting this festering boil of an initscript system be made
> debian policy whereby all debian developers would be forced to use
I never made any such claims. I think it would be good for developers
to volentarily use it if they can, and I said that explicitly.
> slackware, where admin control is the utmost priority. either that or
> OpenBSD.
I stopped using slackware because upgrading a package wiped out all my
configurations without bothering to either prompt me or save the old
ones. That was many years ago (didn't have to happen more than once
before I switched) so hopefully for your sake that practice has
changed. I am ignorant BSDisms.
> > That was my assertion about -f.
>
> fwiw i agree that scripts should use -x rather then -f but i don't
> think its that big a deal.
I didn't think it would be either.
> > nope. I see what it does, it does a lot, and it doesn't really seem as
> > useful as something tailored to initscripts. As I'm pretty sure I've
>
> gee i wonder why start-stop-daemon was written anyway, i think the
> only purpose for its being is to be used inside initscripts.
I didn't set out to rewrite s-s-d, as said before. Consider it an
"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
out of the files that get overwritten on a package upgrade.
> who the hell needs status anyway, when i used redhat i found it to be
> the most worthless thing ever conceived, it never was very accurate.
>
> the way to find out status is ps aux | grep foo period.
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
'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 are suggesting debian policy to use a obfuscated redhat esque
I do not. I merely want to provide an option. Debian policy does not
require the use of start-stop-daemon, yet some scripts chose to use it.
baffling...
> the initscript should be written just as they are now, for example
> here is a patch to sysklogd's initscript to implement the config file:
>
> -----cut-----
> --- /etc/init.d/sysklogd Wed Sep 15 02:02:31 1999
> +++ /tmp/sysklogd Sat Jul 8 16:58:57 2000
> @@ -4,14 +4,9 @@
> test -f /sbin/klogd || exit 0
> test -f /sbin/syslogd || exit 0
>
> -# Options for start/restart the daemons
> -# For remote UDP logging use SYSLOGD="-r"
> +# get configuration variables $SYSLOGD and $KLOGD
> #
> -SYSLOGD=""
> -
> -# Use KLOGD="-k /boot/System.map-$(uname -r)" to specify System.map
> -#
> -KLOGD=""
> +. /etc/default/sysklogd.conf
>
> case "$1" in
> start)
> -----cut-----
Now what happens when /etc/default/sysklogd.conf doesn't exist?
A patch to use my system looks the same, except
> +. /etc/default/sysklogd.conf
becomes
> +. /etc/init.d/defaults sysklogd
and all the needed checking (and consistent error reporting) is done
there.
Same applies to the remainder of your message, no changes.
[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 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
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).
Redhat is completely screwy when it comes to configuring the network,
but Debian isn't a whole lot better (well, ok, it is a whole lot better,
but far from ideal). Solaris does a pretty good job, but that's nothing
I have the energy to discuss here.
Christopher
Reply to: