Apr 5 2012

April 5th 2012: OpenStack 2012.1 ‘Essex’ is here

THE ONLY WAY IS ESSEX

Apr 5 2012

New blog entry on openstack.org/blog: OpenStack Pulls It Out Of The Bag

You can read my newest blog entry on the trials and tribulations of my experience of OpenStack at http://www.openstack.org/blog/2012/04/openstack-community-pulls-it-out-of-the-bag/

OpenStack is a true Open Source Cloud Platform, backed by many companies who have full-time staff writing code and fixing bugs. It has a large community of intelligent minds powering OpenStack that you won’t find in any other community cloud ecosystem. They’re the rock stars of cloud computing.

Mar 28 2012

Screencast / Video of an Install of OpenStack Essex on Ubuntu 12.04 under VirtualBox

A 12 minute screencast showing an installation of OpenStack ‘Essex’ on Ubuntu 12.04 running on VirtualBox

OpenStack Essex Installation Screencast

Note that this screencast has no sound.

Configure VirtualBox with the following
Network Interfaces:
eth0 (nat)
eth1 host-only: 172.16.0.0/16
eth2 host-only: 10.0.0.0/8
Memory: 1536Mb
Hard Disk: 20Gb
System Processor (optional but recommended): Increase CPU from 1
Install Ubuntu 12.04, specifying eth0 as your default interface
Configure networking:
eth1 is your public network set to be 172.16.0.0/16
eth2 is your private VLAN
Run an update on the machine, and reboot
Install Git which allows you to pull down a script to perform the installation of OpenStack
Grab the script using the following:
git clone https://github.com/uksysadmin/OpenStackInstaller.git
Ensure you’re running the ‘essex’ version of the script by running: git checkout essex
Run the script with the following:
./OSinstall.sh -F 172.16.1.0/24 -f 10.1.0.0/16 -s 512 -t demo -v qemu
Upload an image using the test supplied script:
./upload_ubuntu.sh -a admin -p openstack -t demo -C 172.16.0.1
Log into the Dashboard: http://172.16.0.1/ with ‘demo/openstack’
Create your access keys
Edit the default security group (add in SSH access and ability to ping)
Launch your instance
Log into your new instance!

Mar 6 2012

OpenStack Essex Keystone Changes – script showing use

The latest release of OpenStack Essex has changed the way Keystone is managed. Rather than most of the work being done by nova-manage, this has moved to a ‘keystone’ client command (which can be found in the Ubuntu package, python-keystoneclient).

An example of its use can be seen here: https://github.com/uksysadmin/OpenStackInstaller/blob/essex/keystone-services.sh

Feb 9 2012

Updated OpenStackInstaller script for Precise and Essex installs

I’ve updated the OpenStackInstaller script which now gives you a Development (Trunk) OpenStack Essex installation on Ubuntu Precise (Currently Alpha 2) with the following

Nova Compute (and associated services)
Keystone
Glance

This set up allows you to use nova client tools to launch instances

Install Ubuntu Precise
apt-get update
apt-get dist-upgrade
reboot

(as root)

git clone https://github.com/uksysadmin/OpenStackInstaller.git

```
cd OpenStackInstaller
```
```
git checkout essex
```
```
./OSinstall.sh
```

A lot of this wouldn’t be possible without the help of people in #openstack on freenode.org.
For an equally awesome installation from scripts for a Diablo release view these scripts: https://github.com/managedit/openstack-setup

Dec 2 2011

OpenStack Auto Assign Floating IP Not Working in Diablo

Being able to spin up instances in OpenStack is one thing, but they’re not much use if you can’t connect to them using the public network you’ve assigned to it.

Unfortunately in Diablo, the flag –auto_assign_floating_ip=true causes instances to be stuck at pending, and the nova-network.log spews out the something like the following snippet:

(nova.rpc): TRACE:     raise exception.FloatingIpNotFoundForAddress(address=address)
(nova.rpc): TRACE: FloatingIpNotFoundForAddress: Floating ip not found for address
<nova.db.sqlalchemy.models.FloatingIp object at 0x2fc5d90>.

This is down to a bug introduced in Diablo, https://bugs.launchpad.net/nova/+bug/834633

The fix is simple though (tested on Ubuntu 11.10 running Python 2.7):

wget https://review.openstack.org/cat/1328%2C3%2Cnova/network/manager.py%5E0 -O nova_network_manager.zip
unzip nova_network_manager.zip
mv /usr/lib/python2.7/dist-packages/nova/network/manager.py{,.orig}
cp manager_new-305ad3be8272f0c69fa9caa8707994ee9233201f.py /usr/lib/python2.7/dist-packages/nova/network/manager.py
restart nova-network
restart nova-compute

Update 08/01/2012: Alternatively you can use the oneiric-proposed repository that has the fix in for Diablo:

Add the following to /etc/apt/sources.list

 deb http://archive.ubuntu.com/ubuntu oneiric-proposed main restricted universe multiverse

Then run

apt-get update
apt-get -y dist-upgrade

Then reboot your host.

Sep 27 2011

OpenStack Diablo, updates and work in progress!

It has been a while since I blogged, and in that time OpenStack has come on leaps and bounds with Diablo being the latest official release. This will change as I work pretty much full-time on testing OpenStack as an end-user (and day job as architect) based on Diablo. This will also help with some book projects that are in the pipe-line for which I’m very humbled and excited about. I’ll blog my experiences as I go along – after all, it’s the reason you’ve stumbled upon this corner of the internet in the first place to learn from my experiences in using OpenStack.
The project I’m working on will be based on Ubuntu running the latest release of OpenStack, Diablo (2011.3). I’ll be investigating Crowbar from Dell to see how remote bare-metal provisioning of OpenStack is coming along – a crucial element for this to be adopted in established enterprises where it is the norm to roll-out enterprise class software in this way. I’ll try to squeeze in JuJu too. Most importantly though is playing catch up on the raft of projects that are flowing through OpenStack from Keystone for authentication, Quantum (although probably more relevant to Essex as this develops) as well as playing catch up on where Swift, Glance and the Dashboard are.

Jun 27 2011

Mod_rpaf: Extract real-IP from behind reverse proxy/load balancer

There are many reasons why you’d want to front your Apache-based site behind a reverse proxy but one of the sacrifices you make in speed and security, you would by default lose a sensible way to extract the real IP (or at least have a very good chance to) of the client making the request. This is because your reverse proxy or load balancer in many situations becomes the client and to Apache this means you will only ever see the IP (the internal IP if its local to your Apache server farm) which become useless if you are doing analytics on the Apache logs or making decisions for the request based on the IP (for example Geo decisions, or ModSecurity).
To circumvent this, you’d want to use mod_rpaf (http://stderr.net/apache/rpaf/). This module is easily integrated into your Apache environment using the following method (Apache 2.x):

sudo apxs -i -c -n mod_rpaf-2.0.so mod_rpaf-2.0.c

And then configuring Apache to pick up this module:

# if DSO load module first:
LoadModule rpaf_module modules/mod_rpaf-2.0.so
RPAFenable On
RPAFsethostname Off
RPAFproxy_ips 10.10.10.1
RPAFheader X-Forwarded-For

This says look in the X-Forwarded-For header for the existence of the IPs listed in the RPAFproxy_ips line, and if found, pick up the external IP.

Unfortunately in practice this doesn’t work so well for a couple of reasons:

1. When auto-scaling an environment such as in Amazon, and you’re using something like ELB, you won’t know what internal IP the ELB will talk to Apache on – causing you to not be able to auto-configure mod_rpaf at install/run-time.
2. It makes an assumption on the external IP: it just takes the last IP seen on the X-Forwarded-For line.

Number 2 caused me issues because it is possible to have an internal IP address as the last entry on the X-Forwarded-For line – and if inspected properly, the external IP would be somewhere along the X-Forwarded-For line. To get around this and the ability to have more flexibility in the mod_rpaf config so that the code invoked to expose the real IP when an internal address was seen I created the following patch:

--- mod_rpaf-2.0.c 2011-06-23 13:51:53.000000000 +0100
 +++ mod_rpaf-2.0.c.new 2011-06-24 16:08:18.000000000 +0100
 @@ -71,6 +71,7 @@
 #include "http_protocol.h"
 #include "http_vhost.h"
 #include "apr_strings.h"
 +#include "string.h"
module AP_MODULE_DECLARE_DATA rpaf_module;
@@ -136,10 +137,14 @@
 }
static int is_in_array(const char *remote_ip, apr_array_header_t *proxy_ips) {
 - int i;
 + int i,len;
 + char tmp[16];
 char **list = (char**)proxy_ips->elts;
 for (i = 0; i nelts; i++) {
 - if (strcmp(remote_ip, list[i]) == 0)
 + len=strlen(list[i]);
 + strncpy(tmp,remote_ip,len);
 + tmp[len]='';
 + if (strcmp(tmp, list[i]) == 0)
 return 1;
 }
 return 0;
 @@ -155,6 +160,7 @@
 static int change_remote_ip(request_rec *r) {
 const char *fwdvalue;
 char *val;
 + int i;
 rpaf_server_cfg *cfg = (rpaf_server_cfg *)ap_get_module_config(r->server->module_config,
 &rpaf_module);
@@ -183,7 +189,10 @@
 rcr->old_ip = apr_pstrdup(r->connection->pool, r->connection->remote_ip);
 rcr->r = r;
 apr_pool_cleanup_register(r->pool, (void *)rcr, rpaf_cleanup, apr_pool_cleanup_null);
 - r->connection->remote_ip = apr_pstrdup(r->connection->pool, ((char **)arr->elts)[((arr->nelts)-1)]);
 + for(i=arr->nelts-1; i >= 0; i--) {
 + if (is_in_array( apr_pstrdup(r->connection->pool, ((char **)arr->elts)[i]), cfg->proxy_ips) == 0 )
 + r->connection->remote_ip = apr_pstrdup(r->connection->pool, ((char **)arr->elts)[i]);
 + }
 r->connection->remote_addr->sa.sin.sin_addr.s_addr = apr_inet_addr(r->connection->remote_ip);
 if (cfg->sethostname) {
 const char *hostvalue;

Patch and compile/install as follows:

patch -p1 < patch_mod_rpaf
sudo apxs -i -c -n mod_rpaf-2.0.so mod_rpaf-2.0.c

This allows you to use a modified config file which allows you to run Apache behind, say, ELB and it extracts the last seen external IP (i.e. not 10. 172. or 192.168.). Of course, edit to suit your particular environment:

# if DSO load module first:
LoadModule rpaf_module modules/mod_rpaf-2.0.so
RPAFenable On
RPAFsethostname Off
RPAFproxy_ips 10. 172. 192.168.
RPAFheader X-Forwarded-For

When it sees a line like

X-Forwarded-For: 192.168.100.227, 209.88.21.195, 10.58.59.219, 192.168.123.123

It will pick out 209.88.21.195 as the real IP.

System Administration and Architecture Blog

http://www.linuxservices.co.uk/

Category Archives: Cloud and Virtualization