[chef-dev] Re: CHEF-2880 debian policy and service provider

[Laurent Désarmes < >]

Bryan McLellan 
<
 >
 writes:

Bonjour, 

> A chef user recently ran into a problem with the service resource
> where a service was disabled on their system by debian policy
> unbeknownst to them. The underlying script that the resource asked to
> start the service returned successfully, however it did not actually
> start the service because of the system policy.
>
> There are varying opinions as to what should be done here.
>
> 1) Nothing. Chef shouldn't fix your system for you.
> 2) Warn. Chef should tell you if it thinks you are doing it wrong.
> 3) Fail. Chef should throw an exception if you asked it to do
> something it couldn't (by checking policy first).
>
> CHEF-2880 [1] proposes:
>
> 1) Always due #2 from above.
> 2) Add an option to the resource to run "invoke-rc.d --disclose-deny"
> which will cause #3 above to happen.
>
> We're not crazy about adding resource method solely for this. The
> simplest solution is to just run "invoke-rc.d --disclose-deny" all the
> time. The big question here, is there a use case where you would have
> the service disabled by policy but still want Chef to keep running if
> you ask it to start it? Laurent? Thom? Tollef? (CHEF-597 [2])

I use chef to bootstrap debian systems from scratch.
I use cdebootstrap, I install a basic chef setup, then I run chef from
the chrooted system to continue with its setup (fstab, network,
iscsi, multipath, swap, etc...)

As cdeboostrap does, i'm using policy-rc.d to prevent invoke-rc.d to
start any service from the chroot.
In that case i don't expect my cookbooks to fail.

Then when the debian os is run for real, i expect the same cookbooks
to start services.

So I'm definitly in favor of what CHEF-2880 proposes:
1) warn by default, in that case chef doesn't change the default
   behavior of invoke-rc.d. This is the only added value I would
   expect from chef
2) add the option to make it fail when the script action has been
   denied

-- 
Laurent