RE: Re: RE: Re: LWRP inside LWRP Execution Question

Chef Infra (archive)
1

After more investigation, it looks like I am running into a problem with the multiple Chef run-time phases, compile and convergence. The fork idea has turned out to be bad because the resource run queue gets populated in the forked process and never makes it back to the parent.

I actually came across the same article earlier about the euid / egid wrt elevating privileges back to root (thus removing the need to fork). I have a prototype right now that works as long as all LWRP code executes during the compile phase using .run_action() (this is ugly and doesn't support notifications and isn't very Chef like).

I tried wrapping the execution as another user in a ruby_block, but it looks like Chef still pulls it apart and adds the resources to the run queue during compile, only to be executed as root during convergence.

Is there a construct that can hold multiple resources (I was hoping ruby_block worked this way) that lives in the resource run queue as an atomic unit so I can apply user-switch code before the other atomically-grouped-resources execute?

Thanks again for the help!
Wes

-----Original Message-----
From: Daniel DeLeo on behalf of Daniel DeLeo
Sent: Tue 11/19/2013 10:48 AM
To: chef@lists.opscode.com
Subject: [chef] Re: RE: Re: LWRP inside LWRP Execution Question

On Tuesday, November 19, 2013 at 5:29 AM, Wes Parish wrote:

Thanks for the quick reply Daniel. Unfortunately, I have tried the use_inline_resources without success. I don't believe I am having issues with notifications, but instead with LWRP resources not even executing. I have tested this code on both Chef 10.18.2 and Chef 11.4.4 with the same results. I have also tried creating a HWRP in the libraries directory of my cookbook with the same problems. Any other ideas?

I can't figure out anything else from your code. You could try running it with -ldebug.

Suggestions for wrapping existing code (both native resources and LWRPs) to execute as a different user would be helpful as well if there are any examples out there that take a different route (other than fork, change uid / gid and eval() a command string).
That's how you should do it. This article may be informative (even if the tone is a little aggro): http://timetobleed.com/5-things-you-dont-know-about-user-ids-that-will-destroy-you/

Thanks!
Wes

--
Daniel DeLeo

2

On Tuesday, November 19, 2013 at 10:20 AM, Wes Parish wrote:

After more investigation, it looks like I am running into a problem with the multiple Chef run-time phases, compile and convergence. The fork idea has turned out to be bad because the resource run queue gets populated in the forked process and never makes it back to the parent.

I actually came across the same article earlier about the euid / egid wrt elevating privileges back to root (thus removing the need to fork). I have a prototype right now that works as long as all LWRP code executes during the compile phase using .run_action() (this is ugly and doesn't support notifications and isn't very Chef like).

I tried wrapping the execution as another user in a ruby_block, but it looks like Chef still pulls it apart and adds the resources to the run queue during compile, only to be executed as root during convergence.

Is there a construct that can hold multiple resources (I was hoping ruby_block worked this way) that lives in the resource run queue as an atomic unit so I can apply user-switch code before the other atomically-grouped-resources execute?
LWRPs with use_inline_resources do this, here’s the relevant code: chef/lib/chef/provider/lwrp_base.rb at main · chef/chef · GitHub

You could maybe make your own LWRP that takes a block argument and use instance_eval inside the action block to provide a nested recipe. Resources inside that block won’t have visibility to the outside world, but the top-level LWRP could handle notifications correctly.

Thanks again for the help!
We

--
Daniel DeLeo