IT KB Central

Deploying an Amazon MySQL RDS Instance

2011-08-10T07:19:00.000+10:00

by Semir H.

Preparation:

Decide in which Region you will create this.
Decide on the DB Engine (MySQL or Oracle).
For this tutorial I will use the following:

Multi AZ Deployment = Yes
Allocated Storage = 5 GB (minimum - good enough for this tutorial)
DB Instance Identifier = TestDB-Inst
Master Username = dbadmin
Password = whatever you want

Procedure:

Log into your Amazon Web Services (AWS) Management Console. Go to the Amazon RDS tab. Pick your Region. Click on “Launch DB Instance”.
In the “Engine Selection” pick MySQL and click on “Select”.
Fill in the “DB Instance Details” as per your needs. I’ll use the details I put down above. Click on “Continue”
Example:

On the “Additional Configuration” part leave everything at defaults (no need to put a DB name now). Click on “Continue”.

On the “Management Options” pick your Backup Retention Period (e.g. 1 day), Backup Window and Maintenance Window. Click on “Continue”.

Review your settings and if you are happy, launch the DB Instance.

DB Security Groups (connecting EC2 to RDS):

To make sure a particular EC2 Instance (in my case an Ubuntu Linux one) can connect to the Amazon RDS MySQL Instance we just created we need to create or modify an existing DB Security Group. I’ll just modify the default one.
Go to Amazon RDS tab and click on the “DB Security Groups” link.
Click on the “default” DB Security Group.
Under “Connection Type” pick “EC2 Security Group”.
Put in your Security Group name (in my case it was “linux sec grp”) and the AWS Account ID of the AWS account where this EC2 Security Group is. The number is a 12 digit number without any dashes.
Click on “Add”. If all goes well you should see that the connection you just defined will be authorised. Here’s an example (with my personal details blacked out):

This will essentially let any EC2 Instance (my Linux Instances) that are controlled by my “Linux Sec Grp” Security Group be able to communicate with my new MySQL RDS Instance.

To connect to the new MySQL Amazon RDS Instance (TestDB-Inst) we’ll need to find the Endpoint address. We do that by clicking on the DB Instance and looking under its Description. In my case it is “testdb-inst.cheuhkpk9v6o.ap-southeast-1.rds.amazonaws.com”.

Testing connecting:

# mysql -h testdb-inst.cheuhkpk9v6o.ap-southeast-1.rds.amazonaws.com -u dbadmin -p

Enter the password and there you go, you are now connected to your MySQL Instance.
You may now create databases for your projects.

Attach additional Volume(s) to AWS EC2 Linux (Ubuntu) Instance(s)

2011-08-07T23:31:00.000+10:00

by Semir H.

This quick tutorial will show you how to create a new EBS volume in AWS EC2 and attach it to an existing EBS backed Linux (Ubuntu) EC2 Instance.

Preparation:

Please note down which Availability Zone (AZ) your existing Instance is in. You will need to create the new volume in the same AZ. Also note down the Instance identifier (starts with “i”) for easier identification later.
Please also schedule some downtime for your Instance (if it is an important one) as you’ll need to shut it off while the volume is attached and it will need to be restarted at least once for testing.

Procedure:

As an example I have an Ubuntu Instance here with 8 GB of disk space that comes with the Ubuntu EC2 AMIs.

To create a new volume to add to the Instance go to Volumes section of the Amazon EC2 portion in the AWS Management Console. Click on “Create Volume”.

Fill in the desired size of the Volume (my example is 20 GB) and make sure you pick the correct AZ (same as where the Instance you will attach this to is). Ignore the Snapshot. Click on “Yes, Create” to make the Volume.

Once it is created you should right-click on it and select “Attach Volume”.
Select the correct Instance and put in the device name. The default for the Device will usually do.
Click on “Yes, Attach” to proceed.
Example:

After a bit you should see the Volume listed at attached to your Instance. Here’s an example of the original 8 GB Volume and the new 20 GB Volume attached to the same Instance:

Now go back to your Instance and start it up. Log in and check if the new Volume can be seen. The quickest way of doing it is to execute “fdisk -l” as a privileged user. The example below shows the original 8 GB and the new 20 GB device.

Of course, the new Volume is unusable in this state so we’ll need to create a mount point for it, create a file system for it and mount it. We’ll also make sure it auto-mounts after the box is restarted in the future.

First, we’ll create a new mount point. “mkdir /newdisk”. This will create a folder “newdisk” in the root of the current system.

We’ll then run cfdisk on the /dev/xvdf device to create a usable partition. Please see the cfdisk documentation for more details. I basically create a new primary partition (called xvdf1) using all the available space.
Then, we’ll create a file system for the new partition. Let’s go with ext4. Command is “mkfs.ext4 /dev/xvdf1”. You can now mount the partition under the folder we created earlier. Command is “mount /dev/xvdf1 /newdisk/”. Please check you can write to it.
Next, we’ll make sure the new partition is auto-mounted on system start-up. We do this in the /etc/fstab file. Just add the following line (no quotes):

“/dev/xvdf1 /newdisk ext4 defaults 1 2”

Please see the fstab documentation for options. You may want to use different options for your own environment.
Save the file. Restart the system to test it. When you log back in you should see the new partition mounted in the correct folder and you should be able to write to it.
Example (df -h):

How to change AWS EC2 Security Group of an existing Instance

2011-08-04T10:46:00.000+10:00

By Semir H.

Scenario:

You have a few pre-made Security Groups and one of your Instances needs to change from one to another.

Solution:

AWS EC2 does not have a way to easily switch these. You basically have to clone the Instance into an AMI and then deploy a new Instance out of that AMI, taking care to associate the new Instance with the desired Security Group at the time of creation.
You can delete the AMI and the associated Snapshot, if you desire so.

Process:

Create a Security Group with your desired port settings.

Clone your Instance by right clicking on it and choosing to create an Image (EBS AMI). It is best if the original Instance is turned off so that no data is lost.

After a bit of time your new AMI should be visible in the AMIs section. Please make sure you’re in the correct Region.

Right-click on your new AMI and pick “Launch Instance”.

Use the “Request Instance Wizard” to select settings you wish but please make sure you select the correct Security Group during this process.
You may also take this opportunity to change your Key Pair.

Finish the wizard and launch the Instance.

You should now see that the new Instance has the new Security Group associated with it.
Log into your new Instance and confirm that no data is missing.

Cleanup:

Once you are sure no data is missing and that you will not need your original Instance or the resulting AMI then you can delete both.
Also delete the Snapshot that was made during the cloning process.

AWS EC2 Security Group (Firewall) Design and Creation

2011-08-01T11:39:00.000+10:00

By Semir H.

This quick tutorial will show you how to open up some common ports on the AWS EC2 Firewalls, otherwise known as Security Groups. Please note that you should think about the Security Group design before you create Amazon Web Services (AWS) EC2 Instances. Once created and associated with a Security Group, there is no easy way (but there is a way) to associate an Instance with a different Security Group. I’ll show you how you can do it in another tutorial.

Let’s say we want to open TCP port 22 for SSH access to a Linux machine, ports 80 (HTTP) and 443 (HTTPS) for web access and port 10000 for Webmin. We want the HTTP/S ports to be open to anyone on the Internet but we want to restrict access over SSH and Webmin ports to a certain IP. The IP we will restrict it to will be 1.2.3.4 (obviously made up).

Procedure:

Log into your Amazon Web Service (AWS) Management Console.

Navigate to Security Groups in the NETWORKING & SECURITY section.

Click on the “Create Security Group” button.

Give it a Name and a Description. Leave the VPC option as “No VPC”. Click on “Yes, Create”. Example:

Select the newly created Security Group and click on the Inbound tab at the bottom of the page to create new rules.

