Overview

This is a brief attempt to cover those details of data networking at Carleton with which every DCA should be familiar. Many interesting bits will be left out but hopefully we'll cover most of the stuff you really need to know.

Cables, and Wires and plugs (oh my)

At the lowest conceptual level of the network are the physical wires and connectors. Most buildings on campus are wired with 10b-T ethernet that ends up in jacks in the wall of most room. Each jack may have 2 or 4 (or more) plugs that accept phone type connectors (call RJ-45). Often 1 or two of the jacks are actually set aside for phone connections. Often these are marked with a small phone icon. Into these jacks go patch cables with RJ-45 connectors on either end. The sysnet people make these patch cables for us and there is often a supply in a box on the bench. The other end of the patch cable plugs into the computer in one way or another. Newer Macs have receptacles of the appropriate sort built into the back. Older Macs, have a different kind of built-in ethernet connector which requires an adaptor (or a transceiver as they're called in this case) to make the connection. Some older Macs, and all PC's require a card that plugs into the motherboard (called a Network Interface Card--NIC) which has a RJ-45 receptacle built into it.

Once you've plugged an appropriate length (one that reaches) patch cord into both the wall jack, and the back of the computer our job (as far as network hardware) is pretty much done. The computer may need software or hardware (a NIC) to make use of the connection. You can find more details about this under the sections on the specific kind of computer--Mac or PC. Also, the port in the wall needs to be "activated". Essentially this boils down to someone going down to the wiring closet and hooking that port into the campus network. (Activating all the ports would be wastefully expensive so we only keep the ports that are actually in use active). Activating ethernet ports is done by the Sysnet group. To start that process you'll need to send a serf to Les (LLACROIX) or C (CLIANG) asking to have a port activated. You'll need to include the building and room, as well as the port number. Usually wall jacks are labeled across the top with a unique identifying code (like 143W-2, for room 143, west wall, port 2). So, if you include the building, the wall jack number, and indicate which receptacle you want activated that should be enough info.

What about Hulings?

Hulings Hall is unique in that it's wiring is fiber, and not twisted pair. No, this doesn't mean the network is faster, just different. Most of the above info still applies with these differences. Instead of a single twisted pair patch cord with an RJ-45 connector, the patch cords have two cables (usually bound together), and the connectors on either end are different. The patch cables, (and wall jacks, and NICs, and transceivers) all come with nifty black plastic covers. These protect the end of the fiber from getting damaged ($$$) so keep them on unless the ends are actually getting connected. Also, the pair of cables is not symmetric but there is no obvious labeling as to which cable goes where so when you connect them up you'll need to swap them if you don't see any blinking connect lights (on the NIC or transceiver). The few PC's in Hulings have NICs with cards that accept the fiber patch cords. The Macs all use one sort or other of transceiver. Some connect the fiber cable to the built in AUI ethernet port on earlier Power Macs. Some transceivers allow the fiber signal to be translated to one that goes through a twisted pair cable with RJ-45 connectors, and on into the built-in RJ-45 ethernet port on newer Macs. (No, standard patch cables WILL NOT WORK for this application--see Sean for special blue and red cables)

What goes over the wires?

I'll ignore a multitude of interesting levels of detail here and skip right to the functional levels that we care about. Essentially there are 3 different sorts of network languages that get spoken across the campus ethernet: IPX, IP, and AppleShare. IPX is the language that PCs and Macs use to speak to the Novell servers for dealing with files, and printing. IP is the language that unifies the internet and therefore forms the basis of things like WWW, telnet, and ftp connections. AppleShare is used only by Macs for both file sharing of local Mac hard drives, and printing directly to networked printers. It's good to keep these distinctions in mind since often it helps in troubleshooting network problems to know if all the languages (or protocols as they're usually referred to) are broken on a particular machine, or just one or two. This sort of information allows one to quickly pinpoint whether a problem is in hardware or software.

A word about IPX

Support for IPX communication isn't built into any of the machines we use so it's software that you'll have to add when setting up a computer. With this software in place you can connect to the Novell servers and all that good stuff. Usually if things don't work you just reinstall the software. It ain't rocket science.

A brief phrase about AppleShare

AppleShare comes built-in to all Macs as part of the standard operating so if all the other network bits are setup, AppleShare is probably already working. Essentially it allows you to "share" portions (or all) of your local hard drive so that it can be accessed by other Macs on the campus network. Since the Novell servers generally do a better job of this sort of file sharing they are often a better choice for that sort of activity. Also, AppleShare allows Macs to print directly to printers on the network (at least the ones that speak AppleShare as most of ours do). This is in contrast to the PC world where a Novell spooler has to be setup to server as an intermediate between the PC and the printer. AppleShare connections are those accessed through the Chooser.

A bunch about IP

IP, the internet protocol has a number of subsets including TCP (hence the familiar TCP/IP acronym). Unlike the other protocols IP messages can be passed off campus. So anything that leaves Carleton must doing so through IP. Email and the web are two examples. Each machine on an IP network (like the Internet)must have a set of configuration numbers to work properly. We currently run software on our PC's and newer Mac which allows (via something known as Dynamic Host Configuration Protocol--DHCP) the computer to retrieve the necessary details from a central server each time it boots. In these cases we don't have to worry about what the numbers are. (unless the central DHCP servers fail in which case there are probably bigger problems..) For older Macs these numbers must be set by hand. See the specific instructions for more details.

What can I do with all this?

What really matters of course, is what useful activities you can perform with all this miraculous technology. There are 4 mains areas that faculty care about (and therefore so should you):

Novell servers--where the files are and how to get 'em

There are currently 4 Novell Netware 4.1 servers on campus--Celeste, Etienne, Fabio, and Carmen. Each is connected to a shared (actually distributed but we don't care about the details) database of user accounts. The essential concept is that one logs into the Carleton Netware "tree" NOT a particular Netware server. Once logged in you can access any part of any server (provided you have the proper privs) without having to type any more passwords. Each of the four servers has one or more volumes which actually contain the files. For the first 3 servers there is a single "usr" volume (e.g. Celeste_Usr) that holds all that server's files. Carmen (the CD-ROM server) has a separate volume for each CD-ROM it holds. On a Mac you mount individual volumes on the desktop (by choosing the particular server, and then the appropriate volume via the Chooser), and then access the files within as with any other drive. Files that you aren't allowed to access simply don't show up in your view of the volume and its folders. On a PC one "maps" virtual drive letters (like k: and l:) to specific directories within the volume, and then those drive letters allow you to access files at that level, as well as those lower in the hierarchy (though not the ones higher in the hierarchy). Again, directories to which you don't have access simply don't appear. Win95 provides both approaches. You can take a Mac-like whole-volume view of things through the "Network Neighborhood", or work through mapped drive letters in "My Computer."

The division of labor among the servers runs something like this. Celeste is the "faculty server" and at the top level of the Celeste_Usr file hierarchy are directories for each department. Beneath these are personal folders for each faculty member (for temporary storage of files they are working on), and a common folder which can be accessed by all the members of the department (to allow file sharing among members of the same department). Also at the top level of Celeste_Usr is the ACNS folder. This is setup similarly to the other department folders and has the following DCA related features. There is a Studs folder with a personal folder for each ACA (for storing work related files), as well as a common space (filled with too much junk) called ACAs. At the same level as the Studs folder is the ACNS Common folder which contains the Archives folder. This contains the repository of much of the software that ACAs and ACC's need on a day-to-day basis. It is organized by OS, and most new software should generally be put in the experimental directory of the appropriate OS. Note that the archive doesn't contain copies of many large, standard apps like Word, or Photoshop which are better to install off floppy or CD.

Etienne is the lab software server. It holds software and configuration files for the ACNS run public labs on the first floor of the CMC, Mudd 169, Willis, the Libe, and the Write Place. Software from Etienne should NOT be used from anywhere else on campus. Not faculty offices, not CMC 122. There are several programs on Etienne (e.g. Photoshop) which will cause problems for legitimate users if they are run outside the public labs. Don't do it. On public lab PC's appropriate drives will be mapped when the machine boots so that the software on Etienne can be accessed. On public lab Macs there is a Maclab icon which is an alias to the location of the Mac software on Etienne. Note that public lab machines usually login with a generic, passwordless Novell account to access the files on Etienne_Usr.

Fabio is the "student" server which contains both personal folders for students, as well as folders used by particular classes. There is also a selection of weird programs used for Course Specific purposes. (They are on Fabio so that they can be accessed from the dorms for students doing class work that requires their use). Fabio also houses the infamous "Hold Folder" which is useful as temporary storage, and a terrible place to put important work.

Carmen, as mentioned before, is the CD-ROM server. At this point all the CD's are there for particular classes and if you need to use one you'll be shown how. DCA's generally don't need to mess with Carmen as part of their job (though things may change).

For information on how to setup a computer to access the Novell servers see the specific networking documentation for Mac, Win3.1 and Win95. For user type questions like "what steps do I actually have to take to get to all these great files" you'll want to check out the sysnet documentation oriented toward students who need to learn how to use their Novell accounts. Most relevant is the section under the Novell Netware heading. (surprise!)

Printing to Network Printers.

Printing from a faculty computer (or any other one) to a networked printer can follow one of two routes. From a Macintosh it is possible to printer directly from the Mac to the printer using the AppleShare protocol. All you need is a Mac and a printer on the same network. If something goes wrong it's either a problem with the Mac (most often) or the printer (not so likely). Most (all?) of the networked printers on campus can speak AppleShare and thus could be printed to by this method. However this doesn't help much for computers running Win3.1 or Win95 which brings us to the second printing method--using a Novell spooler. In this printing method the computer (Mac, or PC) sends the print job to a Novell server, which stores it locally (in a print spooler) and then forwards it (using either AppleShare or IPX) directly to the printer. This system has some advantages since lots of jobs can be sent by many computers and the spooler will take care of collecting them all and sending them one by one to the appropriate printer. This is especially nice in the public labs where print jobs can all be sent to one spooler (e.g. DOS IIIsi) and the spooler can divide the load among several printers (allowing printing to continue even when one of the printers has problems).

From the PC side spoolers appear as items in the Novell Tree, and so are associated with a particular area of the tree--they have a "context". On the Mac side spoolers (as well as the networked printers themselves) appear in the Chooser, and are organized into zones. Networked printers are set to live in certain zones via programs (like Apple Laserwriter Utility) that set the zone (and their names) in the firmware of the printer. Spooler's zones and names are set on the Novell server (something which Dave takes care of for us). Note that many printers are hidden from the Chooser while their corresponding spooler is not. This means that Mac users have to print via the spooler instead of directly via AppleShare. (This eliminates some confusion on the part of users who would rather not understand why there is a listing for both the spooler and the printer which from their point of view are identical things).

If you run into printing problems the first thing to check is whether the user is printing to a spooler, or directly. If to a spooler, then find out whether the print job made it that far. If so the problem is probably not with the user's machine. (print spoolers can be check via NWADMIN on a PC).

For more info on how to setup printing to a networked printer see specific instructions for Mac, Win3.1, Win95.

Sending and Receiving Email

While most students are familiar with VAX Mail for their daily email use (If not see our local guide ) most faculty use Eudora. There is a complete guide to Eudora (and other internet apps) online. The salient points are as follows. When a faculty member starts up Eudora they provide their VAX password (although Eudora can be set to remember this) and Eudora contacts Veblen (via a protocol called POP) and moves any new mail they have to their local computer. It is stored in a series of mailbox folders (which live in the System folder on Macs, and in a Eudora folder on PCs). They can create new mailboxes and organized the mail they've received in any fashion they like. Eudora is often set to check mail on a regular basis (e.g. every 30 minutes) and then left running in the background. Common Eudora problems center around two issues. The first is the confusion over where the messages actually live. Messages that have been downloaded from veblen sit on the faculty member's hard drive. Messages that haven't been read sit in the veblen NEWMAIL mailbox just like they do for students. Some confusion can arise if the mail is read via VAX Mail (e.g. via dial-up) in which case it moves out of the NEWMAIL folder into some other (MAIL by default). The next time Eudora is started it won't find theses messages and they may appear to be lost. One can fire up VAX Mail and move the messages into the NEWMAIL folder using the Move command. (see help in VAX Mail). The second cause of confusion is attachments.

Attachments are a way of getting around the problem that the internet mail protocol was only designed to deal with plain ascii text files. In order to send an arbitrary binary file (like a Word document or a GIF file) over email it has to be converted into ASCII. There are various methods of doing this and both email programs (the sending one and the receiving one) have to understand and agree on the method. If this doesn't happen the person on the receiving end gets a message full of gibberish. Often the gibberish can be saved to a file and run through a converter program like Mpack, or UUencode, or esscode to retrieve the original binary file. But this is often a bigger hassle than the original sender intended. Often it's is easier just to send the message as text, copy and pasting out of Word (or whatever the application was) if necessary. (Obviously this doesn't help with non-text things like pictures). One last confusing point about attachments is that even when it works the file often ends up in some unknown location on the hard drive. Often a Find is in order, and one can also check the message and the Eudora settings for clues as to where the converted file landed. (The Eudora folder is a popular location).

Web Browsing

Using a web browser is pretty straight-forward and something most of you are familiar with, but here are some tips and local tricks. Most copies of Netscape on campus are setup with 3 levels of cache. This means that the content of the web pages is stored somewhere closer than the web-site itself which is supposed to help make web pages come up faster. There are two levels of cache built into Netscape. Copies of the most recently viewed pages (and associated images et al) are held in RAM so that can be returned to very quickly. Netscape also keeps copies of the not quite most recently viewed pages on the hard drive (in a directory/folder called cache) so that these pages can be called up pretty quickly. The amount of space devoted to these two types of storage can be modified in the Network Prefs section of the Options menu. (Note that you can't change the RAM cache size on Macs this way). This menu also allows you to empty out the caches so you get "fresh" files.

There is another level of cache setup on campus. Most browser on campus are setup to use a local "proxy server". (this is controlled by putting http://www.carleton.edu/proxy.pac in the AutoConfig section of the proxy section of the network setup in Netscape's Option menu) Every time netscape tries to get a page it checks the local server, and gets a copy there if there is one. If not then when the info is loaded from the web site a copy is kept in the local proxy server. In this way much off the info people are getting of the web is stored locally on campus so the second time you (or anyone) goes to access it the data only has to travel cross campus. Actually, the real web server will be contacted first but only verify that the file hasn't changed. So, you may see an initial pause while that is checked and then the page will come up quickly.

Often if pages are coming up weirdly on one machine, but not on others it's worthwhile to clear out the Netscape caches and then do a Reload to clear out the copy on the proxy.

One other big issue is how to get multimedia files (like audio or video) to work when you click on a link that points to some. The key requirements are to have a program (often a "helper-app" or a "plug-in") that can deal with that type of file, and also to have netscape properly associate that file type with that program. Netscape has some reasonable pointers as to how to go about this.