Skip to content

Terraform and OpenStack: Boot an instance from CD-ROM

In the spirit of "this took me way too long", here's how to boot an instance with a CD-ROM on OpenStack, using Terraform.

Why would I need this?

In a perfect world, I have templates to bootstrap instances. Means, the instances are ready to go when booted. I customise them with cloud-init and let them do all kinds of cool (or necessary) stuff like configuring the network, setting hostnames, adding user accounts and then maybe joining them to a cluster.

But I don't live in a perfect world, still: I try to automate as much as I can. So I don't have to remember any of it.

Use-case

The use-case is the installation (or setup) of a SoPhos firewall. The vendor provides me with an image which can be booted and then an installer and setup wizard have to be completed to finish the installation process.

Using Terraform

Let's look at the code first - the following is used to create the instance:

resource "openstack_compute_instance_v2" "vpn_host" {
  depends_on = [
    data.openstack_images_image_v2.vpn_image
  ]

  name        = "vpn"
  flavor_name = "dynamic-M1"

  security_groups = [
    "default",
  ]

  # boot device
  block_device {
    source_type           = "blank"
    volume_size           = "100"
    boot_index            = 0
    destination_type      = "volume"
    delete_on_termination = false
  }

  # cd-rom
  block_device {
    uuid             = data.openstack_images_image_v2.vpn_image.id
    source_type      = "image"
    destination_type = "volume"
    boot_index       = 1
    volume_size      = 1
    device_type      = "cdrom"
  }

  network {
    port = openstack_networking_port_v2.vpn_port.id
  }

  network {
    uuid = data.openstack_networking_network_v2.public_network.id
  }
}

I am omitting some code, but let's walk through this.

How to CD-ROM (block_device)

I am approaching this in reverse order — let me talk about the second block_device block first.

This is the bit that took me the longest because I didn't know how disk_bus or device_type play well together. Or which of the two is needed.

The moral of the story is, if the Terraform provider documentation is too vague, read OpenStack's documentation on device mapping instead. Or in your case, you are reading my blog post! :-)

To continue, the image of the SoPhos firewall is referenced by data.openstack_images_image_v2.vpn_image.id. Therefor, I have a data provider which pulls the image from OpenStack (or Glance):

data "openstack_images_image_v2" "vpn_image" {
  name = "fancy readable name of the ISO here"
}

During terraform apply Terraform will try to resolve it. If successful its result will be used to create a (Cinder) volume from it. The "1 (GB)" size of the volume is what OpenStack suggested when I did this via the fancy web UI. Therefor, I used it in my Terraform setup.

The important part of the block_device block is device_type = "cdrom". Without it OpenStack will refuse to boot from the volume even though we provide a boot_index.

Small caveat: I had to add a depends_on as Terraform's dependency graph would not wait for the data provider to resolve during apply.

Boot device

Last but not least: I also need a bootable root partition to install to, and that's the first block_device block in my code snippet.

If all goes well, the provisioning is as follows:

  1. OpenStack starts the instance
  2. It discovers that the first disk is not bootable (yet)
  3. It proceeds with the CD-ROM (attached to /dev/hda in my case).

After the installation is finished, subsequent reboots of the instance always use the first disk. This is similar to dropping a CD into a (real) server, installing it (from the CD) and leaving the CD (in the drive) at the data center (just in case). :-)

The rest

The rest is hopefully straight forward.

I defined two other networks (with another Terraform run) which are used via data providers.

One is used as a port (for fixed IP allocation/configuration, openstack_networking_port_v2.vpn_port.id) and the other provides the VPN instance with another accessible IP for dial-in and remote management from the public network (via data.openstack_networking_network_v2.public_network.id).

Fin

Thanks for reading.

vpnc (for Cisco VPNs with 2-factor authentication) on Ubuntu

In order to connect to firewall and DRACs of our new Rackspace cluster, I had to setup a VPN connection. Rackspace gave us a Cisco ASA device which is firewall and vpn in one. In order to connect to the VPN the client needs to do 2-factor authentication.

At first I tried to install the necessary add-ons for Ubuntu's network-manager, but after I spent an hour or so trying to make it work, I took an alternate route.

Requirements

Here's all you need to get started:

$ sudo aptitude install vpnc
...

Configuration

Create a configuration file — I called mine rackspace.conf:

$ gksudo gedit /etc/vpnc/rackspace.conf

I put in the following:

IPSec gateway X.X.X.X
IPSec ID GROUPNAME
IPSec secret GROUPPASSWORD
Xauth username USERNAME
Xauth password PASSWORD

Obviously, the capitalized values need to be replaced:

  • IPSec gateway: the VPN's gateway/address
  • IPSec ID: the group's name
  • IPSec secret: the group's password
  • Xauth username: the username
  • Xauth password: the password associated with the username

If you're with Rackspace, they'll tell you those exact things when the firewall is provisioned. I gather other ISPs call them similar.

Using your VPN

Once the file is saved, just start the vpn connection:

$ sudo vpnc rackspace
VPNC started in background (pid: 2691)...

Note: Just rackspace is plenty, not rackspace.conf or similar.

Testing:

$ ping 172.30.0.144
PING 172.30.0.144 (172.30.0.144) 56(84) bytes of data.
64 bytes from 172.30.0.144: icmp_seq=1 ttl=64 time=114 ms
64 bytes from 172.30.0.144: icmp_seq=2 ttl=64 time=113 ms
64 bytes from 172.30.0.144: icmp_seq=3 ttl=64 time=113 ms
^C
--- 172.30.0.144 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 113.766/114.199/114.866/0.552 ms

To disconnect it:

$ sudo vpnc-disconnect 
Terminating vpnc daemon (pid: 2691)

Fin

That's all.

Giganews VPN on Ubuntu

This article briefly describes how you can setup the Giganews VPN (PPTP) on Ubuntu. I'm gonna assume 10.04 (that's what I tested with) and the gnome desktop.

Does this sound familiar: The VPN connection 'xxxxx' failed because there were no valid VPN secrets.

If so then I'm hoping this article will help you.

What is a VPN for?

The use-case for a VPN — and this is for basically any VPN (not just Giganews' service) — is security. For example, for online banking when you use public WIFI at airports, train stations or your favorite coffee place.

Unless the VPN service itself is blocked, a VPN also provides real and unfiltered Internet access. No bogus blocks or censorships because your goverment thought they need to protect you.

From a development perspective using different VPNs also allow me to easily test location-based services. And it doesn't stop there — for example since I work for people in the U.S. we often run into issues with services which we use which do things different to me because of my location. A VPN in the U.S. fixes that for me.

And there are more and more use-cases once you think about it.