Re: Request for Comments: Standardize enabling/disabling of system services
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
Hmm, sysv-rc-conf is a new one to me. I don't care much for the aesthetics
of it (I think the author was too successful at capturing the IRIX/Red Hat
look'n'feel), but it does seem to do most of what's needed.
Both the name and the design are specific to sysv-rc, though.
rcconf looks more promising on those two points, but because it limits
itself to a whiptail interface it also falls short of being a full runlevel
editor, only allowing across-the-board enabling/disabling of services. It
also seems to have some implementation bugs (an 'rcconf --list' here is
missing some services).
> Imho the only sane option is, to get rid of those RUN_ variables as much as
> possible and advertise tools like sysv-rc-conf more (or even install them by
> default).
I think "like" is the key word; I don't think either sysv-rc-conf or rcconf
in present form are suitable to be "the" runlevel editor for Debian.
> There are indeed services though, which should *not* be started by default, as
> e.g. they need to be configured first. But instead of inventing such a RUN_
> variable, the init script could directly check if its prerequisites are given
> and only start in that case. It then can also output a more sane error message,
> telling the user what it is missing and how he can change that.
I agree wholeheartedly.
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).
> > 2.) It makes the init script useless.
> That is definitely not true. The init script still stays a common known
> interface to control a given service. The idea just adds another layer
> of control.
It conflates service starting by the admin with service starting via the
runlevel policy.
--
Steve Langasek Give me a lever long enough and a Free OS
Debian Developer to set it on, and I can move the world.
Ubuntu Developer http://www.debian.org/
slangasek@ubuntu.com vorlon@debian.org
Reply to: