Changing Your CSLab Password

There are two mechanisms in place for changing your password:

  1. Using ssh, log into apps0.cs.toronto.edu in the same manner as when you initially set your password at account creation.

    Run 'passwd' (note this is /local/bin/passwd which should be the default unless you have altered your PATH).
    You will be prompted to enter your current password, and then a new one twice. The new one must pass complexity tests.

  2. With a web browser, navigate to https://services.cs.toronto.edu and log in with your CSLab account name and password.

    Choose the 'Password Change Website' link, and follow the instructions. The new password must pass complexity tests.

Note that it will take up to 15 minutes for your new password to propagate to all of our systems.

CSLab Web Sites

Whom should I contact if I have problems with the web server?

If you have questions or comments regarding the contents of a particular user's page, you should contact the owner of the page.

If you have questions or comments about the contents of the DCS website, you should send mail to the DCS webmaster at <www AT cs.toronto.edu>

If the web server is not operating properly, or you have a technical question about its operation, please contact your Point of Contact (PoC).

How do I publish documents via anonymous FTP?

Please contact your Point of Contact (PoC) for your FTP directory to be set up.

This will create a directory on the anonymous FTP server where you can publish your documents. You can access that directory from any CSLab host as /cs/ftp/pub/[username]/.

Note: Your /cs/ftp/pub/[username]/ directory is provided only for the purpose of publishing information via FTP. Disk space on the CSLab FTP partition is shared amongst many users and is thus potentially a very scarce resource. Please do not use it for general storage of your files: use your home directory or a work disk instead.

How do I create a web page?

Your web page should already be created. If this is not the case, please send an email to your Point of Contact (PoC) to rectify the situation. The rest of this section will provide details about how to access your web page, as well as usage information.

The URL http://www.cs.toronto.edu/~[username]/ corresponds to the directory /cs/htuser/[username]/public_html/. For your convenience, a symbolic link called public_html to this location has been placed in your home directory.

Note: Your /cs/htuser/[username]/ directory is provided only for the purpose of publishing information via the World Wide Web. Disk space on the CSLab web partitions are shared amongst many users and is thus potentially a contested resource. Please do not use it for general storage of your files: use your home directory or a work disk instead.

I want my files to be available via either anonymous FTP or HTTPS. What's the best way to do that?

All documents in your FTP area can also be retrieved via HTTPS.

For example, if you put the file "example.ps.gz" into the directory /cs/ftp/pub/[username]/, it can be retrieved via either of the following URLs:

  • ftp://ftp.cs.toronto.edu/pub/[username]/example.ps.gz

  • https://www.cs.toronto.edu/pub/[username]/example.ps.gz

Can I allow users to upload files to my /cs/ftp/pub/[username]/ directory via anonymous FTP?

No.

The problem with arbitrarily allowing FTP uploads is that as the delinquents on the Internet find sites that allow them, they use those sites to distribute pirated software and other copyrighted materials.

If you require a mechanism to enable a user without a CSLab account to upload files to our filesystems and no alternatives will work for you (courier of a burned DVD, offsite individual making the files available for download from their own ftp or http server, email attachments, etc.) then please get in touch with your Point of Contact (PoC) to open discussion on the subject.

You should never set the permissions for any file in your FTP area (or under your /cs/htuser/[username]/public_html/ directory) to be world-writable. Making your FTP area world-writable will not allow anonymous FTP uploads to take place there.

Are the FTP and HTTP/S logs available to me?

The server logs are located on www.cs.toronto.edu, in the directory /var/log/apache2. The web transfer logs are in the file access.log. The web error logs are in error.log, also in that directory.

What am I allowed / not allowed to put on my web pages?

Anything you put onto your web pages must conform to CSLab policies and University of Toronto policies.

How do I publish a CSRG technical report?

DCS technical reports are available for anonymous FTP or HTTPS access, so that anyone on the network can obtain the formatted reports electronically.

The reports are stored as compressed PostScript files in the directory /cs/ftp/pub/reports. You can tell people to get these reports "by anonymous FTP from ftp.cs.toronto.edu, in pub/reports", or, if you prefer, at the HTTPS URL https://ftp.cs.toronto.edu/csrg-technical-reports. Modern browsers are less and less willing to open ftp links, so you may find the HTTPS URL to be more useful.

If you'd like to make a report available for anonymous FTP, please send mail to <techreports AT cs.toronto.edu> including the title and author(s). A report number will be assigned, a directory will be created for it, and it will be added to the index. You can then copy your report into this directory.

I want to co-author a set of web pages with some colleagues as part of a collaborative project. How do I set this up?

Please see our page on Project Collaboration

Using The CSLab Web Server

What web server software do we use at CSLab, and where can I find documentation for it?

