2010 Apache Web Hosting Changes for Customers

2010 Apache Web hosting customer migration document

Overview

During the summer of 2010 CNS has created a new Apache web hosting environment for our hosting customers. As of August all new customer websites will be created on the new cluster. Furthermore, over the next few months we will be working with our existing customers to migrate their websites to the new infrastructure.

This new infrastructure comes with a handful of significant design changes of which our customers will need to be aware.

Questions?

After you've looked over this document please send any questions or comments to cns-hosting-request-l@lists.ufl.edu

Impacting Changes

1) New document root location. We're moving website document roots under customer's home directories. Most customers already have a "cnswww-" userid, if you don't yet, we will provide you with one as we move your site.  With this in mind your document root will be as follows:

/h/<cnswww-user>/<website>/htdocs/

2) No more NERSP/NERSP user ids. Some of our older customers still use NERSP to manage their websites. If you still use NERSP to access your document root, this will need to change. For several years we have been moving our hosting customers into using non-NERSP ids, and with this new infrastructure we must migrate any cusomers remaining on NERSP to the new userid conventions. If you already have a 'cnswww-' userid and log in to glint to work on your site, then this item doesn't apply to you.

3) PHP execution through CGI wrapper.  In the past PHP has been available through two methods- shebang line call to the php-cgi binary in your scripts (execution via suexec) or php-fastcgi.  We are now moving to utilizing a wrapper script and server define Action that calls the wrapper script for all .php files.  This allows php to be executed via suexec without the requirement that customers place shebang lines in their code (#!/usr/bin/php-cgi).  This should simplify the deployment of pre-canned php apps like wordpress without incurring the resource costs of creating dedicated php fastcgi processes. 

If your website already has shebang lines and you're OK with that we can certainly leave it as-is.  Otherwise your site will have a script-alias set for:

 /cgi-bin/ -> /h/<cnswww-user>/<website>/cgi-bin/

We will provide the php wrapper script as:

/h/<cnswww-user>/<website>/cgi-bin/php.cgi

This script will be used to handle all .php file execution.  So if you delete the script your php will stop working.

4) PHP FastCGI reserved for high-traffic websites.  Previously we provided php-fastcgi to most any customer who wanted to avoid putting shebang lines in their php code.  This resulted in an unneccessary proliferation of php-fastcgi processes.  As mentioned in (3) above, this is no longer necessary to avoid shebang lines, so php-fastcgi will be provided only for high traffic, mission-critical websites.

Non-impacting Changes

This is a list of changes to the architecture that should cause little to no impact to customers.

1) New linux distro: The new webservers are Red Hat Enterprise Linux

2) FastCGI moved to each webserver in the cluster. In the past FastCGI has been provided by dedicated servers that the webservers must connect to and hand off execution.  This created a potential single point of failure. In the new architecture FastCGI execution will exist on each node of the web cluster.

3) Shibboleth moved to each webserver in the cluster. Like FastCGI, shibboleth execution was previously offloaded to a dedicated server which introduced a potential single point of failure. In the new infrastructure a shibboleth daemon will run on each node in the web cluster.