All of that only works within a domain, because it relies on computers in the domain being able to trust each other and/or trust a central (Kerberos) server. Without a domain environment, there really is nothing the server could trust, other than an actual user name and password. In fact, solving this particular issue was the main motivation for creating domains in the first place.
You may have one other option, although it's far too complicated for my taste: you can set up a Kerberos server. Windows can use that for authentication even without a domain.
It sounds like none of this would be an option. Here is another way to do that "the chef way".
You could manually copy the files you need to the file directory in your cookbook. Instead of fetching the file from the UNC server, it would come from Chef itself. Drawback is that you have an updating nightmare.
The other option would be to use a script resource to copy the file over and provide the password.
The third option is to use a wrapper script that authenticates to the UNC share, maybe even mounts it with a drive letter, and then calls chef-client.
-----Original message-----
From: Jesse Campbell < >
Sent: Sun 02-03-2013 09:45 am
Subject: [chef] Re: Installing a package from a password-protected UNC share
To: chef < >;
Is the default account for the chef-client service to use the "system" service account? switching to "network" service as you say here should work quite well in that case.On Fri, Feb 1, 2013 at 7:36 AM, Tensibai < "> > wrote:You may also use Network_service account which is able to establish cifs shares from a service.
Le 2013-01-31 17:40, Andrea Campi a écrit :
On Thu, Jan 31, 2013 at 5:23 PM, Jesse Campbell < "> > wrote:
what about turning off the security policy described in this article?the net use command is creating a stored credential, which would normally only work when applied to a logon session.
http://blogs.technet.com/b/askperf/archive/2012/04/18/task-scheduler-error-a-specified-logon-session-does-not-exist.aspx
That's an excellent idea! Our googling hadn't turned that one up :)> another option would be to run the service as a real user instead of one of the service accounts, though i don't remember the steps to make that happen :)Yeah, that's one of options we were considering…It still feels pretty odd that we need to do this manually; surely somebody else has had this problem?I.e. chef-client::service should probably take care of this.
Archive powered by MHonArc 2.6.16.