Tag Archives: Ubuntu

Ubuntu 12.04 and Cloud Foundry

Well, it’s that fun Ubuntu release day again, and around the world, I’m sure there are parties aplenty…

I grabbed an ISO this morning (64-bit desktop version, natch), and quickly setup a new virtual machine to run on my Mac. A nice feature of VMware Fusion 4.0 is the “easy install” option which lets you rapidly pop in the basic information needed to setup the system, and the rest is taken care of for you.

In my case, I specified a user ID, selected that I wanted my home folder read/write shared into the VM, and then customised the machine to up the memory and add a CPU core. In a few minutes (my machine has an SSD…!) I had a new virtual machine, running full screen in a separate space on Mission Control. Fusion even took care of installing VMware Tools so it was able to do the file sharing, use the full screen resolution etc etc straight away.

So… first impressions? Much more slick than 11.10 which I was using on a daily basis until recently. In particular, the configuration options have been streamlined really nicely. I’m still struggling with discovery of applications in Unity but in general, it’s not bad at all.

Browsing through the available packages, I was interested to find that the Cloud Foundry tools are available in the default repositories:

Cloudfoundry client

That’s awesome! you can just run sudo apt-get install cloudfoundry-client and get the main tool for deploying apps and administering Cloud Foundry right from the repository using the regular apt method (actually this is simply a convenience package – under the covers it installs a package called ruby-vmc, which installs the vmc command-line Ruby gem… it’s nice that the Ubuntu guys have made it easier to discover, though).

So what’s the problem? Well – no big deal, but actually, if you want to keep up with Cloud Foundry as a developing platform, you might want to grab something slightly newer than what is available on tap in the repository. As I write this, the version of vmc available via the cloudfoundry-client package is 0.3.10 and the one we’re currently working with is at least 0.3.16.

My suggestion, therefore, is to do the following:

  1. Install rvm (Ruby Version Manager). That way, you can have different versions of Ruby itself installed, manage gems for the different versions independently, and also – importantly – not require root privileges to do your development work and install additional gems. A handy guide to installing rvm on Ubuntu is here, and it still works fine on 12.04. Just follow the commands shown in the Installing RVM and Installing Ruby sections and you should be all set and rocking ruby-1.9.2 on your new 12.04 setup.
    (I’m using rvm and JewelryBox to manage Ruby versions on OS X, incidentally. Great tools)
  2. Run either gem install vmc or gem install vmc --pre (the latter option will get you the very latest pre-release of vmc, if you like the bleeding edge). Note that, if you installed rvm and Ruby successfully, you should not need root permissions to install gems.
  3. There is no step 3 — vmc target http://api.cloudfoundry.com and then vmc login and you should be good to go. Looking for a sample app to deploy? You could take a look at the Sinatra example I added to the cloudfoundry-samples repository on Github last week…

It’s fantastic that Ubuntu is moving towards strong desktop / development environment support for Cloud Foundry.

Oh, there’s another story with Precise Pangolin,  too – you can rapidly install the server side pieces to build your own cloud using the Juju Charms which provide Cloud Foundry support. But… that’s a story for another post, in another time and place…. 🙂

Update 15/05: I raised bug #998111 against Ubuntu to ask for the ruby-vmc package to be updated, in case you feel like tracking progress via Launchpad.


Eclipse Paho gets started…

Since the announcement of Eclipse Paho (an Open Source project under the Machine-to-Machine umbrella at Eclipse) there has been a fair amount of excitement in the MQTT community about the availability of IBM’s C and Java client code under an Open Source license.

The initial proposal and setup stages have taken a little while, but this week the initial availability of the C client code was announced on the Paho mailing list (Java will follow shortly).


Paho Quickstart

This is not intended to be a comprehensive guide – better documentation etc will emerge over time – but I thought I’d post a quick guide as a kickstart for anyone wanting to give it a look. I did this on 64-bit Ubuntu 11.10 – similar steps will apply on other Linux or UNIX platforms (note, the initial code contribution has a Makefile with rules which should work on UNIX, Windows, or z/OS).

Install the necessary packages to build code. NB git is for grabbing the source from Eclipse; build-essentials is a metapackage providing gcc etc on Ubuntu; and doxygen and optional graphviz are used for generating the documentation.

sudo apt-get install git build-essentials doxygen graphviz

Get the code from the git repository:

git clone git://git.eclipse.org/gitroot/paho/org.eclipse.paho.mqtt.c.git

Quick build for the client library and documentation:

cd org.eclipse.paho.mqtt.c.git/src
make -f ../build/Makefile all
doxygen ../doc/DoxyfileV3ClientAPI

