Using AWS Simple Email Service with Oozie in Cloudera

I’ve moved to a new role where I will be doing a lot more “devops” type work which hopefully comes with more interesting subjects to start writing about.

Oozie and AWS Simple Email Services

The Cloudera cluster I have started working on is hosted in AWS and has all the security bells and whistles turned on; Kerberos, TLS etc.

Recently a support ticket came my way where the Email Action in Oozie was failing, on top of this there was no notification around job success and the Kill action wasn’t sending emails…. more than likely Oozie isn’t correctly configured for email.

As mentioned before, we use TLS everywhere possible and want to use Amazon’s Simple Email Service endpoint to relay the messages through. TLS SMTP isn’t supported directly with Oozie so there is a requirement to put something in the middle. In this case, the something is going to be postfix.


There are a number of details you’ll need to get from AWS Management Console to get things set up.

In the AWS Management Console, navigate to the SES service and in the right hand side select SMTP settings. This is where you’ll find the endpoint you need to use and you can use the Create SMTP Credentials button at the bottom of the page to create some keys. _ Keep in mind that although these keys look like normal AWS Access Keys, they are actually SMTP keys and are specifically for authenticating with AWS SES _

Now on the left choose Email Addresses and follow the process for validating an email address as required by SES.

Installing and configuring postfix

These steps assume that you’re running a yum flavoured Linux, its pretty much the same if you’re working with Ubuntu if you interchange the package tooling.

First we need to install postfix

sudo yum install postfix -y

The configuration for postfix is in /etc/postfix/ This is where the relay to AWS SES is going to be happening.

There are a couple of tweaks that needed to be done in this file in addition to adding the relayhost section.

  1. Change the inet_protocols value to only ipv4 - inet_interfaces=ipv4
  2. Change the inet_interfaces, in my case I just commented out the whole line #inet_interfaces=localhost
  3. Add the smtp_tls_CAFile, in my case we’re using a pem file smtp_tls_CAfile = /path/to/tls_cert.pem

Now the relayhost section needs to be added so that it can forward to SES correctly.

In my case, I’m hosted in Ireland (eu-west-1) so my endpoint for SES is

relayhost = []:25
smtp_sasl_auth_enable = yes
smtp_sasl_security_options = noanonymous
smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd
smtp_use_tls = yes
smtp_tls_note_starttls_offer = yes

You can now save, we’ve finished with that.

You may have noticed the smtp_sasl_password_maps section pointing to a sasl_passwd file. We now need to create that. So create the file /etc/postfix/sasl_passwd and add the following using the credentials created for the SMTP user above.

[]:25 <smtpkey>:<smtpsecret>

You can now create the hash of this file, set the ownership and permissions then remove the new sasl_passwd file with the cleartext keys

sudo postmap hash:/etc/postfix/sasl_passwd
sudo chown root:root /etc/postfix/sasl_passwd.db
sudo chmod 0600 /etc/postfix/sasl_passwd.db
sudo rm /etc/postfix/sasl_passwd

Now all you need to do is start the service sudo postfix start

Configuring Oozie

You can configure Oozie in Cloudera Manager. Go to Oozie service -> Configuration. Set and set the value to the IP address of the server you’ve installed postfix. (To keep it simple, I installed postfix on the Oozie server itself. I had to use the IP as Oozie doesn’t like localhost)

Set the you’re going to be sending from to the value setup in SES Management Console email address page.

Restart Oozie and Hue then create a test workflow with an Email Action sending an email and run. All being well, the email will be sent and the workflow action will go green. Check the logs of the workflow if it doesn’t work, it should be clear from there.

Wordle Interpretation of CV

Today someone showed me a handle word cloud tool called wordle.

I put the skills from my CV into it and had a play with the output… I think it looks quite cool.

My Wordle Skills List

First go at creating a Garmin watch face

For a while Garmin have been adding “wearable technology” functionality to their watches - notifications from the phone etc. I got a Garmin Fenix 3 for Christmas and had a play with the vast number of watch faces and widgets that were available.

The recent updates have really added some great functionality and I ended up settling on the out of the box digital face as my normal watch face but I still wanted to have a go at creating my own watch.

###Monkey C The programming language used to develop the faces, apps, widgets and data fields is called Monkey C and the IDE is mostly intended to be Eclipse.

Its almost certainly going to be worth your time looking at the Garmin developer site to get the full over view of whats required, but I’m covering the headlines below.

####Getting the SDK First you need to download the Garmin SDK from here. I’m using a Macbook so I’ve dropped it in /usr/local/garmin-sdk.

####Eclipse Add in If you look at the getting started pages here you’ll get all the information about adding the Eclipse add in which will give the you project template and intellisense as well as access to some richer wizards for interacting with the simulator.

I’m not very comfortable using Eclipse so I was pleased to see that there is an Intellij plugin that someone had started.

####Intellij Plug in The IntelliJ plugin is added in the normal way, the details about it are here.

At the time of writing this it was fairly basic and doesn’t have many features, I had to rely on the API docs to get the message signatures of everything I needed to use.

####API Docs The API docs are pretty good for getting the gist of what you want to do. You need to know what you want to do and see if you can rather, but thats no different to any API I guess.

###My First Watch face And so to my first watch face. I wanted to have a clean digital watch without the clutter of bars and tickers. I did want to know my relative step progress and the current battery level though, I’ve been caught out a few too many times.

My understanding from the docs is that your watch face updates minutely in low power mode until the gesture of looking at the watch is detected then it becomes every second. There are some methods which are called during this state change but I didn’t have any need for them.

I’m loading the components programatically so I don’t need much in my layouts file

<layout id="WatchFace">

Your watch face must extend the Ui.WatchFace class

class FirstwatchfaceView extends Ui.WatchFace {

  function initialize() {

  function onLayout(dc) {

  function onUpdate(dc) {
    // clear the display
    var font = Gfx.FONT_NUMBER_THAI_HOT;
      // get the info needed
    var activity = ActivityMonitor.getInfo();
    var stats = Sys.getSystemStats()
    var clockTime = Sys.getClockTime();
      var today =;
    var dateInfo =, Time.FORMAT_MEDIUM);
    var timeString = Lang.format("$1$ $2$", [clockTime.hour, clockTime.min.format("%02d")])
    // get the text size to work out where to position it
    var textDim = dc.getTextDimensions(timeString, font);
    var x = (dc.getWidth() / 2);
    var y = (dc.getHeight() /2) - textDim[1] /2;
    var stepsX = x - textDim[0]/2 ;
    var batteryPercent = Lang.format("$1$%", [stats.battery.format("%02d")]);
    var date = Lang.format("$1$ $2$", [, dateInfo.month]);
    var percent =  (activity.steps*100)/activity.stepGoal
    // set the whole screen black
      dc.setColor(Gfx.COLOR_BLACK, Gfx.COLOR_BLACK);
      dc.fillRectangle(0, 0, dc.getWidth(), dc.getHeight())
    if (percent > 100) {
       dc.setColor(Gfx.COLOR_GREEN, Gfx.COLOR_BLACK);
         dc.drawText(x,y, font, timeString, Gfx.TEXT_JUSTIFY_CENTER);
      } else {
         dc.setColor(Gfx.COLOR_RED, Gfx.COLOR_BLACK);
         dc.fillRectangle(stepsX, y+1, min(percent, textDim[0]), textDim[1]);
         dc.setColor(Gfx.COLOR_WHITE, Gfx.COLOR_BLACK);
       dc.fillRectangle(stepsX + percent, y+1, textDim[0]-percent, textDim[1]);
       dc.setColor(Gfx.COLOR_TRANSPARENT, Gfx.COLOR_BLACK);
       dc.drawText(x,y, font, timeString, Gfx.TEXT_JUSTIFY_CENTER);
    dc.setColor(Gfx.COLOR_WHITE, Gfx.COLOR_BLACK);
    dc.drawText(x, (dc.getHeight() - 10 - (dc.getFontHeight(Gfx.FONT_TINY))), Gfx.FONT_TIN batteryPercent, Gfx.TEXT_JUSTIFY_CENTER);
    dc.drawText(x, (10 + dc.getFontHeight(Gfx.FONT_TINY)), Gfx.FONT_TINY, date Gfx.TEXT_JSTIFY_CENTER); }

function min(a, b) {
  if (a > b) {
     return b;
   return a;

Running in IntelliJ for me is a case of Shift+F10 and the Run Configuration loads the simulator.

In the simulator you can set the levels of activity and change properties of the device such as battery status and GPS etc.

Steps in progress Daily steps in progress

Steps in progress Daily steps in completed

Scala eXchange 2015 - Embracing the community

Today I’m at my first Scala eXchange conference - the 5th annual one to be precise.

The day started with the keynote session by @jessitron which was both inspiring and enlightening. The general tone being that code should be clear and useful so that others can learn.

Drawing on examples where opaque libraries with poor documentation or overly simplified examples limited the accessibility to the new user. Words like “Simply”, “Just”, “Obviously” and “Clearly” are the scourge of documentation and for the most part lazy.

Contribution to any project should be welcomed, its an active attempt to say “hey, I’m here to help and I’m interested”. Even if the contribution isn’t entirely helpful or needs polishing it should still be embraced and encouraged.

I’ve mumbled for years about how to get involved with a project assuming that I needed to offer huge value on the first pull request - Jessica has help me see that the first step is to just do something.

If only the second speaker had been listening, maybe his talk would have been less obscure and contained less usage of the words “Simply” and “Just”.

Unit testing HDFS code

I need to write a couple of unit tests for some code to add a log entry into HDFS but I don’t want to have to rely on having access to full blown HDFS cluster or a local install to achieve this.

The MiniDFSCluster in org.apache.hadoop:hadoop-hdfs can be used to create a quick clustered file system which can be used to testing.

The following dependencies are required for the test to work.


The code is reasonably simple, I’m creating the cluster in the Test setup and tearing it down during the teardown phase of the tests

private MiniDFSCluster cluster;
private String hdfsURI;

public void setUp() throws Exception {
    Configuration conf = new Configuration();
    File baseDir = new File("./target/hdfs/").getAbsoluteFile();
    conf.set(MiniDFSCluster.HDFS_MINIDFS_BASEDIR, baseDir.getAbsolutePath());
    MiniDFSCluster.Builder builder = new MiniDFSCluster.Builder(conf);
    cluster =;
    hdfsURI = "hdfs://localhost:"+ cluster.getNameNodePort() + "/";

public void tearDown() throws Exception {

This makes a cluster available for the tests, in this case its a simple log entry which is going to return the path to the log entry, because this has a guid in I need to just make sure the file is created starting as expected

public void testCreateLogEntry() throws Exception {
	String logentry = new LogEntry().createLogEntry("TestStage", "TestCategory", "/testpath", cluster.getFileSystem());
	String date = new SimpleDateFormat("yyyyMMdd").format(new Date());
	assertTrue(logentry.startsWith(String.format("/testpath/TestStage_%s_", date)));