< >> 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 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
>
>
>
>
>
>
>
>
>
> > > > >
Archive powered by MHonArc 2.6.16.