Since I've helped several people set up their UO web pages in the past, I've decided to put together this IT help page for reference. This is not my day job, but I've spent many years as the volunteer web maintainer for the Department of Physics and the Institute of Theoretical Science.
If you're new to the UO, you may be wondering how to establish your web presence here. First you must have set up your DuckID password at the web page linked here. Let's say your DuckID user name is yenz, then you'll want to be reachable at the URL uoregon.edu/~yenz. Here's what you need to do:
uoregon.edu/~yenz. This should forward* you to a page (pages.uoregon.edu/yenz) that contains nothing but an empty directory with the title Index of /~yenz. If it doesn't, then you need to contact IT help to get an account set up.
Sites (on OS X, that's where you would normally publish your web site). I'll assume that you want everything in this folder uploaded to the web site. If you don't actually have anything to upload but want to install a blog or content management system, jump to the end of the page.
Sites folder and type sftp yenz@sftp.uoregon.edu, followed by the password. You will hopefully see a prompt allowing you to type commands. Try ls, and look for an item called public_html. That's the directory holding your web space. If it doesn't exist, create it by typing
mkdir public_html at the command prompt, followed by chmod o+rx public_html (the latter makes the directory contents visible on the web). Now enter that directory using cd public_html and upload everything in your local Sites folder by typing mput * (the star is a wildcard, and could be replaced with specific filenames if you want to upload in a more selective way). For more information about the allowed sftp commands, type help.
bye. FTP program such as Filezilla and follow their instructions for connecting to a host. See this tutorial for more info. Basically, your sftp client program will need sftp.uoregon.edu as the server (host) name, and public_html as the directory path on the remote server. The local directory is obviously the Sites folder mentioned above. One warning: sftp.uoregon.edu does not allow old-style ftp connections, only secure sftp access; so make sure your program supports that.
ssh to get full command-line access to your web space, rather than using sftp. For example, you may want to do some file manipulations directly in public_html that you can't do with sftp. Unfortunately, this is not allowed by default. If you need ssh access, first check the options available for your account at duckid.uoregon.edu and see if you can enable it there, following these instructions. If not (these policies may change after I write this) contact IT help to have this enabled. But remember that sftp lets you do most things that are needed for a web site, e.g., changing file permissions using chmod. To access the command line using ssh, use ssh yenz@shell.uoregon.edu.
Why am I talking about the scripting languages here? Many web applications rely on PHP, Python, Perl etc. Support for these scripting languages on the shell server has always been more or less hopelessly behind in terms of version updates, but if you're a programmer you can probably make it work once you the UO-specific idiosyncraties. If this sounds discouraging to you, the non-programmer, it's OK — you can stop reading now.
On most (Apache) web servers, PHP is enabled as a module such that files with extension .php and world-executable permissions (type chmod 755 at the shell command line) are served as if they were regular HTML pages except for the additional new "tags" <? ... ?> and <?php ... ?> which encapsulate the script parts of the page.
On the UO shell server, on the other hand, a php page is run as a CGI script which means it has to start with the line #!/usr/local/bin/php (or #!/usr/local/bin/php5 for the latest version). What this means is that you will not be able to directly run most canned php scripts on the UO server. To fix this, one approach is to add these starting lines to all those php files which are meant to be served as web pages (i.e., which are not meant to be included in other php files using e.g. the require command). This can be a rather complicated task for larger script collections.
An alternative way of porting an existing set of PHP pages to the UO server works by re-routing their execution through a single CGI script that prepends the missing line. There is a description on the Computer Science web site, but the problem is that the version of PHP it uses is too old for modern uses. So you have to use a slightly different version that invokes PHP5:
#!/usr/local/bin/php5
<?php
$pwuid = posix_getpwuid(posix_geteuid());
if (is_file($_SERVER['PATH_TRANSLATED']) &&
($pwuid['name'] === 'nobody' ||
$pwuid['name'] === 'apache' ||
fileowner($_SERVER['PATH_TRANSLATED']) == posix_geteuid())) {
chdir(dirname($_SERVER['PATH_TRANSLATED']));
include(basename($_SERVER['PATH_TRANSLATED']));
}
?>
Save this as php.cgi in the directory where you'd like to install your scripts, e.g., ~/public_html/here/, and type chmod 755 ~/public_html/here/php.cgi. Then in the same directory, create (or edit) a file .htaccess and put these lines at the top:
RemoveHandler .php AddType application/my-httpd-php .php Action application/my-httpd-php /yenz/here/php.cgi
Don't forget to replace the user name yenz by your own user name!
Python is another common scripting language on the web.
Until June 2013, the latest version installed here is python 2.3 which is too old for
many recently released web applications. Starting late June, a large-scale upgrade of the server software and installed packages should allow you to utilize version 2.6.
However, if you do want to use Python, or any language other than PHP, there is another potential pitfall you should be aware of: by default, your script has to have the suffix .cgi in order to be recognized by the web server. This makes these scripts different from PHP. With the extension .py, the web server will simply print a Python file as text, thus revealing the code instead of executing it. This requirement of choosing the .cgi extension affects only those script files that are to be called directly by the web server. Anything that only gets called via import statements from within another script is allowed to have the .py extension.
Two problems that can happen with a web site are: (1.) you want people to see your pages but they can't, or (2.) you don't want people to see your pages but they can.
yenz) have a file (say file.html) in your public_html directory but can't see it in a browser by going to pages.uoregon.edu/yenz/file.html, there is most likely a problem with your file permissions. Open an sftp connection (as described above) and type chmod o+rx ~/public_html followed by chmod o+rx ~/public_html/file.html and the problem should be fixed.
Not all files on your web site may be intended for the general public. However, if you upload them as described at the top of the page, the only thing that protects your files from being seen is their level of "obscurity" - i.e., how well hidden they are in your directory structure. Even this is not really much help, because all those other UO students and faculty who have a shell account could potentially explore your public_html directory in the same way that they browse through their own account. Without administrator privileges (to set access controls via setfacl) you cannot really protect yourself from this.
However, you can prevent web browsers from accessing the contents of certain directories. Follow the instructions on the linked page to achieve this.
uoregon.edu/~yenz are being rewritten in your browser window to the default form pages.uoregon.edu/yenz/. The only old-style URL that is not rewritten is darkwing.uoregon.edu/~yenz (and for students, gladstone). Ironically, this is a URL format that users were advised not to use anymore after a server upgrade a few years ago, touting among other reasons the availability of a "shorter" URL. With the (in my view arbitrary and unnecessary) change to pages.uoregon.edu, short URLs (uoregon.edu/~yenz) still work fine, except that the browser's URL bar will confusingly display a longer URL than what you typed. If you don't want your audience to worry that they mis-typed the URL, you should publish links to personal UO web pages in the longer form pages.uoregon.edu/yenz.
There is (as of 2013) a dedicated blogging infrastructure at the UO, based on Wordpress: http://blogs.uoregon.edu/. Better late than never... and this means you don't have to install your own blogging software on the pages.uoregon.edu server anymore.