brooklyn.util.internal.ssh.sshj
[Java] Class SshjTool

java.lang.Object
  brooklyn.util.internal.ssh.ShellAbstractTool
      brooklyn.util.internal.ssh.SshAbstractTool
          brooklyn.util.internal.ssh.sshj.SshjTool

All Implemented Interfaces:

SshTool

public class SshjTool
extends SshAbstractTool

For ssh and scp-style commands, using the sshj library.

The implementation is based on a combination of the existing brooklyn SshJschTool, and the jclouds SshjSshClient.

Not thread-safe. Use a different SshjTool for each concurrent thread. If passing from one thread to another, ensure code goes through a synchronized block.

backoffLimitedRetryHandler

protected final BackoffLimitedRetryHandler backoffLimitedRetryHandler

sshTries

protected final int sshTries

sshTriesTimeout

protected final int sshTriesTimeout

SshjTool

public java.lang.Object SshjTool(java.util.Map map)

SshjTool

protected java.lang.Object SshjTool(SshjTool.Builder builder)

acquire

protected java.lang.Object acquire(C connection)

allocatePTY

protected void allocatePTY(Session s)

backoffForAttempt

protected void backoffForAttempt(int retryAttempt, java.lang.String message)

builder

public static SshjTool.SshjToolBuilder builder()

checkConnected

protected void checkConnected()

connect

try {
public void connect()

connect

connect(); // FIXME Should callers instead configure sshTries? But that would apply to all ssh attempts
public void connect(int maxAttempts)

copyFromServer

Files.copy(new InputStreamSupplier(contents), localFile);
public int copyFromServer(java.util.Map props, java.lang.String pathAndFileOnRemoteServer, java.io.File localFile)

copyToServer

}
public int copyToServer(java.util.Map props, byte[] contents, java.lang.String pathAndFileOnRemoteServer)

copyToServer

*   1) to know the length of the InputStream to copy the file to perform copy; and
public int copyToServer(java.util.Map props, java.io.InputStream contents, java.lang.String pathAndFileOnRemoteServer)

copyToServer

}
public int copyToServer(java.util.Map props, java.io.File localFile, java.lang.String pathAndFileOnRemoteServer)

disconnect

try {
public void disconnect()

execCommands

OutputStream out = getOptionalVal(props, PROP_OUT_STREAM);
public int execCommands(java.util.Map props, java.util.List commands, java.util.Map env)

execScript

Boolean noExtraOutput = getOptionalVal(props, PROP_NO_EXTRA_OUTPUT);
public int execScript(java.util.Map props, java.util.List commands, java.util.Map env)

This creates a script containing the user's commands, copies it to the remote server, and executes the script. The script is then deleted.

Executing commands directly is fraught with dangers! Here are other options, and their problems:

• Use execCommands, rather than shell. The user's environment will not be setup normally (e.g. ~/.bash_profile will not have been sourced) so things like wget may not be on the PATH.
• Send the stream of commands to the shell. But characters being sent can be lost. Try the following (e.g. in an OS X terminal): - sleep 5 - Only the first 1024 characters appear. The rest are lost. If sending a stream of commands, you need to be careful not send the next (big) command while the previous one is still executing.
• Send a stream to the shell, but spot when the previous command has completed. e.g. by looking for the prompt (but what if the commands being executed change the prompt?) e.g. by putting every second command as "echo ", and waiting for the stdout. This gets fiddly...

So on balance, the script-based approach seems most reliable, even if there is an overhead of separate message(s) for copying the file!

execShellDirect

public int execShellDirect(java.util.Map props, java.util.List commands, java.util.Map env)

isConnected

}
public boolean isConnected()

newSessionAction

protected SshAction newSessionAction()

Brooklyn Multi-Cloud Application Management Platform
brooklyncentral.github.com. Apache License. © 2012.