i'm having a problem while executing batch script from linux machine.
Scenario:
I've a windows machine installed server2008, I need to automate some windows task that executes from linux machine. I've installed cygwin software on windows VM and create a batch script that is running fine from cygwin terminal. i.e cd ~/;./script.bat
Problem:
When I execute the same script from linux machine using ssh it seems works fine and print script executed successfully but when I checked that the task from windows it did nothing.
cat script.bat
#echo off
set sourcePasswd=%1
set destinationPasswd=%2
set destinationProjectName=%3
set user=%4
set xmlPath=C:\cygwin\home\%user%\Duplicate.xml
ECHO Start : Duplication project source for %destinationProjectName%
"C:\Program Files (x86)\Common Files\MySoftware\Duplicate.EXE" -f %xmlPath% -sp %sourcePasswd% -dp %destinationPasswd% -sup -md -dn %destinationProjectName%
ECHO Finish : Duplication project source for %destinationProjectName%
Looks like Leopard hasn't been back since he posted the question or the link to the answer, so I'll be the Point Pimpette tonight and fill in the blank.
The answer below is from the link:
http://cygwin.com/ml/cygwin/2010-07/msg00598.html
It was fixed after doing the following setup :
Open control panel=> Administrative Tools=>Computer
Management=>Services
lookup the sshd service, right
click=>properties=>log on, and check the checkbox for Allow service
to interact with desktop
restart the service.
thanks
Saravana
Related
I'm trying to run a batch file from a local Windows server that calls on computers in my domain to pull from the shared folder and run an exe. I'm not sure if my script is trying to do too much or too little.
So I run the below batch locally
X:\pstools\psexec.exe \\Computer -d -u DOMAIN\user -p password -i \\SERVER\test\testfile.bat
and testfile.bat:
#echo off
pushd \\SERVER\test\
call program.exe
popd
When I run the script, psexec runs and I get a confirmation that testfile.bat was started on target computer. On the targeted computer nothing happens. If I navigate to the share on the targeted computer and run testfile.bat, I get "CMD.EXE was not started with the above path as the current directory.UNC paths are not supported. Defaulting to Windows directory." From there the computer runs the called .exe with no issues.
If I target this towards another server in my domain it executes perfectly, but not on domain computers. I thought maybe a GPO issue, but I can't find a solution.
Thanks for any knowledge or help provided!
Thanks for all the tips everyone! This is how I ended up getting it working for anyone who might have the same issue.
Script on Server:
x:\pstools\psexec.exe \\Computer(or text file with computers listed) -d -s cmd /c (batchfile.bat)
Similiar to what I was trying before, but to ensure you run the command line as System on the remote PC you have to specify "-s cmd". The /c copies the batch to the remote system to run locally. You can include a "-f" to overwrite if you've already copied it previously. I just put the batchfile in the pstools folder.
Batchfile.bat:
pushd \\networkdrive
call (.bat/.cmd/.exe/etc.)
popd
I disabled the firewall for testing, but I believe you have to open TCP-445/UDP-137 for PSEXEC. Otherwise, that's it. Super simple solution.
I have vs code configured to use the git bash as a terminal in windows 7.
"terminal.integrated.shell.windows": "C:\Program Files\Git\bin\bash.exe"
I have enabled SSH key based authentication to remotely access a host. All this works fine from within the terminal in VS Code.
However, when using the vscode-remote SSH extension to connect to host I get an error because it tries to connect using "The terminal process command 'cmd.exe'" instead of git bash.
I've checked my terminal settings configuration in vs code and it points to git bash.exe
I've used the terminal extension in vs code and it opens a git bash and successfully connects to the host
Is there a setting that I'm missing to force Remote-SSH to use the git bash for the connection?
JerryL's answer lead me to realize, that I can simply set GIT's ssh path c:\Program Files\Git\usr\bin\ssh.exe in the remote.SSH.path setting of VS Code Preferences:
Then it just worked like a charm.
Just for clarity my VS Code version is: 1.40.0-insider (system setup)
I ran into a similar issue trying to get MS VS Code Studio Remote-SSH working with Putty's Pageant. I had Git for Windows installed and in a Git Bash shell, I could ssh and pick up the Pageant keys and no password was needed.
But VS Code Remote-SSH, while using the Git ssh in C:\Program Files\Git\usr\bin\ssh.exe was using Windows 7 cmd.exe shell which didn't talk to Pageant.
What worked for me on Windows 7, VS Code 1.36.1 with (Remote Development 0.15.0, Remote-SSH 0.44.0) and Git for Windows 2.22:
Start Pageant (C:\Program Files\PuTTY\pageant.exe) and Add key.
Start the ssh agent shim (C:\Program Files\Git\cmd\start-ssh-pageant.cmd). This takes care of the communication between Git ssh, which looks for ssh-agent, and Pageant.
Create the SSH_AUTH_SOCK environment variable
Control Panel / System / Advanced Settings / Environment Variables..
User variables for username / New..:
Variable name: SSH_AUTH_SOCK
Variable value: /tmp/.ssh-pageant-username (e.g. /tmp/.ssh-pageant-bill) (Environment Variable assignment screenshot)
Test ssh:
Open a command prompt: Enter set to view the list of Environment Variables. Is the SSH_AUTH_SOCK variable set correctly to something like /tmp/.ssh-pageant-bill?
Try ssh to your host using Git's ssh.exe: c:\Program Files\Git\usr\bin\ssh.exe user#host If this works, then VS Code Remote-SSH should work.
Finally, I added Pageant and start-ssh-pageant.cmd to my Windows 7 Startup so this persists across reboots.
Hope that helps.
Jerry.
I had a similar problem trying to get VS Code Remote use Putty Pageant.
1. Create .bat file somewhere with the following content:
echo OpenSSH
"C:\YOUR_PATH_HERE\PLINK.EXE" -ssh %*
2. Open VS Code settings, type remote ssh path in search and find Remote.SSH: Path settings
3. Past here path to your .bat file
4. Now VS Code Remote will use Pageant correctly.
I am trying to update some legacy software so that it works on a new computer. The software connects to an AS400 with runs a .batfile on the local machine.
The command:
psexec \\localhost -i c:\path\to\file.bat s3
works like a champ when executed from the command line on the local machine, but when fired from the AS400, nothing happens. No errors. No anything.
Any ideas?
update The computer is a Windows 7 machine.
update 2 - batch file contents
FTP -s:C:\scls\PGINPC3I.FTP i.p.a.d.d.r.e.s.s
C:\scls\NGINPC3 S3
FTP -s:C:\scls\PGINPC3O.FTP i.p.a.d.d.r.e.s.s
Provided your version of PSExec is recent. If you haven't ran PSExec on the remote machine physically and accepted the license agreement, you'll get this kind of behavior. There is an undocumented switch for PSExec to alleviate this kind of issue. it's /accepteula just add that in your call to PSExec and see what happens.
Exactly like this with the forward slash:
psexec \\localhost -i /accepteula c:\path\to\file.bat s3
EDIT
The -c switch:
-c Copy the specified program to the remote system for
execution. If you omit this option the application
must be in the system path on the remote system.
What I'm trying to do might be simple for veteran programmers. I have two Windows machines: MachineA and MachineB. From MachineA, I want to:
1) ssh into MachineB, run a batch file say C:\parent\test.bat -start
2) delete C:\parent folder
3) Copy C:\parent folder from MachineA to the C drive in MachineB
4) Run C:\parent\test.bat -stop
5) I need to do all the above through a script on MachineA (preferably a Batch Script)
Most of what I've read so far about this uses plink or other software (someone suggested WinSCP).
It would be nice if I could do all this WITHOUT installing any software. Any suggestions??
(I do have msysgit on both machines)
SSH is not supported by windows. You will have to install a utility to run a command on a remote machine
You can find details in this post:
How to execute a dos command on a remote PC?
Your other option is to use Windows Powershell scripts.
I am trying to run this command in jenkins after a MSbuild
xcopy "C:\Program Files (x86)\Jenkins\workspace\trunk\Projects\results\results\obj\Debug\Package\PackageTmp" "Y:\Extraction_Zone\Jenkins\" /E
Y: is a mapped network drive. This runs fine in cmd.exe but when trying to run it in Jenkins, I am getting the error Invalid drive specification.
Here is the output from jenkins:
Time Elapsed 00:00:04.03
[trunk] $ cmd /c call C:\Windows\TEMP\hudson3389873107474371072.bat
C:\Program Files (x86)\Jenkins\workspace\trunk>xcopy "C:\Program Files (x86)\Jenkins\workspace\trunk\Projects\results\results\obj\Debug\Package\PackageTmp" "Y:\Extraction_Zone\Jenkins\" /E
Invalid drive specification
0 File(s) copied
C:\Program Files (x86)\Jenkins\workspace\trunk>exit 4
Build step 'Execute Windows batch command' marked build as failure
Finished: FAILURE
Any help would be appreciated.
I too had a similar issue once. Try granting the Jenkins service "Logon as This account" right under services.msc and make sure the account you type there is the same as the one you use for running cmd.exe.
These commands based on Java JAR files worked for me:
cmd
net use x: \\
xcopy "dist\" x:\ /Y
And that's it! I spent lot of time figure out this issue and nothing worked until I wrote CMD and NET USE!
Neither I didn't need to change permission on jenkins service nor use runas command.
But I must mention that everyone had read and write access to the network drive.
I had the same issue with my Windows Task running a batch file (I know it is not exactly same) where I tried to copy file to network location i.e. shared drive. I used the UNC path and mapped drive as well but the error was same. For me it was error number 4 - MS DOS error code.
The solution was to use net use command! Hope that it helps.
Easy fix for most things.
Make a batch command with what your trying to run, filename.bat with the command prompt text inside.
Make a normal windows shortcut for the batch command, edit the shortcuts advanced properties and check the "Run as admin" (tricky tricky).
Now run the filename.lnk shortcut from jenkins command line call, this will get you around all the jazz.
:)
The solution of adarshr (i.e., modifying the log on credentials of the service) has worked for me for a part of the problem: in my case, this allowed me to successfully check out a mercurial repository (using ssh protocol), which I could not do when using 'Local System account'.
However, I still have different behavior between running a command-line script or running the same script from a jenkins 'execute shell' script in the build section. In my case, I compile a Python extension. In Jenkins, I cannot import the extension (I don't see any error, but the execution simply stops, so I suspect it crashes).
If I uninstall the service and run the slave agent as a Java Web Start, I do get the same behavoir. It is a temporary fix for me, but it means that when I reboot the windows build machine, I have to manually re-start the Java Web Start application.
So -at least in my case- it is clear that this is a credential problem.
Credentials usage documentation: https://wiki.jenkins-ci.org/display/JENKINS/Jenkins+CLI
I've solved my issue with the CIFS plugin.
Faced similar issue and found two ways to solve.
Type 1:
Tell Jenkins about mapped drive.
1.Goto -> Manage Jenkins -> Script Console (Groovy Script).
2.Run below command
def mapdrive = "net use Y: \\\\copy_nework_address"
mapdrive.execute();
println "net use".execute().getText()
Type:2
1.Goto -> cmd -> run "net use" to know network address
xcopy "C:\Program Files (x86)\Jenkins\workspace\trunk\Projects\results\results\obj\Debug\Package\PackageTmp" "Copy_Network_Address\Extraction_Zone\Jenkins\" /E
Conclusion:- I prefer 2nd types as after every restart i should run Groovy Script.