http://www.cybermerc.org

I will be refreshing a few of the better articles and incorporating them into my new site. I will be leaving this site up for the next few months but eventually I will pull the plug.

No-Mad

Installation:  The program is a simple python command line script which should be able to be installed on any OS with python installed. I wont even bother going over how to install it, you can figure it out, If you can not install software on your workstation you might want to stay away from a server- sorry.

Basic configuration:  The tool is written to allow you to pass the account username and API key via the command line or add it to your system as an environment variable. On a Unix system this is just a matter of adding the following lines to your profile.

export OPENSTACK_COMPUTE_USERNAME=frankjones
export OPENSTACK_COMPUTE_APIKEY=4f3wO9ssdfaer2kw21sdf0

Before we dig any deeper you may to want to look over the documentation for this tool located here.  Next you may want to review the Rackspace developers documentation to better understand the terminology used with this tool. So lets get to the meat of this article -

How to use this great little tool

The list command:  First lets start with a example of listing all the servers on your account. A basic command as long as the username and APIkey are passed via the environment variables if not you will need to add: –username <rackspace username> –apikey <account API key> to every command listed in this article.

$ openstack-compute list
+————+—————–+———+—————+—————+
|    ID           |       Name           | Status  | Public IP      |   Private IP   |
+————+—————–+———+—————+—————+
| 20151110 | webtest2           | ACTIVE | 50.56.22.1 | 10.177.192.8   |
| 20121115 | logserver           | ACTIVE | 50.56.23.5 | 10.177.192.4   |
| 20121113 | webtest1            | ACTIVE | 50.56.23.2| 10.177.194.1    |
+————+——————+——–+—————+—————+

This gives us a quick view of all the servers on the account. It provides the server ID, name, and server status which are required to dig deeper into the server details.

The show command:  Now lets look at the details on a specific server (viewed by ID). The format is: openstack-compute show <server ID>

$ openstack-compute show 20121113
+————+———————————+
|  Property  |              Value                            |
+————+———————————+
| flavor       | 1G server                                    |
| hostId     | 3fc8serbc4ea8sef916c08         |
| id             | 20121113                                      |
| image      | CentOS 6.2                                 |
| metadata | {}                                                 |
| name        | webtest1                                     |
| private ip | 10.177.194.1                               |
| progress   | 100                                              |
| public ip  | 50.56.23.2                                  |
| status       | ACTIVE                                       |
+————+———————————-+

This provides a list of details about the specific server. Such as image and flavor type which are details that are needed to create new servers.

The flavor-List command:  Flavor is the term for the server size which includes RAM and disk size available. The flavors are listed in RAM size and start at the size of 256MB and include 512MB,1GB, 2GB, 4GB, 8GB, 15GB, and 30GB. Below is a list of the flavors available on Rackspace cloud servers with the RAM and Disks sizes listed.

$ openstack-compute flavor-list
+—-+—————+——-+——+
| ID |      Name     |  RAM  | Disk |
+—-+—————+——-+——+
| 1  | 256 server    | 256   | 10      |
| 2  | 512 server    | 512   | 20      |
| 3  | 1GB server    | 1024  | 40    |
| 4  | 2GB server    | 2048  | 80   |
| 5  | 4GB server    | 4096  | 160  |
| 6  | 8GB server    | 8192  | 320  |
| 7  | 15.5GB server | 15872 | 620  |
| 8  | 30GB server   | 30720 | 1200 |
+—-+—————+——-+——+

The image-list command:  Next are images, they are the OS builds that are available. Images fall into two categories, the basic models provided by Rackspace and any custom images you have created within your account. Notice in the example below the last image has a much higher ID number, that is a custom image the rest are the current Rackspace default OS choices. Unlike Amazon there is no shared image pool so you can only build a default system provided by Rackspace or your own custom built image.

