Constructor Detail

• SshjTool

  public SshjTool(java.util.Map<java.lang.String,?> map)

Method Detail

• builder

  public static SshjTool.SshjToolBuilder builder()

• connect

  public void connect()

  Specified by:

  connect in interface SshTool

• connect

  @Deprecated
  public void connect(int maxAttempts)

  Deprecated. 

  Specified by:

  connect in interface SshTool

• disconnect

  public void disconnect()

  Specified by:

  disconnect in interface SshTool

• isConnected

  public boolean isConnected()

  Specified by:

  isConnected in interface SshTool

• copyToServer

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

  Specified by:

  copyToServer in interface SshTool

  See Also:

  SshTool.copyToServer(Map, File, String)

• copyToServer

  public int copyToServer(java.util.Map<java.lang.String,?> props,
                 java.io.InputStream contents,
                 java.lang.String pathAndFileOnRemoteServer)

  Description copied from interface: SshTool
  Closes the given input stream before returning. Consider using KnownSizeInputStream for efficiency when the size of the stream is known.

  Specified by:

  copyToServer in interface SshTool

  See Also:

  SshTool.copyToServer(Map, File, String)

• copyToServer

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

  Description copied from interface: SshTool
  Copies the file to the server at the given path. If path is null, empty, '.', '..', or ends with '/' then file name is used.

  The file will not preserve the permission of last _access_ date. Optional properties are:

  • 'permissions' (e.g. "0644") - see SshTool.PROP_PERMISSIONS
  • 'lastModificationDate' see SshTool.PROP_LAST_MODIFICATION_DATE; not supported by all SshTool implementations
  • 'lastAccessDate' see SshTool.PROP_LAST_ACCESS_DATE; not supported by all SshTool implementations

  Specified by:

  copyToServer in interface SshTool

  Returns:

  exit code (not supported by all SshTool implementations, usually throwing on error; sometimes possibly returning 0 even on error (?) )

• copyFromServer

  public int copyFromServer(java.util.Map<java.lang.String,?> props,
                   java.lang.String pathAndFileOnRemoteServer,
                   java.io.File localFile)

  Description copied from interface: SshTool
  Copies the file from the server at the given path.

  Specified by:

  copyFromServer in interface SshTool

  Returns:

  exit code (not supported by all SshTool implementations, usually throwing on error; sometimes possibly returning 0 even on error (?) )

• execScript

  public int execScript(java.util.Map<java.lang.String,?> props,
               java.util.List<java.lang.String> commands,
               java.util.Map<java.lang.String,?> 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! Another consideration is long-running scripts. On some clouds when executing a script that takes several minutes, we have seen it fail with -1 (e.g. 1 in 20 times). This suggests the ssh connection is being dropped. To avoid this problem, we can execute the script asynchronously, writing to files the stdout/stderr/pid/exitStatus. We then periodically poll to retrieve the contents of these files. Use ShellTool.PROP_EXEC_ASYNC to force this mode of execution.

  Specified by:

  execScript in interface ShellTool

  Specified by:

  execScript in interface SshTool

  Returns:

  exit status of script

  See Also:

  #execScript(Map, List, Map)}

• execShellDirect

  public int execShellDirect(java.util.Map<java.lang.String,?> props,
                    java.util.List<java.lang.String> commands,
                    java.util.Map<java.lang.String,?> env)

• execCommands

  public int execCommands(java.util.Map<java.lang.String,?> props,
                 java.util.List<java.lang.String> commands,
                 java.util.Map<java.lang.String,?> env)

  Description copied from interface: ShellTool
  Executes the set of commands using ssh exec. This is generally more efficient than ssh shell mode (cf ShellTool.execScript(Map, List, Map)), but is not suitable if you need env values which are only set on a fully-fledged shell, or if you want the entire block executed with root permission. Common optional properties (which also apply to ShellTool.execScript(Map, List, Map)) are:

  • ShellTool.PROP_OUT_STREAM
  • ShellTool.PROP_ERR_STREAM
  • ShellTool.PROP_SEPARATOR (for some modes)
  • ShellTool.PROP_NO_EXTRA_OUTPUT (often there is no extra output here)

  Note that ShellTool.PROP_RUN_AS_ROOT is not typically supported here. Prefer ShellTool.execScript(Map, List, Map)).

  Specified by:

  execCommands in interface ShellTool

  Specified by:

  execCommands in interface SshTool

  Returns:

  exit status of commands

  See Also:

  #execCommands(Map, List, Map)}