TeamCity and psexec don't work at all - teamcity

Im trying to execute script on remote machine (script resides REMOTELY, and NOT in agent folder or whatever) through Command Line Runner:
#echo off
%env.ALLUSERSPROFILE%\JetBrains\TeamCity\plugins\.tools\psexec.exe \\12.34.56.78 -h -u admin -p 12345 T:\Folder\Script\update.cmd T:\Folder\Server
But I always get:
The system cannot find the path specified.
Process exited with code 1
And NOTHING else. TeamCity and psexec just scrambling output and not giving it out on what actually not found, what is the problem or whatever. It just freaks me out to even use psexec to run something.
What am I doing wrong? What else do I need to specify to JUST run it remotely (Im not asking about giving me output of script, because as I searched I understand what such simple functionality is not supported by psexec at all)?

Related

SSH tectia, how to run batch commands?

I have tectia ssh server in a windows environment.
When I use sftpg3 -B cmd.txt username#host that works fine. The only problem is that it doesnt let me execute files remotely, it only lets me move files. It reads the commands from cmd.txt but since I cant execute anything it ignores the commands.
Well when I do the same thing but use sshg3, it doesnt recognize the -B flag at all.
SSHG3 -B cmd.txt username#host
cmd.txt' is not recognized as an internal or external command,
operable program or batch file.
I've tried putting -B "cmd.txt"
I tried just putting the cmd.txt contents in the same script instead of housing them in cmd.txt and getting rid of -B, but it doesnt run them that way either.
The docs dont have much to go off of. All it says is use -B for batch processing.
Contents of cmd.txt:
D:
cd Library
cd Backup
parseLibrary.cmd
exit
Trying to sshg3 into a host, navigate to a path and run a batch file on that host.
Any ideas?
-B, --batch-mode
Uses batch mode. Fails authentication if it requires user interaction on the terminal.
Using batch mode requires that you have previously saved the server host key on the client and set up a non-interactive method for user authentication (for example, host-based authentication or public-key authentication without a passphrase).
It does use public key authentication, there is no user interaction needed on the terminal.
Noticed this on the docs for sftpg3
-B [ - | batch_file ]
The -B - option enables reading from the standard input. This option is useful when you want to launch processes with sftpg3 and redirect the stdin pipes.
By defining the name of a batch_file as an attribute, you can execute SFTP commands from the given file in batch mode. The file can contain any allowed SFTP commands. For a description of the commands, see the section called “Commands”.
Using batch mode requires that you have previously saved the server host key on the client and set up a non-interactive method for user authentication (for example, host-based authentication or public-key authentication without a passphrase).
I'm guessing batch file is different than batch mode?
*I figured it out. You have to use the -B flag for every command you want to execute.
I figured it out. You have to use the -B flag for every command you want to execute.
sshg3 user#host -B dir -B ipconfig -B etc.cmd

PSEXEC returning garbage result. Why?

I want to run a script on a remote windows 2008 server using PSEXEC of PSTOOLs..
I have installed PSTOOLs on my local machine and can run the PSEXEC command successfully as well. I connect to the remote server through it and it even picks up the script placed there. However, all I get is some sort of garbage values. And after that it states that the intended network is no longer available, which it is because I can see it and access it through the GUI.
I must mention that when I execute that script manually in the remote server it works fine. I am using windows remote desktop utility to connect to the server.
Am I using PSEXEC the correct way? Or is the intended function of PSEXEC the same as what I am trying to do?
First you should have a look at the help page
You must use -w to specify the remote working dir, and you can't call a .bat directly, you have to call cmd.exe. So try this
psexec \\remoteserver -w "c:\users\admin\desktop\" cmd.exe /c youbatch.bat

run command as administrator on remote windows machine

Situation: Running the bat file on windows machine:
1. When I double click the bat file: Bat running is failed.
2. When I right click on bat file and run as administrator: Bat run is successful.
Now I have to run this bat file successfully from remote machine.
What I did:
1. Installed freeSSDd on remote machine and configured administrator user on freeSSHd to access shell and SFTP.
2. Now I am able to login to the remote machine using putty.
Problem:
I am not able to run the bat file successfully. How can I achieve this?
I also used runas /savecred /user:administrator C:/install.bat, but It didn't helped.
There is a way to get this working without any 3rd party software.
You have to create a task on the remote machine using the windows task scheduler which simply executes the desired command. There is an option where you can tell the scheruler to run a bat with a specific account. Enter an admin account and the password and check the "run with highest privileges" box. Leave "Triggers" empty, go to "Settings" and check the "Allow task to be run on demand" box. That's it!
Now when you want to run your file from a different location do
SCHTASKS /RUN /S <RemoteServerName> /U username /P password /TN "<task name>"
If you don't want to enter username and password each time you can adept the user policy (e.g. add the calling machine to the trusted list of the server).
If you have installed an ssh daemon, then you can run your BAT in a remote shell, but you remote shell may open up in something other than CMD.COM. I use cygwin to set up sshd and then from a remote machine, if I ssh in to run a command, it is using cygwin's bash. I can run a BAT file, but need to call CMD first:
ssh WINDOWS_SERVER "cmd /C D:\PATH_TO_BAT\BATCHFILE.BAT"
But there are some pieces missing here. I looked briefly at the Freesshd page and saw only graphical interfaces. Does freesshd support remote command execution, or just secure fire transfer? And what sort of shell get executed on the windows server when you run it?
cygwin is an entire Linux subsystem that runs under Windows and includes an sshd server, but might be a bit much for someone starting out: https://cygwin.com/
\n makes a powershell remote server that listens on port 22 (ssh) and dumps you into a powershell prompt, you can then use my steps above to call CMD from powershell, versus a bash shell.
http://www.powershellserver.com/

