Workflow (iOS): Server Commands

It’s amazing how many computers we all work with these days. Our phones, our tablets, work computers, personal computers, remote servers, Raspberry Pis; the list goes on. I frequently find myself wanting to action things on a computer other than the one in front of me and I now have another tool in my arsenal to do this … the iOS app Workflow.

Making use of SSH

The premise for carrying out these commands is that Workflow offers an SSH (secure shell) action which allows you to connect to a server running a secure shell service. SSH is a standard offering on *nix based machines (including Mac running OS X) and you can even have a choice of SSH servers for Windows.

Building Functionality Outside of Workflow

Whilst it is relatively straight forward to set-up a workflow to connect to an SSH service and execute a set of commands I wanted to find a more robust way of doing it. Entering all of the details on an iOS device (even an iPad) is a bit tedious with the Workflow app. Even with version 1.1 there are still number of interface bugs that are creeping in. Also what if the address of a server changes and I have a dozen commands I might run on it? That’s a lot of workflows to update. As a result I opted to build a single more complex workflow but also to drive it from files in Dropbox that I could update on pretty much any device in a simple text editor of my choice and have it be available on every Workflow capable device I have. Far better in my opinion.

The Files

The first file the workflow needs is one to identify all of the servers you might connect to. The details for each server are stored on three lines. The first line always begins with a hash (“#”), followed by the memorable name you want to use for the particular remote computer.

The second line contains the address of the computer. This could be the IP address of the computer or the domain name for it. It optionally includes the port to connect on for SSH. The port is specified by appending a “:” followed by the port number. If no port is specified, the workflow will assume that the standard SSH port number of 22 should be used.

The third line specifies the user ID that the SSH should connect with. Note that the file does not contain any passwords. In my opinion storing passwords in Workflow and Dropbox is not a safe thing to do and whilst you could modify the script to do this I’d heartily recommend against it. Maybe one day we’ll get 1Password or LastPass integration in Workflow and then we’d be on much safer ground.

Here’s what an example file with a couple of servers in might look like…

#Home Media Server
server1.atmyhome.org
homeuserid
#Work Build Server
builder.atmywork.com:8008
myworkid001

In the workflow the file name is specified as being /Workflow/wf_servcmd_servers.txt (this is based on the root Dropbox folder), but you could of course rename that to anything you like and move it to any Dropbox folder you like - you just need to update the Workflow. One thing I would point out is that as of version 1.1, Workflow only seems to reliably read text from TXT files, so stick to using that file extension for now.

The second file contains a list of names for command scripts. Each name is held on a single line in the file. The sorts of commands you might want to use could vary by machine and by user, but here’s some ideas of the sorts of things I use on the various computers I connect to.

• Get uptime.
• Get free drive space.
• List running processes.
• Reboot.
• Shutdown.
• Sleep.
• Kill process.
• Trigger a script.

In the workflow these commands are stored in the file /Workflow/wf_servcmd_commands.txt. The same provisos about renaming and moving apply to this as the did the previous file.

Lastly each of these commands needs the actual commands to execute. In effect their own shell script. The Workflow looks in the /Workflow directory for wf_servcmd_cmd_{Command Name}.txt where {Command Name} is the name from the second file. So if for example you had a command called “Reboot” in the second file, you would need a file called /Workflow/wf_servcmd_cmd_Reboot.txt. Whilst I would prefer to have them as .sh files this is where I discovered that Workflow does not currently ‘like’ reading the text out of .sh files.

What the Workflow Does

When run the workflow reads in the servers file and uses some regular expression matching to produce a list of servers (i.e. the lines with beginning with hashes with the hashes stripped off). The user is then presented with these in a list and can select one.

Once the server has been selected the workflow works out which set of settings to look at and then takes note of the computer’s address, port number (defaulting to 22 if not explicitly specified) and the user ID to use.

Next the workflow uses the second file (of commands) to generate a list of commands the user can select a command from. One addition it makes however is to add a custom command option at the top of the list. If the user selects the custom command option they are given a one line prompt in which to enter the details of what they wish to run. If the user selects one of the commands loaded in from file, the corresponding file is read in to get the set of commands to run.

Next the workflow asks the user to enter a password. This entry does not have any password masking. You see the actual characters as you type them in and they do not change to asterisks or other nondescript characters. So just be careful no one is looking over your shoulder when you enter one … which of course you should be doing anyway.

The SSH action is then called with the computer address, port, user ID, password and set of commands. Once completed the results are returned to Workflow. At this point you should be able to just display the results in Quick Look (which gives you useful sharing options if you want to take those results and do something other than just view them). However I think there’s still a bug in this in version 1.1 as it worked inconsistently for me. However I found that assigning the results to a variable and then displaying that variable with Quick Look worked much more reliably.

Wrap-up & Download

That’s what my workflow is for, how it works and some reasons for why I’ve built it the way I have. Hopefully you might find it or some of the techniques it uses useful.

If you are on an iOS device with the Workflow app installed, you can tap here to install the Server Command Workflow, but do remember that you will need to set-up the files in Dropbox for it to work. But of course from then on all you have to do is to maintain the files rather than a set of workflows.