Though that description applies to the Internet connectivity, as well :-) Truth be told, most hotel WiFi is pretty bad. But nestle a lovely little old hotel on a forgotten little Viking/Celtic island and you will really see the problem exacerbated.

I worked around most of my downstream issues with a couple of new extensions to the run-oneproject, and I'm delighted as always to share these with you in Ubuntu's package!

This is useful when downloading something, perhaps using wget --continue or rsync, over a crappy quaint hotel WiFi connection.

run-one-until-failureCOMMAND [ARGS]

This command operates exactly like run-one-constantly except that it respawns "COMMAND [ARGS]" until COMMAND exits with failure (ie, exits non-zero).

This is useful when you want to run something until something goes wrong.

I am occasionally asked about the difference between these tools and the nohup command...

First, the "one" part of run-one-constantly is important, in that it uses run-one to protect you from running more than one instances of the specified command. This is handy for something like an ssh tunnel, that you only really want/need one of.

I was also asked about the difference between these tools and upstart...

Upstart is Ubuntu's event driven replacement for sysvinit. It's typically used to start daemons and other scripts, utilities, and "jobs" at boot time. It has a really cool feature/command/option called respawn, which can be used to provide a very similar effect as run-one-constantly. In fact, I've used respawn in several of the upstart jobs I've written for the Ubuntu server, so I'm happy to credit upstart's respawn for the idea.

That said, I think the differences between upstart and run-one are certainly different enough to merit both tools, at least on my servers.

An upstart job is defined by its own script-like syntax. You can see many examples in Ubuntu's /etc/init/*.conf. On my system the average upstart job is 25 lines long. The run-one commands are simply prepended onto the beginning of any command line program and arguments you want to run. You can certainly use run-one and friends inside of a script, but they're typically used in an interactive shell command line.

An upstart job typically runs at boot time, or when "started" using the start command, and these start jobs located in the root-writable /etc/init/. Can a non-root user write their own upstart job, and start and stop it? Not that I can tell (and I'm happy to be corrected here)... Turns out I was wrong about that, per a set of recently added features to Upstart (thanks, James, and Stuart for pointing out!), non-root users can now write and run their own upstart jobs.. Still, any user on the system can launch run-one jobs, and their own command+arguments namespace is unique to them.

run-one is easily usable on systems that do not have upstart available; the only hard dependency is on the flock(1) utility.

UPDATE: I wrote this charm and blog post before I saw the unfortunate news that the UbuntuForums.org along with Apple's Developer websites had been very recently compromised and user database stolen. Given that such events have sadly become commonplace, the instructions below can actually be used by proactive administrators to identify and disable weak user passwords, expecting that the bad guys are already doing the same.

It's been about 2 years since I've written a Jujucharm. And even those that I wrote were not scale-out applications.

I've been back at Canonical for two weeks now, and I've been spending some time bringing myself up to speed on the cloud projects that form the basis for the Cloud Solution products, for which I'm responsible. First, I deployed MAAS, and then brought up a small Ubuntu OpenStack cluster. Finally, I decided to tackle Juju and rather than deploying one of the existing charms, I wanted to write my own.

Installing Juju

Juju was originally written in Python, but has since been ported to Golang over the last 2+ years. My previous experience was exclusively with the Python version of Juju, but all new development is now focused on the Golang version of Juju, also known as juju-core. So at this point, I decided to install juju-core from the 13.04 (raring) archive.

Using OpenStack (or even AWS for that matter) also requires defining a number of environment variables in an rc-file. Basically, you need to be able to launch instances using euca2ools or ec2-api-tools. That's outside of the scope of this post, and expected as a prerequisite.

Choosing a Charm-able Application

I have previously charmed two small (but useful!) webapps that I've written and continue to maintain -- Pictor and Musica. These are both standalone web applications that allow you to organize, serve, share, and stream your picture archive and music collection. But neither of these "scale out", really. They certainly could, perhaps, use a caching proxy on the front end, and shared storage on the back end. But, as I originally wrote them, they do not. Maybe I'll update that, but I don't know of anyone using either of those charms.

In any case, for this experiment, I wanted to write a charm that would "scale out", with Juju's add-unit command. I wanted to ensure that adding more units to a deployment would result in a bigger and better application.

For these reasons, I chose the program known as John-the-Ripper, or just john. You can trivially install it on any Ubuntu system, with:

sudo apt-get install john

John has been used by Linux system administrators for over a decade to test the quality of their user's passwords. A root user can view the hashes that protect user passwords in files like /etc/shadow or even application level password hashes in a database. Effectively, it can be used to "crack" weak passwords. There are almost certainly evil people using programs like john to do malicious things. But as long as the good guys have access to a program like john too, they can ensure that their own passwords are impossible to crack.

John can work in a number of different "modes". It can use a dictionary of words, and simply hash each of those words looking for a match. The john-data package ships a word list in /usr/share/john/password.lst that contains 3,000+ words. You can find much bigger wordlists online as well, such as this one, which contains over 2 million words.

John can also generate "twists" on these words according to some rules (like changing E's to 3's, and so on). And it can also work in a complete brute force mode, generating every possible password from various character sets. This, of course, will take exponentially longer run times, depending on the length of the password.

Fortunately, John can run in parallel, with as many workers as you have at your disposal. You can run multiple processes on the same system, or you can scale it out across many systems. There are many different approaches to parallelizing John, using OpenMP, MPI, and others.

I took a very simple approach, explained in the manpage and configuration file called "External". Basically, in the /etc/john/john.conf configuration file, you tell each node how many total nodes exist, and which particular node they are. Each node uses the same wordlist or sequential generation algorithm, and indexes these. The node modulates the current index by the total number of nodes, and tries the candidate passwords that match their own id. Dead simple :-) I like it.

