Throw a job ad on a recruitment portal, wait for applications, hold a couple of interviews and that’s it, right? This is what recruiting can look like from the outside but there’s quite a bit more to it. A recruitment campaign can be a massive effort especially for small businesses. In addition, if you’re doing it for the first time, you may want some advice.

We’re a small company (with 3 more or less part-time employees) who recently ran our first official recruitment campaign so we know what we’re talking about! We hope that sharing our experiences will help other small businesses and organizations to get the most out of a recruitment campaign without losing too much time and money and building a good employer brand at the same time.

This posting comes strictly from the land of esoteria. We have a Vagrant + Virtualbox environment that sets up Foreman used for PXE booting baremetal servers. The environment work fine on Linux and MacOS. But we needed to make this environment work also on Windows. Easy, right? Vagrant and Virtualbox are supposed to abstract all those pesky operating system settings away, correct? After resolving a non-Windows related challenge provisioning of Foreman on Windows almost worked. Except that it failed when foreman-installer attempted to start[*]. The error message was this:

The vagrant-hostmanager plugin is a really nice plugin which helps Vagrant VMs communicate with each other using names instead of IP addresses. Essentially it manages hosts entries for the VMs, acting like a poor-man’s DNS. Now, on *NIX operating systems you typically use sudo, which caches your authorization. So, when hostmanager starts, you type your password once and then it is able to add all the host entries it needs to /etc/hosts. This is not so on Windows: you will get one UAC prompt per modification to c:\windows\system32\drivers\etc\hosts. This will eventually drive you crazy. To fix this you need to permit your Windows user account to modify the hosts-file without privilege elevation. To pull this off, you will need to modify that file’s access control lists. The process is quite convoluted imho, but here it goes:

If you’re at all like me, you every now and then find yourself thrown out of your comfort zone, when you should actually be in it.

The pattern usually goes something like this:

1. It’s something simple. I’ll fix it in a couple of minutes and document it for others. I know my stuff. 

2. Hmm, this seems to be a bit stubborn. I need to take a closer look.

3. Still doesn’t work. I need to run this in a debugging set up and break it into pieces, to see where the problem is. 

We’re using the centos/7 base box in Vagrant a lot and often hit this problem when bringing up new VMs with Vagrant:

umount: /mnt: not mounted

This error comes from vagrant-vbguest plugin which tried to install the Virtualbox Guest Additions but failed. The error message is misleading, because the real issue is related to upstream (CentOS) yum repositories. As explained in this Vagrant bug report:

“Basically the CentOS that you’re installing is containing an old kernel version which has been removed from CentOS repositories. Vagrant is trying to install Guest Additions, which has as a dependency the kernel-devel package. kernel-devel package must be the same version as the kernel package that you have it installed in your CentOS box, version which is removed from the CentOS repos.”

We use Vagrant and Virtualbox heavily when developing Puppet code. We also do provisioning of baremetal servers with Foreman. While Vagrant is a really powerful tool, it is not designed for creating VMs that boot from the network (PXE boot). Fortunately Virtualbox itself provides a rich command-line with which you can create and configure virtual machines and configure them to boot from the network. It is assumed below that there is a PXE boot server (e.g. Foreman) created into a hostonly network with Vagrant. Here’s an example script that create a VM with vboxmanage and adds it the same hostonly network interface (vboxnet15) as the PXE boot server:

Ejabberd is a very flexible and scalable XMPP server. We use it because it can be configured using a simple yaml configuration file and managed via ejabberdctl commands. This makes it a good fit for our infrastructure as code approach. That said, ejabberd does require one to understand the XMPP protocol/jargon as it does not abstract away any of it. So simple things like creating chatrooms, limiting access to them and playing history backlog to users who connected them can be an effort if you’ve never done it.

When using ejabberd in a company for multi-user chat (see my earlier blog post) people will quickly start complaining that they missed discussions because they had been offline. Ejabberd does play back last 20 messages when user joins a room, but that is too little for an active chatroom. The simplistic approach is to set history_size in mod_muc settings in ejabberd.yml to a higher value:

mod_muc:
  history_size: 200
  --- snip ---

This simplistic approach should work with any XMPP clients.

Sometimes you’d like to pass a dynamic value to a Terraform resource’s provider parameter. This can be done, but some background first.

Terraform allows you to define multiple providers of the same type using provider aliases. This is useful when you’re working with a provider that is tied to a region, the AWS provider being a prime example. The moment you want to create resources in multiple regions you will have to learn provider aliases.

This could possibly be the most esoteric blog post I’ve ever written, but here it goes. So, for reasons even we have difficulty comprehending (hint: related to PXE booting in a Vagrant/Virtualbox environment) we had to find out which inactive vboxnet (hostonly) interface had the highest index. We wanted the code to (hopefully) run on all platforms (Linux, MacOS, Windows) so we wanted to write this code in Ruby. So, this was the brutal but working end-result: