[chef] Re: Re: knife winrm browsing network shares


Chronological Thread 
  • From: Adam Edwards < >
  • To: " " < >
  • Cc: Brad Knowles < >
  • Subject: [chef] Re: Re: knife winrm browsing network shares
  • Date: Tue, 11 Jun 2013 14:03:29 +0000
  • Accept-language: en-US

To narrow down the problem, it would be good to know the following:

1. On what operating system  / version are you running knife winrm?
2. What OS version is the target OS?
3. Is the target OS joined to a domain?
4. What OS is running on the machine that is the target of the net use
command (i.e. the "server" in "\\server\share")?
5. Is the machine that is the target of the net use command in the same
domain as the machine that is the target of the knife command?
6. Did you set basic auth to true and disable encryption? I'm not sure I'd
expect off-machine access to work in that case.

A short-term workaround is to use scheduled tasks -- if you're interested,
I can give you a specific example, though it would help to know what
you're trying to accomplish with the net use (e.g. run a script, copy a
specific file, etc.).

Problems here are most likely due to the winrm gems used by knife winrm.
Those gems rely on libraries on the system running knife, which could be
Windows, Mac, Ubuntu, etc., and the presence of the right libraries and /
or bug fixes on those platforms varies. We are currently investigating
specific issues with NTLM for instance to see if unreleased versions of
the gems have the improvements needed to make the NTLM scenario work,
hopefully we'll have some prescriptive statements about how to make this
scenario work.

A few more questions:

1. Rather than use knife winrm to perform net use, is this operation
something that you could do from within a Chef recipe that runs on the
target system? That could free you from limitations of WinRM.
2. You could probably use the recipe route via the RC version of
mixlib-shellout, which supports running scripts with alternate
credentials, or some upcoming changes to the Windows mount provider that
will be merged to master this week.

Regarding private vs. open source chef, I don't see anything here that
should make open source chef work differently than private chef. The
connectivity is really about winrm configuration on client and server, and
the winrm / ntlm gems and libraries on those systems, and finally knife
which ships with chef client and plugins like knife-windows that add the
winrm functionality to knife. The chef server code really is not involved
here.

Thanks.

--
Adam Edwards
Software Development Engineer, Opscode, Inc.



On 6/10/13 9:07 PM, "Brad Knowles" 
< >
 wrote:

>On Jun 6, 2013, at 3:00 PM, 
>
> wrote:
>
>> but get an "Access is denied" when doing dir \\\\filer\\share
>
>I'm curious -- has anyone noticed what version of Chef they're using with
>regards to these problems?  At least some of the tickets we've seen
>appear to indicate that the problems with winrm are more prevalent with
>Chef 11.x, whereas Chef 10.18.2 seems to work fine.
>
>But in our case there's also a difference between our using Private Chef
>(based on Chef 11) versus the other site using the Open Source Chef, so
>we're not sure if maybe this is a Private Chef vs. Open Source Chef
>problem, or maybe a Chef 11.x vs. Chef 10.18.x problem, or what.
>
>
>I'm also curious if people have looked at what version of
>knife-essentials they're using?  Some other problems we've seen might be
>related to using older versions of knife-essentials versus newer ones, so
>this is a dimension to the issue that we're also trying to track down.
>
>
>If we can't get this problem resolved quickly, we might be forced to give
>up on Private Chef and step back to Open Source Chef.
>
>Yes, we are working the internal channels at Opscode, but getting more
>information from the community would also be very useful.
>
>--
>Brad Knowles 
>< >
>LinkedIn Profile: <http://tinyurl.com/y8kpxu>




Archive powered by MHonArc 2.6.16.

§