Table of Contents
Overview
To address some long-standing security concerns, we have deployed a new web server to handle personal web pages of the form:
http://www.cs.princeton.edu/~username/
As of August 15, 2014, this new web server is live and all accounts created after that date are using it. Accounts created prior to that date are still using the old web server. The migration instructions on this page only apply to accounts created prior to August 15, 2014.
There are multiple ways users can handle the migration. The instructions below (one command at the shell prompt) will work for most users and have the benefit that web sites will work on both the old and new web server continually through the cutover.
Important details are below, but the big difference between the old web server and the new web server is that the files are served from different locations in the file system.
Please note that the sooner you begin testing your website on the new web server, the more time you'll have to get it working correctly. CS Staff can assist with the transition, but ultimately you are the arbiter of whether or not your site is working correctly.
Timing
Transition Period (8/15/2014 to 10/13/2014)
During this time, web requests to http://www.cs.princeton.edu/~username/ are directed to the old web server by default and to the new web server for accounts that were created after 8/15/2014 or which have made a specific request to CS Staff to be fully opted-in to the new service.
Also, during the transition, the new web server will be serving user web pages (from files in the new location) at:
http://wwwnew.cs.princeton.edu/~username/
If you use the migration instructions below, your web site will work at both URLs during this initial transition period and you will be all set for the cutover.
Finally, during this time if you have a personal website that must take advantage of the features of the new web server before the cutover, you can contact CS Staff to be immediately opted-in to the service so that the old web server is no longer serving your personal web pages.
The Cutover (10/13/2014)
On October 13, 2014, we will throw the "big switch" and, by default, all requests to http://www.cs.princeton.edu/~username/ will be directed to the new web server. Any personal web sites for users who have not taken action will cease to function until they complete the migration instructions below.
Differences Between the Old and New Web Servers
The main differences between the old and new web servers are (1) which files can be accessed, and (2) for executable files (PHP / CGI) what user the code runs as. Together, these make significant changes and improvements to the security properties of the system.
Implementation of suEXEC
Historically, the apache web server has run as user apache on our systems. CGI/PHP in user home directories was executed as apache, so users were required to manage special file ownership for apache, in many cases making files world-readable. This can be a large security vulnerability. suEXEC is designed to fix this by implementing a wrapper around the exec() call that Apache makes. As the name suggests, suEXEC will execute a file as the owner of that file. What this means is that in your web home directory, you will no longer be required to have files owned by apache or in group apache. When your PHP is executed, files written will no longer automatically be owned by apache; they will be owned by you. Another large benefit to this setup is that CGI/PHP executed by other users will no longer be able to perform operations on your directories unless you explicitly mark your directories as world-operable.
Filesystem Organization and Directory Structure
It is the case that web code that is suEXEC'd is running as you, allowing it full access to your directories as you, and in almost all cases that means read/write access. To avoid this becoming a vulnerability of its own, we are NOT mounting home directories on the web server and are moving web directories out of your home directory:
Old Web Server directory: ~/public_html
New Web Server directory: ~/../htdocs/<username>
For users predating the server, your current ~/public_html directory will not be moved without your intervention.
We have also introduced a mechanism whereby the directory ~/../htdocs/*/private will never be served by Apache, and no .htaccess overrides will be allowed for it. A user could mark this directory owned by them, permission mode 700, and inside of it put CGI/PHP content which is sensitive and should be protected from snooping. This is the mode we suggest using for database connection credentials.
Certain symbolic links (aka soft links) may break as a result of this reorganization. In particular, symbolic links to locations no longer accessible by the web server will no longer work. See Publishing Web Pages for more information.
Migration Instructions
There are two basic approaches we are documenting for the migration. The first is to use hard links to make your files in ~/public_html also appear in the new location. The second is to make a complete copy of everything from your ~/public_html directory to the new location. With either method, it is handy to create a convenience link from your home directory to the new location.
Convenience Link
To make it easy for you to navigate to the new location for your web files, you can create a convenience link:
cd; ln -s ../htdocs/`whoami` public_html_new
Method One: hard links
In this method, we use Unix hard links to effectively give all the files in your ~/public_html directory an additional label in your ~/../htdocs/username directory. With hard links, the same file (i.e., blob of data) will be accessible with two different paths. This means that the additional "copies" don't take up additional storage space and editing the file in one place will change it in both places. Deleting the file in one place will remove it from that directory but it will still exist in the other directory. (The file won't really be deleted until all the instances are deleted.) Note that file attributes (ownership and permission) are associated with the data; changing permissions on one instance changes all the instances.
If you have a straightforward website consisting of static files or, possibly, PHP/CGI files that don't modify the filesystem, this is the method we suggest you use.
The following command (all on one line), will recursively create a duplicate directory structure of ~/public_html in ~/../htdocs/username and make corresponding hard links of all the files:
rsync -avH --delete --link-dest=/u/`whoami`/public_html /u/`whoami`/public_html/ /u/`whoami`/../htdocs/`whoami`
Again, note that this approach creates hard links of all files (but not directories); changing a file in one place will change it in both places (but deleting it will only remove one instance).
Method Two: copy the files
If you have enough disk quota space and need a separate unlinked copy of your website, you can simply create new copies of all your web directory files with this command (all one line):
rsync -vaH --delete /u/`whoami`/public_html/ /u/`whoami`/../htdocs/`whoami`
.htaccess File
By default, the new ~/../htdocs/`whoami` directories are populated with .htaccess files that return 404 responses in order to prevent enumeration of our usernames via the wwwnew server. If you use either of the rsync commands above, this .htaccess file will be removed by the --delete switch. However, if you are starting your new site from scratch, you will need to delete or modify this file in order to allow Apache to serve this directory.
Testing Instructions
In order to view and test your website before the cutover date, visit http://wwwnew.cs.princeton.edu/~<username>/.
Once you are satisfied with the appearance of your webpage on the new server, you are ready for when the switch happens on October 13, 2014. If you would like for the new server to be your live site before the October 13, 2014, switch, send an email to CS Staff to create a ticket and we'll get you opted in to the new web server.
If your website does not work properly on the new server, please contact CS Staff and we will assist.