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
> 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.
the hell it shouldn't. not everything is going to end up in the
configuration file, not everything CAN end up in the configuration
file.
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
file my changes are going to be trashed on the next package upgrade.
that is fucking unacceptable.
perhaps you don't understand how dpkg handles conffiles, if you don't
touch the conffile then dpkg will silently upgrade it without asking
you. the question only comes up under these circumstances:
the conffile in the new package is different then the one held in the
previous version's package (not on disk, in the .deb) AND the file on
disk does NOT match the copy in the previous version's .deb.
for example sysvinit has initscripts checkroot.sh and checkfs.sh, i
have not ever modified these scripts, never had a need to. the last 2
sysvinit upgrades however contained new versions of these
initscripts. so dpkg quietly and without asking overwrote the
installed copies with the new versions. it will only ask if you
changed something, and even then if there is nothing new to install it
does not ask either, it just leaves the modified scripts in place.
> Give me a break. I have one redhat machine because, oh, debian didn't
> run on the alpha at the time?
so why don't you install redhat on your remianing machines instead of
trying to turn debian into redhat?
> How does SuSe handle this? Caldera? TurboLinux? We know that RedHat
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.
> 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?
i am arguing that debian initscripts are already consistent when they
can be. most are based on /etc/init.d/skeleton. those that are not
have good reason usually.
and i would not be spending time on this thread if i did not care
about maintenance, your proposal threatens the ability to maintain
debian systems efficiently by introducing this redhat disease into
debian.
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.
> > 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.
no, i simply said that your obfuscated redhat spaghetti is not
necessary to let someone quickly add command line arguments to an
initscript. sysklogd for example at the very beginning has this:
# 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
reimplement this redhat shit.
> 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
you are sugessting this festering boil of an initscript system be made
debian policy whereby all debian developers would be forced to use
it. and by extension all debian admins would be forced to suffer this
atrocity.
> can still edit the file manually.
not if you get your way, see above, you want the initscript to no
longer be a conffile according to dpkg, that means if i edit it (to
replace the obfuscated crap with a real script) it will be blown away
on the next upgrade.
> And which distribution would you be considering?
slackware, where admin control is the utmost priority. either that or
OpenBSD.
> Oh, it's so *obvious* now.
good.
> 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.
> > 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.
i meant that i would have no idea *HOW* its planning on killing sshd.
i would likely figure it was going to kill it somehow, but i want to
know *HOW* its going to do it. i don't want to go dicking around in a
bunch of include files that source yet other include files trying to
find that out. and that is exactly what your bastardized system will
force me to do.
> > 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
gee i wonder why start-stop-daemon was written anyway, i think the
only purpose for its being is to be used inside initscripts.
> 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.]
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.
besides that status info is the most diverse anyway, you cannot
possibly expect to make a generic function to get status about a wide
variety of daemons that is actually useful. (whether `cat
/var/run/sshd.pid` is actually running or not is not that useful, i
can do that myself much faster then dicking with the initscript)
> 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
bullshit, the notion of defaults.d is to have a file with nothing but
variables like say:
SYSLOGD=""
now look a little further in the sysklogd initscript and you find
this:
start-stop-daemon --start --quiet --exec /sbin/syslogd -- $SYSLOGD
hmm gee look at that.
> that regard. Since you dispute the usefulness of defaults.d, you will
> find no validity to my argument.
defaults.d *may* be useful, i am not yet certain its worth the
trouble, and my notion of defaults.d is very very simple:
initscript foo sources /etc/default/foo.conf
foo.conf contains:
FOOARGS=""
*no fscking functions*
however you are right i find no validity in your argument because your
argument is flawed -- start-stop-daemon has no difficulty with
defaults.d.
> Nothing is hidden from the admin. Comments are generous.
bullshit, all the details of how an initscript is implemented are
squirreled away in some bloody include file somewhere. by strict
standards nothing is hidden in redhat's system either, but its still a
royal pain in the ass to figure out how the hell things work. (and
more to the point why the hell something does *not* work)
> 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".
and we need an obfuscated redhat esque system to do this why?
> > 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.
will you please clean all the bullshit out of your ears so you can
hear what i am saying:
ONE SIZE DOES NOT FIT ALL
SYSADMIN NEEDS ARE DIVERSE
THERE ARE TIMES WHEN A SYSADMIN WILL NEED OR DESIRE TO REWRITE THE
INITSCRIPT ENTIRELY, OR CONFIGURE IT IN SUCH A WAY THAT THE CONFIG
FILE DOES NOT ALLOW.
(apologies to everyone else for the yelling)
> > one size does not fucking fit all.
>
> As repeated here and in numerous Pepsi commercials, "duh".
and yet you don't seem to get it.
> I feel like I'm writing to a wall. Don't want to use the functions?
funny i was going to say the same thing.
> Don't. Want to include the file directly? Fine. To the end user, it
> all works the same way.
you are suggesting debian policy to use a obfuscated redhat esque
initscript system, debian policy would compell debian developers to
use it, and by extension the admins will be stuck with it as
well. (since you don't want the initscript to be config files anymore
they cannot simply throw away the garbage script and write thier own)
> 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.
funny since your code is an awful lot like redhat's.
and your suggesting sourcing one file, and that file then sources
other files...
for a defaults.d system the initscript need only source one file: the
config file.
the config file would contain *ONLY* shell variables.
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-----
simple eh? here is the contents of /etc/default/sysklog.conf:
# Options for start/restart the daemons
# For remote UDP logging use SYSLOGD="-r"
#
SYSLOGD=""
# Use KLOGD="-k /boot/System.map-$(uname -r)" to specify System.map
#
KLOGD=""
elegant simplicity. did not even have to change any of the real code
in the initscript.
> Ahh, so *you* came from a redhat system?
yes that is how i recognize the flaws of your system so well, and why
i am so vehemently opposed to it. i have been down that road, i know
exactly where it leads and i don't want to be there.
> 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.
correct, but debian developers are far from all seeing deities they
will not make available every config option that a sysadmin may need,
and when they don't the sysadmin will want and need to edit the
initscript directly. that *must* be allowed.
as i have said leaving the initscripts marked as conffiles hurts no
one, if you don't edit it your not asked if you want to upgrade it.
but NOT making it a conffile DOES hurt those who do wish to
edit/replace the script.
> never said it was a bug.
no you just said it should go away.
> And let's get one thing straight: *you* came from redhat, not *me*.
ok so your saying that your lack of experience in redhat is why you
fail to see that your proprosed initscript system is flawed?
--
Ethan Benson
http://www.alaska.net/~erbenson/
Attachment:
pgpIw3HjWHczY.pgp
Description: PGP signature