LAST UPDATE:

Disclaimer

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.

Feedback

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.

Legend

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.

Welcome to the SOCS computer system

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.

Table of Contents


ACCOUNTS

Introduction

Your Unix account gives you, at a minimum:

These and more are all detailed in the following pages. See Appendix C for details regarding:

Creating

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. zsimms@cs.mcgill.ca is the email address of the user "zsimms".

Some points to note on creating your account:

Rules

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:

labs:
See Lab Rules And Etiquette under the Connecting section on Labs.
bots:
Simply put, you aren't allowed to run IRC bots. (If you don't know what they are, don't worry about it, but remember this rule for when you learn.) If the system staff find any, they'll kill them and send you a warning if they have time. If they manage to catch you after you've been issued a warning, you'll probably find your activities under a lot more scrutiny and risk reprisal of one form or another. [There are vague rumours involving sadistic sysadmins and randomly fluctuating disk quotas, but false rumours abound at SOCS.]
autologout:
You don't have to remember this rule as well as the others, because it's automatically enforced. Basically, if you're idle (inactive) on a FreeBSD machine for long enough, you get kicked off so that someone else can use the machine. "Long enough" is never less than fifteen minutes, and should be longer if other machines are available in the labs. Some users have complained of an unrelated bug causing them to be spontaneously logged out while typing. There is no relation between this bug and the autologout facility.
spamming:
In case the Code Of Conduct doesn't make it clear enough, spamming from your CS account is not tolerated. Do not attempt it; you will be found out. Note that if you are being spammed, you should first send a mail to "abuse@<spammer-domain>". If you continue to receive SPAM from the offending source, you should send the complete mail header to help@cs.mcgill.ca with the subject SPAM. Systems staff will then block that address.
resetting:
DO NOT reset any machine. Bad things can happen, and you'll earn mucho bad karma regardless: your programs will not compile, your email will get lost, and spammers will select you over all other targets. Instead of pushing reset, notify the consultant (if he/she's around) of the problem which makes you want to reset the machine, then try another machine if one's available. If the machine you were originally working on isn't too badly screwed up, you should be able to log in remotely and kill any programs you still have running - this alone may be sufficient to resolve the problem altogether.
account sharing:
You are not allowed to give your password to other people, or to use the accounts of others for any purpose. This is in the Code of Conduct, but, since many people seem to ignore it, we thought we'd reiterate it here.
cracking/compute hogging:
You aren't allowed to run long-running, CPU-intensive jobs for non-school purposes. This includes the SETI search program, the RC5 cracking program, or any other of these communal cycle-sharing projects.
spying:
Just because someone's home directory is readable doesn't mean you're invited to come explore. Please respect the privacy of others.
Home Directory and Storage Quota

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.

disk usage & quota:
Users are allotted a limited amount of storage on every disk we have that stores user files. This limit will normally be zero on every disk except the one that holds your home directory. 'quota -v' will display your limits and how much of your quota is being used, though the usage info will not necessarily be quite up to date.
mail usage & quota:
You can store your mail in your home directory, but initially it's delivered to your Inbox, which is independent of your home and has a quota of its own. (Use the `mailquota' command to check this.) The mail server (po-box) stores all the Inboxes for undergraduates, and will allow you to retrieve the mail from any machine without having to actually log in to the server or download the mail to the machine you're working on (as is the case with the DAS POP system). See the discussion on email in the Internet Services section.
Attributes

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.