HTTP(S) and SSH can be pre-selected from the “Create a new rule” drop-down box. Webmin port will be the custom option.

Finally, click on “Apply Rule Changes”.

To put in a single IP as the Source you need to put the netmask as /32.
So our fake 1.2.3.4 address will be entered as 1.2.3.4/32

As you add the rules they will appear to the right of the rule creation area. You will see a message saying “Your changes have not been applied yet” until you apply them. To apply them just hit the “Apply Rule Changes” button.

Here’s what our finished example looks like:

How to increase disk space on existing AWS EC2 Linux (Ubuntu) Instance without losing data

2011-07-29T10:30:00.000+10:00

By Semir H.

Let’s say you have a Linux Amazon Web Services (AWS) EC2 Instance up and running and you start running out of space. I’ll show you how to quickly clone its disk (EBS volume) onto a bigger disk (also EBS), replace the smaller disk with the bigger one and boot off the bigger (new) disk. No need for any third party tools like Acronis or Ghost or even rsync.

Create Snapshot of the original disk:

First thing we’ll do is to create a Snapshot of the original disk so that we can then create a new, bigger volume out of that Snapshot. There are a couple of things we have to note down first: the Instance number and then the volume attached to that Instance. The easiest way to fine the Instance number is in the Instances part of the AWS Management Console. It will start with “i” and be under the “Instance” column. Now navigate to the Volumes section (Elastic Block Store section) and locate the volume that is attached to your Instance. You can see the Instance number under the “Attachment Information” column. The first half of that string will be the Instance number. Please see the images below for an example.

Instance (in this case number is i-1920b74c):

Please also note which Zone your Instance is in. This will be important for later. In my case the Zone is “ap-southeast-1b” in the Singapore Region. The Zone can be seen by selecting the Instance and looking under its Description tab (bottom).

Volume (note the Instance number):

As you’ll notice in the examples above, the size of the original Volume (EBS Disk) is 8 GB. I’ll increase that to 25 GB.

Creating a Snapshot

To create a snapshot of the Volume you simply right-click on it and click on Create Snapshot. Or you can select the Volume and click on the Create Snapshot button at the top.

Please note that I am creating a Snapshot of the running virtual machine. If you have a database on it or some other application that has a lot of transactions happening then it would be best to turn the virtual machine off (schedule some downtime) and do the Snapshot.

Give the Snapshot a meaningful description and a name. Click on “Yes, Create”.

Once done, you will be able to see your Snapshot in the Snapshots part of the Elastic Block Store area. See example below. Please note the Name, Description and Capacity (original 8 GB).

Creating a new (clone) Volume

Next, we’ll create a Volume out of the Snapshot. Simply right-click on the Snapshot and select “Create Volume from Snapshot” from the resulting menu or you can use the button at the top.

Put in the desired Size of the new Volume and make sure the Availability Zone coresponds to the AZ that the original Instance is in. Click on “Yes, Create”.

If you navigate to the Volumes section you will see the new 25 GB volume there. You’ll notice that it is not in use.

Attach new Volume to existing Instance:

And now for the fun part. We will stop the Instance, detach the original 8 GB Volume, attach the new 25 GB Volume and make sure we are able to boot. Please note the new Volume will have the data up to the point when the Snapshot was taken. If the original machine had more data put onto it since the Snapshot then that will have to be dealt with. This is beyond the scope of this tutorial.

Stop the Instance (if it is running).

Go to the EBS Volumes section, select the original Volume, right click on it and select “Detach Volume”. You can also use the Detach Volume button. When prompted, please select “Yes, Detach”.

To attach the new Volume right-click on it and select “Attach Volume”.

Make sure you select the correct Instance. In the example below I am also modifying the Device to be the same as the original one. The example is for a Linux (Ubuntu) Instance. This is important. Click on “Yes, Attach”.

The Status should change to “in-use”.

Go back to your Instance and start it up. Log back into your Linux Instance and run the following command (for ext3 file system):

resize2fs /dev/xvda1

Please note that the device is not called sda1 but xvda1. The device was renamed by the Kernel.
After it is done you should be able to see the full 25 GB. use the “du -h” command. Example:

Cleanup:

Once you’ve made sure all works as it should and that all your data is fine on the new Volume, you can remove the Snapshot and the old Volume if you do not intend to use them anymore. Go to the relevant AWS Management Console sections and remove (delete) them.

Replace a lost Key Pair an existing AWS EC2 Instance uses

2011-07-28T22:01:00.000+10:00

By Semir H.

This tutorial will show you how to use a new Key Pair with an existing Linux instance.

Problem:

You have an existing EBS (root device) based Instance with data on it that needs to be saved. The original Key Pair has been lost so you can’t log into the Linux Instance. You need to get to the data on the virtual machine.

Solution:

We’ll clone the running Instance and re-deploy it but with a new Key Pair. We can either use a pre-made Pair or create a Pair while we’re re-deploying. My example uses Ubuntu but should apply to other flavours as well.

Creating an Image:

Log into your Amazon Web Services (AWS) Management Console, go to Amazon EC2, pick the Region where the Instance in question is running and click on the Instances link. Right click on the Instance in question and select “Create Image (EBS AMI)” from the resulting menu.

Give it a Image Name and a Description and click on “Create This Image” button. Example:

The process will now begin. Close the notification window.

Once the AMI is created (won’t take long) you should see it in the "Images" - "AMIs" part of your Amazon EC2 AWS Management Console. Please make sure you are still in the correct Region. Example:

Creating new Instance out of the new AMI:

Go to Images AMIs, locate your recently created AMI, right-click on it and select “Launch Instance” from the resulting menu.

Follow the prompts to finish creating the Instance (see my previous post) but make sure you select the correct Key Pair (one you create earlier, not the lost one) in the “Create Key Pair” section. Example:

All other settings should be the same as for the original Instance.
After a little bit of time your new Instance should be up and running.
Here’s an example below. Please note the different Key Pairs.

You can now connect to it, using your new private key, and confirm that all your data is still there.
Once you confirm no data is missing you can stop the old Instance and eventuality terminate it (after making absolutely sure you will never need anything from it).

Cleaning Up:

You can now de-register the AMI (unless you want to use later again).

You should also go to EBS - Snapshots and delete the Snapshot of the disk that was created when the AMI was made (unless you intend to use it for something in the future).

Creating a Key Pair to share between AWS EC2 Instances

2011-07-27T11:12:00.000+10:00

By Semir H.

Sign into Amazon Web Services Console. Go to the Amazon EC2 tab.
Pick your desired Region as this is where the key will be stored.
Locate the “Key Pairs” link under Networking & Security section and click on it.
Click on “Create Key Pair” button on the top to start the process.
Give the Key Pair a name. E.g. APAC-Keys-2011. Click on “Create”.

The Key Pair will be created and you will be prompted to save the private portion (a .pem file) on your computer/device. Please do so and make sure you keep it private,

You can now use this Key Pair for your new Instances. Please pick the “Choose from your existing Key Pairs” at the “Key Pairs” option when creating an Instance and select your pre-made Key Pair. Example below:

Connecting to AWS Linux (Ubuntu) Instance from Windows using PuTTY and the SSH protocol

2011-07-26T19:46:00.001+10:00

By Semir H.

This part continues from the previous “NAME” part where we launched an Instance. In this part I will show you how to use PuTTY to connect to your running Linux (Ubuntu) Instance. In order for PuTTY to access your Instance over the SSH protocol we opened up the SSH TCP port (22) by using a Security Group which is essentially a Firewall.

Creating a PuTTY Private Key:

We must first create a PuTTY Private Key using the .PEM key generated beforehand. For this you need to get puttygen.
Run puttygen to start the process. Click on “File” and on “Load private key”.

