Re: init script config files
[again removing -policy]
Ethan Benson wrote:
>
> On Sat, Jul 08, 2000 at 12:40:01PM -0400, Christopher W. Curtis wrote:
> >
> > Well ... I think we're just going to disagree here, because I think this
> > way makes init scripts simpler, more elegant, more clear. and less
> > fragile.
>
> your method does the exact oposite it makes scripts less elegant, less
> clear and more fragile, along more more obfuscated.
As I said, we disagree.
> the initscripts most certianly cannot go away. conffiles must NEVER
> be removed unless a package is purged. and the initscripts even with
> a config.d system *MUST* remain conffiles. why? because this
> config.d thing is NOT going to let the admin do what he needs done in
> all cases. one example is bind. i have about 80% rewritten that
> initscript. there is no way in fucking hell a config.d approach would
> have worked.
As I said initially, and said specifically to you, it is not, cannot, is
should not try to be a end-all solution. Every initscript that uses
defaults.d (config.d - whatever) does *not* need to be a conffile. And
should not be. Why? Because anything that can be configurable belongs
in the configuration file, not in the script. If a script can't put
everything in there, then it must be, yes. This is a way to get a chunk
of them out of that hairy (mho again) situation.
> uncessasry redhat obfuscation. why don't you just go back to redhat
> and leave us alone?
Give me a break. I have one redhat machine because, oh, debian didn't
run on the alpha at the time?
How does SuSe handle this? Caldera? TurboLinux? We know that RedHat
and HP-UX do it something like this - maybe there's a very good reason
for it. Are you arguing that it's easier to keep things consistent when
you have 100 different people writing every init script from scratch?
Or do you just not care about consistency and/or maintenance?
> > Modifying the script (ie, by the maintiner) to add a variable would go
> > something like:
> >
> > edit /etc/init.d/foo:
> > start)
> > start foo
> >
> > to be:
> > start)
> > start foo $PORT
> >
> > and adding to /etc/init.d/defaults.d/foo
> > PORT="1025"
>
> the "$PORT" example can be done without all your redhat garbage. the
> initscript can source *ONE* fscking file that contains *ONLY* fscking
> variables.
Your argument (which you deleted) was that modifying a script was easy
doing it 'the old way'. This simply shows that doing the same was just
as easy 'this way'. It is not to be used as an example of anything
else.
> > Like I said in my very first message - it won't handle all cases, I hope
> > it will handle about 80% of them though. Nobody is forcing anyone to do
> > anything.
>
> if debian adopts this horrible mess it most certainly is forced upon
> me. or rather i would be forced to switch distributions.
How is it fored on you? If you write scripts, you're not forced to use
it (though users might make that suggestion); if you just run it, you
can still edit the file manually.
And which distribution would you be considering?
> > Adding these functions allows a consistent errorcode mechanism to be
> > implemented trivially for those daemons that can use it, which is
> > something I think that debain should have and this provides.
>
> no it does not.
Oh, it's so *obvious* now.
> initscripts that are done properly don't spew messages to the
> console. a simple 2> /dev/null takes care of that.
That was my assertion about -f.
> when i see `term sshd' i have no idea what the fsck is going to
I think you might be in the minority, then, as anyone who has used kill
should be able determine what "stop) term foo;;" and "restart) usr1
foo;;" *probably* do.
> > > or start-stop-daemon --stop --quiet --exec /usr/sbin/sshd
> >
> > Yes, there is duplication with start-stop-daemon. I am not intimate
>
> in other words:
> "i just don't understand how it works so it sucks"
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
said, this is fine for executing programs, and can be useful in my own
script, but does not replace the ability to do things like "start) start
foo; status $?; exit $? ;;". [NB: In my own code, I added "return $1"
to the end of the status function to make this work. Also eliminates
the need to save $? in the generic case.]
> now instead of just having the bloody start-stop-daemon command in the
> initscript you want to wrap it in a function that you hide in a bunch
> of redhat spaghetii include files somewhere? and you say your trying
> to make things easier on the admin?
Yes. start-stop-daemon isn't enough as shown above, and since it
doesn't support the notion of defaults.d, adds nothing to initscripts in
that regard. Since you dispute the usefulness of defaults.d, you will
find no validity to my argument.
> please tell me how hiding how the system works from the admin is
> helping him?
Nothing is hidden from the admin. Comments are generous.
> sounds like "configuration options should be moved out of conf files
> and into a monolithic Windows registry so things can be consistent,
> more clear, and less fragile."
You can think of it like that if you wish, but I'd like to think of it
more like "instead of compiling all of these options directly into the
executable, why don't we stick them in an external file so it's easier
for users to modify".
> removing the real initscript on remove but not purge WILL destroy user
> settings regardless of whether a config.d system is in place or not.
It certainly won't. The initscript can be removed and the user created
config file can remain.
> one size does not fucking fit all.
As repeated here and in numerous Pepsi commercials, "duh".
> furthermore your redhat mess is not required for the $RUNPORTMAP
> option that can be done as previously suggested by having a SINGLE
> file with ONLY variables. there is absolutly no need to obfuscate the
> initscripts like redhat has done to get this option.
I feel like I'm writing to a wall. Don't want to use the functions?
Don't. Want to include the file directly? Fine. To the end user, it
all works the same way.
> > Now, as you can see, I've removed stuff that shouldn't be in there,
> > abbreviated the *), reload, and force-reload entries, and moved the 'rm'
> > line around, so size doesn't matter. What is important to see is that:
> >
> > *) There is a new check to see if portmap should be run, since portmap
> > is not it's own package. (explination below)
> > *) There are no "echo" statements for start/stop.
> > *) Errors are handled much more gracefully (except the portmap.state
> > stuff, which I left alone).
>
> please explain how your redhat script is necessary to get the
> RUNPORTMAP option?
Never said it was required. Said it did lots of checking, and
implemented the defaults.d type configuration.
And stop asserting that I'm just copying RH code. I've never looked at
any RH initscript code. I tried to figure out /etc/sysconfig/networking
(or something) once, gave up, and just wrote a script to fix it when it
was done. Sourcing one file is *simple*. Calling a function is
optional.
> > and this will persist even after the package is updated, if it is
> > removed and all the init scripts go away, and an upgrade will not result
> > in in a conflict for the SA to have to manually deal with.
>
> all the initscripts go away and destroy any modifictions i made to
> them, thats just wonderful. i might as well go back to redhat.
Ahh, so *you* came from a redhat system?
Either way - if the script uses defaults.d and everything you need to do
can be done from there, there's no need to modify the initscript.
> > If it makes the "/etc/init.d/foo is different, replace? (yntfdok)"
> > messages go away, plus lets me get rid of running portmap from netbase
>
> this is a FEATURE not a bug. again why don't you go back to redhat
never said it was a bug.
And let's get one thing straight: *you* came from redhat, not *me*.
Christopher
Reply to: