If you don’t know what QNX is don’t be scared, but if you don’t know what vagrant is this post is probably not for you :)

Most of my career I have lamented not being able to use the best and most exciting tools because they just won’t work for whatever I have to get running at the time.

Working with Windows you learn very fast to not expect much comfort, or support, or sane functioning command line interfaces for that matter. But I love edge cases, they represent a chalenge.

So for the past week or so I have been putting together a setup for QNX Neutrino 6.5 machines.

QNX Neutrino is a real time operating system offered by QNX Software Systems which apparently belongs to RIM now. It’s a nifty microkernel RTOS, very Unix-like, more BSD than Linux in some ways and you can add all kinds of open source goodies to it.

QNX is also very kind and offers a VMWare VM with the latest version of the OS. For the task at hand that was a godsend. So I made a few copies and started experimenting with the setup until it was done.

And then the yak shaving started.

See, every time I made a mistake I just deleted the VM, made another copy from the QNX master and continued the work. Sounds familiar?

It’s more or less the vagrant work flow: Define your VM, do vagrant up to start it, do the work with vagrant ssh and when you’re finished vagrant halt or vagrant destroy if you went too far. The idea was to use a shell provisioning setup and easily test the setup scripts.

How hard can it be to build a vagrant basebox for QNX? Considering it’s 23:00 and I started this at around 19:00 I would not say it’s easy.

##Creating the basebox The QNX VM came in VMWare format, I have a VM Workstation license and there is a (commercial) vagrant plugin for VMWare which I promptly acquired. I did not want to go through the trouble of converting the QNX VM from VMWare to VirtualBox just in case the yak became a yak herd.

Before we package the whole thing there are a few things that need to be done on the QNX VM to allow vagrant to work with it. Everything listed is run as root.

###Setup sshd

#! /bin/sh

#setup ssh access 
random -t
#use emtpy passphrases
ssh-keygen -t rsa -f /etc/ssh/ssh_host_key -b 2048
ssh-keygen -t rsa -f /etc/ssh/ssh_host_rsa_key
ssh-keygen -t dsa -f /etc/ssh/ssh_host_dsa_key
#and start the server
/usr/sbin/sshd&

Also, edit /etc/rc.d/rc.local and add the line /usr/sbin/sshd& at the end so that sshd starts when the machine reboots.

###Setup the vagrant user I really dislike this because I have not found a way to automate it further. You need to go through the passwd questions manually.

#! /bin/sh
#Accept default values and use vagrant as the password
passwd vagrant

After this you need to add ‘users:x:100:’ at the end of /etc/group

###Passwordless ssh access Get the vagrant insecure public key and copy it into /home/vagrant/.ssh/authorized_keys. Then to make sure do the following

chown -R vagrant:users /home/vagrant/.ssh
chmod -R 700 /home/vagrant/.ssh

If the permissions are not set corretly openSSH will not login succesfully (and you will not know why!)

###Actually create the base box The basebox format is actually very basic: Whatever VM files your provider requires to start the VM plus a metadata.json file with the following content:

{
  provider: "vmware_workstation"
}

Values that are valid at the time of writing are “vmware_workstation”, “vmware_fusion” and “virtualbox”.

For VMWare VMs the following should do the trick when run in the VMs directory.

tar cvf qnx65.box *.vmdk *.vmx *.vmxf *.nvram metadata.json

(add the .json file yourself :) )

##Enter Vagrant So we do the vagrant init and edit the Vagrantfile

VAGRANTFILE_API_VERSION+"2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|
  config.vm.box="qnx65" 
  config.vm.box.url="qnx65.box" #No real URL, the basebox was just in the same directory
end

The first vagrant up needs to specify the provider otherwise vagrant defaults to Virtualbox

vagrant up --provider vmware_workstation

Now, if you did not setup ssh correctly then vagrant is going to hang with “Waiting for VM to boot. This can take a few minutes”. This can be easily ascertained if you set the environment variable VAGRANT_LOG=debug and watch how vagrant repeatedly tries to connect and fails miserably never giving up. Go back and set those permissions…

If you have setup ssh correctly then you’re going to get a “The guest operating system of the machine could not be detected!”. So much for Unix-like.

Fun fact: If ssh is not correctly setup and vagrant up hangs, then you can control-C and then try vagrant halt. After an inordinate amount of time the VM is going to shutdown. If ssh does work then vagrant halt will die horribly complaining that it cannot recognise the OS.

Which means that there’s going to be a continuation to this adventure, where we dwell into the creation of a vagrant guest plugin. This yak is not yet completely shaved.

There’s a follow up post with the QNX guest plugin