Browse to the private key file (.pem) you saved earlier and load it. You should get a success notice like the one below. Click on OK.

You may want to edit the key comment and put a key passphrase before we generate a PPK file. I recommend using a key passhprase but please do not forget it or your resulting PPK will be of no use. Leave the type of key as SSH-2 RSA and leave the number of bits as 1024. Once you’ve made desired comments and put in the phrase click on “Save private key”. Give it a meaningful name and save as .ppk.

Connecting to AWS Linux Instances:

We must first find out the public DNS of the Instance we wish to connect to. To do this go to your AWS Management Console, go to Amazon EC2 tab, Instances, click on your Instance and look down under “Description”. You should see an address, next to Public DNS, similar to this: ec2-122-248-203-235.ap-southeast-1.compute.amazonaws.com

Next, start PuTTY, put the DNS entry into the Host Name field and then browse down to the SSH Category and to the Auth section under SSH. This is where you add your private key (PPK) for later authentication. Go back to the Session category, make sure the DNS entry is still there, give this session a name (e.g. Test AWS Ubunt) and click on Save.
See below for an example:

Now it’s a simple matter of loading the saved session. First time you connect you will get a security alert saying that the server’s host key is unknown to you. Please select Yes to continue if you think it is safe to do so (in this case it is). You will get this with any new server the first time. You will also get this if you turn your Instance off and then on again (because the DNS and server hostname will change). The private key will not change so that can be re-used to connect.
You will be prompted to put in a username to log in. For this particular AMI it is ‘ubuntu’. Once you put that in you will get prompted to put the PPK passphrase (if you set one). If all goes well you should be logged into your Ubuntu Linux Amazon AWS Instance. Yay :)

Troubleshooting:

If you’re having issues then please revisit the steps above. Please make sure you’re using the correct DNS entry and the correct private key. You can check which private key the Instance is using by looking at the Instance Details section (same one where DNS info is located). Please be aware that the public DNS string will change if you shut the server down and start it again. This can be addressed using Elastic IPs but we’ll cover that in another tutorial some other time.

Launching a Linux (Ubuntu) Instance on Amazon Web Services EC2 - A Beginner's Guide

2011-07-26T19:01:00.001+10:00

By Semir H.

To create an AWS account please see How To Sign Up.

Log into your AWS account and go to the AWS Management Console.
Go to the Amazon EC2 tab. Make sure you’ve picked the desired Region (see this article for more detail).

Click on the ‘Launch Instance” button to start the process.

I’ll be creating a micro Instance of Ubuntu 11.04 64-bit server from one of the Community Amazon Machine Images (AMI). Community AMIs are pre-configured operating systems available for anyone to create Instances from.

Choose an AMI:

Click on Community AMIs and find your desired AMI. In my case it will be Ubuntu Natty Daily with AMI ID = ami-48aad21a. Click on “Select” next to it to continue.

Instance Details:

You can leave Instance Details at defaults. I am choosing a Micro Instance and I do not care about the Availability Zone for now. Click on “Continue”.

Leave the Advanced Instance Options at defaults an click on “Continue”.

Leave the Tags part empty for now. We’ll cover this in another tutorial. Click on “Continue”.

Create a Key Pair:

We will need to create public/private key pairs to later access our Linux (Ubuntu) Instance.
You can create these per Instance or you can create them beforehand and use for future Instances. We’ll create one now for testing purposes. I’ll cover creating some for re-use later.

Enter a name for your key pair and click on the “Create and Download you Key Pair” link. Example:

You will get prompted to open/save the resulting .pem file. Please do so.

Configure Firewall:

The next part configuring a security group which is basically a firewall.
Since I want to open ports for SSH (TCP 22) and HTTP (TCP 80) I will choose to create a new group and add those rules in at this stage. You can come back to this later to open more ports or close some.
So pick “Create a new Security Group”, give it a name and a description and add the desired rules. Some are pre-defined (e.g. SSH and HTTP) so you need to just pick them from the “Create a new rule” drop-down and add them. I’m leaving the source at default. Once done click on “Continue”.
See here for an example:

Review:

This is the final stage before launching. It gives you the opportunity to review your choices and edit them if you wish to. If you’re happy with them then click on “Launch”.
You will get a message that the Instance is being launched.

To view the progress of the launch you go back to the AWS Management Console and go to the Amazon EC2 tab. Click on Instances in the menu on the left. You should see your instance and the various properties it has as well as the Status. In no time it will turn to “running”. Here’s an example of this view:

That’s it. You can now connect to your running Instance. I’ll cover how to do that in my next tutorial.

How To KILL a stuck Virtual Machine (ESX 3.5)

2010-02-03T13:54:00.005+11:00

Found this useful the other day - twice.

The first time a VM would not live migrate from one host to another. I stopped it and migrated but then it would not start, giving me the "Could not power on VM: No swap file. Failed to power on VM"
Using the below instruction I managed to kill the process that was still making it seem like the VM was running fine.

The second time I was taking a snapshot of a VM and it just did not work. Timed out AND made the VM freeze. I tried restarting and turning off the VM but it would not as there was "another process running" which I guess was the failed snapshot. Again, I used the below commands to kill the process (the VM) and was then able to start the VM.

ps -auxwww | grep -i

Find the PID and kill -9 pid

or

vm-support -x - to list vmids

vm-support -X to kill it

How To Install Applications on Microsoft Terminal Servers Correctly

2009-08-23T11:11:00.013+10:00

This article assumes that the Microsoft Terminal Services Licensing and other TS features are already configured. It concentrates only on new Terminal Servers and how to deploy Applications on those new Servers.

Many people new to Microsoft Terminal Services will not know how to correctly install various applications in order for them to function properly in a Terminal Services environment. The basic steps are:

Install Microsoft Windows Server (2000/2003/2008).
Do all the Security and Updates Patching.
Install Microsoft Terminal Services in Application Mode.
Enter the "Install" mode.
Install Applications.
Enter the "Execute" mode.
Join the Server to the Domain and the rest of the Terminal Servers.

I won't go into details for most of these steps.

To use the Terminal Server in Application Mode then you must have Microsoft Terminal Services Licensing service installed. If you are joining a new TS Server to the existing TS environment then you already most likely have this. Then you just have to install the Terminal Services role on the new server.

The next step is to go into the "Install Mode". This is done as follows:

Open a command window (cmd).
Type "change user /install" (without the quotes) and press ENTER.

Next you install the desired applications (e.g. Microsoft Office 2003 Enterprise, Crystal Reports, Cisco admin applications, etc)

Next you switch into the "Execute Mode". This is done as follows:

Open a command window (cmd).
Type "change user /execute" (without the quotes) and press ENTER.

IF you have installed the applications before installing Microsoft Terminal Services role then you will have to uninstall and install again following the steps outlined above. Hopefully this will help some of you avoid re-installing the applications by doing it correctly the first time.

For more info please see "When you toggle Terminal Services to Application Server mode, some programs may stop working" from Microsoft Help and Support.

iSCSI Storage Connectivity Best Practice with VMware

2009-08-06T16:40:00.011+10:00

I am quite impressed with VMware I must say. We use it in production at work and now I cannot imagine my professional life without it.
In this post I will briefly describe what your ideal cheap iSCSI Storage setup should look like.

Normally, production environments of many companies will use full versions of VMware ESX (e.g. ESX 3.5 - commonly;y know as VI3 Infrastructure or the new vSphere - ESX 4.0) with a SAN (Storage Area Network) where the Virtual Machines will live. In most cases the connection between the ESX boxes and the SAN is via Fiber Channel (FC) (see here for more info). This is usually very expensive.

Many companies resort to using iSCSI for their test environments or even production environments. You can learn more about iSCSI here.

Both ESX and ESXi versions support Software iSCSI Adapters. You are free to buy iSCSI HBAs but I found that the Software adapter is quite enough for all my testing needs. Money saved.

The diagram bellow shows what you ideal iSCSI network setup should be (click on it for the bigger version).

This setup requires that each ESX (ESXi) box has (at least) two NICs that will carry the data over iSCSI. Each NIC will hook into a separate Network Switches. So you will need two Network Switches too. The idea is that if one of the ESX (ESXi) NICs fails you will still have connectivity over the other NIC. And if one of the Network Switches fails you should still have connectivity to the iSCSI Storage Device.
So the single point of failure in this example is the iSCSI Storage Device (this post will not deal with that).

You can have iSCSI working with just one network sw and one NIC per ESX box but that does not give you redundancy. The above setup is good enough to use in production. I would recommend the 1 SW + 1NIC/ESX for TEST environments only.

I will probably write a more detailed tutorial on how to do the above setup with VMware ESX (ESXi) in the future.

That's it for now :)

Securing Websites with Pound (reverse HTTP proxy & SSL wrapper)

2009-08-02T12:03:00.029+10:00

This is a short article on how to use Pound as a Reverse SSL Proxy.

Problem/Requirement:

You have a few websites in your DMZ or even on the LAN. You want them to be accessible from to the outside (Internet). Some of these websites are web based applications. You also have 1 external IP.
You want to serve all these websites from the one external IP and you want most of them to be secured via SSL (HTTPS).
On top of that you have different web servers serving the pages (e.g. Apache, IIS).

The diagram below depicts a typical inefficient web server setup (click on image to see larger version):

Requirements Summary:

Use just one external IP.
Use one SSL certificate (for websites under the same domain/sub domains).
Secure websites REGARDLESS of the web server technology used to serve those websites.
Have the ability to pick which websites get SSL encryption based on the source of the request (e.g. if from Internet then use SSL, if from corporate LAN then do not encrypt).

Solution:

Use a free application called Pound.

What is Pound?

Pound is a reverse HTTP proxy, load balancer, and SSL wrapper. It proxies client HTTPS requests to HTTP backend servers, distributes the requests among several servers while keeping sessions, supports HTTP/1.1 requests even if the backend server(s) are HTTP/1.0, and sanitizes requests.
It runs on Linux.
You can find more info @ http://www.apsis.ch/pound/

How Will it Work?

The diagram below shows where we want to be (click on image to see larger version):

Basically we want the Pound server to be the first point of contact from the outside. This way we reduce the number of "holes" we have to open in the firewall(s) and put another layer of security between the Internet and our web servers.
Pound meets all of our previously stated requirements:

We can use just one External IP to server all our websites.
Using a wildcard certificate (e.g. *.testdomain.test) we can encrypt all the web sites under the same domain/sub domains with just that one cert.
Because we are doing the SSL encryption with Pound, it no longer matters what the other web servers inside your network use to serve pages. They can be Apache, IIS, Tomcat, etc. You can leave them ALL at the default port 80 (or 8080 for some). Pound can talk to them on pretty much any available port (even 443).
We can make pound encrypt all requests that come from the Internet but NOT do so if the requests come from the LAN. Some companies choose to do that because it makes things faster. Not using SSL/HTTPS internaly can be done in two ways. One way is through Pound (so all the internal websites would point to the same internal Pound IP) and the other way is to not involve Pound at all. People wold just directly access the individual web servers. An advantage of going via Pound is that you can track access from one location and perhaps do custom redirects when needed (e.g. if a web server is down for maintenance you can have pound redirect to a notification page somewhere else).

Of course, there is one problem with using Pound for evertynig. It becomes a single point of failure. I suppose that can be remedied by using another Pound server to load balance or in another way (e.g. run as Virtual Machine - which works good. Let VMware worry about high availability, etc)