$ openstack-compute image-list
+———-+—————————————————+——–+
|    ID    |                        Name                                         | Status |
+———-+—————————————————+——–+
| 24       | Windows Server 2008 SP2 x64                       | ACTIVE |
| 31       | Windows Server 2008 SP2 x86                       | ACTIVE |
| 56       | Windows Server 2008 SP2 x86 – MSSQL2K8R2          | ACTIVE |
| 57       | Windows Server 2008 SP2 x64 – MSSQL2K8R2          | ACTIVE |
| 85       | Windows Server 2008 R2 x64                        | ACTIVE |
| 86       | Windows Server 2008 R2 x64 – MSSQL2K8R2           | ACTIVE |
| 89       | Windows Server 2008 R2 x64 – SQL2K8R2 Web         | ACTIVE |
| 91       | Windows Server 2008 R2 + SQL Server 2012 Standard | ACTIVE |
| 92       | Windows Server 2008 R2 + SQL Server 2012 Web      | ACTIVE |
| 100      | Arch 2011.10                                      | ACTIVE |
| 103      | Debian 5 (Lenny)                                  | ACTIVE |
| 104      | Debian 6 (Squeeze)                                | ACTIVE |
| 108      | Gentoo 11.0                                               | ACTIVE |
| 109      | openSUSE 12                                           | ACTIVE |
| 110      | Red Hat Enterprise Linux 5.5                   | ACTIVE |
| 111      | Red Hat Enterprise Linux 6                        | ACTIVE |
| 112      | Ubuntu 10.04 LTS                                  | ACTIVE |
| 114      | CentOS 5.6                                            | ACTIVE |
| 115      | Ubuntu 11.04                                           | ACTIVE |
| 116      | Fedora 15                                               | ACTIVE |
| 118      | CentOS 6.0                                           | ACTIVE |
| 119      | Ubuntu 11.10                                         | ACTIVE |
| 120      | Fedora 16                                               | ACTIVE |
| 121      | CentOS 5.8                                             | ACTIVE |
| 122      | CentOS 6.2                                             | ACTIVE |
| 125      | Ubuntu 12.04 LTS                                  | ACTIVE |
| 126      | Fedora 17                                                | ACTIVE |
| 17177128 | test-setup-122911                                 | ACTIVE |
+———-+—————————————————+——–+

To create a new server you need to understand these two options so you can add these variables to create a new system.

The boot command:  Here is an example of a create command for a new server named ‘webtest3′ with a size of 1GB (flavor 3) and the OS of CentOS 6.2 (image 122). The format is: openstack-compute boot <flavor #> <image #> <new server name>

$ openstack-compute boot –flavor 3 –image 122 webtest3
+———–+—————————————————————-+
|  Property |                             Value                              |
+———–+—————————————————————-+
| addresses | {u’public’: [u'50.56.118.48'], u’private’: [u'10.19.1.12']} |
| adminPass | v7lAC76webtest3                                                |
| flavorId  | 3                                                                                  |
| hostId    | 3fe7f91b4657cf0a098f5df1b27                             |
| id        | 20936230                                                                      |
| imageId   | 122                                                                            |
| metadata  | {}                                                                              |
| name      | webtest3                                                                    |
| progress  | 0                                                                                |
| status    | BUILD                                                                        |
+———–+—————————————————————-+

The output shows the command was accepted and the new server was created, it has setup the public and private IP’s and assigned a new root login. The status is ‘BUILD’ and will take 3-5 minutes to completed then the status will become ‘ACTIVE’ when the server is ready for your use. To check the status and ensure the build completes just run the ‘show’ command. The format is: openstack-compute show <server ID>

$ openstack-compute show 20936230
+————+———————————-+
|  Property  |              Value               |
+————+———————————-+
| flavor     | 1GB server                       |
| hostId     | 3fe7f91b4657cf0a098f5df1b27 |
| id         | 20936230                         |
| image      | CentOS 6.2                       |
| metadata   | {}                               |
| name       | webtest3                         |
| private ip | 10.19.1.12                     |
| progress   | 100                              |
| public ip  | 50.56.118.48                    |
| status     | ACTIVE                           |
+————+———————————-+

The reboot command:  Another useful command is the server reboot command this can be important if the server locks up or otherwise fails and you need to restore it. The command is pretty straight forward its : openstack-compute reboot <server ID>  This command will not have any output but you can use the ‘show’ command to see the status which will at first be ‘REBOOT’ then ‘ACTIVE’ once its up and running again.

