Invoking Automator Workflows From The Command Line

There’s a great website at that provides a lot of information on using Automator to build automations for the Mac. When you build automations, you can run them by double-clicking on apps or workflows. You can also invoke them with the automator command.

The automator command can, surprisingly, be used to run automator workflows. I know, it’s crazy. Located at /usr/bin/automator the automator command can be used to fire up workflows. In its most basic incantation, you can invoke a workflow without much fuss. Here, I’ll use a workflow that just fires up a specific screensaver:

/usr/bin/automator ~/Desktop/screensaver.workflow

In addition, you can run workflows in verbose mode for simple troubleshooting using -v:

/usr/bin/automator ~/Desktop/screensaver.workflow

Which shows you each thing that happens in a step-by-step:

Starting Automator…
Start Screen Saver is running
Start Screen Saver is finished
The Automator workflow has completed.

You can also send input into a workflow using -I and you can use -D to set multiple variables with values, which I’ll cover in a later article.

Changes in Mountain Lion Server

Mountain Lion Server is now available on the OS X App Store and as with the last few updates there are some things missing that you might be expecting and depending on. First up, three major services are gone: Podcast Producer, RADIUS and dhcp. You can still do dhcp as you always did with OS X client as those features work on OS X Server, but the more granular controls available in OS X Server are now gone. The biggest impact of dhcp is probably in testing NetBoot services when there are network issues and you need to prove to network admins that it’s the network and not your server… I had written an article before about FTP still being in OS X Server from the command line, but now it’s back in the GUI, which should make many an administrator happy. NAT is also gone from the GUI, but natd and natutil are still available from the command line. Might as well just use the Sharing System Preference pane for such things though… Server Admin is now gone (long live Server Admin!) and Workgroup Manager is now a download to be performed and installed following installation. Support for Managed Preferences is gone, even though most manifests technically still work. Many services also got some pretty nice updates. These include:
  • Calendar – There are a few updates on the client side, but not on the server side. Most notably, the option to publish calendars is now gone. If you used that, it’s time to get used to manually exporting, copying to a share and then distributing links. This is going to likely cause more use of the Calendar server itself, to some degree. Also, it’s not iCal or iCal Server, it’s now Calendar and Calendar server. Seems to me that this isn’t obviously an Apple-centric naming structure as with most other things they do, but sometimes you’re gonna’ have that…
  • Contacts – Nope, it’s not called Address Book server, it’s the Contacts service. Same with the client side application.
  • DNS – DNS management is moved into the Server application. You can also now restrict who you do lookups for in the GUI. Under the hood very little changes.
  • File Sharing – Nothing really changes with file sharing, except the wiki integration described in the Wiki section in a little bit.
  • Firewall – The firewall option is gone, as is the ipfilter at the command line, but pf is easy to configure from the command line.
  • FTP – It’s a quick and easy single share solution from the GUI. Using the sharing command there’s still tons available to administrators.
  • Mail – Authentication mechanisms and domains are in the GUI, but very little changes otherwise.
  • Messages – The service name has changed from iChat to Messages in the GUI but is still jabber from the command line. The big change with this service is that the client side is now able to leverage iCloud to instant message mobile devices as well. Therefore, the text messaging component is client-side and has no impact on the jabber service itself.
  • NetInstall – The “NetInstall” service is NetBoot. It can host NetRestore or NetInstall images, but the heavy lifting for that stuff is done in System Image Utility. And the output of the SIU commands are now more scriptable through the automator command line interface. The NetInstall screen is now in Server app and is a good port from Server Admin in that it’s similar in look and feel to the NetBoot screen in Server Admin. A feature that isn’t in the GUI is diskless NetBoot, which is fine because I documented how to do it when I realized it would be an issue for a few customers.
  • Open Directory – Given that Server Admin is gone, something had to happen with Open Directory. The Open Directory screens have been moved to Server app where it’s fast to setup and tear down Open Directory. Open Directory based Users and Groups are also created through the Server App, although Workgroup Manager can be downloaded and used still. Immediately following upgrades, the add and remove users buttons are gone for previously stand-alone hosts. Also the Manage Network Accounts option is now gone from Server app, replaced with the traditional ON button supplied by Apple for other services.
  • Profile Manager – This deserves its own post, which is in the queue, but suffice it to say that while you can’t tell when looking in Server app, there are a number of upgrades to Profile Manager.
  • Software Update – Management of the service is moved from Server Admin to Server app. There are now fewer options in the GUI, but the same in the command line. Cascading is a little different.
  • Time Machine – Time Machine server is the same… The versions option from the Time Machine Server preference pane is gone and the layout is a little changed, but the server component is identical in functionality as well as look and feel.
  • VPN – Unless you add another supported VPN protocol there’s not much to do after fixing most issues in 10.7.4. Except fixing the last issue with search bases, seemingly resolved as it’s working for me pretty well.
  • Websites – There are more options in the GUI for new sites. The default site appears twice (once for 80 and once for 443), but there are more options, such as the Web App functionality that comes with a default Python “Hello World” app. Also the server is still called web from the serveradmin command line, but is now called Websites through the GUI.
  • Wiki – The wiki has themes again, although they’re just color schemes. And you can create your own custom banners and upload, which brings back two of the most common feature requests from people that hack the look and feel of the wiki in versions previous to Lion. But the most substantial aspect of the Wiki to change to me is the document management options, available to users in WebDAV or through the portal. This allows for a very mobile-friendly file management tool. Blogs and wikis for the most part stay the same and have a very clean upgrade process from Lion. The command line tools also feature some new options for indexing, etc., which many will find helpful.
  • Xsan – cvadmin, cvlabel, cvversions, etc are now stored in /System/Library/Filesystems/acfs.fs/Contents/bin/ and Xsan has its own entry in the Server app. Despite hearing people question its future, I’ve never seen as many questions flying around about how to do things with Xsan than I do now. Storage sales are up, monkey chatter on the web is up, deployments are being booked and Xsan looks here to stay. The Server app only really shows you a status of things, but the Xsan Admin app is now embedded in the Server app and available through the Server app Tools directory.
