Migrating From The Campus Web Service
From Campus Web Server Help
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.
- 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
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.
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.
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.
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:
22.214.171.124 $accountname.uga.edu 126.96.36.199 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.