The root-password command:  Along that same line say you have forgot your root password (or administrator on Windows images) and need to reset it to get access to your server again. The control panel will let you reset it, but it generates a random new password for you. This program allows you to reset it to whatever you want in a single command: openstack-compute root-password <server ID> it will then prompt you for the new password twice to ensure its typed correctly. The server will then reboot and once back online the new password will be in effect.

The rename command:  One more useful command is the server rename command, all this does is change the server name as its listed in the API and the control panel it does not make any changes to the server such as changing the hostname. The command is : openstack-compute rename <server ID> <new server name>

The image-create command:  So now you have your new server all configured the way you want it. Before you go into production or make that next new code push you decide to make a on-demand backup of the server in its current state. So if needed you can ‘roll back’ and restore the system to this point in time. This is a full backup of the drive containing all data (configuration files etc). The format for this is:  openstack-compute <server ID> <backup name>

$ openstack-compute image-create 20936230 test3backup
+———-+—————————+
| Property |           Value           |
+———-+—————————+
| id       | 23478575                  |
| name     | test3backup               |
| serverId | 20936230                  |
| status   | QUEUED                    |
| updated  | 2012-06-23T00:44:35-05:00 |
+———-+—————————+

The creation of the server image can take a few minutes (depending on the number of inodes on the server), once it has completed it will be added to image listing for your account so you can use the command: openstack-compute image-list to see all your images and the new one should be listed at the bottom.

The image-delete command:  So now times goes by and you have created multiple backup images and there are several you no longer need. Even though they are pretty cheap to store you may want to remove some of the old ones. Lucky for you there is a command for just that purpose. First you would do a image-list and pick out the image ID of the image you want to remove then issue the following command: openstack-compute image-delete <image ID>  This command will run and you will not get any direct feedback but next time you run and image-list command you will see the image is no longer listed on your account.

The resize command:  The next issue I will show is how to resize a server via the command line tool. First off we need to determine what size the server is and what size you want it to become. Using the show command you can see the details of a specific server: openstack-compute show <server ID> using the example server above (webtest3) its a 1GB server and we can to resize it to a 256MB server. The command to resize using this example is: openstack-compute resize <server ID> <flavor #>

Now the resize command has no output so you have to use the show command to see if the resize started, if it is working it will show status of PREP_RESIZE as the example below shows.

$ openstack-compute show 20936230
+————+———————————-+
|  Property  |              Value               |
+————+———————————-+
| flavor     | 1GB server                       |
| hostId     | 3fe7f91b4657cf0a098f5df1b27ea1fa |
| id         | 20936230                         |
| image      | CentOS 6.2                       |
| metadata   | {}                               |
| name       | webtest3                         |
| private ip | 10.179.1.102                     |
| progress   | 0                                |
| public ip  | 50.56.188.248                    |
| status     | PREP_RESIZE                      |
+————+———————————-+

The resize can take some time depending on the size of the server and the number of inodes in use. Once it has completed it will reboot and come back online as the new size and be in the ‘verify resize’ state. From this point you need to check the status of the server then either confirm or revert the resize.

$ openstack-compute show 20936230
+————+———————————-+
|  Property  |              Value               |
+————+———————————-+
| flavor     | 256 server                       |
| hostId     | 4a9002b8e571ff57c1baf981844270b3 |
| id         | 20936230                         |
| image      | CentOS 6.2                       |
| metadata   | {}                               |
| name       | webtest1                         |
| private ip | 10.179.1.102                     |
| progress   | 0                                |
| public ip  | 50.56.188.248                    |
| status     | VERIFY_RESIZE                    |
+————+———————————-+

Then you would issue one of the following two commands to either verify or revert the resize.

$ openstack-compute resize-confirm 20936230

$ openstack-compute resize-revert 20936230

There is no output from these commands but after issued you can use the ‘show’ command to verify it has executed.

The delete command:  Now say this server has lived out its needed life and your ready to delete it from the account. The command to do that is pretty simple its: openstack-compute delete <server ID>  This command will not return any values but next time you do a list command the server will no longer be on the list.

In conclusion these commands will provide you the basic skills needed to use the openstack-compute command line tool.  In later articles I will go into additional details on how to do advanced curl commands and once live I will be getting deeper into the NOVA client which is the command line tool for the next generation Rackspace cloud platform that will be public within a few months. I’m current in the beta so I’m having a blast playing with Rackspace’s wonderful new toy, which I look forward to teaching you all about soon.

Enjoy

- Nomad

Let me give some history here for the young ones. Web based control panels specifically Plesk and cPanels were designed to run virtual hosting businesses. They became popular in the early 2000′s during the rise of rented dedicated server solutions. Where you wanted to cram 100′s of small sites/customers onto a single server and give them some ability to manage their own setup. Keep in mind you have very limited ability to do non-standard setups so you can meet the lowest common denominator of the systems configuration. This made sense 10 years ago when dedicated servers were expensive and you had to have lots of customers on one just to break even.

Now the cloud servers world today is an extremely different place. When I’m talking about cloud server I’m referring to services like Amazon EC2 or Rackspace Cloud servers. These systems are designed for modular specialized services that allows for fast scalability and redundancy.  You spin up a few web servers behind a load balancer, and a couple of database servers and you have your own small server farm. You offload email and DNS to a third party service and your ready to go.

The smartest designs and setups in the cloud today are all about modularity and optimization. The last thing you would want to do is add a layer of additional crap to slow down your system and keep it from working as designed. Control panels by design are all about setting limits and the cloud is all about building without limits.

Over the next couple of weeks I will be writing several articles to explain how you should be developing cloud solutions using various API and automation tools. With these open source tools I have built scripts that allow me to create multiple types of systems within minutes, along with making configuration changes to multiple lives servers with a single command.

• Rackspace API
• Amazon API
• Using Chef for Automation
• Using Puppet for Automation
• Using Fabric for system configuration

If your business is not fluent is using API’s and some type of automation tool such as Chef or Puppet to build and configure your servers you are way behind the power curve of current technology. Leave the GUI on Windows and learn a new skill set that will enable your business and well as your resume.

Enjoy

- No-Mad

They have a ton of great services documented well here. they include such things as:

• Added layer of security and DDOS Mitigation
• built in CDN
• Web Analytics
• Application optimization

One of the undocumented feature I found to be useful is the ability to completely obscure the real location of my web servers. Using cloudflare along with a private whois service and manicured DNS records there is no way to locate my server behind the cloudflare service, from a security stand point this is a nice addition to an already great service. This limits the attack surface to just web applications so you don’t have to worry about as many attack vectors.

The service comes in two price structures a free basic service (HTTP only) and a ‘Pro’ service for $20/month that adds tons of great features documented here. I would strongly recommend this service to anyone hosting sites today. The added security and the CDN service alone more than pay for the monthly fee for the ‘Pro’ account.

Overall an amazing value add for the small and large bloggers looking to make their sites faster and more secure.

- No-Mad

First setup the file systems on all the web servers, including a user with same UID/GID to use for the ownership of the transferred locations (this part of the configuration is not required to make lsyncd work, but I think a uniform simplistic approach is best). For this example we will use a default web layout of /var/www/html owned by a regular user bob (UID 501, GID 501)

Generate SSH keypair on master:

Then copy /root/.ssh/id_rsa.pub on master to /root/.ssh/authorized_keys on the slave server

Then ensure the following lines are uncommitted in /etc/ssh/sshd_config on the slave server

Then make sure to restart SSH after making changes to the configuration. Then test SSH access from master to slave to ensure entry is working correctly.

Before we can install the demon you will need to ensure you have all the dependencies in place, most likely the following command will get everything you need.

# yum install lua lua-devel pkgconfig

Then grab the source from http://code.google.com/p/lsyncd/

Untar the file and run the standard ‘./configure && make && make install’ to create and install the binaries.

The source code install does not add the init.d script or configuration file by default, those have to be manually added after installation. Create the init.d script from template below.

/etc/init.d/lsyncd

#!/bin/bash
#
# lsyncd: Starts the lsync Daemon
#
# chkconfig: 345 99 90
# description: Lsyncd uses rsync to synchronize local directories with a remote
# machine running rsyncd. Lsyncd watches multiple directories
# trees through inotify. The first step after adding the watches
# is to, rsync all directories with the remote host, and then sync
# single file buy collecting the inotify events.
# processname: lsyncd

# . /etc/rc.d/init.d/functions 

config="/etc/lsyncd.lua"
lsyncd="/usr/local/bin/lsyncd"
lockfile="/var/lock/lsyncd"
prog="lsyncd" RETVAL=0
RETVAL=0

start() {
        if [ -f $lockfile ]; then
        echo -n $"$prog is already running: "
        echo
        else
        echo -n $"Starting $prog: "
        $lsyncd $config
        RETVAL=$?
        echo
        [ $RETVAL = 0 ] && touch $lockfile
        return $RETVAL
        fi
    }

stop() {
        echo -n $"Stopping $prog: "
        killall $lsyncd
        RETVAL=$?
        echo
        [ $RETVAL = 0 ] && rm -f $lockfile
        return $RETVAL
    }

case "$1" in
        start)
        start
        ;;
        stop)
        stop
        ;;
        restart)
        stop
        start
        ;;
        status)
        status $lsyncd
        ;;
        *)

        echo "Usage: lsyncd {start|stop|restart|status}"
        exit 1
    esac

    exit $?

 Set permissions and ownership on init.d file:

Lsyncd configuration file examples. /etc/lsyncd.lua

Here is an example of a master, single slave configuration file (1.1.1.1 is the IP of the slave server).

settings = {

   logfile = "/var/log/lsyncd.log",

   statusFile = "/var/log/lsyncd-status.log",

   statusInterval = 20 }

sync{

   default.rsyncssh,

   source="/var/www/html",

   host="1.1.1.1",

   targetdir="/var/www/html",

   rsyncOpts="-avz" }

Here is an example for a master with two slave configuration (1.1.1.1 first slave, 2.2.2.2 second slave)

settings = {

   logfile = "/var/log/lsyncd.log",

   statusFile = "/var/log/lsyncd-status.log",

   statusInterval = 20 }

sync{

   default.rsyncssh,

   source="/var/www/html",

   host="1.1.1.1",

   targetdir="/var/www/html",

   rsyncOpts="-avz" }

sync{

   default.rsyncssh,

   source="/var/www/html",

   host="2.2.2.2",

   targetdir="/var/www/html",

   rsyncOpts="-avz" }

There is a huge amount that can be done using the configuration file, including execution of lau and bash scripts triggered by events in the configuration files. Here is the manual for configuration http://code.google.com/p/lsyncd/wiki/Lsyncd20Manual I will show you one example of its power to exclude files from sync. If you want to exclude a directory, use an exclude file and the excludeFrom directive:

Sample exclude file – /etc/lsyncd-excludes.txt:

cache/

uploads/

dontcopymebro/

Then a sample configuration file with the exclude file included – /etc/lsyncd.lua:

settings = {

   logfile = "/var/log/lsyncd.log",

   statusFile = "/var/log/lsyncd-status.log",

   statusInterval = 20 }

sync{

   default.rsyncssh,

   source="/var/www/html",

   host="1.1.1.1",

   targetdir="/var/www/html",

   excludeFrom="/etc/lsyncd-excludes.txt",

   rsyncOpts="-avz" }

Once the init script and the configuration file are in place, run the following command to setup run on boot:

chkconfig lsyncd on

Make sure to look over your log files to ensure that everything is working, the most common problem other than SSH login is running out of inodes if your file structure is large. This can be adjusted in /proc/sys/fs/inotify/max_user_watches .

Now I mentioned at the first of this article that this is a one way synchronization program so all disk writes have to be done on the master web server or this will break sync. Now using a CMS like wordpress this is pretty easy to do. The way I recommend to my clients is to force SSL login/admin access. by adding the following lines to your wp-config.php. In my opinion this is a good standard security step anyways.

define('FORCE_SSL_ADMIN', true);

define(‘FORCE_SSL_LOGIN’, true);

This forces all logins to the control panel, which is where all writes are done to SSL. Then you just have to configure whatever load balancing solution your using to send all SSL traffic to your master server only.