Configuring Websites in Server app
The Alerts options are much more robust in Mountain Lion than they were previously. You  can now get alerts on a myriad of things, incuding certs, disks, space, storage quotas, virus detection, network changes and software updates.
Configuring Alerts in Mountain Lion Server
The Server commands also moved and in fact the whole file and folder structure mostly fit nicely inside of the Server app. There are certain things that haven’t been dealt with in this regard such as NetBoot’s library, but for the most part Apple is getting Server to the point where it’s very self-contained. The ramification of which is that upgrades for future releases (and from Lion to Mountain Lion for that matter) are much simpler. Simply downloading a new version informs administrators that the app has been replaced and is good to go, service data in tact. In real world, this has been a little hit or miss but should prove to make our lives much easier in the future. Reducing scope, aligning with better development practices and all the work to merge all of the remaining services into Server app are huge undertakings. I would fully expect no further support or updates to Workgroup Manager, no more testing of managed preferences in deference to profiles and a few other culture shifts that still need to shake themselves out. Most of us are going to seem underwhelmed (if that’s a word, no it’s not ’cause I looked it up -> awesome video below --> ’cause affection has 2 fs, especially when you’re dealin’ with me). But here’s the thing, with an incremental update, you’re not going to get massive changes. Instead we will get slow and steady updates hopefully continuing to build faster towards a better end goal. What’s important is that the foundation is actually better now, given changes to other parts of OS X and so Server is likely now better positioned than ever for great new features in subsequent releases.
Oh, and did I forget to mention that Xgrid is gone. I guess no one really noticed anyway…

Easily Automating and Simulating Web Traffic

