This recipe centers on using the SSH plugin. With this plugin, you are able to connect to appliances (think managed routers, switches, and so on...) or a Linux- or Solaris-based system, run programs, or transfer files.
We need to be able to create a new workflow. We also need a Linux or Solaris system that we can access via SSH (for example, as root). If you don't have a Linux system handy, you can use the Orchestrator appliance itself.
For the SCP example, you need to allow Orchestrator access to its local filesystem, or use the default /var/run/vco directory. Refer to the Configuring access to the local filesystem recipe in Chapter 2, Optimizing Orchestrator Configuration.
If you want to connect to the appliance itself (127.0.0.1) you need to enable SSH access as shown in the Tuning the appliance recipe in Chapter 2, Optimizing Orchestrator Configuration.
We split this recipe into three parts: SSH access, SSL key access, and SCP usage.
You will find a very good, while rather chatty (logs), SSH workflow in Library | SSH | Run SSH command. However, we will create a new short version to showcase SSH:
- Create a new workflow and create the following variables:
Name
Type
Place
Usage
HostString
IN
The IP or FQDN of the host we want to connect to.
UserString
IN
The username to connect to the host.
PasswordSecureString
IN
The password of the user to connect to the host.
CommandString
IN
The command we want to run on the host.
OutputString
OUT
The result of the command we run.
exitcodeNumber
OUT
The exit code
0 = OK.ErrorString
OUT
The error message encountered.
- Add a scriptable task to the schema and enter the following script:
// Open a new SSH session with password var mySSHSession = new SSHSession(host , user); mySSHSession.connectWithPassword(password); //execute the SSH command mySSHSession.executeCommand(command , true); // prepare output output=mySSHSession.output; exitcode=mySSHSession.exitCode; error=mySSHSession.error; //disconnect the SSH session mySSHSession.disconnect(); - Save and close the workflow.
When running this workflow, you will have to supply a command string. The string can be a single command or a string of commands the Linux system can utilize. A command you can try is date.
In the previous example, we used password authentication to log in to the Linux host system. We can use SSL keys to allow automatic login without using a password, which is the method commonly used for automation purposes.
To enable SSL authentication, first we need an SSL key, and we need to store it on the target Linux system. We will use the existing workflows to accomplish this:
- Start the workflow by navigating to Library | SSH | Generate key pair.
- Use the default setting and don't enter a password. Basically, just click on Submit.
- Next, we need to register the SSL key on the host with the user we will use for the connection. To do this, we will use the existing workflow by navigating to Library | SSH | Register vCO public key on host. This workflow will add
vco-key.pubonto the file/root/.ssh/authorized_keys. - Start the workflow, enter the hostname of the target server as well as the credentials of the user, and click on Submit.
- The SSL pairing is now done. Let's try it out. Create a duplicate (or change the original) of the workflow you have created in the first section of this recipe.
- Replace the
mySSHSession.connectWithPassword(Password);line withmySSHSession.connectWithIdentity("../conf/vco_key" , "");. The shorter path works as Orchestrator's working directory is theapp-serverdirectory. - Remove the password in-parameter from the workflow.
- Run the workflow. You won't need a password any longer.
SCP stands for Secure CoPy and allows you to transfer files using an SSH encryption tunnel. However, before we can copy anything from or to the Orchestrator server, we need to have a directory that Orchestrator has access to (see the Configuring access to the local filesystem recipe in Chapter 2, Optimizing Orchestrator Configuration. You can also use the default directory, /var/run/vco.
- Make a copy of one of the SSH workflows: either the password or the SSL one.
- Remove the command in-parameter and add the following in-parameter:
Name
Type
Place
Usage
filenameString
IN
The name of the file.
localDirString
IN
The directory on the Orchestrator server.
remoteDirString
IN
The directory on the remote host.
- Replace the
mySSHSession.executeCommand(Command , true);line with one of the following, depending on whether you want to send or receive a file:Upload
mySSHSession.putFile(localDir+file , remoteDir);Download
mySSHSession.getFile(remoteDir+file , localDir); - Save and run the workflow.
Using SSH together with Orchestrator generates a very powerful team. You can use SSH to access an existing Linux system, configure it, or to connect to a Linux-based management system, such as a Red Hat satellite server.
But, even more powerfully, you can connect to the Orchestrator appliance itself. If you generate a SSL key and register it on 127.0.0.1 (Orchestrator itself), you can run commands as root, such as mounting a NFS or SMB directory. Please be aware that opening SSH for Orchestrator may be considered a security risk.
SCP can be used in conjunction with Orchestrator resources to upload and download files or to transfer any other files between Orchestrator and a target system. Please note that you can also transfer files from one remote system to another using Orchestrator as a temporary storage between transfers.
- Refer to the Configuring access to the local filesystem recipe in Chapter 2, Optimizing Orchestrator Configuration.
- Refer to the File operations recipe in this chapter.
The example workflows are:
09.04.1 SSH (short with password)09.04.2 SSH (short with SSL Key)09.04.3 SCPput09.04.4 SCPget02.01 Tuning the Appliance