We use the Apache web server. The documentation for the version of Apache we're currently using (2.4) is here.

Why can't I access my home directory from the CSLab web server?

The web server runs unaudited programs which may be written by any CSLab user. Such programs could easily contain security holes. For this reason, the security of the web server host is inherently poorer than the rest of the lab.

As such, the web server is generally trusted much less than the rest of the lab's workstations and servers. It does not have permission to access user home directories, project directories, mailboxes, or most other CSLab filesystems.

In general, the web server is considered to be outside CSLab for the purposes of security and trust.

Note that this means that when you log into www.cs.toronto.edu, details such as your environment variables will probably not be set up the way they usually are when you log into a compute server, since the server can't read the .cshrc file in your CSLab home directory.

I set up my pages in my public_html directory, but web browsers report "403 Forbidden" when I try to access them. What's wrong?

Most probably, you've set the permissions on your files or directories too strictly, so that the web server isn't able to read your files.

In general, directories beneath your public_html area should have permissions rwx--x--x, and files should have permissions rw-r--r--. This allows the web server to read your files, but not write to them.

Other reasons you might get this error include:

  • you've set up a symbolic link to a file you don't own;
  • you're trying to browse a directory, but indexing has been disabled for that location;
  • there is an .htaccess file in the directory (or in a parent directory) which the web server can't read. Since, for all the server knows, the .htaccess file might contain directives which would restrict the distribution of the document, the server plays it safe and refuses to serve anything the access file might apply to.

Why won't the web server follow my symbolic link?

By default, the server will only follow symbolic links if you own the file or directory the link points to. You should not be pointing symbolic links at other people's files.

The reason for this restriction is that a user might want some of his files to be controlled by an .htaccess file; for instance, he or she might want certain files to be published to only specific hosts or networks, or to be password protected. However, if you created symbolic links to those files within your own pages, you'd bypass the user's .htaccess file!

Symbolic links within the web server's space should be avoided, in general. If you want to refer to someone else's pages from within your own, it's probably more appropriate to use a Redirect directive to send the visitor's browser to the user's page.

Why are browsers reporting "500 Internal Server Error" for my web pages?

This is almost always due to an error in an .htaccess file in the directory containing the pages, or possibly a directory above it. The file /var/log/apache2/error.log on the web server may include error messages which will help you determine where the error is.

How do I create a CGI program?

At CSLab, CGI programs generally must have filenames which end in ".cgi", to identify to the server that you really intend the program to be run as a CGI. The program must also be executable by your user id (i.e., chmod u+x program.cgi).

If your CGI programs use files to store information, you should probably make sure that those files are not anywhere under your /cs/htuser/[username]/public_html/ directory. Doing so would allow the web server to publish the file without going through your CGI. Instead, you should create other directories under your /cs/htuser/[username]/ directory, e.g., /cs/htuser/[username]/private_cgi.

