I’m seeking help from those of you who have more Windows-fu than I.
I need to install some software from a Windows share.
Unfortunately there doesn’t seem to be a way to specify username and
password in a UNC path and give that to either the windows_service or
remote_file resource. Or is there?
Failing that, we tried something like this:
execute “mount share #{drive}” do
command "net use #{drive}: #{path} /user:#{username} #{password}
/persistent:No"
end
windows_package “Symantec Anti-Virus” do
source
"#{drive}:\#{node[‘symantec-antivirus’][‘installer’][‘arch_file’]}"
options “/qn ALLUSERS=1 REBOOT=ReallySuppress”
action :install
end
execute “unmount share #{drive}” do
command "net use /d #{drive}:"
end
This sucks in many ways (deciding which drive letter to use is tricky, any
failure will leave mapped drives around, …).
Worse, it doesn’t work when chef-client is run a service!
STDERR: System error 1312 has occurred.
A specified logon session does not exist. It may already have been
terminated.
Googling about this stuff, it seems there is a way around this error by
using a PSEXEC.EXE, but I would rather avoid that is possible.
what about using what you have there, but skipping the drive letter?
If i remember correctly you can leave that out, and it will assign it to a
void mount, then you can access it using the original UNC path...
so to get a directory listing it would look like:
net use //myserver/myshare /user:me pass
dir //myserver/myshare/myfolder
net use //myserver/myshare /delete
or maybe you have to use \ instead of //... again, been a few years
-Jesse
I'm seeking help from those of you who have more Windows-fu than I.
I need to install some software from a Windows share.
Unfortunately there doesn't seem to be a way to specify username and
password in a UNC path and give that to either the windows_service or
remote_file resource. Or is there?
Failing that, we tried something like this:
execute "mount share #{drive}" do
command "net use #{drive}: #{path} /user:#{username} #{password}
/persistent:No"
end
windows_package "Symantec Anti-Virus" do
source
"#{drive}:\#{node['symantec-antivirus']['installer']['arch_file']}"
options "/qn ALLUSERS=1 REBOOT=ReallySuppress"
action :install
end
execute "unmount share #{drive}" do
command "net use /d #{drive}:"
end
This sucks in many ways (deciding which drive letter to use is tricky, any
failure will leave mapped drives around, …).
Worse, it doesn't work when chef-client is run a service!
STDERR: System error 1312 has occurred.
A specified logon session does not exist. It may already have been
terminated.
Googling about this stuff, it seems there is a way around this error by
using a PSEXEC.EXE, but I would rather avoid that is possible.
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
On Thu, Jan 31, 2013 at 11:23 AM, Jesse Campbell hikeit@gmail.com 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.
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.
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 hikeit@gmail.com
wrote:
what about turning off the security policy described in
this article?
[1]
the net use command is creating a stored credential, which
would normally only work when applied to a logon session.
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.
Are you working in a domain environment? If not, can you set one up (a Samba-based NT domain should be just fine. Active Directory is better of course)?
With a domain, the computer itself will have a domain account, and you can add computers to the permissions for a share the same way you can give users permissions. I’d recommend creating a group that contains all your computers, and then giving that group permissions on your share.
Ohai Chefs,
I’m seeking help from those of you who have more Windows-fu than I.
I need to install some software from a Windows share.
Unfortunately there doesn’t seem to be a way to specify username and password in a UNC path and give that to either the windows_service or remote_file resource. Or is there?
Failing that, we tried something like this:
execute “mount share #{drive}” do
command “net use #{drive}: #{path} /user:#{username} #{password} /persistent:No”
end
windows_package “Symantec Anti-Virus” do
source "#{drive}:\#{node[‘symantec-antivirus’][‘installer’][‘arch_file’]}"
options “/qn ALLUSERS=1 REBOOT=ReallySuppress”
action :install
end
execute “unmount share #{drive}” do
command "net use /d #{drive}:"
end
This sucks in many ways (deciding which drive letter to use is tricky, any failure will leave mapped drives around, …).
Worse, it doesn’t work when chef-client is run a service!
STDERR: System error 1312 has occurred.
A specified logon session does not exist. It may already have been terminated.
Googling about this stuff, it seems there is a way around this error by using a PSEXEC.EXE, but I would rather avoid that is possible.
Thoughts?
Are you working in a domain environment? If not, can you set one up (a
Samba-based NT domain should be just fine. Active Directory is better of
course)?
Unfortunately not, neither is an option. Too bad, because what you suggest
would be a nice and proper fix.