# Trivial parallel processing example[List.External:Parallel]/* * This word filter makes John process some of the words only, for running * multiple instances on different CPUs. It can be used with any cracking * mode except for "single crack". Note: this is not a good solution, but * is just an example of what can be done with word filters. */int node, total; // This node's number, and node countint number; // Current word numbervoid init(){ node = 1; total = 2; // Node 1 of 2, change as appropriate number = node - 1; // Speedup the filter a bit}void filter(){ if (number++ % total) // Word for a different node? word = 0; // Yes, skip it}

This does, however, require some way of sharing the inputs, logs, and results across all nodes. Basically, I need a shared filesystem. The Juju charm collection has a number of shared filesystem charms already implemented. I chose to use NFS in my deployment, though I could have just as easily used Ceph, Hadoop, or others.

Writing a Charm

The official documentation on writing charms can be found here. That's certainly a good starting point, and I read all of that before I set out. I also spent considerable time in the #juju IRC channel on irc.freenode.net, talking to Jorge and Marco. Thanks, guys!

The base template of the charm is pretty simple. The convention is to create a charm directory like this, and put it under revision control.

mkdir -p precise/johnbzr init .

I first needed to create the metadata that will describe my charm to Juju. My charm is named john, which is an application known as "John the Ripper", which can test the quality of your passwords. I list myself as the maintainer. This charm requires a shared filesystem that implements the mount interface, as my charm will call some hooks that make use of that mount interface. Most importantly, this charm may have other peers, which I arbitrarily called workers. They have a dummy interface (not used) called john. Here's the metadata.yaml:

name: johnsummary: "john the ripper"description: | John the Ripper tests the quality of system passwordsmaintainer: "Dustin Kirkland"requires: shared-fs: interface: mountpeers: workers: interface: john

I also have one optional configuration parameter, called target_hashes. This configuration string will include the input data that john will work on, trying to break. This can be one to many different password hashes to crack. If this isn't specified, this charm actually generates some random ones, and then tries to break those. I thought that would be nice, so that it's immediately useful out of the box. Here's config.yaml:

Files: *Copyright: Copyright 2013, Dustin Kirkland , All Rights Reserved.License: GPL-3 This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version. . This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. . You should have received a copy of the GNU General Public License along with this program. If not, see .

README and revision are also required.

And the Magic -- Hooks!

The real magic happens in a set of very specifically named hooks. These are specially named executables, which can be written in any language. For my purposes, shell scripts are more than sufficient.

The Install Hook

The install hook is what is run at installation time on each worker node. I need to install the john and john-data packages, as well as the nfs-common client binaries. I also make use of the mkpasswd utility provided by the whois package. And I will also use the keep-one-running tool provided by the run-one package. Finally, I need to tweak the configuration file, /etc/john/john.conf, on each node, to use all of the CPU, save results every 10 seconds (instead of every 10 minutes), and to use the much bigger wordlist that we're going to fetch. Here's hooks/install:

The Start Hook

The start hook defines how to start this application. Ideally, the john package would provide an init script or upstart job that cleanly daemonizes its workers, but it currently doesn't. But for a poor-man's daemonizer, I love the keep-one-running utility (written by yours truly). I'm going to start two copies of john utility, one that runs in wordlist mode, trying every one of the 2 million words in my wordlist, as well as a second, which tries every combinations of characters in an incremental, brute force mode. These binaries are going to operate entirely in the shared /var/lib/john NFS mount point. Each copy on each worker node will need to have their own session file. Here's hooks/start:

The Stop Hook

The stop hook defines how to stop the application. Here, I'll need to kill the keep-one-running processes which wrap john, since we don't have an upstart job or init script. This is perhaps a little sloppy, but perfectly functional. Here's hooks/stop:

The Workers Relation Changed Hook

This hook defines the actions that need to be taken each time another john worker unit is added to the service. Basically, each worker needs to recount how many total workers there are (using the relation-list command), determine their own id (from $JUJU_UNIT_NAME), update their /etc/john/john.conf (using sed), and then restart their john worker processes. The last part is easy since we're using keep-one-running; we simply need to killalljohn processes, and keep-one-running will automatically respawn new processes that will read the updated configuration file. This is hooks/workers-relation-changed:

The Configuration Changed Hook

All john worker nodes will operate on a file in the shared filesystem called /var/lib/john/target_hashes. I'd like the administrator who deployed this service to be able to dynamically update that file and signal all of her worker nodes to restart their john processes. Here, I used the config-get juju command, and again restart by simply killing the john processes and letting keep-one-running sort out the restart. This is handled here in hooks/config-changed:

The Shared Filesystem Relation Changed Hook

By far, the most complicated logic is in hooks/shared-fs-relation-changed. There's quite a bit of work we need to here, as soon as we can be assured that this node has successfully mounted its shared filesystem. There's a bit of boilerplate mount work that I borrowed from the owncloud charm. Beyond that, there's a bit of john-specific work. I'm downloading the aforementioned larger wordlist. I install the target hash, if specified in the configuration; otherwise, we just generate 10 random target passwords to try and crack. We also symlink a bunch of john's runtime shared data into the NFS directory. For no good reason, john expects a bunch of stuff to be in the same directory. Of course, this code could really use some cleanup. Here it is again, non-perfect, but functional hooks/shared-fs-relation-changed:

Deploying the Service

If you're still with me, we're ready to deploy this service and try cracking some passwords! We need to bootstrap our environment, and deploy the stock nfs charm. Next, branch my charm's source code, and deploy it. I deployed it here across a whopping 18 units! I currently have a quota of 20 small instances I can run our private OpenStack. Two of those instances are used by the Juju bootstrap node and by the NFS server. So the other 18 will be NFS clients running john processes.

Within a few seconds, this 18-node cluster has cracked all 10 of the randomly chosen passwords from the dictionary. That's only mildly interesting, as my laptop can do the same in a few minutes, if the passwords are already in the wordlist. What's far more interesting is in randomly generating a password and passing that as a new configuration to our running cluster and letting it crack that instead.

Modifying the Configuration Target Hash

Let's generate a random password using apg. We'll then need to hash this and create a string in the form of username:pwhash that john can understand. Finally, we'll pass this to our cluster using Juju's set action.

This was a 6 character password, consisting of 52 random characters (a-z, A-Z), almost certainly not in our dictionary. 526 = 19,770,609,664, or about 19 billion letter combinations we need to test. According to the john -test command, a single one of my instances can test about 12,500 MD5 hashes per second. So with a single instance, this would take a maximum of 526 / 12,500 / 60 / 60 = 439 hours. Or 18 days :-) Well, I happen to have exactly 18 instances, so we should be able to test the entire wordspace in about 24 hours.

So I threw all 18 instances at this very problem and let it run over a weekend. And voila, we got a little lucky, and cracked the password, Uvneow, in 16 hours!

In Conclusion

I don't know if this charm will ever land in the official charm store. That really wasn't the goal of this exercise for me. I simply wanted to bring myself back up to speed on Juju, play with the port to Golang, experiment with OpenStack as a provider for Juju, and most importantly, write a scalable Juju charm.

This particularly application, john, is actually just one of a huge class of MPI-compatible parallelizable applications that could be charmed for Juju. The general design, I think, should be very reusable by you, if you're interested. Between the shared file system and the keep-one-running approach, I bet you could charm any one of a number of scalable applications. While I'm not eligible, perhaps you might consider competing for cash prizes in the Juju Charm Championship.