Re: A few observations about systemd
On Friday, August 05, 2011 02:36:13 PM, Lars Wirzenius wrote:
> On Sat, Aug 06, 2011 at 12:27:43AM +0600, Andrey Rahmatullin wrote:
> > On Fri, Aug 05, 2011 at 07:12:58PM +0100, Lars Wirzenius 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.
> > I can install a package to play with it, read the included docs, etc. I
> > can install a package locally because I need to install it on a remote
> > server and want easy access to its content before/while deploying. I want
> > control over my system so I want to review the configuration before
> > something is started without my permission.
> These are all good reasons to prefer secure-but-easy over easy-but-secure.
> We've heard them before, in fact. Unfortunately, either option will
> be unsatisfactory to many people, so the compromise I suggested at
> the end of my previous mail seems like the best path forward.
There are several daemons in Debian that have symlinks to start, but then read
a configuration file in /etc/default/<daemon> for whether to actually start
the daemon or not. An example is the 'wicd' package. As both wicd and
network-manager might be on the same system and would conflict, wicd checks
the /etc/default/wicd config file for whether it should start, in order to
avoid a conflict. network-manager does not.
One advantage for having a symlink to start and then checking a conifg file as
to whether to actually start is it allows an opportunity for the startup
script to give a useful message that the daemon wasn't started, and where to
look to change that.
I don't know how well this idea scales, and of course it would require a lot
of repackaging work, but it seemed to be worth mentioning, as it seems some
packages are already configured as "secure-but-easy by default".