Re: administration of initscripts
Hello Bob,
Excerpt from Bob Proulx:
> Thilo Six wrote:
>> Subject: administration of initscripts
>> ...in debian has been no pleasure for some time now.
>
> Sorry to hear that. Why not?
I was looking for the "offical" way of dealing with initscript for some time
now. If you look online mostly update-rc.d is recommended in such discussions.
but e.g. compare:
update-rc.d cups stop 80 0 1 .
with:
rc-update cups del
Really the former is a API written to be used by computers and it does a good
job there, but it isn't all that good when being used by humans.
>> Well the reason i write this, is i found a solution that works for me which i
>> would like to share with you.
>
> Thank you for sharing.
You are welcome!
-- <snip> --
>> It is notably that it has even been said on debian-devel, that update-rc.d
>> is a API for developers only and not even been considered to be used by
>> administrators (search for it).
>
> It is designed to be used by packages during postinst and postrm. A
> mechanism for automated install and uninstall. Not really something
> you type in at the command line. But nothing stops you from typing it
> in at the command line. It just isn't designed for it. It is
> designed for the package automation.
I agree with you here.
-- <snip> --
> I have been using Debian for many years now. In all of that time I
> have never wanted to "manage" init scripts. I always wonder. What
> are people trying to do?
Basically with a default debian install there also come some functionality that
i simply do not need. Those i purge rather soon.
Other additional functionality like printing i *might* use someday. So i won't
purge cups for that reason but not starting cups (and some other services)
reduce startup times noticeable.
As others already rightly stated that it is a virtue to turn off not used
listening ports.
Basically administration of initscripts and the decision of which services are
run is the main domain of the local admin.
The question should not be: Why would you do that? but How do you do that?
> What is more complicated than this. If you want it then install it.
> If you don't want it then remove or purge it. With those two commands
> all management is handled automatically.
I named use cases for this. Also i conducted that remove/purge isn't always an
option.
> And therefore I must ask. What more management do you need? Anything
> else is truly unusual.
What i was really looking for is a easy to use API for an human admin to
include/exclude specific services at boot time.
Nothing more nothing less.
If look through several discussions where users ask howto "enable / disable
services in debian" you come rather soon to the conclusion that there does not
seem to be an official way of doing things.
If this thread does nothing else then making it more prominent that the official
way in debian is to 'update-rc.d foo disable|enable' then this would be a good
outcome IMO.
> This doesn't mean there isn't a valid case for different run levels.
> There are. I have just never needed them myself. So I am seriously
> interested in the question.
I until now i do not have a real need for different runlevels either. But i do
have a strong need to manage the one runlevel i actually use the way i say and
that in actually an easy way.
-- <snip> --
> I very much like the fact that you are working with the system and
> with insserv. That is awesome! Everything should work nicely with
> the system that way.
Thank you.
--
Regards,
Thilo
4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F
Reply to: