Chris Knadle | 5 Aug 21:47 2011

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".

  -- Chris

Chris Knadle
Chris.Knadle <at>