[chef] RE: Re: RE: Re: LWRP inside LWRP Execution Question

["Wes Parish" < >]

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: 

 
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

<<winmail.dat>>