On Sat, Jul 08, 2000 at 12:40:01PM -0400, Christopher W. Curtis wrote: > > > > the majority of debian initscripts are elegant in their plain > > simplicity. its very obvious exactly what is occuring and its very > > clear how to make changes (say add a command line argument) > > 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. > The reason for this thread was because changing something in an init > script does not persist, and the whole mess (it's a mess imo) about > 'removing' something versus 'purging' it can basically go away. test -x /usr/sbin/sshd || exit 0 is a mess? or even the test -f with that oh so horrible `crash' where you get a `Permission denied' on your console is a mess? please. > All user changes go into /etc/init.d/defaults.d/PACKAGE.user (this is my > notation and can surely be changed) and this is the only file the user > should have to change, ever. When the package is removed, the scripts > can go away as well so there's not a bunch of scripts running at boot > time checking for -x (or -f) of their daemons in the case that it was > removed but not purged. (Yes, my code makes the same checks, but it > does so for error conditions, not 'what kind of messed up state does > debain require I be in'.) 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. > Adding a commandline argument, using the example I sent, means changing > the variable "OPTIONS" in /etc/init.d/defaults.d/foo.user. If this is > non-obvious, a comment can easily be added so that: > > . /etc/init.d/defaults foo > > becomes: > > # Defaults (settings) are in /etc/init.d/defaults.d/foo > # User overrides go into /etc/init.d/defaults.d/foo.user > . /etc/init.d/defaults foo uncessasry redhat obfuscation. why don't you just go back to redhat and leave us alone? > > 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. > 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. > 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. > I don't say that it is. I say that > > term sshd > > is clearer and more consistent than bullshit. > because (unlike kill -15 especially) it plainly states what it is going > to do, and it does basic error checking to make sure that the program is > running, that the kill is successful, is quiet about it (no "kill: no > such pid" cruft being spewed to stderr), and returns a consistent error > code so that other programs (such as the included 'status' function) can > print pretty and useful messages to the user, like "^[[1;4aProgram not > running^[[0a" (sorry, I forgot my ANSI codes). initscripts that are done properly don't spew messages to the console. a simple 2> /dev/null takes care of that. it sounds to me like you just don't understand what unix commands mean so you don't want to see them at all. when i see `term sshd' i have no idea what the fsck is going to happen, `term' is a non-standard command so i have to go sifting through a bunch of crap include files all over the fscking place trying to find what `term' REALLY does. if the commands are right there in the script i KNOW what is going to happen without looking through some obfuscated crap. > > or start-stop-daemon --stop --quiet --exec /usr/sbin/sshd > > Yes, there is duplication with start-stop-daemon. I am not intimate > with SSD and I read the manpage - it seemed complicated and I just > wanted something simple. However, if people like this, I would be quite in other words: "i just don't understand how it works so it sucks" > content to have 'start', et al, use it. It can do things that I am > unable to do in bash, and it already exists. However, I would still > wrap it in 'start()' &co so that error checking can be moved out of the > init script and into this 'library', and so that consistent error > messages can be implemented - trivially and consistently. what the fuck, this is getting more and more laughable every minute, 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? please tell me how hiding how the system works from the admin is helping him? 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." > So that new init scripts can be installed without destroying user > settings or intervention by the SA, and old ones can be safely removed > at 'remove' time, not 'purge' time. it sounds to me like your gripe is with dpkg's handling of conffiles and nothing else. i personlly like dpkg's handling of conffiles it gives me far more control over my system. 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. one size does not fucking fit all. > A (I hope) pertinent example: I don't like portmap in the required > package netbase. I don't like the existing "solution" for diasbling > it. Why? This is me. Who cares, I'm providing an alternative. Look > at /etc/init.d/portmap. I'm going to rewrite this script using my > 'defaults' library as example: rm /etc/rcS.d/S41portmap works quite well for me. update-rc.d refuses to add the link back since the kill links for runlevel 0 and 6 still exist. i think you just don't like the sysv initscript system, i agree it somewhat sucks in some ways but so does the BSD style scripts (which are much more difficult to upgrade) your ball of obfuscated spaghetti is not the answer to the small difficulties in the sysv initscript system. 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. [snip] > 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? [blah blah blah] > 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. i will say it again, no config.d system is going to fit *ALL* situations, sysadmins are diverse and have diverse needs, the ability to rewrite or edit the initscript directly is absolutly essential. > We disagree here as well. Adding any variables is going to add > complication. Having a default library simply takes some of that > complication out of the init script and puts it out of direct sigh, > which is, to me, less convoluted, and makes writing init scrtipt less > complicated. bullshit. the config.d scheme need not add complication, i don't envision all initscripts even needing it, and the ones that do would probably have not more then 2 or 3 variables. $START would be a good one for portmap and ssh and ppp (get away from this sillyness of files called no_start_ssh and such.) and a $ARGS which many scripts already have anyway (see sysklogd). all your system does is add complication and convolution and obfuscation. it makes writing scripts NO simpler, quite the contrary. > The only difference is that I'd encourage script writers to deal with > error conditions, which currently are by the large ignored. script writers can be encouraged to deal with errors without subjecting them to this crap. > > i am still not entirly convinced the config.d idea is a good one > > 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 these messages will never go away. when i install new versions of ssh i get a message: /etc/ssh/sshd_config is different blah blah blah. do you want to replace it with the maintainers version or keep yours? this is a FEATURE not a bug. again why don't you go back to redhat where your config files are thrown away silently without asking. > without doing a hack (yes, I feel it's a hack) to tell the portmap to > stop in all runlevels via a relatively obscure update-rc.d mechanism, I *yawn* > much prefer it. Especially since init scripts are generally simple > anyway - I don't think something like this would work for, say, the the debian scripts are simple now, if you get your way that would no longer be the case. > samba and squid configuration files. (Although, as an aside, if samba > and squid had a directive to read another file to override the settings > in the default file, or a setup like pine, it would certainly be useful > to have an /etc/config.d/package setup). i think not very many scripts would have much need for the config.d stuff, the more i think about it the more i think its not really worth it. > Maybe I'm willing to make writing things more complicated if it makes > administration easier, and you're not. We just have different what the fuck, how is making the scripts more complicated and less clear make things easier on me as an adminsitrator? you sound like Microsoft "keep the users in the dark and the admins not much brighter" > perspectives that way. But overall, it seems easier to me. yes my philosophy is keep it simple stupid. most of the current debian initscripts are quite simple, and obvious. your scripts are not. -- Ethan Benson http://www.alaska.net/~erbenson/
Attachment:
pgpRUG9zNd8xO.pgp
Description: PGP signature