[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Request for Comments: Standardize enabling/disabling of system services

Hi Steve,

On Wed, Apr 01, 2009 at 06:51:29PM -0700, Steve Langasek wrote:
> On Wed, Apr 01, 2009 at 08:56:43PM +0200, Patrick Schoenfeld wrote:
> > On Wed, Apr 01, 2009 at 06:12:29PM +0200, Michael Biebl wrote:
> > > I don't like this idea of RUN=yes variables in /etc/default.
> > > 1.) There is already a documented interface, how to disable a service (i.e.
> > > renaming the S?? symlinks for that runlevel to K??). Adding another layer to do
> > > this is just confusing and inconsistent.
> > > There are tools like sysv-rc-conf which can handle that for you. Enabling a
> > > service is then as easy as sysv-rc-conf $service on|off
> > yes, that is true. This concept is however limited in so far that you
> > cannot decide before installing a certain service, weither it starts
> > after installation. Which is important if you want to avoid running
> > wrong/half configured services in your network. Basically the approach
> > is just to give some more possible choices to the users.
> All packages should ship with reasonable (--> secure) defaults.  Giving
> users more choices is not an appropriate substitute; and if we have secure
> defaults, giving users more choices should be lower priority.

> That said, if the runlevel editor is appropriately integrated with the
> system, it doesn't have to limit itself to waiting for the service to be
> installed before setting a policy for the service.  The editor could divert
> update-rc.d (or otherwise integrate with it), to ensure both that the
> runlevel editor always knows the intended policy for the service and that
> any global policy set by the admin is respected at the time update-rc.d is
> called (i.e., modifying the arguments before passing them to the diverted
> update-rc.d).

Indeed. Didn't think about the possibility of diversions. I guess
diverting the init scripts could be a solution (besides that it needs
some further work to the service managing utility). Then I'd
whole-heartedly agree with getting rid of RUN_* variables for the sake
of consistence.


Attachment: signature.asc
Description: Digital signature

Reply to: