Migrating From The Campus Web Service

From Campus Web Server Help

Contents 1 Overview 1.1 Enhancements 1.2 Differences Requiring Intervention 2 Required Adjustments 2.1 MyID Authentication 2.2 Aliases Become Virtual Hosts 2.3 PHP4 to PHP5 Code Tweaks 2.4 PHP Sessions + Load Balancing 2.5 LDAP Authentication, PHP Settings, and .htaccess files 2.6 Where Is The Content? 2.7 Review World Permissions 3 Testing 4 Activating Your New Site

Overview

Sites migrated from the legacy web server, also known as the "Campus Web Service", should expect differences in the new environment. The differences are outlined below. For general service documentation, see UGA Webhosting: Standard Edition. Be sure to complete testing of your site and submit your migration request before November 9, 2011.

Enhancements

• MyID authentication (using a special account)
• Automatic provisioning of an UGAMail corresponding account
• PHP5 running as the script owner and under FastCGI (It's possible to disallow group and world-readable attributes!)
• Custom php.ini files and personal PHP error logs
• A virtual host for every site (i.e. yoursite.uga.edu)
• A multi-tiered architecture, including redundant front-end web servers for increased reliability and scalability
• A three-stage development environment (dev, staging, and production) for better change management
• Hosted MySQL 5.1 databases (paid option); MySQL client is still free, though
• Java Appliction Hosting on Tomcat6 (paid option)
• Apache 2.2
• SQLite database support
• ModSecurity with the ability to customize rules
• ModEvasive to deter DDOS attacks
• Free SSL support upon request (for *.uga.edu domains only; not compatible with *.*.uga.edu)

Differences Requiring Intervention

• A password change due to the implementation of MyID authentication
• FTPS login is no longer allowed. Only SFTP and SSH is allowed.
• Developers will connect to ugawebhosting.uga.edu instead of www.uga.edu in order to upload content
• Debugging any PHP errors resulting from the upgrade to a PHP5 interpreter
• .htaccess files using LDAP authentication will need to use the newer mod_authnz_ldap directives
• Fixing path references to conform to the virtual host configuration (alias sites will be "up one level")
• Files reside in /usr/www/$ENVIRONMENT/yoursite (where $environment is one of dev, stage, or prod)
• We strongly recommend that you review the need for world-readable attributes; such rights need only be given to static files, such as CSS, plain HTML, and images

Required Adjustments

MyID Authentication

Web hosting accounts will now require a special MyID, typically named after your legacy web server account name. Some accounts conflicted with existing myids; those usernames are now $accountname-web, unless you have notified us that you own the existing MyID and that you would like to use it for web content management also.

At some point, if not already, EITS will contact you with the initial account username and password. You must change that password upon initial login. You will be required to set a new password and question/answer pairs for this account, just as you do with a standard MyID. Standard MyID password policies, expiration reminders and expirations apply, except that usernames may be longer than eight characters and may contain dots and dashes.

Aliases Become Virtual Hosts

Accounts previously accessible using http://uga.edu/yoursite will be accessed using http://yoursite.uga.edu. The old addresses will continue to work for one year. Users will be redirected. For example, browsing to http://www.uga.edu/toli/practice.html will redirect one to http://toli.uga.edu/practice.html. Effectively, content moving from an alias to a vhost configuration will be"up one directory level". So, you will likely need to adjust links and references accordingly. Those who consistently used relative links will be rewarded for their foresight. Using relative paths and links will cause your old alias site and the new vhost version to render properly.

Furthermore, avoid use of an initial forward slash in references. Instead, use links like ../../images/president.jpg. For example, an image src attribute in a document at http://club45.uga.edu/bios/president/index.html should reference the /images/president.jpg with ../../images/president.jpg. This will make your site more portable (easily moved to different servers).

Using virtual hosts allows us to decouple sites from the main uga.edu website. It will be easier to move your site to a new server in the future.

You should begin advertising the new URL and removing links and references to the old URL as soon as your site's migration is complete.

PHP4 to PHP5 Code Tweaks

Differences in the new PHP5 interpreter may cause some older PHP4 code to break. Testing should be done to ensure that your application behaves as it should

PHP Sessions + Load Balancing

With load balancing, as we now have, PHP sessions can be easily lost. If you use PHP sessions, you should change your session save_path, be sure to change the default session handler or "save path". Details about how to set these is beyond the scope of this article. You will likely want to refer to PHP Configuration to create a custom php.ini file.

Currently, the load balancer sticks visitors to the same server for only two minutes of inactivity. Requests made after two minutes of inactivity will likely result the user's session being lost, as he will probably be routed to another web server.

You'll find the simplest way to deal with this is to set the session save path to be somewhere in your content directory, which is on a shared file server (using NFS as of 3/22/12). Remember, from the viewpoint of the web servers, your content is in /usr/www/$username; so, user gleeclub might choose a "save path" of /usr/www/gleeclub/other/sessions. Of course, you must create the folder you will use in each development tier used. It should be writeable by only your user.

Writing to a shared file store may prove slow for high-traffic sites. Memcache is a faster, built-in handler. But, we do not provide memcache servers as of 3/22/12. Feel free to drop a line to the helpdesk if you'd like to see memcache offered in the future.

Creating your own session handler to store to a database is not difficult either. Online instructions abound. We do not have sufficient data to determine whether file-backed or database-backed sessions are faster on our system. Start with the easy option and see if that meets your needs.

LDAP Authentication, PHP Settings, and .htaccess files

Some sites use LDAP to authenticate users to the site with Apache Basic Authentication, whether it be MyID or other LDAP provider. Apache 2.2 uses mod_authnz_ldap. Developers must change directives in .htaccess files to utilize the directives pertaining to this new module. Don't forget to use the new AuthBasicProvider directive as well.

We are now running PHP in FastCGI mode, rather than as a module. PHP configuration settings can no longer be made in .htaccess files. They must be set via the script or in a custom php.ini.

Where Is The Content?

The old server stored files in /usr/www/YOURSITE. We've kept that convention, but with a twist. There are now three environments, from development to production. You'll notice there are now /usr/www/prod/YOURSITE, /usr/www/stage/YOURSITE, and /usr/www/dev/YOURSITE directories. When uploading files, simply place your content in the directory according to it's current phase of your development cycle.

Scripts other than PHP should be placed in the cgi-bin folder (see Standard Edition: CGI Scripts and Standard Edition: Directory Structure).

From the web servers' perspective, the content path will continue to be /usr/www/YOURSITE. So, there is no need to reference the environment portion of the path in your code or content.

Review World Permissions

Permissions can be confusing. The new environment allows much stricter permissions than the old. But, most things will continue to work without modification if you are uninterested in taking advantage of the better security of tight permissions. If PHP scripts refuse to run with an 500 Internal Server Error, just be sure that the script is only writable by your user (rw------- or 600). If you are ever trying to make something work, do not trust forum suggestions to set everything to 777.

This new environment allows requires scripts (PHP, perl, bash, python, etc) to only be writable by the owner. There is no need to allow read nor execute permissions to the group or other users either. So, in octal representation, scripts should be set to 700. You may also create directories with these permissions, so long as it contains no static content that you wish for Apache to serve directly. In this way, you can secure information from the prying eyes of others. There should be no world-writable directories or files. No matter what you see in any forums, DON'T USE 777! See Standard Edition: CGI Scripts for more information.

Static content that must be served by the web server (and not via a script) should be readable by the apache user. Static content includes types like HTML, images, CSS, javascript, etc. So, you must set the world-readable permission bit for it. In octal representation, an appropriately set file would be 644. Accordingly, any directory or parent directory containing static files should be accessible by apache (an "other" user). Such directories should be set to 711. Really, you should read Standard Edition: CGI Scripts.

Testing

With the above changes in mind, please test your site. If appropriate, test the corresponding SSL (HTTPS) site as well. See that all formatting, downloads, access controls, images, references, links, redirects, forms, etc, work as expected. As mentioned, legacy URLs like http://uga.edu/$accountname/ should continue to work for about one year from migration. Aside from being sure to review links, image paths, form submissions, etc, you should test your site using the following URLs:

http://test.www.uga.edu/$accountname (if it was ever accessible this way)
http://test.www.uga.edu/$accountname/$link_below_docroot (if it was ever accessible this way)
http://dev.$accountname.uga.edu
https://dev.$accountname.uga.edu (if you have requested your site to be accessible via HTTPS)

$accountname is the username that you are accustomed to on the old server. $link_below_docroot is a URI on your site, such as /courses/23424.html.

To most accurately test your site as it will be after migration, you will need to modify your system's "host file" with a simple text editor, such as notepad. The location of this file is described in the Wikipedia article. During testing, you should add a line like this to your file:

128.192.1.181 $accountname.uga.edu
128.192.126.147 uga.edu www.uga.edu

Remove these lines when you are not testing. It's a good idea to restart your browser after adding this line to avoid having the browser use it's internal name cache. If you choose to modify /etc/hosts as described above, you can test using these links:

http://www.uga.edu/$accountname (if it was ever accessible this way)
http://www.uga.edu/$accountname/$link_below_docroot (if it was ever accessible this way)
http://$accountname.uga.edu
https://$accountname.uga.edu (if you have requested your site to be accessible via HTTPS)

If you find something's not right, you can login and fix the code using your new account.

If you use a domain name other than $accountname.uga.edu for your site, please try http://dev.$yourdomain. If you manage the DNS for the domain, create a CNAME for dev.$yourdomain pointing at webhostingsrv-c1.dev.uga.edu.

If your code connects to another system, you may need to open firewall ports on that system. Refer to the List of Servers to see which servers are actively being used for UGA Webhosting.

Activating Your New Site

Once you are satisfied with your development site, submit a formal request for migration by 5 p.m. on November 9, 2011 (http://webmigration.uga.edu)

EITS will only migrate sites upon formal request. If you do not request to have your site migrated, it will be taken offline and archived on November 12, 2011.