(If you maintain web pages in a project directory under /cs/htdocs/, the CGI programs for those pages should keep their files in a corresponding directory under /cs/htdata/. If such a directory doesn't already exist, ask your Point of Contact (PoC) to create one for you.)

My CGI program isn't working. How do I go about troubleshooting it?

The topic of troubleshooting CGI programs in general is beyond the scope of this document, but there are a few things you should keep in mind:

  • The error messages from the HTTP server process that that runs your CGI, and by default the stderr stream of the CGI itself, get sent into the file /var/log/apache2/error.log. Check that file for clues as to why your program isn't running.
  • Also remember that the environment on the web server is quite different than on CSLab's compute servers (see question above). You might want to log onto the web server host to test your CGIs in more or less the same environment the HTTP server runs under.

How can I restrict access to my web pages to specific hosts or networks?

Use the mod_authz_host directives in an .htaccess file.

Also note that the ErrorDocument directive can be used in the .htaccess file to explain why you're denying access to your pages (e.g., ErrorDocument 403 /~[username]/denied.html).

How can I put a password on some of my web pages?

Although you can protect web pages with a password, be aware that neither the password nor the documents themselves are encrypted as they travel over the network, so the password protection is not an absolute guarantee of privacy by any means.

Furthermore, remember that the server is shared by all CSLab users, and runs with the same privileges for everybody; any local user can write their own CGI program that can read the files you're trying to protect with a password.

Here's a walk-through of the steps required to set up password access on a directory:

First, create a directory where the papers will be kept. This needs to be someplace under your public_html/ directory. 

    hostname.cs>  cd /cs/htuser/[username]/public_html
    hostname.cs>  mkdir -m 711 protected
    hostname.cs>  cd protected
    hostname.cs>

Now, create a file called .htaccess in this directory which will tell the web server that restrictions are to be placed on this directory. The file must be world-readable (but should be writable only by you), and should contain the following lines: 

    AuthType Basic
    AuthName Password-Example
    Require valid-user
    AuthUserFile /cs/htuser/[username]/auth/example-passwords

This tells the web server that in order to access anything in this directory, a valid user and password from the file /cs/htuser/[username]/auth/example-passwords must be supplied.

Note that the password file should not be under your public_html/ directory! If it were, then people could steal your password file (by fetching the appropriate URL) and possibly use it to figure out the usernames and passwords you've set.

The name in the "AuthName" line (in this example, "Password-Example") will be used by the user's browser when the password is being prompted for; it'll say something like "Enter username for Password-Example at www.cs.toronto.edu." You can choose any AuthName you wish. Note that if the name you choose contains spaces, you must enclose the name in quotation marks; that is, you must write 

    AuthName "Members Only"
  • and not 
    AuthName Members Only

Finally, you need to create that password file. The format of the file is a username, followed by the encrypted password, with a colon (":") separating them. The password is normally encrypted using the crypt() library call, although other encryption methods are available.

You can use the htpasswd command on the CSLab webserver, www.cs, to create and update this passwd file: 

    www.cs>  cd /cs/htuser/[username]
    www.cs>  mkdir -m 711 auth
    www.cs>  cd auth
    www.cs>  htpasswd -c example-passwords example
    New password: (type the password and press enter)
    Re-type new password: (type the same password again)
    www.cs>  chmod 644 example-passwords

Note: the htpasswd command is not installed on CSLab's apps and comps machines -- only the webserver. The -c option tells htpasswd to create the file, since it doesn't already exist.

You can add more users to the file if you want (e.g., htpasswd example-passwords example2), and give each his or her own password; the require valid-user line we put into .htaccess above means that any valid user/password combination we put into the file will grant access.

You can use the same password file to control multiple directories, and you can restrict different directories to different users by using an appropriate mod_authz_user directive in their respective .htaccess files.

If everything has been set up properly, then attempting to access any documents under the URL http://www.cs.toronto.edu/~[username]/protected/ should now cause the web browser to prompt the user for a username and password. Supplying the username "example" and the password you typed into the htpasswd command above should give you access to the document.

Does our web server support SSL (https://)?

Our web server does indeed provide SSL support; simply use the https URL instead of http. But please keep in mind that the CSLab web server is intended to be a research system, not an e-commerce site. The server is shared by hundreds of users, and there is no practical means by which we can ensure to a high degree of certainty that the security of the web server will never be circumvented. The CSLab web server should not be used to accept or publish sensitive information, such as credit card numbers, as it cannot be made as secure as an isolated webserver dedicated to such a purpose. This is irrespective of whether or not encryption is employed to protect the data as it passes over the network.

User-Managed Webservers

Running your own webserver for advanced configurations.

General introduction and concept

Specific how-to instructions

CSLab email specifics

Your Electronic mail (Email) addresses are (both are equivalent): 

    user@cs.utoronto.ca
    user@cs.toronto.edu

Where is Web Mail?

Web Mail is available at https://webmail.cs.toronto.edu/

How do I set up an autoreply message when I am on vacation?

Please see our email page.

How do I forward my email somewhere?

Please see our email page.

What settings should I use so that I can use the CSLab mail servers for sending and retrieving email?

Please see our email page.

Should I run a virus shield on my Windows or Mac to screen email attachments?

In general, do not open attachments or follow links in any email you did not expect, even if it appears to be from a trusted sender (it is easy to forge a sender on an email message). If you receive an email with an attachment or a link, ask the sender for verification before opening it. This may be a nuisance, but it is not as much of a nuisance as dealing with the aftermath of having your machine compromised by an attacker.

I have received an email from the CSLab staff containing some important news/information/data. Did you really send it to me?

CSLab staff will never send you an email containing an attachment. Do not open the attachment, it more than likely contains a virus.

I am getting a ton of junk mail and spam. Please help!

Please see our spam page.

I think somehow some of my recent email was lost, or I accidentally deleted some messages. What can I do?

You can use your oldmail to retrieve copies of recent email that you've received. Please see our basic email page for details.

Are there any official mailing lists of grad students, faculty, staff, etc?

Yes, there are some authoritative departmental mailing lists: these are documented on DCSWeb (CSLab login required).

I want to set up a mailing list. How do I do that?

Please go to our mailing lists page.

I want to set up a mail alias for myself, so that people can email me at some other address than my login name. How do I do that?

Please go to our mailing List page and set up a mailing list of the desired name that has yourself as the only member.

As a remote user can I make a Samba connection to the CSLab Samba server?

You cannot access Samba directly. This step was taken because Samba credentials although hashed are sent in the clear. You will want to use one of our VPN servers to access samba from outside our networks.