Re: A few observations about systemd
On Fri, Aug 05, 2011 at 11:52:22PM +0600, Andrey Rahmatullin wrote:
> On Fri, Aug 05, 2011 at 07:35:49PM +0200, Wouter Verhelst wrote:
> > If you do want it started, that means you need to install it first. Then
> > it makes very much sense it is started automatically.
> Logical fallacy: "run" implies "install", but "install" doesn't always
> mean "run".
While that is true, it is not really taking the discussion further
without some supporting argumentation. On its own, it just seems like
empty sophistry. I suspect you didn't mean it like that, however.
We have at least two competing viewpoints about starting servers at
install time:
1. Installing a package should start any network-visible server included
in it, so that the user needs to do as little extra work as
possible. Also, the server should be configured to work without
extra configuration, if that is possible, perhaps using debconf
questions (but preferably not asking anything by default). The default
configuration should also be secure. Balancing these contradicting
requirements can be hard, but it's pretty much what we've been doing
for the past couple of decades.
- we can call this "easy-but-secure by default"
2. Installing a package should NOT start any servers included in it.
Starting a server is a risky act that should require an explicit,
conscious decision by the sysadmin (which often means "user" in
these days). There should still be a secure default configuration.
- we can call this "secure-but-easy by default"
As a project, we've been favoring easy-but-secure, though not exclusively.
A number of people would prever secure-but-easy instead. Either
alternative is acceptable, as far as I can see, as long as the myriads
of details are taken care of properly.
Those who want secure-but-easy would like to be able to install
a package without running a network-visible server inside it. At
the moment it's not that easy to do in Debian.
The ideal compromise would be to allow a way for sysadmins to
choose between the two. We have a policy-rc.d specification, but
no default implementation for it. Do we have a way for a sysadmin
to specify a policy for what rc*.d links are to be created when
a package is installed (so they don't need to go fixing them up
by hand afterwards)?
Anyone wanting a change to status quo (easy-but-secure) should
probably make the tools to allow a sysadmin to switch to
secure-but-easy easily. A patch to update-rc.d to allow overriding
symlink creation by maintainer scripts, plus a configurable
policy-rc.d implementation might be enough.
Happy hacking. :)
--
Freedom-based blog/wiki/web hosting: http://www.branchable.com/
Reply to: