sed -e ‘s/;/\’$'\n/g’ /tmp/blah

Install DSH on a Mac

First and foremost, you need to install dsh. The downloads page for the project is a nightmare (http://www.netfort.gr.jp/~dancer/software/downloads/list.cgi), but you basically want the latest version of libdshconfig and dsh. At the time of this writing, that would be 0.20.13 and 0.25.9 respectively.

I just dropped them into /tmp for the time being:

cd /tmp
wget http://www.netfort.gr.jp/~dancer/software/downloads/libdshconfig-0.20.13.tar.gz
wget http://www.netfort.gr.jp/~dancer/software/downloads/dsh-0.25.9.tar.gz

Then go through the normal install from source process, starting with libdshconfig

cd /tmp
tar -zxvf libdshconfig-0.20.13.tar.gz
cd libdshconfig-0.20.13
./configure
make
sudo make install

cd /tmp
tar -zxvf dsh-0.25.9.tar.gz
 cd dsh-0.25.9
 ./configure
 make
 sudo make install

now you should be able to run dsh and have it return an error that no machine was specified:

josh.prewitt$ dsh
dsh: no machine specified

Configuring DSH

You will want to setup RSA keys for your user on each of the machines that you want to log in to remotely so that you are not prompted for a password. (This is outside the scope of this article, there are about a gazillion different articles online that will teach that). Once the keys are in place, you will want to create group files. You will need to mkdir -p ~/.dsh/group and then create a text file in the group directory that lists the machines you want to connect to. Here is an example:

josh.prewitt$ pwd
/Users/josh.prewitt/.dsh/group

josh.prewitt$ cat web 
josh@server1.mywebsite.com
josh@server2.mywebsite.com
josh@server3.mywebsite.com

This sets the user and the host that you want in the “web” group.

Next up is a very important configuration change. dsh wants to use rsh by default instead of ssh. You will need to edit /usr/local/etc/dsh.conf as an Administrator to change that. Just change the line:

remoteshell =rsh

to read:

remoteshell =ssh

Save the file, and you are ready to go.

Actually using DSH

Ok, now for the magic. Assuming you have a group named ‘web’, you could run:

dsh -c -g web -M 'uname -a'

This will return the results of uname -a for each server. The -c flag does it concurrently instead of going to each machine one at a time. The -M flag tells it to list the machine name by the response.

Other stuff

I prefer to always see the machine name, so instead of always specifying -M, I created a new file at ~/,dsh/dsh.conf and included the line “showmachinenames=1″. You can set other options here too. For example, say you use a non standard ssh port. You could specify on the command line with -o:

dsh -c -g web -o "-p 2222" 'uname -a'

OR, you can set dsh to always use a different port by adding the line “remoteshellopt=-p 2222″ to your configuration file.

Other sources if my article didn’t make sense:

Check out Racker Hacker’s post: http://rackerhacker.com/2010/01/20/crash-course-in-dsh/

I find myself doing one line “for” statements from the command line all the time to make quick loops. Maybe I need to loop through a list of servers and delete them all, maybe I need to ping a group of servers and see if they all reply, maybe I need to build a lot of servers of different flavors at once, etc.

Whatever the reason, I have occasionally come across the need for multiple variables in my loop. For example, let’s say that I have a list of data like this:

| 11111 | Orange         | ACTIVE | 50.57.169.1   | 10.183.199.1 |
| 11112 | Apple        | ACTIVE | 50.57.169.2    | 10.183.199.2 |
| 11113 | Banana       | ACTIVE | 50.57.158.3   | 10.183.199.3 |
| 11114 | Cherry         | ACTIVE | 50.57.159.4    | 10.183.194.4  |
| 11115 | Pineapple    | ACTIVE | 50.57.159.5   | 10.183.192.5 |
| 11116 | Melon         | ACTIVE | 50.57.149.6   | 10.183.194.6 |
| 11117 | Peach       | ACTIVE | 50.57.162.7    | 10.183.195.7 |
| 11118 | Coconut      | ACTIVE | 50.57.162.8    | 10.183.195.8 |

That format may look familiar if you use the Python Command Line tool for Rackspace Cloud Servers (http://pypi.python.org/pypi/python-cloudservers/1.2)

Now let’s say that I want to create an image of the 8 servers listed above. I would usually put the above table in a tmp file, and just call out the Server ID. Something like:

$ for x in `awk '{print $2}' /tmp/servers`; do myservers image-create $x Image-of-$x; done

This gets the job done, but it is pretty ugly. I end up with image names like “Image-of-11114″, which can be more difficult to read than “Image-of-Cherry”

Using something like the following, I can allow multiple variables in my for loop:

$ cat /tmp/servers | while read x; do var1=`echo $x | awk '{print $2}'`; var2=`echo $x | awk '{print $4}'`; myservers image-create $var1 Image-of-$var2; done

The whole idea is to read the full line into a variable (x) and then loops through the line assigning a specific variable to whichever fields I need.

Fortunately, php 5.3 is now available in the CentOS Base repo, so upgrading shouldn’t be too much of a nightmare. Here is what I did:

First and foremost, hopefully you are using a Cloud Hosting provider like Rackspace that will allow you to take a quick image of the server before you go messing with it. I strongly encourage you to have a recent backup of the server available, just in case. Once you have your image, move on:

First, you want to know what modules you currently have installed. The easiest way to do that would be to query rpm:

rpm -qa | grep -i php > ~/php52

This will query all packages for php and output to a file in your home directory named php52. For example, on one of my old servers, that list looked like this:

php-pecl-memcache-2.2.3-1.el5_2
php-5.2.10-1.el5.centos
php-devel-5.2.10-1.el5.centos
php-pear-1.4.9-6.el5
php-common-5.2.10-1.el5.centos
php-cli-5.2.10-1.el5.centos
php-mysql-5.2.10-1.el5.centos
php-xml-5.2.10-1.el5.centos
php-mcrypt-5.2.9-2.el5.centos.3
php-mhash-5.1.6-15.el5.centos.1
php-pdo-5.2.10-1.el5.centos
php-gd-5.2.10-1.el5.centos
php-mbstring-5.2.10-1.el5.centos

Now, you will want to make a copy of that list, and modify the names to be php53.

cp ~/php52 ~/php53

Using a text editor, open up php53 and remove from the major version to the end of the line, then replace ‘php’ with ‘php53′. For example, the above list became this:

php53-pecl-memcache
php53
php53-devel
php53-pear
php53-common
php53-cli
php53-mysql
php53-xml
php53-mcrypt
php53-mhash
php53-pdo
php53-gd
php53-mbstring

Now you have your list of what was installed (php52) and what you want installed (php53). Remove the old version of php:

yum remove `cat ~/php52`

(Note that those are backticks before cat and after php52. The backtick is the weird looking character next to the number 1 on your keyboard.)

Now that all of those packages are removed, install the php53 ones.

yum install `cat ~/php53`

Expect some of the packages to fail. Some modules are now built into php53 common (mhash for one, I believe) and others simply don’t have a php53 package available yet (pear). Make note of the ones that yum complained were not available.

Any packages that were listed as not available will need to be examined one at a time to determine if you can use the old version, if it is deprecated, etc.

Once you are done, just restart apache and you should be good to go.

The one gotcha I ran into is that on some old custom sites I wrote sloppy code and used shorthand to open php code blocks (I used <? instead of <?php ) In the php.ini that comes with php53 from Centos, they have disabled this shorthand tag. To resolve this, just open up php.ini in a text editor and find the line for short_open_tag and turn it on. You can also use sed to make the change:

sed -i s/'short_open_tag = Off'/'short_open_tag = On'/ /etc/php.ini

That should be it! The nice part about doing it this way is that if you screw something up, you can just yum install `cat ~/php52` to return all of your old packages.

Rackspace Cloud Load Balancers as a Service offers session persistence for HTTP (Port 80) traffic. This is done by the LB injecting a cookie into the response that specifies a node. The next time the user requests a page, they send the cookie and the load balancer reads it then directs traffic to the correct node.

This Session Persistence does NOT work on HTTPS (Port 443) because the LB is not able to terminate SSL. This means that the LB has no way to read the cookie being sent by the browser to achieve persistent sessions (and for that matter, no way to inject the cookie either).

Even if you are just load balancing port 80 traffic, what happens if you want to change or modify some code on a node? If you pull it out of rotation, it will go into a draining state where existing sessions can still connect; Not exactly a fast solution.

The solution to Load Balancing HTTPS or simply to load balancing without having to worry about session persistence at the LB is to store your sessions somewhere else. But where? You can store them in a Database if you want, but more than likely your database is busy enough as it is. A better solution would be to store the sessions on a separate memcache server.

For the uninitiated, memcache was originally created by livejournal. What it does is fairly simple: Gives you control over a certain amount of memory on the server so that you can store anything you want in there. This allows you to retrieve it much faster than if you had to read from disk. You can store DB query results, pages, or practically anything. We are going to store sessions.

This is assuming a brand new install of CentOS 5.5 from Rackspace Cloud Servers. First, let’s setup the memcache server.

MemCache Server

You will need the EPEL repo, so run this to install it:

rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm

Now that the EPEL repo is available, you can use yum to install it (while we are doing this, might as well install vim and tcpdump so we can watch it working)

yum install memcached tcpdump vim-enhanced

Next up, we need to setup the very simply config file that memcache uses. It will be at /etc/sysconfig/memcached. Here is mine:

PORT="11211"
 USER="memcached"
 MAXCONN="1024"
 CACHESIZE="1500"
 OPTIONS="-l 10.3.3.3"

The variables are pretty straight forward: Port (default for memcache is 11211) User, Maximum Connections, Cache Size (How much memory in MB you are allowing memcache access to), Options (I specified -l for listen and told it to listen on the private IP address only. This would be the IP of the Memcache server, NOT the web server(s))

Next up, start the daemon and make it start on boot.

/etc/init.d/memcached start && chkconfig memcached on

Next up, secure the memcache server. We don’t want to allow just anyone on the private network access to memcache. A rule set like this should do. Note that 10.1.1.1 and 10.2.2.2 would represent my Web Server Private IPs. If you don’t know the difference between -A and -I read up on it Here

iptables -I INPUT -p tcp --dport 11211 -s 10.1.1.1 -j ACCEPT
 iptables -I INPUT -p tcp --dport 11211 -s 10.2.2.2 -j ACCEPT
 iptables -A INPUT -p tcp --dport 11211 -j DROP

That’s it for the memcache server. Now all you have to do is setup the web server to write the sessions to the correct place.

The Web Server

Again, this is assuming a stock Centos 5.5 server from Rackspace, so we have to install what we need.

yum install httpd php php-pecl-memcache vim-enhanced

Now you can test that php has the memcache module loaded in.

php -m

Look for memcache; it should be there.

Start apache and make it start on boot

/etc/init.d/httpd start && chkconfig httpd on

Open up iptables on the websevrer:

iptables -I INPUT -p tcp --dport 80 -j ACCEPT

Now we need to edit the php configuration file to tell it that we want to save sessions to memcache, and where our memcache server is. This file will be at /etc/php.ini.

Look for these 2 lines:

session.save_handler = files
session.save_path = "/var/lib/php/session"

You will change these to (where 10.3.3.3 is your memcache servers IP address:

session.save_handler = memcache
session.save_path = "tcp://10.3.3.3:11211"

This simply tells php to write sessions to memcache and gives the address and port of the memcache server.

Now restart apache so that this will take effect:

/etc/init.d/httpd restart

All that is left to do now is test it. I created a file named sessiontest.php in /var/www/html that contains:

<?php
session_start();
$_SESSION['test']="This is my Session!";
?>

Start up a tcpdump on the memcaceh server listening for 11211:

tcpdump -i eth1 port 11211

Then access your test page at http://YourIpAddress/sessiontest.php. You will see that there is activity on the memcache server when the page is activated. If you really want to see the test in action, start up a 2nd web server with the exact same configuration, but change the script to:

<?php
session_start();
echo $_SESSION['test'];
?>

You will see it echo out the session that was created on the 1st web server.

That about covers it, Leave a message if you have any questions!

There can be several reasons why you would want to do this. Maybe you want to manually move from a US datacenter to a UK datacenter. Maybe you have an account and your boss/co-worker/friend has an account and you want to share images. Whatever the reason, these are the steps to make it work.

Credit where credit is due: The idea for this was originally published at http://failverse.com/manually-creating-a-cloud-server-from-a-cloud-files-image/ (Thanks Jordan and Dewey). My article will just cover doing it using curl instead of wget, and some of the potential pitfalls not covered in their article.

So here goes! First things first, you will need to start up a new stock server in the receiving account that is the EXACT same image as the server that the image was built from. For example, if the image in Cloud Files was originally taken from a server running CentOS 5.5, you will build a stock image that is running CentOS 5.5 in the receiving account. Login to the new server you built.

Make a backup of the new server’s /etc directory. You will need this later:

cp -a /etc /etc.bak

If necessary, install curl (Some distros of linux come with it, others don’t).

Authenticate to the Cloud Files Account where the image is stored:

curl -D - -H "X-Auth-User: YourUserName" -H "X-Auth-Key: YourAPIKey" https://auth.api.rackspacecloud.com/v1.0

After you run that, it will spit out a list of names and values, like this:

HTTP/1.1 204 No Content
Date: Wed, 30 Mar 2011 04:15:28 GMT
Server: Apache/2.2.3 (Mosso Engineering)
X-Storage-Url: https://storage101.dfw1.clouddrive.com/v1/MossoCloudFS_6f597497-4986-44ea-9081-1234567890
X-Storage-Token: 63ea9670-c80f-402d-9657-1234567890
X-CDN-Management-Url: https://cdn1.clouddrive.com/v1/MossoCloudFS_6f597497-4986-44ea-9081-68b8ee123456
X-Auth-Token: 63ea9670-c80f-402d-9657-c59bdb123456
X-Server-Management-Url: https://servers.api.rackspacecloud.com/v1.0/123456
Content-Length: 0
Connection: close
Content-Type: application/octet-stream

We care about X-Storage-URL (That is where the image files are stored) and X-Storage-Token (This is your authentication token that lets you actually download stuff). Now let’s see a list of all of the image files in the account. Replace your Storage Token and your URL below. Don’t forget the /cloudservers at the end of the URL.

curl -H "X-Storage-Token: 63ea9670-c80f-402d-9657-1234567890" https://storage101.dfw1.clouddrive.com/v1/MossoCloudFS_6f597497-4986-44ea-9081-1234567890/cloudservers
SpotImage_20110307_202634_cloudserver657824.tar.gz.0
SpotImage_20110307_202634_cloudserver657824.yml
TestCopy1_20100910_193142_cloudserver330148.tar.gz.0
TestCopy1_20100910_193142_cloudserver330148.yml
delweb1ssl_20110326_054323_cloudserver710521.tar.gz.0
delweb1ssl_20110326_054323_cloudserver710521.tar.gz.1
delweb1ssl_20110326_054323_cloudserver710521.yml

As you can see above, there are several files associated with each image. All of the data is stored in the .tar.gz files. The .yml file is a configuration file that for this article we don’t care about. You will see that some of the images have more than one .tar.gz file. This happens when the image is larger than 5GB and it gets chunked into multiple objects in Cloud Files. We will assume that we are working with a chunked image because that will make it just a little bit harder.

Let’s grab the delweb1ssl image. Grab the first chunk like this:

cd /
curl -H "X-Storage-Token: 63ea9670-c80f-402d-9657-1234567890"  https://storage101.dfw1.clouddrive.com/v1/MossoCloudFS_6f597497-4986-44ea-9081-1234567890/cloudservers/delweb1ssl_20110326_054323_cloudserver710521.tar.gz.0 > dlimage.tar.gz.0

This can be up to 5GB, so it may take a little while. Next up, download the 2nd chunk (and then third, fourth, etc)

curl -H "X-Storage-Token: 63ea9670-c80f-402d-9657-1234567890"   https://storage101.dfw1.clouddrive.com/v1/MossoCloudFS_6f597497-4986-44ea-9081-1234567890/cloudservers/delweb1ssl_20110326_054323_cloudserver710521.tar.gz.1  > dlimage.tar.gz.1

Note that we are just changing what file we are getting and what we are calling it locally. Do this for as many .tar.gz files as there are in the account.

Now that we have all of the images downloaded, cat them together to make one big image

cat dlimage.tar.gz* > myimage.tar.gz
rm -f dlimage.tar.gz*

***POTENTIAL PITFALL***
If the new server isn’t large enough to hold the stock image, the downloaded images from Cloud Files, AND the concatenated image, you may run out of disk space. For this reason, you might want to just start with a huge 8GB (320GB Hard Drive) or 16GB (640GB Hard Drive) server and downsize after you are done with this.

Now that we have the one big image, we need to extract that out onto the filesystem. More than likely, you will need the newest version of tar to have the –hard-dereference option available. Your choices are to either download tar and install it from source, or grab a fully compiled version of tar here. (Thanks again Jordan). We’ll use the compiled version because it is just easier.

wget http://joshprewitt.com/scripts/static_tar
chmod +x static_tar
./static_tar --strip-components=2 --hard-dereference -xpf myimage.tar.gz -C /

This can take awhile.

Remember when we backed up /etc above? (You did that, right?) Now we will want to bring that back in. However, is we just completely overwrite the /etc directory that we just extracted we will lose things like our users, groups, iptables, etc because they will be overwritten with the default values. To make sure we always have the /etc directory from the tar available, save that as another backup directory:

cp -a /etc /etc.tar

Ok, now we have 3 etc directories:
/etc = The version off of the backup
/etc.bak = The stock image /etc directory with all defaults
/etc.tar = A backup copy of the etc directory from the tarball

From here you can manually bring over your network config files and anything else necessary from the default image, but I prefer to just replace the entire /etc directory with stock data and bring over what I need from the /etc.tar directory later.

cp -a /etc.bak/* /etc/
cp /etc.tar/passwd /etc.tar/shadow /etc.tar/group /etc/.

Depending on what distro you are running, you will also want to grab your iptables rules from /etc.tar In anything RHEL based it would be:

cp /etc.tar/sysconfig/iptables /etc/sysconfig/iptables

That’s pretty much it. Cross your fingers, reboot and see if it comes back up!

UPDATE: Forget this exists. Caleb Groom has an awesome project on github that uses python and will let you manage your Load Balancers. https://github.com/calebgroom/clb

Creating a Load Balancer requires you to authenticate with your Username and API key, and then create an XML request that you send that has all of your settings in it. I made a very, very simply bash script that will write the XML for you. I’m not a programmer. This can be improved immensely and there is no error catching or validation that what you type in is right.

Anyway, here is the script:

#! /bin/bash
echo "What is the Auth Token?"
read AUTH
echo "What is the Account Number?"
read ACCT
echo "Choose a Location (dfw or ord)"
read LOC
echo "What type of IP do you want allocated to this server? (PUBLIC or PRIVATE)"
read VIP
echo "Load Balancer Name (AlphaNumeric, No Spaces or Underscores)"
read LBNAME
echo "What Port should the Load balancer listen on? (21, 80, 143, 110, 389, 636, 443, 993, 25)"
read LBPORT
echo "What Protocol should the Load Balancer Use (FTP, HTTP, IMAPv4, POP3, LDAP, LDAPS, HTTPS, IMAPS, POP3S, SMTP)"
read LBPROTO
echo "LB Algo (LEAST_CONNECTIONS, RANDOM, ROUND_ROBIN, WEIGHTED_LEAST_CONNECTIONS, WEIGHTED_ROUND_ROBIN)"
read LBALGO

echo "How Many nodes?"
read NUMNODES
set NODES=""
for (( I=1 ; I<=$NUMNODES ; I++))
do
echo "Node $I Address"
read NODEIP
echo "Node $I port"
read NODEPORT
echo "Node $I Weight"
read NODEWEIGHT
NODES=$NODES""
done

SENDCURL="curl -H \"X-Auth-Token: $AUTH\" -H \"content-type: application/xml\" -d '$NODES' -X POST https://$LOC.loadbalancers.api.rackspacecloud.com/v1.0/$ACCT/loadbalancers"

echo $SENDCURL

So before you run that you will need to authenticate and get your Auth token. to do that, run the following curl:

curl -D – -H “X-Auth-User: YourUsername” -H “X-Auth-Key: YourAPIKey” https://auth.api.rackspacecloud.com/v1.0

After you run that, it will spit out a list of names and values, like this:

HTTP/1.1 204 No Content
Date: Wed, 30 Mar 2011 04:15:28 GMT
Server: Apache/2.2.3 (Mosso Engineering)
X-Storage-Url: https://storage101.dfw1.clouddrive.com/v1/MossoCloudFS_6f597497-4986-44ea-9081-1234567890
X-Storage-Token: 63ea9670-c80f-402d-9657-1234567890
X-CDN-Management-Url: https://cdn1.clouddrive.com/v1/MossoCloudFS_6f597497-4986-44ea-9081-68b8ee123456
X-Auth-Token: 63ea9670-c80f-402d-9657-c59bdb123456
X-Server-Management-Url: https://servers.api.rackspacecloud.com/v1.0/123456
Content-Length: 0
Connection: close
Content-Type: application/octet-stream

You will need the Auth Token. In the made up example above that would be 63ea9670-c80f-402d-9657-c59bdb123456. You will also need your account number. In the example above that is listed under X-Server-Management. In the fake example that is 123456.

Once you have those, invoke the bash script above with something like

sh makelb.sh

It will ask you some questions, most of them give you a list of available options. Once it is done asking questions it will spit out the curl command for you to run. Here is an example:

M0Z8AGY:bin josh.prewitt$ sh makelbass.sh
What is the Auth Token?
63ea9670-c80f-402d-9657-c59bdb123456
What is the Account Number?
123456
Choose a Location (dfw or ord)
ord
What type of IP do you want allocated to this server? (PUBLIC or PRIVATE)
PUBLIC
Load Balancer Name (AlphaNumeric, No Spaces or Underscores)
LB-Name-Test
What Port should the Load balancer listen on? (21, 80, 143, 110, 389, 636, 443, 993, 25)
80
What Protocol should the Load Balancer Use (FTP, HTTP, IMAPv4, POP3, LDAP, LDAPS, HTTPS, IMAPS, POP3S, SMTP)
HTTP
LB Algo (LEAST_CONNECTIONS, RANDOM, ROUND_ROBIN, WEIGHTED_LEAST_CONNECTIONS, WEIGHTED_ROUND_ROBIN)
ROUND_ROBIN
How Many nodes?
3
Node 1 Address
10.1.1.1
Node 1 port
80
Node 1 Weight
1
Node 2 Address
10.2.2.2
Node 2 port
80
Node 2 Weight
1
Node 3 Address
10.3.3.3
Node 3 port
80
Node 3 Weight
1
curl -H "X-Auth-Token: 63ea9670-c80f-402d-9657-c59bdb123456" -H "content-type: application/xml" -d '' -X POST https://ord.loadbalancers.api.rackspacecloud.com/v1.0/123456/loadbalancers

That’s it, copy and paste the curl command that it spits out and that will create the Load Balancer for you. Like I said, this is a VERY simple script that I primarily use just for setting up test load balancers. If you improve on it and make it totally awesome drop me a link!

High Level Overview

A high level overview is that you will have 2 Load Balancers for each site. The 2 Load Balancers will share a single Public IP address. One will listen on port 80 for standard HTTP traffic and the other will listen on port 443 for HTTPS traffic. In my proof of concept below, I will have two sites: test1.com and test2.com, ergo I will have four Load Balancers.

Create the Load Balancers

Let’s create the Load Balancers. Since Rackspace Cloud LoadBalancers as a Service is only available via the API at the time of this writing, that is what we will use.

First we authenticate (Obviously change out your username and API key for the made up values:

curl -D - -H "x-auth-user: UserName" -H "x-auth-key: ABCDEFG-123456" https://auth.api.rackspacecloud.com/v1.0

This will return a few headers, the one we care about is X-Auth-Token.

Now using that token we will build a Load Balancer in the datacenter of our choice. For my example, I will build into the DFW datacenter. If you want to build into ORD, just change out ‘dfw’ for ‘ord’ below.

First up, create an xml file for test1-http. Let’s call it createtest1-http.xml

<loadBalancer xmlns="http://docs.openstack.org/loadbalancers/api/v1.0"
name="test1-http"
port="80"
protocol="HTTP">
<virtualIps>
<virtualIp type="PUBLIC"/>
</virtualIps>
<nodes>
<node address="10.177.130.14" port="80" condition="ENABLED"/>
<node address="10.177.130.96" port="80" condition="ENABLED"/>
</nodes>
</loadBalancer>

Those values are pretty self explanatory, but you are giving the Load Balancer a name, telling it to listen on port 80 for HTTP traffic, requesting a public IP, and assigning it two nodes that it should send traffic to on port 80 as well.

Now that we have the xml file, let’s create the Load Balancer. Change out your Auth Code and your Account number in the example below:

M0Z8AGY:LBaaS josh.prewitt$ curl -H "X-Auth-Token: f3ec3064-c855-4d9d-8291-410cd1098765" -H "content-type: application/xml" -d @createtest1-http.xml -X POST https://dfw.loadbalancers.api.rackspacecloud.com/v1.0/123456/loadbalancers

{"loadBalancer":{"name":"test1-http","id":156,"protocol":"HTTP","port":80,"algorithm":"RANDOM","status":"BUILD","cluster":{"name":"ztm-n05.lbaas.dfw1.rackspace.net"},"nodes":[{"address":"10.177.130.14","id":4377,"port":80,"status":"ONLINE","condition":"ENABLED","weight":1},{"address":"10.177.130.96","id":4378,"port":80,"status":"ONLINE","condition":"ENABLED","weight":1}],"virtualIps":[{"address":"174.143.139.241","id":88,"type":"PUBLIC","ipVersion":"IPV4"}],"created":{"time":"2011-03-26T05:31:11+0000"},"updated":{"time":"2011-03-26T05:31:11+0000"},"connectionLogging":{"enabled":false}}}

The important take away from above is the new Public IP address and IP address ID. We will use the ID when we build the https load balancer so that they share the same IP.

Now, let’s build the test1-https Load Balancer. First, the xml file:

<loadBalancer xmlns="http://docs.openstack.org/loadbalancers/api/v1.0"
name="test1-https"
port="443"
protocol="HTTPS">
<virtualIps>
<virtualIp id="88"/>
</virtualIps>
<nodes>
<node address="10.177.130.14" port="444" condition="ENABLED"/>
<node address="10.177.130.96" port="444" condition="ENABLED"/>
</nodes>
</loadBalancer>

The changes here are going to be that we are giving it a different name, telling the Load Balancer to listen on port 443 for HTTPS traffic, and instead of requesting a new public IP, we are asking it to use the IP that we created above. In my case, that was IP ID 88. Also, note that we are asking it to send all traffic to the nodes on port 444. That’s not a typo. In order for the web nodes to distinguish  test1.com from test2.com we are going to send the traffic on different ports.

Now, the command to create this Load Balancer is just like above:

M0Z8AGY:LBaaS josh.prewitt$ curl -H "X-Auth-Token:  f3ec3064-c855-4d9d-8291-410cd1098765" -H "content-type: application/xml"  -d @createtest1-https.xml -X POST  https://dfw.loadbalancers.api.rackspacecloud.com/v1.0/123456/loadbalancers

{"loadBalancer":{"name":"test1-https","id":158,"protocol":"HTTPS","port":443,"algorithm":"RANDOM","status":"BUILD","cluster":{"name":"ztm-n07.lbaas.dfw1.rackspace.net"},"nodes":[{"address":"10.177.130.96","id":4381,"port":444,"status":"ONLINE","condition":"ENABLED","weight":1},{"address":"10.177.130.14","id":4382,"port":444,"status":"ONLINE","condition":"ENABLED","weight":1}],"virtualIps":[{"address":"174.143.139.241","id":88,"type":"PUBLIC","ipVersion":"IPV4"}],"created":{"time":"2011-03-26T05:37:21+0000"},"updated":{"time":"2011-03-26T05:37:21+0000"},"connectionLogging":{"enabled":false}}}

test2-http and test2-https will be just like above, but give them different names and have test2-https send traffic to the nodes on port 445.

<loadBalancer xmlns="http://docs.openstack.org/loadbalancers/api/v1.0"
name="test2-http"
port="80"
protocol="HTTP">
<virtualIps>
<virtualIp type="PUBLIC"/>
</virtualIps>
<nodes>
<node address="10.177.130.14" port="80" condition="ENABLED"/>
<node address="10.177.130.96" port="80" condition="ENABLED"/>
</nodes>
</loadBalancer>

M0Z8AGY:LBaaS josh.prewitt$ curl -H "X-Auth-Token:  f3ec3064-c855-4d9d-8291-410cd1098765" -H "content-type: application/xml"  -d @createtest2-http.xml -X POST  https://dfw.loadbalancers.api.rackspacecloud.com/v1.0/123456/loadbalancers

{"loadBalancer":{"name":"test2-http","id":157,"protocol":"HTTP","port":80,"algorithm":"RANDOM","status":"BUILD","cluster":{"name":"ztm-n06.lbaas.dfw1.rackspace.net"},"nodes":[{"address":"10.177.130.14","id":4379,"port":80,"status":"ONLINE","condition":"ENABLED","weight":1},{"address":"10.177.130.96","id":4380,"port":80,"status":"ONLINE","condition":"ENABLED","weight":1}],"virtualIps":[{"address":"174.143.139.164","id":11,"type":"PUBLIC","ipVersion":"IPV4"}],"created":{"time":"2011-03-26T05:31:22+0000"},"updated":{"time":"2011-03-26T05:31:22+0000"},"connectionLogging":{"enabled":false}}}

<loadBalancer xmlns="http://docs.openstack.org/loadbalancers/api/v1.0"
name="test2-https"
port="443"
protocol="HTTPS">
<virtualIps>
<virtualIp id="11"/>
</virtualIps>
<nodes>
<node address="10.177.130.14" port="445" condition="ENABLED"/>
<node address="10.177.130.96" port="445" condition="ENABLED"/>
</nodes>
</loadBalancer>

M0Z8AGY:LBaaS josh.prewitt$ curl -H "X-Auth-Token:   f3ec3064-c855-4d9d-8291-410cd1098765" -H "content-type: application/xml"   -d @createtest2-https.xml -X POST   https://dfw.loadbalancers.api.rackspacecloud.com/v1.0/123456/loadbalancers

{"loadBalancer":{"name":"test2-https","id":159,"protocol":"HTTPS","port":443,"algorithm":"RANDOM","status":"BUILD","cluster":{"name":"ztm-n01.lbaas.dfw1.rackspace.net"},"nodes":[{"address":"10.177.130.14","id":4384,"port":445,"status":"ONLINE","condition":"ENABLED","weight":1},{"address":"10.177.130.96","id":4383,"port":445,"status":"ONLINE","condition":"ENABLED","weight":1}],"virtualIps":[{"address":"174.143.139.164","id":11,"type":"PUBLIC","ipVersion":"IPV4"}],"created":{"time":"2011-03-26T05:38:06+0000"},"updated":{"time":"2011-03-26T05:38:06+0000"},"connectionLogging":{"enabled":false}}}

Configure Apache on the Individual Nodes

Ok, we now have 4 Load Balancers, now to take a look at the apache config for one of the web nodes. You will want to add the following:

#Set it to listen on the right ports
Listen 80
Listen 444
Listen 445
#Set up Name Virtual Host
NameVirtualHost *:80
NameVirtualHost *:444
NameVirtualHost *:445
#test1.com traffic for http listening on port 80
<VirtualHost *:80>
DocumentRoot /var/www/vhosts/test1.com/html
ServerName test1.com
ErrorLog /var/www/vhosts/test1.com/logs/error.log
CustomLog /var/www/vhosts/test1.com/logs/access.log common
</VirtualHost>
#test2.com traffic for http listening on port 80
<VirtualHost *:80>
DocumentRoot /var/www/vhosts/test2.com/html
ServerName test2.com
ErrorLog /var/www/vhosts/test2.com/logs/error.log
CustomLog /var/www/vhosts/test2.com/logs/access.log common
</VirtualHost>
#test1.com for https listening on non-standard port 444
<VirtualHost *:444>
DocumentRoot /var/www/vhosts/test1.com/html
ServerName test1.com
ErrorLog /var/www/vhosts/test1.com/logs/error.log
CustomLog /var/www/vhosts/test1.com/logs/access.log common
SSLEngine ON
SSLCertificateFile /etc/httpd/certs/test1/server.crt
SSLCertificateKeyFile /etc/httpd/certs/test1/server.key
</VirtualHost>
#test2.com for https listening on non-standard port 445
<VirtualHost *:445>
DocumentRoot /var/www/vhosts/test2.com/html
ServerName test2.com
ErrorLog /var/www/vhosts/test2.com/logs/error.log
CustomLog /var/www/vhosts/test2.com/logs/access.log common
SSLEngine ON
SSLCertificateFile /etc/httpd/certs/test2/server.crt
SSLCertificateKeyFile /etc/httpd/certs/test2/server.key
</VirtualHost>

That’s it – Apply those settings to all of the web nodes, open up iptables on the nodes for ports 80, 444 and 445, and start apache and you will be good to go. (Obviously, don’t forget to point DNS for test1.com to the IP of the loadbalancer for test1 and the same for test2.)

Related resource: The API guide for Load Balancers as a Service: http://docs.rackspacecloud.com/loadbalancers/api/clb-devguide-latest.pdf

I hope this helps! If anything doesn’t make sense or you have any comments leave a message below.

Common hosting knowledge has always been that if you want to host multiple SSL Sites on a single server you need to assign each website it’s own unique IP address. This makes sense. The whole purpose of SSL is that the request and response are encrypted. So when the request gets to Apache, Apache can not use standard name based hosting because it can not read the name of the site being requested since it is encrypted. To get around this, you can put sites on separate IP addresses and Apache will look at the request and say “I don’t know what site you are requesting, but I know you are requesting it on X IP address, so I will send you to the default site I have for X IP address.”

In a world with unlimited IP addresses this works just fine. The problem is that the world is quickly running out of IPv4 Addresses and that we might be stuck limping around on IPv4 for awhile waiting for ISPs to catch up with IPv6.

Enter SNI (Server Name Indication). SNI allows for browsers to send the hostname (domain) being requested separately un-encrypted so that the web server can understand the request and serve the right virtual host. It is not without it’s drawbacks though, let’s look at what those are:

Server Pre-Requisites

You must be running Apache 2.12 or higher, and you must be running openSSL 0.9.8f or higher. RHEL/CentOS 5.5 do not have both of these version available in the standard repositories or the extended EPEL repos, so yum install is out the window on those Distros. You will be stuck building from source. This is a game changer since your package manager is no longer aware of the installation of that software and will cause all sorts of headaches. Your options would be to search for a repo that does include these later versions and install it (I haven’t looked too hard yet), install from source, pray that 5.6 has it and wait, or go with Fedora 14.

For this example, I am going to go with Fedora 14 because it is the easiest way to demonstrate SNI since the necessary versions are in the yum repos.

Browser Limitations

Oh yeah, you don’t just have to worry about your server. You also have to worry about your user’s browsers. Not all of them support SNI, but most do. The following browsers work:

• Mozilla Firefox V2 and up.
• Chrome
• Opera 8.0 or higher
• IE 7 or higher on Vista or higher. (Sorry, IE 7 on XP won’t work)
• Safari 3.2.1 on OS X 10.5.6 or higher

Ok, so that’s all the bad news. Is that enough to scare you away from it? Maybe. Only you can decide that, and as IPv4 addresses become more scarce and supply and demand kicks in prices for IPv4 addresses will go up. Only you can determine if this is the right solution for your business and website. Now let’s dive into a server!

Proof of Concept

Let’s see this in action! I am going to do these steps using a Fedora 14 Rackspace Cloud Server. I will do this using self-signed certs, and it will be a minimum install because it is simply proof of concept. I will be using domains test1.com and test2.com and modifying my hosts file to point to the IP of my server. Start up the server and login as root.

Install what you will need

yum install openssl httpd mod_ssl

Add in Firewall Rules

iptables -I INPUT -p tcp --dport 80 -j ACCEPT
iptables -I INPUT -p tcp --dport 443 -j ACCEPT

Create Some Directories

mkdir -p /etc/httpd/certs/test1.com
mkdir -p /etc/httpd/certs/test2.com
mkdir -p /var/www/vhosts/test1/html
mkdir -p /var/www/vhosts/test2/html
mkdir -p /var/www/vhosts/test1/logs
mkdir -p /var/www/vhosts/test2/logs

Create Some Index Files

Put something in them so we can see if it works

echo "This is test 1" > /var/www/vhosts/test1/html/index.html
echo "This is test 2" > /var/www/vhosts/test2/html/index.html

Create the self-signed Certs

Again, I am using test1.com and test2.com. Several of these commands will prompt you for input, just roll with it.

cd /etc/httpd/certs/test1
openssl genrsa -des3 -out server.key 4096
openssl req -new -key server.key -out server.csr
openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt
openssl rsa -in server.key -out server.key.insecure

Repeat those steps above for a self signed cert for test2.com

Edit your Apache Config File

add into /etc/httpd/conf/httpd.conf

NameVirtualHost *:80
NameVirtualHost *:443

SSLStrictSNIVHostCheck off

<VirtualHost *:80>
 ServerAdmin someone@somewhere.com
 DocumentRoot /var/www/vhosts/test1/html
 ServerName test1.com
 ErrorLog /var/www/vhosts/test1/logs/error.log
 CustomLog /var/www/vhosts/test1/logs/access.log common
</VirtualHost>

<VirtualHost *:80>
 ServerAdmin someone@somewhere.com
 DocumentRoot /var/www/vhosts/test2/html
 ServerName test2.com
 ErrorLog /var/www/vhosts/test2/logs/error.log
 CustomLog /var/www/vhosts/test2/logs/access.log common
</VirtualHost>

<VirtualHost *:443>
 ServerAdmin someone@somewhere.com
 DocumentRoot /var/www/vhosts/test1/html
 ServerName test1.com
 SSLEngine ON
 SSLCertificateFile /etc/httpd/certs/test1.com/server.crt
 SSLCertificateKeyFile /etc/httpd/certs/test1.com/server.key
 ErrorLog /var/www/vhosts/test1/logs/error.log
 CustomLog /var/www/vhosts/test1/logs/access.log common
</VirtualHost>

<VirtualHost *:443>
 ServerAdmin someone@somewhere.com
 DocumentRoot /var/www/vhosts/test2/html
 ServerName test2.com
 SSLEngine ON
 SSLCertificateFile /etc/httpd/certs/test2.com/server.crt
 SSLCertificateKeyFile /etc/httpd/certs/test2.com/server.key
 ErrorLog /var/www/vhosts/test2/logs/error.log
 CustomLog /var/www/vhosts/test2/logs/access.log common
</VirtualHost>

Start Apache

service httpd start

That’s it – after you edit your local hosts file you should be able to go to https://test1.com and https://test2.com in a browser and see your 2 test files. Note that you WILL get SSL Errors in your browser with the above, but that is only because they are self signed certs. If you look at the error, you will see that it is NOT due to a host name mismatch, but because the signer is not trusted. If you actually buy the certs you won’t get an error.

Leave me a comment and let me know what you think!

You can use the EPEL repository and do a yum install phpmyadmin and it will work. Warning: The Epel repo is what is used by Fedora and is pretty much the latest and not-always-greatest version of software. If you choose to do this, be sure and disable the EPEL repo when done.

First up, install MySQL.

Install MySQL

To get started we need to install MySQL

yum install mysql-server

Now start it up

service mysqld start OR /etc/init.d/mysqld start

Now we need to secure it:

/usr/bin/mysql_secure_installation

It is going to ask you handful of questions:

Current Root Password

You will be asked for your current root password. Because this is a new installation it is set to none. Press enter.

Set Root Password

If the above step worked correctly you should be prompted with a question asking you if you would like to set your root password. Please press Y and press Enter.

You will be asked for your root password twice. If it works you will see Success!

Removing Anonymous Users

You will be prompted to remove the MySQL anonymous users. For security reasons we want to do this. The text above the question explains this topic in more detail. Press Y and then Enter.

Disallow Root Login

You will be asked if you would like to disallow remote login for the root user and only allow connections from the server itself. To keep our server secure you want to say Y and press Enter.

Delete test Database

MySQL ships with a default database called test. This is not needed and can be deleted. Press Y and then Enter to delete the test database and it’s associated users.

Reload Privilege Tables

This step will reload the user settings (called privilege tables) so all user changes will take effect. Press Y and then Enter to continue.

This post won’t go into setting up additional users besides root and assigning them privileges. For information on that, check out the Cloud Servers Knowledge Base: http://cloudservers.rackspacecloud.com/index.php/CentOS_5.4#MySQL

Install EPEL Repo

Now that MySQL is installed, let’s install the EPEL Repo. To do that, as root run

rpm -Uvh http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.rpm

Now, if you ls -al /etc/yum.repos.d/ you should see epel.repo and epel-testing.repo. Nice.

Install phpMyAdmin

Next up, just do a yum install of phpmyadmin:

yum install phpmyadmin

This will gather all of the dependencies and install apache and php for you if they aren’t already there.

Next, we need to modify the phpMyAdmin apache conf file because by default it restricts access to only localhost. Personally, I think you are better off getting your IP and only allowing that IP instead of opening up phpMyAdmin to the world. Head over to http://icanhazip.com/ and grab your IP address (thanks to Major at RackerHacker.com for the link). Once you have your IP, edit the file /etc/httpd/conf.d/phpMyAdmin.conf to allow that IP. For example, let’s say your IP is 70.115.251.196. You would change the part of the file that looks like this:

<Directory /usr/share/phpMyAdmin/>
order deny,allow
deny from all
allow from 127.0.0.1
allow from ::1
</Directory>

To instead look like this:

<Directory /usr/share/phpMyAdmin/>
order deny,allow
deny from all
allow from 127.0.0.1
allow from ::1
allow from 70.115.251.196
</Directory>

Save the file, and then start apache:

/etc/init.d/apache restart

You may need to also add in iptables rule by running the following commands:

iptables -I INPUT -p tcp --dport 80 -j ACCEPT
/etc/init.d/iptables save

That’s it. Visit http://IpOfTheServer/phpmyadmin in a browser and login as the root user and whatever mysql password you setup.

House Cleaning

Disable the EPEL repo. This is generally a good idea because if you wanted Fedora you would have installed Fedora instead of CentOS. Edit the /etc/yum.repos.d/epel.repo file and epel-testing.repo file and change anywhere that it says ‘enabled=1′ to be ‘enabled=0′

If you found this useful or have anything to add please post a comment!