I can run tests on remote machine as pybot test.robot. Now I want to ssh into remote machine from local machine and run above command. I can ssh into remote machine as ssh user#10.0.0.200 ls and see files.
But when I try to run command ssh user#10.0.0.200 pybot ~/dir/test.robot I get error bash: pybot: command not found
pybot is installed on remote machine I can run tests successfully if I run them directly from remote machine.
Try to export your PATH and LD_LIBRARY_PATH at the top of your .bashrc config file. For instance:
export PATH=path-to-the-pybot-directory:$PATH
export LD_LIBRARY_PATH=path-to-lib-directory-for-pybot:$LD_LIBRARY_PATH
You may use ldd pybot to locate where libraries requiered by pybot are installed.
Related
I've set up git on a windows machine with a working PATH environment variable. From both the command line and Cygwin terminal I can use
git status
I've also installed ssh as a service using Cygwin and sshd using the guide here: https://docs.oracle.com/cd/E23562_01/doc.1035/e14501/install.htm. I can successfully ssh to the machine using Putty, but when I try to run git commands, it seems the PATH I've set up doesn't work. Instead I get:
-bash: git: command not found
Is there any way to get this working with a PATH variable? This is going to be used by Jenkins so I have limited control over how the git commands are called.
I guess Cygwin or the ssh client maintains its own PATH so I just needed to add my git.exe path in my ssh session in this way:
export "PATH=$PATH:/cygdrive/c/Program Files/Git/cmd"
To install a Topshelf service, I normally simply do:
myservice.exe install
If I want to install the service on a remote machine, I can't just do:
\\server\c$\myservice.exe install
...because it would still install the service on my local machine.
How can I install a Topshelf service on a remote machine without having to log onto that machine and run the executable directly from there?
Microsoft provides a tool called PsExec. It has a whole bunch of feature one of which is to run command on remote machines.
Edit:
File Deployment: To get the files to the target machine you would have to do some sort of copy, whether that be manually or with some sort of script.
Install: Install psexec on your machine, it may need to be installed on the remote machine but I do not remember. Open command prompt on your machine, type
psexec \\remotecomputername -u admin#domain.com -p p#$$w0rd "c:\applications\myprogram\myprogram.bat"
In this case remotecomputername is the name of the computer your are targeting. If you need to login as another user, use the -u and -p switches in the example and finally, put the path to the exe "c:\applications..."
I installed docker on windows 10 with DockerToolbox (1.11.2) executable. However, I can't evaluate my environment using docker-machine env default directly.
Instead, only when I use this command
C:\Program Files\Docker Toolbox\docker-machine.exe env default *
Can I evaluate the environment?
When I want to check help information, I also have to run
C:\Program Files\Docker Toolbox\docker.exe run --help
In their official tutorial: Install Docker for Windows, they mentioned that after installation, I could use docker,docker-machine,docker-compose directly.
In fact, I found this problem when I met this error:
C:\Program Files\Docker Toolbox\docker.exe: An error occurred trying
to connect: Post https://192.168.99.103:2376/v1.23/containers/create:
dial tcp 192.168.99.103:2376: connectex: A connection attempt failed
because the connected party did not properly respond after a period of
time, or established connection failed because connected host has
failed to respond..
And I solved it by restart my machine, and evaluate it again with the full path of the executable.
Some thing interesting is that docker-machine create -d virtualbox default worked for me while docker stop $(docker ps -a -q) failed.
I can just add those executable to environment variable on Windows.
But I want to what's happaning to that installation which caused this problem.
Screenshot of my installation console:
First, you don't have to use docker-machine env at all: you can simply ssh to your machine, and make your docker commands from there.
docker-machine ssh default
Second, try and use those commands from a regular CMD session (you don't need a bash).
As documented in docker-machine env:
$ docker-machine.exe env --shell cmd dev
set DOCKER_TLS_VERIFY=1
set DOCKER_HOST=tcp://192.168.99.101:2376
set DOCKER_CERT_PATH=C:\Users\captain\.docker\machine\machines\dev
set DOCKER_MACHINE_NAME=dev
# Run this command to configure your shell: copy and paste the above values into your command prompt
(Replace "dev" by the name of your machine, like "default" for instance)
I'm trying to use vagrant ssh in windows console, but it don't work.
Vagrant is correctly installed, and i've installed also Git for windows.
Also, correct path is installed in the system environment, using
setx PATH "%PATH%;C:\Program Files (x86)\Git\bin"
and i can see the path add-on in the console via path and also in the windows system environment.
But when i'm use vagrant ssh in the windows console it give me the usual error:
ssh executable not found in any directories in the %PATH% variable.
Is an SSH client installed? Try installing Cygwin, MinGW or Git, all
of which contain an SSH client. Or use your favorite SSH client with
the following authentication information shown below:
Host: 127.0.0.1 Port: 2222 Username: vagrant Private key:
C:/vagtest/.vagrant/machines/default/virtualbox/private_key
If i digit path in console, i have the correct path with git location, but it is useless.
If i digit
set PATH=%PATH%;C:\C:\Program Files (x86)\Git\bin
the command
vagrant ssh run, but obviusly when i close the console and reopen it, it don't run more.
I really don't understand what happen.
try >vagrant ssh from Git Bash window
To run ssh on windows, you need to download msysgit from msysgit project page and copy the ssh.exe file from msysgit/bin folder to C:\Program Files\Git\bin.
Now try again vagrant ssh from cmd, git cmd or git bash.
Note: if you prefer, you can include the msysgit/bin to path, or copy all the content of msysgit/bin to git/bin.
I'm new to Docker, using Boot2Docker on OSX. After booting it, this message is given:
To connect the Docker client to the Docker daemon, please set
export DOCKER_HOST=tcp://192.168.59.103:2375
Yet even without it, basic Docker commands (eg, docker run hello-world) work fine.
The install instructions aren't very informative:
Note: If you see a message in the terminal that looks something like this:
To connect the Docker client to the Docker daemon, please set:
export DOCKER_HOST=tcp://192.168.59.103:2375
you can safely set the evironment variable as instructed.
Knowing that it's "safe" doesn't say why it's useful.
What I'm not clear on:
What is the docker "client"?
What is the docker "daemon"?
What is the docker "host"? (The Boot2Docker VM itself?)
Ok, I think I got it.
The client is the docker command installed into OS X.
The host is the Boot2Docker VM.
The daemon is a background service running inside Boot2Docker.
This variable tells the client how to connect to the daemon.
When starting Boot2Docker, the terminal window that pops up already has DOCKER_HOST set, so that's why docker commands work. However, to run Docker commands in other terminal windows, you need to set this variable in those windows.
Failing to set it gives a message like this:
$ docker run hello-world
2014/08/11 11:41:42 Post http:///var/run/docker.sock/v1.13/containers/create:
dial unix /var/run/docker.sock: no such file or directory
One way to fix that would be to simply do this:
$ export DOCKER_HOST=tcp://192.168.59.103:2375
But, as pointed out by others, it's better to do this:
$ $(boot2docker shellinit)
$ docker run hello-world
Hello from Docker. [...]
To spell out this possibly non-intuitive Bash command, running boot2docker shellinit returns a set of Bash commands that set environment variables:
export DOCKER_HOST=tcp://192.168.59.103:2376
export DOCKER_CERT_PATH=/Users/ddavison/.boot2docker/certs/boot2docker-vm
export DOCKER_TLS_VERIFY=1
Hence running $(boot2docker shellinit) generates those commands, and then runs them.
Upon investigation, it's also worth noting that when you want to start using docker in a new terminal window, the correct command is:
$(boot2docker shellinit)
I had tested these commands:
>> docker info
Get http:///var/run/docker.sock/v1.15/info: dial unix /var/run/docker.sock: no such file or directory
>> boot2docker shellinit
Writing /Users/ddavison/.boot2docker/certs/boot2docker-vm/ca.pem
Writing /Users/ddavison/.boot2docker/certs/boot2docker-vm/cert.pem
Writing /Users/ddavison/.boot2docker/certs/boot2docker-vm/key.pem
export DOCKER_HOST=tcp://192.168.59.103:2376
export DOCKER_CERT_PATH=/Users/ddavison/.boot2docker/certs/boot2docker-vm
export DOCKER_TLS_VERIFY=1
>> docker info
Get http:///var/run/docker.sock/v1.15/info: dial unix /var/run/docker.sock: no such file or directory
Notice that docker info returned that same error. however.. when using $(boot2docker shellinit)...
>> $(boot2docker init)
Writing /Users/ddavison/.boot2docker/certs/boot2docker-vm/ca.pem
Writing /Users/ddavison/.boot2docker/certs/boot2docker-vm/cert.pem
Writing /Users/ddavison/.boot2docker/certs/boot2docker-vm/key.pem
>> docker info
Containers: 3
...
It points to the docker host! I followed these steps:
$ boot2docker start
Waiting for VM and Docker daemon to start...
..............................
Started.
To connect the Docker client to the Docker daemon, please set:
export DOCKER_HOST=tcp://192.168.59.103:2375
$ export DOCKER_HOST=tcp://192.168.59.103:2375
$ docker run ubuntu:14.04 /bin/echo 'Hello world'
Unable to find image 'ubuntu:14.04' locally
Pulling repository ubuntu
9cbaf023786c: Download complete
511136ea3c5a: Download complete
97fd97495e49: Download complete
2dcbbf65536c: Download complete
6a459d727ebb: Download complete
8f321fc43180: Download complete
03db2b23cf03: Download complete
Hello world
See:
http://docs.docker.com/userguide/dockerizing/