password:
You choose this when you create your account, and can change it at any time by means of the command `passwd'. Note the restrictions imposed on password selection discussed in the Accounts :: Creating section. If you forget your password, go to the Help Desk with your student ID card.
mail password:
This is pregenerated when your account is created. To learn what it is, run `mailpasswordinitial'. To change it, run `mailpassword'. Both of these commands must be run from the Solaris machines (willy, skinner, nova, mimi). You may want to keep this distinct from your main password - for this and other details, see http://www.cs.mcgill.ca/socsinfo/mail/.
shell:
By default this is set to tcsh (actually /usr/local/bin/tcsh), a csh-derived shell. If you don't know what a shell is, don't worry about it for the moment, and look it up in the Guide or elsewhere when you get a chance. If you do know what a shell is and you don't like tcsh, you can use `chsh' (CHange SHell) or `passwd -s' to change yours to csh (/usr/bin/csh) or bash (/usr/local/bin/bash). Other shells may not be supported systemwide, so use them at your own peril.
printing balance:
Printing costs $0.05/page, paid in advance. The command `balance' displays your current funds. Go to the Help Desk to put money on your account or to withdraw the money you have in it when you leave McGill.
Student card for after-hours access:
You can access the FreeBSD workstation labs (105N) 24 hours a day by means of your student ID card. However, you must first have your card prepared at the Telecom office (located on the 4th floor of the Ferrier building, next to the James Administration building). You can then open the main door leading to all the labs by simply swiping your card through the reader - no code is necessary. Running `lab-codes' will list the individual door codes for the labs you have access to.

CONNECTING

Connecting from the Labs

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

via DAS/the internet:
For assistance in getting connected to the internet, Contact CC (help@cc.mcgill.ca) if you're using DAS, or your ISP's support line otherwise. See the Guide for details on setting up such a connection (a PPP connection) when you're running Linux at home. What follows is a quick reference to the key server names which you may need when setting up your connection. Consult the Appendix E - Computing Facilities for further information on our servers.

function protocol hostname
mail (outgoing) SMTP ISP's mailhost/mailhost.cs.mcgill.ca*
popmail (fetching) POP, IMAP po-box.cs.mcgill.ca
news (usenet) NNTP news.mcgill.ca
web HTTP www.cs.mcgill.ca
* If you're logged in from an ISP, set your mailreader (e.g., Netscape) to use your ISP's mailhost for all outgoing mail. Check with your ISP for details. When running a mailreader locally on the SOCS system (e.g., in the labs), use mailhost.cs.mcgill.ca.

Remote Access Methods & Restrictions

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*
login/remote execution ssh/slogin all
* See Security Issues below under email.

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).


INTERNET SERVICES

(e)mail

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, aka Usenet

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:

Newsgroups you're encouraged to follow:

Others are given in the Guide.

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

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.

Lynx is a text-based browser which is accessible on all of our systems and which can even be used on a lowly terminal (the Pentiums have a recent version which can handle frames and other frills). Lynx cannot handle Java or JavaScript.

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.


SECURITY ISSUES

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.

Password Sniffing

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.

Password Security

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:

The same measures should be used for any lab combinations you have access to.

X security

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.

Lab Security

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.


GLOSSARY

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.

box (aka machine):
Colloquialism for a (desktop) computer. "I couldn't get Ghostview to start on my machine, so they told me to go try one of the FreeBSD boxes."

CC:
McGill's Computing Centre is responsible for much of McGill's computing and communications resources, including DAS.
website: http://www.mcgill.ca/cc
see also: DAS

DAS:
DAS (Dial-up Access Service) is McGill's own ISP. It provides special rates for students and staff; for details, contact CC.
website: http://www.mcgill.ca/cc/DAS
see also: CC, ISP

environment variables:
Unix is a programming environment in addition to an operating system and, like any other programming environment, it has variables. Environment variables are those variables which, as the name implies, have direct impact on your computing environment. For example, the PATH environment variable tells your shell where to look for executable programs, and the EDITOR environment variable tells other programs which editor you prefer to use.

host, hostname:
Individual computers are often referred to as hosts by Unix users, especially if the computer is on a network. This can be seen, for example, in the hostname command and the .rhosts (remote hosts) file.

IMAP:
IMAP is an improvement of POP which lets the user manipulate mail on the server so that they don't need to download it (though that remains an option). SOCS is moving to IMAP as the standard means of accessing mail because it is generally more secure; others will gradually be phased out.
see also: DAS

ISP:
ISP stands for Internet Service Provider. ISPs are companies that sell Internet access, usually payable on a monthly or usage basis.
see also: DAS

Linux:
Linux is a free multi-user multi-tasking UNIX-like operating system that was originally developed as a "UNIX for PCs". It has since developed sufficiently into its own identity as a unique flavour of Unix, and it is available on more than just the Intel x86 platform.
see also: Unix
website: http://www.linux.org

POP:
POP is a mechanism for allowing people to download mail from the server to which it is delivered. It is convenient in that you can read the mail at home without having to stay online, but this means that either you have two sets of mail folders to try to maintain, or you can only access your mail in one place.
see also: IMAP, email

root:
Under Unix, this is the account name of the superuser that can do anything, being able to override all file permissions. Generally, system administrators are said to have "root access". This means that they have access to the root account and can perform the tasks that require the freedom that root provides.

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.

server:
A computer which performs a particular role for other computers or users. It may provide networked storage (file server), fast processor(s) (compute server), or other more specialized services like mail or web. Most servers actually have multiple roles and provide several services to their networks.

shell:
The shell is a generic term for anything which passes commands to something else. Typically, it refers to the command-line interpreter which reads your keystrokes and interprets them as instructions for the operating system. In Unix, you are not forced to use a specific command-line interpreter and are encouraged to find one that fits your preferences.

SOCS:
(McGill's) School of Computer Science.

spam:
Unsolicited email or news messages; electronic junk mail. While not necessarily commercial in nature, it's generally despised in any form by most people that don't actually produce it themselves. SOCS is working at reducing the volume of local spamming.
see also: email

superuser:
The account which can "do anything"; generally reserved for system administrators. Under Unix, this account is called root.
see also: root

teaching & research:
Every machine on the SOCS computer network can be classified as belonging to one or the other of these two categories. Undergraduates are generally confined to the teaching system, whereas graduate students have access to one or the other or both, depending on their needs.

Trojan horse:
By analogy with the famous story from the Iliad, a Trojan horse is a program which appears innocuous but has a more sinister function. For example, someone who had access to your account could change your environment such that when you typed `ls' to get a list of files, it actually removed them, or copied them to a directory where that other user could access them.

Unix:
UNIX (note capitalization) is a trademarked term that refers to the multi-user multi-tasking operating system developed in 1969 by Ken Thompson and co-authored by Dennis Ritchie at Bell Labs.

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, FreeBSD, Linux, 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

unsupported:
It is not feasible for system staff to maintain all the software that is available. If you compile a program you downloaded off the net and it doesn't work, they won't usually try to figure out why. Some software that is installed on the computers is also designated unsupported. This means that although it is available, staff has decided not to provide any help with it.

window manager:
This refers to the component of X which controls the look and feel of your interface, as well as what kind of window manipulations are possible. Besides being able to choose from among many different window managers, most window managers are themselves extremely configurable, yielding even further flexibility. By analogy, a window manager is to X what a shell is to the command-line interface.
see also: X

workstation:
A fast computer which sits on someone's desk. A workstation is the term most people use to distinguish between a Toy (something running Windows or worse) and a Computer. Originally used only for high-end Unix machines, it is now being applied to PCs as well.
see also: server

X:
X, X11, or X11R6 is the short name for the the X Window System. The numbers following the "X" refer to release/version numbers. X is a windowing system for Unix which features portability, network-transparency, and componentization.
see also: window manager


APPENDICES

A. Getting More Help

While we were tempted to make this a longish appendix describing all kinds of other resources giving help on the systems SOCS provides, we decided instead simply to refer you to the Guide (http://www.cs.mcgill.ca/~guide). There you will find (surprise, surprise) a longish section describing in detail the other useful resources we're aware of.

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.)

B. McConnell Geography

SOCS is housed in the McConnell Engineering Building. The following McConnell landmarks should be known to every computer science student.

Administrative Office

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.

Assignment Boxes

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.

Help Desk

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 help@cs.mcgill.ca, 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.

Non-CS Attractions

At the opposite end of the lobby you will find a complex of EUS initiatives providing various services, including

CSUS Lounge (111N)

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.

C. Account Specifics

Account Types

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)
[quota/mail]
Cost/Requirements
nt Windows machines 10/10 cs102, cs202, cs203, cs250
major none* 10**/10 none
grad none* 30/10
alumni compute servers only 5/10 $30/3 months
mcgill compute servers only 5/10 $50/6 months
* FreeBSD workstations are only available to students currently enrolled in cs206 and/or cs251, or another higher CS course.

** 20 once user takes a CS course # > 300

Status

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:

711 rwx--x--x (world-executable; default)
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.

700 rwx------ (no permissions for anyone else)
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.

755 rwxr-xr-x (world read/executable)
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.

Mail Forwarding

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 themailforwardset command (available only on willy and skinner). The syntax is:

% mailforwardset addr1[,addr2,addr3,...,addrN]
...where addr1,...,addrN is 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 mailforwardset without arguments.

D. Security

Secure Connections

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.

Password Cracking

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.

E. Computing Facilities

The following is a broad survey of some of the resources available to undergraduates at SOCS, and a very basic introduction to usage. If you're unfamiliar with Unix, you're advised to refer to the Guide, the FAQ, or some other more thorough reference. For details about how to access them and where they're situated, see the Connecting section and/or the Guide.

Workstations

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.

Servers

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.

Printers & Scanners

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.

Storage

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

Blackboards are mounted in 103N, 105N and 106N, and are public-writable.