This short video shows how you can run dynamic commands against a UNIX or Linux server, directly from your Symantec Workflow process. The commands are run using the SSH protocol (via the command line plink.exe from Quest), and so all communications between the Workflow and UNIX server are secure. The video walks you through a simple example to run a UNIX command on the target server, illustrating the flexibility of Symantec Workflow to interact with even non-Windows environments.
UPDATE: The video was updated to demonstrate how to bring standard result and error information from the UNIX command back into your Workflow process. For example, if you run a command to list all of the folders in a directory, this video shows how to capture the result in your Workflow process. It also shows which version of plink is needed to accomplish this, and exactly how to install it. You can download the correct version of plink from here: http://rc.quest.com/downloads.php?release=Quest-PuTTY-0.60_q1
Keywords - PuTTY, plink.exe, form builder, project, theme, label, text box, password field, merge text, command line parameters, standard input, standard output, standard error, execute process and wait, create no window, MultilineTextBox, ascii merge label, font color, debugger, credentials, publish IIS, application pool, virtual directory
00:15:24
HI All,
We have created linux shell scripts in our enviroment , how do we schedule those shell scripts from altiris workflow designer(run shell scripts).
Thanks
Alt
I have now replaced the previous video with a newly recorded one. The main difference is the new video shows how to use the newer version of plink.exe to return data and error information back into your Workflow process. Also in the newer version I am taking in all of the information in form builder fields, whereas in the prior project I did it all with project properties. I thought that doing it in form builder fields would nicely simulate a custom-made console for running UNIX commands on remote servers/VMs.
One interesting application for this would be to make a "restricted UNIX console" that you could expose to only certain server admins in your organization. You could have the console show a dropdown list of UNIX servers that can be acted against, and a dropdown list of specific actions that you want to allow someone to do from this console (e.g. shutdown, reboot, etc.) You could even hard-code the server credentials into the Workflow, and then lock down the published Workflow so that only certain users could use it (could be restricted at the IIS level to individuals in certain AD groups). This would allow the people you specify to run certain commands on certain servers, without you have to give those individuals the credentials to do everything on that server.
Just an idea...obviously with Workflow the possibilities are endless. Thanks again for your feedback.
Thanks for your feedback.
I have now tried the new plink version and it works perfect. It would be great though if the Workflow Solution could have a built in Shell Command component but in the meanwhile this solution will do the trick.
Looking forward to see an upgraded video.
Thank you for bringing this to my attention, as obviously getting "output" back from the UNIX command line call is necessary in many instances.
Normally the "standard output" would automatically come back into Workflow when you checkmark the Standard Output and Standard Error checkboxes in the Execute Process and Wait component. But with some research, I've found that there is a known bug when calling that version of plink from an application (like Workflow, SQL, .NET, etc.) that keeps this standard output from getting reported back to the calling application. Here is the plink bug report:
http://www.chiark.greenend.org.uk/~sgtatham/putty/wishlist/win-plink-stdin-handle-invalid.html
With some searching, I was able to find a newer version of plink which allows for an easy work-around. You can download the newer version from here:
http://rc.quest.com/downloads.php?release=Quest-PuTTY-0.60_q1
Download the Win32 MSI, run it, and then copy plink.exe from c:\program files\Quest Software\PuTTy to c:\SSH (or basically just make sure this newer version of plink is the one that Workflow is calling from your Execute Process and Wait component).
This newer version introduces a command line parameter called -no_in, which tells plink not to expect any standard input. This gets around the bug that was reporting back to Workflow the error message, "Unable to read from standard input: The handle is invalid."
Here are two parameter sets that I was able to get working in Workflow with this new switch:
Make a new directory
-ssh [[ProjectProperties].ServerIP] -l [[ProjectProperties].ServerUsername] -pw [[ProjectProperties].ServerPwd] -no_in mkdir [NewDirName]
List the contents of the home directory
-ssh [[ProjectProperties].ServerIP] -l [[ProjectProperties].ServerUsername] -pw [[ProjectProperties].ServerPwd] -no_in ls ~
In the case of the 2nd example, your Standard Output variable will then be a text variable telling you all of the items in that directory.
I'll eventually re-record the video to take into account the newer version of plink, and to spend a little bit of time talking about the standard output/error messages.
Hi,
Great guide.
I have a question though, if I run a command via plink/SSH according to your description above how can I catch the actual output from that command and store in in a Variable to be presented on a eg. webpage.
I have tried enabling the standarad ouitput and directing this to a variable but with no luck. Do you have any ideas on how to acheive this?
BR /// Per-Erik