Jens Nöckel's Homepage

Computer notes home

Getting access to your web hosting account at the UO

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 Here's what you need to do:

  1. Make sure you know your DuckID password (that's the one you use to get your UO email).
  2. If you have never used web hosting at the UO, open a browser and type This should forward* you to a page ( 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.
  3. The most important information you need, of course, is what you want to put online in the first place. So gather all the files for your web site in an easily reachable directory, perhaps named 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.
  4. Test your access to the shell server. There are various ways to do that, here are some:
    • Open a terminal window on your computer (assuming linux or OS X), navigate to your local Sites folder and type sftp, 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.
    • To exit the connection to the web server, type bye.
    • Alternatively, download an 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 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: does not allow old-style ftp connections, only secure sftp access; so make sure your program supports that.
  5. You may ask whether you can also use 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 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
  6. Keep in mind that your web access (shell) password is the same as that of your UO email account! Therefore, if you value your privacy, do not give that password to anyone who doesn't need to know. This would also include online services that offer to help you compose web pages and then ask to save them to your UO hosting account. It's not a good idea to let web pages from domains outside your control get write access to your UO account in any form.

Running scripts on your UO website

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.


The PHP versions available on the shell server are reasonably up-to-date.

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:

$pwuid = posix_getpwuid(posix_geteuid());
if (is_file($_SERVER['PATH_TRANSLATED']) &&
      ($pwuid['name'] === 'nobody' ||
       $pwuid['name'] === 'apache' ||
       fileowner($_SERVER['PATH_TRANSLATED']) == posix_geteuid())) {

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 and others

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.

Limiting access, setting permissions

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.

  1. If you (intrepid user yenz) have a file (say file.html) in your public_html directory but can't see it in a browser by going to, 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.
  2. 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.

URL rewriting to

If you've been at the UO for a while, you may have noticed that starting in 2010 URLs such as are being rewritten in your browser window to the default form The only old-style URL that is not rewritten is (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, short URLs ( 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

Blogs, Wikis and Content Management

There is (as of 2013) a dedicated blogging infrastructure at the UO, based on Wordpress: Better late than never... and this means you don't have to install your own blogging software on the server anymore.

Jens Nöckel
Last modified: Sat Jun 15 22:50:33 PDT 2013