Welcome to the SOCS computer system

With this handout we hope to introduce you to School's computer system, and point you in the direction of other more detailed sources of information. In particular, see [[[GUIDEURL]]]; this pamplet is section 1 of the [[[GUIDE]]].

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 wish to browse the glossary first to make sure you're familiar with the jargon we use.

Table of Contents

(this is just a temporary convenience - a proper one will be done later)

ACCOUNTS

Introduction

It is strongly recommended that you create a Unix account whether or not you have any courses that require it. To use any part of the system except the NT machines you need a Unix account; more importantly, you cannot receive mail without one, and some useful announcements are sent out by mail. Your Unix account gives you, at a minimum:

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

Creating

To create your Unix account, you need to go to the web page [[[NEWUSERURL]]]. 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.)

If you don't have access to a computer at McGill, log on to one of the PCs in one of McConnell 102n, 103n, or 105n, 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 our database as being enrolled in the necessary courses or program.

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 have a need to use your account before the course information is ready, or if you have problems creating your account, come by the [[[HELPDESK]]] and they'll usually do things manually via MARS.

After identifying yourself to the newuser program, you will be asked to select a login name and password. Together, these allow you to login (i.e., access) your account. Note that your login name is also your email address if you stick it before "@cs.mcgill.ca", e.g. ncc@cs.mcgill.ca.

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:

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

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 lisa) rather than just a workstation when issuing these commands.

* have your card prepared at the Telecom office (located on the 4th floor of Ferrier building, next to the James Administration building)

* send mail to help in order to be given access to the keycard program.

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:

Most of the labs are accessible 24 hours a day to students currently enrolled in CS courses. 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.

The content of the labs is described in the appendix on computing_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 needs to be respected, because keyboards are notoriously sensitive to spills, and McGill has a rodent problem. There is also the issue of excessive noise. Some people never want to leave the labs, so they just hang out there and chat (loudly) with their friends. For people doing last-minute debugging, this is sheer torture. Please have some consideration for their plight, which you will no doubt someday share.

Logging in to a 3151 terminal

While you shouldn't have any difficulty figuring out how to log in to a workstation, using a terminal (the amber text-only screens and keyboards with no box attached) is a bit more complicated. Assuming the terminal you're sitting in front of is working properly, the following steps should log you in. See the handout on configuring terminals or the [[[GUIDE]]] for details on fixing a confused terminal.

1. Press '.' (period) to get a 'SERVICE?' prompt. (Don't worry if you see a lot of garbage at this point - it'll disappear by step 4.)

2. Type 'socs' <Return>

3. Wait a couple of seconds and hit Return until an 'Annex username:' prompt comes up

4. Type your login name, hit Return, then do the same for your password.

5. You are now connected to the Annex, a server for terminals. From it you can type 'rlogin SERVER' to log in to the given server, or simply the server's name if it's one of the better known ones. Note that hitting CTRL-HoldScreen while logged in from a terminal will bring you back to the annex, from which you can use standard shell job control commands to return to your session or switch to others.

6. Often the setup is screwed up so that many commands (like ls) don't work, producing output only on the top line of the screen. The fix for this is usually to type 'stty -tabs.'

7. Once you've closed all your other sessions, don't forget to log off from the Annex as well (using 'exit' or 'logout'.)

Connecting From Home

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 the fact that the insecure 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: simply put, you cannot access the workstations from home by any means other than slogin or (in the case of the Linux machines) ssltelnet. The servers allow connections from anywhere by slogin, but are somewhat selective when it comes to insecure connection methods. Basically, don't worry about it unless you get 'Connection Refused' messages when you try, in which case you should explain the situation to [[[STAFF]]] and give them the hostname of the system you were trying to connect from so that they can grant it access.

Here are the supported access methods:

Access Type   Secure               Insecure

file          scp/ssh,             rcp/rsh,
transfer      slogin-wrapped ftp   ftp

mail access   *                    IMAP, POP

login/remote  ssh/slogin,          rsh/rlogin
execution     ssltelnet            telnet


* covered under email section

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

NOTE: as of this term (Fall 1998), you cannot use a standard email client to access your mail. Inboxes are now 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. Fetchmail will download your mail for you such that your old favourite mailreader can access it. See mail forwarding in the appendeix for more information.

News a.k.a. UseNet

News is usually a means of procrastinating rather than a useful resource, though it has the potention to be either. We mention it here mainly because many announcements are made to local newsgroups and nowhere else, so they at least are worth following. Moreover, all CS courses have newsgroups in which people can ask questions and be generate discussion on course-related topics; the T.A.s and prof may even contribute themselves.

Newsgroups you really should follow:

Newsgroups you're encouraged to follow:

Others are given in the [[[GUIDE]]].

Newsreaders installed include tin, trn, gnus (an emacs-based newsreader) and such all-in-one mailreaders as Netscape's messaging client and Pine. The last two are available just about everywhere (though netscape was recently removed from the servers, all the machines you'll work on except terminals have it.) The others are available on some machines and not others; 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 - SLRN is a good heavy-duty newsreader if you find yourself becoming a slave to the habit.

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 all access anonymous FTP sites as easily as the actual ftp program can (just open ftp://ftp-server-name/pathname).

FTP is not recommended for doing copies of your own files from one computer to another due to its inherant security flaws (see password sniffing and the above Remote Access Methods subsection for an explanation and alternatives.)

So as it happens, you can choose to remain completely ignorant of ftp without missing out on anything.

The World Wide Web

We have three 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). Hopefully the servers will soon be upgraded to that version as well; check the Solaris servers first, as that's where all of the servers are inevitably headed.

Lynx cannot handle Java or Javascript, though as of this writing, even the most recent version of Netscape (4.05) doesn't do everything for Java perfectly. You should only have to worry about it if the Java applet you're playing with uses some of the very latest features, in which case you should try running HotJava (read on).

Netscape is what virtually everyone uses. It is available under NT, on the Macs, and under Linux, and how to start it should be evident on all but the latter. For Linux, if you're using the fvwm window manager (the default), there should be an icon on your screen from which you can start the latest version. Alternatively you can invoke it from the command line as `communicator'.

There is an older version (3.01) installed on some machines which takes about half as much memory and runs about twice as fast. To start that one, type `netscape'.

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 [[[staff]]] rather than rebooting the machine; that way the problem may eventually be fixed.

HotJava is currently only available under Solaris, though naturally you have to have it display on your workstation. Details on running it are not given here as it isn't fully supported, but it is made available for Java programmers who are somehow compelled to stay on the bleeding edge.

Note that unless your X server is running at 8 bpp, the colours will be so screwed up as to make it unusable. To run at 8bpp, hit CTRL-ALT-F6 to switch to a text console and log in again there. Then type

startx -- -bpp 8 vt3
You can now switch to that X server by hitting CTRL-ALT-F3 and back to your own by hitting CTRL-ALT-F2.

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 an invitation to hackers akin to leaving your door ajar. 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, 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 secureconnections.

Note that if you log in via a terminal, you may as well give up on keeping your password private. This may change in the near future; any such change will be posted on socs.system (see news if you don't know what socs.system is.) [?] [annex3 .rhosts?]

Password Security

The end result of being forced to use hard passwords is often that one end 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 [[[SECURITYURL]]]. 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. Assuming you don't want to risk that happening, you should become at least mildly paranoid about protecting your account, as it's the only way to deal with the existence of unscrupulous users.

GLOSSARY

APPENDICES

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 102N (soon), 103N, 105N, and 106N; see the Connecting section for details.

Assignment Boxes

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.

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 seconds 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 (111)

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.

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 alumni accounts (CS graduates who wish to retain their accounts), mcgill accounts (non-CS students or staff who are renting access and disk space from us), eng accounts (chem. eng. students working on aspen), and guest accounts.

Type   Access restrictions   Disk space allocated (MB) [quota/mail]
ugrad  none*                 10/5 (20 once user takes a CS course # > 300)
grad   none*                 30/5
alumni can only use binkley  5/3
mcgill can only use lisa     5/3
eng    can only use willy    don't ask/3

alumni and mcgill accounts are rented for three- and six-month blocks, respectively. eng accounts are kept for the duration of the course, as with ugrad accounts for students not actually enrolled in a major CS program (though the account isn't normally deleted at the end of the term - it is usually just deactivated; see Status below.) The other accounts are usually kept as long as the user is affiliated with McGill in the given capacity.

If you do not currently have access to an account and would like to rent an alumni or mcgill account, go to the [[[helpdesk]]] or the [[[computingcentre]]], respectively. Alumni accounts cost $30 for three months and mcgill accounts cost $50 for six months.

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 (there's little distinction made between the two with Unix) 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 with mode 711, with which 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, such 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 <UNIX> <ADVANCED>

Under the new mail setup, things are somewhat different from the standard Unix mail delivery system. All mail used to go to mailhost.cs.mcgill.ca, which send undergraduate mail to lisa. lisa would then check the recipient's .forward file if any and use the rules given there to figure out what to do with it. The end result was usually that the mail got dumped into /var/spool/mail/USERNAME, and the user was then free to read that mail on any of the servers where /var/spool/mail was available.

The arrangement now is that the mail never leaves mailhost.cs.mcgill.ca; users can read it without downloading it using IMAP, or can copy messages to their home directories or home machines using POP. The hitches? Both protocols are insecure if used from anywhere other than [[[SECUREMAILACCESSHOSTS]]]; moreover, .forward files are not available to the mailhost to allow users to control the delivery of their mail.

A system was implemented to work around the second problem and in the process provide a means for users who want to read their mail elsewhere or with an older mail client to do so. Before continuing, make sure you understand what a .forward file is - read the man page or the [[[GUIDE]]] entry.

If you want mail to be delivered the old way (to a server from which you can access it without POP/IMAP), the simplest way is to create a file named .forward.po-box containing the single line

mailhost2.cs.mcgill.ca

A script runs on the fileservers at least once an hour which will update the mailserver with this information, after which your mail will be delivered to mailhost2; it should then be accesible just as it used to be before we moved to this system (fall 1998.)

Note that your .forward.po-box can only contain email addresses, unlike a standard .forward file. Also, if you have a .forward file but no .forward.po-box file, and the .forward file contains only email addresses, it will be renamed to .forward.po-box such that it takes effect. Otherwise your mail would only be delivered to mailhost.cs.mcgill.ca.

Summary:

Configuration

Here are a few references to things you might want to look into regarding customizing your account setup:

Security

Secure Connections

There are two programs installed on our servers for encrypted logins: slogin and ssltelnet. The first has been around longer and is installed on all of our machines. The second was only installed on a few machines this summer to provide more choice to users for whom slogin was not a viable option. If you're having trouble connecting directly to a server via ssltelnet, try connecting instead to a Linux machine (like a lab Pentium) and then run slogin to reach your final destination.

Some details on using these programs is provided in access methods and in the [[[GUIDE]]], but you can usually just use them more or less like rlogin and telnet (respectively) if you know those programs. So long as you use slogin or ssltelnet 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 any of these mechanisms which we don't have space to go into here, so look in the [[[GUIDE]]] [?] to get the full scoop. For the moment, just use slogin.

The following servers are on a private network, so you can safely type passwords when communicating between them: lisa, po-box, willy, skinner, binkley, www. (Note that this is only true if your first connection is itself secure.) Thus, if you have connected securely to lisa, you can then type your password to retrieve your mail from po-box without worry. However, you should still be alert. If I decide to slogin from a lab machine to lisa and then rlogin to binkley, I'm perfectly safe in doing so. As soon as I log on to a machine not in the above list, however - say I slogin or rlogin to a lab machine - any passwords I type are available for people on the remote network to read. Thus you're still advised to use insecure access methods only when no other alternatives are available.

If any of this doesn't make sense to you, please ask someone that does understand it, or just use slogin indescrimantly in order to be sure.

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 (it's actually a one-way hash algorithm rather than encryption, for the technically minded) 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 (which is most of them) 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. This is why hard-to-type passwords are enforced.

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.

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. Moreover, you should use a password with at least 7 characters.

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

Terminals

A few terminals are still lurking about the labs. These are especially good for when you can't log in to a Pentium and you want to make sure the problem isn't with your account; for example, if your quota is full you won't be able to log in to an X workstation. Logging on to a terminal enables you to make some room so you can log in without having to pester anyone else. .. ref oddities

Some people even use the terminals by choice, finding them quicker to log on to just to check their mail. See logginginto aterminals in the section on Connecting and terminal operation in the [[[GUIDE]]] for details. See also Jacob's article advocating terminals in the SOCS Culture section.

Terminal configuration is also described in the [[[GUIDE]]] and in the labs.

Workstations

Note that because they are running Unix, the non-NT workstations will all allow you to log in to them to do work remotely. See lab etiquette for some issues relating to this.

(make table?)

Servers

We have several Sun compute servers at our disposal for coursework: binkley, willy, skinner and lisa. 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.

(make table)

Printers & Scanners

NT text printouts are free and emerge in the printer in 106N, and all other printouts (sent to lp2/hpp) go to the printer in room 103N. See balance under Accounts for pricing.

The NT printer and lp2 will only accept text jobs, whereas hpp will accept postscript and a few other formats, including text. Note that lp2 and hpp are the same physical printer. If you're confused by the redundancy, suffice it to say that lp2 was once a huge line printer and hpp was the name of one of the first laser printers available to undergraduates.

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 recyling bin under the printer.

A scanner is installed on [[[scannerhost]]]; 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 removeable media in the [[[GUIDE]]] for instructions on accessing all but /stor.

Blackboards

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

Getting More Help