Lab Computers

SSH edit

SSH (Secure Shell) is a tool used to securely login to remote computers from anywhere with an internet connection. All Computer Science students and staff have SSH access to a variety of computers operated by the School of Computer Science, including:



Linux/Mac OS X

If you are using a machine running Linux, OS X, or some other UNIX varient, then you should already have SSH installed. To confirm that it is installed, open a terminal and enter:

which ssh

SSH is installed if you see some output like:


If you do not see output, you will have to install SSH yourself.

  • On Linux, use your distribution's package manager (ie. apt-get install openssh-client)


Windows does not include an SSH client by default, users should install the open-source program called PuTTY.

Basic Usage

On Linux/OS X SSH is very easy to use; to connect to our server named mimi, simply run the command:


You will then be prompted to enter your password. If your credentials are accepted, then you're done; you are now logged in to mimi and can use the bash shell normally.

Windows users should open PuTTY, then enter as the host name. A terminal will open up where you can enter your password then use the bash shell normally.

To terminate the SSH session, use the command exit

Connection to closed.

SSH Keys

A more convenient and secure way to login to a remote computer is to use SSH keys instead of a password.

How Do SSH Keys Work?

SSH keys are based on public key cryptography. The basic protocal is as follows:

  1. On your personal computer, generate an SSH key pair. The key pair contains a public key, which you can place anywhere you want, and a private key, which you must keep safe.
  2. Place your public key on the server you would like to access.
  3. When you try to login to the server, the SSH program on the server will use your public key to generate a message that can only be decrypted using your private key.
  4. If your computer has your private key on it, it will decrypt the message and send an appropriate response.
  5. SSH will then log you in and encrypt all the traffic between your two computers.

How to Set Up SSH Keys

First, on your local machine, create an ssh key pair:

ssh-keygen -t rsa -C ""

It is recommended to use the default settings and use a strong passphrase. The passphrase is used to encrypt the key itself in case it is lost or stolen. There is no way to recover your key if you forget your passphrase.

The keys live in the ~/.ssh directory

ls -l ~/.ssh
-rw-r--r-- 1 demo demo 807 Sep 9 22:15 authorized_keys
-rw------- 1 demo demo 1679 Sep 9 23:13 id_rsa
-rw-r--r-- 1 demo demo 396 Sep 9 23:13

Note that the id_rsa (private key) file is only readable and writable by the owner. It needs these strict permissions to keep it safe. SSH will reject keys that do not have these permissions. The is the public key that you can share. authorized_keys is a file used to keep track of the public keys that are able to access this computer.

You can now transfer your public key to the remote server


Which will start an SSH session, once you enter your password, your public key will be transfered to the server. From now on, you won't have to enter your password when loging in over SSH.

SSH Tunnelling + SOCKS Proxy

When using insecure networks the following will allow you to browse privately

