[chef] Re: Re: Re: Re: Re: Re: Re: Re: Getting "Access denied" when use mount in recipe and run chef-client remotely via winrm

[Tensibai Zhaoying < >]

You may create the task with no schedule and add a registry entry in a 
run_once to trigger the task. 

See 
http://stackoverflow.com/questions/290559/how-do-i-stop-start-a-scheduled-task-on-a-remote-computer-programatically
 for exemple,  locally you can omit the machine Switch or use a dot to target 
the local machine.

Le 3 juil. 2015 04:38, o haya 
<
 >
 a écrit :
>
> Hi, 
>
> BTW, this is the schtasks that I had in my recipe that finally worked (I 
> hard-coded the date/time in this test): 
>
> schtasks /create /tn Task_Name /tr "chef-client -o 
> install-SHAREPOINT2007FULL-PART2" /sc once /RU "env2\\Administrator" /RP 
> "xxxxxxx" /RL HIGHEST /SD 07/02/2015 /ST 21:20 
>
> Jim 
>
>
>
> -------------------------------------------- 
> On Thu, 7/2/15, o haya 
> <
 >
>  wrote: 
>
> Subject: Re: [chef] Re: Re: Re: Re: Re: Re: Getting "Access denied" when 
> use mount in recipe and run chef-client remotely via winrm 
> To: 
> 
 
>  
> Cc: 
> 
 
>  
> Date: Thursday, July 2, 2015, 10:27 PM 
>
> I went back and checked and luckily I 
> still had the test recipes I had been using to test using 
> schtasks to get through the reboot, so I tested again, 
> and... it worked!! 
>
> I'll do more testing with that, and also start looking at 
> using schtasks to do the remote running of chef-client. 
>
> But, does anyone happen to have the powershell code to 
> calculate 'x' time in the future, for the schtasks for 
> running chef-client after a reboot? 
>
> Thanks, 
> Jim 
>
>
>
>
> -------------------------------------------- 
> On Thu, 7/2/15, o haya 
> <
 >
>  
> wrote: 
>
>   Subject: Re: [chef] Re: Re: Re: Re: Re: Re: Getting "Access 
> denied" when use mount in recipe and run chef-client 
> remotely via winrm 
>   To: 
> 
 
>  
>   Cc: 
> 
 
>  
>   Date: Thursday, July 2, 2015, 7:22 PM 
>   
>   Hi, 
>   
>   I might go back and try that (schtasks) again later.  
>   I'd be happy if that worked, but if you recall from the 
>   Stackoverflow thread that you posted on 
> (http://stackoverflow.com/questions/31058849/is-there-a-way-for-a-chef-recipe-to-continue-after-a-reboot-windows),
>  
>   I did try that, but had problems with getting it to work, 
>   and actually I never got it working, so ended up 
> abandoning 
>   using that for the Sharepoint installation because it 
> turned 
>   out I didn't need a mid-installation reboot.  The 
>   Exchange installation, on the other hand, does require a 
>   mid-installation reboot, and because I wasn't able to make 
>   the schtasks approach work earlier, I went with the Chef 
>   service approach instead.  It would be good if I could 
>   get the schtasks approach working :(... 
>   
>   Later, 
>   Jim 
>   
>   
>   -------------------------------------------- 
>   On Thu, 7/2/15, Tensibai Zhaoying 
> <
 >
>  
>   wrote: 
>   
>   Subject: [chef] Re: Re: Re: Re: Re: Re: Getting 
> "Access 
>   denied" when use mount in recipe and run chef-client 
>   remotely via winrm 
>   To: 
> 
 
>  
>   Date: Thursday, July 2, 2015, 5:35 PM 
>   
>   Firing a scheduled task 
>   remotely is easy and get you rid of the whole 
> credential 
>   replay needed from winrm. 
>   
>   This method works since winnt4 (at least) and 
>   has been used for decades to trigger db stop and 
> then 
>   server 
>   Shutdown when there's a power outage and batteries 
>   lifetime is running low (usually this was part of 
> the 
>   weekly 
>   reboot task under nt4 :p) 
>   
>   This gives you the enforcement part on a 
>   regular basis + the ability to trigger a run on an 
> event 
>   with a lot of way to trigger it (winrm may not be 
> allowed 
>   to 
>   so this that's said, I'm unsure about the latest 
>   limitations ) 
>   
>   In brief, 
>   this could be a way to solve your problem on both 
> sides 
>   (credentials of the process and on demand ability) 
>   
>   Le 2 juil. 2015 22:31, o haya 
> <
 >
>  
>   a 
>   écrit : 
>   > 
>   > Steven 
>   and Tensibai (et al), 
>   > 
>   > Thanks for the interesting comments and 
>   discussion. 
>   > 
>   > With 
>   that, I think that my perspective is probably a 
> little 
>   (maybe a lot) different, which probably explains the 
>   differences in opinion.  
>   > 
>   > In our case, we are not looking to 
>   maintaining an environment or environments over time, 
> but 
>   rather, our desire is to be able to deploy specified 
>   environments kind of "on demand", mostly one-time 
>   events.  That is why the winrm-type approach 
> is/would be 
>   most attractive (and as I said, "natural") to us. 
>   
>   > 
>   > Thanks again, 
>   > Jim 
>   > 
>   > 
>   > 
>   -------------------------------------------- 
>   > On Thu, 7/2/15, Steven Murawski 
> <
 >
>  
>   wrote: 
>   > 
>   > Subject: 
>   [chef] Re: Re: Re: Re: Getting "Access denied" 
>   when use mount in recipe and run chef-client remotely 
> via 
>   winrm 
>   > To: 
> 
 
>  
>   
>   > Date: Thursday, July 2, 2015, 4:08 PM 
>   
>   > 
>   > So, I wasn't 
>   referring to 
>   > running part of the 
>   recipe as a scheduled task, but to 
>   > 
>   making the full chef-client run the scheduled 
>   > task. 
>   > 
>   > > Understanding that this is 
>   generically a Windows 
>   > problem, it 
>   still seems like both the scheduled task (if it 
>   > worked for me) and the service approaches 
>   are kind of 
>   > "un-natural" 
>   (read: kludgy) ways to do this, but 
>   > 
>   that's just my opinion.  
>   > >The 
>   
>   > general use case for Chef Client is to 
>   run in the background 
>   > on a schedule, 
>   validating the known good state of the system 
>   > and picking up changes when necessary. 
>    This is usually 
>   > accomplished as a 
>   service (or daemon) or via a scheduled 
>   > 
>   task (or cron job).  On Windows, I find the task 
>   scheduler 
>   
>   > the better option, as you have more 
>   flexibility in 
>   > determining the 
>   conditions you can run the task in, it 
>   > 
>   easily supports alternate credentials, can be run on 
>   demand 
>   
>   > as well, and isn't treated as a 
>   service 
>   > logon. 
>   > 
>   There is an use 
>   > case for invoking 
>   chef-client over winrm (or ssh) via some 
>   > orchestration engine rather than running 
>   on a schedule, but 
>   > that means 
>   you'll have to deal with the limitations of 
>   > WinRM.  There are just too many 
>   "gotchas" in 
>   > running in the 
>   WinRM context.  Many Win32 APIs can't be 
>   > called from a non-interactive logon (which 
>   WinRM is treated 
>   > as) and you have the 
>   credential delegation 
>   > problem. 
>   > As for 
>   > setting up 
>   Chef to run as a service or scheduled task, the 
>   > chef-client cookbook ( 
>   > https://supermarket.chef.io/cookbooks/chef-client ;
>   ) can help 
>   > with that (though I 
>   don't think it wires up "on 
>   > 
>   reboot"). 
>   > Steven 
>   MurawskiCommunity Software Development Engineer @ 
>   > ChefMicrosoft MVP - PowerShell 
>   > http://stevenmurawski.com ;
>   > 
>   
>                                         
>   On 7/2/2015 2:44:09 
>   > PM, Tensibai 
>   Zhaoying 
> <
 >
>  
>   
>   > wrote:In my opinion, running chef (or 
>   any Configuration 
>   > management system) 
>   on demand remotely is an anti-pattern. 
>   > 
>   > 
>   > 
>   If you're describing a 
>   > state, the 
>   targeted machine should launch the check by 
>   > itself periodically and try to fix itself 
>   as much as it 
>   > can. 
>   > 
>   > It's harder to 
>   
>   > compromise a network from a machine 
>   who will overwrite your 
>   > exploits 
>   changes every 30 minutes and enforce you to restart 
>   > your compromission from scratch over and 
>   over again. 
>   > 
>   > 
>   That's just my opinion too 
>   > :) 
>   > 
>   > Le 2 juil. 2015 
>   21:29, 
>   > o haya  a écrit : 
>   > > 
>   > > BTW, I 
>   should mention that I have a ticket 
>   > on 
>   a slightly "larger" question and this came up 
>   > right in the middle of that ticket, so 
>   I've conveyed 
>   > info on what I di to 
>   the support person (Vikas).  I also 
>   > 
>   was wondering out loud if maybe you guys might make 
>   > something like a credential proxy or maybe 
>   add that 
>   > capability to the existing 
>   Chef Windows service.  
>   > > 
>   > > Understanding that 
>   > this is generically a Windows problem, it 
>   still seems like 
>   > both the scheduled 
>   task (if it worked for me) and the 
>   > 
>   service approaches are kind of "un-natural" (read: 
>   
>   > kludgy) ways to do this, but 
>   that's just my opinion. 
>   > > 
>   > > 
>   > > 
>   > > 
>   > > 
>   > > 
>   > 
>   -------------------------------------------- 
>   > > On Thu, 7/2/15, o haya  wrote: 
>   > > 
>   > > Subject: 
>   Re: [chef] Re: Getting 
>   > "Access 
>   denied" when use mount in recipe and run 
>   > chef-client remotely via winrm 
>   > > To: 
>   > 
> 
 
>  
>   
>   > > Cc: 
>   > 
> 
 
>  
>   > > Date: Thursday, July 
>   > 2, 2015, 3:24 PM 
>   > 
>   > 
>   > > 
>   > Hi, 
>   
>   > > 
>   > > Thanks 
>   for 
>   > the info.  I was just about to 
>   post 
>   > > 
>   > that 
>   I've had some success today, but doing something 
>   > 
>   > > different... 
>   leveraging the Chef 
>   > Windows service.  
>   What I 
>   > > did was set 
>   > the user's credentials in place of 
>   whatever 
>   > > was in that service (in 
>   my case the 
>   > Windows domain 
>   > > Administrator) and then 
>   > let the service fire off my 
>   > > 
>   > 
>   recipe/cookbook.  I have to so some tweaking of the 
>   design 
>   
>   > 
>   > > of my 
>   recipes to prevent them from 
>   > 
>   re-running more than 
>   > > once, but I 
>   was 
>   > surprised that it works after 
>   that. 
>   > > 
>   > > 
>   I had seen mention of using 
>   > > task 
>   scheduler/schtasks before, and I 
>   > 
>   would've tried 
>   > > that for this 
>   
>   > situation, but when I was looking into 
>   how to 
>   > > do processing across 
>   reboots, but even 
>   > though I was able to 
>   
>   > > get the task 
>   > scheduling part done, the recipes appeared 
>   to 
>   > > run into the same type of 
>   access denied 
>   > problems.  I fought 
>   > > with that for a 
>   > 
>   couple of days, and finally gave up on it.  
>   > > 
>   > > 
>   > > 
>   > In particular, 
>   I was doing 
>   > > a recipe 
>   > for deploying Exchange, and it required 
>   installing 
>   > > some prerequisites and 
>   then a reboot and 
>   > then the actual 
>   > > installation.  So 
>   > back then, I would have the first part of 
>   
>   > > the recipe create a scheduled 
>   task via 
>   > schtasks, for the 2nd 
>   > > part, but when 
>   > 
>   the 2nd part, which was what actually ran the 
>   > > setup.exe and psconfig.exe, ran, it 
>   kept 
>   > throwing errors 
>   > > indicating that 
>   > 
>   something wasn't accessible. 
>   > > 
>   
>   > > So, at this point, the service 
>   
>   > > approach is the only approach 
>   that works 
>   > for me. 
>   > > 
>   > > Thanks 
>   > again, 
>   > > Jim 
>   > > 
>   > > P.S.  I 
>   
>   > > kind of 
>   > 
>   guessed that there wasn't something, but I 
>   > > posted because the threads, etc I 
>   found on 
>   > the credssp and 
>   > > chef were a couple of 
>   > years old, and was hoping that 
>   > > 
>   > there'd be 
>   something better by now :(... 
>   > > 
>   > > 
>   > > 
>   > > 
>   > 
>   -------------------------------------------- 
>   > > On Thu, 7/2/15, Steven Murawski  
>   > > wrote: 
>   > > 
>   > >   Subject: [chef] Re: 
>   > > Getting "Access denied" 
>   when use 
>   > mount in recipe 
>   > > and run chef-client 
>   > remotely via winrm 
>   > 
>   >   To: 
>   > > 
> 
 
>  
>   
>   > >   Cc: "o haya"  
>   > >   Date: Thursday, July 2, 2015, 3:02 
>   PM 
>   > 
>   > >   
>   > >   
>   > >     
>       
>   > >       
>   >                         
>   > > 
>   >    You are 
>   hitting one of the 
>   > > 
>   > > core challenges in dealing with 
>   Windows 
>   > remote 
>   > 
>   > management. 
>   > >    The ruby 
>   WinRM gem, which we 
>   > > use for 
>   knife-windows, 
>   > >   doesn't 
>   support 
>   > > CredSSP credential 
>   delegation (and there 
>   > 
>   > > 
>   > > are 
>   security 
>   > concerns with that anyway). 
>    A better 
>   > > 
>   > 
>     workaround would be to create a scheduled task 
>   > > that will run 
>   > 
>   >   
>   > Chef Client and trigger that 
>   
>   > > from 
>   > winrm 
>   (with schtasks 
>   > >   /run).  This 
>   
>   > 
>   > > gets around 
>   the logon type and 
>   > credential 
>   > > 
>   > > 
>   > delegation issues running in WinRM 
>   provide. 
>   > > 
>   > 
>   > The cause of the 
>   > issue is that 
>   when you 
>   > > 
>   > 
>   > land in a remote shell hosted inside WinRM 
>   > (either WinRS 
>   > > 
>   or 
>   > > 
>   >   
>   PowerShell Remoting), you're 
>   > > 
>   
>   > connecting to a service and 
>   > >   that 
>   > service 
>   
>   > > does not have the right to 
>   > pass on your 
>   > > 
>   
>   > > 
>   > credentials 
>   to other services/computers.  So when you 
>   > > try 
>   > >   to 
>   mount the 
>   > outside resource, it 
>   > > attempts to 
>   > 
>   connect as the 
>   > >   computer's 
>   
>   > > Network Service account.  The 
>   path around 
>   > 
>   > > 
>   
>   > > this is either 
>   > Kerberos delegation (which has 
>   > > 
>   > requirements 
>   
>   > >   on the client side and 
>   > in 
>   > > Active 
>   Directory) or CredSSP, 
>   > >   which 
>   the 
>   > > WinRM 
>   > 
>   gem doesn't handle.  Task scheduler 
>   > >   suffers no such problems (and is a 
>   
>   > better way 
>   > > 
>   to run Chef 
>   > >   Client - and 
>   closer to how it 
>   > > should run in a 
>   production 
>   > >   context. 
>   > >   Steve 
>   > 
>   > >   Steven 
>   > > 
>   
>   > MurawskiCommunity Software Development 
>   Engineer @ 
>   > >   ChefMicrosoft MVP - 
>   PowerShell 
>   > >   http://stevenmurawski.com ;
>   > >                         
>       
>   >     
>   > > 
>           On 7/1/2015 9:54:21 
>   > 
>   > >   PM, o haya 
>   > 
>   > 
>   > 
>   > > 
>   wrote:Hi, 
>   > >   
>   > >   
>   > >   
>   > >   I have been implementing 
>   > > some 
>   > >   
>   
>   > recipes/cookbooks for deploying and 
>   
>   > > 
>   > configuring 
>   Sharepoint 
>   > >   and Exchange 
>   > onto 
>   > > our 
>   Windows servers.  These 
>   > servers would 
>   
>   > > 
>   > > be 
>   > domain mmembers. 
>   > 
>   >   
>   > >   
>   > 
>   >   
>   > >   I was originally 
>   testing by 
>   > > logging into 
>   > >   one 
>   > of the 
>   Windows server and 
>   > > then running 
>   
>   > "chef-client 
>   > >   -o 
>   > > 
>   myCookbook" and was finally able to 
>   > get them working 
>   > 
>   >   this past week. 
>   > 
>   > >   
>   > >   
>   > >   
>   > >   Both 
>   sets 
>   > > of recipes expect the 
>   respective 
>   > > 
>   > 
>   > installation files to 
>   > be shared 
>   out from the domain 
>   > >   
>   > controller and the recipes do a 
>   > > 
>   > 
>   "mount" to 
>   > >   
>   "Z:" 
>   > drive, 
>   > > and then the recipes do 
>   > "cd 
>   > >   
>   z:\" 
>   > > and then execute the 
>   appropriate .exe 
>   > inside a 
>   > >   powershell_script 
>   > resource. 
>   > > 
>   > > 
>   > >   
>   > >   
>   > >   As I 
>   
>   > > said, I got 
>   > 
>   these recipes working this 
>   > > 
>   > > week, but in the real world, we would 
>   want 
>   > to trigger the 
>   > >   cookbook/recipe 
>   > execution remotely using like 
>   > > 
>   > "knife 
>   > >   winrm", so I 
>   > started 
>   > > testing 
>   the recipes using 
>   > >   "knife 
>   
>   > > 
>   > winrm" 
>   this weekend, and, in both cases, I 
>   > 
>   >   ran into similar problems with both 
>   > sets of 
>   > > 
>   recipes.  
>   > >   
>   > >   
>   > >   
>   > >   The first 
>   > 
>   problem was that 
>   > > the 
>   > >   "mount" would fail with 
>   
>   > > "access denied", 
>   > >   so I've 
>   > 
>   > since 
>   > tried (a) pre-creating the 
>   mapped drive 
>   > >   outside of Chef 
>   and also (b) physically 
>   > 
>   > > copying the entire 
>   > >   directories of 
>   > > 
>   > installation 
>   software to the local C: drive 
>   > > 
>   
>   > > and running the 
>   > installations off of the local files. 
>   > > 
>   >   
>   > >   
>   > >   
>   > >   Unfortunately, neither (a) nor (b) 
>   
>   > approach 
>   > >   
>   worked either.  These 
>   > failures occur 
>   at 
>   > > different points of 
>   > 
>   > >   the 
>   installation, but 
>   > > my impression 
>   is that all the failures 
>   > >   are 
>   
>   > > coming down 
>   > 
>   to some kind of access denied or violation. 
>   > >   
>   > >   
>   > >   
>   > >   So, 
>   I've 
>   > spent most of this weekend 
>   
>   > >   testing 
>   > 
>   and researching, which lead me to find 
>   > 
>   > 
>   > some older 
>   > 
>   >   threads and information 
>   > on 
>   > > things like credssp an 
>   > >   "2-hop" 
>   > > 
>   > that seem to 
>   indicate that these problems 
>   > > 
>   > > have been around for 
>   > awhile, so I was wondering if 
>   > >   
>   > there's 
>   some mechanism or configuration 
>   > > 
>   that should fix 
>   > >   
>   > he problem nowadays? 
>   > 
>   >   
>   > >   
>   > 
>   >   
>   > >   Also, I should mention 
>   that I'm 
>   > tried 
>   > >   setting the WinRM CredSSP to 
>   > "true" 
>   > 
>   > on both the 
>   > >   server side 
>   and on my client 
>   > > (Chef 
>   workstation) side, but 
>   > >   that 
>   
>   > > hasn't 
>   > 
>   made any difference. 
>   > >   
>   > >   
>   > >   
>   > >   Can anyone 
>   > 
>   > here 
>   > tell me how I can get these 
>   
>   > > 
>   > > 
>   cookbooks/recipes to work using 
>   > 
>   "knife winrm"? 
>   > >   
>   > >   
>   > >   
>   > >   Thanks, 
>   > > 
>     
>   > > 
>   > > Jim 
>   
>   > >   
>   > >   
>   
>   > >   
>   > >   
>             
>   >                 
>         
>   > > 
>   > 
>       
>   > >   
>   > 
>   >     
>   >     
>   > 
>   >                       
>   > 
>             
>   > > 
>   > 
>   > 
>   
>                                        
>   
>   > 
>   > 
>   
>                                          
>   
>   > 
>   
>                                         
>   
>   > 
>