Syracuse University Internet Consultant's Guide John M. Wobus Communications & Development Computing & Network Services Syracuse University October 20, 1989 Document Number: ISUCON-1 (c) Syracuse University Computing & Network Services 1989. Copying, in whole or in part, is permitted only for educational purposes and copies must include this copyright notice. Copying or republishing for commercial advantage is prohibited. For per- mission to republish or distribute, write to: Director of Com- puting & Network Services, Syracuse University, Skytop Office Building, Syracuse NY 13244. Abstract This guide is written for those who must help people use the Internet. It holds information sometimes needed to solve Inter- net users' problems not usually covered by program manuals, sim- ple help-sheets or more theoretical explanations of internets. This guide does not cover problems with Internet electronic mail. Abstract ii Contents Abstract . . . . . . . . . . . . . . . . . . . . . . . . . . ii Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 1 Contents of this Guide . . . . . . . . . . . . . . . . . . . 1 Internet Names and Addresses . . . . . . . . . . . . . . . . . 3 Problems Connecting . . . . . . . . . . . . . . . . . . . . . . 5 Does the Problem effect You? . . . . . . . . . . . . . . . . 5 Problems With Names . . . . . . . . . . . . . . . . . . . . . . 7 Host Tables . . . . . . . . . . . . . . . . . . . . . . . . 7 Domain Name System . . . . . . . . . . . . . . . . . . . . . 7 Default Qualifiers . . . . . . . . . . . . . . . . . . . 8 Checking Names . . . . . . . . . . . . . . . . . . . . . . . 8 TELNET . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Escape Characters . . . . . . . . . . . . . . . . . . . . 10 Pacing and Stopping Output . . . . . . . . . . . . . . . . 10 Using TELNET to reach VM/CMS sessions. . . . . . . . . . . 11 Using TELNET from a VM/CMS system to Unix or VMS . . . . . 11 FTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Binary Mode . . . . . . . . . . . . . . . . . . . . . . . 13 Hash . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Using FTP to reach VM/CMS systems . . . . . . . . . . . . 14 Using FTP to reach VMS Systems using Project Accounting . 14 Other Services . . . . . . . . . . . . . . . . . . . . . . . 15 Electronic Mail . . . . . . . . . . . . . . . . . . . . . 15 FINGER . . . . . . . . . . . . . . . . . . . . . . . . . . 15 LPR . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 NFS . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 POP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 RCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 RLOGIN . . . . . . . . . . . . . . . . . . . . . . . . . . 16 RSH . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Finding Internet Hosts . . . . . . . . . . . . . . . . . . . 17 Finding People . . . . . . . . . . . . . . . . . . . . . . . 19 Finding Internet Services . . . . . . . . . . . . . . . . . . 20 Bibliography . . . . . . . . . . . . . . . . . . . . . . . . 21 Appendix A: Other Sources of Information . . . . . . . . . . 23 Syracuse University Internet Consultant's Guide iii Introduction The Internet is a world-wide cooperative network made up of many interconnected smaller networks. The Syracuse University Internet is a portion of the Internet that is located at Syra- cuse University. It is made up of several LANs (Local Area Net- works), each of which serves a portion of the University. A sin- gle LAN might serve a building, a hallway, or a single room. All the LANs are connected together by a campus-wide network which is connected, in turn, to a network which serves our region (NYSER- Net, the New York State Educational and Research Network) which is connected via national networks (ARPANET and NSFnet) to other regional networks, and through them to other campuses and their LANs. Not all LANs at Syracuse University are part of the Internet. Network programs can only communicate with others of the same "family"(1) so the various University LANs are intended to sup- port programs of one or another particular "family". These include the "internet family" (or the TCP/IP "family") as well as "families" specific to various individual computer and network vendors. Internet networking software has the advantage of tying your computer with virtually all types of computers, and through the Internet, to other Universities and research institutions throughout the world. CONTENTS OF THIS GUIDE This guide is written for those who must help people use the Internet. It holds information sometimes needed to solve Inter- net users' problems not usually covered by program manuals, sim- ple help-sheets or more theoretical explanations of internets. Included is a bibliography of documents of interest to the con- sultant. This guide does not cover problems with Internet electronic mail. Electronic-mail consulting is a large enough topic in its own right. Thus, a separate document, [12](2) (which deals with both Internet and non-Internet electronic mail) is dedicated to it. ---------------------- (1) Family is not a standard data-communications term. In stan- dard terminology: There are different, incompatible data- communications protocols that any particular piece of network software may support. (2) In this document, labels like [12] refer to items in the bib- liography. Syracuse University Internet Consultant's Guide 1 This guide does not cover the same material as covered in the user documents--the bibliography includes guides for users. This guide has only a very sketchy description of the basic theory of Internet networking, an area covered in more detail by [18]. This guide also assumes some familiarity with the Syracuse Uni- versity Internet, an overview of which is provided by [20]. Introduction 2 Internet Names and Addresses This section reviews some of the material covered in [18]. Each computer (i.e. host) on an internet must have a unique num- ber associated with it, called an internet number or internet address.(3) The numbers are usually listed as four numbers joined by three periods where each number is between 0 and 255 inclusive. +---------------------------------------------------------------+ | 128.230.1.49 | | | | Figure 1: Example of an internet address. | +---------------------------------------------------------------+ Ranges of such numbers are allocated to institutions like Syra- cuse University for the use of their own hosts. In theory, users do not need to know about internet addresses. Networking software uses addresses to label the data as it is sent through an internet. However, some software does display internet addresses in messages to the user, most often in error messages. Also, many programs accept internet addresses in place of internet names. Each host on an internet also has a unique internet name, intended for the users' use. The name is a string of characters starting with an alpha and including alphanumeric characters as well as a few "special" characters (including period and minus). The computer is likely to have had a name for other purposes and this can easily be adopted as its internet name. However, Offi- cial Internet Names must distinguish between 150,000 or so hosts of the Internet so a system has been devised to ensure unique- ness. Added to the short name are a series of short alphanumeric strings separated by periods. These extra strings, called quali- fiers, distinguish otherwise-identical names. +---------------------------------------------------------------+ | icarus.cns.syr.edu | | suvm.acs.syr.edu | | sunrise.acs.syr.edu | | | | Figure 2: Examples of an Official Internet Name with qual- | | ifiers. | +---------------------------------------------------------------+ ---------------------- (3) This is different from electronic-mail addresses. Syracuse University Internet Consultant's Guide 3 The qualifiers are assigned to institutions (Official Internet Names ending with ".syr.edu" may only be used by permission of Syracuse University). Internet Names and Addresses 4 Problems Connecting Users commonly complain of problems connecting to some host. Such problems result from various causes. The obvious possibili- ty is that the user is mis-typing something or following the wrong procedure. However, as a consultant, you will want to be aware of the other causes in case the user's procedure proves correct. These "underlying problems" fall within the responsi- bility of the network operator and the system administrators of the involved hosts. However, since it is not clear at the outset where the user's problem lies, the consultant's role is blurred somewhat with the network operator and the system administrators: in effect, they will all share the simplest consulting and diag- nostic tasks. Underlying problems include: 1. The host which the user is trying to reach is simply down. 2. The user is entering a host name for which their internet software cannot figure out the corresponding internet (numerical) address. This technical problem falls under the responsibility of the system administrator for the user's host. The next section of this guide deals with this problem. 3. Some part of the network is either down or too busy. 4. One of the two hosts is setting a distance limitation on how far it will send data. Distances are measured in "hops", i.e. network links. Such limitations defuse some network problems which arise now and then, but as the net- work has grown, the limits built into some older software have become obsolete. DOES THE PROBLEM EFFECT YOU? When a user says he/she cannot reach a host you will find it useful to try to reach it yourself. If you succeed you can con- clude that the problem lies not with the remote host, but either with the user's host or with the user's procedure. TELNET or FTP can tell you if the host is reachable. Either takes an internet name or an internet address as its argument. TELNET and FTP require usernames and passwords before you can use the host, but before they ask for these, they try connecting to the host and display a message indicating success or failure. Both can then be terminated before sign on. For information on using TELNET or FTP check your system's help facility. Syracuse University Internet Consultant's Guide 5 Another program, PING, is available on many systems and is designed for this type of testing. However, it works differently on different systems. See the instructions specific to the sys- tem you are using. Problems Connecting 6 Problems With Names When you invoke an internet application you usually give it the internet name of the host you wish to reach. The first thing the application does is figure out the corresponding internet address which is used during actual communication. This process of looking up the internet address associated with the internet name is called resolving the name. HOST TABLES Different hosts use different methods of resolving names. Some hosts keep a table of internet names and addresses (a host table), and simply look up the address in the table whenever the user types the name. Thus, the host's ability to resolve names depends purely on how complete its table is. There is no complete table for the Internet anywhere. There is a table (called "hosts.txt") which is administered and dis- tributed by the Internet Network Information Center (NIC for short) which lists only about three percent of all the hosts on the Internet.(4) However, if a particular host is intended for use outside its own institution, it is likely to be included in this table. The table is updated twice a week. Any large host which resolves names by table-lookup ought to have a table based on a recent version of "hosts.txt". On Unix systems, the table is stored in the file "/etc/hosts". A single- user host is more likely to have an abbreviated host table including only the host names actually used by its users. DOMAIN NAME SYSTEM The other method of resolving names is called the Domain Name System (DNS for short). Designated computers known as nameser- vers scattered throughout the Internet keep track of the names of hosts in their own area (for example, Syracuse University has a nameserver to keep track of its own names). The user's host resolves a name by sending a query about the name to a nearby nameserver which responds with the corresponding address. If that nameserver does not know the answer, it has ways of finding the one that does. The DNS can resolve the names of nearly all hosts on the Internet and is the "official" way to list hosts. However it is still fairly new and not all software uses it. The DNS also has ---------------------- (4) There is a copy of this file available via anonymous FTP from ICARUS under the path "hosts/hosts.txt". Syracuse University Internet Consultant's Guide 7 a few other potential pitfalls: * Looking up a name can take a while. The process of looking up a name will reflect network outages and poor performance. However, since hosts are usually near their nameservers, if the nameserver can't be reached, usually the host couldn't be reached anyway. * The DNS is made up of hundreds of nameservers: the chances are good that not all are configured properly, making the resolution of some names either slow or impossible. In addition to this, the user's host must be configured to know how to reach at least one nameserver. Thus a likely problem for a newly added host is that it simply hasn't been configured to know of a nameserver. Default Qualifiers Official Internet Names are longer than the names that users usually use for various hosts, and they always contain at least one special character, period (.). To simplify things for the user, some network applications append qualifiers to the name that the user types in. The user's host is configured with a string of "default qualifiers". A typical network application first appends the default qualifiers to the name and tries to resolve it. If that won't resolve, then it tries to resolve the name as the user typed it. Unfortunately, this procedure has disadvantages as well as advantages. A user may learn to reach a host without realizing that they are using a short version of its (fully-qualified) Official Internet Name. If they try reaching it from somewhere else, they may find the name they normally use does not work. CHECKING NAMES Here are three checks to help you identify name problems: * See if you can connect to the corresponding address. If you can, then the problem is with the associated name. * See if the DNS can resolve the name. If the DNS cannot resolve the name, it is not official. * See if the host table can resolve the name. This cannot prove that the name is not official, but since some software depends upon the host table, you may have found the user's problem. Problems With Names 8 The best method to see if the DNS can resolve the name is via a Unix command called HOST. Type "host" followed by the official internet name of a host and it will return the host's internet address. If HOST is not available, another command NSLOOKUP will do the same thing. The difference between the two commands is that HOST has prettier output, it automatically does some other types of lookups, and it is used differently when doing other types of lookups.(5) If neither of these are available and your host has a host table (e.g. "/etc/hosts" on a Unix system) then you can use a search command like Unix's GREP to search for the name. The last method is simply to use FTP or TELNET with the name. The method of resolution will be whatever method your host uses. In any case, it should give you an error message if it cannot resolve the name. ---------------------- (5) The DNS also holds some other information besides the mapping from Official Internet Names to Internet Addresses. Syracuse University Internet Consultant's Guide 9 TELNET This section is the first of several that document hints and quirks specific to various internet-based network applications. ESCAPE CHARACTERS Most TELNET programs give the user an "escape character" which will return the user to TELNET's prompt when typed at any time during the session. Typically, the TELNET program will give a message stating the escape character just before it turns "con- trol" of the session over to the remote host. Following is the message as it appears on some Unix systems: +---------------------------------------------------------------+ | Escape character is '^]'. | | | | Figure 3: Message about TELNET escape character. | +---------------------------------------------------------------+ PACING AND STOPPING OUTPUT While in TELNET, all the output must follow a long path: it passes through by the operating system and network software of the remote host, it is carried by the internet, and it passes through your local host. For network efficiency, the data may be buffered quite a bit, and it may not appear on your screen until sometime after it was sent the program on the remote host. The input from your keyboard follows the same path in the opposite direction. It is not buffered because the remote host must act upon some of the characters immediately. Unfortunately, one result of the buffering is that when you type a character which the remote host uses to stop the output (like Control-S which is often used to pause output and Control-C which is often used to abort it), all the data which has already left the remote host still arrives and is displayed. The effect is that Control-S and Control-C take a long time to stop the dis- play. Typical amounts of output (i.e., 50 lines or less) are very likely to be completely buffered by the time the user types the character, so to the user, it appears that the character did nothing. TELNET 10 USING TELNET TO REACH VM/CMS SESSIONS. IBM operating systems usually have only rudimentary support for ASCII terminals, the type of terminal normally used on the Internet, because IBM concentrates its support on its own 3270 family of terminals. VM/CMS's support for ASCII terminals is known as "line mode" whereas its support for IBM 3270-style ter- minals is known as "full-screen mode". IBM's usual manner of handling ASCII terminals in full-screen mode is to use hardware placed between the ASCII terminal and the mainframe to make the ASCII terminal appear to be an IBM 3270-style terminal to the mainframe software as well as to display data correctly on the terminal. The device which IBM provides to do this is the IBM 7171. Normal TELNET sessions use ASCII. VM/CMS treats such TELNET sessions as line-mode terminals. However, VM/CMS supports a mod- ified form of TELNET to handle full-screen. The catch is that it does not use ASCII. When you TELNET to a VM/CMS system, behind the scenes, it queries your host to see if it supports IBM 3270-style full-screen. If so, the TELNET session is automati- cally switched to full-screen. This will happen if you are using full-screen on a VM/CMS system and you TELNET to another VM/CMS system. Users TELNETing from Unix, VAX/VMS systems, and other systems which use ASCII for data interchange still get linemode. However, there is a modified TELNET network application avail- able on some computers called TN3270. In addition to communicat- ing over an internet to a VM/CMS system, it also carries out the function of the IBM 7171--it takes ASCII data from the user and updates the screen and sends the data to the IBM mainframe just as if it were typed on an IBM 3270-style terminal, and it dis- plays the data properly on the screen. To do this, TN3270 must know what type of terminal the user actually has and how to han- dle it. Many operating systems keep track of what type of termi- nal the user has: for example Unix keeps track of it in a "Unix environment variable". Information on how to handle the ASCII terminal is often divided between the operating system (Unix's "termcap" file holds basic information on how to handle various types of terminals) and a special file, known on Unix systems as "map3270" which holds information more specific to TN3270's func- tion. Among other things, "map3270" defines what sequence of keys must be typed to get the effect of each function key of an IBM 3270. USING TELNET FROM A VM/CMS SYSTEM TO UNIX OR VMS Most non-IBM systems have no trouble emulating ASCII termi- nals, but VM/CMS systems cannot emulate ASCII display terminals. Thus, when you first sign on to VM/CMS, then use TELNET to reach a non-VM/CMS host, you cannot get the screen to display normally and input is constrained to the IBM style of terminal input: only ENTER (or on some terminals, RETURN) causes the remote host Syracuse University Internet Consultant's Guide 11 to act upon your input. Also, under VM/CMS full-screen, the ter- minal still keeps some of the characteristics of VM/CMS full- screen support: the display does not scroll and typed input appears at the bottom of the screen until ENTER (or on some ter- minals, RETURN) is pressed, at which time it the line is redis- played on the first available line of the display. This makes TELNET only marginally useful from VM/CMS to Unix or VMS systems. TELNET 12 FTP This section includes hints and quirks concerning FTP. Other network applications are covered in less detail in the following section. BINARY MODE FTP has two basic modes of operation: character mode and bina- ry mode. Most FTP programs assume character mode as the default. Character mode is designed for files with textual data (e.g. ASCII). Textual data is stored in different ways on different computers. In character mode, FTP translates from the host's format to a standard format as it sends the file over the net- work. At the other end of the connection, FTP translates the from standard format to the format used by the receiving host. Among other things, this takes care of the fact that IBM main- frames use EBCDIC instead of ASCII to encode textual data. It also addresses the fact that different systems encode "end of line" differently. The translation assumes that the input file is in the system's normal format for text data: files not in such a format are modi- fied when certain bit-combinations are present in the file. Typ- ical files not in normal textual format include compressed files (like those ending with ".Z" on a Berkeley Unix system) and "backup" files (i.e., files that "encapsulate" both data and directory information for several files, used especially for mag- netic tape, like those created by Berkeley Unix's "tar" utility). Between computers of the same type, users can often get away with using character mode because the translation process often trans- lates the file back to exactly the same as the original, but there are cases where it doesn't. Thus users may get tripped up using a procedure that worked before, or they may "slightly" cor- rupt files without knowing it. Binary mode disables all this translating. It is most useful, and sometimes necessary when transmitting a file between comput- ers that use the same operating system. HASH Some FTP applications have an option called "Hash" which dis- plays a hash-mark (#) on the screen after some prescribed amount of data is transferred from system to system. This is especially handy for transfers of large files over long distances: it lets the user know whether the transfer is continuing smoothly or if it has simply stopped. Syracuse University Internet Consultant's Guide 13 USING FTP TO REACH VM/CMS SYSTEMS When you use FTP to reach a VM/CMS system, you are not actual- ly signed on and you have no automatic access to any of your minidisks. To reach them, the minidisk must be prepared for sharing according to the methods employed by VM/CMS for sharing minidisks. VM/CMS allows you to specify whether or not others can read your minidisk, and whether and what password they need to do it, and similarly for writing on minidisks. Refer to VM/CMS manuals for more about minidisk sharing and passwords. On SUVM at Syracuse University, the VMSECURE USER command allows the user to control the sharing and passwords of the user's mini- disks. One way around this is to sign on to the VM/CMS host and use its FTP to reach the other host. USING FTP TO REACH VMS SYSTEMS USING PROJECT ACCOUNTING Syracuse University's SUNRISE is an example of a VAX/VMS sys- tem set up to use "project accounting" whereby a each username is associated with one or more "projects". Most projects on SUNRISE are set up so that each username-project pair has associated with it a UID (the "stamp" on a file which says to whom it belongs which is the basis for VMS's file protection), a directory, and a disk quota. Each SUNRISE username has a "default project". When you FTP to SUNRISE, as when FTPing to any system, you can choose the username and directory. However (on SUNRISE), once having chosen the username, its default project's UID and disk quota apply. You can select any directory and can read or write files in the directory you select according to VMS's file protec- tion rules as if you were logged in, using your default project. This means copying files not in your default project will require you to learn the principles of sharing VMS files between projects. However, copying files into SUNRISE has another con- straint: as most SUNRISE usernames have the "base" project as the default which has a limited quota, most SUNRISE usernames cannot receive large files when you FTP SUNRISE from another sys- tem. You can get around this by logging on to SUNRISE (via TELNET or whatever), setting to the project in which you have sufficient disk quota and FTPing in the other direction. FTP 14 Other Services Below are listed some of the other services which internet hosts may provide or use though not all hosts provide these ser- vices. We do not provide instructions for using them: user docu- mentation and help commands (e.g. Unix's "man" command) provide that. In each case, we list a brief description of the service along with any known hints and quirks not always addressed by user documentation. Of these, only Electronic Mail has the sta- tus of being an "official service". ELECTRONIC MAIL Electronic mail probably represents the large majority of con- sulting questions on the Internet. Thus, another document, [12], covers the subject in detail. FINGER The FINGER command returns information about people using oth- er internet hosts. Not all Internet hosts pass out this informa- tion. LPR The Unix command LPR prints files on a lineprinter. It can be configured (via the file, "/etc/printcap") to use an internet to print the output on a lineprinter attached to another host. NFS NFS stands for Network File System. It is a protocol for allowing one host to make use of another host's file system to store its files. "Diskless workstations" use NFS to do all their swapping and disk I/O through an internet and another host. POP POP stands for Post Office Protocol. It is a protocol for allowing one host to make use of another host's mail system with- out the user actually having to sign on (via TELNET or whatever). Thus, for example, a Macintosh user can use a typical Macintosh utility to read and send electronic mail even though the mail is stored on a Unix system. Syracuse University Internet Consultant's Guide 15 RCP RCP is a Berkeley Unix utility to copy files from one host to another. It differs from FTP in that you use it as a single com- mand as you do with Unix's CP command. The system manager can configure systems so that no password is necessary as long as the usernames match, and even if it is not done on a system wide basis, users can configure their own accounts this way. RLOGIN RLOGIN is a Berkeley Unix network utility with a function sim- ilar to TELNET. Differences include: * RLOGIN is not standard: it is supported mainly by systems derived from Berkeley Unix. * RLOGIN automatically passes the terminal type and display screen size from the local host to the remote host. * RLOGIN, by default assumes you will use the same username on the remote system that you did on the local system. * Systems can be configured so you can RLOGIN between them without using passwords. The method is the same as for RCP (as described briefly above). * Between Berkeley Unix systems, RLOGIN does no character translation. It is a little bit more transparent than TELNET. RSH RSH is a Berkeley Unix utility for executing a single command on another internet host. It also follows the model of RCP in allowing users to do so without passwords. Other Services 16 Finding Internet Hosts Users will ask what is the Official Internet Name of a partic- ular host. Usually, the purpose is to try to construct someone's electronic mail address, a topic more properly addressed by [12], particularly because the person to be reached may have an address on a computer not on the Internet. However, in this section, we will briefly outline the methods for identifying the names of Internet hosts. 1. Browse a host table. The format of the host table as dis- tributed ("hosts.txt") has the most information about the hosts, including the model of the computer and the operat- ing system. It does not include the site--you have to infer that from the Official Internet Name. This file is available by anonymous FTP from the Internet NIC (NIC.DDN.MIL) as well as from ICARUS (in directory "hosts"). 2. Guess a name and try to resolve it. The commands HOST or NSLOOKUP will lookup the name in the DNS. A special type of lookup known as "hinfo" will report information about the host, the computer model and the operating system. To do that with HOST, type "host -t hinfo foo" to find out about host FOO. To help your guessing, browsing the host table ("hosts.txt") may help you figure out what the quali- fiers are and browsing the list of BITNET hosts (BITNODE SRCHINFO on SUVM) might give you the unqualified name of the host, or might suggest what type of unqualified names the host's site prefers. 3. Look it up in [11]. It lists only some of the hosts on the Internet, but includes all the BITNET information as well as similar information for some other research- and education-oriented networks. 4. Check the list of domain contacts maintained by the Inter- net NIC and available by anonymous ftp from NIC.DDN.MIL (under the name "netinfo:domain-contacts.txt"). Though it does not list which site is associated with each domain per se, it can help you identify the proper qualifiers. 5. Use the Unix command WHOIS. WHOIS looks in a database maintained by NIC.DDN.MIL which includes people as well as hosts (those listed in "hosts.txt"). It includes site information and allows you to search by site (i.e. "WHOIS MIT" or "WHOIS SYRACUSE"). 6. In the future, you may be able to use the NYSERNet White Pages. It lists people and organizations but not hosts, but is likely to start including hosts in the future. There are different ways to use it--one way is use TELNET to reach WP.NYSER.NET with the username FRED. Syracuse University Internet Consultant's Guide 17 7. Ask the NYSERNet NISC. Direct mail to "nisc@nisc.nyser.net". 8. Ask the postmaster of another host at the same site. Every host is supposed to answer mail directed to "POSTMASTER@FOO" (for host FOO). Finding Internet Hosts 18 Finding People As in finding sites, most of the time that users want to find someone, it is for the purposes of sending mail. For the purpos- es of this manual, we will outline the methods of finding people which are specific to the Internet. 1. If you know the target host, use Unix's FINGER command. It will look up a last name or a username in the "username data" of the host you specify. 2. Use Unix's WHOIS command. It will look up a last name and return, among other things, the corresponding electronic- mail address. The database it uses by default resides on the Internet NIC and includes mainly system and network managers. Some other institutions have alternate WHOIS databases which can be specified by means of an option. 3. Use the NYSERNet White Pages. It will look up a name and return, among other things, the corresponding electronic- mail address. At the present time, this is only a pilot project. One way to use it is to TELNET WP.NYSER.NET with the username FRED. It allows you to do some very lengthy and broad searches, but is more practical if you specify the site in order to narrow the search. Instructions are provided by help commands. 4. Ask the postmaster of the host. Each Internet host is sup- posed to have a "postmaster" address (e.g. postmas- ter@icarus.cns.syr.edu) to whom you can address queries about electronic mail. Syracuse University Internet Consultant's Guide 19 Finding Internet Services Following are some of the ways to identify the various servi- ces offered by different sites and hosts on the Internet: 1. [5] and [6] list some network-related services. 2. USENET News offers, among other things, information about services. One newsgroup, COMP.ARCHIVES lists hosts which archive various collections of files. Various articles posted under different newsgroups often list available ser- vices. 3. The Internet Network Information Center (NIC.DDN.MIL) offers some information via anonymous FTP. One file of interest is a list of electronic mailing lists called "net- info:interest-groups.txt". Finding Internet Services 20 Bibliography 1. Comer, Douglas. Internetworking with TCP/IP. Englewood Cliffs: Prentice-Hall, 1988. 2. Davidson, John. An Introduction to TCP/IP New York: Springer-Verlag, 1988. 3. Frey, Donnalyn, and Rick Adams. !:/@ A Guide to Electronic Mail Networks and Addressing. Newton: O'Reilly & Associ- ates, 1989. 4. Hedrick, Charles. Introduction to Internet Protocols. Cen- ter for Computers and Information Services, Rutgers Univer- sity. 5. Kroll, Ed. Hitchhiker's Guide to the Internet. University of Illinois. 6. Internet Resources Guide. National Science Foundation. 7. NYSERNet Map. NYSERNet, Inc. 8. Quarterman, John S. The Matrix. Digital Press, 1990. 9. Quarterman, John S., and Josia C. Hoskins. "Notable Comput- er Networks." In Communications of the ACM 29:932-971. 10. Syracuse University Internet Map. Computing & Network Ser- vices, Syracuse University. 11. User's Directory of Computer Networks. Austin: University of Texas System, 1988. 12. Wobus, John M. Electronic Mail Consultant's Guide. Comput- ing & Network Services, Syracuse University, 1989. 13. Wobus, John M. Electronic Mail Network Help Sheet. Comput- ing & Network Services, Syracuse University, 1989. 14. Wobus, John M. Help Sheet for Anonymous FTP. Computing & Network Services, Syracuse University. 15. Wobus, John M. Internet Help Sheet for RODAN. Computing & Network Services, Syracuse University. 16. Wobus, John M. Internet Help Sheet for SUNRISE. Computing & Network Services, Syracuse University. 17. Wobus, John M. Internet Help Sheet for SUVM. Computing & Network Services, Syracuse University. Syracuse University Internet Consultant's Guide 21 18. Wobus, John M. Introduction to Internet Networking. Com- puting & Network Services, Syracuse University. 19. Wobus, John M. Networks at Syracuse University. Computing & Network Services, Syracuse University. 20. Wobus, John M. Overview of the Syracuse University Inter- net. Computing & Network Services, Syracuse University. 21. Wobus, John M. Syracuse University Internet Host Adminis- trator's Guide. Computing & Network Services, Syracuse Uni- versity. 22. Wobus, John M. Syracuse University Network Bibliography. Computing & Network Services, Syracuse University. [1], [2], [4] and [18] are useful overviews of the technical side of internet networking. [7] and [10] are maps. [20] is a description of the Syracuse University Internet and serves as a key to the second map. [3], [8], [11], and [12] deal with elec- tronic mail. [6] is a listing of various services available through the Internet. [19] is a general overview of networks at Syracuse University. [22] is a more extensive bibliography. The other documents are other overviews of internet networking and various documents designed for users. Also of interest are manu- als for various operating systems and networking packages such as the Berkeley Unix reference manuals. Bibliography 22 Appendix A Other Sources of Information Following is a list of sources of useful information for Internet consultants: NEW-LIST@VM1.NODAK.EDU A mailing list which announces new mailing lists. TCP-IP@NIC.DDN.MIL A mailing list about TCP/IP protocols. INETNEWS@SUVM.ACS.SYR.EDU A mailing list with news about the Internet--mostly outage reports about NYSERNet and the Syracuse Univer- sity Internet. COMP.PROTOCOLS.TCP-IP The companion USENET Newsgroup for the TCP-IP mailing list. The same articles are posted both in the news- group and the mailing list. COMP.ARCHIVES A USENET Newsgroup which lists sites which archive var- ious software posted through USENET News. ICARUS.CNS.SYR.EDU Offers anonymous FTP, offering a copy of the host table under the path "host/hosts.txt" and has several docu- ments on networking available in directory "info". NIC.DDN.MIL Offers anonymous FTP, offering copies of RFCs and vari- ous files of network configuration information, site contacts, etc. NISC.NYSER.NET Offers anonymous FTP, offering some information about NYSERNet and the Internet. NIS.NSF.NET Offers anonymous FTP, offering some information about networks as well as network maps. NNSC.NSF.NET Allows anonymous FTP, offering list of services avail- able on computers on NSFnet, [6]. Syracuse University Internet Consultant's Guide 23