I want to update remote staging server automatically after committing on my dev box.
I'm trying to setup TortoiseSVN post-commit hook on Win 7 64.
I have TortoiseGit installed in system with bunch of useful commands like 'ssh'
I created test.bat script that contains:
ssh -l {username} -i "C:\Users\{path-to-ssh-key.pem}" {server_address} ./svnup
This script running 'svn up' on remote staging server. And this test.bat file works fine when launched manually. But it not works in post-commit configuration. Blank console screen appearing and than TortoiseSVN showing an error:
Error: The hook script returned an error:
Error: 0 [main] ssh 2040 fhandler_base::dup: dup(some disk file) failed, handle 0, Win32 error 6
Error: dup() in/out/err failed
Could you advice?
UPD: I upgraded batch script to use full path.
"C:\Program Files (x86)\Git\bin\ssh.exe" -l {username} -i "C:\Users\{path-to-ssh-key.pem}" {server_address} ./svnup
But error still there. Now it has some new number
Error: The hook script returned an error:
Error: 0 [main] ssh.exe" 6976 fhandler_base::dup: dup(some disk file) failed, handle 0, Win32 error 6
Error: dup() in/out/err failed
Your hook probably cannot find ssh.
Using the full path name can help.
If that doesn't help changing the working directory to the location of ssh can help.
In the worst case you could add the location of ssh to the path, from within the batch file. This will only affect the path, during execution. I believe that a new shell is created by tortoise each time it's called.
As mentioned in the svn book:
For security reasons, the Subversion repository executes hook programs with an empty environment—that is, no environment variables are set at all, not even $PATH (or %PATH%, under Windows). Because of this, many administrators are baffled when their hook program runs fine by hand, but doesn't work when run by Subversion. Be sure to explicitly set any necessary environment variables in your hook program and/or use absolute paths to programs.
Which means your hook script doesn't know where to find ssh and what the current directory is (so using relative paths most likely won't work either).
Solution is to use plink.exe instead TortoiseGit ssh.exe.
And this will work:
c:\plink.exe -ssh -batch -l {username} -i "C:\Users\{path-to-ssh-key.pem}" {server_address} ./svnup
Related
NOTE I am running on windows 10, not linux.
pscp.exe has been downloaded and run in my \Users\Taylor folder. I turned off my firewall just in case that could be interfering. I am trying to download files to my local windows from a remote linux environment using the following input to command prompt:
pscp user#quanah.hpcc.ttu.edu:/home/user/*.ctl \Downloads
I also varied the local name as such:
pscp user#quanah.hpcc.ttu.edu:/home/user/*.ctl C:\Users\Taylor\Downloads
This has worked perfectly in the past (~ one week ago), but now I get the error: "Fatal: Network error: Connection timed out" - I know the server (quanah.hpcc.ttu.edu) is connected and fine because I can ssh to it via PuTTY. Any recommendations?
I'd make sure that once I get the dos shell going, I navigate to where pscp.exe is located and run your command from there, i.e.:
C:\Users\Taylor>pscp ...
I'd also go to the source directory on quanah.hpcc.ttu.edu, in your case, '/home/user/' and do 'pwd' to confirm full path
I'd also set my target directory to be where pscp.exe is located i.e. C:\Users\Taylor because I've had success with that; and not because that is the only way.
I'm using tscon.exe to unlock a remote machine locally before I can run automation tests. When I run my command via RDC it works as expected and unlocks the remote machine locally:
C:>tscon.exe %sessionname% /dest:console
But I need this to run as my first TeamCity build step. Doing so either as a direct TeamCity Custom Script or starting a .bat file, both return the error:
[16:50:22][Step 1/11] in directory: C:\BuildAgent\work\e4249c2d6a4e9e8d
[16:50:22][Step 1/11] 'tscon.exe' is not recognized as an internal or external command,
Why is tscon.exe not recognised when used via TeamCity?
I just had same issue and moving the exe out of System32 is not an option for me.So I have to dig deeper.
Turns out the problem is not Teamcity. It's windows.
"The windows filesystem redirection forces 32-bit application attempts to be installed into or accessed from %windir%\System32, been intercepted and get redirected or re-pointed to %windir%\SysWOW64 instead."
The solution is to use an alias name ( %windir%\Sysnative ) for that directory which windows will not redirected.
Try this :
C:\Windows\Sysnative\tscon.exe %sessionname% /dest:console
For more detailed Reference : http://www.tipandtrick.net/how-to-suppress-and-bypass-system32-file-system-redirect-to-syswow64-folder-with-sysnative/
Here is the solution:
Copy tscon.exe to any location other than %windir%\System32\
i.e. C:\TeamCity\tscon.exe
Add TC build step as below (ensure to include Working Dir):
Now the remote machine will login locally before completing the TC steps
I've got a continuous integration server (Jenkins ) which builds my code (checks for compilation errors) and runs tests and then deploys the files to a remote server (not a war file, but the actual file structure) I do this with a Jenkins plugin which allows me to transfer files via samba, it does this nightly.
Now, what I need to do is run an ant command on the remote server. And after that I need to start the application server on the remote server, the application server is started by running a .bat file from the command line.
I'm pretty clueless how to accomplish this, I know Jenkins is capable of running batch commands, but how do I make them run in the context of the server and not the context of the build server?
If Jenkins on Windows, remote on *nix, use plink.exe (which is essentially command line PuTTy)
If Jenkins on Windows, remote on Window, use psexec.exe
If Jenkins on *nix, remote on *nix, use ssh
If Jenkins on *nix, remote on Windows, (update 2015-01) Ansible http://docs.ansible.com/intro_windows.html has support for calling Windows commands, eg powershell, from a unix/linux machine, https://github.com/ansible/ansible-examples/blob/master/windows/run-powershell.yml
Tell me what OSes are involved (both on Jenkins and remote), and I will flash this out further.
Edit:
The download page for psexec.exe lists all command line options. You will want something along the lines of:
psexec \\remotecomputername -u remoteusername -p remotepassword cmd /c <your commands here>
Replace <your commands here> with actual commands as you would execute them from command prompt.
Note that psexec first needs to install a service, and required elevated command prompt/admin remote credentials to do so.
Also, you need to run psexec -accepteula once to accept the EULA prompt.
Following Slav's answer above, here is a simpler solution for Jenkins (*nix) to remote (windows):
Install an SSH server on your remote windows (MobaSSH home edition worked well for me)
Make sure your Jenkins user, on your Jenkins machine, has the required certification to open an SSH connection with your remote (you can simply open a terminal and ssh to your remote once, then accept the certification. Make sure it is saved for the Jenkins user).
You can now add an execute shell build phase in your Jenkins job which can SSH to your remote windows machine.
Notes :
The established connection might require some additional work - you might have to set windows environment variables or map network drivers in order for your executed commands or batch files to work properly on your windows machines.
If you wish to run GUI related operations this solution might not be relevant (Following my work on running automation tests which require GUI manipulation).
Using Jenkins SSH plugin is an issue, as seen here.
1、i install (MobaSSH home ) on my remote windows server .
2、and install jenkins ssh plugin
3、edit shell eg: go build project
4、it seems something wrong ,
" go: creating work dir: CreateFile C:\WINDOWS\system32\bsh\tmp: The system cannot find the path specified."
I ended up going with a different approach after trying out psexec.exe for a while.
Psexec.exe and copying files over the network was a bit slow and unstable, especially since the domain I work on has a policy of changing password every months (which broke the build).
In the end I went with the master/slave approach, which is faster and more stable. Since I don't have to use psexec.exe and don't have to copy files over the network.
I have kind of a bizarre problem. I have a directory on a network share that contains the cygwin binaries. This cygwin dir used to be on a dell poweredge box and was mounted as a virtual directory in IIS8. A webservice would execute a call then to a bash script like so:
\\poweredgeshare\cygwin\bin\bash --login -c "//poweredgeshare/mytools/myshellscript.sh 2>&1 | tee -a //poweredgeshare/logs/logoutput.txt"
This worked great until we got a new dell Equalogic fileserver with an FS7600 front end and tried to execute that call from IIS8 on a windows server 2012 box. With that combination, I now get the following error:
/usr/bin/bash: //fs7600/mytools/myshellscript.sh: Cannot allocate memory
This WORKS if I mount that exact same fs7600 share on my windows 8 box's IIS8 as a virtual directory. All web calls function as expected. It just blows up after I deploy it to the production (server 2012) machine.
I have found that if I remove the 2>&1 | tee -a and just use > instead it works in all cases. So there is something about the pipe to tee that is causing an issue.
I am not a shell script expert- I didn't write this, I'm just trying to debug it and understand why the exact same cygwin binaries calling the exact same shell scripts but just on a new filesystem blows up.
So to sum up what worked and what doesn't work:
- old fileshare works on both dev (windows 8) and production (server 2012) environment
- new fileshare works on dev, but NOT server 2012
Does anyone have any thoughts as to why this might be happening?
Trying to run a simple
svn list svn+ssh://...
from within jenkins on os X, as an execute shell step. The job is not linked to a SVN repository - I am trying to do an svn list manually on the tags folder without having jenkins downloading a copy of each tag.
but other jobs are connected to svn and jenkins checks out code fine.
I have downloaded jenkins from here which runs jenkins as a daemon
The problem is ssh keys. After a few iterations, here where I am at.
In /Library/LaunchDaemons/org.jenkins-ci.plist I have set JENKINS_HOME as /Users/Shared/Jenkins/Home (that's where jenkins gets installed), and in there I have created ssh keys, without passphrase (for now)
The actual command I am running is
svn --config-dir=/Users/Shared/Jenkins/Home/.subversion list svn+ssh://...
to get around jenkins running shell steps as root without actually having root permissions (not sure why - jenkins is launched by loading /Library/LaunchDaemons/org.jenkins-ci.plist) and causing a permission error when it tires to read /var/root/.servers
in --config-dir=/Users/Shared/Jenkins/Home/.subversion/config I have added
ssh = $SVN_SSH ssh -v -i /Users/Shared/Jenkins/Home/.ssh/id_rsa
so ssh can connect to the server. The last missing step now is that the shell expects the passphrase and cannot get it from Keychain (obviously)
debug1: read_passphrase: can't open /dev/tty: Device not configured
I thought leaving an empty passphrase would do the job, but it doesn't. Any clues? Thanks in advance.
I don't think there is a workaround to "read_passphrase: can't open /dev/tty: Device not configured" - the command expects terminal input and can't get it, nor can it get Keychain to provide it. It's all tied in with running as a daemon.
In the end I downloaded the latest version of the jenkins installer and re-installed to run manually and not as a daemon, so it runs as me instead of some weird flavour of root, and the problem disappeared.