Once these commands complete, you should be left with subdirectories called <platform> and docs. In my case, <platform> was 64-bit Linux, so I had a binary at linux_ia64/libmqttv3c.so. There’s no “make install” rule at the moment, nor is there a rule to compile the docs so I had to run doxygen directly. In the future it would be nice to automate all of that, and also to build some test applications.

Opening docs/html/index.html in a browser reveals very nice documentation describing the client library, including some examples of how to use it. For example, in docs/html/pubasync.html there’s a complete listing for an asynchronous publisher application. I extracted that code into pubclient.c and decided to check that it worked!

gcc -Wall pubexample.c -L./linux_ia64 -lmqttv3c -lpthread -o pubexample

That command successfully built a binary called pubexample. All I needed to do was test it. The sample application assumes that an MQTT broker is available on localhost port 1883 – if you want to change that, simply modify the value of the static variable ADDRESS in pubexample.c – in my case I simply apt-get installed the mosquitto and mosquitto-clients packages onto my system, but I could equally have unzipped and run Really Small Message Broker – both start on port 1883 by default if not given alternative configuration.

export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./linux_ia64/
Waiting for publication of Hello World!
on topic MQTT Examples for client with ClientID: ExampleClientPub
Message with token value 1 delivery confirmed

It was trivial to test that a subscriber (mosquitto_sub in my case) also received the publication. Job done!

Getting involved, and other news on Paho

I mentioned that the Java client contribution should appear soon. One other piece of news this week is that the project’s sandbox broker implementation – based on mosquittohas been spun up. That was posted on the Paho mailing list, and if you want to get involved you should definitely subscribe to that; start to track the Eclipse Bugzilla for Paho; watch the Paho wiki; keep an eye on the source repositories; etc.. I’m already thinking about getting an OS X build rule sorted out. If you want to test your sample code now, you’ve got the option of a local broker, the Eclipse Paho sandbox, the mosquitto sandbox, or various other implementations.

Oh – and please leave a comment on this post if you find this information interesting, or want to discuss where things are with Paho. I’ll be hanging out on the mailing list as well.

What about Bob? (or Andy, even!)

Well, although I’ve left IBM, I’m delighted that MQTT is now going Open Source – in fact that was one of the things that I really wanted to help to achieve before I moved on. I am really pleased that I will be able to continue to contribute to both Paho and the broader Eclipse M2M Industry Working Group. I’ll be helping to update the mqtt.org community site, and heading over to EclipseCon in Virginia in a couple of weeks’ time to talk about M2M and work with our friends from the Koneki project. If you are attending EclipseCon please come say hi to me – and you may be interested in Wes Johnson’s session on MQTT and Eclipse tools.

There are very cool times ahead!

WebSphere MQ and Ubuntu (and other developer resources)

For some time now, I’ve been using Ubuntu as my desktop operating system. Although I’m yet to be convinced by Unity (it’s getting there, the more I learn the shortcuts and stick with it), I do know that Ubuntu is a hugely-popular platform for developers – and I know that many of my colleagues at IBM who are in development roles choose our internal Linux-based client options (which cover a range of distributions), instead of Windows or OS X.

So, what about developing with or using WebSphere MQ on Ubuntu? Well, the officially-supported platforms for WebSphere MQ V7.0.x don’t include Ubuntu – that’s primarily a combination of the relative popularity of RedHat or SuSE Enterprise platforms in production deployments, time and resource spent on testing, and the fact that it would probably only be practical to test and support it on a Long Term Support release if it ever became supported.

However, it is possible to get WMQ installed and running on Ubuntu without jumping through too many hoops. The primary stumbling block is that the software is packaged in RPM format rather than in Debian/Ubuntu-friendly DEB files. One piece of advice is to avoid any guides that suggest converting the packages using alien… it may seem unusual, but you’re likely to find it far easier to get it working by installing rpm on the system instead. My colleague Rob Convery has posted a couple of very useful blog entries on this subject which I’d recommend if you have a need to get yourself running on Ubuntu – again, bearing in mind that it is not an officially supported platform, and that should you encounter issues then it might be necessary to reproduce them under RHEL or SLES when raising a service call with IBM.


There are other ways to get to use and learn about WMQ too, of course – for example, you could grab one of the IBM Industry Application Platform cloud images to run on the IBM SmartCloud or Amazon EC2 (containing WAS V7, DB2 Express-C 9.7, and WMQ V7.0.1, running on SLES), or you can try a number of the WMQ family products in IBM’s SOA Sandbox, (including WMQ File Transfer Edition, and WMQ Advanced Message Security). You can also check out the MQonTV YouTube channel. Let me know what you think!

OggCamp approaches!

I’m getting quite ridiculously excited about an upcoming event…

I’m good friends with the team from the Ubuntu UK Podcast and have been privileged to be invited onto the show as a guest host twice now. They’ve partnered with the Linux Outlaws to create OggCamp for the past three years and this year, finally, I’m able to attend. I admit that it helps that the venue this year is reasonably local for me! I’ve also volunteered to assist as official Crew for the event, so I’ll either be very visible, or barely visible at all 🙂

I’ve blogged fairly frequently about my OSS, Linux, podcasting and social passions so I imagine it’s not a huge surprise to regular readers that I’m excited to finally have an opportunity to be involved. Laura has written about the rapid run-up to the event, and I hear that tickets may be becoming available from returns at the moment, so if you are interested it is worth checking back. I’ve also set up the OggCamp 11 page on Lanyrd if you want to add the event feed to your calendar. I’m also fairly certain that a good gaggle of MQTT geeks will be in attendance (the mosquitto project was born from the first OggCamp in 2009), so I’m looking forward to meeting folks!

Prototyping – Arduino and Ubuntu


My Arduino Uno board, via instagr.am and iPhone, on Flickr

One of those things I’ve been meaning to getting around to doing for ages is to explore this exciting new world of prototyping and hacking my own hardware devices together. A lot of my fellow eightbars and of course many of the HomeCamp community are big fans of the Arduino platform. I’ve also been dying to have a go with the MQTT client for Arduino that Nick has created (although I’ve recently also come across another platform called mbed, and MQTT has been ported to it, of which more to come soon). In fact, I’ve had one of the lovely Arduino starter kits from ::oomlout:: sitting on my desk for a while now, tempting me with its gadgetry and neatly-arranged components in a funky partitioned box… but life has been so hectic that it has taken me until today to finally crack it open!

I’m not going to spend long talking about the Arduino today, except to mention that it was unexpectedly tricky to get working under my OS of choice, Ubuntu 10.10. I’d read on Anton’s blog recently that the new UNO board (which I have) needed a firmware update in order to avoid some weirdness on the serial port, so I thought I’d go ahead and fix that first – his instructions were very clear, and the device seemed to report something, well, expected as I ran the commands. All good, or so I thought!

Português: Logotipo Arduino Uno.

Português: Logotipo Arduino Uno. (Photo credit: Wikipedia)

I installed the Arduino IDE from the Ubuntu repository and attempted to start it from the new Electronics submenu. Nothing happened. At that point I decided to try running “arduino” from the command line, and got back a Java stack trace containing java.lang.UnsatisfiedLinkError: rxtxSerial indicating an issue with some of the libraries. At that point a quick DuckDuckGo search (yes, I’m not using Google much these days) led me to an Ubuntu PPA which contained a fixed version of the IDE.

I was then able to fire up the toolkit and excitedly started looking at the Basic samples. However, as soon as I tried to upload one to the board, I got an error avrdude: stk500_recv(): programmer is not responding which suggested that the board was not being “seen” by the IDE. The only interface the toolkit recognised was ttyS0 and I knew the Arduino wasn’t there… looking in /var/log/messages I could see that it created an interface /dev/ttyACM0 when I plugged it in, but the toolkit wasn’t seeing that. I then tried creating a symlink from /dev/ttyUSB0 (where the wikis and documentation were telling me to expect the Arduino) to /dev/ttyACM0 – and presto, it worked.

Creating static symbolic links in /dev is a bit hokey these days, of course, so I moved across to udev and created a new rule for the UNO in a file called /etc/udev/rules.d/80-arduino-uno.rule

KERNEL=="ttyACM*", ATTRS{product}=="Arduino*", SYMLINK+="ttyUSB%n"

dead simple: if a new device pops up in the kernel named ttyACMsomething, and it has a USB product ID string starting Arduino (which mine does, I checked using the command usb-devices), add another symlink to it at ttyUSBsomething, thanks. Result:

Dec 21 19:18:50 agrippa kernel: [21501.209012] usb 1-1.1: new full 
speed USB device using ehci_hcd and address 17
Dec 21 19:18:50 agrippa kernel: [21501.303198] cdc_acm 1-1.1:1.0: 
ttyACM0: USB ACM device
andyp@agrippa:/etc/udev/rules.d$ ls -l /dev/ttyU*
lrwxrwxrwx 1 root root 7 2010-12-21 19:18 /dev/ttyUSB0 -> ttyACM0

That all seems to have done the trick. I’m just waiting on a couple of shields for the board, not least something that will let me connect it to a network, and then the experiments will continue! Weather-permitting the next lot of electronics should appear in the next day or so. More to come, on both Arduino and mbed hackery…