Re: Disable a service
On Sun, Apr 10, 2011 at 7:27 PM, Joel Roth <joelz@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 <joelz@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.)
Reply to: