The people who wrote this document are perfect. There are no typos, there are no spelling errors, there are no grammatical errors, and the information herein is neither false nor out of date. If you really and truly believe this, stop reading now, because obviously you live in a perfect world and this guide cannot help you. If you are still reading, realize that the entirety of this project was structured and written from scratch in the span of less than a month. It is within the realm of possibility that errors exist.
Note: The online version of the guide is located at http://www.cs.mcgill.ca/~guide and is sporadically updated. You can find out the latest changes at http://www.cs.mcgill.ca/~guide/credits/changes.html.
Should you have some feedback or constructive criticism to share with us, a feedback form is in place at http://www.cs.mcgill.ca/~guide/feedback for this exact purpose.
|Requires some foreknowledge of and/or familiarity with Unix to understand.|
|Advanced topics covered.|
|A recent change or new addition to the way things work at SOCS. Likely to be especially important for returning students.|
This handout is intended as an introduction to the School's computer system, and a pointer to other more detailed sources of information. In particular, see SOCS Inside-Out at http://www.cs.mcgill.ca/~guide ("the Guide"). This pamphlet forms section 1 of the Guide, a student initiative to ease the learning curve of newcomers to SOCS. More information on the project is available on the website.
For those reading a printed version of this document: note that we don't generally bother to provide URLs (references to other resources) here as we assume that if you can get to a browser, you can get to this page as well and thereby reach your desired destination.
If you're not already a technogeek you may want to browse the glossary first to make sure you're familiar with the jargon we use.
Your Unix account gives you, at a minimum:
Anyone taking a computer science course at McGill is eligible for a Unix account with SOCS, though not all accounts grant access to all machines. To create your account(s), go to the web page http://newuser.cs.mcgill.ca/newuser. This page should only be accessible from a machine directly connected to McGill's network (i.e.: a computer located on campus or in a residence or connected via DAS). This will enable you to create a Unix account. In addition, a Windows account will be created if you are eligible for it. See Appendix C to find out which labs you have access to.
If you don't have access to a computer at McGill, log on to one of the PCs in one of McConnell 103N, 105N, or 106N, using the username newuser and the password newuser. That will bring you to the web page automatically. During the first couple of weeks of the term there is usually a machine or two dedicated to this so you shouldn't have to wait.
Please note that your account will be created only if you are listed in the local course database. This means that you probably won't be able to create your account on the first day of classes. If you registered late, you may not even be able to create your account in the first week. If you need to use your account before the course information is ready, or if you have problems creating your account, come by the Help Desk and they'll usually do things manually via MARS.
After identifying yourself to the newuser program, you will be asked to select a password. Your username for the SOCS systems will be identical to your DAS username; together with your password, this allows you to login (i.e., access) your account. Note that your login name is also your email address on the SOCS systems if if you stick it before "@cs.mcgill.ca", e.g. firstname.lastname@example.org is the email address of the user "zsimms".
Some points to note on creating your account:
If you've already created an account and are reading this to make sure you haven't missed anything, check out the Code Of Conduct on the web. In addition, note the following rules account-holders must follow which are specific to our systems:
Your home directory contains virtually all of your files, excepting possibly some email and/or shared files.
The permissions on your home directory are very significant. There's no space here to go into all the details of permissions and their ramifications, but see permissions and chmod in the Guide.
You should note that the permissions mode 711, which is the default setting, was carefully chosen. If you change it, make sure that you understand what you're doing and why. Normally it's set to one of three values, which are detailed in the appendix entry on home directory permissions in Appendix C - Account Specifics.
Some of the information relating to your account is not stored in a file where you can view it, but must be retrieved (and possibly set) by running a particular command. Here are some of the most important settings.
Note that unless otherwise specified, you should be logged in to a server (such as nova) rather than just a workstation when issuing these commands.
The undergraduate labs are at the north end of the 1st floor (that is, one above the ground floor) of the McConnell Engineering Building. The north end is the one closest to the Milton Gates on University, furthest from Sherbrooke St. The labs are comprised of:
The Unix labs are accessible 24 hours a day to students currently enrolled in CS courses. (The doors to McConnell are locked nights and weekends, but you can still get in by the passageway from the Frank Dawson Adams Building, two buildings south.) Eating, drinking, and smoking are forbidden, and the noise level should be kept low. Group work is discouraged and should be confined to the lounge as much as possible. These and other rules are posted on the walls of the labs in bold type.
During weekdays and on Saturdays a consultant is usually on duty handling questions in 104N. You can find a schedule for consultant availability at http://www.cs.mcgill.ca/~consult.
The content of the labs is described in Appendix E - Computer Facilities.
Lab Rules & Etiquette
The basic rules posted in the labs largely amount to behaving responsibly and are not repeated here. However, two of the rules need to be emphasized. The no food or drink rule may be inconvenient but it's important, because keyboards are notoriously sensitive to spills, and McGill has a rodent problem. Anyway system staff have been merciless about enforcing it lately, with at least four public beheadings last year, so don't break it.
There is also the issue of excessive noise. Hanging around chatting with fellow geeks is good fun and encouraged - but not in the labs while people are trying to work. You'll see what this is like sometime when you're trying to debug assembler while the chumps across from you loudly exchange Emacs jokes. Take it to the lounge or elsewhere. Conversely, if someone is preventing you from getting work done, don't be shy about politely asking them to hush, or just get the consultant to do it.
You'll notice that the ratio of lab machines to students isn't quite 1:1. The consequence is that sometimes there's a lineup to get a machine. If someone else is standing there waiting you might ask yourself, is it really decent of you to start up that umpteenth game of Nethack? How much fairer - nay, nobler - to chivalrously give up your seat, thereby winning the admiration and respect of your peers, not to mention the eternal gratitude of some poor sap who desperately needs to print out an assignment.
Asking the stranger sitting next to you for help is fine, within reason. In general you should try the consultant and online references like the Guide before you interrupt someone, but there should be enough camaraderie in the lab that you can check something simple without getting out of your seat. Of course you should ask the guy slouched in his chair lazily sliding his mouse back and forth before the girl hunched over her keyboard typing furiously with sweat pouring down her face.
Then there's the One Holy Law of lab etiquette: never look over someone's shoulder uninvited. (With the unwritten qualification, "...or at least don't get caught doing so.") The labs aren't designed for personal business, but we might as well try to respect each other's privacy as much as we can.
Connecting From Home
|mail (outgoing)||SMTP||ISP's mailhost/mailhost.cs.mcgill.ca*|
|popmail (fetching)||POP, IMAP||po-box.cs.mcgill.ca|
We lack the space here to explain each access method, although some are touched on here and in the Guide. We present them here mainly to inform you of what's available and to document which methods are insecure. See the Security section for details on why, and the Guide or online help for details on using and obtaining these programs/services.
First, the restrictions: The servers allow connections from anywhere by slogin/ssh. Insecure connection methods are not supported.
Here are the supported access methods:
|Access Type||Secure||Available On|
|file transfer||scp/ssh, slogin-wrapped ftp||all|
|mail access||SSL+IMAP/POP, CRAM-MD5 *||Solaris, soon Linux*|
If you need some pointers on where to pick up ssh clients for Windows, please check out The Socs Guide to Using SSH (http://www-cnoc.cs.mcgill.ca/info/ssh.html#IMPLEMENTATIONS).
There's a lot to be said on this topic. We won't attempt to tackle the whole thing, though a half-serious one is made in the Guide. Most people manage just fine without outside help just by starting up Pine or Netscape, the most user-friendly (and therefore brain-dead) of mailreaders.
Here are some references to get you going and some things you should know about as a user of email on our system.
Inboxes are stored on a server which is not accessible to logins, so your mailreader must understand POP or IMAP. The currently installed mailreaders which do are Netscape Mail, Pine, and mutt. If your favourite mailreader is not one of those, it is still possible to use it: `fetchmail' can download mail for you via POP or IMAP. We do not encourage the use of fetchmail unless you know what you are doing, as it is possible to screw up badly and lose mail.
For more details see http://www.cs.mcgill.ca/socsinfo/mail/.
News is usually a means of procrastinating rather than a useful resource. We mention it here mainly because some announcements are made to local newsgroups and nowhere else, so it behooves you to follow them. Moreover, all CS courses have newsgroups in which people can ask questions and discuss course-related topics. The T.A.s and prof may themselves contribute.
Newsgroups you really should follow:
Newsreaders installed include tin, trn, and such all-in-one readers as Netscape and Pine. The last two are available just about everywhere. The others are available on most machines; it's pointless for us to say which as that is subject to change.
Note that you can always compile your own news client if you don't like these. For example, if you find yourself becoming a slave to the habit, SLRN is a good heavy-duty newsreader that is not currently installed on SOCS machines.
If you're new to Usenet it's advised that you lurk around for a while without posting yourself until you get the feel for what's accepted in the newsgroups you're interested in. Some posts will almost always be frowned upon: "me too"-type posts and spam are particularly despised.
FTP is almost as transparent to use as a browser, so we won't describe it here - see the Guide if you're desperate. Actually, browsers can generally access anonymous FTP sites as easily as the actual ftp program can (just open ftp://ftpservername/pathname). In fact, many even provide a way to specify usernames and passwords for non-anonymous access. In Netscape, you can use ftp://username:password@ftpservername/pathname.
FTP is not recommended for copying your own files from one computer to another due to its inherent security flaws. (See password sniffing and the above Remote Access Methods subsection for an explanation and alternatives.) Note also that FTP will soon only be active on the FTP server (ftp.cs.mcgill.ca) - the port will be closed on other machines.
Given the existence of alternatives, you can choose to remain completely ignorant of FTP without missing out on anything.
The World Wide Web
We have the following browsers available.
Netscape is what virtually everyone uses. It is available under Windows, on the Macs, and under FreeBSD, and how to start it should be evident on all but the latter. For FreeBSD, if you're using the fvwm window manager (the default), there should be an icon on your screen you can click on to start the latest version. Alternatively you can invoke it from the command line as `communicator'.
Note that Netscape is known to have bugs, leading it to crash sometimes, or stick around sucking up memory and CPU cycles when you log out. If you see someone else's Netscape process running when they're not logged in, odds are this is why. Please tell the consultant on duty or system staff rather than rebooting the machine; that way the problem may eventually be fixed.
Like every other user, you will want to keep your account secure. Even if there isn't a single file or email you want to keep private, someone who breaks into your account can do all kinds of things in your name. Or, they can try to damage our system or others from your compromised account, which can result in the system being unavailable at the most inoppurtune of times.
Here are some precautions you can take to protect your account from intruders. While some of these may seem obvious, they certainly aren't to everyone. More details are provided in the appendix articles on secure connections and password cracking.
Please note that whenever we refer to logging in, we mean any attempt to authenticate yourself as being the owner of your account, whether it's to transfer files, download mail, or simply login. See also the section on home directories and permissions above and in the Guide.
Probably the biggest weakness in modern computer networks, including the Internet, is a legacy from the past. While it was once acceptable for passwords to be sent unmodified from one host to another (sometimes called "cleartext"), nowadays this is somewhat of an invitation to hackers, akin to leaving your door unlocked. This is because of the way ethernet (the most common LAN protocol in use today) works: it is possible for all machines connected to the same subnetwork to see any traffic involving any one of them. This is usually referred to as "packet sniffing".
While the average Unix user can't do this, root (the superuser) can. This means that if a someone can break into the root account of a single machine they can gather many passwords, possibly on dozens of other machines. Our world being less than perfect, this inevitably happens every so often, and is usually terribly inconvenient both for staff and for the users whose passwords are sniffed. As a result, system staff is trying to eliminate this as a vulnerability in our system.
Until they do, you should protect yourself. There are two ways to keep your password to yourself. Either don't use it, or use an encrypted login program. Instructions on both alternatives are provided in the appendix under secure connections.
The end result of being forced to use hard passwords is often that one ends up writing them down. This isn't too big a deal - system staff pretty much have no choice, since they often have a dozen or more different system passwords to keep track of in addition to their own passwords.
However, you should bear in mind that there's no point in having a good password if someone else has access to it. Some basic tips:
This is too big a topic to squeeze in here - see the Guide or http://ptolemy.eecs.berkeley.edu/~cxh/sapub/Xsecurity.html. We thought it should be noted for those that aren't aware of it yet that X can be very insecure. If you use `xhost', be aware that any users logged in to any machine in your xhosts list have the capacity to do all kinds of nasty things to your session. It's quite possible to intercept your keystrokes and see everything you type or that is displayed on the screen - using slogin won't help you if you've run xhost, as the keys you type can be intercepted before slogin gets to see them.
Don't lose track of the obvious in the attempt to protect your password from all manners of devious attacks. If you're sitting in the lab and leave your machine alone without locking the screen, any number of Trojan horses can be planted which will divulge your password (among other things) to an unscrupulous lab user. Or they could just copy your mail files, etc. The only way to avoid these risks is to become at least a little bit paranoid about protecting your account.
A longer glossary is available in the online Guide. For more definitions, and oodles of geek-culture in-jokes, you can also consult the Jargon File at http://www.tuxedo.org/~esr/jargon.
root also refers to the the top-most directory (symbolically referred to as '/') in a filesystem. It should be clear from the context which meaning of root is intended.
We use the term "Unix" (plural: Unices) to mean "UNIX or UNIX-like
operating system" since there now exist many variations on the original
UNIX. At SOCS, you may encounter these Unices: SunOS, Solaris,
Irix, AIX, and Mach. Even Windows NT has Unix at its core (supposedly
employing a Mach microkernel), but it is sufficiently removed from this
origin to not warrant inclusion on this list. The upcoming
Macintosh OS X uses a Mach kernel.
see also: Linux
This is because (1) this pamphlet is already too long, (2) we can update the web page but can't edit a printed handout, and (3) if you can't get onto the web even after reading through this whole pamphlet, any other resources we give you are unlikely to be much help. You should see the Help Desk if you can't log in, and if you can log in but can't figure out how to load a web page... maybe CS isn't the program for you?
(We were also tempted, not to mention urged by one particularly crusty old Unix geezer, to keep this entire guide down to two words: `man man'. But we just gave his rocking chair a push and he piped down.)
The departmental office is in room 318. This is where you can find information concerning courses or programs of study, or drop off a note in a professor's box. The 3rd floor is also where most of the professors' offices can be found, though several of them have recently migrated to the 1st and 2nd floors as well.
Undergraduate Computer Labs
Located in 103N, 105N, and 106N. See the Connecting section for details.
In the hallway of the labs, you will find a towering array of clear-plastic enclosed boxes. These are to be used for assignment submission; your instructor will provide you with further details.
The system staff and the computing servers are on the second floor, directly above the labs. Problems setting up new accounts, paying for printouts, and other in-person questions may be directed to the help desk in 209N, which is (officially) open on weekdays from 10am-4pm. Questions to system staff and problem reports should be directed to email@example.com, or to extension 7087. They have a web page at http://www-cnoc.cs.mcgill.ca, but it is usually out of date.
NB: outside the hall leading to the Help Desk you will notice a door with a sign on it, saying, "This door swings open at random intervals. Do not sit, stand, study or sleep near it! You have been warned." Take a few moments to burn these words of wisdom indelibly into your skull. Too many promising young students have already been lost.
The CSUS lounge is available to students for group work, play, or what have you. At some point there will be working computers here.
ACM Office (227)
Details about upcoming ACM events are usually posted outside the office, and ACM registration forms are available from within. See the Guide for more info on the ACM.
Users of our system can be classified into several types. The major ones are ugrad, grad, prof, staff, and course accounts (e.g. cs202). There are also CS accounts for non-CS people, which are restricted to particular machines. These include mcgill accounts (non-CS students or staff who are renting access and disk space from us), and guest accounts. alumni accounts are available to CS graduates who want to retain their accounts. To rent an alumni or mcgill account, go to the Help Desk or the Computing Centre, respectively.
|Account Type||Access restrictions||
Disk space allocated (MB)
|nt||Windows machines||10/10||cs102, cs202, cs203, cs250|
|alumni||compute servers only||5/10||$30/3 months|
|mcgill||compute servers only||5/10||$50/6 months|
** 20 once user takes a CS course # > 300
Your account exists in one of many states: created, active, expired, closed, locked, and archived. There is a progression: created accounts exist or may exist but have never been used, whereas a normal user account is active. When the account is no longer allocated, it will be expired (which sends mail to the account owner informing them) and eventually closed. Accounts may also be closed for security reasons or the like. If staff decides that the account may be closed for a while, it will be locked. Finally, if disk space is needed (or if it looks like you're really not coming back) your account may be archived.
At this point at least a year will have passed since the account was expired, so if an archived account is later reopened, the account owner is usually billed $20 if he or she wants any of the files from the archived account restored.
In principle accounts may be expired at any time after they are no longer needed by the user. In practice it is usually a low priority, so it may take a while before your account is deactivated.
Home Directory Permissions
Each file and directory (Unix makes little distinction between the two) has a set of permissions (or mode bits) associated with it. These control what privileges each user has with respect to that file or directory. This is of particular interest when it comes to the permissions on your home directory.
You can change a file's permissions with the `chmod' command. Without going into too much detail, here are the implications of the most common permission settings on directories, including your home:
Home directories are created mode 711, which implies that other users can access files of yours provided the files themselves are readable. Note that the filename must be known to the other user in advance, as they cannot "read" your directory to see its contents. No one can find out what files you have in your home, just whether a particular file or directory (like public_html or .cshrc or Mail) exists and whether or not they can access it.711 rwx--x--x (world-executable; default)
Alternatively you may want to set the permissions to 700, so that no users can access any files of yours by any means. Note that this means that even if you create a web page it will not be accessible on the web.700 rwx------ (no permissions for anyone else)
Some prefer this setting, which is like the default except that other users can also get directory listings. There's nothing fundamentally wrong with this, you just have to be more careful with the permissions on all the files and directories stored in that directory.755 rwxr-xr-x (world read/executable)
Please see http://www.cs.mcgill.ca/socsinfo/mail/ for details on the new mail server setup and http://www.cs.mcgill.ca/socsinfo/mail/#howtoforwardmail for details on how to get mail forwarding working.
The short story, if you are familiar with Unix, is that you
cannot set up a simple .forward file under the new mail setup. To do
it, you must use the
mailforwardset command (available
only on willy and skinner). The syntax is:
% mailforwardset addr1[,addr2,addr3,...,addrN]...where
addr1,...,addrNis a comma-delimited list of email addresses (no spaces please.) If you want to check what address your mail is forwarded to, the command
mailforward(no arguments) will display this for you. To turn off forwarding, just type
The program to use to establish a secure connection is called `slogin'. Some details on using it is provided in access methods and in the Guide, but you can usually just use it more or less like rlogin. So long as you use slogin your password cannot be sniffed.
An alternative approach is to avoid having to send your password over the network at all. This is done either by (1) not logging in remotely, or (2) authorizing logins to your account based on origin. You can skip to the next subsection now if you've decided to adopt the first solution.
There are two ways to log in remotely without typing a password: .rhosts /.shosts files (host based authentication), and slogin's authorized_keys file. There are hazards involved in either of these mechanisms which we don't have space to go into here; this will eventually be documented in the Guide. For now, just use slogin.
Even if you keep your password from ever being seen by others, your account can still be compromised if the password is easy enough to guess. Under Unix, passwords are stored right in the open, although not in their original form. They're encrypted (for the technically-minded: it's actually a one-way hash) using an algorithm which is impossible to reverse, so the theory was that it was safe to keep the encrypted passwords in the open. When you type your password at a prompt, Unix encrypts it with this same algorithm and compares the result to the stored one; if they match, the password is accepted.
Nowadays it's merely time-consuming to crack passwords by brute force means. A hacker with access to a fast computer can copy our password files and run a "crack" program; this is known as a "dictionary attack". As the name implies, passwords are cracked by encrypting names and dictionary words (with variations, e.g. reversed order, numbers or other symbols added to the start or end, etc.) and seeing if they match any of the passwords in the file.
Note that if your password is short enough or the hacker's machine is fast enough, a dictionary attack isn't the only thing you have to fear: it's quite possible to run through all the possible combinations if you only have a six-letter password and the cracker has some patience and/or a fast machine available. This is why hard-to-type passwords are enforced.
The moral of the story: you shouldn't complain, but instead should be happy that the program is making sure you're not making yourself a target for account theft. And you should use a password with at least 7 characters.
Note that because they are running Unix, the non-Windows workstations will all allow you to log in to them to do work remotely. See lab etiquette for some issues relating to this.
We have several Sun compute servers at our disposal for coursework: nova, skinner, willy, and mimi. These are fast machines which can handle dozens or hundreds of users simultaneously with ease.
In addition, there are a few specialized servers of various pedigrees which you may need to deal with at one time or another, but which are not made generally available.
Each lab has its own printer. See printing balance under Accounts for pricing.
The Windows lab (106N) printer is named hpp. Printing under Windows should be straightforward, depending on which program you're printing from. The printers in the FreeBSD labs are named for the labs that contain them: lp103n and lp105n. Use the Unix `lpr' command to print text or PostScript documents on these printers: e.g., `lpr -Plp105n foo.ps'.
Note that print jobs are queued and printed in order of submission. The `lpq' command displays the current list of queued jobs, and `lprm' will remove a job by ID number.
Your login name appears next to your jobs in the queue listing, so be assured that everyone will know who the idiot is that sent 17 copies of a 1MB postscript file to the printer and is preventing everyone else from printing.
Paper can be obtained from the consultant when necessary. There is a recycling bin under the printer.
A scanner is installed on troy. Operating instructions are displayed before and after logging in to the machine, and therefore aren't repeated here.
In addition to the networked storage which we all have access to (i.e., your home directory and mail folders stored on po-box), there are various other storage mechanisms at your disposal. See removable media in the Guide for further instructions.
Blackboards are mounted in 103N, 105N and 106N, and are public-writable.