Now there are plenty of other things that need to be done to setup a multi-server CMS configuration such as session handling and Apache optimization but that’s another article.

Hope you find this article helpful.

- Nomad

First let’s discussed what we are trying to achieve. We are going to setup two users for web content uploads that will be locked into their respective /var/www/vhosts/%u directory structures. There are basically four steps to getting this setup.

• design the layout you want to use for the users
• setup the user and group accounts
• make changes to the sshd configuration
• do permissions cleanup and testing

Layout design

For this example we are setting up two users for website content updates. Each user will have a directory structure that will be tied to a domain. They can edit the files within that structure but can not see or edit anything outside that structure.

We will be setting up the two users – bob and ted, each will have a directory off /var/www/vhosts/ to managed their respective sites. We will create a group call ‘sftponly’ which will include both these users. These accounts will only have sftp access and will not have a working shell (ie standard SSH access).

Setup directory structure for users by adding the following directories as the user root.

      /var/www/vhosts/bob/site1/

     /var/www/vhosts/ted/site1/

Note how each user has a directory to match their user name, then a content directory (in this case named site1).

User and Group setup

First you will want to establish the sftponly group

     # groupadd sftponly

Then create the users with the correct home directories and group

    # useradd -d /var/www/vhosts/bob -s /bin/false -G sftponly bob

     # useradd -d /var/www/vhosts/ted -s /bin/false -G sftponly ted

Don’t forget at this point to also add password to these new accounts.

SSHd configuration changes

Now we need to make changes in /etc/ssh/sshd_config to enable SFTP chroot jails in SSH.

Comment out the following line in /etc/ssh/sshd_config:

      #  Subsystem sftp /usr/lib/openssh/sftp-server

and replace it with this line:

     Subsystem sftp internal-sftp

Then add the following set of lines to the very bottom of the file:

     Match Group sftponly

     ChrootDirectory /var/www/vhosts/%u

     X11Forwarding no

     AllowTCPForwarding no

     ForceCommand internal-sftp

This creates a special login group that then chroot jailed all users in that group into their own home directory.

Once these file changes are saved you will need to restart SSHd for the changes to take effect, using the following command:

        # service sshd restart

 Permissions cleanup and testing

Last issue to address is the permissions settings, for this example the directories /var/www/vhosts/bob and /var/www/vhosts/ted should both be owned by root. The directory /var/www/vhosts/ted/site1 should be owned by ted and the directory /var/www/vhosts/bob/site1 should be owned by bob.

You can then test by trying to SFTP login and see what can be done:

If done correctly you can not upload to any directory other than /site1

$ sftp bob@1.2.3.4
bob@1.2.3.4′s password:
Connected to 1.2.3.4.
sftp> pwd
Remote working directory: /
sftp> cd site1
sftp> put index.html
Uploading index.html to /site1/index.html
index.html                                    100%    0     0.0KB/s   00:00
sftp> ls
index.html
sftp> exit

Gotcha to watch for here is selinux. If all your permission are correct and you can still not write to the site1 folder then check selinux. I have to use ‘setenforce = 0′ to get this demo working.

You should now have two users that are completely jailed off from each other with limited abilities to do any damage to your server.

Enjoy

- Nomad

Now I have been RedHat certified for years, the first certificate I got from them was the RHCT (RHEL3) back on 2004, they have made a lot of changes to RedHat over the years and the new two part certification program is nice example of a maturing certification.

I was pleasantly surprised to see all the changes in RHEL6.

• New init script based on upstart
• New cron process anacron
• New disk encryption program LUKS
• New logging process Rsyslog
• Better implementation of SE Linux
• OpenSSH now allows Match directive for chroot jail

I’m looking forward to CentOS 6 which is due out shortly so I can start implementing more of these changes for my customers.

-Nomad

Here is the official definition of what it does directly from their homepage

suPHP is a tool for executing PHP scripts with the permissions of their owners. It consists of an Apache module (mod_suphp) and a setuid root binary (suphp) that is called by the Apache module to change the uid of the process executing the PHP interpreter.

What that means in a nutshell is if the user bob owns the directory (and the files) wordpress is installed in, then all php files and scripts will run as that user. Keeping the typical apache does not have permission to write to that directory/file errors from occurring.

Now installing this on the standard CentOS/RHEL server is pretty straightforward, this guide is for RHEL/CentOS 5, The newer version available with RHEL/CentOS 6 will be discussed in a future article.

Mod_suphp is available via RPM from the EPEL repository (its version 0.6.3 for RHEL 5, version 0.7.1 is now available for RHEL 6 via RPMForge ). So first off you have to have that repository setup, here is a link for EPEL.

Once you have EPEL setup just run YUM

yum install mod_suphp

Move your php.conf file out of the way

mv /etc/httpd/conf.d/php,conf /root/

Next we will need to edit /etc/httpd/conf.d/mod_suphp.conf

# This is the Apache server configuration file providing suPHP support..
# It contains the configuration directives to instruct the server how to
# serve php pages while switching to the user context before rendering.

LoadModule suphp_module modules/mod_suphp.so

### Uncomment to activate mod_suphp
AddHandler x-httpd-php .php .php3 .php4 .php5
suPHP_AddHandler x-httpd-php

# This option tells mod_suphp if a PHP-script requested on this server (or
# VirtualHost) should be run with the PHP-interpreter or returned to the
# browser "as it is".
suPHP_Engine on

# This option tells mod_suphp which path to pass on to the PHP-interpreter
# (by setting the PHPRC environment variable).
# Do \*NOT\* refer to a file but to the directory the file resists in.
#
# E.g.: If you want to use "/path/to/server/config/php.ini", use "suPHP_Config
# /path/to/server/config".
#
# If you don't use this option, PHP will use its compiled in default path.
suPHP_ConfigPath /etc

Next you can edit the /etc/suphp.conf file

webserver_user=apache

;Path all scripts have to be in
docroot=/

;Path to chroot() to before executing script
;chroot=/mychroot

; Security options
allow_file_group_writeable=false
allow_file_others_writeable=false
allow_directory_group_writeable=false
allow_directory_others_writeable=false

;Check wheter script is within DOCUMENT_ROOT
check_vhost_docroot=true

;Send minor error messages to browser
errors_to_browser=true

;PATH environment variable
env_path=/bin:/usr/bin

;Umask to set, specify in octal notation
umask=0055

; Minimum UID
min_uid=500

; Minimum GID
min_gid=500

; Use correct permissions for mod_userdir sites
handle_userdir=true

[handlers]
;Handler for php-scripts
x-httpd-php=php:/usr/bin/php-cgi

;Handler for CGI-scripts
x-suphp-cgi=execute:!self

Once those two files are setup a restart of apache should be all that is needed. Now this goes better some days than others. You may need to use the apache error logs and the suphp log (var/log/suphp.log) to troubleshoot any problems you might get with your specific configuration. You may need to change a few setting within /etc/suphp.conf to get everything working depending on the setup of your apache files.

Enjoy

-Nomad

Elastic Compute Cloud (EC2) – The basic building block of Amazon’s Cloud, Virtual machines that comes in various RAM and CPU sizes. They have 10 OS’s including RedHat Enterprise Linux, OpenSolaris, SUSE enterprise and Windows 2008 ready to use. Not to mention you can upload your own custom VM’s right into their environment.

These virtual machines come with one public IP and one internal network IP. The internal IP is part of the Amazon Virtual Private Cloud (VPC). It allows customers to do extensive customizable networking to meet your advanced security needs. It allows things like custom tunnels between server clusters in different availability zones or even VPN tunneling to your office or private datacenter.

Additional available networking services include Amazon Route 53 for your DNS Service needs and Elastic Load Balancing to balance your EC2 virtual machines.

Amazon Storage- Amazon has two specific types of storage, Simple Storage Service (S3) or Elastic Block Store (EBS). S3 allows for unlimited storage and also includes CloudFront, Amazon’s own Content Delivery Network (CDN). Elastic Block Store is more like a dedicated SAN in the Cloud that can be added to an EC2 instance within that specific Availability Zone. They can be from 1GB to 1TB in size and can be used in various ways to meet your specific storage needs.

Amazon Database as a Service -

