On Sun, Apr 10, 2011 at 7:27 PM, Joel Roth <jo...@pobox.com> wrote: > On Sun, Apr 10, 2011 at 05:33:10PM -0400, Tom H wrote: >> On Sun, Apr 10, 2011 at 1:36 PM, Joel Roth <jo...@pobox.com> wrote: >> > On Sun, Apr 10, 2011 at 05:51:12AM -0400, Tom H wrote: >> It's interesting/weird that there isn't a canonical way - other than >> breaking some rule(s) by using update-rc.d or insserv. :) >> >> >> I consider >> >> that bad on a single-user box but *very* bad on a >> >> multi-user/multi-sysadmin box. >> > >> > Why is that *very* bad (or even bad)? Please enlighten me! >> >> In a company, using non-standard procedures makes the job of an >> incoming sysadmin and of his/her new colleagues more difficult than it >> should be. > > Well, that's odd to say given what you write above (albeit later) > that there *is* no canonical way. > > Also, odd to say in that checking and setting permissions is > so common. I would expect a professional admin to think > to look at init script permissions if a service didn't start. > (If it's a company, sure, the admin should keep some kind of > logbook explaining his choices.)
This entire "no canonical way" and "update-rc.d is for maintainers" is something of a red herring IMHO. It reminds me of useradd and adduser; adduser is the preferred executable for adding a user because it's (from its man page) "friendlier front ends to the low level tools like useradd ... by default choosing Debian policy conformant UID and GID values, ...". Using useradd isn't going to break your system but you have to specify more inputs to get the same result. Eventually, update-rc.d'll get a similar, Debian-friendly and -approved front-end. In my day job, in a large company, there's no way anything like this would or could happen. A config change on a production box needs three-days' notice and later on is packaged and pushed out/pulled in to keep the builds and actual configs equivalent. For an emergency, same-day change, the head of the Unix department and the head of the department concerned have to sign off - and just about every keystroke's pre-planned. You also have extensive information about every aspect of a box - mind-numbingly so. In my moonlighting in smaller companies, I find differing levels of procedures and changelogs that can regularly lead to headaches. In the specific case of chmod'ing an init script: it's something that'll become obvious quite quickly without necessarily running "ls -l" but it's not something that you really want to worry about since there are more standard ways of disabling an init script. You also want your init script tools to give you the correct information. On a Red Hat box, if you run "chkconfig ---list iptables", you want the output to match the state of the script and not find out that iptables is listed as on in level 3 but it's been chmod -x'd so it's actually off. I've just install chkconfig and run "chkconfig --del nfs-kernel-server" in a sid VM; it turned it off in all runlevels. And "chkconfig -add nfs-kernel-server" re-enabled it in runlevels 2345. (Just in case you're wondering, the symlinks are deleted and created, so the info's correct.) -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/banlktikt4esu_tcekvneygrn6suty9s...@mail.gmail.com
