Service Resource broken on OSX as of 11.12


#1

Hi,

I upgraded to 11.12 due to the heartbleed vulnerability and omnibus’s
embedded openssl - unfortunately, 11.12 has some service changes on OSX
that break Chef (specifically, any time a service resource is re-opened,
the chef run blows up).

I realize that many people are at Chef-Conf, but this is a major regression
that has made Chef unusable on OSX. I’m hoping to get help/attention on
this?

I’d be happy to submit a PR that reverts the service resource change, but
I’m not sure if that’s the right choice here.

https://tickets.opscode.com/browse/CHEF-5223

Halp!

Brian


#2

On Wednesday, April 16, 2014 at 9:55 AM, Brian Hatfield wrote:

Hi,

I upgraded to 11.12 due to the heartbleed vulnerability and omnibus’s embedded openssl - unfortunately, 11.12 has some service changes on OSX that break Chef (specifically, any time a service resource is re-opened, the chef run blows up).

I realize that many people are at Chef-Conf, but this is a major regression that has made Chef unusable on OSX. I’m hoping to get help/attention on this?

I’d be happy to submit a PR that reverts the service resource change, but I’m not sure if that’s the right choice here.
I think it’d be preferable to move forward instead of reverting.

https://tickets.opscode.com/browse/CHEF-5223

In that ticket, you write:

https://github.com/opscode/chef/commit/024b1e3e4de523d3c1ebbb42883a2bef3f9f415c "assumes things about where services end up that may not always be true.”

Can you elaborate on this?

Halp!

Brian

Looks to me like it should be pretty easy to fix, but I’d like to learn more about your comments on the ticket so we can write proper regression tests.


Daniel DeLeo


#3

Hi Daniel,

Thanks for your response!

I can add this to the ticket if you’d like, but the resource attempts to
glob a resource here:

using a list of locations defined here:

It seems plausible that one might run a service with a plist located
elsewhere on the filesystem than what’s in this list (we’re not doing that
under Chef, but I’ve seen it done).

Brian

On Wed, Apr 16, 2014 at 2:04 PM, Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, April 16, 2014 at 9:55 AM, Brian Hatfield wrote:

Hi,

I upgraded to 11.12 due to the heartbleed vulnerability and omnibus’s
embedded openssl - unfortunately, 11.12 has some service changes on OSX
that break Chef (specifically, any time a service resource is re-opened,
the chef run blows up).

I realize that many people are at Chef-Conf, but this is a major
regression that has made Chef unusable on OSX. I’m hoping to get
help/attention on this?

I’d be happy to submit a PR that reverts the service resource change,
but I’m not sure if that’s the right choice here.
I think it’d be preferable to move forward instead of reverting.

https://tickets.opscode.com/browse/CHEF-5223

In that ticket, you write:

https://github.com/opscode/chef/commit/024b1e3e4de523d3c1ebbb42883a2bef3f9f415c"assumes things about where services end up that may not always be true.”

Can you elaborate on this?

Halp!

Brian

Looks to me like it should be pretty easy to fix, but I’d like to learn
more about your comments on the ticket so we can write proper regression
tests.


Daniel DeLeo


#4

On Wednesday, April 16, 2014 at 11:12 AM, Brian Hatfield wrote:

Hi Daniel,

Thanks for your response!

I can add this to the ticket if you’d like, but the resource attempts to glob a resource here:

https://github.com/opscode/chef/blob/master/lib/chef/provider/service/macosx.rb#L192-L195

using a list of locations defined here:

https://github.com/opscode/chef/blob/master/lib/chef/provider/service/macosx.rb#L28-L38

It seems plausible that one might run a service with a plist located elsewhere on the filesystem than what’s in this list (we’re not doing that under Chef, but I’ve seen it done).

Brian
Okay, thanks for explaining. It looks to me like we only need to find the service label from the plist to enable or disable a service, so we can probably make the provider tolerate a missing plist file for the other actions. I’d add a return statement here: https://github.com/opscode/chef/blob/master/lib/chef/provider/service/macosx.rb#L175 (e.g., return false if @plist.nil?) and change this https://github.com/opscode/chef/blob/master/lib/chef/provider/service/macosx.rb#L62 to only require a service label for :enable and :disable.

I think something like that should at least fix everything that was working previously, yes?


Daniel DeLeo


#5

I just traced that out, and it looks correct to me!

Thank you!

On Wed, Apr 16, 2014 at 2:23 PM, Daniel DeLeo dan@kallistec.com wrote:

On Wednesday, April 16, 2014 at 11:12 AM, Brian Hatfield wrote:

Hi Daniel,

Thanks for your response!

I can add this to the ticket if you’d like, but the resource attempts to
glob a resource here:

https://github.com/opscode/chef/blob/master/lib/chef/provider/service/macosx.rb#L192-L195

using a list of locations defined here:

https://github.com/opscode/chef/blob/master/lib/chef/provider/service/macosx.rb#L28-L38

It seems plausible that one might run a service with a plist located
elsewhere on the filesystem than what’s in this list (we’re not doing that
under Chef, but I’ve seen it done).

Brian
Okay, thanks for explaining. It looks to me like we only need to find the
service label from the plist to enable or disable a service, so we can
probably make the provider tolerate a missing plist file for the other
actions. I’d add a return statement here:
https://github.com/opscode/chef/blob/master/lib/chef/provider/service/macosx.rb#L175(e.g., return false if @plist.nil?) and change this
https://github.com/opscode/chef/blob/master/lib/chef/provider/service/macosx.rb#L62to only require a service label for :enable and :disable.

I think something like that should at least fix everything that was
working previously, yes?


Daniel DeLeo


#6

Can you test this? https://github.com/opscode/chef/pull/1380

Thanks in advance and let me know if you have trouble testing.


Daniel DeLeo


#7

I manually patched this into an OSX install that is known to see this
issue, and it now works great. (I also commented the like onto your PR)

On Wed, Apr 16, 2014 at 3:20 PM, Daniel DeLeo dan@kallistec.com wrote:

Can you test this? https://github.com/opscode/chef/pull/1380

Thanks in advance and let me know if you have trouble testing.


Daniel DeLeo