Chef knife winRM interactive mode hangs in Jenkins

I've been stuck on this issue for the past 3 or 4 days. I am trying to run the attached command in a Windows batch file in Jenkins. This causes it to hang and it doesn't accept any further inputs:
knife winrm ec2-xx-xx-xx-xx.compute-1.amazonaws.com interactive -m -x Administrator -P xxxxxxxx
This works fine if run manually on a Windows machine, but I think the ruby.exe that is being opened is starting to cause Jenkins some problems.
Has anyone ever used knife winRM's interactive mode in such a way before? I'm at my wits end here and I really need this to work. Thank you for any help you could provide.
Have you tried running it as "call knife" instead of just "knife"? If, inside a batch file, you run another batch file (knife.bat, for example) without "call", the initial batch file run is terminated. There's a good explanation here: http://www.robvanderwoude.com/call.php

cp command fails when run in a script called by Hudson

This one is a puzzler. If I run a command from the command line to copy a file remotely it works perfectly. If I run that same command inside a script on the server (that hosts Hudson), it runs perfectly as well, same for running the job as hudson from the command line. However, if I run that exact command as a function inside a bash script from a Hudson job, it fails with:
cp: cannot stat '/opt/flash_board.tar.gz': No such file or directory
The variable is defined as:
original_tarball=flash_board.tar.gz
and is in scope (variable expansion works correctly in the script).
The original command is:
ssh -n -o stricthostkeychecking=no root#$IP_ADDRESS ssh -n -o stricthostkeychecking=no 169.254.0.2 cp /opt/$original_tarball /opt/$original_tarball.bak
I've also tried it as:
ssh -n -p 1601 -o stricthostkeychecking=no root#$IP_ADDRESS cp /opt/$original_tarball /opt/$original_tarball.bak
which points to the correct port, but fails in exactly the same way.
For reference all the variables have been checked to be valid. I originally thought this was a substitution error, but that doesn't seem to be the case, so then I tried running it with Hudson credentials as:
sudo -u hudson ssh -n -o stricthostkeychecking=no root#$IP_ADDRESS ssh -n -o stricthostkeychecking=no 169.254.0.2 cp /opt/$original_tarball /opt/$original_tarball.bak
I get the exact same results (it works). So it's only when this command is run from a Hudson job that it fails.
Here's the sequence of events:
Hudson job sets parameters & calls a shell script.
A function inside the script tries to copy the files remotely from an embedded Montevista (Linux) board across an SPI bus to a second embedded Arago (Linux) board
Both boards are physically on the same mother board, but there's no way to directly access the Arago board except through a serial console session (which isn't feasible, this is an automation job that runs across the network).
I've tried this using ssh with -p 1601 (the correct port to the Arago side).
Can I use scp to copy a remote file to the same location as the remote file with a different file extension?
Something like:
scp -o stricthostkeychecking=no root#$IP_ADDRESS /opt/$original_tarball /opt/$original_tarball.bak
I had a couple of the devs take a look at this and they were stumped as well. Anyone got any ideas (A) why this fails & (B) how to work around it. I'm pretty sure I can write a script to run locally on the remote machine, but that doesn't seem like it should be necessary.
Oh, and if I run the exact same command on the Montevista board (which means I don't have to go across the SPI bus (169.254.0.2), it works perfectly from the Hudson job.
So, this turned out to be something completely unrelated to the question. I broke the problem down into little pieces with a test Hudson script, adding more and more complexity from the original script till it failed as before.
It turned out to be pilot error, I'd written an if statement to differentiate between the two boards (Arago & Montevista) and then abstracted out the variables passed to the if statement to the point where it was ambiguous which board was being passed in, so the if logic always grabbed the first match (as it should) and the flash script I was trying to copy on the Arago board didn't exist on the Montevista board (well, it has a different name) so the error returned was absolutely correct.
Sorry for the spin up and thanks for all the effort to help.
cp: cannot stat '/opt/flash_board.tar.gz': No such file or directory
This is saying that Hudson cannot see the file. I would do a ls -la /opt in that shell script of yours. This will show you the permissions on the /opt directory, and whether your script can list that file.
While you're at it, do a du -f on the Hudson machine too and see if that /opt directory is a remote mount or something that could be problematic.
You've already said that you logged in as the user that runs the Hudson task and execute it from the workspace directory.
Right now, I suspect that the directory permission is an issue.
The obvious way that goes wrong is that somehow it is being run on the wrong machine, possibly due to either a line length limit, or to weird quoting issues.
I'd try changing the command to … uname -a or … hostname -f to see if you get the right machine. Or, alternatively, … cp /proc/cpuinfo /tmp/this-machine and then see which machine gets the file.
edit: I see now that OP has answered his own question. I guess I'll leave this here in case it helps any future visitors with similar issues. I guess I should add "or not running the command you thing you're running" to the reasons why it could happen.

Resources