ssh -D 9999 -l cs_username (or 

Remember to point your browser to use the proxy on port 9999

Graphics over SSH

To be able to log in to one of the lab machines from an MS Windows machine at home and then run applications like Eclipse, xemacs, etc...

Go here and follow the instructions for downloading and installing an X server (Cygwin/X).

To be able to use graphics over ssh while using OpenSSH on a UNIX environment, simply use a command like this:

ssh -X -Y -C

This will tell OpenSSH to use X forwarding so you can run graphical applications remotely.

Connecting to a Computer for the First Time

When you connect to a server for the first time, SSH will prompt you to confirm that you would like to connect to the machine.

Host key not found from the list of known hosts. Are you sure you want to continue connecting (yes/no)?

If you anwser "yes" then it will add the new server to the list of know hosts. This list contains servers that SSH accepts as secure. In the future, SSH will find the server on the list and will not ask you to continue.

Host '' added to the list of known hosts.
Last login: Fri Jan  7 14:23:00 2000 from console
Linux 2.2.16 #4 Fri Jun 9 14:06:43 EDT 2000 i686 unknown

SSH's Most Common Warning Message Explained

Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the host key has just been changed.
Please contact your system administrator.
Add correct host key in /user/abatko/.ssh/known_hosts to get rid of this message.
Agent forwarding is disabled to avoid attacks by corrupted servers.
X11 forwarding is disabled to avoid attacks by corrupted servers.
Are you sure you want to continue connecting (yes/no)?

This means that the identity (or key fingerprint) of the server has changed. Most likely the machine was upgraded...

If you are confident that you are not the subject of a man-in-the-middle attack. Follow the directions in the error statement to remove the old key (inside ~/.ssh/known_hosts) of the machine that you are trying to contact. Remember that the keys are stored in a file within your home directory.

Securly Copying Files with SCP

Scp allows you to copy files between coputers.

To copy the file ~/foo.txt on mimi to the directory you are in on your local computer:

scp ./

To copy the file foo.txt in the directory you are in on your local computer to your home folder on mimi:

scp foo.txt

Arguments of note:

  • Recursively copy entire directories: scp -r
  • Verbose mode: scp -v
  • Compression enable: scp -C

Webservers edit

The SOCS Webserver runs on Linux. Compilation of code for running on the webserver (Perl, Python, Java, etc.) needs to be done on or on a close enough version of Debian or Ubuntu.

The McGill Computer Science webserver runs Apache. Apache is the most popular webserver on the Internet since April 1996; it runs the majority of the world's websites.

For more information about the Apache HTTP Server, go to

Creating a Personal Webpage

NOTE: Only students in computer science are able to create personal webpages. If you do not have a McGill Computer Science account, you will not be able to create a personal webpage.

This is a recipe-type set of instructions that make next to no assumptions about where you currently are in your home directory. You can literally copy/paste these commands (pretty much everything in red) at the prompt, but SOCS is not responsible for the outcome of your actions.

  • The zeroth step is to open a shell session. To do this, either log into a Unix workstation, or use ssh to open a remote shell session on a computer server.
  • The first step is to give the home directory the proper permissions, then to create ~/public_html and give it the proper permissions.
[ubuntu] [~] chmod 711 ~
[ubuntu] [~] mkdir ~/public_html
[ubuntu] [~] chmod 711 ~/public_html
  • The second step is to create a simple webpage containing a bit of HTML. This initial webpage (necessarily) named index.html will allow you to access your webpage via url of the form where username is your username at SOCS.
[ubuntu] [~] cat > ~/public_html/index.html

<title> template webpage </title>
<body bgcolor="white" text="black">
Hello World!
</body> </html>
  • The third step is to give ~/public_html/index.html the appropriate permissions.
[ubuntu] [~] chmod 644 ~/public_html/index.html
  • At this point, everything should be in place, and you should be able to access the page by going to where username is your username at SOCS.

CGI via suEXEC

Because suEXEC is installed on our Apache webserver, all CGI programs are run under the UID of the program owner. Normally a CGI program would run as the same user who is running the webserver; however this is no longer the case.

The benefit, and direct result of suEXEC is that CGI programs are no longer required to be world readable and executable. CGI programs can be readable and executable only by the owner. This means that if your CGI program writes to a file, that file no longer has to be world writable. Likewise, all directories should have the mode 711, regardless of whether a CGI program within that directory writes to files or not.

suEXEC has a great security advantage, but it comes with a minimal downside: less open file mode requirements result in a false sense of security since removing permissions from 'group' and 'others' normally means that only the owner can read, write, or execute a given CGI program; however since suEXEC is installed programs with mode 700 will still be executed by the webserver.

In general, CGI programs can be changed to mode 700 (from 755), and writable files can be changed to mode 600 (from 666). Directories can be changed to mode 711 in all cases. All executables must be placed in the cgi-bin directory of your public_html folder.

For more information about the Apache suEXEC support, go to

.htaccess Files


.htaccess files are a way to make configuration changes to specific directories on a website. You place configuration directives inside your .htaccess file, and the .htaccess file inside a directory, to apply those directives to that directory and its subdirectories. Because students at McGill do not have access to the main server configuration file, using a .htaccess file is the only way to do many things, like password protecting a file or directory.

Password Protect Tutorial

To use .htaccess files to password protect a file or directory on you website, follow these steps:

1. Create a .htpasswd file and place it ABOVE your public html folder - somewhere not visible from your website. To do this, navigate to your public_html folder, and run the "print working directory" command pwd to display the path:

[nfland1][lab2-35][~]  pwd 

Now that you're sure you're in your public_html directory, move up one directory and run pwd again:

[nfland1][lab2-35][~]  cd .. 
[nfland1][lab2-35][~]  pwd 

This means that you want to place the .htpasswd file in this directory, as it is the directory just above your public_html folder.

To create the .htpasswd file, run:

[nfland1][lab2-35][~]  htpasswd -c ~/.htpasswd username

where username is the username for the user who you want to be able to access the password protected files.

You will be prompted to create a password, type one in and then hit enter. You will be prompted to confirm it.

New Password:
Re-type new password:

The last line is the username you chose and the encrypted password.

2. Create a .htaccess file and place it inside the directory that you wish to protect. If the you want to protect a directory /home/2010/nfland1/public_html/downloads, place the .htaccess file in this folder. Copy and paste the following into the file:

AuthName "Restricted Area"
AuthType Basic
AuthUserFile /home/2010/nfland1/.htpasswd
AuthGroupFile /dev/null
require valid-user

The path following "AuthUserFile" should be the path where you created the .htpasswd file above, in this example, it is /home/2010/nfland1/.

3. Test to make sure your website prompts for a username and password when trying to access the directory.


.htaccess and .htpasswd will be hidden files, so make sure you have "Show Hidden Files" turned on. To enable this on Ubuntu, click on "View" at the top of the folder and make sure "Show Hidden Files" is checked.

To create .htaccess and .htpasswd files on Windows, open the file in Notepad, choose "Save as..." and select "All types (*.*)" next to file type. Now name the file ".htaccess" and click save.

For more information:


This information comes from the Wikipedia page for Java applets.

The first step is to create a Java applet - here's an example that will display "Hello, World!". Create a file named and place it inside your public_html directory. Open it and paste in the following:

import java.applet.Applet;
import java.awt.*;
public class TestApplet extends Applet {
  public void init() { }
  public void stop() { }
   // Print a message on the screen (x=20, y=10).
  public void paint(Graphics g) {
    g.drawString("Hello, world!", 20,10);

Save and compile this at the command prompt from within your public_html directory:

[nfland1][lab2-35][~] javac

Now, edit the webpage you want to have this applet to include:

<APPLET code="TestApplet.class" WIDTH="200" HEIGHT="40">
This is where TestApplet.class runs.</APPLET>

This will run the TestApplet java applet on your webpage.

The Java Boutique has some Java applets to download and try out.


Perl is an interpreted programming language optimized for scanning arbitrary text files, extracting information from those text files, and printing reports based on that information. Perl's regular expression engine is in a class of its own, capable of things most languages can't even mimic. Those fluent in Perl can use its idioms to produce tiny and elegant code with minimal verbosity.

Perl has packages, modules, objects, unicode support, interprocess communication support, threads, and about a million other things. With Perl, you can have your cake and eat it too.

For a Perl script to be interpreted by our webserver, it must have the suffix .cgi.

Check what Perl modules are currently installed on the SOCS webserver.


This describes how to get a basic cgi/perl script running. This is a recipe-type set of instructions that make next to no assumptions about what you currently have in your home directory. You can literally copy/paste these commands (pretty much everything in red) at the command prompt, but SOCS is not responsible for the outcome of your actions. Please download the files (mentioned below), rather then attempting create them via copy/paste.

  • The first step is to create ~/public_html and give things the proper permissions. If you already have a public_html directory from creating a personal webpage as shown above, you can skip the second line (mkdir ~/public_html).
[nfland1][lab2-35][~] chmod 711 ~
[nfland1][lab2-35][~] mkdir ~/public_html
[nfland1][lab2-35][~] chmod 711 ~/public_html
  • The second step is to create a simple webpage containing a form that will post variables to a Perl script (which we will write later). The bold green portion below is just to emphasize the form portion of the web page, and to bring your attention to action and method (this is how we will call our Perl script). The second bold green portion shows where the input variable is defined (it is called user... so look for it in the Perl script).

    The text editor called pico can be used to enter the text below into a file called test.html (in your public_html directory). You can use any editor you are comfortable with (many people enjoy xemacs because of its ease of use). For the purpose of this example, rather then typing in all the green text below, you can simply download the file test.html into your public_html directory by right-clicking on the link and selecting Save Link As.... Alternatively, you could left-click on the link, and then right-click on the page that loads, and choose View Page Source, and copy/paste the source into a file called test.html in your public_html directory.
[nfland1][lab2-35][~] pico ~/public_html/test.html
<body bgcolor="white" text="black">
<form action="./cgi-bin/" method="post">
<table width="450" cellpadding="3" cellspacing="2" border="0">
   <td valign="middle" align="left" bgcolor="#706090">
     <font color="white" size="2">Your name:</font>
   <td valign="middle" align="left" bgcolor="#706090">
     <font color="white" size="2">
     <input type="text" name="user" value="Bono" size="30" maxlength="30">
 <font color="blue"><input type="submit" name="submit" value="OK"></font>
  • The third step is to give ~/public_html/test.html the appropriate permissions.
[nfland1][lab2-35][~] chmod 644 ~/public_html/test.html
  • The fourth step is to create ~/public_html/cgi-bin (the place where we put our perl scripts), and give that proper permissions.
[nfland1][lab2-35][~] mkdir ~/public_html/cgi-bin
[nfland1][lab2-35][~] chmod 711 ~/public_html/cgi-bin
  • The fifth step is to create a simple CGI/Perl script that will grab the variable user which we created in the webpage above.

    Note that we need to pull in declarations and definitions for cgi, so we do that by adding the line: use CGI;

    Secondly, we also need to create a new query object (in order to parse the input gained by either the POST or GET method of the calling html page), so we do that by adding a line similar to: $q = new CGI;

    Finally, we have to fetch each value passed, by doing something like the following, for each named parameter: $username = $q->param( 'user' );

    As above, the code below can be typed into a file using the text editor called pico. You can use any editor you are comfortable with. For the purpose of this example, rather then typing in all the green text below, you can simply download the file test.perl into your public_html/cgi-bin/ directory by right-clicking on the link and selecting Save Link As.... However, if you choose to download the file, you will have to save it as in your public_html/cgi-bin/ directory, or you will have to rename it to before continuing with the next step (if you download it as test.perl). Alternatively, you can left-click on the link and copy/paste the content of test.perl into a file called in your public_html/cgi-bin/ directory.
[nfland1][lab2-35][~] pico ~/public_html/cgi-bin/
use CGI;
my $q = new CGI;
my $theuser = $q->param( 'user' );
$theuser = '' unless $theuser;
print "Content-Type: text/html\n\n";
print "<html>\n";
print "<head>\n";
print "<title>CGI/Perl Test </title>\n";
print "</head>\n\n";
print "<body>\n\n";
print "Hello, world!<br><br>\n";
print "Your name: $theuser<br><br>\n";
my $date = `/bin/date`;
chomp( $date );
print "date: $date<br>\n\n";
print "</body>\n";
print "</html>\n";
  • The sixth step is to give ~/public_html/cgi-bin/ the appropriate permissions. The reason why it's OK to give so few permissions (700), is because our webserver is running suEXEC. If it weren't, then the permissions would need to be 755.
[nfland1][lab2-35][~] chmod 700 ~/public_html/cgi-bin/
  • At this point, everything should be in place, and you should be able to test the page and script by going to where username is your username. When you get there, just click OK. You will be forwarded to another page (generated by the Perl script).


If you want to see errors (from within McGill) on the web server associated with your username, click HERE.

For more information on CGI/Perl, do `perldoc CGI`.

If you're looking for reliable pre-made CGI scripts, you should check out nms:


For a beginner's tutorial of using Python on your website visit Python's HOWTO Use Python in the Web.

Python is an interpreted, object-oriented programming language. It is capable of many things beyond web scripting, including GUI implementation.

For a Python script to be interpreted by our webserver, it must have the suffix .py.

Here's an example python script to display "Hello World!" on the page. Create a new file called and paste the following inside:

#!/usr/bin/env python
# -*- coding: UTF-8 -*-
print "Content-Type: text/plain;charset=utf-8"
print "Hello World!"

Remember to place this executable .py file inside the cgi-bin directory and give it the appropriate permissions as outlined above in the "CGI via suEXEC" section.

For more information about Python, go to


For a great tutorial about making PHP-enabled web pages, visit the PHP tutorial page.

PHP is an interpreted, server-side, HTML embedded scripting language, somewhat based on Perl, and C. PHP makes dynamic webpages possible becasue its code can be embedded within HTML. To differentiate between PHP and HTML context, PHP's code must be enclosed by special start and end tags that mark the start and end of PHP blocks.

For a PHP file to be interpreted by our webserver, it must have the suffix .php. For info about PHP on our webserver, click here.

To see how PHP works, put the following in a file called testphp.php and place this in your public_html directory:

   <title>PHP TEST</title>
  <?php echo '<p>Hello, World!</p>'; ?>

Navigate to to see your page.

For more information about PHP, go to


For a tutorial on how to use SSI on your webpage visit the apache page for SSI and scroll down to "Basic SSI Directives".

Server Side Includes (SSI) are directives placed within HTML webpages to generate some dynamic side-effects to otherwise static HTML webpages.

SSIs are evaluated on the server at the same time as the webpage, are capable of things such as:

  • obtaining the current date and time
  • obtaining the modification date of the file being evaluated
  • including a file, for example a standard header or footer
  • setting variables
  • evaluating conditional expressions: if/elif/else

For the sake of added security, the exec feature of SSI has been intentionally turned off.

There are two ways of using SSI in webpages.

  • The first way is to place the directives into a file having a .html extention, and turning on that file's "execute" bit.
  • The second way is to place the directives into a file having a .shtml extention, and turning on just the "read" bit.

Notice the s in the latter case, and the absence of it in the former.

If you've already got a lot of pages and links between them, it is probably easier to just turn on the execute bit for the pages rather than going back and renaming all of them to .shtml.

An example of SSI that you could place on your webpage to give the current date:

<!--#config timefmt="%A %B %d, %Y" -->
 Today is <!--#echo var="DATE_LOCAL" -->

This would print the date on a page that had been properly configured to display SSIs.


Almost Free Text (AFT), is a mostly free form document preparation system, which means that you can write documents, lists, notes, etc., with "little intrusive markup".

AFT has a few rules for formatting a document; unlike HTML which embeds tags within the data, there is next to no such polution in AFT documents. This means that AFT documents appear clean and similar, before and after processing (through an aft2html translator).

For an AFT file to be interpreted by our webserver, it must have the suffix .aft.

For more information about AFT, go to, or check out the manual at

Nice/Renice edit

  • If you expect your process to be a CPU hog, before running it, you can specify a "nice" value with the command "nice".
  • If your process is already running, and is a CPU hog (ie. it uses a considerable amount of CPU time), you should "renice" your process with the command "renice".
  • The default "nice" value is 0 (zero). A user may only increase the nice value - never decrease it. The maximum nice value is 19 (or 20, on some systems). The greater the nice value, the nicer you are to other users of the system (because your process has lower priority).
  • The concept can be compared to waiting in a queue at a store. If you have a big load of groceries, and someone behind you only has two or three items, you might decide to be nice and let them go ahead of you.
  • If you don't nice (or renice) heavy processes, and the system staff notice, your processes will most likely be reniced to 19 - the most nice, and least priority (ie. your process will run only when the CPU has nothing else to do). Therefore, it is better to be proactive by setting the nice value yourself, to say, 10. But that is just a suggestion... you are free to experiment.
  • Take note of the priority number as you change the nice value. Use the command "top" to monitor your process and watch its NICE and PRIORITY values change, as you use "nice" or "renice". If you notice that one of your processes is running excessively long without dying, you should terminate it yourself, by sending it an appropriate signal with the "kill" command.

FTP edit

Method 1

The first method is optimal: (drag & drop).

You can download the Educational Windows Version of ssh below. For details please see the LICENSE.


Do the installation. SFtp to or any other lab machine.

Method 2

The second method involves onetime passwords.

The basic idea is that you must generate some "onetime passwords". Each time you log into you will use one of those passwords. When you run out of onetime passwords, you can generate more of them. For more information about this mechanism read skey(1) by doing `man skey`.

If you have trouble (ie. you get a message such as "No manual entry for skey") reading the man page, do `unset MANPATH`.

The procedure for getting onetime passwords is simple and involves only two commands, namely keyinit(1) and key(1).

  • The first step is to log onto the ftp server. To do this, we MUST use ssh(1). You can use ssh from any lab machine or compute server at SOCS.
 [abatko][fiat][~] {1} ssh
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)? yes
Host '' added to the list of known hosts.'s password:
Last login: Fri Oct  6 13:24:17 2000 from electrod.cs.mcgi
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
        The Regents of the University of California.  All rights reserved.
FreeBSD 4.1.1-RELEASE (GENERIC) #0: Tue Sep 26 00:46:59 GMT 2000
Authorized use only.
If you are here to setup one time passwords then
man skey
in particular, keyinit and key are the programs you
are intertested in.
This machine is in a beta state right now, please report any problems
that you have to
Welcome to FreeBSD!
  • The second step is to generate an initial key, thus we use the command keyinit(1). WARNING When setting up your onetime passwords you MUST use ssh(1).
 [abatko][wase][~] {1} keyinit
Adding abatko:
Reminder - Only use this method if you are directly connected.
If you are using telnet or rlogin exit with no password and use keyinit -s.
Enter secret password:
Again secret password:
ID abatko s/key is 99 wa72014
  • The third step is to generate several onetime passwords. We do this using key(1) whose synopsis is key [-n count] [/]

    The option -n count is used to generate a particular number of passwords. So to generate say, 3 passwords do -n 3. The mandatory parameters sequence # and key we just copy over from the output of keyinit(1) (the first blue part above). Thus according to our running example, the sequence # and key are 99 wa72014. If you enter the secret password correctly, the last onetime password (99 in this case) will be the same as the one given to you by keyinit(1). If you look above, you will note the (blue) line "BAND LARY ADAM THE EDGE BONO"; it's the same as the last one below. If it was different, then I would have to do key(1) again and try typing the secret password correctly this time.
 [abatko][wase][~] {2} key -n 3 99 wa72015
Reminder - Do not use this program while logged in via telnet or rlogin.
Enter secret password:
  • Now exit the ftp server (wase) by doing exit.
 [abatko][wase][~] {3} exit
Connection to ftp closed.
  • Finally, let's ftp into Note that now we'll be using our onetime password(s) to log in. The Onetime Password system (S/key) will prompt us for a password. It asks us for a specific by giving the number of the password it wants. Below, you'll note that it's asking for s/key 98 so that's the one I would type in. So from our running example, it would be "MUDD TAGS CASE YOU TWO CALL". IMPORTANT In order for you to be able to log in now, your home directory must have mode atleast 711. So do chmod 711 ~ to change your home directory's mode to 711.
 [abatko][fiat][~] {2} ftp
Connected to
220 wase.CS.McGill.CA FTP server (Version 6.00LS) ready.
Name (
331 s/key 98 wa72015 (s/key required)
230 User abatko logged in, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> exit
221 Goodbye.
  • Ok, let's do it one more time. Note that this time it will ask us for the next lower numbered password, namely s/key 97. So from our running example, it would be "SILT CAW TWIN FUN MOOD SHE".
 [abatko][fiat][~] {3} ftp
Connected to
220 wase.CS.McGill.CA FTP server (Version 6.00LS) ready.
Name (
331 s/key 97 wa72015 (s/key required)
230 User abatko logged in, access restrictions apply.
Remote system type is UNIX.
Using binary mode to transfer files.
ftp> exit
221 Goodbye.
  • Ok, now we've run out of passwords, so we'll have to generate some more by continuing from where we left off. For instance, in the running example, we would do `key -n 10 97 wa72015` to generate 10 more onetime passwords. Make sure that the newly generated password with highest number (97 in this case) is the same one you most recently used (which was 97).

    Once again, if you forgot your passphrase, you have to start all over with keyinit(1) and key(1).

Daily Backups edit

Our file server does nightly backups of your home directories. Those who need a file restored need simply send a request to

We EXCLUDE the following files and directories: (please check this monthly as it is subject to change)

exclude Cache/
exclude Caches/
exclude Dropbox/
exclude Movies/
exclude Music/
exclude My?Music/
exclude My?Videos/
exclude NOBACKUP/
exclude Pictures/
exclude Trash/
exclude Trashes/
exclude temp/
exclude .gvfs-metadata/
exclude .Trash/
exclude .Trashes/
exclude .trash/
exclude .dropbox/
exclude .nfs*
exclude urlclassifier3.sqlite
exclude /~*
exclude *.tmp
exclude *.wmv
exclude *.rpm
exclude *.deb
exclude *.avi
exclude *.mpg
exclude *.mp3
exclude *.m4a
exclude *.iso
exclude core
exclude .DS_Store

Backups for MCB laptop users

To backup your laptop please follow the following steps.

  • Confirm with systems staff that you have a /home/mcb/user directory.
  • Create a ssh key on your laptop (you can choose whether to have a passphrase or not)
ssh-keygen -t rsa
  • Add the newly generated key to your authorized_keys file on (or any other cs machine)
scp ~/.ssh/
cd .ssh
cat >> authorized_keys
  • Create your LAPTOP-BACKUP directory
  • Decide which directory tree you would like to backup, or create a new one for backup purposes
mkdir ~/Research
  • Craft a rsync backup script
# backup contents of ~/Research to /home/mcb/username/LAPTOP-BACKUP
rsync -a --delete-after ~/Research/

Computing Resources edit

CS staff and students have a variety of computing resources available to them. We have desktop workstations and servers running various operating systems. We use a centeralized storage system (NFS) so every user's files are available on any computer they log in to.


Publicay available workstations are on the third floor of the Trottier building. These run Ubuntu Linux with a fully graphical desktop.

These workstations are also available to all McGill students. Non-CS students can log in to a temporary workspace using their normal McGill email username and password.

Hostname Type OS CPU Memory Disk Space
CS-1 - CS-32 Dell Tower Ubuntu LTS Intel i7 (x4) 8GB 450GB


There are several servers available via SSH:

Hostname OS CPU Memory Disk Space
linux Debian Linux Virtual (x4) 3GB  
teaching / mimi / ubunutu Ubuntu Linux Intel Xeon (x3) 6GB 12GB
freebsd FreeBSD Virtual 3GB  

Local Storage

On non-virtualized machines (workstations/teaching) there is a partition of the hard drive mounted at /diskless. This data lives on the local drive and will not be deleted under normal circumstances, but may be deleted at any time for system maintenance. Feel free to use this storage for files that are too large for your home directory (such as databases) but note that this is public storage so anyone will have access to your data. You will notice a performance improvement when compared to your home folder as the data does not need to be sent over the network when you want to use it. This data is only available on the specific machine you are using.