There are a variety of applications out there that will simulate web traffic. But there’s nothing like the idea of true traffic. Load a page, click on a link, wait for the next page to load, click on another link, etc. Traditional load simulators simply are not real world enough in most cases. There are a variety of more real world simulators but they are typically cost prohibitive for the use I recently encountered a need for. So I started looking at using Automator. In its simplest form, you can just fire up Automator, click on the Record button and then perform an action. However, this is going to perform the same action over and over and over. Let’s say you have a MySQL database and you want to loop through calling a lot of records from the web site. Well, the Record button in Automator is actually going to look for the same pattern. Therefore, you could manually go through all the records while recording. But this is going to be a little time intensive and any misclicks will get replicated into your Automator workflow. Especially if, for each record, you have to click on a button to open it up, which is pretty typical. Enter Ottomate. Ottomate is a collection of six Automator actions that will perform GUI-level actions without using the record button. Therefore, you can build a button on a page and tell Ottomate to click it. Then save that and you can call it up from a shell script. So let’s say we have an Automator action called clickbutton that we built using Ottomate. Well, we can call it using the following command: automator clickscript.workflow This is where a quick and easy while loop can come into play. Let’s say that one record for a standard WordPress deployment loads in a browser as:
Hacking at Random 2009 Conference
And another loads in the browser as: The page variable (p=) is increasing one per new article (boy that sure is a lot of articles btw). This makes it pretty simple. We’re going to create a script called In the script we’re going to use variable x, which will be that page variable that we’re going to loop through. Because the shell isn’t going to be a fan of the “?” character we’re then going to go ahead and backspace it out by putting a in front of it. So we can actually open the next link in descending order in Safari using the following command from the shell: open At this point we could put the follwoing into the shell script and have it open the site and click on the desired link: open automator clickscript.workflow We could paste that in over and over and over, manually changing the page (p=). Or we could just loop it, converting the page to a variable. So now we’re going to variabalize the page by converting the number to a variable called x: open$x This would result in a little shell script like so: x=1 open$x automator clickscript.workflow Next, you put a quick while loop around it. Here, we will increase the x variable by one per iteration until it reaches 3086:
x=1 while [ $x -lt 3086 ] do open$x automator clickscript.workflow x=`expr $x + 1` done
Now, a couple of things about this kind of thing. First, the site needs to complete loading before Automator can click on the link. So in your Automator workflow you can assign time out variables. But you can also use the sleep command in your shell script. Either way, when you’re simulating real world testing, you can look through your web logs to determine the average amount of time someone spends on one site before moving over to the next page for a good simulation number. Additionally, Safari is simply going to keep opening new pages. While you might be able to open a few hundred you’re likely going to need to occasionally close the window, or close Safari as an application. If you are just closing the Safari window, you can place a Command-W into your workflow. If you want to close Safari entirely you would use the following command in your script (yes, it’s case sensitive): killall Safari Also, don’t be afraid of getting a little more complicated.  You can use nested loops and random number generators to augment the sleep times and order that sites load.  This way you can be a little more human-like and a little less likely to have cached data or identical patterns changing your findings.  You will also want to run the scripts from a number of hosts in order to determine the load placed by concurrent computers. In a way this is how you would create your own little Mac OS X based botnet (perhaps in a future article I’ll explain how to deploy the botnet payload). This script runs in the foreground. Anything you do with Automator is going to. Therefore, all of the hosts running it will display the pages on the screen and therefore pretty much not be useable for other tasks while the script is running. According to the type of site you’re looking at you could ditch using Automator and use Lynx, which is easily installed using MacPorts (or from source) if you wanted it to run in the background, although clicking buttons is a little more complicated to script if the browser cannot interpret certain types of said buttons… 😉 This article brings up one of the reasons that Captcha and other anti-spam techniques are such good ideas once you go live with a site: it’s just too easy to write a bot these days (and higher unemployment rates mean more people with spare time to do so). The text in this article took way longer to write than the script. I’m not really that great at scripting, but you could easily do something like perform a Google search of all MediaWiki sites, go to a specified link on the site and edit that page with garbage (oddly enough, really common). Same rings true with advertisements for all sorts of scams in your forums and of course click fraud. Either way, this walkthrough is meant for testing your own site for load and maybe showing how easy it is to automate web tasks, not to propagate FUD or show how to engage in click fraud or create a malicious botnet. Have fun with it.