SimpleDB – is a highly available, flexible, and scalable non-relational data store that offloads the work of database administration. Developers simply store and query data items via web services requests, and SimpleDB does the rest.

Relational Database Service (RDS)- Relational Database as a service solution to offload your relational database server needs to Amazon. This also automates database backups and scaling issues, so you can concentrate on the front end services.

Monitoring and Deployment Management programs –

CloudFormation – Think of this as a very basic version of puppet or chef for your Amazon Cloud. Allow you to build various templates to quickly standup of additional systems as needed.

CloudWatch – Web based front end for monitoring of cloud resources and your applications. System administrators can use it to collect and track metrics, gain insight, and react immediately to keep their applications running smoothly. It lets you retrieve your monitoring data, view graphs, and set alarms to help you troubleshoot, spot trends, and take automated action based on the state of your cloud environment.

Amazon Cloud Applications –

Simple Email Service (SES) – Is a scalable and cost effect bulk email sending service, much in the same line as sendgrid.com.

Fulfillment Web Service (FWS) – allows merchants to access Amazon.com’s fulfillment capabilities through a simple web services interface. Merchants can programmatically send order information to Amazon with instructions to physically fulfill customer orders on their behalf.

Flexible Payments Service (FPS) - is the first payments service designed from the ground up for Amazon’s customers. It is built on top of Amazon’s reliable and scalable payments infrastructure and provides developers with a convenient way to charge Amazon’s large customer base. Amazon customers can pay using the same login credentials, shipping address and payment information they already have on file with Amazon.

Cloud Servers- This is the most commonly understood part of Rackspace’s cloud. Consisting of large clusters of virtual machines that can be purchases and spun up within a couple of minutes. Servers sized are determined by RAM amount purchased. Starting at 256MB up to 15.5GB, the larger the systems the more hard-drive space and CPU utilization you get.

These are basic building block servers. They have 15 Linux and 2 Windows OS versions available, these systems come pretty stripped down so you can build what you need. Consider these like basic Lego’s simple building blocks that can be used to design a system that meets your needs.

Every server comes with one public static IP and one private network address. The private IP is referred to as “private net”, traffic over this network incurs no bandwidth charges and is not publicly accessible.  Additional public static IP’s can be purchased with proper justification.

The API – Rackspace has a completely open API, which can be used to Launch servers, reboot systems, rebuild systems from images and soon control DNS zone files for your account. There is also a separate API for Cloud Load Balancers and a third API for Cloud Files intergration.

Service Levels in the Cloud- Rackspace has built their business around great support. For cloud servers this support comes in two levels. Standard support, which include 24/7 chat, phone and ticket support. With Standard support though they will not login to your server, they will ensure its up and running and provide you links and guides and assist with troubleshooting but the rest is up to your team.

Now Rackspace’s Cloud really shines with the introduction late last year of Managed Level Support in the Cloud. This is basically the same support model as their traditional dedicated hosting that built the company into a small business support star.

For an additional management fees they offer full management of the OS. Patching, Monitoring and a more robust backup system is also part of their managed offering. They also have a good deal of expertise in vertical and horizontal scaling and will spend the time to help you design and implement a system that meet your scaling needs.  The extra cost is well worth it if your small business does not have a dedicated Linux specialist on staff.

Other Important Rackspace Offerings:

Cloud Files – This is Rackspace’s unlimited storage system. It allows for the storage of files and media and that content can be delivered via Akamai’s content delivery network (CDN). Rackspace provide an API for Cloud Files that allows for you to integrate file storage and CDN capability right into your site or product.

Cloud Email and Apps – Rackspace’s also has become an industry leader in managed email and applications. They can provide managed email, Exchange and SharePoint to meet your businesses every need.

Dedicated Servers and Hybrid Hosting – Last but not least Rackspace’s traditional dedicate servers unit is still a great asset. At the end of the day there are many needs the Cloud can not provide and dedicated systems may still be needed by many companies not only for performance issues but also for compliance such as PCI and HIPPA. Rackspace has the ability to build you not only an amazing Cloud infrastructure but has the specialists on staff to build amazing Hybrid solutions to meet your every need.

- Nomad