I was thrilled to learn that I had been included in the free HP Cloud (@hpcloud on twitter) beta test. I’ve recently been messing a little bit with Amazon Web Services, and I’d requested access to HP to compare the offerings. Success! My gain is yours, so lets take a quick look…

When logging in, you get an interface similar to this:

There are three offerings immediately available. The two cloud compute options at az-1.region-a.geo-1 and az-2.region-a.geo-1, and a cloud object store at region-a.geo-1. I’m certain that they will offer both more geographic areas and services before the end of the beta, and definitely when the service goes public.

Anyway, I wanted to set up a machine and see what the process was like. I clicked on the blue “Activate Now” button in the picture above, and it took me to this screen:

The options for the size are currently as shown below:

The images available right now are here:

Since AMI on Amazon means “Amazon Machine Image”, I’m not sure what the AMI prefix means here, but whatever. I selected the smallest size and the CentOS 6.2 image with the default security group. At first, I didn’t get a chance to select a key pair, but I left instances at 1 and clicked Create. Of course, you have to have a keypair, or you can’t SSH in, so I got a warning box telling me to click “Key Pair” to make a new keypair. Done. I copied the resulting private key into my HPtestCon1.pem file, chmodded it to 400, and went on my merry way.

Incidentally, key pairs on HP are geographically specific. In running through this process again as I write this entry, I’m doing it on the az-2.region-a.geo-1 compute group. I don’t know if this is going to remain the case for public production, but I hope not. I would like my in-production servers to not need me to be aware of which geographic zone they’re running in. I don’t know if AWS or RackSpace are set up in the same way…maybe someone can chime in below in the comments?

I asked @HPCloud on twitter, and I got a response from HP cloud guy @rupakg:

When I asked about the ability to manually add keys (because I don’t really want to have my scripts care which geographic zone these VMs are running in), he suggested that I check out the Cloud CLI. I haven’t had a chance to play with it yet, but it seems promising. There are Powershell commandlets for Windows and a Ruby gem for Unix, in addition to Eucalyptus tools, which makes sense, since all of HP Cloud is based on OpenStack.

After creating a key pair, I was able to start the new instance with no problems whatsoever. Of course, once I started the instance, I ran into a small hiccup…my Private IP was 10.4.7.whatever and I didn’t have a public IP to connect to it using. Right. So I clicked on the instance number listed, and one of the options was “ATTACH PUBLIC IP”, and all of a sudden, I had a public IP. An IPv4 public IP.

I’ve been looking for a cloud provider that has IPv6 out of the box, and sadly, HP doesn’t have it. That’s ok, as far as I can tell, no one else does, either. [Edit: Several people have told me on twitter that Linode has it. Yay!] I still wanted to set up an IPv6 web server as a demo, though, and I wasn’t going to let this stop me, so I went through the path of least resistance: http://www.tunnelbroker.net/.

I created a TunnelBroker account in about a minute. After logging in, I clicked “Create Regular Tunnel”, and was asked for my IPv4 Endpoint, and I gave it the IPv4 address that was assigned to my VM. It then checked the address, determined that it was a potential tunnel endpoint, and suggested I use the Chicago tunnel server. Sure, why not? I clicked Create Tunnel, and in a few seconds, it took me to the Tunnel Details page:

Easy peasy. Anyway, my server was up and running, so to connect to it, I just ran

ssh -i ~/HPtestCon1.pem root@mypublicIP

Once on the server, I quickly configured the IPv6 tunnel from Hurricane Electric. In the Tunnel Details above, you can see the “Example Configurations” tab, which I clicked. Once on that page, there’s a pulldown for “Select your OS”, and when I selected Linux-net-tools, I got the following:

ifconfig sit0 up

ifconfig sit0 inet6 tunnel ::209.51.181.2

ifconfig sit1 up

ifconfig sit1 inet6 add 2001:470:1f10:294::2/64

route -A inet6 add ::/0 dev sit1

Pasting this into the shell didn’t produce any errors whatsoever, and I tested my IPv6 connectivity:

[root@server-49193 ~]# ping6 ipv6.google.com

PING ipv6.google.com(mil01s17-in-x10.1e100.net) 56 data bytes

64 bytes from mil01s17-in-x10.1e100.net: icmp_seq=0 ttl=54 time=185 ms

64 bytes from mil01s17-in-x10.1e100.net: icmp_seq=1 ttl=54 time=185 ms

64 bytes from mil01s17-in-x10.1e100.net: icmp_seq=2 ttl=54 time=185 ms

64 bytes from mil01s17-in-x10.1e100.net: icmp_seq=3 ttl=54 time=185 ms — — ipv6.google.com ping statistics — -

5 packets transmitted, 4 received, 20% packet loss, time 4016ms

rtt min/avg/max/mdev = 185.038/185.082/185.142/0.432 ms, pipe 2

Excellent. Now for Apache. First, lets install it:

yum install httpd -y

Now we have to configure it. Edit /etc/httpd/conf/httpd.conf, and look for the Listen lines which dictate which IPs the machine responds to. The default line number is 134, if you were curious.

Because we want to be specific, change the line that says:

Listen 80

and change it to

Listen 10.6.whatever.whatever:80

where 10.6.whatever.whatever is your private IP.

We’re also going to add a line specific to the IPv6 address that we’ve been given by Hurricane Electric, so in the commands above, I would use 2001:470:1f10:294::2. That’s my side of the tunnel that they set up for me. Yours will be slightly different. The line I added was:

Listen [2001:470:1f10:294::2]:80

You’ll notice that there are square brackets surrounding the IPv6 address. These are very important. The reason is that, historically, the colon separated the IP address from the port number, as it does in the IPv4 line above. With IPv6, we can shorten the IP by replacing the longest string of zeros with :: — thus making an IP of 2001:470:1f10:294::2 when the full length address is 2001:1f10:2940:0000:0000:0000:0000:0002. Having colons define a port number doesn’t work anymore unless you do something else to determine the IP address, so the standard operation is to enclose it in square brackets. Make sure to do that.

Save the file, then start up Apache:

[root@server-49193 ~]# service httpd start

Starting httpd:

[root@server-49193 ~]# service httpd status

httpd (pid 3002) is running…

[root@server-49193 ~]#

Now, we can test it by going back to the Hurricane Electric page, and clicking “IPv6 Port scan” under “User Functions” on the left. It asks for the IPv6 address to check, so put your end of the tunnel (in my case, 2001:470:1f10:294::2). I put it in, and the submit button didn’t light up, so I hit tab, which made it start checking the IP. The IP was valid, and I could click submit, so I did.

The output on the Nmap window came back like this:

Starting Nmap 5.00 ( http://nmap.org ) at 2012–03–11 19:17 PDT

Interesting ports on standaloneSA-2-pt.tunnel.tserv9.chi1.ipv6.he.net (2001:470:1f10:294::2):

Not shown: 998 closed ports

PORT STATE SERVICE

22/tcp open ssh

80/tcp open http Nmap done: 1 IP address (1 host up) scanned in 17.62 seconds

Exactly what I was looking for!

So there you have it. Around 5 minutes to set up IPv6 on a web server, and a quick walkthrough of the new HP Cloud beta. I think it has a lot of potential, and I’m looking forward to seeing where HP takes it. You can watch as news comes out by checking the HP Cloud Blog. They’re also at SXSW , which I really want to go to next year. I had a really great time in Austin for Tech Field Day 7…I can’t imagine the spectacle that must be South by SouthWest.

Anyway, I hope you enjoyed this walkthrough. Let me know if you have any questions about this that I can answer (or find you the answer to)!