On Lu, 30 iul 12, 11:12:43, Vincent Lefevre wrote:
> On 2012-07-29 21:43:57 +0200, Wouter Verhelst wrote:
> > An ENABLE switch does more than just disabling the run-at-boot state of
> > an initscript. While I can buy the argument that some packages should
> > not start *at boot* by default,
>
> The problem is not just at boot, but also when pacakges are installed
> (first install or upgrade).
>
> > I do believe that whenever an initscript is called with the argument
> > "start", it should bloody well start, and not exit after doing
> > nothing because I haven't edited some scarcely related file
> > somewhere.
>
> As long as scripts are allowed to execute init scripts directly with
> "start" or "restart" (see rsync postinst script, for instance), this
> must not be the case. Otherwise there would be no means to disable a
> daemon (uninstalling the package would not be a satisfactory solution
> because the client may still be useful, such as with rsync).

I'd say there is a need for:

1. a system-wide setting to start daemons or not on boot/upgrades/etc.
2. a blacklist - daemons listed here should not start no matter what
3. a whitelist - daemons listed here should start no matter what

This should satisfy all camps

Kind regards,
Andrei
--
Offtopic discussions among Debian users and developers:
http://lists.alioth.debian.org/mailman/listinfo/d-community-offtopic

On Mon, Jul 30, 2012 at 11:12:43AM +0200, Vincent Lefevre wrote:
> > I do believe that whenever an initscript is called with the argument
> > "start", it should bloody well start, and not exit after doing
> > nothing because I haven't edited some scarcely related file
> > somewhere.
>
> As long as scripts are allowed to execute init scripts directly with
> "start" or "restart" (see rsync postinst script, for instance), this
> must not be the case. Otherwise there would be no means to disable a
> daemon (uninstalling the package would not be a satisfactory solution
> because the client may still be useful, such as with rsync).

Package maintainer scripts are _not_ allowed to execut init.d scripts
directly. They have to do it via invoke-rc.d, which obeys runlevel
configurations and local policy made by the sysadmin (using the
/usr/sbin/policy-rc.d interface, which is not the world's greatest one,
but at least it's there).

I'm writing this on a machine running squeeze, so this may be a bit
different in later versions, but here's the snippet:

if [ -x /etc/init.d/rsync ]; then
if dpkg --compare-versions "$oldversion" lt "3.0.7-2"; then
update-rc.d -f rsync remove
fi

update-rc.d rsync start 50 2 3 4 5 . >/dev/null
if [ -x /usr/sbin/invoke-rc.d ]; then
invoke-rc.d rsync restart
else
/etc/init.d/rsync restart
fi
fi

This invokes the service ("runs the init.d script") with invoke-rc.d, if
available. The rsync postscript should not need to check for invoke-rc.d
anymore, it's been available in a required package for a long time now,
but it shouldn't matter, either.

--
I wrote a book: http://gtdfh.branchable.com/

On 12-07-30 at 12:37pm, Andrei POPESCU wrote:
> On Lu, 30 iul 12, 11:12:43, Vincent Lefevre wrote:
> > On 2012-07-29 21:43:57 +0200, Wouter Verhelst wrote:
> > > An ENABLE switch does more than just disabling the run-at-boot
> > > state of an initscript. While I can buy the argument that some
> > > packages should not start *at boot* by default,
> >
> > The problem is not just at boot, but also when pacakges are
> > installed (first install or upgrade).
> >
> > > I do believe that whenever an initscript is called with the
> > > argument "start", it should bloody well start, and not exit after
> > > doing nothing because I haven't edited some scarcely related file
> > > somewhere.
> >
> > As long as scripts are allowed to execute init scripts directly with
> > "start" or "restart" (see rsync postinst script, for instance), this
> > must not be the case. Otherwise there would be no means to disable a
> > daemon (uninstalling the package would not be a satisfactory
> > solution because the client may still be useful, such as with
> > rsync).
>
> I'd say there is a need for:
>
> 1. a system-wide setting to start daemons or not on boot/upgrades/etc.
> 2. a blacklist - daemons listed here should not start no matter what
> 3. a whitelist - daemons listed here should start no matter what
>
> This should satisfy all camps

That should be simple to setup, as the infrastructure exist already:
policy.d.

What I do locally to suppress starting daemons inside chroots is use
policyrcd-script-zg2 and then add a [custom script]. That script should
be easily changed/extended e.g. using "run-parts --list", and either
published at our wiki or released in a package conflicting with
policyrcd-script-zg2.


- Jonas

[custom script]: http://source.jones.dk/?p=sbin.git;a=blob;f=policy-rc.d

--
* Jonas Smedegaard - idealist & Internet-arkitekt
* Tlf.: +45 40843136 Website: http://dr.jones.dk/

[x] quote me freely [ ] ask before reusing [ ] keep private

On 2012-07-30 10:50:17 +0100, Lars Wirzenius wrote:
> I'm writing this on a machine running squeeze, so this may be a bit
> different in later versions, but here's the snippet:
>
> if [ -x /etc/init.d/rsync ]; then
> if dpkg --compare-versions "$oldversion" lt "3.0.7-2"; then
> update-rc.d -f rsync remove
> fi
>
> update-rc.d rsync start 50 2 3 4 5 . >/dev/null
> if [ -x /usr/sbin/invoke-rc.d ]; then
> invoke-rc.d rsync restart
> else
> /etc/init.d/rsync restart
> fi
> fi
>
> This invokes the service ("runs the init.d script") with invoke-rc.d, if
> available. The rsync postscript should not need to check for invoke-rc.d
> anymore, it's been available in a required package for a long time now,
> but it shouldn't matter, either.

It is currently required, but perhaps not in the future, with other
init systems. I suppose that there will be some document saying that
whatever init system is chosen, update-rc.d and invoke-rc.d must be
available.

IMHO, this is not "should not need to check" but "must not check",
because /usr/sbin/invoke-rc.d may not be there if the system is
broken, and in such a case, trying to start the daemon while the
user may have requested to disable it is bad for the security of
the system.

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120730101033.GH6859@xvii.vinc17.org">http://lists.debian.org/20120730101033.GH6859@xvii.vinc17.org

On 2012-07-30 12:01:08 +0200, Jonas Smedegaard wrote:
> On 12-07-30 at 12:37pm, Andrei POPESCU wrote:
> > I'd say there is a need for:
> >
> > 1. a system-wide setting to start daemons or not on boot/upgrades/etc.
> > 2. a blacklist - daemons listed here should not start no matter what
> > 3. a whitelist - daemons listed here should start no matter what
> >
> > This should satisfy all camps
>
> That should be simple to setup, as the infrastructure exist already:
> policy.d.
>
> What I do locally to suppress starting daemons inside chroots is use
> policyrcd-script-zg2 and then add a [custom script]. That script should
> be easily changed/extended e.g. using "run-parts --list", and either
> published at our wiki or released in a package conflicting with
> policyrcd-script-zg2.

There's a lack of documentation, with examples, e.g. on how to
blacklist a daemon.

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)


--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20120730101609.GI6859@xvii.vinc17.org">http://lists.debian.org/20120730101609.GI6859@xvii.vinc17.org

On Mon, Jul 30, 2012 at 12:10:33PM +0200, Vincent Lefevre wrote:
> > This invokes the service ("runs the init.d script") with invoke-rc.d, if
> > available. The rsync postscript should not need to check for invoke-rc.d
> > anymore, it's been available in a required package for a long time now,
> > but it shouldn't matter, either.

> It is currently required, but perhaps not in the future, with other
> init systems. I suppose that there will be some document saying that
> whatever init system is chosen, update-rc.d and invoke-rc.d must be
> available.

It will remain required. The document that covers this is Debian Policy.
Bug #591791 includes the patch to spell out the requirements in the upstart
case in particular.

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