Next we will examine how some of the above is actually implemented:

Please Note:
This tutorial will not examine how the SSL certificates are acquired. The only thing you have to make sure is that they are Linux compatible. Pound runs on Linux. I usually use a self signed cert but if you generate one via a trusted CA then use the Apache/Linux instructions.

Let's assume you want to Encrypt web access for two of your internal web servers IF the requests are from the Internet. If they are from the LAN then do not encrypt.

Domain = testdomain.test
Internal Web Srv 1 = 192.168.7.5 (DMZ)
Internal Web Srv 2 = 192.168.0.10 (LAN)

The Pound server should always be put in the DMZ. Ideally all of your "exposed" servers should be but that is sometimes not an option.

Pound Server = 192.168.7.50 (DMZ)

First we define a HTTP (port 80) listening directive. Under that we put in our two web servers and since we want to encrypt them (if the requests is from the Internet and is on port 80 (HTTP) we will redirect to HTTPS:


ListenHTTP
Address 192.168.7.50
Port    80
xHTTP   2
Service
HeadRequire "Host: .*web1.testdomain.test.*" 
Redirect "https://web1.testdomain.test"
End
Service
HeadRequire "Host: .*web2.testdomain.test.*"
Redirect "https://web2.testdomain.test"
End
End

Next we define a HTTPS directive. This will be the one that will accept the redirects from above AND direct HTTPS requests (no redirect required in that case). This is also where we define which certificate to use and which back servers to contact.

ListenHTTPS
Address 192.168.7.50
Port    443
 Cert    "/path/to/cert.pem"
AddHeader "X-Forwarded-Proto: https"
HeadRemove "X-Forwarded-Proto"
Ciphers "ALL:!ADH:!EXPORT56:RC4+RSA:+HIGH:+MEDIUM:+LOW:+SSLv2:+EXP:+eNULL"
xHTTP   1

Service
HeadRequire "Host: .*web1.testdomain.test.*"
BackEnd
Address 192.168.7.5
Port 80
End
End

Service
HeadRequire "Host: .*web2.testdomain.test.*"
BackEnd
Address 192.168.0.10
Port 80
End
End
End

There is also a recommended "catch-all" deirective that goes to the end. This will be what Pound will serve if nothing above is matched. Example:

Service
BackEnd
Address 192.168.0.10
Port    80
End
Session
Type    BASIC
TTL     300
End
End

Access from the Internet:

Your external DNS will point web1 and web2 URLs to the same external IP. Your firewall (I use shorewall) will redirect traffic that comes on that IP over port 80 and 443 to the Pound server in the DMZ. Your internal DNS will point the above URLs to the DMZ IP of the Pound server (192.168.7.50).
So when the requests come from outside on HTTP they first hit the HTTP directive which just redirect to HTTPS. Internal DNS kicks in and the traffic is redirected back to Pound but this time over HTTPS (443). This is when the HTTPS directive kicks in. If you asked for web1 then request is directed internally to 192.168.7.5 over port 80 (HTTP). The answer is returned to the Pound server over port 80 (not encrypted) and then the traffic is encrypted to goioutside (from Pound to the Internet).
If the request from the outside is over HTTPS then the HTTPS directive is used straight away. Answers are returned to the Internet over HTTPS of course.

Access from the Inside:

The easy way is NOT to use pound if you don't want encryption.

If you want internal encryption then you just have to point the internal DNS to the Pound IP.

If you do not want encryption but still want to go through Pound then you need to give the Pound another internal IP (either another NIC or add an IP to the current NIC) and then create HTTP directives that forward traffic to the individual web servers. Of course, your Internal DNS will then have to point to that new Pound IP.
What happens if people have bookmarks that have HTTPS in them?
You can create HTTPS directives that redirect to HTTP. Effectivelly you do the opposite of what you did for the Internet traffic. Slightly more work but not the end of the world :)

Pound is capable of more complex setups than this and I may describe some of those in the future.